don quijote de la mancha

another query, that uses the ‘//’ symbol, book//chapter[number = ’1’], returns: we observe several things from these examples. firstly, although two kinds of elements are specified in each of the queries (library and section in the first, book and chapter in the second), the query results contain only the elements of the rightmost type. secondly, the results are flat and structural relationships are not immediately obvious. xpath does provide a mechanism to interrogate the returned items using the concept of axes. an axis defines a node set relative to the current node, and there are a number of pre–named axes. in particular, using the ancestor–or–self axis we can select all ancestors of the current node as well as the current node itself. however, these sets of ancestors may contain nodes not included in the original query. for instance, if we were to use axes in the second example (above), we would get the two sub–trees shown in 3 / 13 volume 50 (2011) model querying-by-example figure 2. finally, there is a substantial effort required to generate results shown in figure 2 using the axes approach, and a further effort to reduce the sub–trees in the figure to contain only the element types specified in the query (i.e. book and chapter). 3 related work a common approach to querying trees is xquery [w3c10b]. xquery is a w3c recommendation, is built on the xpath [w3c10a] expressions, and is often regarded in relation to xml as the equivalent of sql [bea09] to databases. it is the language for finding and extracting elements and attributes from xml documents. its advantages include its ability to query xml data and the ease with which one can learn it. there have been attempts to enhance the xquery usability (e.g. [bcc05], but the key limitation, other than those discussed earlier, is that its mechanisms for dynamic binding and query composition are cumbersome. pattern matching in trees has received much research attention. the main focus has been on traditional databases and performance aspects, such as the efficiency of matching algorithms [ajk+02][bks02][clt+06][cjlp03][gkp05][ho82][jac+02][kos89]. for example, hoffman and o’donnell [ho82] introduce new techniques for pattern matching, analyzed for time and space complexity. chen et al. [clt+06] work on minimizing intermediate results, while in [cjlp03] the authors demonstrate how their plans based on generalized tree patterns significantly outperform straightforward plans and plans based on navigation. kosaraju [kos89] reports improvement in pattern matching time by extending convolutions and suffix trees, and by partitioning trees into chains and anti-chains. sarkar’s work on tree pattern matching in source code [ssb01] aims to produce an optimized compiler that performs retargetable object code generation. there is also an abundance of work specific to querying xml data. amer–yahia et al. [acs02] suggest techniques for approximate xml query matching which reportedly outperform rewriting–based and post–pruning strategies. al–khalifa et al. [ajk+02] argue that complex query tree patterns can be decomposed into a set of primitive relationships between pairs of nodes. the query pattern can then be matched by (i) matching each of the binary structural relationships against the xml database, and (ii) ‘stitching’ together these basic matches. bruno et al. [bks02] propose a technique that uses a chain of linked stacks to compactly represent partial results to root–to–leaf query paths. these are then composed to obtain matches for the specified patterns. from a mathematical perspective, there is research on conjunctive queries over trees, sometimes referring to incomplete xml trees (a.k.a. tree patterns), and at other times talking about data exchange and integration (i.e. transforming tree patterns). gottlob et al. [gks04] present a detailed study on the tractability of conjunctive queries over trees. they define a dichotomy based on a set of axes and demonstrate that these queries are tractable if they use a subset of: {child, nextsibling, nextsibling*, nextsibling+}, {child+, child*} or {following}. for each other set of axes, the combined complexity of the query evaluation problem is np–complete. bjorklund et al. [bms07] investigate containment of conjunctive queries over trees considering tree patterns without data value comparisons (unlike our approach). they found that the containment p ⊆ q holds if there is a homomorphism from the canonical database of q to the canonical proc. mpm 2011 4 / 13 eceasst database of p, and that such a homomorphism is a sufficient, but not a necessary condition for containment (in relational databases it is a necessary condition). the results were encouraging, as the complexities (compared with acyclic queries) did not increase much. barcelo et al. in [blps10] aim to provide a classification of problems associated with incompleteness for xml documents. they prove a strong generalization of polynomial–time algorithms for xml cases by addressing standard problems of consistency (does an incomplete database have a completion satisfying some conditions) or query answering (asking, for instance, whether a given tuple of values is a certain answer, i.e. an answer that is independent the way in which the missing parts of patterns are interpreted). arenas and libkin [al05] use declarative schema formalisms to define formal semantics for data exchange between xml schemas, and providing the basis for extensions dealing with rewritability, query answering, or schema composition. in the mde space there has been substantial work on the qvt standard for model querying and transformation, and implementations of qvt and qvt–like languages have appeared. constraint languages such as ocl have also been used for model querying, though these are targeted at models that comply with the omgs metamodelling infrastructure. finally, there have been attempts to deal with recursion in pattern matching. lindqvist et al. [llp07] propose a star operator, similar to that in kleene algebra, for a model query language. this is a pattern based approach that can be used to represent recursive or hierarchical structures in models. the approach is based on rule schemas with sub–graphs that can be cloned or copied before applying the rule. varro et al. [vhv08] present core data structures and algorithms for matching graph patterns with general recursion. although the approach is limited to recursive sub–patterns, a highly–sophisticated local–search based graph pattern matching allows the tool (viatra2) to scale up to very large models. körtgen [k0̈8] develops a loop–construct to express repetitive structures, and introduces a concept of a general region that could be used for further extensions like recursive transformation rules. 4 approach the key objective of our work was to provide a practical mechanism for querying models (represented as trees) by example. specifically, a query that is in the form of a tree–like pattern should produce a result in the same or similar structure as the pattern itself. a logical conjecture which follows is that it is highly desirable that the query result: (a) includes the structural relationships from the source tree, (b) is in a form of a tree, and (c) provides this hierarchical association in an obvious (i.e. easily accessible) manner. this is so that structure can be directly exploited in down–stream activities, and so we do not have to manage flat query results (which could be extremely large for complex queries on large models). in other words, we desire queries that are compositional. we can see that the second query pattern in the previous section is a tree: a node of type book at the root of the tree, and a descendant node of type chapter. it is beneficial that the result is in the same (tree) form. consequently, instead of having the results in a list form as shown earlier, or in a cluttered tree form as in figure 2, we would get them as a set (or a sequence) of trees shown in figure 3 that closely resemble the query pattern. this can be achieved in xquery as follows: 5 / 13 volume 50 (2011) model querying-by-example figure 3: query results that resemble the query pattern. for $b in $input//book, $c in $b//chapter where $c/@number = "1" return element book { $b/@*, $c } however, the limitations mentioned in section 1 are still valid: besides the platform specificity, xquery does not scale up well and for a more detailed search in large input trees, queries quickly become more elaborate whilst the processing time is substantially increased. we now explain in more detail the four components of our method. we define a subject tree simply as a tree–like representation of an input model. this representation is the well–known rooted tree from graph theory [wik11]. the vertices (nodes) represent the structural model elements, whilst the edges represent the containment relationship. nodes are of two types: normal and reference (to support cross–referencing within a model and across different models). in addition, each node may have a set of one or more properties attached to it. a property has three attributes: the type, the name and the value. figure 4 depicts the subject tree meta–model in uml notation on the left, and a tree example on the right. this meta–model represents the interchange format which allows us to operate on many commonly used specifications (uml, java, sql, etc.) in a consistent fashion. (a) (b) figure 4: subject tree: meta–model (a), and an example (b). a tree query consists of two parts: the mandatory pattern and an optional set of matching proc. mpm 2011 6 / 13 eceasst figure 5: a simple tree query with a pattern that uses only normal nodes (left) and its result set (right). conditions. the patterns are trees in a similar sense as the subject trees, with a few differences. firstly, two kinds of nodes can be present in a pattern: normal nodes and wildcard nodes (explained by example shortly). here, 3 constraints related to the structure of the pattern must hold: (i) the root must always be a normal node, (ii) a wildcard must have children, and (iii) the children of a wildcard node must all be normal nodes. secondly, pattern nodes must be named, i.e. they have a single mandatory attribute called name which is of the string type. and thirdly, pattern nodes do not have a set of properties associated with them. instead, normal pattern nodes (only) typically have matching conditions attached. a matching condition comprises three elements: property name, property value, and a compare method. during the execution of a tree query, the matching algorithm parses the set of properties of the current node in the subject tree, comparing the property names and their values with corresponding elements in the matching condition using the specified compare method. when a match is found, this method returns a boolean true value. we now describe how a pattern containing only the normal nodes is matched against a subject tree. a simple query is shown on the left of figure 5. the pattern consists of two nodes (l and b). the l node has a single match condition which, in simple words, looks for nodes in the subject tree whose native type is library. similarly, the b node looks for books. running the query against the subject tree in figure 4, returns the result shown on the right of figure 5. if we wanted to query the tree from figure 4 to return all the book chapters, but that each returned chapter is associated with the book it belongs to, it would be impossible to achieve it with a single query that has only the normal nodes. this is because the chapter elements are placed in different position within the tree. the ulysses book is divided in parts, then in chapters. the second book has no parts – only chapters. we would have to use separate queries as shown in figure 6: the query on the left for the alice book, and the query on the right for the ulysses book. moreover, the query results would consist of sub–trees that include the nodes which lie in between the required ones (e.g. contents and part nodes shown in figure 7. it is not difficult to see that the resulting sub–trees can be substantial in size and almost as equally hard to study as the original subject tree. the introduction of the wildcard nodes in the pattern resolves this problem. a wildcard node can be regarded as a ‘sink’ or a ‘collector’ for the intermediate nodes that are typically not relevant (desired), and are typically (but do not have to be) excluded from the query results. for instance, the pattern in figure 8 that searches for books and chapters is sufficient to parse the entire subject tree from figure 4 in a consistent fashion (the wildcard node is shown as a star). this means that all the matched sub–trees (unlike those in figure 7) have the same structure 7 / 13 volume 50 (2011) model querying-by-example figure 6: queries needed to find chapters (normal nodes only). figure 7: query results for the chapter search shown on the left of figure 6. (figure 8). importantly, the intermediate nodes are not present in the result set. there are two minor differences between the definitions of the normal and the wildcard nodes. firstly, the wildcard nodes do not have to be named (the name attribute can be an empty string). and secondly, the wildcard nodes have an additional attribute (of boolean type) called hide with default value equal true. this means that, by default, the intermediate nodes (like the content and part nodes from figure 7) will not be part of the matched sub–trees in the result set. graphically, this is shown by a dashed line that outlines a wildcard node (figure 8). (if hide is false, the line is solid and the intermediate nodes are included in the result set). finally, each patternnodeinstance has its own solution. this is best illustrated by example. in figure 10, (a) represents a tree query pattern that we are trying to find in the subject tree (b), and the solution is represented in (c). for simplicity, we assume that all nodes in (b) are of the same type, and that the matching conditions associated with the pattern nodes in (a) require that a, b, c and d can match any node type in the subject tree. in other words, we are really trying to find the node structure specified by the pattern within the subject tree (b). it is pretty obvious that there are only two matches as shown in (c). we can now relate the 3 types from figure 9(b) (solution, image and patternnodeinstance) to the nodes shown in the previous tree examples. for instance, in figure 8, the ‘query results’ corresponds to the solution, ‘match x’ (x=1, 2, 3,) corresponds to the image, and the children of the ‘match’ nodes are of the patternnodeinstance type. a pattern is a tree structure with a single root node and zero or more other nodes. however, each pattern node with all of its descendants can also be described in the same way, i.e. a pattern proc. mpm 2011 8 / 13 eceasst (a) (b) figure 8: a query with a wildcard (a) used against the tree in figure 4, and the result set (b). node with its descendants is just another pattern. consequently, each has its own solution. next, we provide a high level overview of the algorithm used to obtain the query results. the algorithm uses recursion, is designed to traverse the subject tree only once, and does not return non–injective matches. the search starts by calling patterns search method, passing a reference to the subject tree to be searched (figure 11). the contract() method (line 8) ensures that any wildcard nodes with their property hide set to true are invisible in the solution (the meaning of the word ‘contract’ here is that of the verbs ‘shrink’ or ‘reduce’). the findsolution() method is called next. the parameter required by this method is a set of nodes that need to be searched (along with all of their descendants). although a subject tree only has one immediate child (the tree root), the instancetree class implements this as a set of instancetreenode objects to make it consistent with the implementation of the children property in instancetreenode, and to enable a single implementation of the findsolution() method. the findsolution() method is recursive; its body consists of a single loop that iterates through the set of instance nodes (method’s sole parameter). here, the method performs two key steps. firstly, it attempts to match the current instance node to the pattern’s root. and secondly, it continues iterating through the current instance node’s children (by recursively calling itself) and thus ensuring navigation of the entire subject tree. the code listed in figure 11 traverses the entire subject tree, node by node, and attempts to find all matches for the pattern’s root node. to use an example, this would be the equivalent of trying to match the root node b from figure 6 (either pattern – left or right) with the nodes of the subject tree from figure 4, i.e. finding all the books. if a match is found, then the code on lines 18 through to 26 (figure 11) is executed. on line 19, a patterninstancenode object is created, pairing the pattern’s root node with a subject tree node that matches it. the constructor for the patterninstancenode class immediately searches for a solution. if a solution is found for the patterninstancenode object (line 20 in figure 11), it is then encapsulated inside 9 / 13 volume 50 (2011) model querying-by-example (a) (b) figure 9: tree query meta–model (a) and the query result data model (b). an image object and added to the overall solution (lines 22–24). 5 prototypical scenarios space limits prohibit a detailed example of the approach. we have applied the model querying approach extensively, particularly for system integration scenarios where we needed to first carry out matching (via querying) of heterogeneous system models expressed in multiple dialects of uml (e.g., legacy version 1.x models) supported by different tools (e.g., obsolete versions of rational rose). another scenario involved using queries in a model management workflow, featuring analysis of an input model and then transformation to a different model. the input figure 10: example: (a) a pattern, (b) a subject tree, and (c) the solution. proc. mpm 2011 10 / 13 eceasst figure 11: pattern class: search algorithm (top level) model was a uml model consisting of multiple class diagrams and state machines expressed in uml 1.x (legacy models created for a system engineering project). the output model was expressed in a dsl (annotated behavioural models for simulation). we first used the model querying to extract information from the uml class and state machine diagrams sufficient for simulation; the results of this (in the form of trees) was then passed to a model transformation that produced models in the dsl, optimised for simulation. the input models consisted of large numbers of model elements, and the tree patterns for querying consisted of tens of elements; the query results were produced effectively instantaneously. 6 conclusions and future directions querying is a critical component of model management, as evidenced by standards and languages such as qvt, ocl and xquery. a wealth of querying techniques that treat models as trees have been proposed, but the limitations of these approaches which make it difficult to extract structural information from query results, which are not based on example, and which are often platform–specific need to be addressed for multi–paradigm modelling and model management in the large. overall, we have argued that current model querying techniques generate results that are typically flat, and that a research gap lies in providing mechanisms that allow us to obtain structural information from the result set in a straightforward manner. we have presented a solution that consists of four components: a common interchange format, a tree query meta–model, a query results meta–model, and an algorithm. we argued that various model management techniques and activities, such as model analysis, model transformation and 11 / 13 volume 50 (2011) model querying-by-example system integration, could benefit greatly from our approach. at the moment, our approach is implemented in a prototype tool and we use graphical notation for specifying queries and patterns. our near–term objectives are to provide external interfaces (in the form of an api) to the query engine, and provide a concrete textual notation akin to xpath, in order to support diverse users and diverse model management scenarios. bibliography [acs02] s. amer-yahia, s. cho, d. srivastava. tree pattern relaxation. in 8th international conference on advances in database technology (edbt 2002). pp. 496–513. springer berlin / heidelberg, prague, czech republic, 2002. [ajk+02] s. al-khalifa, h. jagadish, n. koudas, j. m. patel, d. srivastava, y. wu. structural joins : a primitive for efficient xml query pattern matching. in 18th international conference on data engineering. p. 12. 2002. [al05] m. arenas, l. libkin. xml data exchange : consistency and query answering. in 24th acm sigmod-sigact-sigart symposium on principles of database systems (pods ’05). pp. 13–24. acm new york, baltimore, md, 2005. [bcc05] d. braga, a. campi, s. ceri. xqbe ( xquery by example ): a visual interface to the standard xml query language. acm transactions on database systems (tods) 30(2):398–443, 2005. [bea09] a. beaulieu. learning sql. 2nd ed. o’reilly media, 2009. [bks02] n. bruno, n. koudas, d. srivastava. holistic twig joins. in 2002 acm sigmod international conference on management of data (sigmod ’02). p. 12. acm press, new york, new york, usa, 2002. [blps10] p. barceló, l. libkin, a. poggi, c. sirangelo. xml with incomplete information. journal of the acm 58(1):1–62, 2010. [bms07] h. björklund, w. martens, t. schwentick. conjunctive query containment over trees. in 11th international conference on database programming languages (dbpl ’07). volume 77(3), pp. 66–80. springer berlin / heidelberg, 2007. [cjlp03] z. chen, h. v. jagadish, l. v. s. lakshmanan, s. paparizos. from tree patterns to generalized tree patterns: on efficient evaluation of xquery. in 29th international conference on very large data bases (vldb’03). pp. 237–248. vldb endowment, 2003. [clt+06] s. chen, h.-g. li, j. tatemura, w.-p. hsiung, d. agrawal, k. s. candan. twig 2 stack: bottom-up processing of generalized-tree-pattern queries over xml documents. in 32nd international conference on very large data bases (vldb’06). pp. 283–294. vldb endowment, seoul, korea, 2006. proc. mpm 2011 12 / 13 eceasst [gkp05] g. gottlob, c. koch, r. pichler. efficient algorithms for processing xpath queries. acm transactions on database systems 30(2):444–491, 2005. [gks04] g. gottlob, c. koch, k. u. schulz. conjunctive queries over trees. in 23rd acm sigmod-sigact-sigart symposium on principles of database systems. volume 53(2), pp. 180–200. acm new york, paris, france, 2004. [gl07] e. guerra, j. de lara. adding recursion to graph transformation. in 6th international workshop on graph transformation and visual modeling techniques. volume 6. electronic communications of the easst, braga, portugal, 2007. [ho82] c. m. hoffmann, m. j. o’donnell. pattern matching in trees. journal of the acm 29(1):68–95, 1982. [jac+02] h. jagadish, s. al-khalifa, a. chapman, l. lakshmanan, a. nierman, s. paparizos, j. patel, d. srivastava, n. wiwatwattana, y. wu, c. yu. timber: a native xml database. the international journal on very large data bases (vldb) 11(4):274– 291, 2002. [k0̈8] a.-t. körtgen. modeling successively connected repetitive subgraphs. in 3rd international symposium on applications of graph transformations with industrial relevance (agtive 2007). pp. 426–441. springer berlin / heidelberg, kassel, germany, 2008. [kos89] s. kosaraju. efficient tree pattern matching. in 30th annual symposium on foundations of computer science (focs 1989). pp. 178–183. ieee, 1989. [llp07] j. lindqvist, t. lundkvist, i. porres. a query language with the star operator. in ehrig and giese (eds.), 6th international workshop on graph transformation and visual modeling techniques (gt-vmt 2007). pp. 69–80. electronic communications of the easst, braga, portugal, 2007. [ssb01] v. sarkar, m. j. serrano, b. bluestein simons. retargeting optimized code by matching tree patterns in directed acyclic graphs. 2001. [vhv08] g. varró, a. horváth, d. varró. recursive graph pattern matching ( with magic sets and global search plans ). in 3rd international symposium on applications of graph transformations with industrial relevance (agtive 2007). volume 67651, pp. 456–470. springer berlin / heidelberg, kassel, germany, 2008. [w3c10a] w3c. xml path language (xpath) 2.0 (second edition). technical report, 2010. http://www.w3.org/tr/xpath20/. [w3c10b] w3c. xquery 1.0: an xml query language (second edition). technical report, 2010. http://www.w3.org/tr/xquery/. [wik11] wikipedia. tree (graph theory). 2011. http://en.wikipedia.org/wiki/tree (graph theory). 13 / 13 volume 50 (2011) introduction example related work approach prototypical scenarios conclusions and future directions automated model synchronization: a case study on uml with maude electronic communications of the easst volume 41 (2011) proceedings of the tenth international workshop on graph transformation and visual modeling techniques (gtvmt 2011) automated model synchronization: a case study on uml with maude artur boronat, josé meseguer 14 pages guest editors: fabio gadducci, leonardo mariani managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst automated model synchronization: a case study on uml with maude artur boronat1, josé meseguer2 1aboronat@mcs.le.ac.uk, university of leicester 2meseguer@uiuc.edu, university of illinois at urbana-champaign abstract: design specifications of software-intensive systems involve models that have been defined with different modelling languages for different purposes. hence, a specification can be seen as the description of a system from multiple viewpoints, each providing domain-specific constructs for modelling the system in a more precise way. such heterogeneity of models can jeopardize the consistency of the specification, because updates in one viewpoint may cause unpredictable design errors in other viewpoints, which can then be transferred to the implementation. omg’s meta-object facility enhances the automation of the model consistency management by providing a uniform format for different modelling languages. in this paper, we illustrate a technique, based on rewriting logic and on strategies for finding inconsistencies in mof-based heterogeneous specifications and for resolving them in an automated way. keywords: model synchronization, inconsistency repair plans, mof, maude. 1 introduction software-intensive systems comprise a wide variety of heterogeneous software artefacts, including requirements, design models, program code, test suites, configuration files and documentation, which are usually developed by distributed teams. these artefacts describe parts of the same system from different points of view and at different levels of abstraction, hence overlapping in various ways. in this setting, evolution is a challenging, expensive task since changes can result in unanticipated inconsistencies and incompleteness [ac07]. to enhance the automated management of software evolution, model-driven software development methods advocate the use of models as first-class citizens to abstract relevant features of a system from implementation details. within this context, omg’s meta-object facility [omg06] provides a common metadata infrastructure in which the abstract syntax of modelling languages is defined by means of so-called metamodels, which can be viewed as type graphs, so that software specifications can be represented as (typed attributed) instance graphs. two main approaches to manage inconsistencies in model-based heterogeneous specifications can be distinguished by considering how a set of consistent specifications is defined: either by means of coupled graph grammars, such as the case of triple-graph grammars [sk08], or by means of mof metamodels with constraints. in the first case, consistency is characterized by membership in the resulting graph language, and automatically-generated transformations deal with incompleteness of views while consistency is ensured by construction. in the second case, 1 / 14 volume 41 (2011) mailto:aboronat@mcs.le.ac.uk mailto:meseguer@uiuc.edu automated model synchronization: a case study on uml with maude materialization of specification inconsistencies during the design process is assumed to be a natural, unpredictable (and even desirable) event [fgh+94], for which means are provided to identify inconsistencies and to fix them. in the second approach, given a set of metamodels and a set of mappings among them defining inconsistency constraints, inconsistencies in a multi-domain specification have to be found and repaired until consistency is restored, i.e., until no inconsistency constraint is satisfied. achieving a practical solution to this problem involves addressing several challenges, such as scalability and usability issues [smbb10]: once a conflict is detected, an automated mechanism should find a number of resolution choices; resolution of conflicts should minimize the creation of new conflicts; the order in which inconsistencies are resolved is important to reproduce the changes to be applied, due to possible conflicts between updates. a sequence of updates that restores the consistency in a specification is called a repair plan. in this work, we follow this second approach, focusing on a novel encoding1, in maude, of state-of-the-art techniques for defining and managing design inconsistencies so that they can be applied in mof multi-domain specifications. in particular, inconsistency constraints are expressed as parametric model propositions that are formally defined in equational logic. once inconsistencies are detected, resolution choices are locally obtained following the user-defined choice generator function technique proposed in [egy07]. our approach uses rewriting logic to define a search space of possible repair plans from a given inconsistent specification, and exploits maude’s pattern matching algorithm modulo associativity, commutativity and identity (acu) and search capabilities to find an efficient repair plan that brings an inconsistent heterogeneous specification to a consistent state, where efficiency is estimated by means of the number of inconsistencies that need to be fixed after the application of an update. we use the breadthfirst search (bfs) algorithm built within maude’s search command. we explain how several strategies to search consistent specifications can be expressed in a succinct way. the paper is structured as follows: §2 summarises the formalization of models as graphs in rewriting logic and a dual representation of models in our approach; §3 details the main contribution of the paper by defining the chief constructs to identify inconsistencies, to provide inconsistency resolution choices and to find efficient repair plans by exploring the search space of inconsistent specifications using a bfs; §4 provides an account of related approaches; and §5 draws some final conclusions on the approach. 2 an algebraic approach to encode and manipulate mof models 2.1 rewriting logic a theory in membership equational logic [mes98] is used to define algebraic data types, specifying their types using sorts and subsorts, their operations using equationally-defined operators and structural properties using equations and memberships. such a theory is defined as a pair (σ, e ∪ a), where σ is a signature specifying sorts, subsorts, kinds and operators in the theory, e is a collection of statements (equations and memberships, possibly conditional) and a 1 some familiarity with algebra and equational logic is assumed, mainly concerning to the notions of algebra, binary operations, and equational specifications of operations. proc. gtvmt 2011 2 / 14 eceasst "?" name : string class name : string operation ownedoperations owningclass * name : string statemachine «abstract» vertex kind : pseudostatekind pseudostate name : string state finalstate name : string transition* 1 src outgoing * 1 tgt incoming * container transitions * container states name : "display" '0 : class name : "select" '1 : operation name : "stop" '2: operation name : "play" '3 : operation name : "draw" '4 : operation name : "streamer" '5 : class name : "stream" '6 : operation name : "wait" '7: operation name : "connect" '8 : operation kind : initial '9 : pseudostate name : "waiting" '10 : state name : "playing" '11 : state name : "connect" '12 : transition name : "stream" '13 : transition name : "select" '14 : transition src tgt tgtsrc srctgt waiting playing select() stop() play() draw() display stream() wait() connect() streamer initial join fork junction choice «enumeration» pseudostatekind name : "?" '15 : statemachine statesstates states transitions transitions transitions class diagram metamodel state machine metamodel class diagram model (abstract syntax) state machine model (abstract syntax) class diagram model (concrete syntax) state machine model (concrete syntax) select connect stream figure 1: simplified version of uml metamodel for class diagrams (top left) and for state machines (top right); syntactic representation of a class diagram (middle) and of a state machine (bottom), both in abstract and concrete syntax. is a set of structural axioms, such as associativity (assoc), commutativity (comm) and identity (id: element), defined for some binary operators. under the assumption that the equations e are confluent, terminating and sort-decreasing, the theory (σ, e ∪ a) defines the initial model t (σ, e ∪ a), which is the quotient of the σ−algebra tς of ground terms modulo the equations and axioms e ∪ a. in rewriting logic [bm06], a membership theory (σ, e ∪ a) can be extended with rewrite rules r specifying local concurrent transitions in a system, whose states are algebraically characterized by the membership theory. in this work, we use membership theories for formalizing metamodels and for representing and manipulating models as directed graphs; and we use rewriting logic to analyze sequences of model manipulation events that enforce the consistency in a multi-domain specification in the presence of inconsistencies. 2.2 a state-based view of mof models in this section we recall an algebraic representation of mof models as (equivalence classes of) terms in an equational theory and explain how models are semantically treated as (typed attributed) graphs [bm10]. the abstract syntax of models is defined through metamodels. a metamodel is a collection of metaclasses that contain properties, which can be either attributes − typed with basic datatypes − or references − typed with other metaclasses. metaclasses can specialize other metaclasses through metaclass inheritance relationships. in fig. 1 (top), an excerpt of the uml metamodel for class diagrams and for state machines is shown. a metamodel is syntactically formalized as an order-sorted signature σ and a set of equations. 3 / 14 volume 41 (2011) automated model synchronization: a case study on uml with maude σ can be split into a generic part providing constructs (sorts, subsorts, and operators) for defining directed graphs of objects, and a metamodel-specific part containing type-relative information (metaclass names and properties). in the generic part, an object in a model is represented by a triple < o : c | ps > using the operator op < : | > : oid cid propertyset -> object . so that o is a unique object identifier2, c is a class name, and ps is a record where each field represents either a slot (an attribute value) or a reference (a collection of pointers to other objects). objects can be grouped in collections of objects by means of an associative, commutative union operator (denoted by juxtaposition) with identity none: subsort object < objcol . op none : -> objcol . op : objcol objcol -> objcol [assoc comm id: none] . in the metamodel-specific part of the signature σ, there is a sort for each metaclass name and there is a constant defining this sort if the metaclass is not abstract. metaclass inheritance is formalized by means of subsort relationships between the sorts corresponding to each metaclass. taking into account the resulting subsort ordering, maximal sorts in this ordering are declared as subsorts of the sort cid. in addition, properties defined for each metaclass are encoded as constructors3 of the sort property defining fields for the record propertyset. the classes vertex, state and pseudostate from the metamodel in fig. 1 are encoded as follows: sorts sm/state sm/pseudostate sm/vertex . subsorts sm/state sm/pseudostate < sm/vertex . op sm/vertex/outgoing‘: : oidset -> property . op sm/vertex/incoming‘: : oidset -> property . op sm/state : -> sm/state . op sm/state/name‘: : string -> property . op sm/pseudostate/kind‘: : pseudostateenum -> property . in this work, the carrier of the sort objcol4 in the initial algebra tς, e ∪ a, associated with the equational theory (σ, e ∪ a) corresponding to a metamodel, provides the language of models that conform to this metamodel, i.e., its algebraic semantics [bm10]. note that each such model corresponds to an instance graph whose nodes are associated with metaclass names defined in the metamodel. the abstract syntax graph of an excerpt of the uml class diagram in fig. 1 (middle left) is represented as an (acu) term as follows: < ’5 : class | name : "streamer", ownedoperations : ’6 ’7 ’8 > < ’6 : operation | name : "stream", owningclass : ’5 > < ’7 : operation | name : "wait", owningclass : ’5 > < ’8 : operation | name : "connect", owningclass : ’5 > 2.3 an event-based view of mof models in this section we present an algebra inspired in the mof reflective api, initially presented in [bor07] and applied in [bhm09], for creating and manipulating mof models in heterogeneous specifications, i.e., specifications that consist of models conforming to different metamodels. 2 we define identifiers using literals prefixed with a quote, such as ’a or ’1, using the built-in datatype qid, which is defined as a subsort of the sort oid. 3 we use the qualified name of properties to avoid name clashes when several metamodels are taken into account. however we will abbreviate their name to their last suffix when there is no room for confusion. 4 in previous work, we used the sort model to define the language of well-formed models for a given metamodel. in this paper, we simplify the sort structure to provide a simpler presentation of models as terms. proc. gtvmt 2011 4 / 14 eceasst we define the representation of a multi-domain specification, the notion of model event and how events can act on a specification. domains. a domain encapsulates a specific model within a heterogeneous specification and tags it with a label name that identifies the domain and with the name of the metamodel, indicating the type of the domain. syntactically, a domain is given as a structured object that has a unique name, a type name corresponding to the name of the metamodel and a single property, for which we simply omit the name, containing a collection of objects representing the model: sorts domain multimodel . op < : | > : oid cid objcol -> domain . a multi-domain specification is given as a multiset of domains where the uniqueness of the domain names is assumed implicitly. subsort domain < multimodel . op none : -> multimodel . op : multimodel multimodel -> multimodel [comm assoc id: none] . model events. a model event syntactically represents an atomic change in a model, mainly concerning the creation and destruction of objects, and the manipulation of their properties. each possible change is represented by an operator that always carries as argument the identifier of the object that is manipulated. assuming that the name space of object identifiers is global, i.e., object identifiers are unique in a multi-domain specification, create(d,c,o) represents the creation of an object with identifier o of type c in the model of the domain d; destroy(o) represents the removal of the object with identifier o; set(o, p, v) represents the initialization of the attribute with name p with the value v in the object with identifier o; and set(o1,p,o2) represents the addition of the identifier o2 to the collection of identifiers in the value of the reference with name p in the object with identifier o1. sort modelevent . op create : cid oid -> modelevent . op destroy : oid -> modelevent . op set : oid propname string -> modelevent . op set : oid propname oidset -> modelevent . a complex change can be represented as a sequence of model events. this is a achieved through the associative concatenation operator ; : sort modeleventseq . subsort modelevent < modeleventseq . op ; : modeleventseq modeleventseq -> modeleventseq [assoc] . a model can then be created or modified by a sequence of model events. the sequence of events that creates the class "display" with the operation "select" in the class diagram given in fig. 1 corresponds to the following sequence create(cd, class, ’0) ; set(’0, name, "display") ; create(cd, operation, ’1) ; set(’1, name, "select") ; set(’1, owningclass, ’0) ; set(’0, ownedoperations, ’1). converting from event-based to state-based representation. in our approach the canonical representation of a model is given by its state-based representation. in fact, the state-based representation of a model corresponds to the representative of an equivalence class of model event sequences, those that lead to the same canonical form (up to name isomorphism with respect to object identifiers). the following operator enables the application of events to a term representing the state-based view of the model. 5 / 14 volume 41 (2011) automated model synchronization: a case study on uml with maude op [ ] : [multimodel] [modeleventseq] -> [multimodel] . the semantics of this operator is equationally defined below and corresponds to the intuition described for each model event above. note that the operator is only partially defined5. ceq [ < dn : mn | oc > m ] create(dn, c, o) = < dn : mn | new( c, o ) oc > m if not (o in oc) . ceq [ < dn : mn | < o : c | ps > oc > m ] destroy(o) = < dn : mn | oc > m if nac("nodanglingedge", oid : o, < dn : mn | oc > m) . eq [ < dn : mn | < o : c | pn : v1, ps > oc > m ] set(o, pn, v2) = < dn : mn | < o : c | pn : v2, ps > oc > m . ceq [ < dn : mn | < o1 : c | pn : os, ps > oc > m ] set(o1, pn, o2) = < dn : mn | < o1 : c | pn : o2 os, ps > oc > m if o2 in oc . eq [ < dn : mn | < o1 : c | pn : os, ps > oc > m ] set(o1, pn, null) = < dn : mn | < o1 : c | pn : null, ps > oc > m . where new(c,o) is an operator defined with an equation for each metaclass and is metamodel dependent. an object can only be destroyed if it does not leave dangling edges. this is checked by the negative application condition "nodanglingedge", which checks that an object with a pointer o does not exist. the nac function enables the application of a rule that calls it when a specific pattern is not found in the multi-domain specification. attribute values can be unset with the event set( o, pn, v2 ) by using the default value of the attribute as new value v2, while references can be unset by using the value null in the event set( o, pn, null ). 3 an approach for detecting and resolving model inconsistencies in this section, the core components of our approach are introduced and are illustrated with a uml case study, adapted from [elf08]: definition and detection of inconsistencies; generation of repair event sequences for a specific inconsistency; and generation of repair plans. 3.1 model inconsistency relation in our approach, a heterogeneous mof specification is syntactically encoded as a multiset of domains containing viewpoint models conforming to different metamodels. nonetheless, since these models are regarded as views of the same system, there is usually an overlap among them, so that the same information may be represented from different points of view and with different modelling languages. this overlap is defined by means of syntactic or structural constraints and by means of semantic constraints. since the goal in this work is to find inconsistencies, we encode the negation of such consistency constraints by means of an inconsistency satisfaction relation m ⊧ i(o, p), where the existence of inconsistencies in the multi-domain specification m is determined by the truth value of a proposition i parameterized with an object identifier o and a property name p. in the example, two model predicates are defined in a similar way as in [bhm09] for indicating violations of the requirements that a state machine must correspond to a class in the class diagram (classnotdefined), and that transitions in a state machine must be labelled with a method of the class associated with the state machine (methodnotdefined). the satisfaction operator for the inconsistency relation is as follows: 5 the use of brackets indicates that the operator is not defined for the entire carrier of the sort multimodel, i.e., it is partial and is therefore defined over its kind. proc. gtvmt 2011 6 / 14 eceasst figure 2: graphical representation of the inconsistency relation of the case study. op |= : multimodel inconsistencyprop -> bool [frozen] . where the attribute frozen avoids the application of rewrite rules to the multimodel. the inconsistency constraints defined in fig. 2 are expressed as equations defining the inconsistency satisfaction relation as follows: op classnotdefined : oid propname -> inconsistencyprop . ceq m |= classnotdefined( o2, sm/statemachine/name ) = true if < dn : mn | < o2 : statemachine | name : cn, ps2 > oc2 > m2 := m // nac("cnd-nac", classname : cn, m) = true . op methodnotdefined : oid propname -> inconsistencyprop . ceq m |= methodnotdefined( o4, sm/transition/name ) = true if < dn : mn | < o3 : statemachine | name : cn, ps3 > < o4 : transition | name : opn, container : o3, ps4 > oc2 > m2 := m // nac("mnd-nac", classname : cn operationname : opn, m) = true where nac("cnd-nac", classname : cn, m) checks whether there is not a class with name cn in the domain cd in the multi-domain specification m, and nac("mnd-nac", classname : cn operationname : opn, m) checks whether there is not a method with name opn in the class with name cn in the domain cd in the multi-domain specification m. finally, an equation that is applied in case an inconsistency cannot be found is added for completing the equational specification of the inconsistency predicate: eq m:multimodel |= ip:inconsistencyprop = false [owise] . the purpose of the inconsistency relation is twofold: the definition of inconsistencies and their detection. when a given inconsistency proposition is satisfied, the parameters of the proposition identify the location of the inconsistency as indicated in the following section. 3.2 inconsistency location inconsistencies occur when certain model elements in one or several domain models satisfy the inconsistency relation with regard to a given inconsistency proposition, hence violating the associated consistency constraint. most inconsistencies can be avoided by manipulating property values (including both attributes and references) in the conflictive objects of a domain model. hence, in our approach an inconsistency is uniquely determined by a pair < o, p >, formed by an object identifier o and a (qualified) property name p in the object identified by o. 7 / 14 volume 41 (2011) automated model synchronization: a case study on uml with maude sorts inconsistency . op < ‘, > : oid propname -> inconsistency . sets of inconsistencies are defined in the usual way through a binary operation that is associative, commutative and idempotent, syntactically represented with the juxtaposition operator . in the multi-domain specification in fig. 1, two inconsistencies are found with regard to the inconsistency relation in fig. 2, namely <’14, sm/transition/name> and <’15, sm/statemachine/name>. 3.3 choice generator function once inconsistencies are detected, an automated approach for conflict resolution must provide one or more possible solutions in order to fix the inconsistency. given that the location of an inconsistency is determined by a property in a specific object, resolution choices are syntactically constrained by the type of this location. hence, they are specific to one metamodel. we follow the proposal from [elf08], whereby resolution choices are manually encoded in choice generator functions independently of inconsistency constraints. in addition, choices are provided as finite sets of elements that are extracted from the multi-domain specification using a query mechanism, imposing a reasonable bound on the number of decisions that have to be explored. this reduces the amount of resolution decisions that have to be encoded from #inconsistency constraints * #location types to #location types only, enhancing maintenability. choices for a particular inconsistency location type are given by the following function: op repairchoices : multimodel oid propname modeleventseq -> modeleventseq . which has to be refined for each inconsistency type location. this function takes as arguments a multi-domain specification and the location of an inconsistency (identified by an object identifier and a property name), and generates a set6 of repair actions, where a repair action is a sequence of events that eliminates the inconsistency. in the example, possible choices for fixing the name of the state machine are the set of names of classes in the class diagram. the following equation, generates a set event with the name of each class in the class diagram: eq repairchoices(< dn : cd | < o1 : class | name : cn, ps > oc > m, o, sm/statemachine/name, ras ) = repairchoices( < dn : cd | oc > m, o, sm/statemachine/name, (set(o, sm/statemachine/name, cn) ras) ) . similarly, possible solutions for fixing the label of a transition, when it does not correspond to a method in the class associated with the state machine, are the names of the methods of the corresponding class. 6 this set is also passed as argument so that it can be recursively built through the application of equations. proc. gtvmt 2011 8 / 14 eceasst eq repairchoices( < dn1 : cd | < o1 : class | name : cn, ownedoperations : o2 os1, ps1 > < o2 : operation | name : opn, ps2 > oc1 > < dn2 : sm | < o3 : statemachine | name : cn, transitions : o os2, ps3 > oc2 > m, o, sm/transition/name, ras ) = repairchoices( < dn1 : cd | < o1 : class | name : cn, ownedoperations : os1, ps1 > oc1 > < dn2 : sm | < o3 : statemachine | name : cn, transitions : o os2, ps3 > oc2 > m, o, sm/transition/name, (set(o, sm/transition/name, opn) ras) ) . note that the second equation only returns choices if the name of the class associated with the state machine belongs to an existing class. hence, in case both a class name and a method name are found to be inconsistent, repairchoices will only provide choices for fixing the method name after the class name has been fixed. the following equation returns the set of choices produced for a specific inconsistency when no more repair actions can be generated: eq repairchoices( m, o, pn, rps ) = rps [owise] . 3.4 repair plan selection and generation in the previous section, the approach for detecting inconsistencies and for proposing resolution choices has been explained. in this section, a mechanism for building repair plans as sequences of model events that remove inconsistencies from the specification is developed. definition 1 (repair action) given a multi-domain specification m and an inconsistency < o, p > such that m ⊧ i(o, p) for a specific inconsistency proposition i, a repair action ra for this inconsistency, i.e., ra ∈ repairchoices(m,o, p,∅) is a sequence of model events such that [m] ra ⊭ i(o, p). since the inconsistency satisfaction relation ⊧ can be defined for different inconsistency propositions and a multi-domain specification may contain several inconsistencies of different types, we extend the notion of repair action to the notion of repair plan as follows: definition 2 (repair plan) given a multi-domain specification m, a set i of inconsistency propositions, and an inconsistency satisfaction relation ⊧, a repair plan for an inconsistent specification m is a sequence rp = ra1;...; ran such that rai ∈ repairchoices(m,o, p,∅) for an inconsistency < o, p > in m, and [m] rp ⊭ i for all inconsistency propositions i in i. note that repairing a specific inconsistency may result in more inconsistencies. this definition captures the idea that a repair plan is a sequence of events that leads to a consistent model. the exploration of possible repair plans is achieved by specifying a conditional rule that, given a specific inconsistency, chooses a repair action from the set of choices provided by the function repairchoices for the inconsistency. the notion of repair plan is useful because it enables the analysis of sequences of repair actions corresponding to different inconsistencies and their composition, instead of considering the resolution of one inconsistency at a time. in our analysis technique, the notion of state in the search space involves the dual view of 9 / 14 volume 41 (2011) automated model synchronization: a case study on uml with maude a model as a pair [ m | es ], where m is a multi-domain specification where each domain includes the state-based representation of a viewpoint model, and es is a model event sequence providing the event-based representation of the same multi-domain specification. the search space is generated by applying a single rule with two sources of non-determinism: (1) several inconsistencies can occur in a multi-domain specification; and (2) for each inconsistency there may be several repair choices. we consider three ways of analysing choices for resolving a specific inconsistency: (i) by brute force, which allows us to explore all choices for a specific inconsistency; (ii) by an efficient repair-driven strategy, which constrains the number of repairing choices that can be applied for a given inconsistency; and (iii) by extending the second strategy to all inconsistencies. brute force. the following conditional rule obtains the set of inconsistencies through the function getis, which recursively collects a set of inconsistencies in its second argument, and chooses one, namely , modulo associativity commutativity in the first matching equation in the condition of the rule. the choices for repairing this inconsistency are retrieved by means of the function repairchoices, from which one repair action is chosen, namely ra, which is applied to the multi-domain specification in the right hand side of the equation in order to fix the selected inconsistency. we also append this repair action to the current repair plan in the second component of the state. the rule is shown in maude format as follows: crl [ m | rp ] => [ [ m ] ra | rp ; ra ] if < o , pn > is := getis(m, none) // ra ras := repairchoices(m, o, pn, noaction) . efficient repair-driven strategy. the rule above is applied with a brute force strategy, in which all choices for fixing inconsistencies are explored, even those that insert more inconsistencies or that would not make sense from the user point of view. for example, if the name of the class associated with the state machine happens to be inconsistent with the class diagram, the choices that would be proposed by repairchoices are: "streamer" and "display". however, choosing "display" would make most of the labels in the state machine inconsistent, whereas choosing "streamer" would lead to a model with only one inconsistency left. definition 3 (extended repair action) given a multi-domain specification m and an inconsistency relation ⊧, an extended repair action is a pair (ra,n), where ra is a repair action, and n is a natural number indicating the number of inconsistencies w.r.t. ⊧ in the specification [m] ra, i.e., the number of inconsistencies left in the model m after applying the repair action ra. definition 4 (strict order over repair actions) given a multi-domain specification m and an inconsistency relation ⊧, we define the strict order (a,<)m ⊧ over the set a of extended repair actions (ra,n) for a given inconsistency < o, p >, where ra ∈ repairchoices(m,o, p,∅), by extending the strict ordering over the component with the natural number as follows: (ra,n) < (ra′,n′) if n < n′ we refine the rule above with a sensible heuristic to select only minimal extended actions with regard to this strict ordering, that is, we select repair actions that lead to specifications proc. gtvmt 2011 10 / 14 eceasst with a minimal number of inconsistencies. the refinement consists in the addition of one more matching equation in the condition of the rule. this equation computes the set of extended repair actions by means of the function countis and selects the repair actions from the set of minimal extended repair actions through the function selectoptimalras as explained above7. crl [ m | rp ] => [ [ m ] ra | rp ; ra ] if < o , pn > is := getis(m, none) // ras := repairchoices(m, o, pn, noaction) // ra ras2 := selectoptimalras(countis( m, ras, empty ), max, ras) . a variant of this strategy is defined by choosing a repair action from the set of minimal extended repair actions that corresponds to all inconsistencies, thus reducing the amount of choices due to different inconsistencies: crl [ m | rp ] => [ [ m ] ra | rp ; ra ] if < o , pn > is := getis(m, none) // ras := repairallchoices(m, o, pn, noaction) // ra ras2 := selectoptimalras(countis( m, ras, empty ), max, ras) . where repairallchoices is the extension of the function repairchoices to all inconsistencies. repair plan generation. to generate repair plans for a given inconsistent multi-domain specification, we can use maude’s search command in order to explore the search space generated by each one of the aforementioned rules using breadth-first search (bfs). the use of bfs ensures that a repair plan will be found if it exists. as initial state, we use the pair [ m | noevent ], where m is an equationally-defined constant representing the inconsistent specification and noevent represents the empty repair plan. we can use the search command to obtain a pair matching the pattern [m:multimodel|ra:repairplan], where m:multimodel will be assigned to a consistent specification and ra:repairplan will be assigned to the repair action that can be used to obtain the consistent specification in m from m. this can be achieved by using the search option =>! to obtain a canonical form of the pair instantiating [m:multimodel|ra:repairplan] such that the condition getis(m:multimodel, none) == none is satisfied, i.e., no more inconsistencies are left. we can explore one solution through the option [1] as follows: search [1] [ m | noevent ] =>! [ m:multimodel | ra:repairplan ] such that getis(m:multimodel, none) == none . obtaining the first solution: solution 1 (state 8) states: 26 rewrites: 2324 in 18ms cpu (18ms real) (126558 rewrites/second) m:multimodel --> ... ra:repairplan --> set(’15, sm/statemachine/name, "streamer") ; set(’12, sm/transition/name, "connect") ; set(’13, sm/transition/name, "connect") to obtain the next solution we can use the command cont 1 ., or just cont . to resume all remaining solutions. alternatively, we can execute the search command without the option [1] to list all solutions directly. 7 the complete specification of these functions can be found in the appendix. 11 / 14 volume 41 (2011) automated model synchronization: a case study on uml with maude 4 related work in [elf08], the authors provide an scalable mechanism for evaluating choices for fixing inconsistencies in uml design models at runtime. this mechanism draws on the generator functions provided in [egy07] for obtaining repair choices for a given inconsistency. in addition, it filters out those repair choices that create other inconsistencies by checking that the elements to be modified do not violate other inconsistency rules in an incremental way, that is, only inconsistency rules that apply to these model elements are checked. in this approach, valid repair choices are shown to the user who must choose one. hence, only one conflict can be manually resolved at a time resulting in a fine-grained semi-automated resolution approach. an approach for generating complex repair plans for resolving model inconsistencies in an automated way is presented in [smbb10]. this approach is based on an operation-based representation of models [bmmm08] where inconsistency rules are encoded as cause detection rules using prolog as underlying formalism. these rules detect which actions caused inconsistencies instead of identifying which elements are inconsistent. the iterative deepening depth-first search strategy (iddfss) is used to find the best repair plan that leaves the model in a consistent state. some heuristics are used to guide the search by assuming that the last changes in the model are the most likely to be inconsistent. in our approach, we use both a state-based representation of models to find specific inconsistent model elements and a similar operation-based representation for generating repair plans and for checking their validity. this dual view of a model comes at a low computational cost of conversion, since updates are determined by a specific model element. in this way, we can use the state-based view of a model, usually available in mof-compliant modelling repositories, or the operation-based view when the order of actions provided by the user is relevant. we have shown how to use maude’s search bfs algorithm for finding efficient repair plans to obtain consistent models. a key difference with the approach above is that the state-based view of a model corresponds to an equivalence class of event sequences, namely those that lead to the same model up to renaming, hence reducing the number of states that need to be explored in the search space. a more comprehensive comparison with this approach is left for future work due to the current lack of an incremental consistency checker. the approach in [smsj03] uses description logic to detect and resolve the inconsistencies among uml class diagrams, sequence diagrams and state machines that result from the evolution of such models. the underlying formalism allows the authors to dismiss the closed-world assumption to enable the definition of incomplete models; whilst in our work inconsistencies are checked over a closed world, the multi-domain specification, and the lack of inconsistencies is understood as a consistent specification. our assumption seems reasonable in common modelling scenarios and tools, where inconsistencies are checked in multi-domain specifications that may have been developed by different teams but that are available as a whole nonetheless. in [smsj03], strategies for providing repair plans were not studied. graph-transformation theory is a well-established formalism for defining visual languages, allowing for the analysis of consistent model-based specifications. in particular, triple-graph grammars (tggs) [sk08] are used to define consistency relations between graph grammars, so that forward and backward (non-deleting) translators can be automatically generated. to guarantee that generated translators effectively compute synchronisation policies, properties to determine their functional nature were studied in [eehp09, heog10]. an analysis of bidirectional proc. gtvmt 2011 12 / 14 eceasst model transformations based on tggs with respect to information preservation is presented in [eee+07]. a recent approach [lmt11] considers tggs to relate models with different syntax by considering different metamodels and triple graph constraints. maude has been previously used for encoding uml consistency constraints in a qvt relations dialect and for resolving inconsistencies using rewrite rules [lmá09], pursuing the use of mda standards and the development of a case tool. the main aim in our approach has been the design of efficient mechanisms for exploring and resolving inconsistencies using inconsistency constraints, local definitions of repair actions and search strategies. 5 conclusions in this paper, we have presented search strategies for identifying model inconsistencies in heterogeneous mof-specifications and for automating inconsistency resolution using maude, and have illustrated them with a uml case study. in particular, maude’s search command is used to find consistent models using a bfs strategy and two uniform-cost search strategies are used to improve the outcome of the initial strategy. in an extended version of this paper8, the use of maude’s ltl model checker for finding model repair plans and a quantitative evaluation of the different search strategies are also discussed. our technique for analyzing and repairing inconsistencies addresses the following software quality features: maintenance, our technique is generic and can be instantiated with a specific set of metamodels; scalability, the function repairchoices generates a finite set of repair actions by querying the specification, imposing a bound on the branching factor of the search tree for resolving a given inconsistency; usability, the syntactic representation of mof models is isomorphic to the one used in the tool moment2 [bhm09], hence an integration of our technique into emf has already been proved feasible. acknowledgements: we are grateful to anonymous reviewers for their helpful comments. the first author has been supported by the university of leicester. the second author has been supported by nsf grant ccf 09-05584. bibliography [ac07] m. antkiewicz, k. czarnecki. design space of heterogeneous synchronization. in gttse. lncs 5235, pp. 3–46. 2007. [bhm09] a. boronat, r. heckel, j. meseguer. rewriting logic semantics and verification of model transformations. in fase. pp. 18–33. lncs 5503, 2009. [bm06] r. bruni, j. meseguer. semantic foundations for generalized rewrite theories. theor. comput. sci. 360(1-3):386–414, 2006. [bm10] a. boronat, j. meseguer. an algebraic semantics for mof. formal aspects of computing 22:269–296, 2010. 8 http://www.cs.le.ac.uk/∼aboronat/papers/modelsynch11.pdf 13 / 14 volume 41 (2011) http://www.cs.le.ac.uk/~aboronat/papers/modelsynch11.pdf automated model synchronization: a case study on uml with maude [bmmm08] x. blanc, i. mounier, a. mougenot, t. mens. detecting model inconsistency through operation-based model construction. in icse. pp. 511–520. acm, 2008. [bor07] a. boronat. moment: a formal framework for model management. phd thesis, universitat politènica de valència (upv), spain, 2007. [eee+07] h. ehrig, k. ehrig, c. ermel, f. hermann, g. taentzer. information preserving bidirectional model transformations. in fase. pp. 72–86. lncs 4422, 2007. [eehp09] h. ehrig, c. ermel, f. hermann, u. prange. on-the-fly construction, correctness and completeness of model transformations based on triple graph grammars. in models. pp. 241–255. lncs 5795, 2009. [egy07] a. egyed. fixing inconsistencies in uml design models. in icse. pp. 292–301. ieee computer society, 2007. [elf08] a. egyed, e. letier, a. finkelstein. generating and evaluating choices for fixing inconsistencies in uml design models. in ase ’08. pp. 99–108. ieee computer society, 2008. [fgh+94] a. finkelstein, d. gabbay, a. hunter, j. kramer, b. nuseibeh. inconsistency handling in multiperspective specifications. software engineering, ieee transactions on 20(8):569–578, aug. 1994. [heog10] f. hermann, h. ehrig, f. orejas, u. golas. formal analysis of functional behaviour for model transformations based on triple graph grammars. in icgt. lncs, 2010. [lmá09] f. j. lucas, f. molina, j. a. t. álvarez. a systematic review of uml model consistency management. information & software technology 51(12):1631–1645, 2009. [lmt11] y. lamo, f. mantz, g. taentzer. on the relation of meta-modeling and typed graphs. in gt-vmt’11. eceasst, 2011. [mes98] j. meseguer. membership algebra as a logical framework for equational specification. in wadt’97. pp. 18–61. lncs 1376, 1998. [omg06] omg. meta object facility (mof) 2.0 core specification (ptc/06-01-01). 2006. [sk08] a. schürr, f. klar. 15 years of triple graph grammars. in icgt. pp. 411–425. lncs 5214, 2008. [smbb10] m. a. a. da silva, a. mougenot, x. blanc, r. bendraou. towards automated inconsistency handling in design models. in caise. lncs 6051, pp. 348–362. springer, 2010. [smsj03] r. v. d. straeten, t. mens, j. simmonds, v. jonckers. using description logic to maintain consistency between uml models. in uml. lncs 2863, pp. 326–340. springer, 2003. proc. gtvmt 2011 14 / 14 introduction an algebraic approach to encode and manipulate mof models rewriting logic a state-based view of mof models an event-based view of mof models an approach for detecting and resolving model inconsistencies model inconsistency relation inconsistency location choice generator function repair plan selection and generation related work conclusions reachability and reward checking for stochastic timed automatathis work is supported by the eu 7th framework programme under grant agreements 295261 (meals) and 318490 (sensation), the dfg transregional collaborative research centre sfb/tr 14 avacs, the cas/safea international partnership program for creative research teams, the chinese academy of sciences fellowship (grant no. 2013y1gb0006), and the research fund for international young scientists (grant no. 61350110518). electronic communications of the easst volume 70 (2014) proceedings of the 14th international workshop on automated verification of critical systems (avocs 2014) reachability and reward checking for stochastic timed automata e. moritz hahn, arnd hartmanns and holger hermanns 15 pages guest editors: marieke huisman, jaco van de pol managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst reachability and reward checking for stochastic timed automata† e. moritz hahn1, arnd hartmanns2 and holger hermanns2 1 state key laboratory of computer science institute of software, chinese academy of sciences, china 2 saarland university – computer science saarbrücken, germany abstract: stochastic timed automata are an expressive formal model for hard and soft real-time systems. they support choices and delays that can be deterministic, nondeterministic or stochastic. stochastic choices and delays can be based on arbitrary discrete and continuous distributions. in this paper, we present an analysis approach for stochastic timed automata based on abstraction and probabilistic model checking. it delivers upper/lower bounds on maximum/minimum reachability probabilities and expected cumulative reward values. based on theory originally developed for stochastic hybrid systems, it is the first fully automated model checking technique for stochastic timed automata. using an implementation as part of the modest toolset and four varied examples, we show that the approach works in practice and present a detailed evaluation of its applicability, its efficiency, and current limitations. keywords: stochastic timed automata, probabilistic reachability, expected rewards 1 introduction proper consideration of quantitative aspects is crucial to formally model and analyse many complex safety-critical or economically vital systems. key quantities are time, to represent e.g. timeouts and delays, and probabilities, to model the quantified uncertainty that appears, for example, in randomised algorithms, as disturbances like random failures, and as randomised delays. additionally, nondeterminism is a key feature for verification that enables abstraction, concurrency, and the specification of unquantified uncertainty. we need to analyse properties like the probability of (un)desired behaviour, the expected time to success, or the probability of an error within a given amount of time. a suitable model for these kinds of systems are stochastic timed automata (sta). they allow nondeterministic decisions, real time aspects, continuous and discrete probabilistic choices, and any combination thereof. sta had been introduced as the original formal semantics of the high-level compositional modelling language modest [bdhk06]. they are at the heart of a large spectrum of compositional models, summarised in figure 1, rooted in labelled transition † this work is supported by the eu 7th framework programme under grant agreements 295261 (meals) and 318490 (sensation), the dfg transregional collaborative research centre sfb/tr 14 avacs, the cas/safea international partnership program for creative research teams, the chinese academy of sciences fellowship (grant no. 2013y1gb0006), and the research fund for international young scientists (grant no. 61350110518). 1 / 15 volume 70 (2014) reachability and reward checking for stochastic timed automata dtmc mdp ctmc imc pta ma sta sha lts ta + continuous probability + continuous dynamics + real time nondeterminism discrete probabilities exponential delays key: sha stochastic hybrid automata sta stochastic timed automata pta probabilistic timed automata ma markov automata ta timed automata mdp markov decision processes (or probabilistic automata) imc interactive markov chains lts labelled transition systems dtmc discrete-time markov chains ctmc continuous-time markov chains figure 1: stochastic timed automata and related models systems and markov chains. modest has since been extended with support for continuous dynamics [hhhk13] based on the model of stochastic hybrid automata [fhh+11]. the compositionality properties of sta in turn rest on results established by strulo, bravetti and especially d’argenio [bd04, bg02, dk05, hs00]. sta can also be viewed as generalised semi-markov processes (gsmp) extended with discrete and continuous nondeterminism. the modest toolset, which is available at www.modestchecker.net, provides analysis tools for a variety of these models [hh14]. however, so far it did not support the genuine analysis of full sta models with nondeterministic decisions, and that is what this paper is about: we present an algorithm to compute upper/lower bounds on maximum/minimum reachability probabilities and expected cumulative reward values in a given sta. it uses abstraction to convert the sta into a pta, which can then be analysed using existing pta model checking techniques [nps13]. we show the correctness of the abstraction for the considered properties. the underlying theory was originally developed for stochastic hybrid systems [fhh+11, hah13]; we explain how we take advantage of the specialisation to timed systems to improve scalability, usability and applicability. we implemented the new approach in the modest toolset, which allows us to investigate its effectiveness and efficiency using four different example models. related work. kwiatkowska et al. [knss00] have pioneered the foundational basis of sta model checking with their work on timed automata with generally distributed clocks, verified against properties in probabilistic timed ctl. they use a semantics based on the region graph where regions are further partitioned to cater for the stochastic behaviour. the main differences to what we present in this paper are that our approach can handle distributions with unbounded support (e.g. the exponential and normal distributions), supports expected rewards, and that we avoid the region construction. we also show a working implementation, which instead currently uses a digital clocks semantics, but this can be interchanged with other approaches. in case an sta only uses bounded-support distributions (e.g. the continuous uniform one), our approach provides the same error bounds. however, we do not provide error bounds for the general case. other related approaches that we find are based on statistical model checking [dll+11], numerical discretisation [lhk01], discrete event simulation [hs00], or state classes [bbh+13] (on a different model also called sta). however, all of these either implicitly or explicitly exclude proc. avocs 2014 2 / 15 http://www.modestchecker.net/ eceasst the presence of nondeterminism, and thus work in the gsmp realm instead. as an example, consider the “sta” model of [bbjm12] (which is closely related to the one of [bbh+13]): there, a single distribution is sampled on every edge, the result being the exact sojourn time in the following location. in comparison, our model of sta also supports continuous and discrete nondeterminism as well as multiple samplings per edge and multiple sampled variables that can memorise their values over several edges/locations. in particular, the method we present in this paper is geared towards correctly handling the general combination of stochastics and nondeterminism. dedicated approaches for deterministic models provide better precision or performance for that special case. we return to this tradeoff in our evaluation in section 6, where we look at two deterministic models for comparison, and two nondeterministic case studies that can only be handled correctly with our new approach. 2 preliminaries we use r+0 to denote the set of nonnegative real numbers and n + for the positive natural numbers. for a set s, p(s) denotes its powerset. we assume familiarity with general notions and constructions from probability theory. due to space constraints, we do not consider possible measurability issues (see e.g. [hah13, chapter 5] for discussions concerning a more general model). for all probability distributions, we assume an according (borel) space to be given. by prob(ω) we denote the set of all probability measures on the sample space ω. the dirac distribution d(x) ∈ prob(ω) is s.t. we have d(x)(a) = 1 if x ∈ a and d(x)(a) = 0 otherwise. by [∀i : xi 7→ pi] or [x1 7→ p1, . . . , xn 7→ pn] we denote the distribution ∑i pid(xi). given a set var of variables where each variable x has an associated domain (or type) dom(x), we let val denote the set of variable valuations, i.e. of functions var → ⋃ x∈var dom(x) where v ∈ val ⇒ ∀x ∈var : v(x) ∈ dom(x). 0 ∈val assigns zero to every variable. by exp we denote the set of expressions over the variables in var. we write e(v) for the evaluation of expression e in valuation v. we consider three restricted classes of expressions: boolean expressions bxp, arithmetic expressions axp and sampling expressions sxp ) axp that may include probability distributions. the set of assignments is asgn = var × sxp such that 〈x, e〉 ∈ asgn ⇒ ∀v ∈val : e(v) ∈ dom(x). the modification of v ∈val according to u ∈ asgn is written as as [[u]](v). a set of assignments is called an update, and notation for assignments can be lifted to updates. a symbolic probability distribution for a set s is a function f ∈ s → axp that maps elements of s to weights s.t. the support {s ∈ s | f (s) 6= 0} is countable. given a valuation for the variables appearing in these weights, a symbolic distribution can be turned into the concrete probability distribution given by the ratios of individual weights over the sum of all weights in the support. we only consider proper symbolic distributions: those where all weights evaluate to positive numbers and the sum of all weights is finite (i.e. convergent) and nonzero, for all relevant valuations. 3 stochastic timed automata as a generalisation of timed automata, stochastic timed automata deal with time through clock variables (or clocks). clocks take values in r+0 and advance synchronously over time with rate 1. if v ∈ val and t ∈ r+0 , then v + t denotes the valuation where all clocks have been incremented 3 / 15 volume 70 (2014) reachability and reward checking for stochastic timed automata l0, true l1, c ≤ x ∧ ṙ = 1 l2, c ≤ 16 l3, true l4, true true, a 1 2 , {c := 0, x := exp(λ )} 1 2 , {c := 0} c ≥ 8, τ , ∅ c ≥ x, b, ∅ c ≥ 16, τ , {r := r + 16} figure 2: an example stochastic timed automaton by t. clock constraints are expressions in bxp of the form cc ::= b | cc ∧ cc | cc ∨ cc | c ∼ e | c1 − c2 ∼ e where ∼ ∈ {>,≥, <,≤, =, 6=}, c, c1, c2 are clocks and b ∈ bxp, e ∈ axp are clock-free expressions. if all e are of integer type, we have an integer clock constraint. a clock constraint that does not contain the last case (where two clocks are compared) is diagonal-free. if all comparison operators ∼ used in a clock constraint are in {≥,≤, =}, it is closed. definition 1 a stochastic timed automaton (sta) is a 6-tuple 〈loc,var, a, e, linit, inv〉 where loc is a countable set of locations, var ⊇ c is a finite set of variables with a subset of clocks c , a is the automaton’s finite alphabet, e ∈ loc → p(cc × a × wxp) is the edge function, linit ∈ loc is the initial location, and inv ∈ loc → cc is the invariant function. an edge consist of a guard that determines when the edge is enabled, an action label, and a symbolic probability distribution over updates and target locations in wxp = p(asgn) × loc → axp. we also write l g,a−→ w for 〈g, a, w 〉 ∈ e(l). the invariant function maps each location to an expression that allows time to pass as long as it evaluates to true. we can equip sta with rewards, which can be seen as real-valued variables available to external observers only (i.e. they can be used during verification, but not be read in guards etc.). they advance at a certain rate in locations and can be increased when taking an edge: definition 2 a reward r = 〈rewloc, rewe〉 ∈ (loc → axp) × (e → axp) for an sta as above assigns rate rewards to its locations and edge rewards to edges. example 1 the graphical representation of an example sta with reward r is shown in figure 2. locations contain their name, invariant and rate reward (when not zero). edges are shown either as simple arrows labelled with guard, action and update if they lead to a single update/location pair with probability 1, or as split arrows with an intermediate node otherwise. edge rewards are included in updates. the example automaton contains a probabilistic choice on the edge labelled a. out of l2, the edge to l4 can only be taken after a deterministic delay of 16 time units, while the one back to l0 can be taken after any delay nondeterministically chosen out of [8, 16]. after 16 time units, the choice of edge in l2 thus becomes nondeterministic. the delay incurred in l1, on the other hand, is stochastic: x := exp(λ ) assigns to x a value sampled from the exponential distribution with rate λ , thus the delay is exponentially distributed with rate λ . the reward r keeps track of the time spent in l1, and is increased by 16 upon entering l4. proc. avocs 2014 4 / 15 eceasst the semantics of sta is given in terms of timed probabilistic transition systems [bdhk06]: definition 3 a timed probabilistic transition system (tpts for short) is a 4-tuple 〈s, a, t, sinit〉 where s is an (uncountable) set of states, a = r+0 ] a ′ is the system’s (uncountable) alphabet that can be partitioned into delays in r+0 and discrete actions in a ′, t ∈ s → p(a × prob(s)) is the transition function, and sinit ∈ s is the initial state. we also write s a−→ μ for 〈a, μ〉 ∈ t (s). for every delay-labelled transition 〈x, μ〉 ∈ t (s), x ∈ r+0 , we require that ∃s ′ ∈ s : μ = d(s′), 〈x, μ′〉 ∈ t (s) ⇒ μ = μ′ (time determinism), and 〈x + x′, d(s′)〉 ∈ t (s) ⇔ ∃ s′′ ∈ s : 〈x, d(s′′)〉 ∈ t (s) ∧〈x′, d(s′)〉 ∈ t (s′′) for x′ ∈ r+0 (time additivity). definition 4 a reward structure for a tpts is a function rew ∈ t → r+0 assigning a nonnegative reward to each of its transitions. definition 5 the semantics of an sta m = 〈loc,var, a, e, linit, inv〉 is defined as the tpts [[m]] = 〈loc ×val,r+0 ] a, tm,〈linit, 0〉〉 where tm is the smallest function that satisfies l g,a −→e w g(v) 〈l, v〉 a −→tm μ v w (jump) t ∈ r+ ∀t′ ≤ t : (inv(l))(v + t′) 〈l, v〉 t −→tm d(〈l, v + t〉) (delay) where for l′ ∈ loc and measurable v ′ ⊆val we have μ vw (〈l ′,v ′〉) def= ∑l∈loc,u∈p(asgn) π vw (〈u, l〉) ∙ μ v u (v ′) where π vw is the discrete probability distribution for the symbolic distribution w in valuation v and μ vu (v ′) returns the probability of v ′ corresponding to the sampling expressions in update u . the jump inference rule creates action-labelled transitions for the discrete jumps corresponding to taking an edge in the sta. these transitions therefore go from a state into a continuous distribution over target states according to the sampling expressions in the assignments. inference rule delay creates real-labelled transitions that represent the passage of time whenever this is allowed by the invariants. they always lead into dirac distributions, i.e. a single target state. definition 6 the semantics of a reward r for an sta m is a reward structure [[r]] : tm → r + 0 for the tpts semantics [[m]]. for transitions labelled with time actions t ∈ r+0 , it assigns a reward of t times the location reward rate according to rewloc. for a-labelled transitions, the reward value is as defined by rewe for the sta edge inducing the tpts transition. 3.1 reachability probabilities and expected rewards for a given sta, we want to answer questions of the form “what is the probability of reaching a certain set of states from the initial state” and “what is the expected accumulated reward when a certain set of states is reached for the first time”. these properties ask for the computation of reachability probabilities and expected rewards. since sta may be nondeterministic, we quantify over the resolutions of nondeterminism by asking for maximum or minimum values. for a given tpts m = 〈s, a, t, sinit〉, we now define paths and schedulers: definition 7 the set of finite paths is pathsfinm def= s × (a × prob(s) × s)∗. the last state of the finite path β = s0a0 μ0s1a1 μ1 . . . sn is last(β ) def= sn. a scheduler is a function σ ∈ pathsfinm → 5 / 15 volume 70 (2014) reachability and reward checking for stochastic timed automata prob(a × prob(s)) so that for each β ∈ pathsfinm we have σ (β )(a × prob(s) \ t (last(β ))) = 0. a scheduler σ induces the stochastic processes x σm(∙) of the current state of m and y σ m (∙) of the transition chosen by σ in the current state. it is time-divergent if prob(∑∞i=0 f (y σ m (i)) = ∞) = 1 for f (s a−→ μ) = a if a ∈ r+0 and f (s a−→ μ) = 0 otherwise. we denote the set of all time-divergent schedulers of m by sm . a scheduler assigns probabilities to sets of enabled action-distribution pairs depending on the history seen so far. it resolves the nondeterminism in a tpts so as to obtain probability measures, allowing to derive according stochastic processes. the semantics of the two kinds of properties we consider for sta can then be defined on the tpts semantics in the usual way using measurable sets of paths and the cylinder construction. given a set of states b, we are interested in minimal/maximal values, that is infima/suprema over all σ ∈sm . the reachability probability induced by σ is defined as prob(∃i ≥ 0 : x σm(i) ∈ b), i.e. the measure of paths with a state in b. the expected accumulated reward is e(∑ x σm (i)∈b i=0 [[r]](y σ m (i))) if prob(∃i ≥ 0 : x σ m(i) ∈ b) = 1 and ∞ otherwise. it is thus the expected reward accumulated along paths provided b is reached eventually; otherwise the expected value is infinity. as the values of clocks are explicit in tpts, timed properties can be specified by referring to these values directly in the characterisation of b, e.g. referring to an extra clock that is never reset to specify time bounds. example 2 we are interested in the probability of reaching l3 or l4 within at most t time units in the sta of the previous example. the minimum probability is 0 because the invariant of l0 allows us to stay there forever. if t < 8, we can only reach l3 and thus compute the maximum probability using the cdf of the exponential distribution: it is p = 12 ∙(1 − e −λ t ). if t ≥ 16, we can also reach l4 and the result is p + 1 2 . for t ∈ [8, 16), we get p ′ = 12 ∙ (1 − e −λ t ) + 14 ∙ (1 − e −λ (t−8)) by going back to l0 from l2 as soon as possible. observe that p = p ′ for t = 8, but for t = 16, p′ 6= 12 + p: here, the nondeterministic choice available in l2 makes an important difference. now, let us look at the (time-unbounded) minimum and maximum expected reward r when we reach l3 or l4. by definition, since there is a scheduler that reaches those locations with probability less than 1 (by staying in l0 forever), the maximum value is ∞. if λ ≥ 116 , the minimum value that we can achieve is 1λ by always returning to l0 from l2; otherwise, it is 1 2 ∙ (16 + 1 λ ). 3.2 model context sta are related to many other automata models (cf. figure 1). of particular interest for this paper are stochastic hybrid automata (sha) and probabilistic timed automata (pta): the analysis technique we present is based on an existing one for sha, and it involves the transformation of sta into pta that are subsequently model checked using the digital clocks approach for pta. sha [fhh+11] add continuous variables to sta. these can change over time according to differential (in)equations specified by the invariants. in contrast to clocks, they can also appear on the right-hand side of assignments, in particular in sampling expressions. sha thus combine hybrid system behaviour (as in hybrid automata) with stochastic sampling and delays (as in sta). pta are the special case of sta where all clock constraints are integer and no continuous probability distributions are used. all delays and choices are thus based on discrete (usually finite-support) distributions, or nondeterministic. a number of techniques to model check pta proc. avocs 2014 6 / 15 eceasst exist [nps13]. in this paper, we use the digital clocks approach because it supports both reachability probabilities and expected rewards: clocks are replaced by (bounded) integer variables, and self-loop edges are added to increment them synchronously as long as the location invariant is satisfied. this turns the pta into a (finite) markov decision process (mdp) where reachability probabilities and expected rewards can be computed using standard techniques. the results are correct for the original pta whenever all clock constraints are closed and diagonal-free. 4 checking reachability and rewards we use a combination of abstraction and probabilistic model checking to compute bounds on reachability probabilities and expected reward values for sta. this works as follows: first, the continuous distributions that occur in the sta are abstracted by a combination of discrete probabilistic choices and continuous nondeterminism. the result is a pta. the digital clocks approach is used to convert that into a finite mdp. standard techniques like value iteration can now be used to derive maximum/minimum reachability probabilities and expected rewards. the results are upper/lower bounds on the corresponding values in the original sta. this approach is a special case of a technique developed for sha safety verification [fhh+11] and rewardbased analysis [hah13], which was (partly) implemented in the prohver tool [hhhk13]. by specialising for sta, we gain scalability, improve usability by requiring less user input and improving automation, and are able to compute useful lower bounds on minimum probabilities. 4.1 abstracting continuous distributions in the first step, the support of a continuous distribution is divided into a number of intervals and the probability of each interval is computed. the continuous sampling is then replaced by a probabilistic choice over the intervals with the computed probabilities, followed by a nondeterministic choice of which concrete value to pick from the chosen interval. when using prohver, the probabilities for the intervals had to be concrete real values due to the phaver backend used. in our new approach, we can map to pta with probabilities that depend on state variables (but not on clocks or variables that were previously sampled). since pta allow only integer clock constraints, the choice of intervals is limited to those with integer bounds. we always overapproximate continuous distributions with intervals of unit width 1 aligned on integer bounds in the current implementation; all integer time points are anyway enumerated in the resulting mdp’s state space. for distributions with unbounded support, such as the exponential or normal distribution, we generate as many unit width intervals as needed to cover a probability mass of 1 − ρ and then add half-open intervals for the residual of the support. instead of a set of intervals as with prohver, the only parameter of our approach therefore is this residual probability ρ . we use a default of ρ = 0.05 unless stated otherwise. example 3 for the sta of example 1, we show the pta overapproximation for the case that a single unit-width interval is sufficient to cover 1 − ρ probability in figure 3. with ρ = 0.05, this is ensured provided λ ≥ 3. we use ≥∃ and ≤∃ to denote interval comparisons. they are satisfied whenever there exists some value in the interval such that the concrete comparison is satisfied. this amounts to a comparison with the upper bound for ≤∃ and with the lower bound for ≥∃ 7 / 15 volume 70 (2014) reachability and reward checking for stochastic timed automata l0, true la1 , c ≤∃ x ∧ ṙ = 1 lb1 , c ≤∃ x ∧ ṙ = 1 l2, c ≤ 16 l3, true l4, true true, a 1−e−λ 2 , {c := 0, x := [0, 1]} e−λ 2 , {c := 0, x := [1, ∞)} 1 2 , {c := 0} c ≥ 8, τ , ∅ c ≥∃ x, b, ∅ c ≥∃ x, b, ∅ c ≥ 16, τ , {r := r + 16} figure 3: a pta abstraction of the example sta when the interval operand is on the right-hand side. 4.2 correctness we now show that, in the pta that is constructed as described above, the maximum/minimum reachability probabilities and expected reward values are indeed upper/lower bounds for the corresponding values in the original sta. we first define the effect of abstraction more formally: definition 8 consider an sta m = 〈loc,var, a, e, linit, inv〉 and a (potentially infinite) family of sets a = 〈bi〉i∈i . each abstract state bi ⊆ loc ×val subsumes certain concrete states of [[m]], we have ⋃ i bi = loc ×val so that all states are covered. we require that an abstract state only subsume concrete states of the same location. assume binit 3 〈linit, 0〉, and bi, b j with i 6= j disjoint. the abstraction tpts is defined as abs(m, a ) def= 〈a , a ]r+0 , t abs m , binit〉 where t abs m is defined similar to definition 5 with the jump rule being l g,a −→e w 〈l, v〉 ∈ bi g(v) bi a −→t absm [∀ j : b j 7→μ vw (b j)] where μ vw is as in definition 5. we require a to be defined s.t. all induced [∀ j : a j 7→μ v w (a j)] have finite support. timed transitions are defined accordingly. we assign rewards to abstract states according to the rate for its location and the rewards of the edges originating from there. in the context of this paper, a is obtained by splitting the possible values sampling variables can take into unit width or half-open intervals. this construction ensures the finite-support requirement. for instance, for a single sampling variable x, all concrete states where x is sampled to take values between 1 and 2 are subsumed by a single abstract state. for multiple sampling variables, abstract states are built from the cross product of intervals. lemma 1 for an sta m with abstraction set a and some set of states b the maximal (minimal) probability/reward value to reach b in abs(m, a ) is not lower (not higher) than the maximal (minimal) probability/reward value in [[m]]. proof. we only consider disjoint abstract states. non-disjoint ones (from overlapping intervals) would however not affect correctness, yet induce imprecision due to additional transitions in the abstraction. let m = 〈loc,var, a, e, linit, inv〉 and a = 〈bi〉i∈i . we define the intermediate proc. avocs 2014 8 / 15 eceasst abstraction m′ def= 〈loc ×val, a ]r+0 , t ′ m,〈linit, 0〉〉 by replacing jump of definition 5 by l g,a −→e w g(v) 〈s ′ j〉 j∈i s.t. ∀ j ∈ i : s ′ j ∈ b j 〈l, v〉 a −→t ′m [∀ j ∈ i : s ′ j 7→μ v w (b j)] . let f map paths from the intermediate abstraction to the semantics [[m]], so for a path β = s0a0[∀ j : s ′ j 7→μ v w (b j)]s1a1 . . . we have f (β ) def= s0a0 μ v0 w s1a1 . . .. for σ ∈ s[[m]] we construct σ ′ ∈ sm′ . consider path β with last(β ) = 〈l, v〉. w.l.o.g. consider a subset a = {a} × adist ⊆ a × prob(s) of the possible successors when choosing edge e = l g,a−→ w ∈ e with 〈l, v〉 a−→tm μ v w . let 〈si〉i ⊆ a i be the finite set of abstract states for which μ vw (si) > 0. define μi ∈ prob(si) as μi(ai) def= μ vw (ai)/μ v w (si) for measurable ai ⊆ si and denote their product measure by μprod ∈ prob(×i si). define u def= {[∀i : s′i 7→μ vw (si)] | ∀i : s′i ∈ si}, function g([s′1 7→p1, . . . , s ′ n 7→pn]) def= (s′1, . . . , s ′ n), and μ(b) def= μprod(g(b)). then we set σ ′(β )(a) def= μ(adist ∩u )σ ( f (β ))({edge e chosen}). this way σ ′ for m′ simulates the continuous distributions in [[m]] s.t. measures on paths with σ and σ ′ agree [hah13, theorem 4.22]. this implies that reachability probabilities and reward values when using equivalent reward structures agree. because distributions in m′ and abs(m, a ) have finite support, one can define a finite automata simulation relation [sl95] such that 〈l, v〉 � bi if 〈l, v〉 ∈ bi from which one concludes that abs(m, a ) also bounds reachability probabilities of m′. using extensions of simulation relations similar to e.g. [hah13, definition 7.26] one can also bound reward values in this way. 4.3 digital clocks and scaling time we model-check the resulting pta using the existing digital clocks approach [nps13]. let us illustrate this approach on our running example: example 4 the digital clocks mdp for the pta from the previous example is shown in figure 4. the clock-incrementing self-loops are labelled tick. we have excluded the non-stochastic part (locations l2 and l4) and merged the interval-valued variable x into the locations to show the concrete comparisons on the edges of la1 and l b 1 . we have also included the concrete probabilities for λ ≈ 3. the maximum probability of reaching l3 or l4 in this mdp in at most t ∈ n time units is 0.475 for t = 0 and 0.5 for 1 ≤ t ≤ 7. we know from example 2 that the actual probability in the sta is 12 ∙ (1 − e −λ t ) < 0.5. in our case of λ ≈ 3, this is 0 for t = 0, approx. 0.475 for t = 1 and very close to 0.5 for t = 7. the error is thus between 0.475 and almost 0 depending on t. for reward r, the maximum value is ∞ even if we remove the tick-edge from l0: we can stay in lb1 forever due to the right-open interval created for the unbounded exponential distribution. the minimum value computed in this mdp is 0.475 ∙ 0 + 0.025 ∙ 1 = 0.025, whereas the actual value for λ ≈ 3 is ≈ 13 . the example shows that the error introduced by the abstraction of the continuous distributions depends on the variance of the distributions in relation to the interval width of at least 1 required to use pta. in models where the dependence between time and property values is similarly direct as in this example, we can get more accurate results at the cost of larger mdp state spaces by scaling time: both the results of the sampling and the non-interval values that clocks are compared to (including those in properties) are multiplied by some factor d ∈ n+. (for the 9 / 15 volume 70 (2014) reachability and reward checking for stochastic timed automata l0 la1 lb1 l3 true, a 1 2 , . . . 0.475, {c := 0} 0.025, {c := 0} c ≥ 0, b, ∅ c ≥ 1, b, ∅ true, tick, {c := min{c+1, 2}} c ≤ 1 − 1, tick, {c := min{c+1, 2}, r := r+1} c < ∞, tick, {c := min{c+1, 2}, r := r+1} true, tick, {c := min{c+1, 2}} figure 4: digital clocks mdp of the pta abstraction (explicit intervals) exponential distribution, for example, the former can be achieved by dividing the rate by d.) example 5 by scaling time by a factor of d = 2 in our running example sta, two unit width intervals are used for r = 0.05 and λ ≈ 3, with probabilities 0.388 and 0.087. the upper bound for the reachability probability drops to 0.388 for t = 0 and 0.475 for t = 1; the lower bound for the minimum expected reward rises to 0.137. although scaling time can lead to tighter bounds, there is another, independent cause of overapproximation error, which is due to the digital clocks requirement of closed clock constraints: all adjacent intervals have a singleton overlap, and we can only refer to exactly these overlapping values in clock constraints and properties. they have probability 0 in the sta, but not in the pta, which leads to e.g. the upper bounds for time-bounded reachability probabilities being “one step ahead”: in example 5, the upper bound computed for t = 0 is the actual probability for t = 1, the bound for t = 1 is the probability for t = 2, and so on. 5 implementation we have implemented our sta analysis approach in the new mcsta tool within the modest toolset [hh14]. it relies neither on mcpta [hh09] nor on prism for pta model checking. it currently supports the continuous uniform, exponential and normal distributions as follows, where x is a variable of type real and sampling expressions may reference other state variables: – x := uni(lower, upper) for the uniform distribution, where lower resp. upper are expressions of type real for which a concrete lower bound lb resp. a concrete upper bound ub ∈ r can be determined with lb ≤ ub. the intervals are then [blbc,blbc + 1], . . . , [dube − 1,dube] with probability expressions constructed according to cdf uni(x) = (x − lower)/(upper − lower). – x := offset + exp(rate) for the exponential distribution, where offset is an expression of type int and rate is an expression of type real for which a concrete lower bound λ ∈ r+ can be determined. the intervals are then [offset, offset + 1], . . . , [offset + n−1, offset + n] and [offset + n, ∞) where n = d−ln ρλ e (using the quantile function of the exponential distribution). the probability expressions of the intervals are constructed according to cdf exp(x) = 1 − e −rate∙x. – x := norm(m, σ ) for the normal distribution, where the mean m is an expression of type int and the standard deviation σ is a concrete value in r+. the intervals are (−∞, m−n], . . . , [m− 1, m], [m, m + 1], . . . , [m + n, ∞). since neither the quantile function nor the cdf of the normal proc. avocs 2014 10 / 15 eceasst 0 0.2 0.4 0.6 0.8 1 5 20 40 60 80 100 120 probability time bound probability actual ρ = 0 .10 ρ = 0 .0 5 = 0.10ρ 2 m 4 m 6 m 8 m 10 m 5 20 40 60 80 100 120 states time bound ρ = 0.1 0 ρ = 0. 05 0 m figure 5: reachability results and state space sizes for the m/g/1 example distribution have a closed-form solution, we require σ to be a concrete value to precompute n and the actual interval probabilities based on σ and ρ close to double precision. these examples show a general recipe to support other continuous distributions using their quantile function and cdf. in case a distribution is parameterised by an expression that contains state variables, we may generate more intervals than necessary for some valuations, which then have zero probability. for example, we generate two intervals for x := uni(0, 2i) when i has domain {0, 1} since the upper bound of expression 2i is 2. however, since the probabilities are preserved as expressions, the probability of [1, 2] will evaluate to 0 for all states where i 6= 2. 6 evaluation we have applied mcsta to four different examples. we are interested in how close the computed bounds are to the actual values (effectiveness), and how large the state spaces of the underlying mdp become1 (efficiency). all measurements were performed on the same 1.7 ghz intel core i5-3317u system with 4 gb of ram running 64-bit windows 8.1. the first two models we present are deterministic. as mentioned, our method is not targeted for this special case, so we expect correct and useful, but not very tight, computed bounds. specialised methods will perform better or be more precise in these cases. the last two models, however, contain continuous and discrete nondeterminism, so our technique is currently the only one available for verification. 6.1 m/g/1 queueing system with normal distribution our first example models an m/g/1/6 queueing system as sta where the service time is normally distributed with mean 10 and standard deviation 2. since clocks cannot be negative, it is implicitly truncated to values ≥ 0 when we compare the result to a clock. the time between customer arrivals is exponentially distributed with rate 16 . the queue has length 5, not counting the customer being served, and is initially empty. we are interested in the following values: – the probability p that the queue is full and ≤ tp time units have elapsed, – the expected time t until the queue is full for the first time, and – the expected number c of customers served before the queue becomes full. since nondeterminism is absent by construction, we can use statistical model checking with the modes simulator from the modest toolset to obtain good approximations of p, t and c. 1 memory was the limiting factor in all examples; runtime was always below 3 minutes. 11 / 15 volume 70 (2014) reachability and reward checking for stochastic timed automata 0 0.2 0.4 0.6 0.8 1 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 probability (first queue full) time boundprobability actual ρ = 0. 10 , tim e × 20 ρ = 0.05, time × 10 ρ = 0.10, time × 10 0 0.2 0.4 0.6 0.8 1 1 2 3 4 5 6 7 8 9 10 probability (all queues full, time bound 2) × time scale actual probability ρ = 0.05 ρ = 0.10 ρ = 0.20 figure 6: reachability results and time scale effects for the tandem queues the results of computing upper and lower bounds on p using mcsta are shown in figure 5. on the left, we show the computed bounds for different values of tp as black triangles. we see that there is a noticeable approximation error, but the general evolution of the probability over time is preserved. after tp ≈ 80, the lower bound shows no significant improvements. for tp ≥ 90, we ran out of memory, so we increased the residual probability parameter ρ to 0.1. the number of concrete states in the mdp of the digital clocks semantics is shown on the right of figure 5. we see that it increases linearly with tp and can be reduced significantly by increasing ρ , i.e. by lowering the number of intervals for the abstraction of the exponential and normal distributions. asking for minimum expected rewards, we compute bounds t ≥ 43.4 and c ≥ 3.52 for the other two values. as we do not need a global clock to check a time bound like tp here, the underlying mdp has just 136 767 states. state-space exploration and computation of both bounds takes only 2.3 s in total. if we ask for maximum expected rewards, we get bounds ∞ due to the right-open intervals created by the abstraction of the unbounded distributions (cf. example 4). simulation with modes tells us that t ≈ 61 and c ≈ 6.2 for this deterministic model. 6.2 tandem queueing network we next look at a model from the prism benchmark suite [knp12]: the tandem queuing network of an m/cox2/1/4 followed by an m/m/1/4 queue [hms99]. it is a ctmc and we can thus model it as an sta without nondeterminism. we experiment with scaling time as described in section 4.3. we compute the maximum probability pff of the first queue being full in time t, trying to use a value of ρ ≥ 0.05 as low as possible and a time scaling factor as high as possible without running out of memory. the result is shown on the left of figure 6. the second property we look at is the maximum probability paf of both queues becoming full within time t. this happens at a vastly different time scale: paf only starts to approach 0.5 when t is on the order of 50. we thus focus on the effect of scaling time on the approximation error for fixed time bound t = 2. the results are shown on the right of figure 6. we see that the error can be significantly reduced by scaling up time. finally, we compute bounds on the expected times tff until the first queue becomes full and taf until both are full. as we increase the time scaling, we go from lower bounds tff ≥ 0.000012 and taf ≥ 0.56 for time scale d = 1 with 9 557 mdp states, computed in 0.1 s, to tff ≥ 0.108710 and taf ≥ 5.87 for d = 10 with 3 662 958 states, computed in 108 s. again, upper bounds (i.e. maximum expected rewards) are all ∞. from simulation, we get tff ≈ 0.29 and taf ≈ 17.9. proc. avocs 2014 12 / 15 eceasst table 1: results and comparison for the wlan example model type pmax [e ∧ min, e ∧ max] [e ∨ min, e ∨ max] [e 1 min, e 1 max] states time wlan pta 0.18359 [1325, 6280] μs [450, 4206] μs [450, 5586] μs 104 804 8 s wlan-uni sta 0.13659 [2325, 4607] μs [950, 3018] μs [950, 3880] μs 264 240 15 s 6.3 wireless lan with uniform transmission time departing from queueing systems, we now look at the model of a communication protocol: the carrier-sense multiple-access with collision avoidance (csma/ca) part of ieee 802.11 wlan. we take the modest pta model [hh09] and replace the nondeterministic choice of transmission delay out of [200, 1250] μs (with a unit of time representing 50 μs) by a uniformly distributed choice over the same interval. the result is still nondeterministic, and an sta instead of a pta. model-checking results for the original pta (“wlan”) and the new sta (“wlan-uni”) are shown in table 1. we see that the state space of the underlying mdp is larger when the uniform distribution is used. this is because the states not only contain explicit values for all clocks as in the original pta, but additionally 21 different concrete intervals that overapproximate the result of sampling from uni(4, 25). the blowup thus stays far below the worst-case factor of 21. we analyse six time-unbounded properties: pmax, the maximum probability that either of the two modelled senders’ backoff counters reaches the upper bound of 2, as well as e∧min/e ∧ max, e∨min/e ∨ max and e 1 min/e 1 max, the minimum/maximum expected times until both senders, either of them, or the one with id 1 correctly deliver their packets. due to the nondeterminism, we cannot use simulation or any other technology to compute the actual values. however, the computed bounds are plausible if we assume that in the pta, the longest/shortest transmission delay maximises/minimises the values. the sta is thus indeed expected to show less extremal behaviour. 6.4 file server as a final example, we analyse another model that combines all essential features of sta and cannot be model checked with any other approach we know of (except prohver). it represents a single-threaded file server with slow archival storage: – requests arrive to a single queue of length c = 5 with interarrival times following exp( 18 ). – file sizes are uniformly distributed over some range such that sending the file back to a client takes time uniformly distributed over [1, 3]. – 2 % of all files are in slow archival storage. retrieving a file is instantaneous for normal storage, but takes between 30 and 40 time units nondeterministically for archival storage. we thus have continuous stochastic delays, a probabilistic choice and nondeterministic delays. additionally, we model the initial queue length as uniformly distributed in {0, . . . ,bc2 c}. the model is part of the modest toolset download. we are interested in the probability p that the request queue becomes full within time tp, and the minimum (i.e. worst-case) expected time t until this happens. for t, we obtain a lower bound of 462 time units from an mdp with 107 742 states in 6 s. for p, the results are shown in figure 7. on the right, we see that the number of mdp states again grows linearly with the time bound. 13 / 15 volume 70 (2014) reachability and reward checking for stochastic timed automata probability time bound ρ = 0.0 75 ρ = 0.0 5 alap asap 0 0.1 0.2 0.3 0 50 100 150 200 0 m 2 m 4 m 6 m 8 m 10 m 12 m 14 m 0 50 100 150 200 states time bound ρ = 0. 05 ρ = 0.0 75 figure 7: model checking results and state space sizes for the file server example on the left, we have plotted the computed upper/lower bounds using small triangles. due to the nondeterministic delay, we cannot use simulation. however, we can instruct modes to resolve that delay by scheduling events either as soon or as late as possible (asap/alap). simulating these deterministic variants of the model gives us t ≈ 1012 for asap and t ≈ 721 for alap. for p, the simulation results are included on the right of figure 7. the results that we get via our new approach are clearly useful: they are safe bounds whereas we do not know anything about the relationship between simulation results and the actual values. 7 conclusion we presented the first fully-automated model checking approach for sta with general, unbounded distributions and support for nondeterminism. it provides upper bounds for maximum and lower bounds for minimum reachability probabilities and expected rewards. we investigated causes of approximation error and showed that scaling time can effectively reduce the error. in experiments performed with our implementation, mcsta, we saw that the approach works well in practice, but state-space explosion is a significant problem for time-bounded properties. references [bbh+13] p. ballarini, n. bertrand, a. horváth, m. paolieri, e. vicario. transient analysis of networks of stochastic timed automata using stochastic state classes. in qest. lncs 8054, pp. 355–371. springer, 2013. [bbjm12] p. bouyer, t. brihaye, m. jurdzinski, q. menet. almost-sure model-checking of reactive timed automata. in qest. pp. 138–147. ieee computer society, 2012. [bd04] m. bravetti, p. r. d’argenio. tutte le algebre insieme: concepts, discussions and relations of stochastic process algebras with general distributions. in validation of stochastic systems. lncs 2925, pp. 44–88. springer, 2004. [bdhk06] h. c. bohnenkamp, p. r. d’argenio, h. hermanns, j.-p. katoen. modest: a compositional modeling formalism for hard and softly timed systems. ieee trans. software eng. 32(10):812–830, 2006. proc. avocs 2014 14 / 15 eceasst [bg02] m. bravetti, r. gorrieri. the theory of interactive generalized semi-markov processes. theor. comput. sci. 282(1):5–32, 2002. [dk05] p. r. d’argenio, j.-p. katoen. a theory of stochastic systems part i: stochastic automata. inf. comput. 203(1):1–38, 2005. [dll+11] a. david, k. g. larsen, a. legay, m. mikucionis, z. wang. time for statistical model checking of real-time systems. in cav. lncs 6806, pp. 349–355. springer, 2011. [fhh+11] m. fränzle, e. m. hahn, h. hermanns, n. wolovick, l. zhang. measurability and safety verification for stochastic hybrid systems. in hscc. pp. 43–52. acm, 2011. [hah13] e. m. hahn. model checking stochastic hybrid systems. phd thesis, universität des saarlandes, 2013. [hh09] a. hartmanns, h. hermanns. a modest approach to checking probabilistic timed automata. in qest. pp. 187–196. ieee computer society, 2009. [hh14] a. hartmanns, h. hermanns. the modest toolset: an integrated environment for quantitative modelling and verification. in tacas. lncs 8413, pp. 593–598. springer, 2014. [hhhk13] e. m. hahn, a. hartmanns, h. hermanns, j.-p. katoen. a compositional modelling and analysis framework for stochastic hybrid systems. formal methods in system design 43(2):191–232, 2013. [hms99] h. hermanns, j. meyer-kayser, m. siegle. multi terminal binary decision diagrams to represent and analyse continuous time markov chains. in nsmc. pp. 188–207. prensas universitarias de zaragoza, 1999. [hs00] p. g. harrison, b. strulo. spades a process algebra for discrete event simulation. j. log. comput. 10(1):3–42, 2000. [knp12] m. z. kwiatkowska, g. norman, d. parker. the prism benchmark suite. in qest. pp. 203–204. ieee computer society, 2012. [knss00] m. z. kwiatkowska, g. norman, r. segala, j. sproston. verifying quantitative properties of continuous probabilistic timed automata. in concur. lncs 1877, pp. 123–137. springer, 2000. [lhk01] g. g. i. lópez, h. hermanns, j.-p. katoen. beyond memoryless distributions: model checking semi-markov chains. in papm-probmiv. lncs 2165, pp. 57– 70. springer, 2001. [nps13] g. norman, d. parker, j. sproston. model checking for probabilistic timed automata. formal methods in system design 43(2):164–190, 2013. [sl95] r. segala, n. a. lynch. probabilistic simulations for probabilistic processes. nord. j. comput. 2(2):250–273, 1995. 15 / 15 volume 70 (2014) introduction preliminaries stochastic timed automata reachability probabilities and expected rewards model context checking reachability and rewards abstracting continuous distributions correctness digital clocks and scaling time implementation evaluation m/g/1 queueing system with normal distribution tandem queueing network wireless lan with uniform transmission time file server conclusion towards 11smv model checking of 11signal (multi-clocked) specifications electronic communications of the easst volume 23 (2009) proceedings of the ninth international workshop on automated verification of critical systems (avocs 2009) towards smv model checking of signal (multi-clocked) specifications julio c. peralta and thierry gautier 15 pages guest editor: markus roggenbach managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst towards smv model checking of signal (multi-clocked) specifications julio c. peralta and thierry gautier irisa-inria, centre rennes-bretagne atlantique, 35042 rennes cedex, france julio.peralta@inria.fr thierry.gautier@inria.fr abstract: signal is a high-level data-flow specification language that equally allows multi-clocked descriptions as well as single-clocked ones. it has a formal semantics and is supported by several formal tools for simulation and static validation. this generality renders it useful for various specification, simulation, and verification tasks in embedded system design. smv, in turn, is a language and model checker where synchronous models are single-clocked by definition. roughly, we use standard techniques to describe clocks by boolean variables, with the advantage that the number of such variables is kept to a minimum through a static analysis provided by the signal compiler. in particular, we propose a translation from possibly multi-clocked signal specifications into smv specifications for their corresponding verification by model checking. keywords: synchronous programs, multiple-clocks, smv, model checking 1 introduction the increasing complexity of embedded systems and the costs associated with failures in their engineering and operation demand for models and tools that enable safe design and formal validation. in the past years, system design based on the synchronous model [bb91] has attracted the attention of many academic and industrial actors. this paradigm consists in abstracting the nonfunctional implementation details of a system, thus fostering a focused reasoning on the logic behind the instants at which the system functionalities should be secured. a benefit of designing with languages based on the synchronous model (e.g. esterel [bg92], lustre [hcrp91], or signal [ltl03]) is the availability of associated verification tools. among synchronous languages, a salient feature of signal is the notion of polychrony: the capability to describe systems in which components may have different clock rates. this expressivity coupled with its (compiler) ability to statically synthesize schedules (reasoning about the logic behind the source clock constraints) allows to embrace complex systems that arise in the form of gals (globally-asynchronous locally-synchronous) or (loosely) time-triggered architectures, and thus renders the model checking of such specifications highly attractive. smv, in turn, is a language and model checker where synchronous models are single-clocked by definition. however, this apparent constraint does not prevent us from describing and verifying signal multi-clocked specifications as we demonstrate here. in order to describe multiclocked computations using a single-clocked framework we use standard techniques to describe clocks by boolean variables [bbg+00], with the advantage that the number of such variables is 1 / 15 volume 23 (2009) mailto:julio.peralta@inria.fr mailto:thierry.gautier@inria.fr model checking signal kept to a minimum through a static analysis provided by the signal compiler. such analysis produces a hierarchy of clocks (ordered by set inclusion) which is useful to avoid proliferation of smv state variables. the paper presents in section 2 syntactic and semantic highlights of our source signal programs and the target smv programs. section 3, in turn, describes a generic smv translation for each signal kernel operator. then in section 4 we provide examples of translations for (possibly multi-clocked) signal specifications and show the use of the signal compiler analysis to reduce the number of smv state variables. the behaviours of the translated examples will be examined in section 5 by model checking with smv itself. next, in section 6 some elements for comparison with related work on model checking for other synchronous languages are presented. finally, some concluding remarks and pointers for future work are given in section 7. 2 signal and smv: syntax and semantics in this section we introduce the signal kernel language and a subset of the smv language used for our translation, as well as highlights of each language semantics. 2.1 signal kernel signal is a data-flow relational language that relies on the polychronous model [ltl03, bgl08]. it handles possibly infinite sequences of typed values called signals. a signal x is implicitly indexed by discrete time, thus denoting the sequence xt where t ∈ h, h ⊆ n. at any instant (arbitrary t ∈ n) a signal may be present, at which point it holds a value, or absent. there is no actual value associated with a signal when it is absent, by contrast with the instants when it is present. the instants of absence of a signal are denoted with the special symbol ⊥, in the semantics. signals may be of standard types, e.g. boolean, integer, real, etc. additionally, there is a particular type of signal called event. a signal of this type is always true when it is present. the set of instants (index set h above) where a signal x is present represents its clock, noted x̂ (which implicitly denotes a signal of event type). a process is a system of equations (also called elementary processes) over signals that specifies relations between values and clocks of the signals. a program is a process. signal relies on a few primitive constructs that define elementary processes from which bigger processes may be built. next the definition of four elementary processes and two other constructs to build bigger processes, and to mask signals, respectively. • function. y:= f(x1,...,xn) def ≡ x1t 6= ⊥ ⇔ ... ⇔ xnt 6= ⊥ ⇔ yt = f (x1t , ..., xnt ) • delay. y:= x $ 1 init c def ≡ xt 6= ⊥ ⇔ yt 6= ⊥ ⇔ [(t > 0 ∧ yt = xk ∧ k = max{t ′ | t′ < t ∧ xt′ 6= ⊥}) ∨ (t = 0 ∧ yt = c)]; (c is a compile time constant). • undersampling. y:= x when b (where b is boolean) def ≡ yt = xt if bt = true, else yt = ⊥; (observe that expression y:= when b is equivalent to y:= b when b). • deterministic merge. z:= x default y def ≡ zt = xt if xt 6= ⊥, else zt = yt . proc. avocs 2009 2 / 15 eceasst table 1: clock relations for primitives. construct clock relations y := f(x1,...,xn) ŷ = x̂1 = ... = x̂n y := x $1 init c ŷ = x̂ y := x when b ŷ = x̂ ∩ [b], [b] ∪ [¬b] = b̂ and [b] ∩ [¬b] = /0 z := x default y ẑ = x̂ ∪ ŷ • parallel composition. p1|p2 def ≡ union of equations of p1 and p2. • hiding. p where x def ≡ x is local to the process p. derived operators are defined using the primitive operators above. for instance, a synchronization equation x ˆ= y specifies that x and y have the same clock. moreover, the equation x ˆ= y ˆ+ z asserts that the clock of x is the union of the clocks of y and that of z. a memory: y := x cell b init y0 allows to memorize in y the latest value carried by x when x is present or when b is true. processes can be abstracted and declared, in a standard way, by explicitly designating their input and output signals (preceding their declarations with “?” and “!”, respectively), with the sole constraint that the designated input signals cannot be defined (i.e. occur in the lhs of a := symbol) inside such a process. 2.2 static analysis of signal specifications in order to assess the consistency of the clock relations associated with a program, and to organize the control of such a program, the compiler synthesizes a clock hierarchy [abl95, bgl08]. a clock k1 is said to be greater than a clock k2 if k2 is included in k1 in terms of sets of instants. table 1 shows the clock relations implicit in each primitive construct of signal. for the undersampling construct, the clock of the boolean signal b is partitioned into [b] and [¬b]. the sub-clock [b] (resp. [¬b]) denotes the set of instants where the boolean expression b is present and true (resp. false). clock relations are automatically added and (possibly) new relations between clocks are inferred by the compiler from any program to be analyzed. for a program p = p1|...|pn, its resulting relations between clocks are the result of applying the clock calculus on the conjunction of the clock relations associated with the sub-processes pk, k ∈ 1..n. the clock calculus [abl94], in turn, seeks the greatest clock in the program, called master clock, from which all other clocks in the program can be extracted. in this case, the clock hierarchy is a tree. nonetheless, in some programs, such a unique master clock may not exist. in this latter case, there are several local master clocks and the clock hierarchy is a forest. note, however, that the root of a tree may not correspond with the clock of an input signal. a program in which the clock hierarchy is a tree is endochronous. such a program can be run in an autonomous way (its master clock plays the role of an activation clock). otherwise, the program needs extra information from its environment to be run in a deterministic way. the automatic code generation, for an endochronous program, relies on the synthesized clock 3 / 15 volume 23 (2009) model checking signal smvpgr → modulemain | modulestmt smvpgr modulestmt → module id[(idlist)] var vardcllst assign assignstmt invar invarstmt vardcllst → ε | id : type ; vardcllst assignstmt → ε | lhs := rhs ; assignstmt invarstmt → ε | s bool exp lhs → init(id) | id | next(id) rhs → cnst exp | set exp | case exp case exp → case cases esac ; cases → 1 : rhs ; | bool exp : rhs ; cases figure 1: subset of smv language. hierarchy. each clock is represented by a boolean variable (booleanization stage [bbg+00]) which is true when the clock is present, and false otherwise. for every signal, its value is meaningful (under a multi-clock interpretation) when the boolean representing its clock has the value true. this allows to organize the control of the application following the clock hierarchy. 2.3 smv: a subset for our translation purposes we use only a subset of the smv language. we present such a subset using the syntax of smv that is compatible with the three versions [mcm01, mcm99, ccj+05] of the language currently available on the web (smv from cadence, smv from carnegie-mellon university, and nusmv). we identify the following syntax with the oldest [mcm01] of the three versions. syntax our smv programs will consist of modules with parameters, except for the reserved module main. module declarations may not be nested. each module has a name, (possibly) a list of parameter names, and at most three sections: a section for variable declarations and/or module instantiation, marked at the beginning by the var reserved word; a section describing the variable values (initial, current or next instant), initiated by the assign keyword; and, a section describing invariants between the variables of the referred module, and whose beginning is marked by the reserved word invar. define, fairness and spec sections are not considered for the moment, but their use will be motivated when we present translation examples (sect. 4), and some verification (sect. 5) on them. figure 1 depicts the grammar of our subset of smv. the possible type (type) of an identifier (id) is integer (or intervals thereof), boolean, enumerated, or the name of another module; in this last case the identifier is used to refer to an instance of the referred module, and appropriate expressions should be given as parameters for the intended instance. access to members of a module instance is through a dot notation (i.e. id.var id). an expression of an invariant is of type boolean and may only contain module variables in its present form (i.e. no use of init or next operators are allowed). the right-hand-side of an assignment (rhs), for the case of a constant expression (cnst exp), is a valid expression (e.g. containing arithmetic, boolean or comparison operators) using any of the possible type values for a correct typing of the identifier in the left-hand-side; a right-hand-side, for the case of a set expression (set exp), uses curly braces to extensively list the elements (separated by commas) of the desired set. operations on sets are union and test of membership. proc. avocs 2009 4 / 15 eceasst var f, h x, h y: boolean; assign init(y) := c; next(y) := case f & next(h x) : x; 1 : y; esac; init(f) := h x; next(f) := f | next(h x); invar (h y <-> h x) (a) y := x$1 init c in smv var h x, h y, h b: boolean; assign init(y) := x; next(y) := case next(h y) : next(x); 1 : y; esac; invar (h y <-> (h x & h b & b)) (b) y := x when b in smv figure 2: function and undersampling operators in smv semantics assignments for the first value (signaled by the use of init keyword on the lhs) of a program variable are only executed in the first instant of program execution, whereas assignments for the next instant are executed to obtain the value of the designated variable starting from the second instant. assignments with no occurrences of init or next in their lhs are executed at all instants. the order in which assignments are executed is given by the data dependencies existing between the variables occurring in the right-hand-sides of the assignments to execute (among all assignments of a program including those added by process instantiation). the rule that dictates the (partial) order of assignment execution says that a variable is first assigned before its value is used in a right-hand-side evaluation. invariants define (possibly) extra relations/constraints to those already imposed by the assignments, thus limiting the valid executions of the source program to those where the invariant expressions hold. 3 from signal to smv let us now describe a possible translation from simple equations in the signal kernel, to smv module fragments. we will assume, for simplicity of exposition, that there is only one kernel operator per equation. also, the translation for each such signal source equation is an smv program fragment where variable declarations will be omitted (whenever possible) to allow for a greater translation generality, provided that their translation depends on whether they are input, output or local in the presence of multiple signal processes. roughly, the translation has an smv variable to carry the value of each source signal, as well as a boolean smv variable to denote its clock. an instant of an smv execution corresponds to an instant of signal execution. the multi-clock reading of an smv generated program comes from reading pairs of smv variables: one denoting its clock and another carrying its value (if any). delay see smv translation in figure 2(a). variables h x, h y, and f were added by the translation. the first two represent the clock of x and y respectively, while the last variable is 5 / 15 volume 23 (2009) model checking signal var h x, h y, h z: boolean; assign init(z) := case h x: x; 1: y; esac; next(z) := case next(h x): next(x); next(h y): next(y); 1: z; esac; invar (h z <-> (h x | h y)) (a) z := x default y in smv var h x, h y, h z: boolean; assign init(z) := f(x,y); next(z) := case next(h z): next(f(x,y)); 1: z; esac; invar (h z <-> h x) & (h x <-> h y) (b) z := f(x,y) in smv figure 3: merge and function operators used to detect the first instant of signal x. the guard labeled with 1 in the case statement is the default choice if none of the offered options holds. it is important to note here that the previous value of x should be kept (in its smv definition, not shown here) in case it is absent (typically the default case in a next assignment) since this signal operator will refer to the previous value in signal semantics, which is not necessarily that of smv. also, note here that the value of y is kept in case its first instant does not coincide with that of smv. variable f is needed to detect the first instant of y (or x since they are synchronous). for the signal kernel operators that follow we decided to keep the previous value of the defined variable, considering a general schema of translation, but in some particular occurrences of such operators we may not need to keep the value. the use of assignments that keep the value by default, allows for stuttering steps in our translation: a fundamental property if compositionality is desired. undersampling the smv translation is depicted in figure 2(b). here we (potentially) need three clocks, one for each signal. the init definition fixes the value to that of x disregarding clock h y. this is correct, however, because if h y holds in the first instant then the value is correct, and if it doesn’t then the value is not important, thus any value is valid in this last case. merge figure 3(a) depicts the translation into smv. here, as above, we have three (clock) smv variables. once again, the initial assignment definition for the default case (labeled with 1) appears arbitrary; it is justified, however, with a similar reasoning as that used for the undersampling operator above. function refer to figure 3(b) for the smv translation. the reason for the initial instant assignment is similar to that used for the when operator above. whether the output is present or not, the chosen value will be good. proc. avocs 2009 6 / 15 eceasst 3.1 improving the translation into smv so far we have proposed an intuitively correct translation from signal elementary processes into smv modules. we anticipate/conjecture that this translation is correct given the straightforward coding style of data-flow and clock constraints into smv assign statements and invariants. nonetheless, scalability is another desirable feature. to this aim we would like to reduce the number of smv (state) variables introduced by our translation, since the number of such variables may (sometimes) render the state space exponentially bigger. the natural candidates for elimination are the clock variables, and perhaps also the smv variables corresponding to signal source variables. in order to avoid state variables in the translation the reader should know that smv allows to define a variable as a function of other variables without the use of next or init operators. that is, such assignments may only refer to the present values of other smv variables. in order to identify such variable definitions smv provides a section named define. roughly, uses of the variables so defined are replaced by their definition thus sparing some state variables. at first sight, we may think that there is no need to introduce state variables for signals defined through operator when, or default, or function, since they all refer to values in the same instant. it would be tempting to replace them by their equivalent in the define section, and thus their values would be arbitrary when absent. however, this replacement would be incorrect when the values they define are referenced through a signal delay operator. recall that the clock of a signal variable coincides with the instants of the associated smv boolean variable when it has value true, which is not necessarily the previous smv instant. consequently, for those signal elementary processes using kernel operator when, default, or function that do not define a value used in a delay operator, one may replace the smv translation proposed above by one referring to present values in the corresponding define section. for the smv (clock) variables introduced we propose to have one state smv variable per tree root in the forest constructed (during clock calculus) by the signal compiler. the remaining smv (clock) variables will be assigned in the define section. it is important to note here a shift in the translation. so far we translated clock relations as boolean formulas in the invar section by pure constraint reasoning. replacing such constraints with assignments (in the define section) renders the constraints functional. in summary, smv variables that represent source signal clocks and are associated with an internal node in one of the trees found by the signal compiler may be translated using assignments in the corresponding smv define section. in addition, the number of clock variables may be reduced by using one variable per synchronous equivalence class found by the compiler, as well as by elimination of those clocks (variables) found to be empty. 4 translation examples in the following we will provide examples of source signal specifications and their translation into smv. such signal examples will make part of a bigger specification describing a communication protocol for loosely time-triggered architectures [bcl+02]. 7 / 15 volume 23 (2009) model checking signal 4.1 a one-place fifo consider a one-place fifo in signal, fifo 1 in figure 4(a). its content is the last value written into it. the output (signal sx) may only be read/retrieved after at least one instant that it was entered. the number of instants between a write and a read may increase non-deterministically. each such instant is given by the (internal) clock of the local boolean signal b (interleave process). before translating into smv we will give the fifo 1 program to the signal compiler so that the hierarchy of clocks becomes evident as well as other optimisations applied by the compiler. for this program the compiler produces the signal program depicted in figure 4(b). the hierarchy of clocks is made visually evident by the nesting of parallel1 subprocesses (the only subprocess in this example comprises lines 5-13). the root of the only tree is that of the clock defined at the top, line 3. this line also indicates that the clock h b is not fixed, but a free variable which could have any value at any instant. line 4 gives the set of signals that share the same clock (h b). lines 6,8 indicate what is the name of the clock of signals x,sx, respectively, whereas lines 5,7 give their definitions. finally, lines 9-11 provide the definition of the fifo 1 output sx (through the use of the value of an intermediate variable tmp). now the translation of the compiled fifo 1 program into smv is in figure 5. translation of the negated delay spans lines 13-20; translation of the cell operator lays between lines 5-12; and, the when operator is translated into line 24 (if the type of tmp was not boolean then a case statement would have been used). there is a clear depart from the translation schemes presented in section 3. this stems from several improvements in the translation (already suggested at the end of section 3), and with some conventions in the compiler program generation, figure 4(b). a first convention exploited in our translation says that all uses of when operator have as first operand a synchronous expression (i.e. all its signals share the same clock) and second operand a signal denoting a clock smaller or equal to that of the first operand. as a result, our translation into smv (figure 2(b)) need not test the clock (h x) of the first operand together with the clock (h b) and value (b) of the second operand; it suffices to guard the use of the first operand value by the clock given as second operand (i.e. expression h y <-> h x & h b & b becomes h y <-> h b & b). the next convention states that occurrences of the default operator have the standard form x:= (a when h f) default (b when h g) (with possibly more default and their corresponding operators) where h f,h g are clocks and a,b are synchronous expressions. note here that clock signal h g should be defined (implicitly or explicitly) as the difference between the clocks of x and h f. our translation of this operator (figure 3(a)) won’t have to translate the when operator occurrences in such equations, they serve to identify the clock guard for each case branch of the default operator. finally, to discuss the cell operator recall that, in general, an equation x := y cell z init c is equivalent to the two equations x := y default (x$1 init c) | x =̂ y +̂ when z. uses of such cell operator have as second operand the clock of the defined signal. that is, z above will be a signal denoting the clock of x, and y is either a synchronous expression or a when operator. an explanation of the simplification in the translation (lines 13-20, figure 5) of the negated delay (line 12, figure 4(b)) is in order. because the definition of bw is quasi-circular (through a function operator and a one instant delay) we do not need the extra f variable to detect the first 1 the signal parallel composition operator is commutative and associative. proc. avocs 2009 8 / 15 eceasst process fifo 1 = (? boolean x; ! boolean sx;) (| sx := current 1(x,̂sx) | interleave(x,sx) |) where process current 1 = (? boolean wx; event c; ! boolean rx;) (| rx := (wx cell c init false) when c |); process interleave = (? boolean x, sx; !) (| x =̂ when b | sx =̂ when (not b) | b := not(b$1 init false) |) where boolean b; end; end; (a) one-place fifo in signal 1: process fifo 1 = (? boolean x; 2: ! boolean sx;) 3: (| h b := ˆ h b 4: | h b =̂ tmp =̂ b 5: | (| h x := when b 6: | h x =̂ x 7: | h sx := when (not b) 8: | h sx =̂ sx 9: | sx := tmp when h sx 10: | tmp := (x when h x) cell 11: h b init false 12: | b := not (b$1 init false) 13: |) 14: |) where event h b, h sx, h x; 15: boolean tmp, b; end; 16: end; (b) fifo 1 after clock calculus figure 4: fifo 1 source: before and after applying clock calculus instant, neither do we need an extra state variable (the x variable in figure 2(a)) to guarantee that the delayed value is the correct one. all the information, clock-wise and data-wise, is comprised in the same signal, hence the compact smv code generation. a straightforward generalisation of this reasoning allows us to translate in the same way all equations with form: y := f(x$1 init c), where f is a signal function operator. a two-place fifo. let us now consider the translation of the two-place fifo resulting from composing two one-place fifos, as shown by process fifo 2 in figure 6(a). for reasons of space we won’t show the compiled version2 of fifo 2 but use the generated smv code (fig2 the compiler automatically inlines all process instances. 1: module fifo 1(x,h x) 2: var 3: h b, b, tmp: boolean; 4: assign 5: init(tmp) := case 6: h x : x; 7: 1 : 0; 8: esac; 9: next(tmp) := case 10: next(h x) : next(x); 11: 1 : tmp; 12: esac; 13: init(b) := case 14: h b : 1; 15: 1 : 0; 16: esac; 17: next(b) := case 18: next(h b) : !b; 19: 1 : b; 20: esac; 21: define 22: h x := h b & b; 23: h sx := h b & !b; 24: sx := h sx & tmp; figure 5: one-place fifo in smv. 9 / 15 volume 23 (2009) model checking signal process fifo 2 = (? boolean x; ! boolean xok;) (| xok := fifo 1( fifo 1(x)) |) where process fifo 1 ... where process current 1 ... process interleave ... end; end; (a) two-place fifo in signal. module fifo 2(x, h x) var ff11: fifo 1(x, h x); ff12: fifo 1(ff11.sx, ff1.h sx); invar ff11.h sx <-> ff12.h x define xok := ff12.sx; h xok := ff12.h sx; (b) two-place fifo in smv. figure 6: signal and smv: a two-place fifo ure 5), and compose two instances of fifo 1 accordingly. an interesting feature of the fifo 2 signal program is that it is not endochronous (unlike fifo 1) and thus has multiple (master) clocks. its translation into smv (figure 6(b)) uses the same schemas as for endochronous programs though. yet another feature of the generated code is the existence of a clock constraint in the form of an smv invariant. this expression was not translated as a clock definition since the signal compiler was unable to verify its validity, hence its form of constraint rather than a directed assignment (as those appearing in a define section, for instance). 4.2 the whole communication protocol we’ve applied the mentioned simplifications for the complete specification of the protocol proposed by benveniste et al. [bcl+02] (see ftp://ftp.irisa.fr/local/signal/publis/sig2smv/ for the whole protocol and its translation). our simplification rules with the aid of the compiler reduced the number of state variables from 98 to 27 (disregarding any possible reductions in the smv internal representation of such models), with the ensuing improvements in verification time. 5 some model checking here we will pose some ctl [cgp00] queries (and ltl whenever possible, in order to ease the reading) to our previous smv programs (section 4) in order to elucidate some behaviour information from the signal source or the smv translation. also, our queries aim at illustrating the use of the smv clock variables introduced by the translation. 5.1 the need for fairness constraints recall the fifo 1 smv module (fig. 5). we are interested to know whether the smv translation correctly assigns true for the first instant (in signal) of b, given that the default case assigns false (i.e. 0). also recall that the first instant of an smv program does not necessarily correspond to the first instant of some signal clocks. an ltl query could be as follows: (!h b u b). our formula states that along all paths from the initial state(s) of the system our proc. avocs 2009 10 / 15 ftp://ftp.irisa.fr/local/signal/publis/sig2smv/ eceasst signal may remain absent until it is first present with value 1. however, the smv model checker says that our model fails to follow this ltl specification, and gives us a one-state trace to support such a response. a close examination of the counter-example shows that it is a state with a loop transition to it; that is, a behaviour of our system where the signal (h b) is forever absent. this is a valid behaviour and is desirable for compositional reasons. for model checking, however, it is best to ignore behaviours consisting only of such self loops. fortunately, smv provides ways of ensuring that our queries are verified on (possibly looping) behaviours where something interesting happens. this may be achieved using smv fairness statements to restrict the verification to paths where such statements hold infinitely often. hence, for our fifo 1 example, we added the following line: fairness h b, and then our model verifies our ltl query above. let us assume that appropriate fairness constraints have been added to all our examples and our ltl/ctl goals are to be verified along fair paths. clearly the correct fairness statements refer to the clocks of the root(s) of the tree(s) found during clock calculus. now, we can check whether the boolean (guard) signal (b) is alternating, by posing the ltl query: g( ( (h b & b) -> x(!h b u !b) ) | ( (h b & !b) -> x(!h b u b) ) ). by such formula we mean that all states where the signal is present and true are always followed by a sequence of states where the signal may be absent until it first arises (is present) with value false, or the converse (for the signal values only). as expected, the smv answer is affirmative. 5.2 some non-determinism let us now query the fifo 2 module (fig. 6(b)) where a stored value can only be retrieved (at least) two instants after it has been written, and not before. a ctl formula for inspecting whether given an input event (h x), in the next instant, an output event (h xok) is possible could be expressed as ag(ff11.h x -> ex(h xok)). for this goal the model checker answers no and gives a counter-example where every arrival of the output occurs two instants after an input was received. one may think that the output is always available exactly two instants after an input is placed, and thus pose the ltl query g(ff11.h x -> x(x(h xok))). unfortunately this is not the case, as shown by another counter-example generated by smv; the first output arrives four instants after the first input and then every three instants after another input. this (apparently) non-deterministic behaviour is due to the polychronous nature of the signal source by virtue of the two instances of the fifo 1 process (and more specifically, of the interleave process). nonetheless we may assert that in general, there is always a behaviour for which after exactly two instants the output will arrive, in ctl: ag(ff11.h x -> ex(ex( h xok ))). alternatively, we may claim that given the input the output will always eventually arrive, in ltl: g( ff11.h x -> f(h xok) )) and thus verify this with the model checker. note that (in part) due to the imposed fairness constraints, given an input, the output will eventually arrive, even when the constraint is not on the input or output variables. 5.3 correctness of the whole communication protocol before verifying the correctness of the protocol we succeeded in verifying the correctness of a claimed specification property (property number 16 [bcl+02]) of the protocol implementation: 11 / 15 volume 23 (2009) model checking signal never two writing events between two successive bus/buffer sampling events. finally, we posed the same two ctl goals (to prove correctness of the protocol) to our smv translation and thus confirmed the answer previously reported [bcl+02]. 6 related work here we provide some comparison elements for work on model checking for three synchronous languages: esterel, lustre and signal, and work on model checking multi-clocked specifications outside the synchronous paradigm. from the language expressivity perspective it is worth noting that esterel and lustre assume a master clock3, while signal does not impose such a constraint. we may say that the subset of signal programs that are found to be endochronous by the compiler coincide with those synchronous programs with a single master clock. for lustre alone there is a model checker called lesar [ray06]. it is based on symbolic model checking too, and is able to reason about numerical constraints (convex polyhedra) on the transition systems, unlike smv. however, lesar is unable to validate liveness properties; only safety properties can be proved. a case study [bwl06] comparing model checking using lesar and smv (among other validation tools), shows the improved power of smv compared with lesar. in such comparison some translation from lustre is used, but unfortunately it is not provided. nonetheless, a close examination of the lustre sources for their example shows that their programs were already single-clocked, and thus the translation into smv appears much simpler than ours. also, a manual translation from esterel to lustre is mentioned (not provided) to reach the facilities of smv. two other transformations from lustre to smv are mentioned in [mmm05, maww05]. neither of them provide the transformation rules used, nor the lustre subset that could be translated. for model checking esterel programs we know of a proposal [mhm+95] that first translates such programs into an intermediate representation called boolean automata, and then translates such programs into smv. however, the actual definition and transformation into boolean automata is not provided and it appears that not all such boolean automata could be described in their version of smv. sigali [mrls01] is the model checker for signal. it is tightly integrated with the (signal) compiler internal representation and optimisations. in addition to model checking, sigali is also useful for controller synthesis [bbg+01]. however, it does not generate counter-examples (nor witnesses). from the beginning, it was conceived as a decision procedure and some limited form of counter-example generation is possible for safety properties only. the problem of generating counter-examples may be cast as controller synthesis to somewhat project the source program on all the behaviours that lead to a given unsafe set of states. such program projection may be interpreted as a set of counter-examples. as regards the input language, sigali only supports boolean and event signals whereas smv has some (limited form of) integer reasoning and offers the possibility to bridge to bounded model checkers too. nonetheless, in sigali, signal clocks need not always be explicit in ltl/ctl goals, they may remain implicit unlike our proposal for smv. 3 esterel v7 appears to be multi-clocked, though. proc. avocs 2009 12 / 15 eceasst we argue that making clocks explicit fosters a good understanding of the source specification, besides the potential feedback provided by counter-examples. outside the synchronous approach there is the work of clarke et al. [cky03] and the work of ganai and gupta [gg07]. in the context of bounded model checking, the former considers linear relations (equality and/or inequality) between clocks as input and then synthesises an automaton that describes all possible schedules of the clock ticks. even though the system of linear relations may reference precise clock frequencies the synthesised automaton refers to logical instants, as in signal. stuttering transitions are problematic for the automaton representation since it is not evident which is(are) the master clock(s), if any. the authors appear to circumvent the problem for their experiments but a definitive answer is missing. their proposal is tightly dependent on their bounded model checker and the kind of properties checked appears to be restricted to safety issues only, whereas we are not dependent on safety properties and bounded model checking remains one possibility amongst several. in a refinement of this work, ganai and gupta [gg07] propose a specialised translation of ltl goals for clocked specifications, which apparently render the bounded model checking scalable, for multiple-clocks. by contrast, we do not propose any model checking technique, neither an optimised translation of clocked ltl/ctl formulas. however, we propose a tightly integrated (with the signal compiler) translation from specifications with multiple clocks into smv where bounded model checking is one option. last, but not least, smv itself provides a syntax for composing (single-clocked) modules asynchronously, using the process keyword. this language feature offers the possibility to express some coarse-grained multi-clocked specifications without the need for extra explicit signaling (as is the case of our smv boolean variables to denote clocks). by contrast, in our source signal multi-clocked specifications clocks are finely interwoven. the challenge here is to derive a so-called gals (globally-asynchronous locally-synchronous) description from the signal source multi-clocked specifications in order to match and profit from this smv language feature (i.e. asynchronous composition of single-clocked modules). 7 concluding remarks we have shown a simple source-to-source translation from signal (multi-clocked) specifications to single-clocked smv programs for the purpose of ctl verification. then we refine the translation taking into account the compiler analysis of the source signal program, in order to reduce the number of state variables added by the translation. this optimisation allows us to eliminate signal variables as well as (boolean) clock variables. we stick to a syntax compatible with the three versions of smv currently available. we presume soundness of our translation given the semantic proximity of the two languages and because the smv coding neatly reflects the clock relations (using invariants or definitions) and data-flow (with assignments). the generality of our proposed translation is exercised through modeling and verification of signal specification with multiple master clocks. there are two additions to common/standard use of smv and ctl for model validation, namely, (a) clocks are explicit in smv and ltl/ctl goals, and (b) fairness constraints are needed for ensuring reactivity of the model behaviours; such constraints refer to the clocks of all the roots found during clock calculus. 13 / 15 volume 23 (2009) model checking signal boolean smv variables are used to model signal clocks. the translation automatically adds the boolean clocks, and it is the user who will be responsible for a correct combination of clocks and signals while querying (in ltl or ctl) the produced smv model. the chief condition for a sound use of explicit clocks is that the value of a signal is only meaningful when its clock evaluates to true. as a result, the user is only concerned with knowing the name of the clock of a signal and for every occurrence of the signal name (in a temporal formula) add the conjunct to test its presence (by referring to a true occurrence of its clock variable). future work. here we only used the ltl/ctl verification functionality of smv. we plan to experiment with other functionalities (bounded model checking, bounds analysis, refinement checking, induction, and compositional verification). in order to reduce the load to the user on combining clocks and signal values while querying the smv model, we envisage automating the addition of clocks to temporal formulas without them. bibliography [abl94] t. p. amagbegnon, l. besnard, p. le guernic. arborescent canonical form of boolean expressions. technical report 2290, unité de recherche inria rennes, irisa, campus universitaire de beaulieu, 35042 rennes cedex, france, 1994. [abl95] t. p. amagbegnon, l. besnard, p. le guernic. implementation of the dataflow synchronous language signal. in conference on programming language design and implementation, pldi95. acm press, 1995. [bb91] a. benveniste, g. berry. the synchronous approach to reactive and real-time systems. in proceedings of the ieee. volume 79(9), pp. 1270–1282. september 1991. [bbg+00] l. besnard, p. bournai, t. gautier, n. halbwachs, s. nadjm-tehrani, a. ressouche. design of a multi-formalism application and distribution in a data-flow context: an example. in gergatsoulis and rondogiannis (eds.), intensional programming ii. pp. 149–167. world scientific, 2000. [bbg+01] a. benveniste, p. bournai, t. gautier, m. le borgne, p. le guernic, h. marchand. the signal declarative synchronous language: controller synthesis & systems/architecture design. in conference on decision and control. pp. 3284–3289. 2001. [bcl+02] a. benveniste, p. caspi, p. le guernic, h. marchand, j.-p. talpin, s. tripakis. a protocol for loosely time-triggered architectures. in emsoft 2002. pp. 252–265. 2002. [bg92] g. berry, g. gonthier. the esterel synchronous programming language: design, semantics, implementation. science of computer programming 19(2):87–152, 1992. [bgl08] l. besnard, t. gautier, p. le guernic. signal v4-inria version: reference manual. march 2008. http://www.irisa.fr/espresso/polychrony/. proc. avocs 2009 14 / 15 eceasst [bwl06] f. boniol, v. wiels, e. ledinot. experiences in using model checking to verify real time properties of a landing gear control system. in conference on embedded realtime systems. january 2006. [ccj+05] r. cavada, a. cimatti, c. a. jochim, g. keighren, e. olivetti, m. pistore, m. roveri, a. tchaltsev. nusmv 2.4 user manual. itc-irst, via sommarive 18, 38055 povo (trento), italy, 2005. http://nusmv.irst.itc.it. [cgp00] e. m. clarke (jr.), o. grumberg, d. a. peled. model checking. the mit press, 2000. [cky03] e. m. clarke, d. kroening, k. yorav. specifying and verifying systems with multiple clocks. in international conference on computer design (iccd’03). p. 48. 2003. [gg07] m. k. ganai, a. gupta. efficient bmc for multi-clock systems with clocked specifications. in asia and south pacific design automation conference. pp. 310–315. 2007. [hcrp91] n. halbwachs, p. caspi, p. raymond, d. pilaud. the synchronous dataflow programming language lustre. in proceedings of the ieee. volume 79(9), pp. 1321–1336. september 1991. [ltl03] p. le guernic, j.-p. talpin, j.-c. le lann. polychrony for system design. journal of circuits, systems, and computers, march 2003. [maww05] s. p. miller, e. a. anderson, l. g. wagner, m. w. whalen. formal verification of flight critical software. in aiaa guidance, navigation and control conference and exhibit. august 2005. [mcm99] k. l. mcmillan. the smv language. march 1999. http://www.kenmcmil.com/smv.html [mcm01] k. l. mcmillan. the smv system (version 2.5.4). 2001. http://www-2.cs.cmu.edu/∼modelcheck/smv/smvmanual.ps [mhm+95] m. müllerburg, l. holenderski, o. maffeı̈s, a. meceron, m. morley. systematic testing and formal verification to validate reactive programs. software quality journal 4(4), 1995. [mmm05] m. moy, f. maraninchi, l. maillet-contoz. lussy: an open tool for the analysis of systems-on-a-chip at the transaction level. design automation for embedded systems 10(2-3):73–104, 2005. [mrls01] h. marchand, e. rutten, m. le borgne, m. samaan. formal verification of programs specified with signal: application to a power transformer station controller. science of computer programming 41(1):85–104, 2001. [ray06] p. raymond. vérification de programmes synchrones avec lustre/lesar. in navet (ed.), systèmes temps réel 1. pp. 181–216. hermes science publications, lavoisier, 2006. 15 / 15 volume 23 (2009) http://www.kenmcmil.com/smv.html http://www-2.cs.cmu.edu/~modelcheck/smv/smvmanual.ps introduction signal and smv: syntax and semantics signal kernel static analysis of signal specifications smv: a subset from signal to smv improving the translation into smv translation examples a one-place fifo the whole communication protocol some model checking the need for fairness constraints some non-determinism correctness of the whole communication protocol related work concluding remarks formal relationship between petri net and graph transformation systems based on functors between m-adhesive categories electronic communications of the easst volume 40 (2011) proceedings of the 4th international workshop on petri nets and graph transformation (pngt 2010) formal relationship between petri net and graph transformation systems based on functors between m -adhesive categories maria maximova, hartmut ehrig and claudia ermel 18 pages guest editors: claudia ermel, kathrin hoffmann managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst formal relationship between petri net and graph transformation systems based on functors between m -adhesive categories maria maximova, hartmut ehrig and claudia ermel institut für softwaretechnik und theoretische informatik technische universität berlin, germany mascham@cs.tu-berlin.de, ehrig@cs.tu-berlin.de, claudia.ermel@tu-berlin.de abstract: various kinds of graph transformations and petri net transformation systems are examples of m -adhesive transformation systems based on m -adhesive categories, generalizing weak adhesive hlr categories. for typed attributed graph transformation systems, the tool environment agg allows the modeling, the simulation and the analysis of graph transformations. a corresponding tool for petri net transformation systems, the ron-environment, has recently been developed which implements and simulates petri net transformations based on corresponding graph transformations using agg. up to now, the correspondence between petri net and graph transformations is handled on an informal level. the purpose of this paper is to establish a formal relationship between the corresponding m -adhesive transformation systems, which allow the translation of petri net transformations into graph transformations with equivalent behavior, and, vice versa, the creation of petri net transformations from graph transformations. since this is supposed to work for different kinds of petri nets, we propose to define suitable functors, called m -functors, between different m -adhesive categories and to investigate properties allowing us the translation and creation of transformations of the corresponding m -adhesive transformation systems. keywords: m -adhesive transformation system, equivalence, graph transformation, petri net transformation, m -adhesive category 1 introduction modeling the adaptation of a dynamic system to a changing environment gets more and more important. application areas cover e.g. computer supported cooperative work, multi agent systems or mobile networks. one approach to combine formal modeling of dynamic systems and controlled model adaption are reconfigurable petri nets. the main idea is the stepwise development of place/transition nets by applying net transformation rules [ehp+08, pehp08]. this approach increases the expressiveness of petri nets and allows in addition to the well known token game a formal description and analysis of structural changes. rule-based petri net transformation is related to graph transformation [eept06]. for typed attributed graph transformation systems, the well-established tool agg [agg09] allows the modeling, the simulation and the analysis of graph transformations. recently, a tool for reconfigurable petri nets, called ron-tool [tfs07, behm07] (reconfigurable object nets), exe1 / 18 volume 40 (2011) mailto:mascham@cs.tu-berlin.de mailto:ehrig@cs.tu-berlin.de mailto:claudia.ermel@tu-berlin.de translation and creation of transformations cutes and analyzes petri net transformations based on corresponding graph transformations using agg. as a matter of fact, the correspondence between petri net and graph transformations is handled on an informal level up to now. since both graph and net transformation systems are formally defined, the aim of this paper is to propose formal criteria ensuring a semantical correspondence of reconfigurable petri nets and their corresponding representations as graph transformation systems. an m -adhesive transformation system is a general categorical transformation framework based on m -adhesive categories, which rely on a class m of monomorphisms, generalizing weak adhesive hlr categories. the double-pushout approach, based on categorical constructions, is a suitable description of transformations leading to results like the local church-rosser, parallelism, concurrency, embedding, extension, and local confluence theorems [eept06]. a set of rules over an m -adhesive category according to the double-pushout approach constitutes an m -adhesive transformation system [egh10]. aiming for a more general approach to ensure a semantical correspondence of different transformation systems, we establish a formal relationship between two corresponding m -adhesive transformation systems. this correspondence allows us especially the translation of petri net transformations into graph transformations and, vice versa, the creation of petri net transformations from graph transformations in order to analyze the behavior of petri net transformation systems by analyzing their translation in terms of typed attributed graph transformation systems using the tool agg [agg09]. we propose to define suitable functors, called m -functors, between different m -adhesive categories and to investigate properties, which allow us the translation and creation of transformations of the corresponding m -adhesive transformation systems. the paper is structured as follows: section 3 introduces the formal notions m -adhesive transformation systems and m -functors. the first main result given in section 4 states that an m functor translates rules in a way that applicablility and transformation results are translated as well. vice versa, the second main result states that an m -functor also creates applicability of rules in the other direction. section 5 applies these new main result to the translation and creation of petri net transformations by constructing and analyzing an m -functor from the category of place/transition nets to the category of typed attributed graphs with corresponding type graph1. in section 6, we conclude and propose interesting future research directions. 2 related work in [mm90], meseguer and montanari represented petri nets as graphs equipped with operations for composition of transitions. they introduced categories for petri nets with and without initial markings and functors expressing duality and invariants. their constructions provide a formal basis for expressing concurrency in terms of algebraic structures over graphs and categories. based on categorical petri nets, in [ds02], petri nets are related to automata with concurrency relations by establishing a correspondence as coreflection between the associated categories. a first approach to relate petri nets and graph transformation systems has been proposed by kreowski in [kre81], where petri net firing behavior is expressed by graph transformation rules. in our approach, we want to consider petri net transformations in addition. moreover, we aim for a 1 for the results in section 5, we give only proof ideas. more detailed proofs are given in [mee11]. proc. pngt 2010 2 / 18 eceasst more general approach that establishes a semantical correspondence not only between petri net and graph transformation systems but between any kind of formally defined rule-based transformation systems that can be generalized as m -adhesive transformation systems. in order to transform not only graphs, but also high-level structures as petri nets and algebraic specifications, high-level replacement (hlr) categories were established in [ehkp91a, ehkp91b], which require a list of so-called hlr properties to hold. they were based on a morphism class m used for the rule morphisms. this framework allowed a rich theory of transformations for all hlr categories, but the hlr properties were difficult and lengthy to verify for each category. combining adhesive categories [ls04] and hlr categories lead to (weak) adhesive hlr categories in [ehpp06] and to m -adhesive categories in [egh10], where a subclass m of monomorphisms is considered and only pushouts over m -morphisms have to fulfill the van kampen property (a certain compatibility of pushouts and pullbacks). not only many kinds of graphs, but also different kinds of place/transition nets and algebraic high-level nets are m -adhesive and also weak adhesive hlr categories which allows the application of the theory to all these kinds of structures [eept06, pe07, mge+09]. in fact, all results in [eept06] for weak adhesive hlr categories are also valid for m -adhesive categories [egh10]. 3 m -adhesive categories, transformation systems and m -functors an m -adhesive category [egh10], consists of a category c together with a class m of monomorphisms as defined in definition 1 below. the concept of m -adhesive categories generalises that of weak adhesive, adhesive hlr and adhesive categories [ls04]. the category of typed attributes graphs and several categories of petri nets are weak adhesive hlr (see [eept06]) and hence also m -adhesive. definition 1 (m -adhesive category) an m -adhesive category (c,m ) is a category c together with a class m of monomorphisms satisfying • c has pushouts (pos) and pullbacks (pbs) along m -morphisms, • m is closed under composition, decomposition, pos and pbs, • pos along m -morphisms are m -vk-squares, i.e. the vk-property holds for all commutative cubes, where the given po with m ∈ m is in the bottom, the back faces are pbs and all vertical morphisms a,b,c and d are in m . the vk-property means that the top face is a po iff the front faces are pbs. a b c d a′ b′ c′ d′ m f g n m′ f ′ g′n ′ a b c d definition 2 (m -adhesive transformation system and independence) given an m -adhesive category (c,m ). • an m -adhesive transformation system as = (c,m ,p) has in addition a set p of productions of the form ρ = (l l←− k r−→ r) with l,r ∈ m . 3 / 18 volume 40 (2011) translation and creation of transformations a direct transformation g ρ,m =⇒ h via production ρ and match m consists of two pos (1) and (2) as shown in the diagram to the right, where n : r → h is called comatch of m. a production ρ is applicable via m to g, if we have a po complement d in (1), such that (1) becomes a po. l k r g d h (1) (2) l r m n • two (direct) transformations g ρ1,m1 =⇒ h1 and g ρ2,m2 =⇒ h2 are called parallel independent, if there are morphisms d12 : l1 → d2, d21 : l2 → d1 such that l∗1 ◦d21 = m2 and l∗2 ◦d12 = m1. dually g ρ1,m1 =⇒ h1 and h1 ρ2,m2 =⇒ h2 are sequentially independent if h1 ρ1 −1,n1 =⇒ g and h1 ρ2,m2 =⇒ h2 are parallel independent, where ρ1−1 = (r1 r1←−k1 l1−→ l1) and n1 is the comatch of m1. r1 k1 l1 l2 k2 r2 h1 d1 g d2 h2 m1 d12 m2 d21 l1 l∗1 l2 l∗2 in order to study translation and creation of transformations between different m -adhesive transformation systems we introduce the notion of an m -functor. an m -functor establishes a semantical correspondence between different m -adhesive transformation systems. definition 3 (m -functor) a functor f : (c1,m1) → (c2,m2) between m -adhesive categories is called m -functor, if f (m1)⊆ m2 and f preserves pushouts along m -morphisms. on purpose we don’t require that an m -functor preserves pullbacks along m -morphisms, vk-squares, or other properties, but later additional properties of f will be required in order to achieve specific results. remark 1 if we want to consider only (direct) transformations with injective matches, as in the case of petri net transformations in the next section, then it is sufficient to define the functor f on injective morphisms only. moreover, this restriction is necessary, if f is not well-defined for non-injective morphisms. for this case we need to define a special kind of an m -functor: a restricted m -functor. definition 4 (restricted m -functor) a functor f : c1|m1 → c2|m2 between m -adhesive categories (c1,m1) and (c2,m2) with ci|mi the restriction of ci to mi-morphisms for i = 1,2 is called a restricted m -functor, if f (m1) ⊆ m2 and f translates pos along m1-morphisms in (c1,m1) into pos along m2morphisms in (c2,m2). proc. pngt 2010 4 / 18 eceasst 4 translation and creation of transformations to obtain a semantical correspondence between any two transformation systems we need to ensure that the respective transformation systems together with their relevant properties are translated and reflected properly. given an m -adhesive transformation system as1 = (c1,m1,p1) with an m -adhesive category (c1,m1) and productions p1. we want to translate transformations from as1 to as2 = (c2,m2,p2) with m -adhesive category (c2,m2) and suitable productions p2. this can be done using an m -functor f : (c1,m1)→ (c2,m2) for p2 = f (p1). theorem 1 (translation of transformations) an m -functor f : (c1,m1) → (c2,m2) translates applicability of productions, construction of (direct) transformations , as well as parallel and sequential independence of transformations. proof. as2 = (c2,m2,f (p1)) is a well-defined m -adhesive transformation system, because f translates m1-morphisms into m2-morphisms for the productions and each direct transformation g ρ,m =⇒ h in as1 given by pushouts (1) and (2) leads to a direct transformation f (g) f (ρ),f (m) =⇒ f (h) in as2 given by pushouts (3) and (4), because f preserves pushouts along m -morphisms. l k r g d h (1) (2) l r m ⇒ f (l) f (k) f (r) f (g) f (d) f (h) (3) (4) f (l) f (r) f (m) moreover, the functor property of f implies that f translates parallel and sequential independence of transformations. as shown above, we need for translation of transformations from as1 to as2 only the basic properties of an m -functor. this is no longer true for creation of transformations in as1 from transformations in as2 with p2 = f (p1) as above. definition 5 (creation of applicability and direct transformations) 1. an m -functor f : (c1,m1)→ (c2,m2) creates applicability of a production ρ = (l l←− k r−→ r) to object g, if applicability of f (ρ) to f (g) with match m′ : f (l) → f (g) implies applicability of ρ to g with some match m : l → g and f (m) = m′. 2. f creates direct transformations, if for each direct transformation f (g) f (ρ),m′ =⇒ h′ in as2 there is a direct transformation g ρ,m =⇒ h in as1 with f (m) = m′ and f (h)∼= h′ leading to f (g) f (ρ),f (m) =⇒ f (h) in as2: 5 / 18 volume 40 (2011) translation and creation of transformations f (l) f (k) f (r) f (g) d′ h′ (1) (2) f (l) f (r) m′ ⇒ l k r g d h (3) (4) l r m 3. f creates parallel (and similarly sequential) independence, if parallel independence of f (h1) f (ρ1),f (m1)⇐= f (g) f (ρ2),f (m2) =⇒ f (h2) in as2 implies parallel independence of h1 ρ1,m1⇐= g ρ2,m2 =⇒ h2 in as1. remark 2 if f creates parallel (sequential) independence, then f characterises parallel (sequential) independence, i.e., parallel (sequential) independence in as1 is equivalent to parallel (sequential) independence in as2, because f already preserves parallel (sequential) independence by theorem 1. in the following we formulate the properties for an m -functor f , such that we have creation of applicability, direct transformations and parallel (sequential) independence. but first we review the notion of initial pushouts motivated by remark 3 below. definition 6 (initial pushout) given a morphism f : g → g′ in an m -adhesive category (c,m ). (1) is an initial pushout (ipo) over f with boundary b, context c and b,c ∈ m , if (1) is po ∧∀ pos (2) over f (defined by the outer diagram) with h,h′ ∈ m =⇒ ∃!b∗ : b → b′,c∗ : c →c′. h◦b∗ = b ∧ h′◦c∗ = c ∧ (3) is a po. b g b′ (2) c g′ c′ (1)(3) = = b b∗ k h c c∗ k′ h′ f remark 3 for each match m : l → g with initial pushout (4) and b ∈ m1, a production ρ = (l l←−k r−→r) is applicable with match m : l→g, iff the following “gluing condition” is satisfied: there is b′ : b → k in m1 with l ◦b′ = b. in this case the pushout complement d in (5) can be constructed as pushout of b′ ∈ m1 and a leading to h : c → d,k : k → d and an induced morphism d : d → g, s.t., (5) is pushout and (7) commutes (see [eept06]). b l k c g d (4) (5) (6) (7) b l a b′ h k d m definition 7 (properties of m -functors) 1. an m -functor f : (c1,m1)→(c2,m2) creates morphisms, if for all m′ : f (l)→f (g) in (c2,m2) there is exactly one morphism m : l → g with f (m) = m′. 2. f preserves initial pushouts, if for each initial pushout (ipo) (1) over m : l → g, also (2) is initial pushout over f (m) : f (l)→ f (g). proc. pngt 2010 6 / 18 eceasst b (1) l c g b m ⇒ipo in (c1,m1) ipo in (c2,m2) f (b) (2) f (l) f (c) f (g) f (b) f (m) this leads to the following theorem on creation of transformations by m -functors: theorem 2 (creation of transformations) given an m -functor f : (c1,m1)→(c2,m2) with initial pushouts in (c1,m1), which creates morphisms and preserves initial pushouts, then f creates applicability of productions, direct transformations, as well as parallel and sequential independence of transformations. proof. 1. f creates applicability of productions given ρ = (l l←− k r−→ r) and match m′ : f (l)→f (g), s.t., f (ρ) is applicable to m′. since f creates morphisms we have a unique m : l → g with f (m) = m′. let (1) be an initial pushout over m in the diagram below. by assumption on f , (2) is initial pushout over f (m) and (4),(5) are pos. this means, that f (ρ) is applicable to m′ = f (m). according to remark 3, this implies the existence of b′′ : f (b)→ f (k) in m2 with f (l)◦b′′ = f (b). l k rb c g d h (3) (6)(1) l r m b′ a b ⇐ f (l) f (k) f (r)f (b) f (c) f (g) d′ h′ (4) (5)(2) f (l) f (r) m′ b′′ f (b) f (a) since f creates morphisms there is a unique morphism b′ : b → k with f (b′) = b′′. moreover, uniqueness of creation of morphisms implies l◦b′ = b and hence b′∈m1 by decomposition property of m1. hence the gluing condition is satisfied and we have applicability of ρ to g with match m : l → g and f (m) = m′ with pushout complement d in (3). 2. f creates direct transformations given the direct transformation f (g) f (ρ),m′ =⇒ h′ in as2 by pushouts (4) and (5) in (c2,m2). we have already constructed pushout (3) in (c1,m1) and can construct pushout (6) along r ∈ m1 leading to a direct transformation g ρ,m =⇒ h. since f preserves pushouts along m morphisms and pushout complements in (c2,m2) and they are unique up to isomorphism. we have f (d)∼= d′, f (h)∼= h′ and hence also f (g) f (ρ),f (m) =⇒ f (h) in as2. 3. f creates parallel (sequential) independence by parallel independence of f (h1) f (ρ1),f (m1)⇐= f (g) f (ρ2),f (m2) =⇒ f (h2) in as2 we have mor7 / 18 volume 40 (2011) translation and creation of transformations phisms d′12 : f (l1) → f (d2) with f (l ∗ 2)◦d′12 = f (m1) and d ′ 21 : f (l2) → f (d1) with f (l∗1)◦d′21 = f (m2) leading to corresponding morphisms d12 : l1 → d2 and d21 : l2 → d1 with l∗2 ◦d12 = m1 and l∗1 ◦d21 = m2, because f creates morphisms uniquely and preserves composition. remark 4 for the case described in the remark 1 we have to show for theorem 1 that f translates pushouts of m1-morphisms in (c1,m1) into pushouts of m2-morphisms in (c2,m2). for theorem 2 we need in addition, that f creates m -morphisms, i.e., for each (m′ : f (l) → f (g)) ∈ m2 there is exactly one morphism (m : l → g) ∈ m1 with f (m) = m′ and f preserves initial pushouts over m1-morphisms. note, that we cannot replace the m -adhesive categories (ci,mi) for i = 1,2 by (ci|mi,mi), because (ci|mi,mi) are in general not m -adhesive. 5 translation and creation of petri net transformations according to our overall aim in section 1 we want to construct a functor from petri nets to typed attributed graphs and show how to apply the main results of theorem 1 and theorem 2 in order to translate and create petri net transformations using graph transformations. for this purpose we review on one hand the m -adhesive categories (ptinet,m1) of petri nets with individual tokens and class m1 of all injective morphisms, which is defined and shown to be m -adhesive in [mge+09]. on the other hand we review typed attributed graphs (agraphsatg,m2), which are shown to be m -adhesive in [eept06] and we define a suitable attributed petri net type graph at g = pnt g. moreover we construct a functor f between both categories, which, however, is only defined on injective morphisms m1. note, that we do not use petri nets with “classical initial markings”, known as petri net systems [rei85], because the corresponding m -adhesive category requires a class m leading to petri net rules which are marking preserving. marking preserving rules are not adequate to model firing steps as direct transformations since tokens must not be created or deleted. other choices for (c1,m1) would be petri nets without initial marking or algebraic high-level nets (see [eept06, rei85, mge+09]). in fact, we can construct a functor f : ptinet|m1 → agraphspntg|m2 between the categories restricted to m -morphisms, but not an m -functor f : (ptinet,m1)→ (agraphspntg, m2), because f is not well-defined on non-injective morphisms (see counterexample in figure 1 below, where f ( f ) does not preserve attributes in and wpre). this means, we proceed as discussed in remark 4, which allows the application of theorem 1 and theorem 2 in order to obtain translation and creation of petri net transformations with injective morphisms. for application of theorem 1 we need steps 1.-5., and for theorem 2 in addition steps 6. and 7. 1. definition of petri nets with individual tokens: ptinet. 2. definition of typed attributed graphs over petri net type graph pnt g: agraphspntg. 3. translation of pti nets into pnt g-typed attributed graphs (definition of functor f on objects). 4. translation of restricted ptinet-morphisms into restricted agraphspntg-morphisms (definition of functor f : ptinet|m1 → agraphspntg|m2 on morphisms). proc. pngt 2010 8 / 18 eceasst 5. f translates pushouts of m1-morphisms in (ptinet,m1) into pushouts of m2-morphisms in (agraphspntg,m2). 6. f creates m1-morphisms. 7. f preserves initial pushouts over m1-morphisms. figure 1: counterexample for general (non-injective) morphisms 5.1 petri nets with individual tokens: ptinet for classical place / transition (p/t) nets n we adopt the approach of meseguer and montanari [mm90] using free commutative monoids p⊕ over p, where n = (p,t, pre, post) with places p, transitions t , functions pre, post : t → p⊕ and markings m ∈ p⊕. petri nets ni = (p,t, pre, post,i,m) with individual tokens are place/transition nets n = (p,t, pre, post) together with a set i of individual tokens and a marking function m : i →p assigning a place m(x) ∈ p to each x ∈ i. therefore two (or more) different individual tokens x,y ∈ i may be on the same place, i.e. m(x) = m(y), while in the standard “collective token approach” the marking m ∈ p⊕ tells us only how many tokens we have on each place, but we are not able to distinguish between two tokens on the same place. a formal definition of a petri net with individual tokens is as follows ([mge+09]). definition 8 (petri net with individual tokens) a petri net with individual tokens ni = (p,t, pre, post,i,m) is given by a classical p/t net n = (p,t, pre : t → p⊕, post : t → p⊕), where p⊕ is the free commutative monoid over p, a (possibly infinite) set of individual tokens i, and the marking function m : i → p, assigning to each individual token x ∈ i the corresponding place m(x)∈ p. ptinet-morphisms now define not only a mapping between two p/t nets but also between their individual tokens: definition 9 (ptinet-morphism) a ptinet-morphism f : ni1 → ni2 is given by a triple of functions f = ( fp : p1 → p2, ft : t1 → t2, fi : i1 → i2), such that the following diagrams commute with pre and post respectively. 9 / 18 volume 40 (2011) translation and creation of transformations t1 = p1⊕ t2 p2⊕ pre1 post1 ft fp ⊕ pre2 post2 i1 = p1 i2 p2 m1 fi fp m2 it is also shown in [mge+09], that (ptinet,m1) with the class m1 of all injective morphisms is an m -adhesive category, where pushouts and pullbacks are constructed componentwise (see figure 2, where (1) is an example for a pushout in (ptinet,m1), with individual tokens colored in black). figure 2: po in ptinet in the following we only consider the restriction of ptinet to m1-morphisms, ptinet|m1 , in order to define the functor f in subsection 5.4, because f is not well-defined on general morphisms. but we use the m -adhesive category (ptinet,m1) in order to define pushouts, because (ptinet|m1,m1) is not m1-adhesive due to the well-known fact, that the induced morphism of m1-morphisms is in general not an m1-morphism. 5.2 typed atributed graphs over petri net type graph pntg according to [eept06] the category (agraphsatg,m2) of typed attributed graphs with class m2 of all injective morphisms with isomorphism on the data type part is m -adhesive, where pushouts along m2-morphisms are constructed componentwise in the graph part. proc. pngt 2010 10 / 18 eceasst place token trans nat token2 place place2trans trans2place weightpost weightpre in out place token trans in : nat out : nat place2trans weightpre : nat trans2 place weightpost : nat token2 place σ−nat sorts : nat opns : z :→ nat succ : nat → nat nat natnat = n znat = 0 ∈n succnat : n→n x 7→ x + 1 figure 3: type graph pntg with data type signature σ−nat and algebra nat objects in agraphs are pairs (g,d) of an e-graph g with signature e (shown to the right), and σ−nat data type d, where in the following we only use d = tς−nat ∼= nat . this means, g is given by g = (v gg ,v g d = n,e g g ,e g na,e g ea,(s g j ,t g j ) j∈{g,na,ea} ), where v gg resp. v g d are the graph resp.-data nodes of g, e g g , e g na, eg vg ena vd eea sg tg sna tna sea tea resp. e gea are the graph edges resp. node attribute and edge attribute edges of g and s g j ,t g j are corresponding source and target functions for the edges. in our case, the type graph atg is the petri net type graph pntg shown in figure 3 with data type signature σ−nat and algebra tς−nat ∼= nat for rules and graphs, where the e-graph of pntg is shown on the left and its attribute notation on the right of figure 3. objects in agraphspntg are pairs (an,type) with attributed graph an = (g,d) with d = nat and agraphs-morphism type : (g,d)→(pntg,dfin) with final σ−nat data type dfin. morphisms in agraphspntg are defined componentwise and are type compatible with morphisms in agraphs. four sample morphisms in agraphspntg are shown in figure 4, where a pushout is constructed. 5.3 translation of pti nets into pntg-typed attributed graphs a formal definition of the functor f on objects is given as follows. definition 10 (translation of ptinet-objects) given a pti net ni = (p,t, pre, post,i,m). we define the object f (ni) = ((g,nat ),type) in agraphspntg with type : (g,nat )→ (pnt g,d f in) and g = (v gg ,v g d = n,e g g ,e g na,e g ea, (sgj ,t g j ) j∈{g,na,ea} ) as follows, where we use the following abbreviations: token2place , to2 p, place2trans , p2t,trans2 place , t2 p,weightpre , wpre,weightpost , wpost and pre(t)(p) = np ∈ n for pre(t) = ∑p∈p np · p ∈ p⊕ and similar for post(t)(p). 11 / 18 volume 40 (2011) translation and creation of transformations figure 4: po in agraphspntg v gg = p]t ]i e gg = e g to2 p ]e g p2t ]e g t2 p with e gto2 p ={(x, p)∈ i ×p | m(x) = p}, e g p2t ={(p,t)∈ p×t | pre(t)(p) > 0} and e gt2 p ={(t, p)∈ t ×p | post(t)(p) > 0} e gna = e g in ]e g out with e gin ={(t,n,in) | (t,n)∈ t ×n∧|•t|= n}, e gout ={(t,n,out) | (t,n)∈ t ×n∧|t •|= n}, where •t and t• are the preand post-domains of t ∈ t with cardinalities |•t| and |t •|. e gea = e g wpre ]e g wpost with e gwpre = { (p,t,n)∈ e gp2t ×n | pre(t)(p) = n } e gwpost = { (t, p,n)∈ e gt2p ×n | post(t)(p) = n } sgg,t g g : e g g →v g g defined by s g g(a,b) = a resp. t g g (a,b) = b sgna : e g na →v g g , t g na : e g na →n defined by s g na(t,n,x) = t resp. t g na(t,n,x) = n sgea : e g ea → e g g defined by s g ea(p,t,n) = (p,t) and s g ea(t, p,n) = (t, p) t gea : e g ea →n defined by t g ea(p,t,n) = n and t g ea(t, p,n) = n proc. pngt 2010 12 / 18 eceasst the corresponding type-morphism is given in definition 11 below. an example for using the functor f on objects is shown in figure 4, where the four typed attributed graphs are translations of the corresponding four pti nets in figure 2. definition 11 (agraphspntg-morphism type) the agraphspntg-morphism type : (g,nat ) → (pnt g,d f in) is given by final morphism of data types and typeg : g → pnt g given by e-graph morphism typeg = (typevg,typevd,typeeg, typeena,typeeea) where typevg : v g g →v pnt g g with x 7→ place (x ∈ p), x 7→ trans (x ∈ t ), x 7→ token (x ∈ i) typevd : n→ d f innat with x 7→ nat (x ∈n) typeeg : e g g → e pnt g g with x 7→ y for x ∈ e g y and y ∈{to2p, p2t,t2 p} typeena : e g na → e pnt g na with x 7→ y for x ∈ e g y and y ∈{in,out} typeeea : e g ea → e pnt g ea with x 7→ y for x ∈ e g y and y ∈{wpre,wpost} 5.4 translation of restricted ptinet-morphisms into restricted agraphspntg-morphisms we now define the functor f : ptinet|m1 → agraphspntg|m2 on injective morphisms. a counterexample for the translation of non-injective morphisms is given in figure 1, examples for injective morphisms in figure 2 and corresponding translated morphisms in figure 4. definition 12 (translation of ptinet-morphisms) for each ptinet-morphism f : ni1 → ni2 with f = ( fp, ft , fi) ∈ m1, i.e. fp, ft , fi injective, we define f ( f ) : f (ni1)→ f (ni2) where f (nii) = (vig,n,eig,eina,eiea,(si j,ti j) j∈{g,na,ea}) with i = 1,2 by f ( f ) = f ′ = ( f ′vg, f ′ vd, f ′ eg, f ′ ena, f ′ eea) with f ′vg : v1g →v2g with vig = pi ]ti ]ii for i = 1,2 by f ′ vg = fp ] ft ] fi f ′vd : n→n by f ′ vd = idn f ′eg : e1g → e2g with eig = eito2 p ]ei p2t ]eit2 p by f ′eg(x, p) = ( fi(x), fp(p)) for (x, p)∈ e1to2 p f ′eg(p,t) = ( fp(p), ft (t)) for (p,t)∈ e1 p2t f ′eg(t, p) = ( ft (t), fp(p)) for (t, p)∈ e1t2 p f ′ena : e1na → e2na with eina = eiin ]eiout by f ′ena(t,n,i) = ( ft (t),n,i) for (t,n,i)∈ e1in ]e1out ∧i ∈{in,out} f ′eea : e1ea → e2ea with eiea = eiwpre ]eiwpost by f ′eea(p,t,n) = ( fp(p), ft (t),n) for (p,t,n)∈ e1wpre f ′eea(t, p,n) = ( ft (t), fp(p),n) for (t, p,n)∈ e1wpost 13 / 18 volume 40 (2011) translation and creation of transformations lemma 1 (well-definedness of morphism translation) for each f : ni1 → ni2 in ptinet with f ∈ m1 is f ( f ) : f (ni1)→ f (ni2) in agraphspntg well-defined with f ( f )∈ m2. moreover f preserves inclusions. proof. a detailed proof is given in [mee11] showing the following steps: 1. f ′vg, f ′ vd, f ′ eg, f ′ ena, f ′ eea are well-defined w.r.t. codomain. 2. the components of f ( f ) are compatible with sources and targets. 3. the components of f ( f ) are compatible with typing morphisms. 4. f ∈ m1 (inclusion) implies f ( f )∈ m2 (inclusion). 5.5 translation of pushouts we have to show, that if (1) is a po in ptinet with fi ∈ m1, then we have that (2) is a po in agraphspntg with f ( fi)∈ m2. ni0 (1) ni1 ni2 ni3 f1 f2 f4 f3 f (ni0) (2) f (ni1) f (ni2) f (ni3) f ( f1) f ( f2) f ( f4) f ( f3) since pos in ptinet are constructed componentwise, we know that the p-, t and i-components of (1) are pos in sets. since also pos in agraphsatg and agraphspntg are constructed componentwise we have to show that the vg-, vd-, eg-, enaand eea-components of (2) are pos in sets. this is clear for the vg-components fivg = fip] fit ] fii , because pos are compatible with coproducts and for fid, because all components are identities. for the eg-component we have to show, that (3) is po in sets, which follows if (4) and similar (4a) resp. (4b) with “to2p” and “ fii × fip” replaced by “p2t” and “ fip × fit ” resp. “t2p” and “ fit × fip” are pos. e0g (3) e1g e2g e3g f ( f1)g f ( f2)g f ( f4)g f ( f3)g e0to2 p (4) e1to2 p e2to2 p e3to2 p f1i × f1p f2i × f2p f4i × f4p f3i × f3p for the enaand eea components, it is sufficient to show pos (5) and (6) and similar (5a) with “in” replaced by “out” and (6a) with “pre” replaced by “post”. e0in (5) e1in e2in e3in f1t ×idn f2t ×idn f4t ×idn f3t ×idn e0wpre (6) e1wpre e2wpre e3wpre f1p × f1t f2p × f2t f4p × f4t f3p × f3t proc. pngt 2010 14 / 18 eceasst all these diagrams commute, because each product component commutes by assumption. but it is more difficult to show explicitly, that they are pos (see for example lemma 2 below), because products of pos are in general not pos. an example is the translation of the po in ptinet shown in figure 2 to the po in agraphspntg shown in figure 4. lemma 2 (translation of pushouts) diagrams (4) and (4a) are pushouts. proof. see [mee11]. 5.6 creation of injective morphisms given f (ni1),f (ni2) and f ′ : f (ni1)→ f (ni2)∈ m2 with type compatible morphisms f ′vg : v1g →v2g with vig = pi ]ti ]ii for i = 1,2 f ′vd : n→n with f ′ vd = idn f ′eg : e1g → e2g with eig = eito2 p ]ei p2t ]eit2 p f ′ena : e1na → e2na with eina = eiin ]eiout f ′eea : e1ea → e2ea with eiea = eiwpre ]eiwpost define f : ni1 → ni2 with ni j = (pj,tj, pre j, post j,i j,m j) for j = 1,2 by f = ( fp : p1 → p2, ft : t1 → t2, fi : i1 → i2) with ft (t) = f ′ vg(t) for t ∈ t1 ⊆v1g fp(p) = f ′ vg(p) for p ∈ p1 ⊆v1g fi(x) = f ′ vg(x) for x ∈ i1 ⊆v1g well-definedness of f : ni1 → ni2 ∈ m1 follows from lemma 3 below, where the proof of part 2 is based on lemma 4. the proofs of both lemma are given in [mee11]. lemma 3 (well-definedness of creation of injective morphisms) given the construction above for f : ni1 → ni2. the following holds: 1. f ′vg(t)∈ t2, f ′ vg(p)∈ p2, f ′ vg(x)∈ i2, and 2. squares (1),(2) to the right commute with injective fp, ft , fi . t1 (1) p1⊕ t2 p2⊕ pre1 post1 ft fp ⊕ pre2 post2 i1 (2) p1 i2 p2 m1 fi fp m2 lemma 4 (pti-morphism-lemma) f : ni1 → ni2 is an injective ptinet-morphism ⇔ f = ( fp, ft , fi) is injective with 1−4, where 1. ∀t ∈ t1.p ∈•t ⇔ fp(p)∈• ft (t) and ∀t ∈ t1.p ∈ t•⇔ fp(p)∈ ft (t)• 2. ∀(p,t)∈ p1 ⊗t1 = e1 p2t. (p,t,n)∈ e1wpre ⇔ ( fp(p), ft (t),n)∈ e2wpre and ∀(t, p)∈ t1 ⊗p1 = e1t2 p. (t, p,n)∈ e1wpost ⇔ ( ft (t), fp(p),n)∈ e2wpost 15 / 18 volume 40 (2011) translation and creation of transformations 3. ∀t ∈ t1. card(•t) = n ⇔ card(• ft (t)) = n and card(t•) = n ⇔ card( ft (t)•) = n with •t ={p ∈ p1 | pre1(t)(p) > 0} and t•={p ∈ p1 | post1(t)(p) > 0} 4. ∀x ∈ i1.(x, p)∈ e1to2 p ⇔ ( fi(x), fp(p))∈ e2to2 p 5.7 preservation of initial pushouts the proof of this property is based on the initial po constructions for ptinet in [mge+09] and for agraphsatg in [eept06]. details of the proof are given in [mee11]. an example is given in figure 5, where (1) is an initial po over f in ptinet, (2) the induced po over f ( f ), and the initial po over f ( f ) in agraphspntg is given by the outer diagram with corners b′,c′,f (l),f (g). since i′ and j′ are isomorphisms, diagram (2) is already initial po over f ( f ). figure 5: preservation of initial pushouts 6 conclusion and future work as pointed out already in section 1 we want to develop a general framework to establish a formal relationship between different m -adhesive transformation systems based on m -adhesive categories. the main idea is to construct a suitable m -functor between the corresponding m adhesive categories, which translates pushouts, creates morphisms and preserves initial pushouts. proc. pngt 2010 16 / 18 eceasst this allows by theorem 1 and theorem 2 the translation and creation of transformations between the corresponding m -adhesive transformation systems, including parallel and sequential independence of transformations. moreover, we have discussed the restriction to injective matches via m1-morphisms, which requires only a functor for m1-morphisms. in section 5 we have discussed a corresponding functor from petri nets with individual tokens to typed attributed graphs. we have verified that this functor translates pushouts of m1-morphisms, creates m1-morphisms and preserves initial pushouts over m1-morphisms, which allows the application of theorem 1 and theorem 2 in connection with remark 4. in future work, we will provide sufficient conditions in order to ensure that the m−functor preserves initial pushouts2. in the long run, this should allow the analysis of interesting properties of petri net transformation systems, like termination and local confluence in addition to parallel and sequential independence, using corresponding results and analysis tools like agg for graph transformation systems. moreover, it is interesting to study the relationship between other m -adhesive transformation systems using this approach, e.g. high-level petri nets and typed attributed graphs as well as triple graphs and flattening of triple graphs. acknowledgements: some of the authors are partly supported by the german research council project behaviour simulation and equivalence of systems modelled by graph transformation (behaviour-gt). references [agg09] tfs-group, tu berlin. agg. 2009. http://tfs.cs.tu-berlin.de/agg. [behm07] e. biermann, c. ermel, f. hermann, t. modica. a visual editor for reconfigurable object nets based on the eclipse graphical editor framework. in proc. workshop on algorithms and tools for petri nets (awpn’07). 2007. http://tfs.cs.tu-berlin.de/publikationen/papers07/behm07.pdf [ds02] m. droste, r. m. shortt. from petri nets to automata with concurrency. applied categorical structures 10:173–191, 2002. 10.1023/a:1014305610452. http://dx.doi.org/10.1023/a:1014305610452 [eept06] h. ehrig, k. ehrig, u. prange, g. taentzer. fundamentals of algebraic graph transformation. eatcs monographs in theor. comp. science. springer, 2006. [egh10] h. ehrig, u. golas, f. hermann. categorical frameworks for graph transformation and hlr systems based on the dpo approach. bulletin of the eatcs 102:111– 121, 2010. http://tfs.cs.tu-berlin.de/publikationen/papers10/egh10.pdf [ehkp91a] h. ehrig, a. habel, h.-j. kreowski, f. parisi-presicce. from graph grammars to high level replacement systems. in 4th int. workshop on graph grammars and their application to computer science. lncs 532, pp. 269–291. springer, 1991. 2 first steps in this direction are lemma 5 and lemma 6 in [mee11]. 17 / 18 volume 40 (2011) http://tfs.cs.tu-berlin.de/agg http://tfs.cs.tu-berlin.de/publikationen/papers07/behm07.pdf http://dx.doi.org/10.1023/a:1014305610452 http://tfs.cs.tu-berlin.de/publikationen/papers10/egh10.pdf translation and creation of transformations [ehkp91b] h. ehrig, a. habel, h.-j. kreowski, f. parisi-presicce. parallelism and concurrency in high-level replacement systems. math. struct. in comp. science 1:361–404, 1991. [ehp+08] h. ehrig, k. hoffmann, j. padberg, c. ermel, u. prange, e. biermann, t. modica. petri net transformations. in petri net theory and applications. pp. 1–16. i-tech education and publication, 2008. [ehpp06] h. ehrig, a. habel, j. padberg, u. prange. adhesive high-level replacement systems: a new categorical framework for graph transformation. fundamenta informaticae 74(1):1–29, 2006. [kre81] h.-j. kreowski. a comparison between petri nets and graph grammars. in 5th international workshop on graph-theoretic concepts in computer science. lncs 100, pp. 1–19. springer, 1981. [ls04] s. lack, p. sobociński. adhesive categories. in proc. fossacs 2004. lncs 2987, pp. 273–288. springer, 2004. [mee11] m. maximova, h. ehrig, c. ermel. functors between m -adhesive categories applied to petri net and graph transformation systems. technical report 2011/04, tu berlin, 2011. http://www.eecs.tu-berlin.de/menue/forschung/forschungsberichte/2011 [mge+09] t. modica, k. gabriel, h. ehrig, k. hoffmann, s. shareef, c. ermel, u. golas, f. hermann, e. biermann. lowand high-level petri nets with individual tokens. technical report 2009/13, technische universität berlin, 2009. http://www.eecs. tu-berlin.de/menue/forschung/forschungsberichte/2009. [mm90] j. meseguer, u. montanari. petri nets are monoids. information and computation 88(2):105–155, 1990. [pe07] u. prange, h. ehrig. from algebraic graph transformation to adhesive hlr categories and systems. in algebraic informatics. proceedings of cai 2007. lncs 4728, pp. 122–146. springer, 2007. [pehp08] u. prange, h. ehrig, k. hoffman, j. padberg. transformations in reconfigurable place/transition systems. in concurrency, graphs and models: essays dedicated to ugo montanari on the occasion of his 65th birthday. lncs 5065, pp. 96–113. springer, 2008. [rei85] w. reisig. petri nets: an introduction. eatcs monographs on theoretical computer science 4. springer, 1985. [tfs07] tfs-group, tu berlin. reconfigurable object nets environment. 2007. http://www.tfs.cs.tu-berlin.de/roneditor proc. pngt 2010 18 / 18 http://www.eecs.tu-berlin.de/menue/forschung/forschungsberichte/2011 http://www.eecs.tu-berlin.de/menue/forschung/forschungsberichte/2009 http://www.eecs.tu-berlin.de/menue/forschung/forschungsberichte/2009 http://www.tfs.cs.tu-berlin.de/roneditor introduction related work m-adhesive categories, transformation systems and m-functors translation and creation of transformations translation and creation of petri net transformations petri nets with individual tokens: ptinet typed atributed graphs over petri net type graph pntg translation of pti nets into pntg-typed attributed graphs translation of restricted ptinet-morphisms into restricted agraphspntg-morphisms translation of pushouts creation of injective morphisms preservation of initial pushouts conclusion and future work analysis of collaboration effectiveness and individuals' contribution in floss communities electronic communications of the easst volume 48 (2012) proceedings of the fifth international workshop on on foundations and techniques for open source software certification (opencert 2011) analysis of collaboration effectiveness and individuals’ contribution in floss communities antonio cerone, simon fong and siraj ahmed shaikh 15 pages guest editors: luı́s soares barbosa, dimitrios settas managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst analysis of collaboration effectiveness and individuals’ contribution in floss communities antonio cerone1, simon fong2 and siraj ahmed shaikh3 1 antonio@iist.unu.edu, unu-iist — international institute for software technology united nations university, macau sar china 2 ccfong@umac.mo department of computer and information science university of macau, macau sar china 3 s.shaikh@coventry.ac.uk department of computing, coventry university, uk abstract: free/libre open source software (floss) development has proven itself over the years to be able to deliver high-quality software products. however, it is not clear how quality emerges from the large amount of loosely organised activities of a floss community. this makes it difficult to apply traditional quality metrics and certification processes to floss products. this paper investigates possible indicators of collaboration effectiveness and quality of individuals’ contribution that could be extracted from the data available in repositories of floss projects. the ultimate purpose of this effort is to develop quantitative metrics for these indicators and merge such metrics into a global metric for floss software quality to be used in a certification process. keywords: open source software, software quality, collaboration models, trust models, certification. 1 introduction free/libre open source software (floss) development has proven itself over the years to be able to deliver high-quality software products. moreover, the potential benefits of the floss development model include “the ability to more easily carry out open peer reviews, add new functionality either locally or to the mainline products, identify flaws, and fix them rapidly — for example, through collaborative efforts involving people irrespective of their geographical locations and corporate allegiances.” [neu05]. although the high-quality of a number of free/libre open source software (floss) products has been accepted as a fact, it is still unclear how such high-quality emerges from the “bazaarstyle” activities of a floss community. raymond claims that “the high level of quality of free software is partly due to the high degree of peer review and user involvement” [ray99]. mcconnell [mcc99] acknowledges the efficiency of extensive field testing and peer review, along with an emphasis on the need for a comprehensive methodology for open source development. 1 / 15 volume 48 (2012) mailto:antonio@iist.unu.edu mailto:ccfong@umac.mo mailto:s.shaikh@coventry.ac.uk collaboration effectiveness and individuals’ contribution in floss communities this is important if open source development is to be used for producing high quality complex software for use in critical domains such as safety and security. in fact, schneider [sch00] finds that open source software still falls short of requirements for security systems. halloran and scherlis [hs02] review a number of notable quality practices on some popular open source projects, of which good project communication and management is highlighted. coverity has been analysing the quality of open source software since 2006, using coverity scan, a tool for automated static analysis of source code [cov]. the results of this analysis have been published by coverity in annual reports. the 2008 and 2009 reports show that defect density has fallen by 16% over the period 2006–2008 to the extent that the static analysis defect density averaged across all the participating projects is 0.25, or roughly one defect per 4,000 lines of code [cov08, cov09]. improvements to coverity scan and its underlying technology over the past years have allowed to flag more defects than in prior years. as a consequence a direct comparisons to prior years coverity scan results is no longer possible. the 2010 report highlights that (1) nearly half (45%) of the defects discovered in open source are considered highrisk defects; (2) there has been very little change in the types of defects found and frequency in which they occur in open source software; and (3) open source accountability is fragmented [cov10]. in spite of these drawbacks, the report expresses the expectation that as open source continues to mature, more and more projects will begin to adopt stronger quality practices. the 2011 report includes a comparison of proprietary software and open source software that leads to an important key finding: “open source quality for active projects in coverity scan is better than the software industry average” [cov11]. large communities of users have been growing around popular high-quality floss products such as linux, ubuntu, apache, mysql and moodle, among the others. the widespread use of floss products not only involves personal users, who install linux/ubuntu and mysql on their machines, but also small and medium enterprises, who use apache servers and floss tools in their production activities or even incorporate floss components in their software products, and academic and teaching institutions, who use floss products in their research and educational activities, including learning management systems (lms) such as moodle. more recently, large software companies have been launching floss projects with the aim to get revenues by adopting a freemium business model, in which the basic product or service is provided free of charges, while a premium is charged for the provision of support services and/or advanced features and functionality. as highlighted by the 2010 coverity report [cov10], due to the rapid adoption of open source as part of many commercial software supply chains, there is an increasing demand from oems (original equipment manufacturer) to get visibility into the open source software development process and hold open source to the same scrutiny as their other software systems to meet the enterprises necessary quality, safety, and security requirements. the fragmented nature of open source supply chain, made up of multiple components from multiple development teams, makes if difficult to identify who is accountable to upholding requirements and providing visibility and who is to be blamed if and when there is a problem [cov10]. all the above considerations lead to a major limitation for the diffusion of floss products: the lack of a certification process that could provide accountability, meet certification standards and facilitate the approval of a certification authority. however, the lack of accurate information on how quality emerges from the large amount of loosely organised activities of a floss comproc. opencert 2011 2 / 15 eceasst munity makes it difficult to apply traditional quality metrics and certification processes to floss products. for instance, if we consider mccall’s production revision quality factors [mrw77], can we claim that a floss product lacks maintenability because there are no defined coding standards and guidelines to which programming has adhered? the philosophy of freedom and absence of hierarchical organisation typical of floss communities results in collaborative production environments in which there is no space for prescriptive standards and strict guidelines. communication and collaboration are the drivers of such production environments and naturally determine the evolution of programming practices within teams of contributors and across the floss community, even beyond a specific floss project. in such a context, a descriptive approach that analyses the floss community of practise and its activities is likely to define better indicators of the quality of the software product than a prescriptive approach that tries to check whether these activities follow prescribed standards and guidelines [cer12]. in this paper, we carry out a preliminary discussion towards a methodology to analyse community activities in floss projects and extract from the data collected pieces of semantic information to be used as indicators of the quality of the software product. in particular, we focus on two aspects of the floss community of practice: collaboration effectiveness and quality of individuals’ contribution. in section 2 we identify possible indicators of collaboration effectiveness and present cognitivebased collaboration models and a filtering trust network model, and discuss how to adapt them to a floss context. based on the adaptation of one of such cognitive-based collaboration models to a floss context, section 2.1 illustrates an example of metric to characterise collaboration effectiveness in a floss community. section 2.2 illustrates an instantiation of filtering trust network model and further discusses how to adapt such a model to a floss context. section 3 analyses engagement, productivity and reputation, as indicators to be used to define metrics that characterise quality of individuals’ contribution. finally section 4 summerises the achievements of this work and discusses ideas and objectives for future work. 2 collaboration effectiveness collaboration within floss communities is enabled by the usage of tools, such as versioning systems, mailing lists, reporting systems, etc. these tools also serve as repositories which can be data mined to understand the identities of the individuals involved in a communication, the topics of their communication, the amount of information exchanged in each direction, as well as the amount of contribution in terms of code commits, bug fixing, reports and documentation produced and email postings. such a large amount of data can be selectively collected and then analysed not only by using inferential statistics to identify activity patterns but also by using ontology engineering formalisms that support the extraction of semantic information. in the area of empirical software engineering, cyber-archeology [sss07] has been applied to these repositories to learn and better understand the patterns of contribution of floss developers in the projects concerned [sc10]. in such previous work [sc10] data collection has involved communications mainly in terms of participants, quantity and sometimes topics but neglected the objective collection of actual communication contents. at most, content data has been collected through questionnaires and 3 / 15 volume 48 (2012) collaboration effectiveness and individuals’ contribution in floss communities individuals team perform task ? notice need for interaction ? prepare for interaction � �6 interaction �� delivertask product �� figure 1: noble and letsky individual team interplay. surveys or through written reports by researcher who joined the community as observers, thus providing subjective rather than objective data. with reference to existing cognitive-based collaboration models [nl02], data mining methods can be used to extract content information from email communication and posting with the support of appropriate ontologies aiming to identify patterns, progress, evolution and achievements in the collaboration process occurring within groups of participants. this requires the analysis of incremental data and the construction and analysis of graph data from the overall social networking aspect of the floss community. cognitive-based collaboration theory [nl02] aims to consider many different factors underlying the mechanisms that connect community member understandings to community effectiveness in production. there is no single model that represents all of these factors, but separate models that address different factors. only some of these models are relevant to a self-organising non-hierarchical community as is a floss community. the individual-team interplay model [nl02] described in figure 1 is a cyclic model in which individuals perform a task, notice need for interaction, prepare for interaction, perform the interaction and go back to the task, possibly delivering the product of the task and then starting a new task. figure 2 shows how this model can be adapted to the floss context. here interaction consists essentially in posting activities while the product of the task is delivered through a commit activity by the individual or through an approval or release decision by the leader team. the interaction process is decomposed into two looping sub-processes [cer12]: learning sub-process in which the exchange of knowledge between individual and community results in the growth of knowledge at both the individual level and the team or community proc. opencert 2011 4 / 15 eceasst individuals team perform task ? notice need for interaction ? prepare for interaction � �6 interaction @ @ @i learning �� contribution �� comit$�6 internalise �� @ @ @ @ @i team decision �� $� �� approvalor release data mining6 l(t) c(t) d(t) figure 2: individual team interplay for floss. level; contribution process in which a contribution in terms of commit of code, bug report, etc. is the result of an exchange of communications. with reference to this adapted model, section 2.1 illustrates a possible way for defining a metric to characterise collaboration effectiveness in a floss community. the cognition-behaviour-product model [nl02] emphasises the nature of the relationship between individual and team understandings, individual and team behaviours and individual and team production. in a floss context, this model has the important role to explain how task quality and understanding affect each other and is essential in measuring individual task performance and collaboration effectiveness. an important factor in collaboration is trust. fong et al. [ckf12, cf10], have developed a filtering trust network model to study about fusing elusive information and deriving trust factors in a social network, by taking facebook as a case. the above models can be used to define metrics for information interaction, task performance, product quality, peer trust [nl02, cf10]. in addition to metrics definition, some contextual inferring mechanisms are needed as a data pre-processing step for extracting the semantics and essences from the empirical data using machine learning techniques. techniques previously applied to the analysis of public moods based on internet comments [fon12] can be also applied to implement such mechanisms. this will be further discussed in section 2.2. 5 / 15 volume 48 (2012) collaboration effectiveness and individuals’ contribution in floss communities 2.1 towards an individual-team interplay metric one way for defining a metric to characterise collaboration effectiveness within a community that is continuously evolving and producing, as a floss community, is to take snapshots of the collaboration measure at consecutive intervals of a sufficiently short duration ∆t and then calculate the average of the measure over the entire community lifetime. with reference to figure 2 we consider the numbers • l(t) of learning activities, • c(t) of contributions, • d(t) of team decisions that occur during the period [t,t + ∆t] for a given time t. it has been observed [cer12] that participation in a floss project evolves through three stages: stage 1 (understanding) in which communication is heavily used to capture, describe and understand contents, while no production activity is performed; stage 2 (practice) in which the role of communication gradually moves to the proposal of new contents, the defence of the proposed contents and the criticism to existing contents or contents proposed by others, while production activity starts as a trial and error process; stage 3 (developing) in which real development occurs. let • n1(t) be the number of contributors in the understanding stage (stage 1), • n2(t) be the number of contributors in the practice stage (stage 2), • n3(t) be the number of contributors in the developing stage (stage 3) at time t. then the measure of the collaborative effectiveness that characterises the quality enhance of the project development during the period [t,t + ∆t] for a given time t as follows. mt = l(t) · kl n1(t) + n2(t) + c(t) · kc n2(t) + n3(t) + d(t) · kd n3(t) if n2(t) 6= 0 and n3(t) 6= 0. where kl, kc and kd are constants. this measure shows how collaboration effectiveness in individual-team interplay within a floss community is characterised by a combination of learning activities (l(t)) by individuals at the learning (n1(t)) and practice (n2(t)) stages, contribution activities (c(t)) by individuals at the practice (n2(t)) and developing (n3(t)) stages, and team decision activities only by individuals at developing (n3(t)) stages. the contribution of each of the three categories of activities to the quality enhance is directly proportional to the number of activities of that category during the considered time period and inversely proportional to the number of individuals that characterise that category of activities. the constants give weights to the three categories of activities. it is reasonable to expect that kl < kc < kd. note that n3(t) > 0 for proc. opencert 2011 6 / 15 eceasst n(t) n1(t) n2(t) n3(t) l(t) c(t) d(t) mt 10 6 2 2 5 1 1 kl = 1 kc = 2 kd = 4 3.125 10 5 1 4 5 1 1 10 3 3 4 5 1 1 2.233 2.219 10 5 1 4 4 2 1 10 3 3 4 3 1 3 2.467 3.786 figure 3: example. any active project and if n1(t) = n2(t) = 0 the equation above may be modified by removing the first addend. let us consider the example in figure 3 where we use constants kl = 1 < kc = 2 < kd = 4. a project with 10 contributors, 6 at the learning stage, 2 at the practice stage and 2 at the developing stage with 5 learning activities, 1 contribution activity and 1 team decision activity has a quality enhance 3.125. as contributors move to more mature stages, if there is no variation on the activity pattern, the quality enhance decreases to 2.233 (2 contributors move to the developing stage) and then to 2.210 (to further contributors move to the practice stage). on the other hand, an increase in the number of contribution activities is associated with an increase in quality enhance from 2.233 to 2.467 (1 additional contribution) and an increase in the number of team decision activities is associated with an increase in quality enhance from 2.219 to 3.786 (2 additional team decisions). the quality by development of a project of duration d is therefore defined as follows m = 1 n n ∑ t=0 mt where n = d/∆t. 2.2 filtering trust network model reputation is considered as one of the key parameters for defining the quality of an individual’s contribution to a floss project. for example a reputable contributor is expected to be an active and valuable contributor; making quality contributions over a period of time, and this will earn him a good reputation, and vice-versa. without being able to easily gauge quality as it involves complex context and semantics (and is quite subjective), reputation is often related to trust which is a social evaluation or opinion about an individual person. 7 / 15 volume 48 (2012) collaboration effectiveness and individuals’ contribution in floss communities figure 4: hierarchical trust metrics model. in a recent paper [cf10], online trust is inferred via a hierarchical metrics model which consists of explicit trust by relation, and implicit trust by reputation. figure 4 shows the online trust metrics model. trust by relation would have to be manually configured by a system administrator. trust by relation suggests that a relatively high degree of trust is perceived between parents and children, spouses and siblings, and perhaps only a moderate amount of trust is reckoned for a stranger who was met on a trip. in a floss project, it is more relevant to deduce implicit trust — hence reputation, from a series of online social criteria, because of the availability of the collected data. many techniques for inferring trust quantitatively exist in the literature ranging from psychology to computer science. it is noted, however, that the selection of factors or criteria to account for and quantify in the trust equation is not definitive. in fact, there is no definite selection of trust factors ever published or consistently agreed by all researchers. a growingly popular set of factors for deducing online trust is the one proposed by massa and bhattacharjee [mb04], which takes into account the number of messages exchanged between users, the number of mutual readings and comments on each others blogs (or walls in a social network), and the number of common chats within a specified period. some of these attributes are included in a typical trust filtering equation as shown in the following model instantiation as an example. the equation was used to empower a collaborative filtering algorithm for implementing a social network-based recommender [ckf12]. proc. opencert 2011 8 / 15 eceasst the quantified trust by reputation ta,u between user a and user u can be evaluated based on the measured values of these attributes using multiple attribute utility theory (maut) as follows: ta,u = α ∑ pi totpi + β ∑w tw p totw t w p + γ ∑ lf totlf + δ ∑ nf totnf + ε ∑ t tott + θ ∑ gic totgic where α + β + γ + δ + ε + θ = 1, and • pi quantifies personal information; • w t w p is the number of wall-to-wall posts; • lf is the number of links among friends; • nf is the number of friends; • t is the number of tags between user a and user u; • gic is the number of groups in common. and in each term, the denominator tot represents the total quantity of that particular attribute of this user. given the trust estimation equation between any pair of users, a quantifying reputation ra could be defined as the general perceivable credibility of a particular user a by all his peers ra = φ n ∑ u=0 u6=a ta,u where n is the total number of users in the online community and φ is the normalizing factor. however, it should be clear that the selection of criteria is tightly dependent on the functionalities that each specific social networking site provides to its users, and thus can vary greatly from site to site. a recent study [gk09] generalized the trust factors into seven categories (called time strength dimensions), and has statistically shown how useful they are as predictive variables for trust in social networks. these factors are illustrated in figure 5. in addition to the metrics mentioned above, which can be extracted directly from the users’ accounts, the influence of a particular user in a social network can be quantified by how far and how deep his messages propagate to. it is also known that the reputation of a good user is partially measured by his popularity and that of his messages, assuming they are of good-will. klout [klo], the standard for measuring online influence, has derived a collection of in-depth metrics as social media analytics that measure the outreach level and popularity of one’s messages; hence they may form insightful indicators for inferring one’s reputation in his social group. klout scores which range from 1 to 100 correspond to the assessment of the three following measures: true reach which measures the group size of the user’s engaged followers who actively respond to his posted messages; amplification propensity which calculates the likelihood that the user’s posted messages will invite reciprocating messages; 9 / 15 volume 48 (2012) collaboration effectiveness and individuals’ contribution in floss communities figure 5: the distribution of the predictive power of the seven time strength dimensions as part of the how-strong model. source: gilbert and karahalios [gk09]. network score which computes the influential impact value on the users followers. so far it is observed that all the social media metrics proposed by the other researchers are either focused on the quantity of one’s generated messages and his received messages (the so-called interactions), or his intimacy (relations) with his peers. such metrics are indeed pertinent for social network analysis because a social network essentially aims to provide a convergent platform for social activities. such metrics, however, may not suffice the inference of reputation, at least not directly or easily, in floss environment because floss activities are usually task-oriented with specific objectives. for example, an influencer in a social network may be a propaganda promoter which does little constructive contribution to a specific project but counter-productive noise, perhaps. the current models lack of some measures that indicate or imply who has contributed how much a share of progress in a collaborative environment like floss. though the social media metrics and the trust filtering model may serve as good ingredients for data mining and measuring the interaction level respectively, a higher level of processing may be needed for adding the semantics and contextual references to the messages that were exchanged. proc. opencert 2011 10 / 15 eceasst 3 quality of contributions quality of an individual’s contribution to a floss project can be measured in terms of three parameters: engagement, productivity and reputation. shaikh and cerone [sc09] have identified some factors that are unique to the floss development process and influence the entire software development process and, consequently, the quality of the final software product. in their work, shaikh and cerone also define an initial framework in which such factors can be related to each other and to the quality. in particular, they distinguish three main notions of quality in the context of floss development quality by access which aims to measure the degrees of availability, accessibility and readability of source code in relation to the media and tools used to directly access source code and all supporting materials such as the documentation, review reports, testing outcomes, as well as the format and structural organisation of both source code and supporting materials. quality by development which aims to measure the efficiency of all development and communication processes involved in the production, evolution and release of source code, its execution, testing and review, as well as bug reporting and fixing; quality by design which corresponds to the traditional notion of software quality [pre00]: the end quality is judged by the design and implementation of the actual software and the code that underlies it. these three notions of quality can be used as a basis for characterising the quality of engagement of an individual in the community. every activity of an individual can be classified under an appropriate category of quality and marked to contribute to the final software product accordingly. bug reporting, testing and reviews enhance quality by development, the media and format used to externalise such contributions affect quality by access, whereas evidence of planning and design, and validation of software code contribute to quality by design. number of commits and communications provide indicators of the level of contribution of an individual in the community and have been statistically analysed to determine patterns of contribution and their implications for the quality of code [sc10]. the number of commits describes how much the individual delivers in terms of product and is therefore an indicator of the individual’s productivity. although there is no guarantee on the quality of the product delivered, number of commits can be considered by itself an important parameter in evaluating the quality of the individual as a contributor. moreover, by integrating data on the quality of the contribution in terms of quality of code and bug reports produced, and efficacy of bug fixing, and quantitative data on the approval and inclusion of the resultant artifacts in a release by the project leader team, we can define a more accurate measure of the quality of the individual’s productivity. evidence suggests [rhs06] that reputation serves to be a major source of motivation for developers to participate in a community. there is also a clear link between higher status of developers’ reputation and higher levels of income [hnh03], which makes it even more significant given the desire for career progression for developers as another motivation to participate in 11 / 15 volume 48 (2012) collaboration effectiveness and individuals’ contribution in floss communities floss project repositories analysis technology floss community activities ? ? ?? ? ?? ? ? communications commits code reports data mining productivity text mining reputation quality of individuals’ contribution + ? collaboration & trusts models collaboration effectiveness ? categories of quality engagement 6 figure 6: descriptive approach for floss quality assurance floss communities. communications among members of a floss community can be analysed to extract information about the reputation an individual has achieved within the community. text mining of communications can be used to identify keywords and phrases that may indicate whether an individual is asking or providing support and whether an answer or suggestion is taken on board or refuted by others. in addition, the filtering trust network model [ckf12, cf10] discussed in section 2.2 can highlight trust factors that contribute to build an individuals reputation. factors influencing individual reputation can then be categorised as both computational (such as communications) and non-computational (trust factors, ratings). the reputation of an individual depends not just on the participation to a specific floss project, but on the global activities of that individual in the floss world. therefore reputation information of a given individual have to be collected over all floss projects listing that individual as a participants and be integrated with personal information including the individual’s background, publication in the floss field and participation in related social networks and discussion fora. finally, the level of engagement of an individual within a project is visible to the entire project community and, therefore, implicitly affects that individual’s reputation. 4 conclusion and future work we have discussed possible indicators of collaboration effectiveness and quality of individuals’ contribution which can be extracted from the data available in repositories of floss projects. the approach is summarised in figure 6. data involving communications, commits, code and reports may be collected from repositories of floss projects and analysed using data mining and text mining technology, collaboration and trust models and applying the categories of qualproc. opencert 2011 12 / 15 eceasst ity defined by shaikh and cerone [sc09], to extract indicators of specific floss community activities. such indicators can be used to define metrics that characterise collaboration effectiveness in terms of information interaction, task performance, product quality and peer trust, as we have discussed in section 2, and quality of individuals’ contribution in terms of engagement, productivity and reputation, as we have discussed in section 3. we have seen in section 2.1 how to use the individual-team interplay model for floss to define a metric to characterise collaboration effectiveness in a floss community. we have illustrated in section 2.2 an instantiation of filtering trust network model and further discussed how to adapt such a model to a floss context as a characterisation of reputation and as a further characterisation of collaboration effectiveness. finally, we have discussed in section 3 how separate metrics can be defined to characterise engagement, productivity and reputation of individuals. however, it is still unclear how to combine such metrics into a global metric that could quantify the quality of an individuals contribution to a specific floss project. one of the challenges is represented by possible interrelations between the three metrics; for instance, we have pointed out above that engagement affects reputation. in addition to trust, recent work in this area points to various other social parameters that affect reputation [hzc12] demonstrating how reputation obeys the laws of cumulative advantage (through higher likelihood of attracting good reputation given past reputation) and homophily (providing advantage through shared affiliations in terms of common floss projects). further work will aim to 1. analyse all these various social parameters that affect reputation and their impact on quality of individual’s contribution and collaboration effectiveness; 2. combine separate metrics for quality of individuals’ contribution possibly into a contributor profile to offer a more member-centric view of floss development than the community-centric analysis traditionally common in this domain. in our future work, as the final objective of the work presented in this paper, we intend to merge all metrics defined for specific quality indicators into a comprehensive framework to determine a global metric for floss software quality to be used in a certification process. acknowledgements: this work has been supported by macao science and technology development fund, file no. 019/2011/a1, in the context of the ppael project. bibliography [cer12] a. cerone. learning and activity patterns in oss communities and their impact on software quality. in proceedings of opencert 2011. volume 48 of electronic communications of the easst. 2012. [cf10] w. chen, s. fong. social network collaborative filtering framework and online trust factors: a case study on facebook. in the 5th international conference on digital information management (icdim 2010). july 2010, thunder bay, canada, pp. 266–273. ieee press, 2010. 13 / 15 volume 48 (2012) collaboration effectiveness and individuals’ contribution in floss communities [ckf12] w. chen, r. khoury, s. fong. web 2.0 recommendation service by multicollaborative filtering trust network algorithm. journal of information systems frontiers, 2012. [cov] coverity scan. http://scan.coverity.com/about.html [cov08] 2008 coverity scan open source report. 2008. http://scan.coverity.com/report/ [cov09] 2009 coverity scan open source report. 2009. http://scan.coverity.com/report/ [cov10] coverity scan: 2010 open source integrity report. 2010. http://www.coverity.com/library/pdf/coverity-scan-2010-open-source-integrity-report.pdf [cov11] coverity scan: 2011 open source integrity report. 2011. http://www.coverity.com/resource-library [fon12] s. fong. measuring emotions from online news and evaluating public models from netizens comments: a text mining approach. journal of emerging technologies in web intelligence 4(1):60–66, february 2012. [gk09] e. gilbert, k. karahalios. predicting tie strength with social media. in proceedings of the 27th international conference on human factors in computing systems (chi 09). april 4–9, 2009, boston, massachussetts, usa, pp. 211–220. acm, 2009. [hnh03] g. hertel, s. niedner, s. herrmann. motivation of software developers in open source projects: an internet-based survey of contributors to the linux kernel. research policy 32(7):1159–1177, 2003. [hs02] t. j. halloran, w. l. scherlis. high quality and open source software practices. in 2nd workshop on open source software engineering. may 2002. [hzc12] d. hu, j. l. zhao, j. cheng. reputation management in an open source developer social network. decision support systems 53(3):526–1058, jun 2012. [klo] klout. http://www.klout.com [mb04] p. massa, b. bhattacharjee. using trust in recommender systems: an experimental analysis. in proceedings of the 2nd international conference in trust management (itrust 2004). lecture notes in computer science 2995, pp. 221–235. 2004. [mcc99] s. mcconnell. open source methodology: ready for prime time? ieee software 16(4):6–8, jul/aug 1999. ieee computer society. [mrw77] j. a. mccall, p. k. richards, g. f. walters. factors in software quality. volume i. concepts and definitions of software quality. 1977. http://www.dtic.mil/dtic/tr/fulltext/u2/a049014.pdf proc. opencert 2011 14 / 15 http://scan.coverity.com/about.html http://scan.coverity.com/report/ http://scan.coverity.com/report/ http://www.coverity.com/library/pdf/coverity-scan-2010-open-source-integrity-report.pdf http://www.coverity.com/resource-library http://www.klout.com http://www.dtic.mil/dtic/tr/fulltext/u2/a049014.pdf eceasst [neu05] p. g. neumann. attaining robust open source software. in perspectives on free and open source software. the mit press, 2005. [nl02] d. noble, m. letsky. cognitive-based metrics to evaluate collaboration effectiveness. in analysis of the military effectiveness of future c2 concepts and systems. rto-mp-117, nato consultation, command and control agency, the hague, the netherlands, 23-25 april 2002. http://www.rto.nato.int/pubs/rdp.asp?rdp=rto-mp-117 [pre00] s. r. pressman. software engineering a practitioner’s approach. mcgraw-hill international, london, 2000. [ray99] e. s. raymond. the cathedral and the bazaar. o’reilly, 1999. [rhs06] j. roberts, i. hann, s. slaughter. understanding the motivations, participation, and performance of open source software developers: a longitudinal study of the apache projects. management science 52(7):984–999, 2006. [sc09] s. a. shaikh, a. cerone. towards a metric for open source software quality. in proceedings of opencert 2009. volume 20 of electronic communications of the easst. 2009. [sc10] s. k. sowe, a. cerone. integrating data from multiple repositories to analyze patterns of contribution in foss projects. in proceedings of opencert 2010. volume 33 of electronic communications of the easst. 2010. [sch00] f. b. schneider. open source in security: visting the bizarre. in 2000 ieee symposium on security and privacy. may 14–17, 2000, berkley, california, usa, pp. 126– 127. ieee computer society, 2000. [sss07] s. k. sowe, i. g. stamelos, i. m. samoladas (eds.). emerging free and open source software practices. igi global, 2007. 15 / 15 volume 48 (2012) http://www.rto.nato.int/pubs/rdp.asp?rdp=rto-mp-117 introduction collaboration effectiveness towards an individual-team interplay metric filtering trust network model quality of contributions conclusion and future work graph transformation with symbolic attributes via monadic coalgebra homomorphisms electronic communications of the easst volume 71 (2015) graph computation models selected revised papers from gcm 2014 graph transformation with symbolic attributes via monadic coalgebra homomorphisms wolfram kahl 17 pages guest editors: rachid echahed, annegret habel, mohamed mosbah managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst graph transformation with symbolic attributes via monadic coalgebra homomorphisms wolfram kahl∗ mcmaster university, hamilton, ontario, canada, abstract: we show how a coalgebraic approach leads to more natural representations of many kinds of graph structures that in the algebraic approach are frequently dealt with using ad-hoc constructions. for the case of symbolically attributed graphs, we demonstrate how using substituting coalgebra homomorphisms in double-pushout rewriting steps yields a powerful and easily understandable transformation mechanism. keywords: transformation of symbolically attributed graphs, attributed graphs as coalgebras, categoric approach to graph transformation 1 introduction an attributed graph is a graph where (some of) the items (nodes and edges) carry “attributes”, which are taken from some attribute datatypes. formal treatments of datatypes [em85, bkl+91, bm04] typically characterise datatypes as algebras, or “sets with operations”; they are most frequently implemented as software libraries where the sets are only abstract entities, the operations are executable code, and only the elements of the sets are represented as static data. graphs, too, can be characterised as algebras, most prominently in the “algebraic approach to graph transformation” [cmr+97, ehk+97, eept06]. however, the sets in question are the sets of nodes and edges, and the “operations” are the incidence relations; the whole algebra, understood as a graph, is typically represented as static data. in attributed graphs, these two conflicting views of algebras come together, and formalisations that consider an attributed graph as a single algebra that includes both graph item sorts and attribute value sorts do not correspond to the way attributed graphs are understood in terms of data organisation. for graph transformation, the theory of the algebraic approach also contributes to the necessity of keeping the graph algebra separate from the attribute value algebra, since pushouts of graph structures, customarily considered as unary algebras [löw90, cmr+97], can be calculated component-wise, while for typical attribute value algebras, this is not the case. indeed, most applications have no need to transform the attribute value algebras, since most transformation concepts for attributed graphs expect the transformation results to be attributed over the same attribute datatypes. an exception to this consideration are symbolic attributes, which can easily be drawn from term algebras over different variable sets during different stages of transformation. ∗ this research is supported by the national science and engineering research council of canada, nserc. 1 / 17 volume 71 (2015) graph transformation with symbolic attributes via monadic coalgebra homomorphisms unary algebras are in fact also co-unary coalgebras, and many kinds of graphs that do not fit the mould of unary algebras can actually naturally be considered as more general coalgebras. this argument was first made in [kah14]; in the current paper we continue that development and show how to use substituting coalgebra homomorphisms for dpo rewriting of symbolically attributed graphs. after discussing related work in the next section and providing necessary notation in sect. 3, we explain the basic technicalities for modelling graph structures using coalgebras in sect. 4. using the example of edge-labelled and node-attributed graphs, we move to substituting coalgebra homomorphisms in sect. 5. the resulting category is an instance of the monadic product coalgebra categories introduced in [kah14]; we summarise definition and basic results in sect. 6. the resulting pushouts are used in sect. 7 to obtain direct derivations of attributed graphs. we contrast our approach with the adhesive approach of [eept06] in more detail in sect. 8. since the rules and direct derivations of sect. 7 are not using monomorphisms where most of the current dpo graph transformation literature, and in particular the adhesive approach, prescibe them, we prove a characterisation of monomorphisms in categories of substitutions in appendix a. 2 related work löwe et al. [lkw93] appear to have been the first to consider attributed graphs in the context of the algebraic approach to graph transformation; they propose to extend the customary unary graph structure signature with an arbitrary attribute signature, and a set of unary attribution operators connecting the two. these attribution operators typically may have as their source special sorts of attribute carriers, which can be deleted and re-created for relabelling. könig and kozioura [kk08] essentially follow the approach of [lkw93], but choose a rigid organisation of unlabelled nodes, and labelled hyperedges with a single attribute the sort of which is determined by the edge label. homomorphisms include algebra homomorphisms. in a rule (l,r,α,g), the two rule sides l and r are attributed graphs over the term algebra over a globally fixed set of variables, with l attributed only with variables, and only variables occurring in l may occur in r. the rule morphism is defined by an injective node mapping α ; rule morphisms are not defined for edges and attributes, and therefore are a special case of partial morphisms. (the boolean guard term g controls applicability of the rule.) matches need to be injective on edges; rewrite steps preserve the data algebra. in the double-pushout approach, [hkt02, ept04] use attribution edges connecting graph items with attribute values, and are essentially predecessors of [eept06], the approach of which is discussed in more detail in sect. 8. all the above consider arbitrary attribute algebras for the application graphs, with term algebras a special case. for the “symbolic graphs” of [ore11, ol10b], the data algebra is not considered an explicit part of the graph structure; instead, a “symbolic graph” is an e-graph over a sorted variable set together with a set of formulae (most typically equations) that may refer to constants drawn from the data algebra. since the conventional m-adhesive approach does not cover rule applications that change attributes, [gol12] presents a variant of adhesive categories that softens the adhesive restrictions selected revised papers from gcm 2014 2 / 17 eceasst to only affect the pushouts that are actually needed during transformation, avoiding spurious non-unifiability problems for attributes. similarly, habel and plump [hp12] restrict the class of morphisms to be used in “vertical” roles in the rewriting steps, to be able to capture the relabelling dpo graph transformations of [hp02, plu09] which use partially labelled interface graphs. a different approach to relabelling is that of rebout [rfs08], which combines de-facto-partial attribution relations with a special mechanism for relabelling via “computations” in the left-hand side of the rule. rutten’s overview article [rut00] is useful for general theory of coalgebras. related with our current work is the part of the coalgebra literature that deals with combining algebras and coalgebras; one approach considers separate algebraic and coalgebraic structures in the same carriers, for example kurz and hennicker’s “institutions for modular coalgebraic specifications” [kh02]. a further generalisation are “dialgebras” [hag87, pz01], which have a single carrier x, and operations fi ∶ fi x → gi x, where both fi and gi are polynomial functors. 3 notation and background: categories and monads we assume familiarity with the basics of category theory; for notation, we write “f ∶ a→b” to declare that morphism f goes from object a to object b, and use “.,” as the associative binary forward composition operator that maps two morphisms f ∶ a→b and g ∶ b→c to (f ., g) ∶ a→c. the identity morphism for object a is written ia. we assign “.,” higher priority than other binary operators, and assign unary operators higher priority than all binary operators. the category of sets and functions is denoted by set. a functor f from one category to another maps objects to objects and morphisms to morphisms respecting the structure generated by →, i, and composition; we denote functor application by juxtaposition both for objects, f a, and for morphisms, f f . although we use forward composition of morphisms, we use backward composition “○” for functors, with (g○f) a = g (f a). a monad on a category c consists is a functor m ∶ c→c for which there are two natural transformations (“polymorphic morphisms”) returna ∶ a →m a and joina ∶m (m a)→m a satisfying returnm a ., joina = i and m returna ., joina = i and m joina ., joina = joinm a ., joina. important monads are the list monad, and the term monad tς for any (algebraic) signature σ. for the former, joinlist,a ∶ list (list a)→list a is the function that flattens (or concatenates) lists of lists. for the latter, tς v is the set of terms with elements of set v used as variables; the function join tς,v ∶tς (tς v)→tς v maps nested terms (or terms using v -terms as variables) into “flattened” v -terms. each monad m on c induces the so-called kleisli category km that has the same objects as c, but c-morphisms a →m b as morphisms from a to b. kleisli-composition of f ∶ a →m b with g ∶ b →m c will be written f # g; this is defined by f # g = f .,(m g) ., joinc. in the term monad tς, kleisli morphisms are substitutions σ ∶ v1→tς v2, and kleisli composition is just composition of substitutions. application of a substitution σ ∶ v1→tς v2 to a term t ∶tς v1 will be written σ ▹t. (appendix a contains a few more details about the term monad.) 3 / 17 volume 71 (2015) graph transformation with symbolic attributes via monadic coalgebra homomorphisms the double-pushout (dpo) approach to high-level rewriting [cmr+97] uses transformation rules that are spans l ϕl� g ϕr-r in an appropriate category between the left-hand side l, gluing object g, and right-hand side r. a direct transformation step from object a to object b via such a rule is given by a double pushout diagram, with host object h, where the morphism µ is called the match. l ϕl� g ϕr r µ ? η ? ν ? a � ψl h ψr b 4 the coalgebra view of graph structures in the context of the algebraic approach to graph transformation, graph structures have traditionally been presented as unary algebras [löw90, cmr+97]. however, as such they are the intersection between algebras and coalgebras, and in [kah14], we showed how more general coalgebras are useful in modelling graph features. recall: given a (unary) functor f, • an f-algebra a =(ca,fa) is an object ca together with a morphism fa ∶ f ca→ca • an f-coalgebra a =(ca,fa) is an object ca together with a morphism fa ∶ ca→f ca. whereas non-unary algebras allow structured types for the arguments of their operations, nonunary coalgebras allow structured types for their results. also, while in practical algebras, the shape of the arguments can typically be described by a polynomial functor, more general functors are routinely considered for the shape of the results in coalgebras. in the signatures for such coalgebras, we therefore allow additional syntax for such functors, like list, with fixed interpretation, just like the product functor × that is used for the argument shapes of non-unary algebras. in general, we assume a language of functor symbols (with arity), and a signature introduces first, after “sorts:”, a list of sort symbols, and then, after “ops:”, a list of function symbols (or operation symbols), and for each operation symbol, an argument type expression and a result type expression (separated by “→”) each built from the functor symbols and the sort symbols. • an algebraic signature has only single sort symbols as result types. • an coalgebraic signature has only single sort symbols as argument types. for example, the following is a coalgebraic signature for directed hypergraphs where each hyperedge has a sequence of source nodes and a sequence of target nodes, and each node is labelled selected revised papers from gcm 2014 4 / 17 eceasst with an element of the constant set l: sigdhg ∶= ⟨ sorts: n,e ops: src ∶ e→list n trg ∶ e→list n nlab ∶ n→ l ⟩ the coalgebra functor corresponding to sigdhg is a functor between product categories because of the two sorts: fsigdhg (n , e) = (l , ((list n)×(list n))) since in algebras, all operations must have a sort as result, modelling labelled graphs as algebras always has to employ the trick of declaring the label sets as additional sorts, and then consider the subcategory that has algebras with a fixed choice for these label sets, and morphisms that map them only with the identity. similarly, list-valued source and target functions are frequently considered for algebraic graph transformation, but with ad-hoc definitions for morphisms and custom proofs of their properties. in contrast, declaring these features via a coalgebra signature such as sigdhg directly captures the mathematical intent. 5 attributed graphs as coalgebras the expressive power of coalgebraic signatures extends to attributed graphs without any effort. for example, the following is a coalgebraic signature for edge-labelled (with label set l) and node-attributed graphs, with symbolic attributes taken from the term algebra over some term signature σ and with variables from the variable carrier set for sort v: sigsnagς ∶= ⟨ sorts: n,e,v ops: src ∶ e→n trg ∶ e→n lab ∶ e→l attr ∶ n→tς v ⟩ the resulting homomorphism concept only allows renaming of variables: fact 5.1 a sigsnagς-coalgebra homomorphism f ∶ g1 → g2 consists of three mappings fn ∶ n1 →n2 and fe ∶ e1 →e2 and fv ∶ v1 →v2 satisfying the following conditions: fe ., src2 = src1 ., fn fe ., lab2 = lab1 fe ., trg2 = trg1 ., fn fn ., attr2 = attr1 .,tς fv dpo rewriting in this category would have to rely on deletion and re-creation of attribute carrying nodes to implement relabelling, similar to [lkw93, kk08]. in addition we also lack the ability to instantiate rules via variable substitution as part of the morphism concept, and might therefore be tempted to add such instantiation outside the dpo rewriting framework, as in [ps04]. 5 / 17 volume 71 (2015) graph transformation with symbolic attributes via monadic coalgebra homomorphisms the homomorphism concept for sigsnagς-coalgebras can be “fixed” to allow substitution, by also adapting the morphism conditions to take the substituted variables inside the image terms of the attribution function into account: definition 5.2 we define the category snagς to have sigsnagς-coalgebras as objects, and a morphism f ∶ g1 → g2 consists of three mappings typed as shown to the left, satisfying the conditions shown to the right: fn ∶ n1 →n2 fe ∶ e1 →e2 fv ∶ v1 →tς v2 fe ., src2 = src1 ., fn fe ., lab2 = lab1 fe ., trg2 = trg1 ., fn fn ., attr2 = attr1 # fv note that fv is now a morphism in the kleisli category of the term monad tς, and accordingly the homomorphism condition for fv employs kleisli composition #. it is not hard to verify that this category is well-defined — the key to the proof is to recognise that the fv components are substitutions and compose via kleisli composition of the term monad. 6 monadic product coalgebras in [kah14], we introduced the concept of “monadic product coalgebras” as abstract setting for graph structures with substituting homomorphisms, which distinguishes “graph item sorts” from “variable sorts” by setting the formalisation in the product category c1 ×c2, assuming: • two categories c1 and c2, • a monad m on c2, • a functor f from c1 ×c2 to c1. in terms of coalgebraic signatures, this implements the restriction that sorts mentioned as monad arguments do not occur as source sorts of operators, and that the monad must not depend on sorts that do occur as source sorts of operators. this restriction is satisfied by all simple kinds of symbolically attributed graphs where the monad is typically a term monad, is applied only to sets of free variables, and these variables do not otherwise participate in the graph structure. definition 6.1 ([kah14]) an m-f-product-coalgebra a is a triple (a1,a2,opa) consisting of • an object a1 of c1, and • an object a2 of c2, and • a morphism opa ∶ a1 →f (a1, m a2) a m-f-product-coalgebra homomorphism f from (a1,a2,opa) to (b1,b2,opb) is a pair (f1,f2) consisting of a c1-morphism f1 from a1 to b1 and a morphism f2 from a2 to b2 in the kleisli category of m such that f1 ., opb = opa .,f (f1, mf2 ., join) . morphism composition is composition of the corresponding product category. selected revised papers from gcm 2014 6 / 17 eceasst this morphism composition is well-defined, and induces a category. if we let m0 be the product monad of the identity monad on c1 and m, then we see that m-f-product-coalgebra homomorphism are in fact morphisms of the kleisli category km0 , and also use its composition. if we further define f0 as endofunctor on c1 ×c2 by f0(x1,x2)= (f(x1,x2),1l), then an mf-product-coalgebra is indeed a (f0 ○m0)-coalgebra. (this factorisation is further explored in [kah14], and is too general for pushout creation). example 6.2 the category snagς of def. 5.2 is equivalent to the category of tς-fsigsnagproduct-coalgebras, where c1 = set × set for nodes and edges, c2 = set for variables (or terms), and fsigsnag ((n,e),t)=(t,(n ×n ×l)) . the four constituents of the result type of fsigsnag correspond to the four operators attr, src, trg, and lab of sigsnag, with attr being the first constituent, since it is the only operator starting from sort n, while the remaining three all start from sort e. since m0 is a product monad, pushouts in km0 are calculated component-wise, that is, they consist of a pushout in c1 and a pushout in the kleisli category of m, and we have: theorem 6.3 ([kah14]) the forgetful functor from the category of m-f-product-coalgebra homomorphisms to the kleisli category of m0 creates pushouts. more explicitly, if a span b f� a g-c of m-f-product-coalgebra homomorphisms is given, and also a cospan (b1,b2) h-(d1,d2) k� (c1,c2) in km0 that is a pushout for the kleisli morphisms underlying f and g, then (d1,d2) can be extended to a m-f-product-coalgebra d =(d1,d2,opd) such that b h-d k� c is a pushout for b f� a g-c in the m-f-productcoalgebra category. together with the equivalence of categories of example 6.2, pushouts for node-attributed graphs essentially reduce to unification for their variable components (due to the fact that set as underlying category has pushouts): corollary 6.4 a span b f� a g-c in the category snagς of node-attributed graphs (as sigsnagς structures) has a pushout if fv and gv, as substitutions, have a pushout. 7 dpo transformation with substituting homomorphisms most dpo approaches to attributed graph transformation insist that the “data algebra” supplying the attribute values remains unchanged by transformation. in contrast, our approach has the data algebra generated by a monad from selected carrier sets — most typically, the data algebra is the term algebra of the variable carrier set. and since variables are just elements of one of the carrier sets, adding and deleting variables is as easy as adding and deleting nodes and edges. for the sake of readability, we limit the discussion in this section to the symbolically attributed graphs of sect. 5, but it obviously applies to arbitrary m-f-product-coalgebra categories. 7 / 17 volume 71 (2015) graph transformation with symbolic attributes via monadic coalgebra homomorphisms for rewriting of symbolically attributed graphs, we organise the variable set vg of the gluing graph as a coproduct vg = tg +rg of • the set tg of transfer variables, and • the set rg of replacement variables. we demand that • the graph parts (node and edge components) of the rule morphisms are injective, • the rule morphisms map transfer variables injectively to variables, • all replacement variables occur in attributes of gluing graph items. a (rule) morphism satisfying these conditions is called rigid. for human-oriented presentation, and for simplifying the technical arguments below, the transfer-variable parts of the rule morphisms, namely ϕl,t ∶ tg →tς vl and ϕr,t ∶ tg →tς vr, will be subset inclusions, with tg = vl ∩vr. in the following example drawings, we explicitly list the variable set for each graph, and the variable component (substitution) for each homomorphism. f g x y y + d x−d r1 r2 x 7→ x y 7→ y r1 7→ x r2 7→ y x 7→ x y 7→ y r1 7→ y + d r2 7→ x−d {x, y, r1, r2}{x, y} {x, y, d} ϕl ϕrl g r in the rule drawn above, the transfer variables are x, and y, and the replacement variables are r1 and r2; the latter are mapped to different terms on the two rule sides, thus implementing “reattribution”. furthermore, variable d is “added by the rhs”; if the host graph h had already contained a variable d, then the d of the rhs would have been mapped to some fresh variable in the result graph b. note that ϕl is not a monomorphism in the category snagς of def. 5.2: consider a graph z with empty node and edge sets and with variable set {z}, and homomorphisms • λ1 ∶ z → g with λ1,v(z)= x and • λ2 ∶ z → g with λ2,v(z)= r1, then λ1 # ϕl = λ2 # ϕl, but λ1 ≠ λ2. (the homomorphism ϕr “accidentally” happens to be a monomorphism, but it would not be one if, e.g., “x − d ” had been replaced with “x − 1”. see appendix a for more information about monomorphisms in categories of substitutions.) selected revised papers from gcm 2014 8 / 17 eceasst although the replacement variables in the example above correspond to undefined labelling in, e.g., [hp12], this is not their only possible use; replacement variables can also occur deeper in the term structure of graph item attributes. this could be used for example to emulate multiple attributes via record-valued single attributes, and then replacing selected attributes could employ gluing nodes with attributes like “pair(x,r1)” or even “⟨a1 ↦ x,a2 ↦ r1,a3 ↦ 3 ⋅r2⟩”. existence of a pushout complement in the category snagς requires, besides the conventional gluing condition for the graph part, the following additional clause for the attribution part: definition 7.1 (variable gluing condition) each deleted variable (i.e., each variable in vl −vg) is mapped by the matching µ to a variable in a that does not occur in attributes outside the image of the deleted part of l (which is the “dangling” aspect), and also does not occur in the result of µv for any other variable (which is the “identification” aspect). since variable deletion is probably a relatively rarely-useful operation, we show an example redex and dpo transformation step not involving variable deletion on the left-hand side, and therefore trivially satisfying the variable gluing condition (we do not indicate the obvious node and edge mappings for the application span a� h -b): x 7→ a + b y 7→ 2 · b f a + b 2 · b {a, b, c} a f a · c x 7→ a + b y 7→ 2 · b r1 7→ r1 r2 7→ r2 r1 r2 {a, b, c, r1, r2} f a · c x 7→ a + b y 7→ 2 · b d 7→ d g 2 · b + d a + b−d {a, b, c, d} b f a · c h x 7→ x y 7→ y r1 7→ y + d r2 7→ x−d ϕr a 7→ a b 7→ b c 7→ c r1 7→ 2 · b + d r2 7→ a + b−d x 7→ x y 7→ y r1 7→ x r2 7→ y ϕl a 7→ a b 7→ b c 7→ c r1 7→ a + b r2 7→ 2 · b r1 r2 {x, y, r1, r2} g g y + d x−d {x, y, d} r µ η ν f x y {x, y} l ψl ψr recall that µv is a function of type vl →tς va, that is, a substitution that maps variables from vl to terms over va. we will apply it to terms t ∶tς vl using the notation µv ▹ t introduced in sect. 3. the pushout complement, consisting of the host graph h and the morphisms η and ψl, is 9 / 17 volume 71 (2015) graph transformation with symbolic attributes via monadic coalgebra homomorphisms obtained via the following steps: • the graph part (nodes and edges) is constructed as the pushout complement of the graph part of g ϕl-l µ-a. • we then calculate a least unifier γ ∶ rg →tς rg that simultaneously unifies (without instantiating any variables of a) all pairs ( µv ▹(attrg(n1)), µv ▹(attrg(n2))) for different preimages n1 ≠ n2 ∈ ng of nodes identified by µ , that is, with µn(ϕl,n(n1))= µn(ϕl,n(n2)). such a least unifier exists since the matching µ proves unifiability. • the variable set vh is the disjoint union of the preserved variables of a, that is, vp ∶= va − µv(vl −vg), with the replacement variables of rg that occur in the range of γ . (variables that have been unified away must be removed.) • for the attribution function, we then define (note that γ and µv replace disjoint sets of variables): attrh(n)={ γ (µv ▹(attrg(m))) if n = ηn(m) with m ∈ ng attra(ψl,n(n)) if ψl,n(n)∉ µn(nl) • the substitution ηv is the identity on replacement variables, and coincides with µv on transfer variables. • the substitution ψl,v is the identity on preserved variables, and coincides with ϕl,v # µv on replacement variables. commutativity ηv # ψl,v = ϕl,v # µv is then trivial; the attribute preservation properties ηn ., attrh = attrg # ηv and ψl,n ., attra = attrh # ψl,v are trivial when γ is trivial (that is, when µn does not identify any nodes), and in general require careful analysis for the different variable sets. the variable gluing condition (def. 7.1) is essential to show the universality property of the cospan l µ-a ψl� h; altogether we obtain: theorem 7.2 (existence and uniqueness of the pushout-complement) for g ϕl-l µ-a in the category snag, if ϕl is a rigid morphism, then a pushout complement g η-h ψl-a exists iff the extended gluing condition is satisfied. if a pushout complement exists, it is unique up to isomorphism. selected revised papers from gcm 2014 10 / 17 eceasst since the category snag does not have all pushouts, the right-hand side of a rule might contribute additional application conditions. now we define a snag-transformation rule to be a span l ϕl� g ϕr-r of rigid snag-homomorphisms. with that restriction, it is easy to see that right-hand side pushouts always exist at least if the matching µ does not identify any nodes. in the case of node identification via µ , the extended gluing condition is only sufficient for construction and well-definedness of the pushout complement; for the construction of the result graph, the following additional condition is necessary: definition 7.3 (attribute identification condition) there is a unifier δ ∶ vr →tς vr that simultaneously unifies all pairs ( µv ▹(attrr(ϕr,n(n1))), µv ▹(attrr(ϕr,n(n2)))) for different preimages n1 ≠ n2 ∈ ng of nodes identified by µ , that is, with µn(ϕl,n(n1)) = µn(ϕl,n(n2)). theorem 7.4 (existence of direct derivation) for a µ� l ϕl� g ϕr-r in the category snag, if ϕl and ϕr are rigid morphisms and the attribute identification condition is satisfied in addition to the gluing condition for g ϕl-l µ-a, then the usual double-pushout diagram for a direct derivation from a via the rule l ϕl� g ϕr-r and the matching µ can be constructed. 8 comparison with attributed graph transformation in the adhesive approach in the adhesive hlr approach to attributed graph transformation, presented in detail in [eept06, chapters 8–12], each attributed graph contains its own σ-algebra for attribute values. attributes are associated with graph items (nodes or edges) through special “attribute edges” that have a graph item as source and an attribute value as target. this has the advantage that the source of a matching needs to have only those attributes defined that are relevant for the matching, but also has the disadvantage that “attribute names” require separate mechanisms for distinguishing attributes belonging to different names (achieved via “typing”, i.e., move to a slice category, in [eept06, def. 8.7]), for enforcing existence (achieved via “constraints” in [eept06, section 12.1]), and for enforcing uniqueness (apparently requiring tuning a global parameter of the “constraint” mechanism, see [eept06, example 12.2]). for the implementation agg, [eept06, p. 308] mentions that “agg allows neither graphs which are only partially attributed, nor several values for one type. this restriction is natural, [...]. in the theory, this restriction can be expressed by adding [...] constraints [...]”. we agree that “this restriction is natural”, and we consider coalgebras a far more natural way to incorporate this restriction into the theory of attributed graphs: any number of attribution operators can be added to a coalgebraic signature, each of these is then necessarily interpreted (implemented) as a (conceptually separate) total function in all coalgebras for that signature. the typed attributed graph transformation rules of [eept06, chapter 9] are restricted to a “term algebra with variables” for attributes, and the choice of class m implies that all three graphs of a rule l� g -r share the same term algebra. therefore, “[the] definition of the 11 / 17 volume 71 (2015) graph transformation with symbolic attributes via monadic coalgebra homomorphisms match [l → a] already requires an assignment for all variables” [eept06, p. 183], including those that one might otherwise consider as “introduced in the rhs”. the fact that all horizontal morphisms are restricted to isomorphisms on the value algebra implies that that algebra cannot be modified by transformations. in particular, if the application graph contains a term algebra, it is not possible to add or delete variables. 9 conclusion and outlook the theory of coalgebras, where operations map carrier set elements to arbitrary types constructed via functors from all carrier sets, provides inherent flexibility for modelling of graph structures that is sorely missing from the theory of unary algebras traditionally employed for this purpose in the “algebraic” approach to graph transformation. in particular, coalgebras can model attributed graph structures effortlessly. in contrast, the non-unary value algebras needed for practical applications of attribution form an alien element in the traditional unary algebras modelling graph structures, and therefore require complex auxiliary constructions to properly capture even the simple fact that attribution is a total function from (e.g.) nodes to attribute values, as explained in the previous section. while the traditional approach handles substitution (typically as a special case of evaluation) via algebra homomorphisms, we use the approach of [kah14] to handle substitution via kleisli composition, by factoring the coalgebra functor over an appropriate monad. in the current paper, we restricted our attention to the term monad, and therefore only considered symbolic attribution with terms in more detail; due to the fact that the set of variables is one of the carrier sets of our coalgebras, adding and deleting variables via dpo transformations is essentially as easy as adding and deleting nodes or edges. because of this possibility of adding variables via transformation steps, we obtain a symbolic rewriting system that is closer in spirit to that of [ol10a] than to the point of view of [eept06], where additional variables in the rhs need to be instantiated as part of the rule application (and indeed already as part of the matching, for technical reasons). even though the kleisli category of the term monad does not have all pushouts (since not all terms are unifiable), we still managed to obtain a rule concept with an application condition that is an only slightly strengthened gluing condition, and that guarantees that a dpo rewriting step can be constructed. interestingly, the rule sides, although injective on their graph parts, are not monomorphisms in our coalgebra category, so none of the current m-adhesive, wadhesive [gol12], or m,n-adhesive [hp12] approaches is directly applicable. the general approach of e.g., [gol12], should however still be applicable to dpo rewriting in categories of monadic product coalgebras — the concrete instance of a w-adhesive category of attributed graphs presented in [gol12] (implicitly) uses, for enabling attribute change, a partiality monad, which, like the term monad, is a “guarded monad” [gld05]; we conjecture that guarded monads might be used to unify the two approaches. for future work, we therefore hope to identify an appropriate variant of the adhesive hlr approaches that does not require monomorphisms for the rule sides, and still supports typical hlr results. the fully abstract generalisation of the results of sect. 7 to arbitrary m-f-productselected revised papers from gcm 2014 12 / 17 eceasst coalgebra categories will then require monads with membership [fhm93] for the gluing condition. besides the dpo-based hlr approaches, we also plan to investigate applying to monadic product coalgebras for example also the sesqui-pushout (sqpo) approach of [chhk06], which is aplied to attributed graph transformation in [depr14]. while the approach of sect. 7 can only delete variables that are matched to variables, sesqui-pushout rewriting should give us more flexibility there. it may even be advantageous to explore applying the fibred apprach to rewriting [kah97], as this provies a principled approach to distinguish the different ways substitution and/or partiality are employed in the horizontal versus the vertical arrows of “double-square rewriting”. we also plan to investigate moving from term algebras to more general algebras as target types for attributions. bibliography [bkl+91] m. bidoit, h.-j. kreowski, p. lescanne, f. orejas, d. sanella (eds.). algebraic system specification and devalopment — a survey and annotated bibliography. lncs 501. springer, 1991. [bm97] r. s. bird, o. de moor. algebra of programming. international series in computer science 100. prentice hall, 1997. [bm04] m. bidoit, p. d. mosses. casl user manual. lncs (ifip series) 2900. springer, 2004. with chapters by t. mossakowski, d. sannella, and a. tarlecki. http://link.springer.de/link/service/series/0558/tocs/t2900.htm [cekr02] a. corradini, h. ehrig, h. kreowski, g. rozenberg (eds.). proc. first international conference on graph transformation, icgt 2002. lncs 2505. 2002. doi:10.1007/3-540-45832-8 [chhk06] a. corradini, t. heindel, f. hermann, b. knig. sesqui-pushout rewriting. in corradini et al. (eds.), graph transformations. lncs 4178, pp. 30–45. springer berlin heidelberg, 2006. doi:10.1007/11841883 4 http://dx.doi.org/10.1007/11841883 4 [cmr+97] a. corradini, u. montanari, f. rossi, h. ehrig, r. heckel, m. löwe. algebraic approaches to graph transformation, part i: basic concepts and double pushout approach. chapter 3, pp. 163–245 in [roz97]. [depr14] d. duval, r. echahed, f. prost, l. ribeiro. transformation of attributed structures with cloning. in gnesi and rensink (eds.), fundamental approaches to software engineering. lncs 8411, pp. 310–324. springer berlin heidelberg, 2014. doi:10.1007/978-3-642-54804-8 22 13 / 17 volume 71 (2015) http://link.springer.de/link/service/series/0558/tocs/t2900.htm http://dx.doi.org/10.1007/3-540-45832-8 http://dx.doi.org/10.1007/11841883_4 http://dx.doi.org/10.1007/11841883_4 http://dx.doi.org/10.1007/978-3-642-54804-8_22 graph transformation with symbolic attributes via monadic coalgebra homomorphisms [eekr12] h. ehrig, g. engels, h.-j. kreowski, g. rozenberg (eds.). proc. sixth international conference on graph transformation, icgt 2012. lncs 7562. springer, 2012. [eept06] h. ehrig, k. ehrig, u. prange, g. taentzer. fundamentals of algebraic graph transformation. springer, 2006. [ehk+97] h. ehrig, r. heckel, m. korff, m. löwe, l. ribeiro, a. wagner, a. corradini. algebraic approaches to graph transformation, part ii: single pushout approach and comparison with double pushout approach. chapter 4, pp. 247–312 in [roz97]. [em85] h. ehrig, b. mahr. fundamentals of algebraic specification 1: equations and initial semantics. springer, 1985. [ept04] h. ehrig, u. prange, g. taentzer. fundamental theory for typed attributed graph transformation. pp. 161–177 in [pbe04]. doi:10.1007/b100934 [fhm93] p. freyd, p. hoogendijk, o. de moor. membership of datatypes. dec. 1993. unpublished manuscript, see also [bm97, sect. 6.5]. [gld05] n. ghani, c. lüth, f. de marchi. monads of coalgebras: rational terms and term graphs. mathematical structures in computer science 15:433–451, 2005. doi:10.1017/s0960129505004743 [gol12] u. golas. a general attribution concept for models in m-adhesive transformation systems. pp. 187–202 in [eekr12]. doi:10.1007/978-3-642-33654-6 13 [hag87] t. hagino. a categorical programming language. phd thesis, edinburgh university, 1987. [hkt02] r. heckel, j. m. küster, g. taentzer. confluence of typed attributed graph transformation systems. pp. 161–176 in [cekr02]. doi:10.1007/3-540-45832-8 14 [hp02] a. habel, d. plump. relabelling in graph transformation. pp. 135–147 in [cekr02]. doi:10.1007/3-540-45832-8 12 [hp12] a. habel, d. plump. m,n-adhesive transformation systems. pp. 218–233 in [eekr12]. doi:10.1007/978-3-642-33654-6 15 [kah97] w. kahl. a fibred approach to rewriting — how the duality between adding and deleting cooperates with the difference between matching and rewriting. technical report 9702, fakultät für informatik, universität der bundeswehr münchen, may 1997. http://www.cas.mcmaster.ca/∼kahl/publications/tr/kahl-1997b.html. http://www.cas.mcmaster.ca/∼kahl/publications/tr/kahl-1997b.html selected revised papers from gcm 2014 14 / 17 http://dx.doi.org/10.1007/b100934 http://dx.doi.org/10.1017/s0960129505004743 http://dx.doi.org/10.1007/978-3-642-33654-6_13 http://dx.doi.org/10.1007/3-540-45832-8_14 http://dx.doi.org/10.1007/3-540-45832-8_12 http://dx.doi.org/10.1007/978-3-642-33654-6_15 http://www.cas.mcmaster.ca/~kahl/publications/tr/kahl-1997b.html http://www.cas.mcmaster.ca/~kahl/publications/tr/kahl-1997b.html eceasst [kah14] w. kahl. categories of coalgebras with monadic homomorphisms. in bonsangue (ed.), coalgebraic methods in computer science, cmcs 2014. lncs 8446, pp. 151–167. springer, 2014. agda theories available via http://relmics.mcmaster. ca/rath-agda/. doi:10.1007/978-3-662-44124-4 9 [kh02] a. kurz, r. hennicker. on institutions for modular coalgebraic specifications. theoretical computer science 280(1–2):69–103, 2002. doi:10.1016/s0304-3975(01)00021-4 [kk08] b. könig, v. kozioura. towards the verification of attributed graph transformation systems. in ehrig et al. (eds.), 4th intl. conf. on graph transformations, icgt 2008. lncs 5214, pp. 305–320. 2008. doi:10.1007/978-3-540-87405-8 21 [lkw93] m. löwe, m. korff, a. wagner. an algebraic framework for the transformation of attributed graphs. in sleep et al. (eds.), term graph rewriting: theory and practice. pp. 185–199. wiley, 1993. [löw90] m. löwe. algebraic approach to graph transformation based on single pushout derivations. technical report 90/05, tu berlin, 1990. [ol10a] f. orejas, l. lambers. delaying constraint solving in symbolic graph transformation. in ehrig et al. (eds.), fifth intl. conf. on graph transformation, icgt 2010. lncs 6372, pp. 43–58. sept. 2010. doi:10.1007/978-3-642-15928-2 4 [ol10b] f. orejas, l. lambers. symbolic attributed graphs for attributed graph transformation. eceasst 30(graph and model transformation 2010):2.1–2.25, 2010. [ore11] f. orejas. symbolic graphs for attributed graph constraints. j. symbolic comput. 46(3):294–315, mar. 2011. doi:10.1016/j.jsc.2010.09.009 [pbe04] f. parisi-presicce, p. bottoni, g. engels (eds.). proc. second international conference on graph transformation, icgt 2004. lncs 3256. 2004. doi:10.1007/b100934 [plu09] d. plump. the graph programming language gp. in algebraic informatics, cai 2009. lncs 5725, pp. 99–122. 2009. doi:0.1007/978-3-642-03564-7 6 [ps04] d. plump, s. steinert. towards graph programs for graph algorithms. pp. 128–143 in [pbe04]. doi:10.1007/978-3-540-30203-2 11 [pz01] e. poll, j. zwanenburg. from algebras and coalgebras to dialgebras. entcs 44(1):289–307, 2001. doi:10.1016/s1571-0661(04)80915-0 15 / 17 volume 71 (2015) http://relmics.mcmaster.ca/rath-agda/ http://relmics.mcmaster.ca/rath-agda/ http://dx.doi.org/10.1007/978-3-662-44124-4_9 http://dx.doi.org/10.1016/s0304-3975(01)00021-4 http://dx.doi.org/10.1007/978-3-540-87405-8_21 http://dx.doi.org/10.1007/978-3-642-15928-2_4 http://dx.doi.org/10.1016/j.jsc.2010.09.009 http://dx.doi.org/10.1007/b100934 http://dx.doi.org/0.1007/978-3-642-03564-7_6 http://dx.doi.org/10.1007/978-3-540-30203-2_11 http://dx.doi.org/10.1016/s1571-0661(04)80915-0 graph transformation with symbolic attributes via monadic coalgebra homomorphisms [rfs08] m. rebout, l. féraud, s. soloviev. a unified categorical approach for attributed graph rewriting. in hirsch et al. (eds.), computer science — theory and applications, csr 2008. lncs 5010, pp. 398–409. springer, 2008. doi:10.1007/978-3-540-79709-8 39 [roz97] g. rozenberg (ed.). handbook of graph grammars and computing by graph transformation, vol. 1: foundations. world scientific, singapore, 1997. [rut00] j. j. rutten. universal coalgebra: a theory of systems. theoretical computer science 249(1):3–80, 2000. doi:10.1016/s0304-3975(00)00056-6 a monomorphisms in substitution categories let tς denote the term functor for signature σ, that is, tς x is the set of σ-terms with elements of set x as variables. let fv(t) denote the set of (free) variables occurring in term t. tς is an endofunctor on the category set, and naturally extends to a monad (see sect. 3), the term monad. its “join” natural transformation, join tς , produces for each set a (of variables) the function join tς,a ∶tς (tς a)→tς a which “flattens” nested terms over variables in a (that is, terms over tς a as their set of variables). substitutions, that is, functions x →tς y , are morphisms in the kleisli category of the term monad tς, and therefore compose via kleisli composition, which is defined for arbitrary substitutions f ∶ x →tς y and g ∶ y →tς z as follows: f # g = f .,tς g ., jointς,z conventionally, this would be described via “application” of substitutions to terms — since we write f ▹t for the application of substitution f ∶ x →tς y to term t ∶tς x, the composition f # g can defined by (f # g)(v)= f ▹(g(v)) , for all v ∶ x. when starting from the monadic setting, application of substitutions can be defined as follows: f ▹t =((tς f) ., joiny)(t) monomorphisms in any monad, if the “return” natural transformation produces monomorphisms (which it does for tς), then monomorphisms in the kleisli category of this monad are also monomorphisms in the underlying category. monomorphisms f of the underlying category that are preserved by the monad functor give rise to monomorphisms f ., return in the kleisli category. the term functor preserves all monomorphisms: an injective variable mapping f ∶ v1 → v2 gives rise to an injective term mapping tς f ∶tς v1 →tς v2 that only renames variables. the resulting substitution f ., return ∶ v1 →tς v2 is an injective variable renaming, which is therefore a mono in the category of substitutions, too — this also can easily be seen directly. the category of substitutions has pushouts along such variable renamings; these pushouts implement name-clash-avoiding extension of the domain of substitutions. selected revised papers from gcm 2014 16 / 17 http://dx.doi.org/10.1007/978-3-540-79709-8_39 http://dx.doi.org/10.1016/s0304-3975(00)00056-6 eceasst for σ , being a monomorphism in the category of substitutions exactly means that substitution application of σ does not unify any two different terms. that is, σ is a monomorphism in the category of substitutions iff for any two terms t1 and t2 we have σ ▹t1 = σ ▹t2 implies t1 = t2 . from this, it is easy to see that monomorphisms in the category of substitutions cannot map any variables to ground terms. however, this condition is not easy to check directly. fortunately a much simpler condition is (necessary and) sufficient: we can show that monomorphisms in the kleisli category of the term monad are those substitutions that do not identify variables with different terms: theorem a.1 a substitution σ ∶ v1 →tς v2 is a monomorphism in the category of substitutions iff for every variable v ∶ v1 and every term t ∶tς v1, we have: σ v = σ ▹t implies v = t . proof. “⇒” follows directly by applying the monomorphism property to the two terms v and t. “⇐”: assume that σ satisfies the given condition. to show that σ is a monomorphism in the category of substitutions it suffices to show that for any two terms t,u ∶tς v1 with σ ▹ t = σ ▹ u, we have t = u. since this is actually equivalent to restricting v0 to a one-element set, it suffices to show that for all terms t1,t2 ∶tς v1 with σ ▹t1 = σ ▹t2 we have t1 = t2. • if t = v is a variable, then σ v = σ ▹ t = σ ▹ u, from which the given property yields v = u. (the case where u is a variable is analogous.) • if t = f(t1,...tn) and u = g(u1,...un), then σ ▹t = σ ▹u implies f = g and σ ▹ti = σ ▹ui, from which the induction hypothesis yields ti = ui for all i, implying t = u. for finite substitutions, this condition directly translates into a decision procedure that for each variable v ∶ v1 checks whether for any different variable u ∶ v1, its image σ u occurs as a subterm in σ v. 17 / 17 volume 71 (2015) introduction related work notation and background: categories and monads the coalgebra view of graph structures attributed graphs as coalgebras monadic product coalgebras dpo transformation with substituting homomorphisms comparison with attributed graph transformation in the adhesive approach conclusion and outlook monomorphisms in substitution categories richer interface automata with optimistic and pessimistic compatibilitythis research was supported by the dfg (german research foundation, grants lu 1748/3-1 and vo 615/12-1). electronic communications of the easst volume 66 (2013) proceedings of the automated verification of critical systems (avocs 2013) richer interface automata with optimistic and pessimistic compatibility gerald lüttgen and walter vogler 15 pages guest editors: steve schneider, helen treharne managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst richer interface automata with optimistic and pessimistic compatibility∗ gerald lüttgen1 and walter vogler2 1 gerald.luettgen@swt-bamberg.de software technologies group university of bamberg, germany 2 vogler@informatik.uni-augsburg.de institute for computer science university of augsburg, germany abstract: modal transition systems are a popular semantic underpinning of interface theories, such as nyman et al.’s iomts and bauer et al.’s mio, which facilitate component-based reasoning of concurrent systems. our interface theory mia repaired a compositional flaw of iomts-refinement and introduced a conjunction operator. in this paper, we first modify mia to properly deal with internal computations including internal must-transitions, which were largely ignored already in iomts. we then study a mia variant that adopts mio’s pessimistic – rather than iomts’ optimistic – view on component compatibility and define, for the first-time in a pessimistic, non-deterministic setting, conjunction and disjunction on interfaces. for the pessimistic mia variant we also provide a mechanism for extending alphabets when refining interfaces, which is a desired feature in practice. we illustrate our advancements via a small example. keywords: interface theory, modal transitions system, modal interface automata, optimistic and pessmimistic view, interface refinement, alphabet extension. 1 introduction interface theories [bmsh10, lnw07, lv13, rbb+11] are a key technology for the componentbased design of critical systems and are applied, e.g., for specifying web services [bchs07] and software contracts [bdh+12]. many interface theories are inspired by de alfaro and henzinger’s interface automata (ia) [dh05] which employs transition systems with input and output actions and alternating simulation for refinement. it is distinguished from classic process algebras by its parallel composition operator: an interface cannot block an incoming input in any state but, if an input arrives unexpectedly, this is treated as error, i.e., as an incompatibility. ia suffers from the fact that outputs cannot be required since any interface may be implemented by a component that accepts all inputs and does not engage in any output, hence avoiding errors altogether. this is undesired in practice and has led researchers to base interface theories on modal transition ∗ this research was supported by the dfg (german research foundation, grants lu 1748/3-1 and vo 615/12-1). 1 / 15 volume 66 (2013) mailto:gerald.luettgen@swt-bamberg.de mailto:vogler@informatik.uni-augsburg.de richer interface automata systems (mts) [lar90]; these distinguish between mustand may-transitions and thus allow one to enforce outputs via output must-transitions. in the light of errors that may arise when joining components in parallel, two schools on mts-based interface theories have emerged, which treat compatibility either optimistically or pessimistically. the pessimistic school of bauer et al. [bmsh10] only defines the composition of a restricted set of components; however, their mio setting employs standard modal refinement as refinement preorder and standard weak transitions for abstracting from internal computation. in contrast, the optimistic school of nyman et al. [lnw07] follows ia in that parallel composition is still defined in the presence of error states, if some concrete system environment may prohibit such states to be reached. their iomts setting is equipped with a customized preorder, which allows one to compose a much larger set of components than in mio. fatally, iomtsrefinement does not require the matching of internal must-transitions of implementations and is not at all permissive wrt. abstracting from internal computation. our interface theory modal interface automata (mia) [lv13] adopts iomts-refinement while repairing a compositional flaw regarding iomts parallel composition. it also adds conjunction on interfaces, which is a key operator allowing engineers to specify a concurrent system from different perspectives. this paper advances the state-of-the-art of both schools. regarding the optimistic mia setting, we first re-consider iomts-refinement so that it properly deals with internal computation including internal must-transitions (cf. sec. 2). along the way we also permit general, disjunctive must-transitions, thereby increasing expressiveness and enabling an intuitive definition of disjunction on interfaces. to the best of our knowledge, no existing work on disjunctive mts considers weak transitions. we then study a pessimistic variant of mia and define, for the firsttime in a pessimistic, non-deterministic setting, conjunction and disjunction on interfaces (cf. sec. 3). while bauer [bau12] and raclet et al. [rbb+11] also investigated conjunction, they did so only for deterministic interfaces not containing internal computation. extending alphabets is useful in practice, firstly, when composing partial specification interfaces to an overall interface conjunctively and, secondly, since implementors may decide to add extra features that are not covered by the specification interface (cf. [rbb+11]). we add such a mechanism for the pessimistic mia version and discuss the problems that arise with alphabet extension in the optimistic version. in summary, we achieve a richer interface theory than related work does. in mia, one may specify non-deterministic behaviour, enforce outputs, express disjunctive must-transitions, abstract from internal computation, interpret compatibility optimistically or pessimistically, compose interfaces also conjunctively and disjunctively, and (in the pessimistic version) extend alphabets. a small example dealing with a communication protocol illustrates our advancements (cf. sec. 3.4). 2 modal interface automata: the optimistic setting this section fixes a severe shortcoming of mia [lv13] that it inherited from iomts [lnw07], namely that the refinement preorder ignores the matching of must-transitions labelled with the internal action τ . the mia variant presented below also permits (in contrast to [lv13]) general disjunctive must-transitions, thus enabling a natural definition of disjunction on interfaces. proc. avocs 2013 2 / 15 eceasst definition 1 (modal interface automata) a modal interface automaton (mia) is a tuple (p, i, o,−→, 99k), where (i) p is the set of states, (ii) a =df i ∪o with i ∩o = /0 is the alphabet consisting of disjoint inputs and outputs, resp., and not containing the special, silent action τ , (iii) −→⊆ p ×(a ∪{τ})×(pfin(p)\ /0) is the must-transition relation (with pfin(p) being the set of finite subsets of p), (iv) 99k⊆ p ×(a ∪{τ})× p is the may-transition relation, such that the following conditions hold for all i ∈ i and α ∈ a ∪{τ}: (a) p i−→ p′ and p i−→ p′′ implies p′ = p′′ (input determinism), (b) p i 99k p′ implies ∃p′. p i−→ p′ and p′ ∈ p′ (input must), (c) p α−→ p′ implies ∀p′∈p′. p α 99k p′ (syntactic consistency). conds. (a)–(c) are adapted from the corresponding definition in [lv13]. input determinism is required for the mia-refinement preorder (see below) to be a precongruence for parallel composition and conjunction; this condition is already imposed by ia, but note that, here, an input must-transition is disjunctive, thus allowing nondeterminism within a transition. the input-must condition is natural in the presence of ia-inspired parallel composition: a may-input in an interface specification may simply be left out by a refining implementation, and thus increase the potential for errors rather than decrease it. finally, syntactic consistency is natural and inherited from modal transition systems [lar90]. in the sequel, we identify a mia (p, i, o,−→, 99k) with its state set p and, if needed, use index p when referring to one of its components, e.g., we write ip for i. similarly, we write, e.g., i1 instead of ip1 for mia p1. in addition, we let i, o, a, ω and α stand for representatives of the alphabets i, o, a, o ∪{τ} and a ∪{τ}, resp., write a = i/o when highlighting inputs i and outputs o in an alphabet a, and define â =df a and τ̂ =df ε (the empty word). in figures, we often refer to an action a as a?, if a ∈ i, and as a!, if a ∈ o, and omit the label of τ -transitions. musttransitions (may-transitions) are drawn using solid, possibly splitting arrows (dashed arrows); any depicted must-transition also implicitly represents the resp. may-transition(s). we now define weak mustand may-transition relations that abstract from transitions labelled by τ , as will be needed for mia-refinement. this is the first definition of this kind, which covers disjunctive must-transitions; it is quite subtle as can be seen in lemma 1 and fig. 2 below. definition 2 (weak transition relations) weak mustand weak may-transition relations −→−→ and 99k99k , resp., are defined as the smallest relations satisfying p ε −→−→{p}, p ε 99k99k p and the following conditions, where ω̂ ∈ o ∪{ε}: (a) p ω̂ −→−→p′, p′ ∈ p′ and p′ τ−→ p′′ implies p ω̂ −→−→(p′ \{p′})∪ p′′, 3 / 15 volume 66 (2013) richer interface automata (b) p ε −→−→p′ = {p1, . . . , pn} and ∀ j. p j o−→ pj, implies p o −→−→ ⋃n j=1 pj, (c) p ε 99k99k p ′′ τ99k p′ implies p ε 99k99k p ′, (d) p ε 99k99k p ′′ ω99k p′′′ ε 99k99k p ′ implies p ω 99k99k p ′. our refinement relation is adapted from [lnw07, lv13] and called mia-refinement: definition 3 (mia-refinement) let p, q be mias with common input and output alphabets. relation r ⊆ p × q is a mia-refinement relation if for all (p, q) ∈ r: (i) q i−→ q′ implies ∃p′. p i−→ p′ and ∀p′∈p′∃q′∈q′. (p′, q′) ∈ r, (ii) q ω−→ q′ implies ∃p′. p ω̂ −→−→p′ and ∀p′∈p′∃q′∈q′. (p′, q′) ∈ r, (iii) p ω 99k p′ implies ∃q′. q ω̂ 99k99k q ′ and (p′, q′) ∈ r. we write p @ ` q and say that p mia-refines q if there exists a mia-refinement relation r such that (p, q) ∈ r. it is easy to see that @ ` is the largest mia-refinement relation and a preorder, i.e., it is reflexive and transitive. the key difference to [lv13] is that our revised definition of mia above also allows τ -must-transitions that must be matched (cond. (ii), for ω = τ ). the reason why input musttransitions must be matched directly and not via a weak transition is due to the notion of mia parallel composition, which we adopt from ia [dh05] and explain below. the same comment applies to the fact that our relation is insensitive to the refining mia adding input-transitions, since input may-transitions are not considered in cond. (iv). 2.1 parallel composition we define a parallel composition operator | on mia in analogy to ia [dh05, lnw07] in two stages: first a standard product ⊗ between two mias is introduced, where common actions are synchronized and hidden. then, error states are identified, and all states are pruned from which reaching an error state is unavoidable in some implementation. definition 4 (parallel product) mias p1, p2 are composable if a1 ∩ a2 = (i1 ∩ o2)∪(o1 ∩ i2). for such mias we define the product p1 ⊗ p2 = (p1 × p2, i, o,−→, 99k), where i = (i1 ∪ i2) \ (o1 ∪ o2) and o = (o1 ∪ o2)\(i1 ∪ i2) and where −→ and 99k are defined as follows: (must1) (p1, p2) α−→ p′1 ×{p2} if p1 α−→ p′1 and α /∈ a2 (must2) (p1, p2) α−→ {p1}× p′2 if p2 α−→ p′2 and α /∈ a1 (must3) (p1, p2) τ−→ p′1 × p ′ 2 if p1 a−→ p′1 and p2 a−→ p′2 for some a (may1) (p1, p2) α 99k (p′1, p2) if p1 α 99k p′1 and α /∈ a2 (may2) (p1, p2) α 99k (p1, p′2) if p2 α 99k p′2 and α /∈ a1 (may3) (p1, p2) τ 99k (p′1, p ′ 2) if p1 a 99k p′1 and p2 a 99k p′2 for some a. proc. avocs 2013 4 / 15 eceasst figure 1: necessity of matching input-transitions strongly (left) and of ignoring input maytransitions when matching (right). the difference to the version of mia in [lv13] is that we now have τ -must-transitions; in particular, this has led us to introduce rule (must3). definition 5 (parallel composition) given a parallel product p1 ⊗ p2, a state (p1, p2) is an error state if there is some a ∈ a1 ∩ a2 such that (a) a ∈ o1, p1 a 99k and p2 6 a−→, or (b) a ∈ o2, p2 a 99k and p1 6 a−→. we define the set e ⊆ p1 ×p2 of incompatible states as the least set such that (p1, p2) ∈ e if (i) (p1, p2) is an error state or (ii) (p1, p2) ω 99k (p′1, p ′ 2) and (p ′ 1, p ′ 2) ∈ e. the parallel composition p1|p2 of p1 and p2 is now obtained from p1 ⊗ p2 by pruning, namely removing all states in e and every transition that involves such states as its source, its target or one of its targets; all may-transitions underlying a removed must-transition are deleted, too. if (p1, p2) ∈ p1|p2, we write p1|p2 and call p1 and p2 compatible. it is easy to see that parallel products and parallel compositions are well-defined mias and that the parallel composition operator is commutative and associative. in addition and as we will show below, mia-refinement is compositional wrt. parallel composition, i.e., @ ` is a precongruence. it is this desired property that requires us in def. 3 to match input must-transitions strongly and to ignore input may-transitions when matching. to see the former, consider fig. 1 (left) with input/output alphabets ap =df aq =df {i}/ /0 and ar =df /0/{i}. now, p should not refine q since q and r are compatible while p and r are not (because (p, r) is an error). therefore, one must not be able to match a transition i−→ by a transition sequence ( τ−→)+ i−→, unless the notion of error state originating from interface automata [dh05] is changed, as is done in [bmsh10]. to see the latter, observe that prescribing the matching of input may-transitions as in def. 3(iv) for output may-transitions would lead to a compositionality bug. for example, for the mias in fig. 1 (right) with alphabets ap =df {o}/ /0 and aq =df aq′ =df {i}/{o} we would have q′ @` q but p|q′ 6@ ` p|q would fail. theorem 1 (compositionality of parallel composition) let p1, p2, q be mias with p1 ∈ p1, p2 ∈ p2, q ∈ q and p1 @` q. assume that q and p2 are composable; then: (a) p1 and p2 are composable. (b) if q and p2 are compatible, then so are p1 and p2 and p1|p2 @` q|p2. the proof of this result requires a couple of auxiliary properties regarding the preservation of 5 / 15 volume 66 (2013) richer interface automata figure 2: example showing that set r in lemma 1 is not always the full set p′ × q′. composability and consistency under refinement, respectively, as well as the following property of weak must-transitions: lemma 1 (weak must-transitions) let p, q be composable mias. if p a −→−→p p ′ and q a−→q q′ for some action a ∈ (op ∩ iq)∪(ip ∩ oq), then (p, q) ε −→−→r in p ⊗ q with r ⊆ p′ × q′. fig. 2 shows that, in general, r 6= p′ × q′; here, 1 a! −→−→p {2, 3, 4, 5} and 0 a? −→−→q 0, but not 1|0 ε −→−→ {2, 3, 4, 5}×{0}. the sets r with maximal cardinality satisfying 1|0 ε −→−→r are {2, 4, 5}×{0} and {3, 4, 5}×{0}. 2.2 conjunction & disjunction conjunction on mia will be defined in two stages, similarly to parallel composition. state pairs can be logically inconsistent due to unsatisfiable must-transitions and are then removed incrementally in the second stage. definition 6 (conjunctive product) let (p, i, o,−→p, 99kp) and (q, i, o, −→q, 99kq) be mias with common input and output alphabets and disjoint state sets. the conjunctive product p&q =df ((p × q)∪ p ∪ q, i, o,−→, 99k) inherits the transitions of p and q and has additional transitions as follows: (omust1) (p, q) ω−→ {(p′, q′)| p′ ∈ p′, q ω̂ 99k99kq q ′} if p ω−→p p′ and q ω̂ 99k99kq (omust2) (p, q) ω−→ {(p′, q′)| p ω̂ 99k99kp p ′, q′ ∈ q′} if p ω̂ 99k99kp and q ω−→q q′ (imust1) (p, q) i−→ p′ if p i−→p p′ and q 6 i−→q (imust2) (p, q) i−→ q′ if p 6 i−→p and q i−→q q′ (imust3) (p, q) i−→ p′ × q′ if p i−→p p′ and q i−→q q′ (may1) (p, q) τ 99k (p′, q) if p τ 99k99kp p ′ (may2) (p, q) τ 99k (p, q′) if q τ 99k99kq q ′ (may3) (p, q) ω 99k (p′, q′) if p ω 99k99kp p ′ and q ω 99k99kq q ′ (imay1) (p, q) i 99k p′ if p i 99kp p′ and q 6 i 99kq (imay2) (p, q) i 99k q′ if p 6 i 99kp and q i 99kq q′ (imay3) (p, q) i 99k (p′, q′) if p i 99kp p′ and q i 99kq q′ observe that the conjunctive product is inherently different from the parallel product, as can be proc. avocs 2013 6 / 15 eceasst seen from some ‘unusual’ rules that define single transitions on the basis of weak transitions (rules (omust) and (may)) and synchronize on τ -transitions (rule (may3)). these will be justified by thm. 2 below. as an aside, note that we assume in the (omust) rules and in similar cases below, that the target set of the defined transition is finite. if one wishes to deal with infinite target sets in mia, one has to modify the definition of ε −→−→ by allowing the simultaneous replacement of several p′ by suitable p′ in def. 2(a); this would make the latter definition more complicated and lemma 1 superfluous. we now define a conjunction operator on mias that have the same input and output alphabets; relaxing this requirement will be discussed below. definition 7 (conjunction) given a conjunctive product p&q, the set f ⊆ p×q of (logically) inconsistent states is defined as the least set satisfying the following rules: (f1) p o−→p and q 6 o 99k99kq implies (p, q) ∈ f (f2) p 6 o 99k99kp and q o−→q implies (p, q) ∈ f (f3) (p, q) α−→ r′ and r′ ⊆ f implies (p, q) ∈ f the conjunction p ∧ q of mias p, q with common input and output alphabets is obtained by deleting all states (p, q) ∈ f from p&q. this also removes any mayor must-transition exiting a deleted state and any may-transition entering a deleted state; in addition, deleted states are removed from targets of disjunctive must-transitions. we write p∧q for state (p, q) of p∧q; all such states are defined – and consistent – by construction. operator ∧ indeed defines conjunction on mia, i.e., ∧ is the greatest lower bound wrt. @ ` : theorem 2 (∧ is and) let p and q be mias with the same alphabets and disjoint state sets. we have (i) (∃mia r and r ∈ r. r @ ` p and r @ ` q) iff p ∧ q is defined. further, in case p ∧ q is defined and for any mia r and r ∈ r: (ii) r @ ` p and r @ ` q iff r @ ` p ∧ q. in both statements, r is supposed to have the same alphabets as p and q. the theorem’s first part reflects the intuition that specifications p and q are logically inconsistent if they do not have a common implementation; formally, p∧q is undefined in this case. its proof demands us to reason about inconsistent states, for which we resort to a notion of witness: definition 8 (witness) a witness w of p&q is a subset of (p × q) ∪ p ∪ q such that the following conditions hold for all (p, q) ∈ w : (w1) p o−→p implies q o 99k99kq (w2) q o−→q implies p o 99k99kp (w3) (p, q) α−→ r′ implies r′ ∩w 6= /0 lemma 2 (concrete witness) let p&q be a conjunctive product of mias. then, for any witness w of p&q, we have (i) f ∩w = /0. moreover, (ii) the set w =df {(p, q) ∈ p×q | ∃mia r and r ∈ r. r @ ` p and r @ ` q}∪ p ∪ q is a witness of p&q. statement (ii) above is now the key for proving thm. 2. as a corollary to this theorem, one may 7 / 15 volume 66 (2013) richer interface automata obtain compositionality of mia-refinement wrt. conjunction: corollary 1 if p @ ` q and p ∧ r defined, then q ∧ r defined and p ∧ r @ ` q ∧ r. note that one cannot expect that definedness of q∧r implies that of p∧r, because specializing q to p might introduce an inconsistency. we now turn our attention to defining the dual disjunction operator ∨ on mia, which expresses the least upper bound property wrt. @ ` . the definition of disjunction may make use of the disjunctive must-transitions relation also for inputs and the internal action τ : definition 9 (disjunction) let (p, i, o,−→p, 99kp) and (q, i, o, −→q, 99kq) be mias with common input and output alphabets and disjoint state sets. the disjunction p ∨ q is defined by ({p ∨ q| p∈p, q∈q}∪ p ∪ q, i, o,−→, 99k), where −→ and 99k are the least sets satisfying the conditions −→p⊆−→, 99kp⊆99k, −→q⊆−→, 99kq⊆99k and the following rules: (must) p ∨ q τ−→ {p, q} (imust) p ∨ q i−→ p′ ∪ q′ if p i−→p p′ and q i−→q q′ (may) p ∨ q τ 99k p, p ∨ q τ 99k q (may1) p ∨ q i 99k p′ if p i 99kp p′ and ∃q′. q i 99kq q′ (may2) p ∨ q i 99k q′ if q i 99kq q′ and ∃p′. p i 99kp p′ the idea behind the operational reading of ∨ is very intuitive since p∨q τ−→ {p, q} naturally describes disjunctive behaviour. the only subtle point is that must-inputs must be matched directly, which justifies rule (imust) above. we now have the following desired theorem and corollary: theorem 3 (∨ is or) let p, q and r be mias with common alphabets, disjoint state sets and states p, q, r, resp. then, p ∨ q @ ` r iff p @ ` r and q @ ` r. corollary 2 mia-refinement is compositional wrt. disjunction. the above conjunction and disjunction operators are only defined on mias with the same alphabets. in practice, one would wish to also be able to apply these operators to mias that specify different aspects of the system under study and, thus, have different alphabets (cf. sender and resetter in sec. 3.4). one way to deal with this situation is to extend the alphabets of the conjuncts in some p∧q to a common alphabet by adding a may-loop p a 99k p to all states p ∈ p and for all actions a ∈ aq \ap, and similarly for q; such loops would express that p, q behave neutral regarding actions that are not in their resp. alphabets. however, there is a problem with this idea in the context of mia refinement, which we inherited from the iomts framework [lnw07]. to see this problem, consider the mias p, q depicted in fig. 3 with input/output alphabets /0/{o, o′} and resp. {i}/ /0, as well as mias r1, r2 and r3 with alphabets {i}/{o, o′}. intuitively, r1 and r2 should refine p ∧ q, while r3 should not. this is because (i) p morally has an i-may-loop and q allows input i, and (ii) p enforces one output o and prohibits o′ independent of any i. however, there is no mia r with alphabets {i}/{o, o′} and some r ∈ r which has these properties of p ∧ q: if r2 refines r, then so does r3. the problem’s source lies in the fact proc. avocs 2013 8 / 15 eceasst figure 3: alphabet extension and conjunction in the optimistic setting. that, as shown in fig. 1 (right), any reasonable refinement relation on mia must allow additional inputs (with arbitrary subsequent behaviour) in implementations, if compositionality for parallel composition as in ia [dh05] should hold. one could try to generalise def. 3 such that the refining p may have additional inputs (and outputs) and decree that p i−→ p′ with i ∈ ip \ iq implies ∀p′ ∈ p′. (p′, q) ∈ r, as we did in a prior version of this paper that is included in the pre-proceedings of avocs’13. but the example above shows that the resulting refinement notion would not be transitive, since then r3 @` r2 @ ` p but r3 6@` p. our special treatment of inputs implies that may-inputs make no sense, because inputs are always implicitly allowed. thus, one cannot formalize the decision not to implement some input in some state. as we will show in the next section, the pessimistic approach as, e.g., in [bmsh10] avoids this problem. 3 the pessimistic setting orthogonal to the ‘optimistic’ school on interface theories, comprising ia [dh05], iomts [lnw07] and the above mia approaches, there is the school of bauer et al. who has adopted a pessimistic view of compatibility in the presence of errors; see, e.g., [bmsh10]. their interface theory, called mio, also roots in larsen’s modal transition systems [lar90] and allows may-inputs, but it defines parallel composition for much fewer interfaces when compared to optimistic approaches. in our opinion, intuition for the pessimistic setting is weak since it distinguishes a state p where an input i is absent, from the situation where an i-transition leads to an error state; in both cases, an error is reached iff the environment provides input i. however, the pessimistic setting has technical advantages as we will see below. we will therefore re-develop our mia theory for such a pessimistic setting, to which we will primarily contribute conjunction and disjunction operators and also disjunctive must-transitions. for completeness note that conjunction was defined by bauer for a pessimistic interface theory in [bau12]; however, he considered deterministic interfaces only and no internal actions. definition 10 (relaxed mia) a relaxed modal interface automaton (relaxed mia) is a tuple (p, i, o,−→, 99k) as in def. 1, but which is only required to satisfy syntactic consistency. in the context of the pessimistic setting, it turns out that input determinism and input must (conds. (a) and (b) of def. 1) will not be necessary. we thus eliminate these conditions from 9 / 15 volume 66 (2013) richer interface automata mia and call the resulting automata relaxed mias. in analogy to def. 2 we now define weak transitions for relaxed mia and, for convenience, overload the according transition symbols: definition 11 (relaxed weak transition relations) the relaxed weak must-transition relation −→−→ and relaxed weak may-transition relation 99k99k are defined identically to the weak mustand may-transition relations in def. 2, but replacing ω by α , ω̂ by α̂ , and o by a. for input actions, we additionally define a restricted weak must-transition that only allows trailing τ -actions as follows: (e) p i−→ p′ implies p i −→−→−→−→p′, (f) p i −→−→−→−→p′, p′ ∈ p′ and p′ τ−→ p′′ implies p i −→−→−→−→(p′ \{p′})∪ p′′, observe that p i −→−→−→−→p′ implies p i −→−→p′, which will be used in the sequel. since may-inputs are available in the pessimistic setting, extending the alphabets of interfaces can be defined via an according operation, as we will see below (def. 15). therefore, we first consider refinement and operators for relaxed mias with the same input and output alphabets. the corresponding notions for relaxed mias with dissimilar alphabets will then be defined on the basis of the existing ones and the alphabet extension operator. definition 12 (modal refinement on relaxed mia) let p, q be relaxed mias with the same input and output alphabets. r ⊆ p × q is a modal refinement relation if for all (p, q) ∈ r: (i) q i−→ q′ implies ∃p′. p i −→−→−→−→p′ and ∀p′∈p′∃q′∈q′. (p′, q′) ∈ r, (ii) q ω−→ q′ implies ∃p′. p ω̂ −→−→p′ and ∀p′∈p′∃q′∈q′. (p′, q′) ∈ r, (iii) p α 99k p′ implies ∃q′. q α̂ 99k99k q ′ and (p′, q′) ∈ r. we write p @ a q and say that p modal-refines q if there exists a modal refinement relation r such that (p, q) ∈ r. moreover, we denote the kernel of @ a by @ a a a . 3.1 parallel composition the definitions of composability, parallel product and error state for relaxed mias are as in def. 4 for mias. however, the pessimistic setting is distinguished from the optimistic one by the following definition of compatibility, which is much stricter than the notion of compatibility introduced in def. 4: definition 13 (compatibility on relaxed mia) given relaxed mias p1 and p2, states p1 ∈ p1 and p2 ∈ p2 are called incompatible if an error state is reachable from (p1, p2) in p1 ⊗ p2. here, reachable means reachable via any kind of may-transition. we write p1 ⊗ p2 for (p1, p2) if p1 and p2 are compatible. note that lemma 1 is still valid in the pessimistic setting. we now obtain the analogue of thm. 1: proc. avocs 2013 10 / 15 eceasst theorem 4 (compositionality of parallel composition) let p1, p2, q be relaxed mias with p1 ∈ p1, p2 ∈ p2, q ∈ q and p1 @a q. assume that q and p2 are composable; then: (a) p1 and p2 are composable. (b) if q and p2 are compatible, then so are p1 and p2 and p1 ⊗ p2 @a q ⊗ p2. in contrast to the optimistic setting, the matching of input may-transitions in the refinement preorder does not preclude compositionality. this is because for p1 @a q, there exist much fewer p2 such that q and p2 are compatible. in other words, for establishing the precongruence property for parallel composition ⊗, there are much fewer results p1 ⊗ p2 @a q ⊗ p2 to prove. 3.2 conjunction & disjunction the definition of conjunction ∧ on relaxed mia gets by with five instead of eleven rules. this is because it allows one to merge the corresponding rules for outputs and inputs, due to the use of weak input must-transitions in def. 12: definition 14 (conjunctive product on relaxed mia) let (p, i, o, −→p, 99kp) and (q, i, o,−→q, 99kq) be relaxed mias with common alphabets. the conjunctive product p&q =df (p × q, i, o,−→, 99k) is defined by the following operational transition rules: (must1) (p, q) α−→ {(p′, q′)| p′ ∈ p′, q α̂ 99k99kq q ′} if p α−→p p′ and q α̂ 99k99kq (must2) (p, q) α−→ {(p′, q′)| p α̂ 99k99kp p ′, q′ ∈ q′} if p α̂ 99k99kp and q α−→q q′ (may1) (p, q) τ 99k (p′, q) if p τ 99k99kp p ′ (may2) (p, q) τ 99k (p, q′) if q τ 99k99kq q ′ (may3) (p, q) α 99k (p′, q′) if p α 99k99kp p ′ and q α 99k99kq q ′ conjunction on relaxed mia – including the set f of inconsistent states – is now defined identically to these notions on mia (def. 7), but replacing o ∈ o with a ∈ a; the same applies to the notion of witness (def. 8). in analogy to lemma 2, we obtain the following concrete witness lemma for our pessimistic setting: lemma 3 (concrete witness for relaxed mias) let p, q and r be relaxed mias. (i) for any witness w of p&q, we have f ∩w = /0. (ii) the set {(p, q) ∈ p × q | ∃r ∈ r. r @ a p and r @ a q} is a witness of p&q. on the basis of this lemma we can now establish the desired greatest lower bound result for ∧, which implies the compositionality of @ a wrt. ∧: theorem 5 (∧ is and) let p and q be relaxed mias with common alphabets. then, (i) (∃r and r ∈ r. r @ a p and r @ a q) iff p ∧ q defined. further, in case p ∧ q defined and for any r and r ∈ r: (ii) r @ a p and r @ a q iff r @ a p ∧ q. 11 / 15 volume 66 (2013) richer interface automata corollary 3 modal-refinement is compositional wrt. conjunction. we now turn our attention to disjunction ∨ on relaxed mia, which is defined as in def. 9 for mia and for which we obtain, in analogy to thm. 3 and cor. 3: theorem 6 (∨ is or) let p, q and r be relaxed mias with common alphabets, disjoint state sets and states p, q and r, resp. then, p ∨ q @ a r iff p @ a r and q @ a r. corollary 4 modal-refinement is compositional wrt. disjunction. 3.3 alphabet extension as motivated in sec. 2, we introduce alphabet extension as an operation on relaxed mia: definition 15 (alphabet extension) given a relaxed mia (p, i, o, −→, 99k) and disjoint action sets i′ and o′ satisfying i′ ∩a = /0 = o′ ∩a, where a =df i ∪o. the alphabet extension of p by i′ and o′ is given by [p]i′, o′ =df (p, i∪i′, o∪o′,−→, 99k ′) for 99k′ =df 99k ∪{(p, a, p)| p ∈ p, a ∈ i′ ∪ o′}. we often write [p]i′, o′ – or conveniently [p] in case i′, o′ are understood from the context – for p as state of [p]i′, o′ . for relaxed mias p, q with p ∈ p, q ∈ q, ip ⊇ iq and op ⊇ oq, we define p @a ′ q if p @ a [q]ip\iq, op\oq . since @a ′ extends @ a to relaxed mias with different alphabets, we write @ a for @ a ′. we also abbreviate [q]ip\iq, op\oq by [q]p. our compositionality result regarding parallel composition of thm. 4 immediately carries over to the alphabet extension situation, if we require that alphabet extension does not yield new communications: theorem 7 (compositionality of parallel composition) let p1, p2, q be relaxed mias as well as p1 ∈ p1, p2 ∈ p2, q ∈ q such that, for i′ =df i1 \iq and o′ =df o1 \oq, we have (i′∪o′)∩a2 = /0. assume further that q and p2 are composable and p1 @a q. then: (a) p1 and p2 are composable. (b) if q and p2 are compatible, then so are p1 and p2 and p1 ⊗ p2 @a q ⊗ p2. the conjunction operator in the presence of alphabet extension can now be lifted from sec. 3.2 in a straightforward manner: definition 16 (conjunction operator) let p, q be relaxed mias, p ∈ p and q ∈ q such that ip ∩ oq = /0 = iq ∩ op. then, p ∧′ q =df [p]q ∧[q]p. again, we simply write p ∧ q for p ∧′ q. to be able to lift our main result, thm. 5, we only need to establish that the alphabet extension operation is a homomorphism for conjunction: lemma 4 let p with p ∈ p and q with q ∈ q be relaxed mias that have the same alphabets. consider the alphabet extensions by some i′ and o′. then: proc. avocs 2013 12 / 15 eceasst (a) p and q are consistent iff [p] and [q] are. (b) given consistency, [p ∧ q] @ a a a [p]∧[q]. theorem 8 (∧ is and) let p with p∈p, q with q∈q, and r with r∈r be relaxed mias such that ip ∩ oq = /0 = iq ∩ op, ir ⊇ ip ∪ iq and or ⊇ op ∪ oq. then, (i) there exists such an r and r ∈ r with r @ a p and r @ a q iff p∧q is defined. further, in case p∧q is defined: (ii) r @ a p and r @ a q iff r @ a p ∧ q. the situation for disjunction under alphabet extension is analogous to above, but exploiting monotonicity of the alphabet extension operation wrt. @ a : definition 17 (disjunction operator) let p, q be relaxed mias with disjoint state sets, p ∈ p and q ∈ q such that ip ∩ oq = /0 = iq ∩ op. then, p ∨′ q =df [p]q ∨[q]p. once again, we simply write p ∨ q for p ∨′ q. lemma 5 let p with p∈p and r with r∈r be relaxed mias having the same alphabets, as well as i′ and o′ be suitable action sets for extending them. then, p @ a r iff [p] @ a [r]. theorem 9 (∨ is or) let p with p∈p, q with q∈q, and r with r∈r be relaxed mias with disjoint state sets such that ip ∩ oq = /0 = iq ∩ op, ir ⊆ ip ∪ iq and or ⊆ op ∪ oq. then, p ∨ q @ a r iff p @ a r and q @ a r. 3.4 example we briefly illustrate the utility of our interface theory by a small example that models parts of a communication protocol (see fig. 4) and is inspired by an example in [rbb+11]. the protocol’s abstract specification is given by mia spec. it receives a message from its environment (action get?), delivers it (put!) and signals to its environment its willingness to handle the next message (nxt!). the two τ -may-transitions making up the τ -loop model that the message’s transmission may fail and that this failure may possibly be repaired. the design of our communication protocol contains a generic component sender, which receives a message for delivery (get?). it sends this message (msg!) to the medium and waits for an according acknowledgment (ack?). in case a negative acknowledgment arrives (nack?), the message is re-sent. sender is specialized by conjoining it with component resetter, which can suggest a reset (rst!) after a negative acknowledgment; it is defined such that an implementation may decide, e.g., to initiate a reset after exactly n negative acknowledgments, showing the utility of may-inputs for specification and the model-refinement preorder. (relaxed) mia sender∧resetter is the result of formally applying our conjunction operator to (relaxed) mia sender and relaxed mia resetter. note that applying conjunction implicitly extends the alphabet of resetter by get?, ack?, msg! and nxt! (cf. def. 16). in addition, no inconsistency arises in our example. however, if one would refine sender and resetter by removing the rst!-loop at state d and making the reset transition a must-transition instead of a may-transition, then state db (or, more precisely, d∧b) would be 13 / 15 volume 66 (2013) richer interface automata figure 4: example: design = (sender∧resetter)|medium and spec. inconsistent; removing this state as is required by the definition of ∧ would then yield state ab unreachable. (relaxed) mia medium specifies a communication medium with potential failure, which receives a message (msg?) and may either deliver it to the environment (put!) or – via the τ -may-transition – may lose it. in the former case, medium returns to its initial state by sending an acknowledgment (ack!); in the latter case, it signals failure (failed!) and may return a negative acknowledgment (nack!). the parallel composition design =df (sender∧ resetter)|medium is also shown in fig. 4. using our refinement preorder, it is now easy to check that design modal-refines spec when the latter’s alphabet is extended by failed!, i.e., design @ a [spec] /0,{failed}. note that this relies on our use of weak mustand maytransitions in the definition of @ a , i.e., on the ability to abstract from internal τ -transitions. as a practical case for the problem that we discussed using fig. 3, observe the following: if resetter would permit everything after the unknown input get?, output rst! would then always be allowed – also without any occurrence of nack?. proc. avocs 2013 14 / 15 eceasst 4 conclusions & future work interface theories are an important tool for reasoning about component-based systems [bdh+12, bmsh10, bchs07, dh05, lnw07, lv13, rbb+11]. this paper advanced the state-of-the-art of both the optimistic and pessimistic schools on interface theories. regarding the optimistic school, we repaired a shortcoming of the refinement preorder introduced in [lnw07], which ignored internal must-transitions, thereby leading to unintuitive refinements. regarding the pessimistic school, we showed how its approach may be extended by conjunction and disjunction operators; conjunction is a key operator in any component-based setting, which enables engineers to express that some component is required to satisfy several interfaces. in future work we wish to investigate whether there are suitable interface theories in-between the optimistic and pessimistic approaches. this might fix their current limitations, namely allowing may-inputs as in the pessimistic approach while maintaining the truly open systems view of the optimistic approach. bibliography [bau12] s. bauer. modal specification theories for component-based design. phd thesis, faculty of mathematics, informatics and statistics, lmu munich, germany, 2012. [bchs07] d. beyer, a. chakrabarti, t. henzinger, s. seshia. an application of web-service interfaces. in icws. pp. 831–838. ieee, 2007. [bdh+12] s. bauer, a. david, r. hennicker, k. larsen, a. legay, u. nyman, a. wasowski. moving from specifications to contracts in component-based design. in fase. lncs 7212, pp. 43–58. springer, 2012. [bmsh10] s. bauer, p. mayer, a. schroeder, r. hennicker. on weak modal compatibility, refinement, and the mio workbench. in tacas. lncs 6015, pp. 175–189. springer, 2010. [dh05] l. de alfaro, t. henzinger. interface-based design. in engineering theories of software-intensive systems. nato science series 195. springer, 2005. [lar90] k. larsen. modal specifications. in automatic verification methods for finite state systems. lncs 407, pp. 232–246. springer, 1990. [lnw07] k. larsen, u. nyman, a. wasowski. modal i/o automata for interface and product line theories. in esop. lncs 4421, pp. 64–79. springer, 2007. [lv13] g. lüttgen, w. vogler. modal interface automata. logical methods in computer science 9(3:4), 2013. [rbb+11] j. raclet, e. badouel, a. benveniste, b. caillaud, a. legay, r. passerone. a modal interface theory for component-based design. fund. inform. 107:1–32, 2011. 15 / 15 volume 66 (2013) introduction modal interface automata: the optimistic setting parallel composition conjunction & disjunction the pessimistic setting parallel composition conjunction & disjunction alphabet extension example conclusions & future work graph tuple transformation electronic communications of the easst volume 62 (2013) specification, transformation, navigation special issue dedicated to bernd krieg-brückner on the occasion of his 60th birthday graph tuple transformation hans-jörg kreowski and sabine kuske 23 pages guest editors: till mossakowski, markus roggenbach, lutz schröder managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst graph tuple transformation hans-jörg kreowski1 and sabine kuske2∗ 1 kreo@informatik.uni-bremen.de, http://www.informatik.uni-bremen.de/theorie 2kuske@informatik.uni-bremen.de,http://www.informatik.uni-bremen.de/∼kuske department of computer science university of bremen, germany abstract: graph transformation units are rule-based devices to model and compute relations between initial and terminal graphs. in this paper, they are generalized to graph tuple transformation units that allow one to combine different kinds of graphs into tuples and to process the component graphs simultaneously and interrelated with each other. moreover, one may choose some of the working components as inputs and some as outputs such that a graph tuple transformation unit computes a relation between input and output tuples of potentially different kinds of graphs rather than a binary relation on a single kind of graphs. keywords: graph transformation, transformation units, graph tuples 1 introduction for some decades, many software engineers have dreamt about system development in such a way that data processing problems and their solution are modeled by means suitable for the application domain and then transformed into smoothly and efficiently running and trustworthy programs. this idea has been discussed under various headings like program transformation and stepwise refinement (see, e.g., wirth [wir71] and basin and krieg-brückner [bk99]). nowadays the term model transformation is quite popular referring to the transformation of platformindependent models into platform-dependent models (see, e.g., frankel [fra03]). as the former ones are often assumed to be visual models like uml diagrams or petri nets, some researchers have proposed graph transformation as a framework for the description of visual models as well as their transformation (see, e.g., [lt04, küs06, eee+07, kks07, vb07, ee08]). in this paper, we try to enhance the usefulness of graph transformation as a base of model transformation by introducing the concept of graph tuple transformation offering the parallel processing of graph components of arbitrary tuples. the basic idea is that a visual model of a software system usually does not consist of a single diagram, but of a family of interrelated diagrams which is better covered by a graph tuple than a single graph. our particular motivation is the observation that the area of theoretical computer science provides a wealth of model transformation examples like the transformation of automata into grammars, grammars into some normal forms, formulas into graphs, etc. where most involved models are tuples of some kind and their transformation often consists of transformations of the tuple components. we hope ∗ research partially supported by the collaborative research centre 637 (autonomous cooperating logistic processes: a paradigm shift and its limitations) funded by the german research foundation (dfg). 1 / 23 volume 62 (2013) mailto:kreo@informatik.uni-bremen.de http://www.informatik.uni-bremen.de/theorie mailto:kuske@informatik.uni-bremen.de http://www.informatik.uni-bremen.de/~kuske graph tuple transformation that it is worthwhile to exploit the experiences of model transformation in theoretical computer science. in more explicit terms, graph transformation units are generalized to graph tuple transformation units. a graph transformation unit consists of specifications of initial and terminal graphs, a set of rules, a set of imported graph transformation units, and a control condition. the semantics is a relation between initial and terminal graphs obtained by the interleaving of rule applications and calls of imported units in such a way that the control condition holds. if the initial and terminal graphs are models of some kind, a graph transformation unit specifies a model transformation. graph transformation units do not depend on specific rule classes, specific classes of graph class specifications or particular classes of control conditions, i.e., their components can be taken from an arbitrary graph transformation approach consisting of a graph class, a rule class, a class of graph class expressions, and a class of control conditions. the basic components of graph transformation units are recalled in the following section (see [kk99, kkr08] for more details). the generalization to tuples of graphs is introduced in section 3. the component graphs may be of different kinds like directed or undirected graphs. they may use different label alphabets. or they may be of special forms representing strings, numbers or truth values for example. corresponding to the different kinds of component graphs, there can be different kinds of rules available for the various components. the transformation of graph tuples is based on actions being tuples of rules, which can be applied in parallel to the component graphs. to get more flexibility, we allow also actions where rules may be replaced by calls of units or by the special symbol −. the latter means that nothing happens in the respective components. the former replaces a single rule application by an auxiliary computation of another unit. moreover, a mechanism is provided that allows one to choose some of the components of the graph tuples processed by actions as inputs and some as outputs. respectively, the semantics of a graph tuple transformation unit is a relation between input tuples and output tuples given by an iterated execution of actions. all new concepts are illustrated by various aspects of the recognition of strings by finite automata. a short and preliminary version of this paper appeared as [kkk04]. 2 graph transformation in this section we recall the main concepts of graph transformation like graphs, rules and graph transformation units and illustrate them with various small examples. in the literature one can find many more applications of graph transformation which stress the usefulness from the practical point of view. these are for example applications from the area of functional languages ([pe93, spe93]), visual languages (e.g. [bmst99, eg07]), software engineering ([nag96]), uml (e.g. [bkpt00, ehhs00, fntz00, ps00, ehk01, kus01, kgkz09, hzg06]), and agent systems (e.g. [jan99, dhk02, gk07, tkkt07]). graph transformation comprises devices for the rule-based manipulation of graphs. given a set of graph transformation rules and a set of graphs, one gets a graph transformation system in its simplest form. such a system transforms a start graph by applying its graph transformation rules. the semantics can be defined as a binary relation on graphs where the first component of every pair is some start graph g and the second component is a graph derived from g by applying festschrift bernd krieg-brückner 2 / 23 eceasst a sequence of graph transformation rules. in general, the application of a graph transformation rule to a graph transforms it locally, i.e., it replaces a part of the graph with another graph part. often one wishes to start a derivation only from certain initial graphs, and to accept as results only those derived graphs that are terminal. moreover, in some cases the derivation process should be regulated in a certain way to cut down the nondeterminism of rule applications. for example, one may employ a parallel mode of transformation as in l systems, or one may restrict the order in which rules are applied. graph class expressions and control conditions are suitable to restrict the derivation process where the former allow to choose initial and terminal graphs and the latter require certain derivation steps and forbid others. altogether, graphs, rules, their application, graph class expressions, and control conditions are the basic elements of a so-called graph transformation approach. 2.1 graphs one of the most elementary components of a graph transformation system is a class of graphs g . the graphs of g can be directed or undirected, typed or untyped, labeled or unlabeled, simple or multiple. examples for graph classes are labeled directed graphs, hypergraphs, trees, forests, state graphs of finite automata, petri nets, etc. the choice of graphs depends on the kind of applications one has in mind and is a matter of taste. in this paper, we consider directed, edge-labeled graphs with individual, multiple edges. a graph is a construct g = (v,e,s,t,l) where v is a finite set of nodes, e is a finite set of edges, s,t : : e → v are two mappings assigning each edge e ∈ e a source s(e) and a target t(e), and l : e → c is a mapping labeling each edge in a given finite label alphabet c. a graph may be represented in a graphical way with circles as nodes and arrows as edges that connect source and target each, with the arrowhead pointing to the target. the labels are placed next to the arrows. in the case of a loop, i.e., an edge with the same node as source and target, we may draw a flag that is posted on its node with the label inside the box. to cover unlabeled edges as a special case, we assume a particular label ∗ that is invisible in the drawings. for instance, the graph in figure 1 is a state graph of a finite deterministic automaton where the edges labeled with a and b represent transitions, and the sources and targets of the transitions represent states. the start state is indicated with a start-flag and every final state with a final-flag. moreover there is a flag labeled with current at the current state of the state graph of the finite deterministic automaton. start final final current a a a b b b figure 1: the state graph of a deterministic finite automaton 3 / 23 volume 62 (2013) graph tuple transformation two further instances of graphs are shown in figure 2. the left one consists of five nodes and six directed edges (two of which are represented as flags). it is a string graph which represents the string abba. the beginning of the string is indicated with the begin-flag at the source of the leftmost a-edge. analogously, there is an end-flag at the end of the string, i.e., at the target of the rightmost a-edge. a b b a begin end begin end figure 2: a string graph (left) and a 4-string graph (right) if one takes this string graph and removes all occurrences of the labels a and b, one gets the string graph on the right of figure 2 which is a graph that is a simple unlabeled path from a begin-flagged node to an end-flagged node. such string graphs can be used to represent natural numbers. hence, the right string graph in figure 2 represents the number 4 because it has four unlabeled edges between its begin-flagged and its end-flagged node. whenever a string graph represents a natural number k in this way, we say that it is the k-string graph. a graph morphism g from a graph l = (v,e,s,t,l) to a graph g = (v ′,e′,s′,t′,l′) is a pair of mappings (gv (: v → v ′ ,ge : e → e ′) that is structure and label preserving, i.e., gv (s(e)) = s′(ge (e)), gv (t(e)) = t ′(ge (e)), and l(e) = l ′(ge (e)). the graph morphism g is injective if gv and ge are injective. 2.2 rules and rule applications to be able to transform the graphs in g , rules are applied to the graphs yielding graphs. given some class r of graph transformation rules, each rule r ∈ r defines a binary relation =⇒ r ⊆ g × g on graphs. if g =⇒ r h , one says that g directly derives h by applying r. there are many possibilities to choose rules and their applications. rule classes may vary from the more restrictive ones, like edge replacement [dhk97] or node replacement [er97], to the more general ones, like double-pushout rules (corradini, ehrig, löwe, montanari, and rossi [ceh+97]), single-pushout rules (ehrig, heckel, korff, löwe, ribeiro, wagner, and corradini [ehk+97]), or progres rules (schürr [sch97]). in general, all rule classes contain at least a left-hand side which specifies the part that should be deleted from the graph to which the rule is applied, and a right-hand side which determines the items that should be added to the graph. in the examples of this paper, we use a simplified form of double-pushout rules, but it is worth noting that our approach works for arbitrary rule classes. every rule (of this simplified rule class) is a triple r = (l,k,r) where l and r are graphs (the leftand right-hand side of r, respectively) and k is a set of nodes shared by l and r. in graphical representations, l and r are drawn as usual, with numbers uniquely identifying the nodes in k. its application means to replace an occurrence of l with r such that the common part k is kept. a rule r = (l,k,r) can be applied to some graph g directly deriving the graph h if h can festschrift bernd krieg-brückner 4 / 23 eceasst be constructed up to isomorphism (i.e., up to the renaming of nodes and edges) in the following way. 1. find an injective graph morphism g from l to g, i.e. a subgraph g(l) that coincides with l up to the naming of nodes and edges. 2. remove all nodes and edges of g(l − k), i.e., all nodes and edges of g(l) except the nodes corresponding to k, provided that the remainder is a graph (which holds if the removal of a node is accompanied by the removal of all its incident edges). 3. add r by merging each node v in k with its image g(v) in g. for example, the rule go(a) in figure 3 has as left-hand side a graph consisting of an a-edge from node 1 to node 2 and a current-flag at node 1. the right-hand side consists of node 1, node 2, the a-edge and a new current-flag at the target of the a-edge. the common part of go(a) consists of nodes 1 and 2 as well as of the a-edge. the rule go(a) moves a current-flag from the source of some a-labeled edge to the target of this edge. its application to the state graph in figure 1 results in the same state graph except that the current state is changed to the start state. go(a): current 1 2 a current 1 2 a ::= figure 3: the rule go(a) another example of a rule is shown in figure 4. it has as left-hand side a graph consisting of an a-edge and a begin-flag. the right-hand side consists of the target of a new begin-flag at the target of the a-edge. the common part of the rule read(a) consists of the target of the a-edge. the rule read(a) can be applied to the left string graph in figure 2. its application deletes the begin-flag and the leftmost a-edge together with its source. it adds a new begin-flag at the target of the a-edge. the resulting string graph represents the string bba. read(a): begin 1 a ::= begin 1 figure 4: the rule read(a) 2.3 graph class expressions the aim of graph class expressions is to restrict the class of graphs to which certain rules may be applied or to filter out a subclass of all the graphs that can be derived by a set of rules. typically, a graph class expression may be some logic formula describing a graph property like connectivity, 5 / 23 volume 62 (2013) graph tuple transformation or acyclicity, or the occurrence or absence of certain labels. in this sense, every graph class expression e specifies a set sem(e) of graphs in g . for instance, all refers to all directed, edge-labeled graphs, whereas empty designates the class consisting of the empty graph empty. every graph g ∈ g is also a graph class expression specifying itself. in particular, we also use the graph class expression dfsg specifying all state graphs of deterministic finite automata as well as the expression start specifying all graphs in sem(dfsg) where the current state is the start state. moreover, the expressions string and nat specify the set of all string graphs and the set of all k-string graphs, respectively. a further graph class expression used in the following is bool which specifies the two graphs true and false. both graphs consist of a single node with a flag that is labeled true and false, respectively: true = true false = false a particular kind of a graph class expression is given by a single graph type ∈ g specifying the class sem(type) of all graphs that can be mapped homomorphically to type. these graphs are called typed graphs in, e.g., [eept06]. it is meaningful to require that graph class expressions are decidable, i.e., for any graph class expression e and any graph g there should be an algorithm that decides whether g ∈ sem(e). it is worth noting that this is the case in the presented examples. 2.4 control conditions a control condition is an expression that determines, for example, the order in which rules may be applied. semantically, it relates start graphs with graphs that result from an admitted transformation process. in this sense, every control condition c specifies a binary relation sem(c) on g . as control condition we use in particular the expression true that allows all transformations (i.e., all pairs of graphs). moreover, we use regular expressions as control conditions. they describe in which order and how often the rules and imported units are to be applied. in particular, for control conditions c, c1, and c2 the expression c1;c2 specifies the sequential composition of both semantic relations, c1|c2 specifies the union, and c ∗ specifies the reflexive and transitive closure, i.e., sem(c1;c2) = sem(c1)◦sem(c2), sem(c1|c2) = sem(c1)∪ sem(c2), and sem(c∗) = sem(c)∗. moreover, for a control condition c the expression c! requires to apply c as long as possible, i.e., sem(c) consists of all pairs (g,h) ∈ sem(c)∗ such that there is no h′ with (h,h′) ∈ sem(c). in the following the control condition c1|···|cn will also be denoted by {c1,...,cn}. for example, let c1, c2, and c3 be control conditions that specify binary relations on graphs of a certain type. then the expression c1!;c ∗ 2 ;(c3|c1) prescribes to apply first c1 as long as possible, then c2 arbitrarily often, and finally c3 or c1 exactly once. the precise meaning of a regular expression is explained where it is used. more about control conditions can be found in, e.g., [kus00, hp01, hkk08]. 2.5 transformation units a class of graphs, a class of rules, a rule application operator, a class of graph class expressions, and a class of control conditions form a graph transformation approach based on which graph festschrift bernd krieg-brückner 6 / 23 eceasst transformation units as a unifying formalization of graph grammars and graph transformation systems can be defined. more precisely, a graph transformation approach is defined as a = (g ,r,=⇒,x ,c ) where g is a graph class, r is a rule class, =⇒ is a rule application operator which provides a rule application relation =⇒ r ⊆ g × g for each r ∈ r, x is a class of graph class expressions with sem(e) ⊆ g for all e ∈ x , and c is a class of control conditions with sem(c) ⊆ g × g for all c ∈ c . in the following, the components g , r, =⇒, x , and c of an approach a are also denoted by ga , ra , =⇒ a , xa , and ca , respectively. in general, a graph transformation system may consist of a huge set of rules that by its size alone is difficult to manage. transformation units provide a means to structure the transformation process. the main structuring principle of transformation units relies on the import of other transformation units or – on the semantic level – of binary relations on graphs. the input and the output of a transformation unit each consist of a class of graphs that is specified by a graph class expression. the input graphs are called initial graphs and the output graphs terminal graphs. a transformation unit transforms initial graphs to terminal graphs by interleaving the applications of graph transformation rules and imported transformation units. since rule application is nondeterministic in general, a transformation unit contains a control condition that may regulate the graph transformation process. let a = (g ,r,=⇒,x ,c ) be a graph transformation approach. a graph transformation unit over a is a system gtu = (i,u,r,c,t ) where i and t are graph class expressions in x , u is a (possibly empty) set of imported graph transformation units over a , r is a set of rules in r, and c is a control condition in c . to simplify technicalities, we assume that the import structure is acyclic (for a study of cyclic imports see [kks97]). initially, one builds units of level 0 with empty import. then units of level 1 are those that import only units of level 0 but at least one, and units of level n + 1 import only units of level 0 to level n, but at least one from level n. in graphical representations of transformation units we omit the import component if it is empty, the initial or terminal component if it is set to all, and the control condition if it is equal to true, meaning that there is no restriction. in the following, we present some simple examples of transformation units specifying natural numbers and truth values. the latter are used in subsection 3.5 as an auxiliary data type to model the more interesting examples concerning finite automata. the control condition of each example unit in this section is equal to true. the examples in subsection 3.5 contain more sophisticated control conditions. the first transformation unit nat0 depicted in figure 5 constructs all string graphs that represent natural numbers by starting from its initial graph, which represents 0, and transforming the n-string graph into the n + 1-string graph by applying the rule succ. the second transformation unit nat1 shown in figure 6 is a variant of nat0, but now with all nstring graphs as initial graphs. consequently, it describes arbitrary additions to arbitrary n-string graphs by sequentially increasing the represented numbers by 1. the third transformation unit nat2 is shown in figure 7. it also transforms string graphs into string graphs. it has two rules pred and is-zero. the application of the rule pred to the n-string graph (with n ≥ 1 since otherwise the rule cannot be applied) converts it into the n − 1-string graph. the second rule is-zero can be applied only to the 0-string graph but does not transform 7 / 23 volume 62 (2013) graph tuple transformation nat0 initial: begin end 1 rules: succ : end 1 ::= end 1 figure 5: the transformation unit nat0 nat1 initial: nat rules: succ : end 1 ::= end 1 figure 6: the transformation unit nat1 it, which means that this rule can be used as a test for 0. the transformation unit nat2 imports nat1 so that arbitrary additions can be performed, too. the rules of nat2 and the imported unit nat1 can be applied in arbitrary order and arbitrarily often. hence nat2 converts n-string graphs into m-string graphs for natural numbers m, n. therefore nat2 can be considered as a data type representing natural numbers with a simple set of operations. our model of the natural numbers is very simple providing just a graphical variant nat2 initial: nat uses nat1 rules: pred : end 1 ::= end 1 is − zero : begin end 1 ::= begin end 1 figure 7: the transformation unit nat2 festschrift bernd krieg-brückner 8 / 23 eceasst of the unary representation with the possibility to increase and to decrease a number by 1 as well as to test for 0. a more sophisticated model of natural numbers is not needed in this paper. the fourth transformation unit bool0 = (empty, /0,generate-true,true,bool) in figure 8 has a single initial graph, the empty graph empty. it does not import other transformation units and it has one rule generate-true which turns empty to the graph true. the control condition allows all transformations, meaning that true may be added arbitrarily often to empty. however, the terminal graph class expression bool ensures that the rule generate-true is applied exactly once to the initial graph. one can consider bool0 as a unit that describes the type boolean in its simplest form. at first sight, this may look a bit strange. but it is quite useful if one wants to specify predicates on graphs by nondeterministic graph transformation: if one succeeds to transform an input graph into the graph true, the predicate holds; otherwise it fails. in other words, if the predicate does not hold for the input graph, none of its transformations yields true. bool0 initial: empty rules: generate-true : empty ::= true 1 terminal: bool figure 8: the transformation unit bool0 2.6 interleaving semantics of transformation units transformation units transform initial graphs to terminal graphs by applying graph transformation rules and imported transformation units so that the control condition is satisfied. hence, the semantics of a transformation unit can be defined as a binary relation between initial and terminal graphs. for example, the interleaving semantics of the transformation unit nat2 consists of all pairs (g,g′) such that g is a k-string graph and g′ is an l-string graph (for some k,l ∈ n). in general, for a transformation unit gtu without import, the semantics of gtu consists of all pairs (g,g′) of graphs such that 1. g is an initial graph and g′ is a terminal graph; 2. g′ is obtained from g via a sequence of rule applications, i.e., (g,g′) is in the reflexive and transitive closure of the binary relation obtained from the union of all relations =⇒ r where r is some rule of gtu; and 3. the pair (g,g′) is allowed by the control condition. if the transformation unit gtu has a non-empty import, the interleaving semantics of gtu consists of all pairs (g,g′) of graphs which satisfy the preceding items 1 and 3, and where, in addition 9 / 23 volume 62 (2013) graph tuple transformation to rules, imported transformation units can be applied in the transformation process of gtu, i.e., the second item above is extended to: 2’. g′ is obtained from g via a sequence of rule applications and applications of imported units. this means that (g,g′) is in the reflexive and transitive closure of the binary relation obtained from the union of all relations =⇒ r and sem(u) where r is some rule of gtu and u is some imported transformation unit of gtu. more formally, the interleaving semantics of gtu is defined as follows. let gtu = (i,u,r,c,t ) be a transformation unit. then the interleaving semantics sem(tu) is recursively defined as sem(tu) = sem((i,u,r,c,t )) = sem(i)× sem(t )∩( ⋃ r∈r =⇒ r ∪ ⋃ u∈u sem(u)) ∗ ∩ sem(c). if the transformation unit gtu is of level 0, the semantic relation is well-defined because the union over u is the empty set. if gtu is of level n + 1, we can inductively assume that sem(u) of each imported unit u is already well-defined, so that sem(tu) is also well-defined as a union and intersection of defined relations. 3 graph tuple transformation graph transformation in general transforms graphs into graphs by applying rules, i.e. in every transformation step a single graph is transformed with a graph transformation rule. in graph tuple transformation, this operation is extended to tuples of graphs. this means that in every transformation step a tuple of graphs is transformed with a tuple of rules. the graphs, the rules, and the ways the rules have to be applied are taken from a so-called tupling base which consists of a tuple of rule bases where a rule base b = (g ,r,=⇒) is a graph transformation approach without control conditions and graph class expressions. 3.1 basic actions the iterated application of rules transforms graphs into graphs yielding an input-output relation on graphs. but in many applications one would like to consider several inputs and maybe even several outputs, or at least an output of a type different from all inputs. in order to reach such an extra flexibility, we introduce in this section the transformation of tuples of graphs, which is the most basic operation of the graph tuple transformation units presented in subsection 3.4. graph tuple transformation over a tupling base is an extension of ordinary rule application in the sense that graphs of different classes can be transformed in parallel. for example to check whether some string can be recognized by a deterministic finite automaton, one can transform three graphs in parallel: the first graph is a string graph representing the string to be recognized, the second graph is a state graph of a deterministic finite automaton, and the third graph represents the boolean value false. to recognize the string one applies a sequence of rule applications which consume the string graph while the corresponding transitions of the deterministic finite state graph are traversed. if after reading the whole string the current state is a final state, festschrift bernd krieg-brückner 10 / 23 eceasst the third graph is transformed into a graph representing true. this example will be explicitly modeled in subsection 3.5. in graph tuple transformation, tuples of rules are applied to tuples of graphs. a tuple of rules may also contain the symbol − in some components where no change is desired. the graphs and the rules are taken from a tupling base, which is a tuple of rule bases tb = (b1,...,bn). let (g1,...,gn) and (h1,...,hn) be graph tuples over tb, i.e. gi,hi ∈ gbi for i = 1,...,n. let a = (a1,...,an) with ai ∈ rbi or ai = − for i = 1,...,n. then (g1,...,gn)−→ a (h1,...,hn) if for i = 1,...,n, gi =⇒ ai hi if ai ∈ rbi and gi = hi if ai = −. in the following we call a a basic action of tb. for a set act of basic actions of tb, −→ act denotes the union ⋃ a∈act −→ a , and ∗ −→ act its reflexive and transitive closure. for example, let i be some finite alphabet and let bbasicstring = (string,{read(x) | x ∈ i},=⇒) and bbasic dfsg = (dfsg,{go(x) | x ∈ i},=⇒) be two rule bases such that string consists of all string graphs over some alphabet i and dfsg consists of all state graphs of deterministic finite automata over i. let (abba)• be the left string graph of figure 2, let gr(a,v0) be the state graph in figure 1 where a denotes the corresponding finite automaton and v0 is the node with the currentflag. then ((abba)•,gr(a,v0))−→ a ((bba)•,gr(a,v1)) for the basic action a = (read(a),go(a)) of tupling base (bbasicstring,b basic dfsg ) where v1 is the node with the start-flag. the transformation of graph tuples via a sequence of basic actions is equivalent to the transformation of tuples of graphs where every component is transformed independently with a sequence of direct derivations of the corresponding component. this is expressed in the following proposition. proposition 1 let act be the set of all basic actions of tb = (b1,...,bn). then (g1,...,gn) ∗ −→ act (h1,...,hn) if and only if gi ∗ =⇒ rbi hi for i = 1,...,n. 3.2 graph tuple class expressions similarly to graph class expressions, the aim of graph tuple class expressions is to restrict the class of graph tuples to which certain transformation steps may be applied, or to filter out a subclass of all the graph tuples that can be obtained from a transformation process. typically, a graph tuple class expression may be some logic formula describing a tuple of graph properties like connectivity, or acyclicity, etc. formally, every graph tuple class expression e over a tupling base tb = (b1,...,bn) specifies a set sem(e) ⊆ gb1 ×··· × gbn of graph tuples in tb. as graph class expressions, graph tuple class expressions should be decidable. in many cases, such a graph tuple class expression will be a tuple e = (e1,...,en) where the ith item ei restricts the graph class gbi of the rule base bi, i.e. sembi (ei) ⊆ gbi for i = 1,...,n. consequently, the semantics of e is semb1 (e1) × ··· × sembn(en). hence, each item ei is a graph class expression as defined for transformation units in section 2. 11 / 23 volume 62 (2013) graph tuple transformation a typical example of a graph tuple class expression over the tupling base tb3 = (b,b,b) for some rule base b is the relation of the component graphs of the triple of graphs as used in triple graph grammars [sch94, sk08]. let triple be a constant expression, then sem(triple) consists of all triples of graphs (g1,g2,g3) such that g2 is subgraph of g1 and g3 as well. the graph tuple class expressions mainly used in this paper are tuples of graph class expressions. a simple example of a graph tuple class expression is (e1,...,en) with ei = all for i = 1,...,n which does not restrict the graph classes of the rule bases, i.e. sem((e1,...,en)) = gb1 ×···× gbn . 3.3 control conditions for graph tuple transformation similarly to control conditions in graph transformation units, a control condition for graph tuple transformation is an expression that determines, for example, the order in which transformation steps may be applied to graph tuples. semantically, it relates tuples of start graphs with tuples of graphs that result from an admitted transformation process. in this sense, every control condition c over a tupling base tb specifies a binary relation sem(c) on the set of graph tuples in tb. more precisely, for a tupling base tb = (b1,...,bn) sem(c) is a subset of (gb1 ×···×gbn) 2. as control conditions we use in particular actions, regular expressions over control conditions (i.e. sequential composition, union, and iteration of control conditions), as well as the expression as-long-as-possible (abbreviated with the symbol ! ). an action prescribes which rules or imported units should be applied to a graph tuple, i.e. an action is a control condition that allows one to synchronize different transformation steps. the basic actions of subsection 3.1 are examples of actions. roughly speaking, an action over a tupling base tb = (b1,...,bn) is a tuple act = (a1,...,an) that specifies an n,n-relation sem(act) ⊆ (gb1 ×···× gbn) 2. actions will be explained in detail in subsection 3.4. 3.4 graph tuple transformation units graph tuple transformation units provide a means to structure the transformation process from a tuple of input graphs to a tuple of output graphs. more precisely, a graph tuple transformation unit transforms k-tuples of graphs into l-tuples of graphs such that the graphs in the k-tuples as well as the graphs in the l-tuples may be of different types. hence, a graph tuple transformation unit specifies a k,l-relation on graphs. internally, a graph tuple transformation unit transforms n-tuples of graphs into n-tuples of graphs, i.e. it specifies internally an n,n-relation on graphs. the transformation of the n-tuples is performed according to a tupling base which is specified in the declaration part of the unit. the k,l-relation is obtained from the n,n-relation by embedding k input graphs into n initial graphs and by projecting n terminal graphs onto l output graphs. the embedding and the projection are also given in the declaration part of a unit. graph tuple transformation units generalize the notion of triple grammars as introduced by schürr [sch94] which in turn are a generalization of pair grammars studied by pratt [pra71]. tupling bases, graph tuple class expressions, and control conditions form the ingredients of graph tuple transformation units. moreover, the structuring of the transformation process is achieved by an import component, i.e. every unit may import a set of other units. the transformations offered by an imported unit can be used in the transformation process of the importing festschrift bernd krieg-brückner 12 / 23 eceasst unit. the basic operation of a graph tuple transformation unit is the application of an action, which is a transformation step from one graph tuple into another where every component of the tuple is modified either by means of a rule application, or is set to some output graph of some imported unit, or remains unchanged. since action application is nondeterministic in general, a transformation unit contains a control condition that may regulate the graph tuple transformation process. moreover, a unit contains an initial graph tuple class expression and a terminal graph tuple class expression. the former specifies all possible graph tuples a transformation may start with and the latter specifies all graph tuples a transformation may end with. hence, every transformation of an n-tuple of graphs with action sequences has to take into account the control condition of the unit as well as the initial and terminal graph tuple class expressions. a tuple of sets of rules, a set of imported units, a control condition, an initial graph tuple class expression, and a terminal graph tuple class expression form the body of a graph tuple transformation unit. all components in the body must be consistent with the tupling base of the unit. formally, let tb = (b1,...,bn) be a tupling base. a graph tuple transformation unit gttu with tupling base tb is a pair (decl,body) where decl is the declaration part of gttu and body is the body of gttu. the declaration part is of the form in → out on tb where in : [k] → [n] and out : [l] → [n] are mappings with k,l ∈ n.1 the body of gttu is a system body = (i,u,r,c,t ) where i and t are graph tuple class expressions over tb, u is a set of imported graph tuple transformation units, r is a tuple of rule sets (r1,...,rn) such that ri ⊆ rbi for i = 1,...,n, and c is a control condition over tb. the numbers k and l of gttu are also denoted by kgttu and lgttu. moreover, the ith input class gbin(i) of gttu is also denoted by ingttu(i) for i = 1,...,k and the jth output class gbout( j) by outgttu( j) for j = 1,...,l. as in the case of graph transformation units, we assume that the import structure of graph tuple transformation units is acyclic. 3.5 examples of graph tuple transformation units in the following we illustrate the concept of graph tuple transformation units with examples from the area of automata theory. example 1 the tupling base of the following example of a transformation unit is the tuple (bstring,bdfsg,bbool). the rule base bstring is (string,{read(x) | x ∈ i} ∪ {is-empty},=⇒), where the rule is-empty checks whether the graph to which it is applied represents the empty string. it has equal leftand right-hand sides consisting of a node with an beginand an end-flag. is-empty : begin end 1 ::= begin end 1 the rule base bdfsg is (dfsg,{go(x) | x ∈ i} ∪ {is-final},=⇒). the rule is-final checks whether the current state of a deterministic finite state graph is a final state, resetting it to the start state in that case, and can be depicted as follows. 1 for a natural number n ∈ n, [n] denotes the set {1,...,n}. 13 / 23 volume 62 (2013) graph tuple transformation is-final : start final current 1 2 start final current 1 2 ::= the rule base bbool contains the graph class bool which consists of the two graphs true and false. the class of rules of bbool consists of the four rules set-to-true : 1 false ::= 1 true is-true : 1 true ::= 1 true set-to-false : 1 true ::= 1 false is-false : 1 false ::= 1 false where set-to-true changes a false-flag into a true-flag, set-to-false does the same the other way round, is-true checks whether a graph of type bool is equal to true, and is-false checks the same for false. now we can define the unit recognize shown in figure 9. it has as input graphs a string graph recognize decl (string,dfsg,−) → (−,−,bool) on (bstring,bdfsg,bbool) initial (string,start,false) rules (rbstring ,rbdfsg ,{set-to-true}) cond a1!; a2! where a1 = {(read(x),go(x),−) | x ∈ i} and a2 = (is-empty,is-final,set-to-true) terminal (string,dfsg,bool) figure 9: a unit with empty import and a state graph of a deterministic finite automaton and as output graph a boolean value. the mapping in of the declaration part of recognize is defined by in : [2] → [3] with in(1) = 1 and in(2) = 2. we use the more intuitive tuple notation (string,dfsg,−) for this. the mapping out is denoted by (−,−,bool) which means that out : [1] → [3] is defined by out(1) = 3. hence, inrecognize(1) = string, inrecognize(2) = dfsg, and outrecognize(1) = bool. the initial graph tuple class expression is (string,start,false), i.e. it admits all triples (g1,g2,g3) ∈ string × dfsg × bool where the current-edge of g2 points to the start state and g3 is equal to false. the rules are restricted to the tuple (rbstring ,rbdfsg ,{set-to-true}). hence, just one rule from bbool is admitted. the control condition requires to apply first the action a1 as long as possible and then the action a2 as long as possible, where a1 applies read(x) to the first component of the current graph tuple and go(x) to the second component (for any x ∈ i). the action a2 sets the third component to true if the current string is empty, the current festschrift bernd krieg-brückner 14 / 23 eceasst state of the state graph is a final state, and the third component is equal to false. this is the case where the string represented by the input string graph can be recognized by the automaton corresponding to the input state graph. note that a2 can be applied at most once because of set-to-true, and only in the case where a1 cannot be applied anymore because of is-empty. in particular, if the string of the input string graph cannot be recognized by the automaton, the action a2 cannot be applied at all. the terminal graph tuple class expression does not restrict the graph types of the tupling base, i.e. it is equal to (string,dfsg,bool). the unit recognize does not import other units. example 2 the unit recognize-intersection shown in figure 10 is an example of a unit with a non-empty import component. it has as input graphs a string graph and two state graphs of recognize-intersection decl (string,dfsg,dfsg,−,−,−) → (−,−,−,−,−,bool) on (bstring,bdfsg,bdfsg,bbool,bbool,bbool) initial (string,dfsg,dfsg,bool,bool,false) uses recognize rules (/0, /0, /0,{is-true},{is-true},{set-to-true}) cond a1; a2! where a1 = (−,−,−,recognize(1,2),recognize(1,3),−) and a2 = (−,−,−,is-true,is-true,set-to-true) terminal (string,dfsg,dfsg,bool,bool,bool) figure 10: a unit with imported units combined in an action deterministic finite state automata. the output graph represents again a boolean value. the tupling base of recognize-intersection is the six-tuple (bstring,bdfsg,bdfsg,bbool,bbool,bbool). the mapping in of the declaration part requires to take a string graph from the first rule base of the tupling base, one state graph from the second and one from the third rule base as input graphs. the mapping out requires to take a graph from the last rule base as output graph. the unit recognize-intersection imports the above unit recognize and has as local rules is-true and set-to-true where is-true can be applied to the fourth and the fifth component of the current graph tuples and set-to-true to the sixth component. the control condition requires the following. 1. apply recognize to the first and the second component and write the result into the fourth component and 2. apply recognize to the first and the third component and write the result into the fifth component. 3. if then possible apply the rule is-true to the fourth and the fifth component and the rule set-to-true to the sixth component. this means that in the first point recognize is applied to the input string graph and the first one of the input state graphs. in the second point recognize must be applied to the input string 15 / 23 volume 62 (2013) graph tuple transformation graph and to the second state graph of a deterministic finite automaton. these two transformations can be performed in parallel within one and the same action denoted by the tuple (−,−,−,recognize(1,2),recognize(1,3),−). (the precise semantics of this action will be given in the next subsection where actions and their semantics are introduced formally.) the rule application performed in the third point corresponds to applying the basic action a2. since the initial graph tuple class expression requires that the sixth graph represent false, this means one application due to set-to-true. the terminal graph tuple class expression admits all graph tuples of the tupling base. example 3 let i be the alphabet consisting of the symbols a,b, let l,la,lb be regular languages, and let subst : i → p(i∗) be a substitution with subst(a) = la and subst(b) = lb. the aim of the following example is to model the recognition of the substitution language subst(l) = {subst(w) | w ∈ l} based on a description of l,la,lb by deterministic finite automata. (the model can of course be extended to arbitrarily large alphabets.) first, consider the unit reduce shown in figure 11. it takes a string graph and a state graph of reduce decl (string,dfsg) → (string,−) on (bstring,bdfsg) initial (string,start) rules (rbstring ,rbdfsg ) cond a1 ∗; a2 where a1 = {(read(x),go(x)) | x ∈ i} and a2 = (−,is-final) terminal (string,dfsg) figure 11: a unit that returns a modified input graph as output a deterministic finite automaton as input, requiring through the initial component that the state graph be in its start state. it then reduces the string graph by arbitrarily often applying actions of the form (read(x),go(x)), i.e. by consuming an arbitrarily large prefix of the string and changing states accordingly in the state graph, and returns the residue of the string graph as output, but only if the consumed prefix is recognized by the state graph, i.e. only if the action (−,is-final) is applied exactly once. the unit recognize-substitution shown in figure 12 makes use of reduce in order to decide whether an input string graph is in the substitution language given as further input by three state graphs of deterministic finite automata a,aa,ab that define l,la,lb, in that order. initially, the state graphs must once again be in their respective start states and the value in the output component is false. the idea is to guess, symbol by symbol, a string w ∈ l such that the input string is in subst(w). if the next symbol is guessed to be a, the action (reduce(1,3),go(a),−,−,−) is applied that runs aa to delete a prefix belonging to la from the input string (reduce(1,3)) and simultaneously executes the next state transition for a in a (go(a)). the second action (reduce(1,4),go(b),−,−,−) works analogously for the symbol b. thus, recognize-substitution is an example of a unit that combines an imported unit (reduce) and a rule (go(x)) in an action. festschrift bernd krieg-brückner 16 / 23 eceasst recognize-substitution decl (string,dfsg,dfsg,dfsg,−) → (−,−,−,−,bool) on (bstring,bdfsg,bdfsg,bdfsg,bbool) initial (string,start,start,start,false) uses reduce rules ({is-empty},rbdfsg , /0, /0,{set-to-true}) cond (a1|a2) ∗; a3 where a1 = {(reduce(1,3),go(a),−,−,−), a2 = {(reduce(1,4),go(b),−,−,−), and a3 = (is-empty,is-final,−,−,set-to-true) terminal (string,dfsg,dfsg,bool,bool,bool) figure 12: a unit with imported units combined in an action finally, a mandatory application of the action (is-empty,is-final,−,−,set-to-true) produces the output value true, but only if the input string is completely consumed and a is in some final state. it may be noted that even though the finite state graphs are deterministic, there are two sources of nondeterminism in this model: the symbols of the supposed string w ∈ l must be guessed as well as a prefix of the input string for each such symbol. consequently, the model admits only tuples with output true in its semantics. 3.6 semantics of graph tuple transformation units graph tuple transformation units transform initial graph tuples to terminal graph tuples by applying a sequence of actions so that the control condition is satisfied. moreover, the mappings in and out of the declaration part prescribe for every such transformation the input and output graph tuples of the unit. hence, the semantics of a graph tuple transformation unit can be defined as a k,l-relation between input and output graphs. let gttu = (in → out on tb,(i,u,r,c,t )) be a graph tuple transformation unit with tb = (b1,...,bn), in : [k] → [n], out : [l] → [n], and r = (r1,...,rn). if u = /0, gttu transforms internally a tuple g ∈ gb1 ×···× gbn into a tuple h ∈ gb1 ×···× gbn if and only if 1. g is an initial graph tuple and h is a terminal graph tuple, i.e. (g,h) ∈ sem(i)×sem(t ); 2. h is obtained from g via a sequence of basic actions over (r1,...,rn), i.e. g ∗ −→ act (gttu) h where act (gttu) is the set of all basic actions a = (a1,...,an) of tb such that for i = 1,...,n, ai ∈ ri if ai 6= − , and 3. the pair (g,h) is allowed by the control condition, i.e. (g,h) ∈ sem(c). if the graph tuple transformation unit gttu has a non-empty import, the imported units can also be applied in a transformation from g to h . this requires that we extend the notion of basic actions so that calls of imported units are allowed, leading to the notion of (general) actions. 17 / 23 volume 62 (2013) graph tuple transformation formally, an action of gttu is a tuple a = (a1,...,an) such that for i = 1,...,n we have ai ∈ ri, or ai = −, or ai is of the form (u,input,out put) where u ∈ u , input : [ku] → [n] with gbin put( j) ⊆ inu( j) for j = 1,...,ku, and out put ∈ [lu] with outu(out put) ⊆ gbi . in the latter case, we denote ai by u(input(1),... ,input(ku))(out put), and shorter by u(input(1),... ,input(ku)) if u has a unique output, i.e. lu = 1 = out put. the application of an action a = (a1,...,an) to a current graph tuple of n graphs works as follows: as for rule application, if ai is a rule of ri, it is applied to the ith graph. if ai is equal to −, the ith graph remains unchanged. the new aspect is the third case where ai is of the form (u,input,out put). in this case, the mapping input : [ku] → [n] determines which graphs of the current tuple of graphs should be chosen as input for the imported unit u. the output out put ∈ [lu] specifies which component of the computed output graph tuple of u should be assigned to the ith component of the graph tuple obtained from applying the unit u to the input graphs selected by input. for example the action (−, −, −, recognize(1,2), recognize(1,3), −) of the graph tuple transformation unit recognize-intersection has as semantics every pair ((g1,...,g6),(h1,...,h6)) such that gi = hi for i ∈ {1,2,3,6}, h4 is the output of recognize applied to (g1,g2), and h5 is the output of recognize applied to (g1,g3). formally, assume that every imported unit u of gttu defines a semantic relation sem(u) ⊆ (inu(1)×···× inu(ku))×(outu(1)×··· × outu(lu)). then every pair ((g1,...,gn),(h1,...,hn)) of graph tuples over tb is in the semantics of an action a = (a1,...,an) of gttu if for i = 1,...,n: • gi =⇒ ai hi if ai ∈ ri, • gi = hi if ai = −, and • hi = h ′ out put if ai = (u,input,out put) and ((ginput(1),...,ginput(ku)), (h′1,...,h ′ lu )) ∈ sem(u). the set of all actions of gttu is denoted by act (gttu) and the semantics of an action a ∈ act (gttu) by sem(a). now we can define the semantics of gttu as follows. every pair ((g1,...,gk),(h1,...,hl)) is in sem(gttu) if there is a pair (ḡ,h̄) with ḡ = (ḡ1,...,ḡn), h̄ = (h̄1,...,h̄n) such that the following holds. • (g1,...,gk) = (ḡin(1),...,ḡin(k)), • (h1,...,hl) = (h̄out(1),...,h̄out(l)), • (ḡ,h̄) ∈ (sem(i)× sem(t ))∩ sem(c), • (ḡ,h̄) ∈ ( ⋃ a∈act (gttu) sem(a)) ∗. for example, the semantics of the unit recognize consists of all pairs of the form ((g1,g2),(h)) where g1 is a string graph, g2 is a state graph of a deterministic finite automaton with its start festschrift bernd krieg-brückner 18 / 23 eceasst state as current state, and h = true if g1 is recognized by g2; otherwise h = false. the semantics of the unit recognize-intersection consists of every pair ((g1,g2,g3),(h)) where g1 is a string graph, g2 and g3 are state graphs of deterministic finite automata with their respective start state as current state, and h = true if g1 is recognized by g2 and g3; otherwise h = false. the semantics of the unit reduce contains all pairs ((g1,g2),(g3)) where g1 and g3 are string graphs and g2 is a state graph of a deterministic finite automaton with its start state as current state such that g3 represents some suffix of the string represented by g1 and g2 recognizes the corresponding “prefix” of g1. the semantics of recognize-substitution contains all pairs ((g1,g2,g3,g4),(true)) where g1 represents a string in the substitution language subst(l), g2 recognizes the language l, and g3 and g4 recognize the languages subst(a) and subst(b), respectively. 4 conclusion in this paper, we have introduced the new concept of graph tuple transformation units, which is helpful to specify transformations of combinations of various kinds of graphs simultaneously and in a structured way. to this aim a graph tuple transformation unit contains an import component which consists of a set of other graph tuple transformation units. the semantic relations offered by the imported units are used by the importing unit. the nondeterminism inherent to rule-based graph transformation can be reduced with control conditions and graph tuple class expressions. graph tuple transformation units generalize transformation units [kk99] in the following aspects. (1) whereas a transformation unit specifies a binary relation on a single graph type, a graph tuple transformation unit specifies a k,l-relation of graphs of different types. (2) the transformation process in transformation units is basically sequential whereas in graph tuple transformation units the component graphs are transformed in parallel. further investigation of graph tuple transformation units may concern the following aspects. (1) we used graph-transformational versions of the truth values, numbers, and strings, but one may like to combine graph types directly with arbitrary abstract data types, i.e., without previously modeling the abstract data types as graphs. (2) in the presented definition, we consider acyclic import structures. their generalization to networks of graph tuple transformation units with an arbitrary import structure may be an interesting task. (3) in the presented approach the graphs of the tuples do not share any common parts and are not directly interrelated with each other in any other way while the components of the actions can share information and can be interconnected in this way. but it may also be of interest to consider graph tuple transformation where some relations (like morphisms) can be explicitly specified between the different graphs of a tuple. (4) the concepts of pair grammars [pra71] and triple graph grammars [sch94] are similarly motivated as graph tuple transformation units so that a close and detailed comparison may be worthwhile. as our notion of control conditions is very general, it is more or less obvious that pair and triple grammars are special cases of graph tuple transformation units. but it will need more considerations to figure out which consequences this observation has. (5) as graph tuple transformation provides a particular form of parallelism by allowing the simultaneous change of components, it may be enlightening to compare and relate it with other graph-transformational approaches to parallelism. (6) finally, case studies of graph tuple transformation units should 19 / 23 volume 62 (2013) graph tuple transformation also be worked out that allow to get experience with the usefulness of the concept for the modeling of (data-processing) systems and of systems from other application areas as well as of model transformations, in particular. acknowledgement we are grateful to the referees for their valuable remarks. bibliography [bk99] d. basin, b. krieg-brückner. formalization of the development process. in astesiano et al. (eds.), algebraic foundations of systems specification. ifip state-ofthe-art reports, pp. 521–562. springer verlag, 1999. [bkpt00] p. bottoni, m. koch, f. parisi-presicce, g. taentzer. consistency checking and visualization of ocl constraints. in evans et al. (eds.), proc. uml 2000 the unified modeling language. advancing the standard. third international conference, york, uk, october 2000, proceedings. lecture notes in computer science 1939, pp. 294– 308. 2000. [bmst99] r. bardohl, m. minas, a. schürr, g. taentzer. application of graph transformation to visual languages. in ehrig et al. (eds.), handbook of graph grammars and computing by graph transformation, vol. 2: applications, languages and tools. pp. 105–180. world scientific, singapore, 1999. [ceh+97] a. corradini, h. ehrig, r. heckel, m. löwe, u. montanari, f. rossi. algebraic approaches to graph transformation part i: basic concepts and double pushout approach. pp. 163–245 in [roz97]. [dhk97] f. drewes, a. habel, h.-j. kreowski. hyperedge replacement graph grammars. in rozenberg (ed.), handbook of graph grammars and computing by graph transformation. vol. 1: foundations. chapter 2, pp. 95–162. world scientific, 1997. [dhk02] r. depke, r. heckel, j. m. küster. formal agent-oriented modeling with uml and graph transformation. science of computer programming 44:229–252, 2002. [ee08] h. ehrig, c. ermel. semantical correctness and completeness of model transformations using graph and rule transformation. in ehrig et al. (eds.), proc. 4th international conference on graph transformations (icgt’08). lecture notes in computer science 5214, pp. 194–210. 2008. [eee+07] h. ehrig, k. ehrig, c. ermel, f. hermann, g. taentzer. information preserving bidirectional model transformations. in dwyer and lopes (eds.), proc. 10th international conference on fundamental approaches to software engineering (fase’10). lecture notes in computer science 4422, pp. 72–86. 2007. [eept06] h. ehrig, k. ehrig, u. prange, g. taentzer (eds.). fundamentals of algebraic graph transformation. springer, 2006. festschrift bernd krieg-brückner 20 / 23 eceasst [eg07] k. ehrig, h. giese (eds.). proceedings of the sixth international workshop on graph transformation and visual modeling techniques (gt-vmt 2007). electronic communications of the easst 6. http://eceasst.cs.tuberlin.de/index.php/eceasst/issue/archive, 2007. [ehhs00] g. engels, j. h. hausmann, r. heckel, s. sauer. dynamic meta modeling: a graphical approach to the operational semantics of behavioral diagrams in uml. in evans et al. (eds.), proc. uml 2000 – the unified modeling language. advancing the standard. lecture notes in computer science 1939, pp. 323–337. 2000. [ehk+97] h. ehrig, r. heckel, m. korff, m. löwe, l. ribeiro, a. wagner, a. corradini. algebraic approaches to graph transformation ii: single pushout approach and comparison with double pushout approach. pp. 247–312 in [roz97]. [ehk01] g. engels, r. heckel, j. küster. rule-based specification of behavioral consistency based on the uml meta-model. in gogolla and kobryn (eds.), proc. uml 2001 – the unified modeling language. modeling languages, concepts, and tools. lecture notes in computer science 2185, pp. 272–286. 2001. [er97] j. engelfriet, g. rozenberg. node replacement graph grammars. in rozenberg (ed.), handbook of graph grammars and computing by graph transformation. vol. 1: foundations. chapter 1, pp. 1–94. world scientific, 1997. [fntz00] t. fischer, j. niere, l. torunski, a. zündorf. story diagrams: a new graph transformation language based on uml and java. in ehrig et al. (eds.), proc. theory and application to graph transformations. lecture notes in computer science 1764, pp. 296–309. 2000. [fra03] d. s. frankel. model driven architecture. applying mda to enterprise computing. wiley, indianapolis, indiana, 2003. [gk07] h. giese, f. klein. systematic verification of multi-agent systems based on rigorous executable specifications. international journal on agent-oriented software engineering (ijaose) 1(1):28–62, 2007. [hkk08] k. hölscher, r. klempien-hinrichs, p. knirsch. undecidable control conditions in graph transformation units. electronic notes in theoretical computer science 195:95–111, 2008. [hp01] a. habel, d. plump. computational completeness of programming languages based on graph transformation. in honsell and miculan (eds.), proc. foundations of software science and computation structures (fossacs 2001). lecture notes in computer science 2030, pp. 230–245. 2001. [hzg06] k. hölscher, p. ziemann, m. gogolla. on translating uml models into graph transformation systems. journal of visual languages and computing 17(1):78– 105, 2006. 21 / 23 volume 62 (2013) graph tuple transformation [jan99] d. janssens. actor grammars and local actions. in ehrig et al. (eds.). pp. 57–106. world scientific, singapore, 1999. [kgkz09] s. kuske, m. gogolla, h.-j. kreowski, p. ziemann. towards an integrated graphbased semantics for uml. software and systems modeling 8(3):385–401, 2009. [kk99] h.-j. kreowski, s. kuske. graph transformation units with interleaving semantics. formal aspects of computing 11(6):690–723, 1999. [kkk04] r. klempien-hinrichs, h.-j. kreowski, s. kuske. typing of graph transformation units. in ehrig et al. (eds.), proc. second international conference on graph transformations (icgt’04). lecture notes in computer science 3256, pp. 112–127. 2004. [kkr08] h.-j. kreowski, s. kuske, g. rozenberg. graph transformation units – an overview. in degano et al. (eds.), concurrency, graphs and models. lecture notes in computer science 5065, pp. 57–75. 2008. [kks97] h.-j. kreowski, s. kuske, a. schürr. nested graph transformation units. international journal on software engineering and knowledge engineering 7(4):479–502, 1997. [kks07] f. klar, a. königs, a. schürr. model transformation in the large. in crnkovic and bertolino (eds.), proc. 6th joint meeting of the european software engineering conference and the acm sigsoft international symposium on foundations of software engineering. pp. 285–294. acm, 2007. [kus00] s. kuske. more about control conditions for transformation units. in ehrig et al. (eds.), proc. theory and application of graph transformations. lecture notes in computer science 1764, pp. 323–337. 2000. [kus01] s. kuske. a formal semantics of uml state machines based on structured graph transformation. in gogolla and kobryn (eds.), proc. uml 2001 – the unified modeling language. modeling languages, concepts, and tools. lecture notes in computer science 2185, pp. 241–256. 2001. [küs06] j. m. küster. definition and validation of model transformations. software and system modeling 5(3):233–259, 2006. [lt04] j. de lara, g. taentzer. automated model transformation and its validation using atom 3 and agg. in diagrams. lecture notes in computer science 2980, pp. 182– 198. 2004. [nag96] m. nagl (ed.). building tightly integrated software development environments: the ipsen approach. lecture notes in computer science 1170. springer-verlag, 1996. [pe93] r. plasmeijer, m. van eekelen. functional programming and parallel graph rewriting. addison-wesley, 1993. festschrift bernd krieg-brückner 22 / 23 eceasst [pra71] t. w. pratt. pair grammars, graph languages and string-to-graph translations. journal of computer and system sciences 5:560–595, 1971. [ps00] d. c. petriu, y. sun. consistent behaviour representation in activity and sequence diagrams. in evans et al. (eds.), proc. uml 2000 – the unified modeling language. advancing the standard. lecture notes in computer science 1939, pp. 359–368. 2000. [roz97] g. rozenberg (ed.). handbook of graph grammars and computing by graph transformation, vol. 1: foundations. world scientific, singapore, 1997. [sch94] a. schürr. specification of graph translators with triple graph grammars. in mayr et al. (eds.), proc. 20th int. worhshop on graph-theoretic concepts in computer science. lecture notes in computer science 903, pp. 151–163. 1994. [sch97] a. schürr. programmed graph replacement systems. pp. 479–546 in [roz97]. [sk08] a. schürr, f. klar. 15 years of triple graph grammars. in ehrig et al. (eds.), proc. 4th international conference on graph transformations (icgt’08). lecture notes in computer science 5214, pp. 411–425. 2008. [spe93] m. r. sleep, r. plasmeijer, m. van eekelen (eds.). term graph rewriting. theory and practice. wiley & sons, chichester, 1993. [tkkt07] i. j. timm, p. knirsch, h.-j. kreowski, a. timm-giel. autonomy in software systems. in hülsmann and windt (eds.), understanding autonomous cooperation & control in logistics the impact on management, information and communication and material flow. pp. 255–273. springer, berlin heidelberg new york, usa, 2007. [vb07] d. varró, a. balogh. the model transformation language of the viatra2 framework. science of computer programming 68(3):214–234, 2007. [wir71] n. wirth. program development by stepwise refinement. communications of the acm 14(4):221–227, 1971. 23 / 23 volume 62 (2013) introduction graph transformation graphs rules and rule applications graph class expressions control conditions transformation units interleaving semantics of transformation units graph tuple transformation basic actions graph tuple class expressions control conditions for graph tuple transformation graph tuple transformation units examples of graph tuple transformation units semantics of graph tuple transformation units conclusion on the decidability of model checking ltl fragments in monotonic extensions of petri nets electronic communications of the easst volume 64 (2013) proceedings of the xiii spanish conference on programming and computer languages (prole 2013) on the decidability of model checking ltl fragments in monotonic extensions of petri nets marı́a martos-salgado and fernando rosa-velardo 18 pages guest editors: clara benac earle, laura castro, lars-åke fredlund managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst on the decidability of model checking ltl fragments in monotonic extensions of petri nets marı́a martos-salgado1 and fernando rosa-velardo2∗ 1 mrmartos@ucm.es universidad complutense de madrid 2 fernandorosa@sip.ucm.es universidad complutense de madrid abstract: we study the model checking problem for monotonic extensions of petri nets, namely for two extensions of petri nets: reset nets (nets in which places can be emptied by the firing of a transition with a reset arc) and ν -petri nets (nets in which tokens are pure names that can be matched with equality and dynamically created). we consider several fragments of ltl for which the model checking problem is decidable for p/t nets. we first show that for those logics, model checking of reset nets is undecidable. we transfer those results to the case of ν -petri nets. in order to cope with these negative results, we define a weaker fragment of ltl, in which negation is not allowed. we prove that for that fragment, the model checking of both reset nets and ν -petri nets is decidable, though with a non primitive recursive complexity. finally, we prove that the model checking problem for a version of that fragment with universal interpretation is undecidable even for p/t nets. keywords: ltl, model checking, petri nets, decidability, complexity 1 introduction temporal logics [4] have been established as a very expressive formalism for the specification of properties of computational concurrent systems. model checking is the problem of deciding if a given system satisfies a given temporal formula. for infinite state systems the model checking problem is undecidable in general [15]. a very well known formalism for infinite state concurrent systems is that of petri nets [6]. among them, place/transition nets (p/t nets) are potentially infinite state, but their expressive power is below minsky machines (e.g., reachability is decidable for them [8]). decidability and complexity of the model checking problem for p/t nets are well studied, and the corresponding decidability frontiers are well settled [13, 9, 12, 8]. roughly speaking, model checking of p/t nets is undecidable for any branching-time logic, while for linear time logics, “event-based” ltl is decidable, though “state-based” ltl is undecidable. in the last two decades, several monotonic extensions of petri nets have appeared in the literature. these extensions usually consist either on the extension of the firing rule of p/t nets, ∗ authors supported by the spanish projects strongsoft tin2012-39391-c04-04 and prometidos s2009/tic-1465. 1 / 18 volume 64 (2013) mailto:mrmartos@ucm.es mailto:fernandorosa@sip.ucm.es on the decidability of model checking ltl fragments in monotonic extensions of petri nets or on the use of colours, that is, distinguishable tokens. we consider two simple extensions of p/t nets, one in each group: reset nets [7] and ν -petri nets (ν -pn) [21]. in reset nets the firing of a transition can empty some places. their modeling capabilities are discussed for instance in [14]. tokens in ν -pns are pure names, that can be created fresh, moved along the net and used to restrict the firing of transitions with name matching. names can be seen as process identifiers [19], so that ν -pn can serve as the basis of models in which an unbounded number of components (which are in turn unbounded) synchronize. for example, they can be used to model resource-constrained workflow nets, an extension of workflow nets in which an arbitrary number of instances of the workflow can be executed concurrently [11]. in [5], they are used to give a semantics to an extension of bpel [16] with instance isolation. in this paper we study the decidability of the model checking problem of these models. more precisely, we consider the logics for which model checking of p/t nets is decidable, and we study their decidability for the two extensions. in particular, we study lt l f , which is the fragment of ltl that uses only first as basic predicate [9], l (f), the fragment of ltl in which negation is only applied to basic predicates (not to operators), and the operators are x (next), f (eventually), ∧ and ∨ [12]; and l (gf), which is the fragment of ltl in which the only allowed composed operator is gf (globally future), the operators are f, ∨ and ∧ and negation is only applied to basic predicates [13]. unfortunately, we conclude that the decidability results for p/t nets cannot be adapted, so that model checking for any of the logics considered is undecidable. in particular, we reduce lt l f model checking of lossy inhibitor nets, which is undecidable, to lt l f model checking of reset nets. moreover, we prove that repeated coverability and reachability, which are undecidable for reset nets, can be expressed in l (gf) and l (f) respectively. as a first step to mitigate the previous undecidability result, we consider a fragment of ltl weaker than all the logics considered so far in which, in particular, we do not allow negations. we call that logic fcov. we prove that the model checking problem for this logic is decidable for both models. in some of the subclasses of ltl considered in the literature [13, 12] a formula is said to be satisfied if there exists one run that satisfies it, as opposed to the more standard definition of ltl in which all runs are required to satisfy the formula. even though the two interpretations are equivalent when negation can be used without restriction, this is not the case for the considered subclasses of ltl, neither for fcov. we justify this definition by proving that already for p/t nets, fcov model checking is undecidable under the universal interpretation. table 1 summarizes the results on model checking of p/t nets, reset nets and ν -pns. by “+” (resp. -) we denote that the model checking problem for the considered logic is decidable (resp. undecidable). if the references of the results are not given, then the result is either new (the ones with signs in bold letters) or follows directly from other results of the table. outline: the rest of the paper is structured as follows. section 2 presents some basic results and notations we use throughout the paper. section 3 proves undecidability of the model checking problem for the considered logics, for reset nets and ν -pn. section 4 defines fcov and proves decidability of the model checking problem for reset nets and ν -pn, and undecidability for p/t nets in the universal case. in section 5 we present our conclusions. proc. prole 2013 2 / 18 eceasst p/t reset ν -pn lt l [9] lt l f + [9] [3] l (gf) + [13] l (f) + [12] fcov + + + ∀fcov table 1: summary of results. those in bold signs are the new contributions of this paper. 2 preliminaries a quasi order (qo) is a reflexive and transitive binary relation. for a qo ≤, we write a < b if a ≤ b and b 6≤ a. labelled transition systems. a transition system is a tuple s = (s,l,→,init), where s is a (possibly infinite) set of states, l is a set of labels, init ∈ s is the initial state and →⊆ s × l × s 1. given two states s1,s2 ∈ s and a ∈ l, we write s1 a → s2 instead of (s1,a,s2) ∈→, and s1 → s2 if s1 b → s2 for some b ∈ l. we denote by → ∗ the reflexive and transitive closure of → and by →+ the transitive closure of →. a run π of s is any sequence s0 a0 → s1 a1 → s2... such that si ai → si+1 for i ≥ 0. we define the length of a run π as n ∈ n if π = s0 a0 → s1 a1 → ... an → sn is a finite run, and ∞ if π is an infinite run. the reachability problem consists in deciding for a given state s f whether init →∗ s f . if s is endowed with a qo ≤ we can define the coverability problem, that consists in deciding, given s f ∈ s, whether some s ≥ s f is reachable. then, we say that s covers s f . the repeated coverability problem is the problem of deciding whether a given state is covered infinitely often in some infinite run starting in init, that is, for a given s there is an infinite run init →+ s1 → + s2 → + ... such that s ≤ si for all i ≥ 1. multisets. given a (possibly infinite) arbitrary set a, we denote by a⊕ the set of finite multisets over a, that is, the mappings m : a → n for which su p p(m) = {a ∈ a | m(a) > 0} is finite. when needed, we identify each conventional set with the multiset defined by its characteristic function, and use set notation for multisets when convenient, with repetitions to account for multiplicities greater than one. moreover, given two sets a and b, and an injection α : a → b, sometimes we interpret α as the function α : a⊕ → b⊕ such that given ma ∈ a, α(ma) = mb, where for each b ∈ b, mb(b) = n > 0 if there exists a ∈ a with α(a) = b and ma(a) = n, and mb(b) = 0 otherwise. given two multisets m1,m2 ∈ a ⊕ we denote by m1 +m2 the multiset defined by (m1 +m2)(a) = m1(a) + m2(a). we define multiset inclusion as m1 ⊆ m2 if m1(a) ≤ m2(a) for all a ∈ a. if m1 ⊆ m2, we can define m2 − m1, taking (m2 − m1)(a) = m2(a)− m1(a). we denote by /0 ∈ a ⊕ the empty multiset, given by /0(a) = 0 for all a ∈ a. petri nets. a place/transition net (p/t net for short) is a tuple n = (p,t,f) where p is a finite set of places, t is a finite set of transitions (with p ∩ t = /0) and f : (p × t ) ∪ (t × p) → n is 1 we use transition labels to homogeneously define logics based on states and events. 3 / 18 volume 64 (2013) on the decidability of model checking ltl fragments in monotonic extensions of petri nets • •a ab•• p q r t → • •a a• p q r t figure 1: the firing of a transition in a p/t net. the flow function. given t ∈ t , the multiset of preconditions of t is •t ∈ p⊕ given by (•t)(p) = f(p,t). analogously, the postconditions of t are given by (t•)(p) = f(t, p). a marking is any m ∈ p⊕. for petri nets we consider the order between markings given by multiset inclusion. this order defines the standard coverability problem for petri nets. we say that a transition t is enabled at a marking m if for each p ∈ p, m(p) ≥ f(p,t). in that case, t can be fired from m, reaching a new marking m′, which is denoted by m t → m′, where m′ is given by m′(p) = (m(p)− f(p,t)) + f(t, p). the reachability, the coverability and the repeated coverability problems are all decidable for p/t nets [8]. in the rest of this paper, we represent places as circles, transitions as rectangles, the flow function as arrows and markings as tokens inside places. the arcs which represent the flow function are not labelled by any constant representing the corresponding values of f . that is because for all p ∈ p, t ∈ t with an arc going from p to t (resp. from t to p) in figures, we assume f(p,t) = 1 (resp. f(t, p) = 1). example 1 in the p/t net in the left-hand side of fig. 1, transition t is enabled, so it can be fired reaching the marking depicted in the right-hand side. tokens have been consumed from p and r, and a token has been produced in q. as there is not a priority order over transitions, note that from the marking represented in the left-hand side, the other transition could have been fired instead of t, reaching a marking with a token in each place of the net. now, we explain two extensions of p/t nets, namely reset nets and inhibitor nets. both of them are defined from p/t nets by adding special arcs: reset arcs, which empty a place, and inhibitor arcs, which add to the enabling conditions the requirement that a certain place is empty. for both extensions, the concepts of preconditions, postconditions and marking are analogous to those for p/t nets. a reset net is a tuple n = (p,t,f,r), where (p,t,f) is a p/t net and r ⊆ p × t is a relation containing the so called reset arcs. the enabled transitions at a marking are defined as for p/t nets. an enabled transition t can be fired from a marking m reaching m′ given by: m′(p) = { (m(p)− f(p,t))+ f(t, p) if (p,t) /∈ r f(t, p) if (p,t) ∈ r notice that if (p,t) ∈ r and f(t, p) = 0 (i.e., t does not put any token in p) then p has no tokens after the firing of t (hence p is reset). example 2 focus on fig. 2. the double arc represents a reset arc from place r to t, that is, (r,t) ∈ r. then, transition t is enabled in the marking represented in the net in the left-hand side proc. prole 2013 4 / 18 eceasst • •a ab•• p q r t′ t → • •a a• p q r t′ t figure 2: the firing of a transition in a reset net. ab ab a bc be p1 p3 p2 p4 xy xν1 y ν1ν2 → aa ad a c de (d,e fresh) p1 p3 p2 p4 xy xν1 y ν1ν2 figure 3: a simple ν -pn of the figure, and it can be fired, reaching the marking depicted in the right. all tokens in place r have been consumed in the firing of t due to the presence of the reset arc. note that transition t′ is also enabled in the marking represented in the net in the left-hand side. transitions with reset arcs do not have any priority over the rest of the enabled ones. therefore, transition t′ could be fired from the first marking too. an inhibitor net is a tuple n = (p,t,f,i) where n = (p,t,f) is a p/t net, and i ⊆ p × t is a relation containing the inhibitor arcs (also called zero tests). we say that a transition t is enabled at a marking m if: • for each p ∈ p, m(p) ≥ f(p,t) and • for each (q,t) ∈ i, m(q) = 0 (place q is empty). then, t can be fired from m, reaching the marking m′ given by m′(p) = (m(p)−f(p,t))+f(t, p) (as for p/t nets) 2. inhibitor nets with two inhibitor arcs are already turing complete [15], though, interestingly, inhibitor nets with only one inhibitor arc are not [18]. ν -pn. another way in which p/t nets are extended in the literature is by considering distinguishable tokens. perhaps the most simple extension of p/t nets with (arbitrarily many) distinguishable tokens are ν -petri nets [21], that encompass unboundedly many names (via a mechanism for fresh name creation) and the unbounded occurrence of each name. let var be a set of variables, and ϒ ⊂ var a set of special variables for fresh name creation. a ν -petri net (ν -pn for short) is a tuple n = (p,t,f), where p and t are finite disjoint sets, and f : (p × t ) ∪ (t × p) → var⊕ labels every arc by a multiset of variables. we denote pre(t) = ⋃ p∈p su p p(f(p,t)) (the set of variables in pre-arcs) and post(t) = ⋃ p∈p su p p(f(t, p)) (the set of variables in post-arcs). we also take var(t) = pre(t)∪ post(t). 2 actually, it is straightforward to simulate a reset arc using inhibitor arcs, in a way preserving reachability, coverability and repeated coverability. 5 / 18 volume 64 (2013) on the decidability of model checking ltl fragments in monotonic extensions of petri nets let id be an infinite set of names. a marking of a ν -pn is a mapping m : p → id⊕ assigning to each place the multiset of tokens currently in it. we take id(m) = ⋃ p∈p su p p(m(p)), that is, the set of names in m. given a transition t ∈ t of a ν -pn, a mode for t is any injection σt : var(t) → id. as modes are injections, we can match names with equality (just by using the same variable more than once) and with inequality (by using different variables). we say that a transition t is enabled with a mode σt for a marking m, if for each ν ∈ ϒ, σt(ν) /∈ id(m) and for all p ∈ p, σt(f(p,t)) ⊆ m(p). then, t can be fired, and a new marking m′ is reached, given by m′(p) = (m(p)− σt(f(p,t)))+ σt(f(t, p)) for all p ∈ p. in that case we write m t → m′. example 3 fig. 3 depicts the ν -pn n given by n = ({p1, p2, p3, p4},{t},f) with f(p1,t) = {x,y}, f(p2,t) = {y}, f(t, p3) = {x,ν1}, f(t, p4) = {ν1,ν2}, and for (n,m) ∈ {(p3,t),(p4,t), (t, p1),(t, p2)}, f(n,m) = /0. we assume that ν1,ν2 ∈ ϒ. the initial marking is given by m0(p1) = {a,b}, m0(p2) = {b,c} and m0(p3) = m0(p4) = /0. the transition is fired with respect to a mode σ given by σ(x) = a, σ(y) = b, σ(ν1) = d and σ(ν2) = e. note that names d and e are not in the initial marking, and therefore they are created new. intuitively, each name in a marking of a ν -pn can represent a different process running in the same net. therefore, we can represent the synchronization between processes and the creation of new ones. given a marking m of a ν -pn and a set i of names, a renaming of m is any injection α : id(m) → i. we say that m ⊑ m′ ⇔ there is a renaming α of m such that α(m)(p) ⊆ m′(p) for all p ∈ p. with this order, coverability is decidable for ν -pn, though reachability is undecidable for them [21]. example 4 the marking m given by m(p1) = /0, m(p2) = /0, m(p3) = {a,d}, m(p4) = {a,c} is covered by the marking m′ on the right-hand side of fig. 3. note that, although there is not a token of name a in place p4, with the order we have defined, m is covered by m ′ by considering the renaming α , such that α(a) = d, α(d) = a and α(e) = c. finally, note that both models induce labelled transition systems in the obvious way: the states of the labelled transition systems are the markings of the nets, the set of labels is the set of transitions, and if m is the set of markings of the net, the transition relation →⊆ m × t × m is the one such that m1 t →m2 in the net ⇔ (m1,t,m2) ∈→. 3 model checking of petri net extensions temporal logics are used to specify dynamic properties of systems. they consider a set of atomic propositions (which express atomic properties), the boolean operators and several temporal operators and path quantifiers, which allow us to express temporal properties. there are mainly two kinds of temporal logics: linear time logics and branching time logics. the properties that are expressed in branching time logics are about the computation tree [1], while the ones expressed in linear time logics are about the runs [17] (where we consider the notion of run defined in the preliminaries). in this paper we focus on linear time logics because model checking of p/t nets proc. prole 2013 6 / 18 eceasst with branching time logics is undecidable, even for very simple fragments [9]. the basic temporal operators used in temporal logics are x, f and u3. the most representative example of a linear time logic is ltl. definition 1 an ltl formula is either an atomic proposition or a formula of the form ¬ϕ , ϕ ∧ ψ , ϕ ∨ ψ , xϕ , fϕ , or ϕ uψ , where ϕ and ψ are ltl formulae. first, we explain the semantics of the temporal operators informally. ltl formulae are interpreted over maximal runs, i.e., runs that are either infinite, or end in a deadlock state. let ϕ be an ltl formula, s a transition system and π a maximal run starting in s. we write s ,π � ϕ to denote that π satisfies ϕ : • s ,π � xϕ (next) holds if the property ϕ holds in the state that follows s in π . • s ,π � fϕ (eventually) holds if the property ϕ holds in some state of π . • s ,π � ϕ uψ (until) holds if there is a state of the run π such that ψ holds in that state, and ϕ holds at every preceding state on the run. we also define g (globally) as gϕ = ¬f¬ϕ , so that s ,π � gϕ holds if ϕ holds in every state of π . now, we give the formal semantics of temporal operators. let π = s0 a1 → s1 a2 → ... be a finite or infinite run of length n ∈ n∪{∞}. for n > 0, π i is defined as the suffix of the run π starting by the i-th state si. we suppose that the states and the actions of a system are labelled by the atomic propositions that they satisfy, that is, if a state s (or an action a) satisfies an atomic proposition p, then p ∈ l(s) ( p ∈ l(a) resp.), where l(s) (l(a)) represents the labels of s (a). the formal definition of the semantics of the previous operators is inductively defined as [4]: • t ,π � p ⇔ p ∈ l(s0)∨π 1 is defined (that is, the length of π is greater than 0) and ∈ l(a1). • t ,π � ¬ϕ1 ⇔ t ,π 2 ϕ1. • t ,π � ϕ1 ∨ ϕ2 ⇔ t ,π � ϕ1 or t ,π � ϕ2. • t ,π � ϕ1 ∧ ϕ2 ⇔ t ,π � ϕ1 and t ,π � ϕ2. • t ,π � xϕ1 ⇔ π 1 is defined and t ,π 1 � ϕ1. • t ,π � fϕ1 ⇔ there exists a k ≥ 0 such that t ,π k � ϕ1. • t ,π � gϕ1 ⇔ for all i ≥ 0 such that π i is defined, t ,π i � ϕ1. • t ,π � ϕ1uϕ2 ⇔ there exists a k ≥ 0 such that π k is defined, t ,π k � ϕ2 and for all 0 ≤ j < k,t ,π j � ϕ1. 3 even though f can be defined in terms of u, we prefer to include it as a primitive temporal quantifier, since we will later disallow u. 7 / 18 volume 64 (2013) on the decidability of model checking ltl fragments in monotonic extensions of petri nets note that in the previous definition, we assign the propositions they satisfy to both the states and the transition labels (a), defined for the labelled transition systems. the atomic propositions usually considered for p/t nets, are given by the following predicates: • cov(m), where m is a marking: cov(m) holds in π if the first marking in π covers m. • first(t), where t is a transition: first(t) holds in π if the first transition fired in π is t. some works consider the atomic propositions ge(p,n) and en(t) [9]. the first one expresses that there are at least n tokens in place p, and the second states that t is enabled. we will not consider them since they are equivalent to cov({ n p,..., p}) and cov(•t), respectively. according to the standard definition, a system s satisfies an ltl formula ϕ , denoted by s |= ϕ iff every maximal run of the system starting in the initial state init satisfies it (universal interpretation). the model checking problem consists in deciding, given s and ϕ , whether s |= ϕ . the model checking problem is equivalent to deciding, given s and ϕ , the existence of one run starting in init satisfying the formula (existential interpretation), provided negation can be used without restriction, since s |= ϕ (under the universal interpretation) iff s 6|= ¬ϕ (under the existential interpretation). we consider different ltl fragments, built depending on which predicates and operators we consider. definition 2 we consider the following fragments of ltl: • lt l f , the fragment of ltl that uses only first as basic predicate [9], • l (f), the fragment of ltl in which negation is only applied to basic predicates (not to operators), and the operators are x, f, ∧ and ∨ [12], • l (gf), the fragment of ltl in which the only allowed composed operator is gf, the operators are f, ∨ and ∧ and negation is only applied to basic predicates [13]. example 5 the formula ffirst(t), which expresses that t is eventually fired, is in l (f), but gfirst(t) = ¬f¬first(t), which expresses that t is always fired, is not. the formula first(t) → gffirst(t), which expresses that if t is the first transition being fired then t is fired infinitely often, is in l (gf), but ffirst(t) → gffirst(t) = ¬ffirst(t)∨ gffirst(t), which expresses that if t is eventually fired, then it is fired infinitely often, is not. in lt l f negation can be used without restriction, so that the universal and the existential interpretations are equivalent (i.e., their model checking decision problems are equivalent). however, this is not the case for l (f) and l (gf). actually, they are defined using the existential interpretation in [12, 13]. for the subclasses of ltl considered, we have the following results. • ltl model checking is undecidable (with both first and cov), but lt l f model checking is decidable (with cov only) [9]. • l (f) model checking is decidable [12] (with existential interpretation), • l (gf) model checking is decidable [13] (with existential interpretation). proc. prole 2013 8 / 18 eceasst 3.1 model checking of reset nets let us show that the three logics which are decidable for p/t nets become undecidable for reset nets. let us first consider lt l f . in [3] the model checking problem of lt l f is studied for lossy vector addition systems (lossy vas) with tests for zero, which is proved to be undecidable. let us see that we can adapt that result for reset nets. let us first define the lossy version of a transition system in general. definition 3 given a transition system s = (s,→,init) and a quasi-order ≤ over s, the lossy version of s is sl = (s,→l,init), where s1 →l s2 if and only if there exists two states s ′ 1 and s ′ 2 such that s1 ≥ s ′ 1 → s ′ 2 ≥ s2. a lossy petri net is the lossy version of some petri net. in the lossy version of a transition system, states can be spontaneously decreased. in the case of petri nets, tokens may be lost just before or after a transition is fired. example 6 focus on fig. 2. in the lossy version of the p/t net obtained by replacing the reset arc by a plain arc, despite r is not reseted by any reset arc of t, the second marking could be reached from the first one by first losing a token from r and then firing t. reset nets can simulate lossy inhibitor nets, as we prove next. this fact is used in the proof of the next result. proposition 1 lt l f model checking is undecidable for reset nets. proof. we reduce lt l f model checking for lossy inhibitor nets, which is undecidable [3], to the same problem for reset nets. let n = (p,t,f,i) be an inhibitor net. we define the reset net n′ = (p,t,f,i). we are going to prove that there is a surjective function between the runs of n and n′ that preserves the sequence of labels of runs and therefore, since the only atomic proposition in lt l f is first, given an lt l f formula ϕ , n |= ϕ iff n′ |= ϕ . notice that since n′ is a reset net, checks for zero have been replaced by resets, that is, an inhibitor arc from a place p to a transition t in n is replaced by a reset arc from p to t in n′. the following holds: • m1 t →m2 in n ⇒ there is an m ′ 2 ≥ m2 such that m1 t →m′2 in n ′: the preconditions and effects of the firings of t in n and n′ are the same, except for the fact that we have replaced inhibitor arcs by reset arcs. therefore, when a transition with an inhibitor arc in n is firing in n′, the corresponding place is reseted instead of being checked for zero. if there are tokens in such a place, all the tokens in it are removed, so there exist a possibility of losing tokens in our simulation if the place was not empty. if t has no inhibitor arc, and m1 t →m2 in n, t is enabled at m1 in n ′, and it can be fired reaching a marking greater or equal than m2, because some token may have been lost in the firing in n. now, suppose that t has some inhibitor arcs, and m1 t →m2 in n. first of all, note that if a transition is enabled in n at a marking, it is enabled in n′ at the same marking. moreover, the places with inhibitor arcs leading to t are empty in that marking. therefore, when t is fired from m1 in n ′, these places are reset (hence staying empty). therefore, the only differences in the effects of the firing of t in both nets come because of lossiness. in 9 / 18 volume 64 (2013) on the decidability of model checking ltl fragments in monotonic extensions of petri nets t t • • t t t •• •• t t t • • t t t a1 a2 b1 b2 m1 m′1 m ′ 2 m21 m22 m1 m′1 m ′ 12 m2 m′21 m′22 figure 4: from lossy inhibitor nets to reset nets particular, since t may loose tokens in n, but not in n′, m1 t →m′2 in n ′, with m′2 ≥ m2. for example, focus on the left-hand side of fig. 4. in the inhibitor nets depicted in this figure, given a place p and a transition t, we represent (p,t) ∈ i by an arc from p to t, with a circle in the place p. the marking m1 in the first lossy inhibitor net in a1 may evolve to m21 or m22 (m22 has lost the token). the corresponding reset net, depicted in a2 can only evolve t the marking m′2. however, note that m ′ 2 covers both m21 and m22. • m1 t →m2 in n ′ ⇒ m1 t →m2 in n: in particular, if n ′ resets a place, n can first loose tokens, thus emptying it, and then test for zero in that place. therefore, the transition is fireable in n (because the preconditions of the firings of t in n and n′ are the same, except for the lossiness and the inhibitor arcs) and the place is empty at the end of both firings. focus on the right-hand side of fig. 4. transition t is fireable from the marking m1 in the reset net in b1, reaching the marking m2. despite t is not fireable from m ′ 1 = m1, the lossy inhibitor net may lose tokens, reaching m′12, from which t can be fired, reaching the markings m′21 or m ′ 22. therefore, there is a surjective function between the runs of n and n′ that preserves the sequence of labels of runs. note that this holds because reset nets are monotonic, so transitions which are fired in n at a marking m which has lost tokens, can be fired from the corresponding marking m′ of n′, without loss of tokens, because m′ ≥ m. since the only atomic proposition in lt l f is first, n |= ϕ iff n′ |= ϕ and we conclude. let us now focus on the two other fragments of ltl. the case for l (gf) is straightforward: proposition 2 l (gf) model checking of reset nets is undecidable. proof. it is enough to consider that gfcov(m), which is a formula in l (gf), expresses the repeated coverability problem, which is undecidable for reset nets [2]. proc. prole 2013 10 / 18 eceasst however, not only that fragment, but the weaker fragment l (f), which is decidable for p/t nets [12], is undecidable for reset nets. the following proof uses ideas from [12], in which l (f) model checking is reduced to reachability for p/t nets. proposition 3 l (f) model checking of reset nets is undecidable. proof. we reduce reachability, which is undecidable for reset nets [2], to model checking some formula in l (f). let n = (p,t,f,r) be a reset net and m a marking of n. we can compute the set of the least markings greater than m.4 indeed, that set is just {mp | p ∈ p}, where mp is given by mp(q) = m(q) for q 6= p and mp(p) = m(p) + 1. for example, the set of the least markings greater than the marking depicted in the net in the left-hand side of fig. 2 is {mp,mq,mr}, where mp = {p, p,r,r}, mq = {p,q,r,r} and mr = {p,r,r,r}. then, m is reachable in n iff there is a reachable marking m′ that covers m, but does not cover any mp, because this would imply that in each place p, m′ has exactly m(p) tokens (because it does not cover mp). therefore, m is reachable in n iff the formula f(cov(m)∧ ∧ p∈p ¬cov(mp)) is satisfied. the previous proof is based on obtaining a formula which expresses the reachability problem. in order to obtain this formula, there is an important property that reset nets satisfy: given a marking m, we are able to compute a finite set of markings s = {m1,...,mn} such that for each mi ∈ s, mi ⊃ m and if m ′ ⊃ m, then there is mi ∈ s such that m ′ ⊇ mi. intuitively, we can compute the finite set of “the smallest markings greater than m”. as we can build that set, a marking m f coincides with m if and only if m f covers m and m f does not cover any marking of s. 3.2 model checking of ν -pn we first recall from [21] how ν -pn can simulate reset nets (see fig. 5, where the double arrow represents a reset arc). for each place p of a reset net n we consider a copy of it and a new place p′ in the ν -pn n′ we build. the main idea of the construction is to store in place p′ a single token of the colour that we consider valid in the current marking for place p of n′. that is, the tokens in p of the colour of the token in p′ will be considered valid, and the rest of the tokens in p will be considered garbage. for example, in the ν -pn of fig. 5, there are two valid tokens in place r, because the colour of the token in r′ is b. the construction of n′ guarantees that for each place p of n, the place p′ of n′ contains a single token at any time. the firing of any transition ensures that the token being used in the place p of n′ coincides with that in p′ (by labelling both arcs with the same variable xp). every time a transition resets a place p of n, the token in p′ is replaced by a fresh one, so that no token remaining in place p of n′ can be used from then on. for example, suppose we fire transition t in fig. 5. then, a new colour is put in r′, and therefore the tokens of name b in r cannot be used anymore. therefore, this simulation can introduce some garbage tokens (those in p when p is reset). given a marking m we define m′ by arbitrarily choosing a different name ap ∈ id for each p ∈ p, and taking m′(p′) = {ap}, and m ′(p) = {ap, m(p)... ,ap}. then, if m0 is the initial marking of n, n ′ 4 in order theory that set is called the cover of m, though we prefer not to overload that term here. 11 / 18 volume 64 (2013) on the decidability of model checking ltl fragments in monotonic extensions of petri nets • •a ab•• p q r t → a aa a c cbbb a p q r p′ r′ q′ t xp xq xp xq xr ν xr xq xq xr figure 5: a reset net and the corresponding ν -pn. the double arrow represents a reset arc with initial marking m′0 simulates n. the previous simulation preserves all behavioral properties. then, the following is a straightforward consequence of prop. 1. corollary 1 lt l f model checking is undecidable for ν -pn. the previous simulation also preserves coverability. more precisely, if a marking m is coverable in the reset net n, then the marking m′ of n′ defined above is coverable too. the markings in the simulation may contain some garbage, which is created when we simulate the firing of a reset, because instead of removing all tokens of some place p, we change the name of the token in p′, making all tokens in p become garbage. however, the presence of that garbage is irrelevant for coverability. in particular, we have the following. proposition 4 repeated coverability is undecidable for ν -pn. proof. it is enough to consider that repeated coverability is undecidable for reset nets [2], and that the previous simulation preserves repeated coverability. we prove that m can be repeatedly covered from m0 in n iff m ′ can be repeatedly covered from m′0 in n ′. indeed, if m is repeatedly covered there is a run m0 → + m1 → + m2 → + ... of n such that mi ≥ m for all i ≥ 1. by construction of n′, there is a run m′0 → + m1 → + m2 → + ... of n′ such that mi ≥ m ′ i ≥ m ′ for all i ≥ 1, so m′ is repeatedly covered. moreover, mi coincides with m ′ i when considering only the “valid tokens” of mi (and after possibly renaming the names carried by the tokens). the converse is analogous. once we know that repeated coverability is undecidable, undecidability of l (gf) model checking is trivial. corollary 2 l (gf) model checking of ν -pn is undecidable. next, we see the undecidability of l (f) model checking for ν -pn. proposition 5 l (f) model checking of ν -pn is undecidable. proof. the proof is analogous to the one of the same result for reset nets. we reduce reachability in ν -pn, which is undecidable [21], to the model checking problem for some formula in l (f). let n = (p,t,f) be a ν -pn. given a marking m, we can compute the finite set of the least markings greater than m. indeed, given p ∈ p and c ∈ id(m)∪{b}, with b /∈ id(m), we define proc. prole 2013 12 / 18 eceasst mpc given by mpc(q) = m(q) if p 6= q and mpc(p) = m(p)+{c}. then, the set we are looking for is {mpc | p ∈ p,c ∈ id(m)∪{b}}. for example, consider a net with two places p and q, and a marking m with one token a in p and empty in q. the set of the least markings greater than this marking is {mpa,mpb,mqa,mqb}, where mpa(p) = {a,a}, mpa(q) = /0, mpb(p) = {a,b}, mpb(q) = /0, mqa(p) = {a}, mqa(q) = {a}, mqb(p) = {b} and mqb(q) = {a}. therefore, m is reachable in n iff n |= f(cov(m)∧ ∧ p,c ¬cov(mpc)), and we conclude. 4 a decidable fragment in the previous section we have proved the undecidability of model checking of reset nets and ν -pn for some logics, whose model checking problem is known to be decidable for p/t nets. in this section we define a restriction of l (f), thus obtaining a fragment that is less expressive than all the logics considered here. definition 4 fcov is the fragment of l (f) in which negation is not allowed. in this logic we can express bounded repeated coverability. however, fcov cannot express properties like ¬cov(m). in particular, the formula f(cov(m) ∧ ∧ p∈p ¬cov(mp)) which expresses reachability, is not a formula of fcov. as for l (f), we consider existential interpretation, so that a formula is satisfied if some maximal run starting in the initial marking satisfies it. we will see that fcov model checking is decidable both for reset nets and for ν -pn. later, we will consider ∀fcov, the version of fcov with universal interpretation, and we will prove that ∀fcov model checking is undecidable even for p/t nets. proposition 6 fcov model checking of reset nets is decidable. proof. let n = (p,t,f,r) be a reset net and φ a formula in fcov. we proceed by induction on the nesting of operators f in φ . if φ is a boolean combination of formulae of the form cov(m), it is trivial to decide whether φ is satisfied because multiset inclusion is decidable. let us suppose that we can check each formula with at most n > 0 nested f operators. let φ be a boolean combination of formulae of the form cov(m) and fϕ , where ϕ has at most n nested f operators, and let us see that we can decide whether each of those formulae fϕ is satisfied (and hence, whether φ is satisfied). using standard techniques, we can write fϕ as f( ∨ i(( ∧ j cov(mi j)) ∧ ( ∧ k fϕik))), where ϕik are formulae of fcov with at most n − 1 nested operators. that formula is equivalent to the formula ∨ i f(( ∧ j cov(mi j)) ∧ ( ∧ k fϕik)), that is, a disjunction of formulae of the form f(cov(m1)∧ ... ∧ cov(mq)∧ fϕ1 ∧ ... ∧ fϕr), where q and r are not simultaneously zero, and each ϕk has at most n − 1 nested operators. let us distinguish the following two cases: (a) if q = 0 the formula is of the form f(fϕ1 ∧ ...∧ fϕr), which is equivalent to fϕ1 ∧ ...∧ fϕr. hence, we can apply the induction hypothesis to each fϕk and we are done. (b) if q > 0, we modify n, thus obtaining n′, by adding transitions t1,...,tq,tq+1 and places p0, p1,..., pq as follows. we add p0 as precondition/postcondition of every transition in n. moreover, ti moves a token from pi−1 to pi, provided mi is covered. finally, tq+1 can be fired only one time (for which we add a new place with a single token initially, as precondition of tq+1), 13 / 18 volume 64 (2013) on the decidability of model checking ltl fragments in monotonic extensions of petri nets p0 t1 p1 p2 t2 • paux t3 m1 m2n figure 6: construction of n′ in prop. 6 setting again a token in p0, and having pq as precondition and postcondition. this construction is represented in fig. 6, for q = 2. then, n′ behaves as n, but when every mi can be covered, it can sequentially fire t1,...,tq,tq+1. hence, every mi can be simultaneously covered in n iff pq can be covered in n′. we consider the following two sub-cases: (b.1) if r = 0 then the formula is of the form f(cov(m1)∧ ...∧ cov(mq)) and hence equivalent to fcov({pq}), which expresses a coverability problem, so that it can be decided. (b.2) consider now that r > 0. for any formula ϕ , we define ϕ′ as follows: • if ϕ = cov(m) then ϕ′ = cov(m +{pq}). • if ϕ = ϕ1 ∧ ϕ2 then ϕ′ = ϕ′1 ∧ ϕ ′ 2. analogously, if ϕ = ϕ1 ∨ ϕ2 then ϕ ′ = ϕ′1 ∨ ϕ ′ 2. • if ϕ = fϕ1 then ϕ′ = fϕ′1. then, f(cov(m1)∧ ...∧ cov(mq)∧ fϕ1 ∧ ...∧ fϕr) holds in n iff f(fϕ′1 ∧ ...∧ fϕ ′ r) holds in n′. notice that the number of nested f operators is the same for ϕk and ϕ′k. then, by (a) we are done. the proof of the same result for ν -pns is analogous to the previous one.5 proposition 7 fcov model checking is decidable for ν -pn. proof. the construction for ν -pn is the same as the previous one. the only difference is that the names in the markings of the formulae need to be handled correctly in n′, by choosing a different variable for each name in a marking to label the arcs. since in particular fcov allows us to express coverability, which has a non primitive recursive complexity for reset nets [22] and for ν -pn [21], we have the following: proposition 8 the complexity of fcov model checking is non primitive recursive for reset nets and for ν -pn. 5 actually, the same is true for any model that belongs to the class of well structured transitions systems, with fairly minor conditions. proc. prole 2013 14 / 18 eceasst to conclude, let us see that the version of fcov with universal interpretation, that we denote by ∀fcov, is undecidable even for p/t nets. intuitively, formulae in ∀fcov are global properties of some trace, or equivalently, eventuality properties of every trace. for instance, fcov(m) expresses that every run starting from the initial marking eventually covers m. we reduce control-state reachability for two counter machines, which is undecidable [15]. a two counter machine (tcm for short) is a tuple c = (q,{c1,c2},ins,q0), where q is a finite set of control states, c1 and c2 are the two counters, ins is a set of instructions and q0 ∈ q is the initial state. an instruction can be of the following three forms: inc(p,i,q), dec(p,i,q) or zero(p,i,q), where p,q ∈ q and i ∈ {1,2}, for the increasing of the counter ci, the decreasing of ci, or check for zero of ci respectively. a configuration of c is given by a tuple 〈q,c1 = n1,c2 = n2〉, where q ∈ q is the current state, and n1,n2 ∈ n are the current values of the counters. the initial configuration is 〈q0,c1 = 0,c2 = 0〉. in a configuration 〈p,c1 = n1,c2 = n2〉, we may execute inc(p,i,q) ∈ ins, reaching 〈q,c1 = n′1,c2 = n ′ 2〉, where n ′ i = ni + 1 and n ′ 3−i = n3−i. if ni > 0 we may execute dec(p,i,q) ∈ ins, reaching 〈q,c1 = n ′ 1,c2 = n ′ 2〉, where n ′ i = ni − 1 and n ′ 3−i = n3−i. finally, if ni = 0, we can execute zero(p,i,q) ∈ ins, reaching 〈q,c1 = n1,c2 = n2〉. the control-state reachability problem consists in deciding, given q ∈ q, whether a configuration of the form 〈q,c1 = n1,c2 = n2〉 is reachable. it is well-known that this is an undecidable problem [15]. example 7 consider the tcm c = (q,{c1,c2},ins, p), with q = {p,q,r} and ins = {inc(p,c1,q), inc(q,c2, p),zero(p,c2,r)}. in order to reach a configuration with state r, the first instruction to be executed must be zero(p,c2,r). otherwise, the two first executed instructions are inc(p,c1,q) and inc(q,c2, p), so we reach a configuration with c1 = c2 = 1. as there is not a dec instruction in this machine, after executing this instructions we cannot reach a configuration with c2 = 0 anymore, and therefore we cannot reach state r anymore. we consider only deterministic tcm, that is, tcm such that at each reachable configuration there is at most one instruction that can be executed. moreover, without loss of generality we assume that if zero(p,i,q) ∈ ins then there is no other instruction of the form inc(p′, j,q), dec(p′, j,q) or zero(p′, j,q) in ins, that is, q can only be reached by that instruction (defined as requirement †). indeed, for each instruction i = zero(p,i,q) ∈ ins we can add two states q1,q2, and replace i by zero(p,i,q1), inc(q1,i,q2), dec(q2,i,q). 6 the control-state reachability problem for deterministic tcm is still undecidable. proposition 9 ∀fcov model checking of p/t nets is undecidable. proof. we reduce the control-state reachability problem for deterministic tcm to the model checking problem of a formula in ∀fcov. let c = (q,{c1,c2},ins,q0) be a deterministic tcm and pend ∈ q. we use the standard simulation of a tcm by means of a p/t net. we define n = (q ∪{c1,c2},ins,f), where: • f(p,inc(p,i,q)) = 1, f(inc(p,i,q),q) = 1, and f(inc(p,i,q),ci) = 1 (a token is moved from p to q, and a token is added to ci). 6 if we allow instructions that do not modify the counter then it is enough to add a single state q1 and an instruction changing the state from q1 to q. 15 / 18 volume 64 (2013) on the decidability of model checking ltl fragments in monotonic extensions of petri nets p inc(p,c1,q) q inc(q,c2, p) r zero(p,c2,r) c1 c2 figure 7: construction of prop. 9 for the tcm of ex. 7 • f(p,dec(p,i,q)) = 1, f(dec(p,i,q),q) = 1, and f(ci,dec(p,i,q)) = 1 (a token is moved from p to q, and a token is removed from ci). • f(p,zero(p,i,q)) = 1 and f(zero(p,i,q),q) = 1 (a token is moved from p to q). moreover, f(n,m) = 0 elsewhere, and the initial marking of n is {q0}. in n, the number of tokens in ci represent the value of the counter ci in c. increasing and decreasing transitions are simulated faithfully. however, the simulation of a transition zero(p,i,q) can “cheat”, whenever it is fired with tokens in ci. in that case, notice that the marking {ci,q} can be covered. moreover, because q cannot be reached using a different instruction (requirement (†) above), we know that if such marking is covered then the current simulation has cheated. focus on fig. 7, which represents the net built from the tcm of ex. 7. note that transition zero(p,c2,r) can be fired even after firing inc(p,c1,q) and inc(q,c2, p), when c2 is not empty. in this case, this simulation has cheated. we consider ϕ = f(cov(pend)∨ ∨ m∈j cov(m)), where j = {{ci,q} | zero(p,i,q) ∈ ins}. notice that all the cheating runs satisfy ϕ . we prove that pend can be reached in c if and only if n |= ϕ . for the if part, if c reaches pend then the non-cheating run of n eventually covers pend , so that it satisfies ϕ . since cheating runs always satisfy ϕ , every run of n satisfies ϕ . conversely, if c does not reach pend then the non-cheating run of n does not satisfy ϕ . 5 conclusions and future work table 1 summarizes the results on model checking of p/t nets, reset nets and ν -pns. in particular, in this work we have proved the undecidability of the fragments lt l f , l (gf) and l (f) for reset nets and ν -pn. we have defined fcov, a very simple restriction of ltl that does not allow negations, for which model checking of reset nets and ν -pn is decidable. actually, we claim this is the case for any model in the class of well structured transition systems [10] under fairly minor conditions, since the model checking problem can be reduced to a finite number of coverability problems. moreover, we have proved that if we require that every run starting from the initial marking satisfies a formula, then even for the simple case of fcov and p/t nets, the corresponding model checking problem is undecidable. proc. prole 2013 16 / 18 eceasst further study, in order to define more expressive logics for which the model checking problem is decidable, is needed. a possible direction in such study could be the definition of logics with atomic propositions that are more specific of the particular model. such direction links with the so called yen’s logics for p/t nets. in the case of ν -pn, the corresponding logic should be able to express properties about the names in the marking. language theory was used to prove the difference of expressiveness between reset nets and ν -pns in [20]. in this sense, it would certainly be interesting to find a logic which distinguishes between reset nets and ν -pns. finally, we have proved that the complexity of fcov model checking is non primitive recursive for reset nets and for ν -pn. however, it would be interesting to perform a finer complexity analysis. bibliography [1] m. ben-ari, z. manna and a. pnueli. “the temporal logic of branching time”. acta informatica 20, 207-226(1983). [2] r. bonnet. “theory of well-structured transition systems and extended vector-addition systems”. thèse de doctorat, laboratoire spécification et vérification, ens cachan, france (2013). [3] a. bouajjani and r. mayr. “model checking lossy vector addition systems”. international symposium on theoretical aspects of computer science, lncs vol. 1563, 323-333 (1999). [4] e. m. clarke, o. grumberg, and d. a. peled. “model checking”. mit press cambridge(1999). [5] g. decker, m. weske. “instance isolation analysis for service-oriented architectures”. proceedings of the 2008 ieee international conference on services computing, 1, 249256 (2008). [6] j. desel and w. reisig. place/transition petri nets. lectures on petri nets i: basic models, lncs vol. 1491, pp.122–173. springer, 1998. [7] c. dufourd, a. finkel, and ph. schnoebelen. “reset nets between decidability and undecidability”. international colloquium on automata languages and programming, lncs vol. 1443, 103-115 (1998). [8] j. esparza and m. nielsen. “decidability issues for petri nets”. brics report series, rs-94-8 (1994). [9] j. esparza. “on the decidability of model checking for several µ -calculi and petri nets”. colloquium on trees in algebra and programming, lncs vol. 787, 115-129 (1994). [10] a.finkel, and p.schnoebelen. well-structured transition systems everywhere! theoretical computer science 256(1-2):63-92 (2001). 17 / 18 volume 64 (2013) on the decidability of model checking ltl fragments in monotonic extensions of petri nets [11] k. van hee, a. serebrenik, n. sidorova and m. voorhoeve. soundness of resourceconstrained workflow nets. applications and theory of petri nets, lncs vol. 3536, 250267 (2005) [12] r. howell, l. rosier and h. yen. “a taxonomy of fairness and temporal logic problems for petri nets”. theoretical computer science 82, 341-372 (1991). [13] p. jančar. “decidability of a temporal logic problem for petri nets.”. theoretical computer science 74, 71-93 (1990). [14] c. lakos, s. christensen. a general systematic approach to arc extensions for coloured petri nets. applications and theory of petri nets. lncs vol. 815, pp. 338-357 (1994) [15] m. l. minsky. “computation: finite and infinite machines” prentice-hall (1967). [16] oasis web services business process execution language version 2.0. oasis standard (2007). http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.pdf [17] a. pnueli. “the temporal semantics of concurrent programs” theoretical computer science, 13, 1-20(1981). [18] klaus reinhardt. “reachability in petri nets with inhibitor arcs” electr. notes theor. comput. sci. 223: 239-264 (2008). [19] f. rosa-velardo and d. de frutos-escrig. name creation vs. replication in petri net systems. fundamenta informaticae 88(3). ios press (2008) 329-356. [20] f. rosa-velardo and g. delzanno. “language-based comparison of nets with black tokens, pure names and ordered data.”. international conference on language and automata theory and applications, lncs vol. 6031, pp. 524-535. springer (2010) [21] f. rosa-velardo and d. de frutos-escrig. decidability and complexity of petri nets with unordered data. theoretical computer science 412(34): 4439-4451 (2011) [22] ph. schnoebelen. “revisiting ackermann-hardness for lossy counter machines and reset petri nets”. theoretical computer science, lncs vol. 6281, pp. 616,628 (2010). proc. prole 2013 18 / 18 http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.pdf introduction preliminaries model checking of petri net extensions model checking of reset nets model checking of -pn a decidable fragment conclusions and future work on propagation-based concurrent model synchronization electronic communications of the easst volume 57 (2013) proceedings of the second international workshop on bidirectional transformations (bx 2013) on propagation-based concurrent model synchronization fernando orejas artur boronat hartmut ehrig frank hermann hanna schölzel 19 pages guest editors: perdita stevens, james f. terwilliger managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst on propagation-based concurrent model synchronization fernando orejas1 ∗ artur boronat1 2 † hartmut ehrig3 frank hermann4 hanna schölzel3 1 universitat politècnica de catalunya, barcelona, spain. 2 the university of leicester, uk 3 tu berlin, germany 4 interdisciplinary center for security, reliability and trust, université du luxembourg, luxembourg abstract: the aim of concurrent model synchronization is to merge pairs of updates on interrelated models. for instance, this situation may occur in the context of model driven software development when the work is distributed between different teams. a first problem is that, if the updates are in conflict, this conflict is never explicit. the reason is that the updates do not interfere directly since they are assumed to modify different models. for this reason, detecting and solving conflicts becomes already more difficult than in the more standard case of synchronizing concurrent updates over a given model. existing general approaches define the solution to this problem in terms of the solution to the simpler problem of update propagation in bidirectional model transformation. we call these approaches propagation based. in this paper, we first state some properties that, in our opinion, must be satisfied by a concurrent synchronization procedure to be considered correct. then, we show how to check whether the given updates are conflict-free and, in this case, we present a correct synchronization procedure based on this check. finally, we consider the case where the given updates are in conflict and we show how we can build solutions that satisfy some of the correctness properties but, in general, not all of them. specifically, we present counter-examples that show how some of these properties may fail. keywords: model synchronization, bidirectional model transformation, modeldriven development 1 introduction the aim of concurrent model synchronization is to merge pairs of updates on interrelated models. for instance, this situation may occur in the context of model-driven software development when different teams are working on different (related) models of the same software artifact. this ∗ this work has been partially supported by the cicyt project (ref. tin2007-66523) and by the agaur grant to the research group albcom (ref. 00516). † supported by a study leave from university of leicester. 1 / 19 volume 57 (2013) on propagation-based concurrent model synchronization problem is a generalization of (standard) model synchronization, where updates on one model must be propagated to its related model. in particular, in standard model synchronization we look for operations that implement this propagation. however, concurrent model synchronization is more difficult due to the possible existence of conflicts between the given pair of updates. an additional complication comes from the fact that these conflicts are not explicit, since the updates are applied to different models, but they are only apparent when trying to propagate the effects of the given updates. the only approaches [xsht09, xsht13, heeo12] that we know that provide a general solution to this problem define concurrent synchronization procedures in terms of the propagation operations defined for solving the standard synchronization problem. in [xsht13], the authors present a procedure for synchronizing conflict-free concurrent updates that roughly works as follows. given two interrelated models m and n and two updates u and v on m and n, respectively, in the first step the procedure propagates u to n in order to check if there are conflicts with v. this is easy to see, since both v and the propagation of u, prop(u), are updates on the same model. then, if there are no conflicts the procedure merges v and prop(u) and propagates back the result to m. if the procedure finds a conflict, or some other problem, then the procedure reports an error. the approach presented in [heeo12] is similar, but allowing for the possibility of handling conflicts using results from [eet11]. in this paper, we say that this kind of approaches are propagation-based, because their solution is defined in terms of the propagation operations defined for standard synchronization. as we have seen, their main advantage is that, since we can put together the given updates and their propagation, we can easily detect conflicts by making them explicit and, so, we can decide how to handle them. another advantage is that these procedures are quite generic: we define them independently of how standard synchronization procedures are defined. however, as we will see in this paper, this approach has also some limitations. for instance, propagation-based procedures are not hippocratic in general. in this paper, we study at a general level the correctness and the limitations of propagationbased concurrent synchronization. for this purpose, we provide an abstract and formal view for propagation based synchronization that covers different existing approaches. since some of the well established properties are too restrictive for several applied cases, we present new properties that overcome these restrictions in an elegant way. moreover, we present formal properties concerning additional relevant aspects such as maximal preservation of given updates and soundness (avoidance of side effects). then, we show how we can check whether the given updates are conflict-free and, in this case, we also show how we can construct a correct synchronization (theorem 1). moreover, when the given updates are in conflict, we present a propagation-based procedure for concurrent synchronization and show its correctness concerning most of the properties (theorem 3). finally, we show that existing solutions satisfy some of the correctness properties but, in general, not all of them. specifically, we present counter-examples that show how some of these properties may fail. the paper is organized as follows. in section 2, we present an example of model transformation that will be used to show specific counter-examples in the rest of the paper. in section 3, we introduce the basic theoretical framework used in the paper, first our notion of model update and, then, our assumptions about update propagation operations. in section 4, we introduce the problem of concurrent synchronization and the properties that we claim that propagation-based procedures should satisfy. in section 5, we present different propagation-based solutions to the proc. bx 2013 2 / 19 eceasst concurrent synchronization problem, first for the conflict-free case and, then, for the general case. finally, in section 6, we present some related work and present some conclusions. 2 running example to help in providing some explanations and counter-examples we use a very simple example. source and target models describe different views of (part of) the information system of a company. they both describe information about their employees. following the metamodels, depicted in fig. 1, the source metamodel, on the left, describes the employees of a certain branch of the given company, for instance the employees of the barcelona branch. it consists just of a single class, employee, with attributes name (the name of the employee), dept (the name of the department where the employee works), base (the base salary of the employee), and bonus. the target metamodel, depicted on the right, describes the employees of the whole company. in particular, the metamodel includes three classes: employee, dept and branch. branch and dept include just a name attribute, but employee includes three attributes: name, salary (the total salary received by the employee) and address (the address of the employee). in addition, each employee must be associated to the branch and to the department where he currently works. a source and a target model are consistent if the following conditions hold: • every employee in the source model is also present in the target model and is associated to the barcelona branch. conversely, every employee associated to the barcelona branch in the target model must also be present in the source model. • the salary of each employee associated to the barcelona branch in the target model is the addition of the base and bonus of that employee in the source model. • the department of an employee in the source model is a string d if and only if that employee is associated to the department of name d in the target model. we may notice that source and target models share some information, but also include some information of their own. for instance, source models include more information about the salaries of the employees. conversely, target models include the address of employees, and they also include information about the employees of other branches different than barcelona. figure 1: source and target metamodels moreover, we assume that updates on the source or target models are propagated as follows: • if we add an employee to the source model, this modification is propagated to the target model by including that employee with the address ”xxx” and with a salary that is 3 / 19 volume 57 (2013) on propagation-based concurrent model synchronization the sum of its base and bonus. moreover, if the department of the new employee is not present in the target model, then the new department is also added. finally, the employee is associated with its department and the barcelona branch. • conversely, if an employee is added to the target model and it is associated to the barcelona branch, the modification is propagated to the source model by adding that employee together with the corresponding department. moreover, we set the base and bonus attributes to 3/4 and 1/4 of the salary, respectively. • finally, if an employee is deleted from either the source or the target model, its propagation consists of the deletion of that employee from the other model (if present), without any additional side-effects, like the deletion of its associated branch or department. how that employee is identified depends on specific details of the given models. for instance, if the models would be represented by a triple graph [sk08] then there would be a correspondence element relating each employee in the source model to the same employee in the target model. otherwise, probably a key would identify each employee on the two models. in this scenario, source and target updates occurring in parallel can cause several types of conflicts, which have to be resolved by a concurrent synchronization operation. consider, e.g., the situation depicted in fig. 2. the source update us deletes employee e1 and the target update ut modifies the address of this person. propagating us to the current state of the target domain would remove that person. on the other hand, propagating ut to the source domain would undo the deletion and create a new person with a base salary of 6000 and a bonus salary of 2000. there are several possibilities on how the synchronization works in the concurrent case to handle such conflicts and we will study different properties of concurrent synchronization in this paper. figure 2: a parallel update 3 the basic framework this paper is not about some specific kind of models. instead, we aim to study some properties and constructions about a wide class of models and model transformations. obviously, there proc. bx 2013 4 / 19 eceasst could be some frameworks where our results do not completely apply. in this sense, first, we present our assumptions about the given model framework and, then, we present a generic notion of model update or modification, and study some properties of this notion. thereafter, in the second subsection, we present our framework of integrated models and the description of the operations of update propagation, together with the properties that we may expect that they satisfy. 3.1 models and updates we assume that, technically, our model classes form m-adhesive categories [ls05, eept06, egh10], which roughly means that our models are some kind of structured sets where union, intersection and set difference can be defined in terms of pushouts, pullbacks and pushout complements. for example, not only sets, but most classes of graphical structures form m-adhesive categories, e.g., plain graphs, typed attributed graphs, hyper graphs, petri nets, and high-level petri nets. our approach is δ-based [dxc10], which means that, when considering the update of a model, we do not take into account only the models before and after the update. instead, we deal with updates representing explicitly which elements have been added to or deleted from the given model (for a discussion on the advantages of δ-based approaches in comparison to state based approaches, see [dxc10]). more precisely, an update or modification [eet11] of a model m, denoted m ⇒ m′ is a span of inclusions (or, in general, injective morphisms) m ← m0 → m′. intuitively, the elements in m that are not in m0 are the elements deleted by the modification, and the elements in m′ that are not in m0 are the elements added by the modification. so, m0 consists of all the elements of m that remain invariant after the modification. updates u1 : m1 ⇒ m2 and u2 : m1 ⇒ m2 may be equivalent, denoted u1 ∼ u2, in the sense that they yield the same result, but that they are technically different, because they are defined as different spans. for instance, the identity update id : m ← m → m is equivalent to any update u : m ← m0 → m, but id , u if m , m0. intuitively, id neither deletes nor adds any element to m, while u would delete all the elements in m which are not in m0 and, then, it would add them again. updates are closed under composition, i.e., given updates u1 : m1 ← m0 → m2 and u2 : m2 ← m′0 → m3 there exists the composition u2 ◦u1 : m1 ← m → m3 defined by the diagram below: m1 m0oo // m2 m′0oo // m3 m aa == (1) where (1) is a pullback (intuitively, the intersection of m0 and m′0), i.e. m includes all the elements of m1 that are neither deleted by u1 nor by u2. sometimes, as we will see in the sections below, we are interested, not in the composition of updates, but in their decomposition. intuitively, an update u3 : m1 ⇒ m3 can be decomposed as u2 ◦u1, denoted u3 d = u2 ◦u1, with u1 : m1 ⇒ m2 and u2 : m2 ⇒ m3 if, on the one hand, the composition u2 ◦u1 coincides with u3 and, on the other hand, the changes included in u1 are not undone by u2. in particular, this requires that u2 neither deletes any element that is created by u1 nor it adds back any element deleted by u1. in other words, once an element is created, it 5 / 19 volume 57 (2013) on propagation-based concurrent model synchronization will survive the full update, and if an element is deleted it will remain deleted for the full update. formally, u3 d = u2 ◦u1 if, in the above diagram, (1) is a pullback and a pushout. obviously, if u3 d = u2 ◦u1 then u3 = u2 ◦u1, but the converse is not necessarily true. for instance, u1 may be like u3 but adding some extra elements and u2 may just delete these additional elements. in that case, we would have that u3 = u2◦u1 but not u3 d = u2◦u1. moreover, we say that u1 decomposes u3 or that u1 is a submodification of u3, denoted u1 e u3, if there exists u2 such that u3 d = u2 ◦u1. we may notice that, according to the previous definitions, the only submodification of the identity update id : m ← m → m is the identity update itself. the reason is that, if there would be another submodification u1 of id, then either u1 would delete some element from m or it would add some new element to m. but, then, any u2 such that u2 ◦u1 = id would need to add or delete the corresponding elements. formally, if in the diagram above, m1 = m3 = m, the only way that (1) is a pushout and a pullback is that m0 = m2 = m′0 = m. it is easy to define the inverse of an update u : m ← m0 → m′. it is enough to reverse the span, i.e. u−1 = m′← m0 → m. however, we may notice that u−1◦u ∼ id but, in general, u−1◦u , id. when several users want to apply different updates on the same model we need to have a merge operation that combines these modifications into a single one. this problem has been studied by several authors, but here we essentially follow the work in [eet11]. a main problem is that there may be conflicts between the given modifications. for instance, an update u1 may specify the deletion of a certain element e1 and u2 may specify the addition of an element e2 that needs the existence of e1. this is called a delete/insert conflict in [eet11]. for example, u1 may specify the deletion of a node in a graph model and u2 may specify the addition of an edge e2 that is connected to e1. hence, a first problem is how to detect if there are conflicts between the given modifications. two modifications are conflict-free, if none of them deletes an element that is needed by the other one. this condition is formalised in definition 1. intuitively, by defining m as the pullback of (1), we are defining m as the intersection of m′0 and m ′′ 0 , i.e. u3 deletes from m0 all the elements that are deleted either by u1 or u2. then, the existence of m′1 and m ′ 2 1 means that no element added by u1 or by u2 needs the existence of an element deleted by u2 or by u1, respectively. finally, if (4) is a pushout, the elements added to m by u1 ⊗u2 are the union of the elements added by u1 and by u2. in the case of conflict-free modifications, we can define the result of this merging as the modification u3 = u1 ⊗u2 : m0 ← m → m3, where diagram (4) is a pushout. notice that, by construction, u1 and u2 are submodifications of u1 ⊗u2, as we would expect. definition 1 (conflict-free updates) let u1 : m0 ← m′0 → m1 and u2 : m0 ← m ′′ 0 → m2 be two modifications. let m be constructed via the pullback (1) in figure 3. then, u1 and u2 are conflict-free, if there are objects m′1 and m ′ 2 yielding pushouts (2), (3) and (4). in case that u1 and u2 are in conflict, solving the conflicts would typically mean finding conflict-free maximal submodifications u′1 e u1 and u ′ 2 e u2 and merging them, as described above, where maximality means that if u′1 e u ′′ 1 e u1 and u ′ 2 e u ′′ 2 e u2 and u ′′ 1 and u ′′ 2 are conflict1 in adhesive categories, pushout complements along monomorphisms as they appear in graph modifications are unique. this means that, if they exist, m′1 and m ′ 2 are unique. proc. bx 2013 6 / 19 eceasst m0 (1) u1 '' u2 �� m′0 (2) oo // m1 m′′0 (3) oo �� m (4) oo oo // �� m′1 oo �� m2 m′2oo // m3 m0 u1 // u2 �� u3 m1 u′2 �� m2 u′1 // m3 figure 3: condition for conflict-free modifications u1 and u2 free, then u′1 = u ′′ 1 and u ′ 2 = u ′′ 2 . in this paper, we are not concerned with specific procedures or strategies for solving conflicts. for example, in [eet11] a procedure is described to find solutions where delete/insert conflicts are solved giving priority to insertions. 3.2 integrated models and update propagation we assume that two classes (categories) of models are given, ms and mt , called the classes of source and target models, respectively, even if in a bidirectional framework there may be no specific notion of source or target. and we consider that an integrated model m is just a pair m = 〈ms,mt〉 consisting of a source and a target model. in previous work (e.g. [heo+11, heeo12]) we considered that an integrated model is a correspondence, r : ms ↔mt , that relates the elements of both models. for many purposes, we think that working in terms of correspondences is more adequate. however, in this paper, we do not make any use of knowing the relation between the elements of both models. therefore, for the sake of simplicity we will assume that the class of integrated models im is the cartesian product ms ×mt . we also assume that a subclass of consistent integrated models, c ⊆im is also given. the notion of consistently integrated models induces a notion of consistence of models. in particular, a source model ms (resp. a target model mt ) is consistent if there is a consistent integrated model 〈ms,mt〉 that includes that model for some target model mt (resp. for some source model ms). in addition, we assume that our framework is equipped with propagation operations that solve the basic synchronization problem. this means that, given an integrated model m and an update on one domain, either ms or mt , these operations propagate the given changes to the other domain. more precisely, we assume that our framework includes suitable total forward and backward functions fppg and bppg. in the case of fppg, the input is an integrated model m ∈ im together with a source model update us : ms ⇒ m′s, and the output is a target update ut : mt ⇒ m′t . the operation bppg behaves symmetrically to fppg. it takes as input m and a target modification ut : mt ⇒ m′t and it returns a source update us : ms ⇒ m′s. in principle, we do not require that the given integrated model, nor the result of the propagation have to be consistent, i.e. we assume that our propagation operations will provide an output for any possible update. for instance, the deletion of a given element on the source model may be propagated to the deletion of some elements of the target model, independently of the consistency of the 7 / 19 volume 57 (2013) on propagation-based concurrent model synchronization original and the resulting integrated models. there are several properties that have been proposed by different authors (e.g. [ste10, dxc+11b] to consider that propagation operations are correct. below we can find the main ones. however, due to lack of space, we just state these properties for forward propagation, since the corresponding properties for backward propagation are similar. the most basic ones are the ones that we call consistency, identity and hippocraticness. consistency states that if the given update yields a consistent model then the resulting integrated model should be consistent. 1. consistency: if fppg(m1,us : ms1 ⇒ m s 2) = (u t : mt1 ⇒ m t 2 ) and m s 2 is consistent, then 〈ms2,m t 2 〉 is also consistent. identity states that if the given update is the identity and the given correspondence is consistent, then the propagation operations change nothing. 2. identity: if 〈ms,mt〉 is consistent then fppg(m,ids) = idt finally, hippocraticness states that if after the given update the resulting models are already consistent then propagation should also do nothing. notice that identity is a special case of hippocraticness. 3. hippocraticness: given m1 = 〈ms1,m t 1 〉 and u s : ms1 ⇒ m s 2 , if 〈m s 2,m t 1 〉 is consistent then fppg(m1,us) = idt another property that has been proposed by several authors is the so called put-put law, stating the compatibility of propagation with respect to update composition: 4. compatibility of propagation and update composition: if fppg(m1,us1 : m s 1 ⇒ m s 2) = (ut1 : m t 1 ⇒ m t 2 ) and fppg(m2,u s 2) = u t 2 then fppg(m1,u s 2 ◦u s 1) = u t 2 ◦u t 1 however, the put-put law is too strong in general. for instance, in the example described in section 2, if we delete an employee from the source model and, then, we add it again, after propagating both updates, the employee in the target model would have the address ”xxx”. however, the composition of the two updates is, obviously, equivalent to the identity, whose propagation is also equivalent to the identity. hence if the address of that employee in the target model before the update was not ”xxx”, the put-put law would not be satisfied. instead of the put-put law, we propose the following alternative law that states the compatibility of propagation with respect to update decomposition: 5. compatibility of propagation with update decomposition: if fppg(m1,us1 : m s 1 ⇒ ms2) = (u t 1 : m t 1 ⇒ m t 2 ) and fppg(m2,u s 2) = u t 2 and u s 3 d = us2 ◦u s 1 then fppg(m,u s 3) = u t 3 , with ut3 d = ut2 ◦u t 1 strong invertibility is a law that is also too strong in many contexts (see, e.g. [fkpt08, ste10, dxc+11b, ste12]. instead, we may ask for its weaker version of invertibility. strong invertibility states that if u′ is the update propagation of u then u must be the update propagation (in the reverse direction) of u′: proc. bx 2013 8 / 19 eceasst 6. strong invertibility: if fppg(m,us) = ut then bppg(m,ut ) = us a weaker version is invertibility that roughly says that if u2 is the update propagation of u1 and u3 is the update propagation (in the reverse direction) of u2 then u2 must be the update propagation of u3: 7. invertibility: if fppg(m,us1) = u t 1 and bppg(m,u t 1 ) = u s 2 then fppg(m,u s 2) = u t 1 in [ste12] the relations between some of these and other properties are studied in detail. 4 propagation-based concurrent synchronization the aim of concurrent synchronization is to merge pairs of updates (in what follows, parallel updates) on interrelated models. a first problem is that, if the updates are in conflict, this conflict is not explicit. the reason is that, here, on the contrary to what we have seen in sect. 3.1, the updates do not interfere directly since they are assumed to modify different models. the conflicts may arise when we try to build a consistent integrated model out of the two updated models. as we show in section 5, a simple way of approaching the problem is to use the forward and backward propagation operations, described in section 3.2 both to detect conflicts and to implement the synchronization procedure. we say that this kind of approaches are propagationbased. in general, the result of concurrent synchronization is not unique: each possible way of solving the existing conflicts may be considered a possible solution, where the users may decide whether each result corresponds to their needs. in particular, given a parallel update u = 〈us,ut〉, if there are conflicts between us and ut , we may consider that each possible result corresponds to the merging of two conflict-free submodifications, us0 e u s and ut0 e u t , obtained after backtracking some of the conflicting operations involved in us and ut . this condition is addressed in this section by the formal properties soundness and maximal preservation. for instance, in the example described in section 2, if we have a source update that includes the deletion of an employee and a target update that includes a change on the salary of that employee, the two updates would be in conflict. to solve the conflict, we would need to either backtrack the deletion of the employee from the source model or to backtrack the change of salary of that employee in the target model. before studying the problem in more detail, we should note that if ms and mt are madhesive categories then the category of integrated models, im = ms ×mt , is also madhesive, and its updates are parallel updates u = 〈us,ut〉. therefore we can apply the concepts and techniques presented in section 3 to work with these updates. more formally, we consider that a concurrent synchronization procedure csync is a nondeterministic function whose input is a pair consisting of an integrated model m and a parallel update u1 : m ⇒ m1 and the output are parallel updates u2 : m ⇒ m2, where us2 and u t 2 could be seen as the result of merging us1 and u t 1 or some of its submodifications. moreover, when we write csync(m,u1) = u2 we mean that u2 is a possible result of this synchronization. our notion of concurrent synchronization fits the procedure described in [xsht13]. however, in [heeo12], the result of concurrent synchronization is defined in a slightly different way. in that paper, a result of synchronizing u1 : m ⇒ m1 is a parallel update u2 : m1 ⇒ m2, such that m2 ∈c. from 9 / 19 volume 57 (2013) on propagation-based concurrent model synchronization a practical point of view, the latter notion suggests that, when we start the synchronization operation, the given updates us1 and u t 1 have already been performed, i.e. the given state consists of the models ms1 and m t 1 , so the resulting updates u s 2 and u t 2 are applied to that state yielding the final state 〈ms2,m t 2 〉. this means that, if conflicts are found in the synchronization process, then us2 and u t 2 would have to undo some of the modifications included in u s 1 and u t 1 . on the contrary, the current notion suggests that, when the synchronization operation starts, the given updates us1 and ut1 would have not been executed so the current state is still 〈m s,mt〉. instead, these updates would have been kept or stored in some way, and the synchronization process would, first, find the possible conflicts between us1 and u t 1 , then, it would compute the resulting updates u s 2 and ut2 and, finally, it would execute these updates over the initial state, leading to the final state 〈ms2,m t 2 〉. however, from a theoretical point of view, both notions can be considered equivalent, in the sense that, in general, from one kind of solution we can construct the other one. let us now see what properties should be satisfied by a propagation-based concurrent synchronization procedure csync when applied to an integrated model m and a parallel update u1. the first three properties are just the concurrent version of the corresponding properties defined for propagation operations presented in section 3.2. the first property states that any result must be consistent; the second one says that if the given modifications are the identity then the resulting updates should also be the identity (when the given interrelated model is consistent: otherwise the former properties would be contradictory); finally the third property is the concurrent version of hippocraticness. it just says that if the interrelated model after applying two updates is already consistent, then we may consider that the updates are already synchronized. 1. consistency: given the integrated model m and a parallel update u1 : m ⇒ m1, if csync(m,u1) = (u2 : m ⇒ m2), then m2 ∈c. 2. identity: if m is consistent and csync(m,〈ids,idt〉) = u2 then u2 = 〈ids,idt〉. 3. hippocraticness: given u : m ⇒ m1, if m1 ∈c then csync(m,u) = u. the above properties say very little about the relation between the resulting modifications and the given updates. in particular, a concurrent synchronization procedure that returns some updates that have nothing in common with the original modifications may satisfy these properties. hence, we have to relate the output modifications with the input updates. in the context of propagation-based concurrent synchronization, we may consider that each update us on the source model not only specifies some given modifications on ms, but it also specifies the modifications included in its propagation f ppg(m,us) on the target model, and similarly for target updates. therefore, in this framework, we may consider that a concurrent synchronization csync is sound if whenever u2 = csync(m,u1), then all the modifications included in u2 are part of us1 and ut1 or their propagation. this is stated by saying that the resulting updates can be obtained by merging some submodifications of the input updates and their propagation. 4. soundness: if csync(m,u1) = u2 then there are submodifications v1 and v2, such that v1 e u1, vs2 e bppg(m,u t 1 ), v t 2 e f ppg(m,u s 1), and v1 ⊗v2 = u2. however, this is not enough. a concurrent synchronization procedure that always returns the identity updates would be considered sound. obviously, this is not what we want. what we proc. bx 2013 10 / 19 eceasst may expect is that any resulting update u2 should include as much as possible the modifications specified by the input update u1. in particular, when there are no conflicts between us1 and u t 1 , u2 should include all the modifications specified by us1 and u t 1 . 5. maximal preservation: if csync(m,u1) = u2, then for all parallel updates v1 : m ⇒ m′1 and v2 : m ⇒ m ′ 2, such that v1 is conflict-free, v1 e u1, v2 = v1 ⊗ 〈bppg(m,vt1 ), f ppg(m,v s 1)〉 and m ′ 2 ∈c, then if u2 e v2, we have v2 = u2. finally, we may consider that, after conflict resolution, we have backtracked certain modifications included in the given input update u1, so that what we really want is to synchronize some conflict-free submodification u0 e u1. then, we may also consider that the resulting update u2 should only include modifications from us0 and u t 0 and their propagation. 6. strong soundness: if csync(m,u1) = u2 then there is a parallel update u0 e u1, such that us0 ⊗bppg(m,u t 0 ) = u s 2, and f ppg(m,u s 0)⊗u t 0 = u t 2 . it is not difficult to see that strong soundness implies the properties of soundness and identity: proposition 1 if csync(m,u1) = u2 is a strongly sound solution then it also satisfies the properties of identity and soundness. proof sketch. • identity. if u1 is the identity parallel update then, the only update u0 satisfying u0 e u1 is also the identity update. but, if u0 is the identity, according to the identity property of basic synchronization, we have that bppg(m,ut0 ) = id, and f ppg(m,u s 0) = id. but this means that us0 ⊗bppg(m,u t 0 ), and f ppg(m,u s 0)⊗u t 0 are also the identity. • soundness. let us suppose that csync(m,u1) = u2 and there is an update u0, such that u0 e u1, us0 ⊗ bppg(m,u t 0 ) = u s 2, and f ppg(m,u s 0)⊗ u t 0 = u t 2 . then, by the property of preservation of decomposition of basic synchronization, we have that bppg(m,ut0 ) e bppg(m,ut2 ), and f ppg(m,u s 0)e f ppg(m,u s 2). therefore, if we take as submodifications v1 = u0, vs2 = bppg(m,u t 0 ), and v t 2 = f ppg(m,u s 0), then we have that v1 and v2 satisfy the conditions stated in the soundness property. 5 strategies for propagation-based concurrent synchronization in section 4, we have seen some conditions that we may consider when reasoning about the adequacy of a given concurrent synchronization procedure. in this section we study different approaches to define propagation-based procedures for concurrent synchronization and we analyze up to which point they satisfy our correctness properties. in particular, in the first subsection we will study the conflict-free case: we will show how we can check the existence of conflicts between two updates us and ut , and we will see that this check immediately tells us how to define the synchronization of these updates. moreover, we will see that this procedure satisfies 11 / 19 volume 57 (2013) on propagation-based concurrent model synchronization all the properties defined in section 4, except hippocraticness. then, in the second subsection we consider the case where us and ut are in conflict and we show that using propagation and conflict resolution, as presented in section 3, we can build solutions that satisfy some of the above properties, but not all of them. 5.1 conflict-free concurrent synchronization the simplest approach to make conflicts explicit in a parallel update u1 is to consider simultaneously the given updates, us1 and u t 1 , and their propagation over the given integrated model. in particular, if we define u2 = 〈bppg(m,ut1 ), f ppg(m,u s 1)〉, we can first check if u1 and u2 are in conflict, according to the notion of conflict studied in section 3. however, this check only tells us if all modifications defined by u1 are compatible with the modifications defined by u2, but it does not tell us if the result of merging u1 and u2, u1 ⊗u2, is consistent. in particular, if it is inconsistent, we should consider that there is also some kind of conflict between u1 and u2. hence, a simple procedure to check conflict-freeness of u1 would be: 1. let u2 = 〈bppg(m,ut1 ), f ppg(m,u s 1)〉. 2. if u1 and u2 are conflict-free and u1⊗u2 : m →m2 with m2 ∈c then return true; otherwise return false. now, if u1 satisfies the above check, then we can define csync0(m,u1) = (u1 ⊗u2) as the concurrent synchronization of u1. theorem 1 (properties of conflict-free concurrent synchronization) if u1 = 〈us1,u t 1 〉 is a conflict-free parallel update over m, then csync0(m,u1) = (u1 ⊗ u2), where u2 = 〈bppg(m,ut1 ), f ppg(m,u s 1)〉, satisfies the properties of 1) consistency, 2) identity, 4) soundness, 5) maximal preservation and 6) strong soundness. proof sketch. according to prop 1, strong soundness implies identity and soundness. hence, it is enough to prove the properties of consistency, maximal preservation and strong soundness. • consistency. by construction, the result of u1 ⊗u2 is consistent. • maximal preservation. if we have that v1 : m ⇒ m′1 and v1 e u1 this means that 〈bppg(m,vt1 ), f ppg(m,v s 1)〉 e 〈bppg(m,u t 1 ), f ppg(m,u s 1)〉, as a consequence of the compatibility of propagation and update decomposition. but this means that v2 = v1 ⊗ 〈bppg(m,vt1 ), f ppg(m,v s 1)〉e u2. therefore, if u2 e v2, we have v2 = u2. • strong soundness. it is enough to take as submodification u0 = u1. unfortunately, in general, csync0 does not satisfy hippocraticness. the reason is that, given u1 : m ⇒ m1, if m1 ∈c, in general, we cannot expect that u1 = (u1 ⊗u2), where u2 is defined as above. obviously, we can avoid this problem by checking if m1 is consistent before starting the whole procedure. however, the rationale of hippocraticness is that synchronization or propagation procedures should perform the least amount of modifications to produce a consistent proc. bx 2013 12 / 19 eceasst integrated model. then, by including this additional check, we avoid the extreme case, where no additional modifications are needed. however, from an informal viewpoint, we may conclude that propagation-based synchronization approaches are not hippocratic since, when propagating the given updates, we may be performing more modifications than needed. in [xsht13] a conflict-free concurrent synchronization procedure, called sy nc, is defined in a slightly different way. however, this difference causes that sy nc may fail to deliver a result in cases when there are no conflicts. roughly2, given a model m and a parallel update u1, sy nc builds the resulting update u2 in four steps: • first, it does a backward propagation of ut1 . • then, if there are no conflicts between us1 and bppg(m,u t 1 ), it merges the two updates obtaining the source update us2 = u s 1 ⊗bppg(m,u t 1 ). • in the third step, it forward-propagates us2, obtaining the target update u t 2 = f ppg(m,u s 2). • finally, it checks if the solution found, u2 preserves the given update u1, which essentially means that u2 includes all the modifications specified by u1. if u2 preserves u1, the procedure returns u2, otherwise it reports an error. the problem can be seen in the following example. let us suppose, following section 2, that the source update us1 consists of the addition of some employee e1 and the target update u t 1 consists of the addition of a different employee e2 that works in the berlin branch. obviously, there is no conflict between the two updates. now, according to [xsht13], sy nc would behave as follows: • the backward propagation of ut1 would be the trivial identity update, since e2 is not working in the barcelona branch. as a consequence, us2 = u s 1. • ut2 = f ppg(m,u s 2), i.e. u t 2 consists just of the addition of e1 to the target model. • unfortunately, u2 does not preserve u1, since employee e2 is not added now to the target model. thus the procedure would deliver an error. the problem is related with the properties of invertibility and strong invertibility of (backward) propagation. in particular, if bppg is strongly invertible then, if there are no conflicts, sy nc is always preserving, but if it is not strongly invertible then sy nc may be not preserving and, as a consequence, it may report an error, when the updates are conflict-free, as shown with the previous example. proposition 2 if us1 and u t 1 are conflict-free updates of an integrated model m, bppg is strongly invertible, and sy nc(m,u1) = u2 then u1 e u2. proof sketch. we know that us2 = u s 1⊗bppg(m,u t 1 ), so by construction (cf. section 3.1) u s 1 e u s 2. let us now show that ut1 e u t 2 . by construction, we know that there is some target update v t 1 such 2 the approach in [xsht13] is not δ-based, but state-based. as a consequence, their formulation is slightly different. 13 / 19 volume 57 (2013) on propagation-based concurrent model synchronization that vt1 ◦bppg(m,u t 1 ) d = us2. by the property of compatibility of propagation with update decomposition, we have that f ppg(m′,vt1 )◦ f ppg(m,bppg(m,u t 1 )) d = f ppg(us2), where m ′ is the integrated model obtained after applying the parallel update 〈bppg(m,ut1 ), f ppg(m,bppg(m,u t 1 ))〉 on m. but, if bppg is strongly invertible, f ppg(m,bppg(m,ut1 )) = u t 2 implying u t 1 e u t 2 . 5.2 conflicts and concurrent synchronization given an integrated model m, if the given parallel update u1 includes some conflicts, to ensure the properties of consistency, identity, maximal preservation and strong soundness, we would need to find (maximal) conflict-free subupdates v e u1. then, for each such v, we could find a solution just computing csync(m,v) as described in the previous section. a simple solution could consist: a) in computing all subupdates v e u1; b) for each v, checking if it is conflictfree; and, finally, c) returning the maximal subupdates found. obviously, the problem of this kind of approach is that it may be computationally very costly. in what follows we study two approaches that are more efficient in general, although we may be unable to ensure some of the above properties. the first approach was proposed in [heeo12] and can be seen as a variation (including conflict resolution) of the procedure sync defined in [xsht13] and analyzed above. the proposed procedure, which we will call csync1 can be described in four steps. we assume to have an integrated model m and a parallel update u : m ⇒ m1: • in the first step, we compute the forward propagation of us. now, we have two updates over mt , ut : mt → mt1 and f ppg(m,u s) : mt → mt0 . • if there are no conflicts between ut : mt → mt1 and f ppg(m,u s) : mt → mt0 we just merge these updates, otherwise we find a solution to them. hence, after this step we have computed a target update vt : mt → mt3 that is equal to the merging of conflict-free subupdates vt0 e u t and vt1 e f ppg(m,u s). now, we may notice that there must exist an update wt such that wt ◦ut is equivalent to vt . the reason is that if wt0 is the update such that ut d = wt0 ◦v t 0 and w t 1 is the update such that v t d= wt1 ◦v t 0 , it is enough to define wt = wt1 ◦(w t 0 ) −1. intuitively, wt first undoes the modifications which are part of ut but that are not part of vt , and then it applies the additional modifications wt1 . • next, we find a maximal consistent submodel mt2 of the target model m t 3 . obviously, if mt3 is already consistent then m t 2 = m t 3 . let now w t 1 : m t 3 → m t 2 be the update that deletes all the elements in mt3 which are not in m t 2 . • finally, we apply backward propagation of the update wt1 ◦ w t to m1, leading to a source model ms2 . in this context the resulting integrated model after the concurrent synchronization would be 〈ms2,m t 2 〉, which means that, in our terms 3, csync1(m,u) = 〈bppg(wt1 ◦w t )◦us,wt1 ◦v t〉. 3 as mentioned in sect. 4, given m and a parallel update u : m ⇒ m1, in [heeo12], it is assumed that the result of the operation of concurrent synchronization is a parallel update over m1 proc. bx 2013 14 / 19 eceasst it is not difficult to prove that csync1 satisfies the properties of consistency and identity. in particular, we know that the resulting model m2 = 〈ms2,m t 2 〉 is consistent because of the consistency of backward propagation, since, by construction, mt2 is consistent and m2 is obtained applying backward propagation to the update that lead to mt2 . the case of the identity property is simpler. it is enough to notice that if the given parallel update u : m ⇒ m1 is the identity, then all the updates defined in the above procedure, by construction, are also the identity. as a consequence, we have: theorem 2 (properties of csync1) csync1 satisfies the properties of consistency and identity. however, csync1 is not sound. let us consider the example presented in section 2 that is depicted in fig. 2. in that example, the source update us includes the deletion of an employee e1 with a base salary of 5000 euro and a bonus of 3000 euro, and the target update ut includes a change of the address of e1: • suppose, that the conflict between the deletion of e1 and its change of address is solved delivering a target update wt that does not include that deletion, and suppose that the resulting target model mt3 is consistent. • now, e1 is included in mt3 with an overall salary of 8000 euros, but it is not included in ms1 . then, the backward propagation of w t would include the addition of e1 to the source model including a base salary of 6000 euro and a bonus of 2000 euro. this modification of base salary and bonus is not specified by u, so the synchronization is unsound. the problem with soundness is, in a way, similar to the problem that we found in the previous section that causes that the procedure in [xsht13] may be unable to find a synchronization, even if the given parallel update is conflict-free. however, in this case, if forward propagation is strongly invertible this does not necessarily mean that csync1 should be sound. the problem is in the third step, when constructing the maximal consistent submodel mt2 of m t 3 we may delete some elements from the latter model that need not be deleted according to the given update. the second approach, which we will call csync2, is an extension, including conflict resolution, of the procedure presented in section 5.1. again, we start assuming that we have a parallel update u1 : m ⇒ m1 over an integrated model m. • first, we compute the parallel update u2 = 〈 f ppg(m,us1),bppg(m,u t 1 )〉 : m ⇒ m2. • if u1 and u2 are conflict-free and u1 ⊗ u2 ∈ c, then we can define the result u = csync(m,u1) = (u1 ⊗u2), as in the previous section. otherwise, we look for a maximal update u : m ⇒ m′ that is a solution to the conflicts and such that m′ is consistent. how we can find u and m′ depends on the specific framework. in particular, in the case of working with triple graph grammars, we could use a technique similar to consistency creation (see, e.g., [heeo12]). csync2 satisfies the properties of consistency, identity, soundness and maximal preservation. however, the procedure is not strongly sound, as the example below shows: 15 / 19 volume 57 (2013) on propagation-based concurrent model synchronization • suppose that the source update us1 consists of the addition of a new employee e1, working at a new department d to ms. so the propagation of this update would include adding e1 and d to the target model mt . • suppose that adding e1 to mt creates a conflict with the given target update ut1 (for example, because ut1 includes the addition of another employee with the same name and it is forbidden to have in our model two employees with the same name). • suppose that the conflict is solved by not adding e1 to mt , which means that we would backtrack the addition of e1 to ms. • now, the fact that adding e1 to the mt creates a conflict, it does not mean that the addition of d creates any conflict. hence, in the conflict resolution step we would keep the addition of d to mt . however, if we have backtracked the addition of e1 to ms, adding d to mt would not be a consequence of the propagation of the resulting source update, nor of the original target update. hence, the procedure would not be strongly sound. theorem 3 csync2 satisfies the properties of consistency, identity, soundness and maximal preservation. proof sketch. csync2 is consistent since the resulting integrated model is consistent by construction. if u1 is the identity and m is consistent, then u1 has no conflicts and, as we have seen in thm 1, the result of synchronization is the identity. csync2 is sound since, by construction, all the modifications included in u1 are, by construction, part of u1 or of u2. finally, csync2 also satisfies maximal preservation because of the construction of u1. 6 related work incremental model transformation or (standard) model synchronization is a problem that has been largely studied in different areas of computer science like databases, software engineering, and programming languages (see, e.g., [db82, fkpt08, ste10, hpw11, bpv06, tcc12]. however, to our knowledge, the only approaches that deal with the problem of concurrent synchronization of general models were presented by xiong et al. [xsht09, xsht13] handling the conflict free case and by hermann et al. [heeo12] handling the general case including possibly conflicting updates. we studied both of them in detail in this paper based on an abstract framework of for propagation-based synchronization. other authors have also considered the problem of concurrent synchronization, albeit in a more restrictive setting. in particular, foster et al. [fgk+05] consider this problem, but models are restricted to tree like structures and the target model is an abstract of the source. also, xiong et al.[xhz+09] consider this problem when updates are defined in terms of a given set of operations. different kinds of synchronization frameworks that are based on the concept of lenses [bpv06, hpw12] solve the view update problem in the domain of programming languages. some of these works considered the put-put law as a major requirement [dxc11a, gj12], which ensures compositionality in a rigorous manner. however, as discussed in several proc. bx 2013 16 / 19 eceasst papers and also for our example, the put-put law is often too restrictive for solving the general concurrent synchronization problem. therefore, we presented the properties of soundness and strong soundness that do not enforce compositionality in general, but only in cases where composition of the given updates is compatible with decomposition. this allows us to show that concurrent synchronization can ensure soundness (theorem 3) and even strong soundness in the case of conflict free updates (theorem 1). however, propagation-based approaches have also some disadvantages. the main one, which is not explicit in the paper, is that these procedures may be unable to find some reasonable solutions for the synchronization of a given parallel update. the problem is caused by the fact that, given an update on a given model (e.g. the source model), there may be different ways of propagating that update to the target model. however, since propagation operations are supposed to be deterministic, the operation f ppg would only implement one of these ways. hence, given a parallel update u, the solutions that we may obtain by a propagation-based procedure would only be built from the specific ways of propagating us and ut implemented in f ppg and bppg. in particular, if f ppg and bppg differ from each other in this sense, then the derived synchronization approaches are not hippocratic [ste08], which would require that the synchronization has no effect, if the current integrated model is already consistent. the second problem is related with the fact that, in case of conflicts, the procedures that we have studied do not satisfy some of the properties (especially, soundness or strong soundness) that, a priori, we thought that they should satisfy. however, this is not as important as it may seem to be. our soundness properties are based on the idea that the modifications specified by each source or target update consist of the modifications included in the update and the ones included in its propagation. we believe that this is reasonable in the context of propagation-based methods, but it would be too strong in general. the reason is that, according to the ideas discussed above, there may be reasonable solutions to the synchronization problem that are not based on the given propagation operations. as a consequence, these solutions would probably be unsound, in view of our notion of soundness. 7 conclusion and future work in this paper, we provided a general and abstract framework for handling the problem of concurrent model synchronization using propagation-based approaches. the use of propagation operations has mainly two advantages. the first one is that they provide a simple way of checking the existence of conflicts in a given parallel update. the second one is that the operations for concurrent synchronization are relatively easy to implement, since we may reuse propagation operations defined for the basic synchronization problem. in our main results (theorem 1 and theorem 3), we have shown under which conditions propagation based synchronization approaches ensure maximal preservation of the given updates and soundness (avoidance of side effects). for further work, we believe that it will be interesting to define a concurrent synchronization procedure that is not propagation-based, studying its feasibility and correctness. 17 / 19 volume 57 (2013) on propagation-based concurrent model synchronization bibliography [bpv06] a. bohannon, b. c. pierce, j. a. vaughan. relational lenses: a language for updatable views. in proceedings of the twenty-fifth acm sigact-sigmod-sigart symposium on principles of database systems. acm, 2006. [db82] u. dayal, p. a. bernstein. on the correct translation of update operations on relational views. acm trans. database syst. 7(3):381–416, 1982. [dxc10] z. diskin, y. xiong, k. czarnecki. from stateto delta-based bidirectional model transformations. in proc. icmt 2010. lecture notes in computer science 6142, pp. 61–76. springer, 2010. [dxc11a] z. diskin, y. xiong, k. czarnecki. from stateto delta-based bidirectional model transformations: the asymmetric case. journal of object technology 10:6: 1–25, 2011. [dxc+11b] z. diskin, y. xiong, k. czarnecki, h. ehrig, f. hermann, f. orejas. from stateto delta-based bidirectional model transformations: the symmetric case. in model driven engineering languages and systems, models 2011. lecture notes in computer science 6981, pp. 304–318. springer, 2011. [eept06] h. ehrig, k. ehrig, u. prange, g. taentzer. fundamentals of algebraic graph transformation. eatcs monographs of theoretical comp. sc. springer, 2006. [eet11] h. ehrig, c. ermel, g. taentzer. a formal resolution strategy for operationbased conflicts in model versioning using graph modifications. in fundamental approaches to software engineering, fase 2011. lecture notes in computer science 6603, pp. 202–216. springer, 2011. [egh10] h. ehrig, u. golas, f. hermann. categorical frameworks for graph transformation and hlr systems based on the dpo approach. bulletin of the eatcs 102:111–121, 2010. [fgk+05] j. n. foster, m. b. greenwald, c. kirkegaard, b. c. pierce, a. schmitt. schemadirected data synchronization. technical report ms-cis-05-02, university of pennsylvania, 2005. [fkpt08] r. fagin, p. g. kolaitis, l. popa, w. c. tan. quasi-inverses of schema mappings. acm trans. database syst. 33(2), 2008. [gj12] j. gibbons, m. johnson. relating algebraic and coalgebraic descriptions of lenses. electronic communications of the easst (eceasst) 49, 2012. [heeo12] f. hermann, h. ehrig, c. ermel, f. orejas. concurrent model synchronization with conflict resolution based on triple graph grammars. in fundamental approaches to software engineering, fase 2012. lecture notes in computer science 7212, pp. 178–193. springer, 2012. proc. bx 2013 18 / 19 eceasst [heo+11] f. hermann, h. ehrig, f. orejas, k. czarnecki, z. diskin, y. xiong. correctness of model synchronization based on triple graph grammars. in model driven engineering languages and systems, models 2011. lecture notes in computer science 6981, pp. 668–682. springer, 2011. [hpw11] m. hofmann, b. c. pierce, d. wagner. symmetric lenses. in proceedings of the 38th acm sigplan-sigact symposium on principles of programming languages, popl 2011. pp. 371–384. acm, 2011. [hpw12] m. hofmann, b. c. pierce, d. wagner. edit lenses. in field and hicks (eds.), proc. symp. on principles of programming languages (popl’12). pp. 495–508. acm, 2012. [ls05] s. lack, p. sobocinski. adhesive and quasiadhesive categories. theor. inf. app. 39:511–545, 2005. [sk08] a. schürr, f. klar. 15 years of triple graph grammars. in proc. int. conf. on graph transformation (icgt 2008). pp. 411–425. 2008. doi:10.1007/978-3-540-87405-8 28 [ste08] p. stevens. towards an algebraic theory of bidirectional transformations. in ehrig et al. (eds.), proc. int. conf. on graph transformation (icgt’08). lecture notes in computer science 5214, pp. 1–17. springer, 2008. [ste10] p. stevens. bidirectional model transformations in qvt: semantic issues and open questions. software and system modeling 9(1):7–20, 2010. [ste12] p. stevens. observations relating to the equivalences induced on model sets by bidirectional transformations. eceasst 49, 2012. [tcc12] j. f. terwilliger, a. cleve, c. curino. how clean is your sandbox? towards a unified theoretical framework for incremental bidirectional transformations. in theory and practice of model transformations 5th international conference, icmt 2012. lecture notes in computer science 7307, pp. 1–23. springer, 2012. [xhz+09] y. xiong, z. hu, h. zhao, h. song, m. takeichi, h. mei. supporting automatic model inconsistency fixing. in esec/fse 2009. pp. 315–324. 2009. [xsht09] y. xiong, h. song, z. hu, m. takeichi. supporting parallel updates with bidirectional model transformations. in theory and practice of model transformations, icmt 2009. lecture notes in computer science 5563, pp. 213–228. springer, 2009. [xsht13] y. xiong, h. song, z. hu, m. takeichi. synchronizing concurrent model updates based on bidirectional transformation. software and system modeling 12(1):89– 104, 2013. 19 / 19 volume 57 (2013) http://dx.doi.org/10.1007/978-3-540-87405-8_28 introduction running example the basic framework models and updates integrated models and update propagation propagation-based concurrent synchronization strategies for propagation-based concurrent synchronization conflict-free concurrent synchronization conflicts and concurrent synchronization related work conclusion and future work qbf with soft variables electronic communications of the easst volume 70 (2014) proceedings of the 14th international workshop on automated verification of critical systems (avocs 2014) qbf with soft variables sven reimer, matthias sauer, paolo marin, bernd becker 15 pages guest editors: marieke huisman, jaco van de pol managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ qbf with soft variables sven reimer, matthias sauer, paolo marin, bernd becker institute of computer science, albert-ludwigs-universität freiburg georges-köhler-allee 051, d-79110 freiburg, germany {reimer | sauerm | marin | becker}@informatik.uni-freiburg.de abstract: qbf formulae are usually considered in prenex form, i.e. the quantifier block is completely separated from the propositional part of the qbf. among others, the semantics of the qbf is defined by the sequence of the variables within the prefix, where existentially quantified variables depend on all universally quantified variables stated to the left. in this paper we extend that classical definition and consider a new quantification type which we call soft variable. the idea is to allow a flexible position and quantifier type for these variables. hence the type of quantifier of the soft variable can also be altered. based on this concept, we present an optimization problem seeking an optimal prefix as defined by user-given preferences. we state an algorithm based on maxqbf, and present several applications – mainly from verification area – which can be naturally translated into the optimization problem for qbf with soft variables. we further implemented a prototype solver for this formalism, and compare our approach to previous work, that differently from ours does not guarantee optimality and completeness. keywords: qbf, maxqbf, prefix, dependency, optimization problem 1 introduction for design automation tasks in safety-critical or other domains where precise answers are necessary, applications employing quantified boolean formulae (qbf) logic have been demonstrated to be an effective solution: in contrast to the traditional sat-based 01x-encoding [jbm+00], qbf delivers accurate answers by accurately considering unknown and unspecified signals [sb01], which is also named zi-encoding [hb07]. in particular universally quantified variables in qbf are used to accurately model the behavior of unknown circuit lines. the encoding of such problems is often not trivial and the effort required to solve them strongly depends on the prefix order, i. e. the user-given dependencies between the existential and universal variables. additionally, there is an increasing interest for optimization problems with qbf [blv08, ijm13] in the game theory domain [cp04]. however, in the classical definition of a qbf, the prefix is known and fixed. research interests considering the possibility of changing the given prefix structure is focused on simplifying the solving to a given qbf without changing its meaning, e.g. by optimizing decision strategies in search-based solving [gnt07]. more generalized approaches apply so-called dependency schemes [sam08] focusing on tractable algorithms, i. e. heuristics with polynomial complexity, optimizing the prefix order wrt. the dependencies between the variables. as we will show in this paper, there is a relation between the prefix order and the optimization problem for maximizing unknown values within a circuit [rs04, nsb07, pr00]. e. g., one seeks for a maximum number of don’t care signals at the input of a circuit in order to generalize a found solution [rs04]. since in qbf these don’t care or unknown values are modeled by universally quantified variables, one needs the possibility to change the quantifier for a particular variable from existential to universal and vice versa in order to optimize the number of unknowns. in pure qbf, quantifiers have to be given a-priori and cannot be changed. this work was partly supported by the german research council (dfg) as part of the transregional collaborative research center “automatic verification and analysis of complex systems” (sfb/tr 14 avacs). 1 in this paper we present a new formalism based on qbf supporting a dynamic prefix using so-called soft variables. in contrast to previous perceptions, our approach allows to change the prefix position of such soft variables dynamically. in particular, the quantifier from existential to universal can be altered and vice versa. technically the mechanism provides a set of possible qbf prefixes. the challenge is to find a satisfiability preserving prefix such that the soft variables are quantified following an ordering as close as possible to user-given preferences. we define an optimization problem for qbf with soft variables and an algorithm returning the optimal prefix. the algorithm is based on the optimization problem called maxqbf [cfls93]. we highlight the importance of our formalism by showing applications from different verification areas, which are naturally covered by our formalism. previous work on these applications has two main disadvantages: • most approaches use a sat-based encoding, which is less precise than a qbf represenation (with soft variables). • applications using qbf formulations usually need more encoding effort than approximate sat encodings. as we will show, the optimization problem for solving qbf with soft variables is pspace-complete (as qbf), but allows a more compact and in many cases “easier” representation of the problem statement than pure qbf. we developed a prototype solver for solving both: 1) maxqbf based on [ijm13] and 2) qbf with soft variables based on maxqbf. first experimental results demonstrate the applicability of our implementation and the advantage of the solution compared to heuristic approaches. the paper is structured as follows: in §2 we introduce basic information, terminology, and notation used throughout the paper. in §3 the concept of qbf with soft variables is introduced as well as an algorithm to solve the problem. we introduce applications for the formalism and first experimental results for some of those in §4. lastly, §5 concludes the paper and discusses future work on this topic. 2 preliminaries in this section we introduce the notation and some background on solving techniques, and some further details necessary for a good comprehension of this paper. we assume that propositional logic and the sat problem is familiar to the reader. the interested reader is referred to [bhmw09] for further insight in optimization problems in propositional logic and qbf. 2.1 qbf the logic of quantified boolean formulae (qbf) is an extension of sat by bounding the variables to quantifiers q∈{∃,∀}. in the following, we will consider prenex conjunctive normal form formulae (pcnf) ψ = q1x1 ...qnxn.ϕ, where ϕ is a quantifier free matrix in cnf. we denote with v the set of variables occurring in ϕ. we call p = q1x1 ...qnxn the prefix of ψ. w.l.o.g. qi 6= qi+1 for all i∈{1,...,n−1}, i. e. the existential and universal quantifiers have an alternating order, and x1,...,xn are disjoint sets of variables with x1 ⋃ ... ⋃ xn := x.1 we define a quantifier level function δ : x → n for a variable x as δ(x) = i for x∈xi. in the following, w.l.o.g. we set q1 = ∃, in particular, variables on odd quantification levels are always existentially quantified and on even levels universally quantified. we say that an existential variable x∈xi depends on all universal variables y ∈xj with j < i and qj = ∀, i. e. the assignment of x depends on the assignment of y. a variable x∈w = v\x is not bound by any quantifier and is called free variable. if ψ contains free variables, then ψ is an open qbf, otherwise it is a closed formula. given a set of variables v 1 note that xi = ∅ or x 6= v may hold 2 and an open qbf ψ, we say that some variable valuation f ∈ (w →b) is a model of ψ iff ψ(f) = >, and ψ(w ) is satisfiability equivalent to the closed qbf where the free variables w are existentially quantified at level 1. the co-factor of a propositional formula is defined as ϕ|x = ϕ[x = >] and ϕ|x = ϕ[x = ⊥] respectively, where ϕ[x = c] denotes a propositional formula with every occurrence of x replaced by the value c∈{>,⊥}. similarly, ψ|x is defined as the qbf where the matrix ϕ is replaced by ϕ|x and all superfluous quantifications are excluded from the prefix (and analogously for ψ|x). we define the semantics of qbf recursively as follows: qx ψ = { ψ|x∧ ψ|x if q = ∀ ψ|x∨ ψ|x if q = ∃ if ϕ does contain an empty clause, ψ is unsatisfied, otherwise satisfied in case no variable is left unassigned. 2.2 maxqbf maxqbf (also referred to as maxqsat in the literature) is an extension of qbf for optimization problems [cfls93]. the semantics is similar to the analogous optimization problem for sat, called maxsat. a maxsat procedure tries to satisfy as many clauses of a propositional formula as possible. we denote these clauses as soft clauses. the optimization problem for qbf ensures that these soft clauses have to be satisfied for every branch of the universal variables. there are some extensions of maxsat which can be adapted quite naturally to maxqbf: • weighted maxsat/qbf: each soft clause c is associated with a non-negative integer weight ω(c). if a clause is satisfied, the clause gains ω(c) as score, otherwise the score of the clause is 0. the objective is to maximize the sum of the scores. • partial maxsat/qbf: there are two types of clauses: hard clauses and soft clauses. hard clauses must be satisfied, while soft clauses may be satisfied. the objective is to maximize the number of satisfied soft clauses. • weighted partial maxsat/qbf: combination of the two concepts stated above. to the best of our knowledge there exist only two references proposing exact algorithms to solve optimization problems over quantified formulae: [blv08] considers quantified constraint optimization problems (qcop) as extension of constraint optimization problems (cop). in [ijm13] the authors propose two algorithms for solving the related qmaxsat problem: given a qbf instead of optimizing the number of satisfied soft clauses, the goal is to maximize a linear pseudoboolean cost function. the maxqbf problem can be easily expressed by this formalism and vice versa. 3 qbf with soft variables in this section we describe the concept of soft variables in qbf, as well as an algorithmic approach for solving this formalism using maxqbf, and an algorithm for solving maxqbf problems. finally, we state some details of our implementations. 3.1 soft variables the syntax of soft variables in the context of a qbf is defined as follows. definition 1 consider a qbf ψ = p.ϕ, a boolean variable s∈v and a set of natural numbers l. we call s a soft variable iff the following properties hold: 3 1. s does not occur in p , and 2. l is a set of quantification levels on which s is designated to be quantified, also called the quantification set of s. we denote with æ ls a soft variable s, where l contains all possible prefix positions. furthermore we write ψ( æ l1s1,..., æ lnsn), indicating that s1,...,sn are soft variables of ψ with possible prefix positions lj, for each j ∈{1,...,n}. we write sψ indicating the set of all soft variables in ψ. moreover, we allow soft variable groups s, written æ ls. we write ψ( æ l1s1,..., æ lnsn) for a qbf ψ with different groups of soft variables sj. we also allow combinations of soft variables and groups of soft variables within a qbf. in the following we distinguish the two cases by using capital letters for groups and small letters for variables. definition 2 let ψ( æ l1s1,..., æ lnsn) be a qbf with soft variables. we call λ : sψ → n the level function of ψ which maps each variable sj to a quantification level l∈lj. given such a level function λ we denote ψ( æ l1s1,..., æ lnsn)λ as the qbf where every soft variable is mapped to one possible quantification level within p of ψ according to λ. for each soft variable of one soft variable group sj ∈s the level function has to be same value, i. e. sj = l for a fixed level l and for all sj ∈s. intuitively ψ( æ l1s1,..., æ lnsn) is a set of qbf with different prefixes for the soft variables, to be more precise every qbf resulting from every possible level function λ of ψ. example 1 consider the qbf with soft variables ψ1 with a matrix ϕ1 = (s1 ∨y)∧(s1 ∨z)∧(y∨ z)∧(s1 ∨y), where s1 is a soft variable in the scope of all existential levels: ψ1( æ {1,3}s1) = ∀y∃z.(s1 ∨y)∧(s1 ∨z)∧(y∨z)∧(s1 ∨y) by definition we are allowed to set s1 either to the first or third (i. e. an existential) level, resulting in the two possible level functions with λ1(s1) = 1 and λ2(s1) = 3, and therefore in two possible prefixes p1 =∃s1∀y∃z and p2 =∀y∃z∃s1. the qbf ψ1( æ {1,3}s1)λ1 = p1.ϕ1 is unsatisfiable, whereas ψ1( æ {1,3}s1)λ2 = p2.ϕ1 results in a satisfied matrix for all branches of the universal variable y, i. e. is satisfied. now consider the formula ψ2 with a matrix ϕ2 = (y∨z)∧(s2 ∨z)∧(s2 ∨y∨z) where s2 is a soft variable with level 2 and 3 as possible prefix positions: ψ2( æ {2,3}s2) = ∀y∃z.(y∨z)∧(s2 ∨z)∧(s2 ∨y∨z) by applying the soft variable concept we obtain two possible level functions with λ3(s2) = 2 and λ4(s2) = 3 and the respective prefixes p3 =∀y∀s2∃z and p4 =∀y∃z∃s2. both ψ2( æ {2,3}s2)λ3 = p3.ϕ2 and ψ2( æ {2,3}s2)λ4 = p4.ϕ2 are satisfiable. based on this syntax we briefly define the semantics of a qbf with soft variables. definition 3 a qbf with soft variables ψ( æ l1s1,..., æ lnsn) is satisfied iff there exists a level function λ such that ψ( æ l1s1,..., æ lnsn)λ is satisfied. if for all possible level functions the resulting qbf is unsatisfied, we say ψ( æ l1s1,..., æ lnsn) is unsatisfiable. we want to consider an optimization problem for qbf with soft variables. to do so, we first define a score function σ as follows: definition 4 let ψ( æ l1s1,..., æ lnsn) be a qbf with soft variables s1,...,sn. the score function σ : (sψ×n) →n is defined for each variable sj as σ(sj,l) = χsj,l, where χsj,l is a user-given score 4 and lj the corresponding level with λ(sj) = lj. the overall score χλ is the sum of all scores for one level function λ: χλ = ∑n j=1 χsj,lj . the score function allows to define the optimization problem ω(ψ( æ l1s1,..., æ lnsn)) as follows: definition 5 given a qbf with soft variables ψ( æ l1s1,..., æ lnsn) and a score function σ of ψ, the optimization problem ω(ψ( æ l1s1,..., æ lnsn)) is to find a level function λ maximizing the score χλ such that ψ( æ l1s1,..., æ lnsn)λ is satisfied, i. e. ω(ψ( æ l1s1,..., æ lnsn)) = max λ χλ. if ψ( æ l1s1,..., æ lnsn)λ is unsatisfied, the score is χλ = 0. example 2 consider the qbf ψ1 of example 1. we chose the following scores: σ(s1,1) = 2 and σ(s1,3) = 1. the qbf ψ1( æ {1,3}s1)λ1 is unsatisfied, and therefore the score evaluates to χλ1 = χs1,1 = 0. since ψ1( æ {1,3}s1)λ2 is satisfied, we yield the score χλ2 = χs1,3 = 1, which is also the maximum score over all possible level functions λ of ψ1 and thus the result of the maximization problem ω(ψ( æ {1,3}s1)) is 1 with λ2. considering ψ2 from example 1, we chose the scores σ(s,2) = 2 and σ(s,3) = 1. ψ2( æ {2,3}s2)λ3 as well as ψ2( æ {2,3}s2)λ4 are satisfied and gain the scores χλ3 = χs2,2 = 2 and χλ4 = χs2,3 = 1. hence, we obtain ω(ψ2( æ {2,3}s2)) = 2 with level function λ3 as solution to the optimization problem. please note, in this example we chose the weights for both formulae in a meaningful way: the qbf where the soft variable is quantified on a level which is more likely to be unsatisfiable gets the higher score. proposition 1 solving the optimization problem ω(ψ( æ l1s1,..., æ lnsn)) is pspace-complete. proof. (sketch) to decide the optimization problem we need to solve a qbf problem for each possible level function. qbf is in pspace [sm73] and since we only need to store the currently optimal level function and its score, which needs polynomial space, the optimization problem for qbf with soft variables is also in pspace. for pspace-hardness we reduce from qbf which is pspace-hard [sm73]. let ψ be a qbf ψ = q1x1 ...qnxn.ϕ. let m be a new existential level with m > n. we define a qbf with soft variables: ψ′( æ {1,m}x1,..., æ {n,m}xn) = ϕ, i. e. ψ′ is obtained from ψ by eliminating p and declaring each variable in x as part of a soft variable group xi. the possible prefix positions are chosen such that the whole group xi is either quantified at level i as in ψ, or at the new level m. we define the score function σ such that for each soft variable group xi both σ(xi,m) = 0 and σ(xi,i) = 1 holds, i. e. the preference is to set the group to the level it belonged to in ψ. the maximization problem for qbf with soft variables tries to set all groups of ψ′ to the corresponding position in ψ. from the result of the qbf with soft variables problem ω(ψ′) = max λ χλ we directly obtain the satisfiability value of ψ: if at least one soft variable group is not set at level i < m in λ of ψ′ or max λ χλ = 0 holds, the qbf ψ is unsatisfiable. otherwise, if all groups xi are set to level i, the qbf ψ is satisfiable. 3.2 algorithm in this section we describe an algorithm to solve the optimization problem for qbf with soft variables which is based on weighted partial maxqbf. to do so, we present an approach for solving maxqbf (and its extensions) based on iterative maxsat algorithms. 3.2.1 solving qbf with soft variables let ψ( æ l1s1,..., æ lnsn) = p.ϕ be a qbf with soft variables s1,...,sn, p a prefix over the variables x, and ϕ a quantifier free matrix over the variables v. in the following we show how to transform 5 this problem into a weighted partial maxqbf problem. therefore, we need to transform our formalism into a qbf without any soft variables. we denote emax of ψ as the innermost existential level with no further (existential or universal) quantification level right of emax. hence, emax is the right-most existential level wrt. the current prefix p and all levels l∈lj for all j ∈{1,...,n}. the following extensions/modifications have to be applied for each soft variable sj, j ∈{1,...,n}: we quantify sj on level emax existentially such that the appearances of sj in the matrix is welldefined. for each level l∈lj we introduce a new quantification of a helper variable slj on level l and a new free variable flj of ψ. these helper variables allows us to alter the quantification levels by setting flj appropriately. therefore, we connect these variables to ϕ by the constraint f l j ⇒ (s l j ≡sj) for each l∈lj, i. e. we set sj to slj (and hence sj quantified on level emax semantically “behaves” like the variable slj quantified on level l) if the free variable f l j is set to >. we have to ensure that exactly one flj for all l ∈l j is set to > and all other fkj , k 6= l are set to ⊥, which is also known as an exactly-one constraint. we add the encoding of such a constraint for each new free variable of every soft variable to ϕ. we declare every clause of ϕ as well as every additional constraint we introduced so far as hard clause of the weighted partial maxqbf instance. finally, we add an additional unit clause for each free variable flj, declared as soft clause with weight σ(sj,l). a weighted partial maxqbf solver maximizes these weights, i. e. the score function σ is directly mapped to a the maximum number of satisfied unit soft clauses triggering a soft variable to be set on the corresponding position in the prefix. for the free variables flj we obtain a model from which we can extract the level function λ: if flj is set to >, λ(sj) = l holds. by construction, χλ is the maximum score of ψ( æ l1s1,..., æ lnsn). remark 1 handling groups s of soft variables is analogous to the method described above. instead of introducing a free variable flj for each variable and level, we only have to introduce one f l s for each level and group, i. e. every variable of a group s is either quantified simultaneously on l or not. the additionally introduced constraint is fls ⇒ (s l j ≡sj) for each sj ∈s. example 3 consider ψ1 from our running example. first, we introduce the soft variable æ {1,3}s1 into p by introducing an existential quantification ∃s1 on level emax = 3. by definition, æ {1,3}s1 can be quantified on both existential levels 1 and 3, therefore we introduce two existential helper variables s11 and s 3 1 as well as two new free variables f 1 1 and f 3 1 . moreover, we introduce a cnf representation for the constraints f11 ⇒ (s11 ≡ s1) and f31 ⇒ (s31 ≡ s1), the constraints for the exactly-one-constraint, and the unit clauses for the free variables into ϕ1, resulting in: ∃s11∀y∃s 3 1∃z∃s1. original ϕ1︷︸︸︷ (s1 ∨y)∧(s1 ∨z)∧(y∨z)∧(s1 ∨y)∧ (f11 ∨s 1 1 ∨s1)∧(f11 ∨s11 ∨s1)︸︷︷︸ f11⇒(s 1 1≡s1) ∧(f31 ∨s 3 1 ∨s1)∧(f31 ∨s31 ∨s1)︸︷︷︸ f31⇒(s 3 1≡s1) ∧ (f11 ∨f31 )∧(f 1 1 ∨f 3 1 )︸︷︷︸ exactly-one ∧(f11 )∧(f 3 1 )︸︷︷︸ soft clauses this instance is passed to a weighted partial maxqbf solver, where (f11 ) and (f31 ) are declared as soft clauses with weight 2 and 1 respectively. all other clauses are declared as hard clauses. analogously we obtain for ψ2 the following weighted partial maxqbf instance: ∀s22∀y∃s 3 2∃z∃s2. (y∨z)∧(s2 ∨z)∧(s2 ∨y∨z)∧ (f22 ∨s 2 2 ∨s2)∧(f22 ∨s22 ∨s2)∧(f32 ∨s 3 2 ∨s2)∧(f32 ∨s32 ∨s2)∧ (f22 ∨f32 )∧(f 2 2 ∨f 3 2 )∧(f22 )∧(f32 ) 6 with the soft clauses (f22 ) and (f32 ) and weights 2 and 1, respectively. 3.2.2 solving maxqbf in this section we present an approach for solving maxqbf and its extensions based on iterative methods from maxsat [zsm03]. the method is also mentioned in [ijm13], but we present some further details. first, we describe the iterative approach in maxsat and then we introduce how to adapt this technique for maxqbf. iterative maxsat solvers as introduced in [zsm03] add a new relaxation literal r to each soft clause. if r is set to ⊥, the corresponding soft clause has to be satisfied, otherwise (r = >) the clause is relaxed, i. e., it is satisfied by the relaxation literal and hence, the (original) soft clause does not have to be satisfied by the set of variables belonging to the original cnf. let ϕ be the original maxsat instance with m soft clauses including a unique relaxation literal (r1,...,rm) for each soft clause. in an iterative approach the relaxation literals are connected to the inputs of a cardinality network [sin05] and the instance ϕ∧β(r1,...,rm)∧(oi) is handed over to a sat solver, where β(r1,...,rm) is the cnf encoding for such a cardinality network, with r1,...,rm as inputs and o1,...,om as outputs. the additional unit clause (oi) demands at least i arbitrary inputs of the network to be set to ⊥, therefore i soft clauses have to be satisfied. if this sat instance is satisfiable, there are at least i simultaneously satisfied soft clauses, otherwise there exists no solution with i satisfied soft clauses. the solution is narrowed by the incremental usage of the underlying sat solver until a value k is identified with ϕ∧β(r1,...,rm)∧(ok) being satisfiable and ϕ∧β(r1,...,rm)∧(ok+1) being unsatisfiable. this value k is the maximum number of simultaneously satisfied soft clauses. this procedure can be easily extended to the partial maxsat and weighted maxsat concepts: in partial maxsat, hard clauses are not connected to the network, and in weighted maxsat a soft clause c is connected ω(c) times into the network, where ω(c) is the weight of the clause c. the algorithm for weighted partial maxsat is obtained by a straight-forward combination of both methods. we adapt this concept for maxqbf by using an incremental qbf solver. the cardinality network and the relaxation variables are encoded as in maxsat. the variables for the encoding are added as free variables of the qbf, since a soft clause has to be satisfied for every branch of the universal variables and we are able to obtain a model for these variables as a result from solving the open qbf. likewise to maxsat we call the qbf solver incrementally in order to find a value k such that the qbf with k satisfied soft clauses is satisfied, but unsatisfied with k + 1 clauses. the extension for partial maxqbf, weighted maxqbf and weighted partial maxqbf is done in the same manner as for the maxsat extension. 3.2.3 implementation details we implemented a weighted partial maxqbf solver as well as the algorithm for solving qbf with soft variables. for the maxqbf solver we used the qbf solver quantom [rpsb12] and implemented incremental functionality based on [mmb12]. for the model of the free variables (representing the level function λ) we adapt techniques of [belm12]. for scalability reasons we also use a preprocessor for qbf. the preprocessor is implemented for incremental usage (see also [mmlb12]) as well as model preservation techniques known from sat [eb05] adapted to qbf. all variables which are introduced in context of a soft variable are set as “don’t touch”[klsb11] in the preprocessor, i. e. these variable are excluded from several preprocessing techniques, among others variable elimination and pure literal detection. for an exactly-one-constraint with more than 5 possible levels (i. e. |lj|> 5), we use the encoding for lt n,1 seq as presented in [sin05] using o(|l j|) clauses and o(|lj|) additional auxiliary variables 7 only. otherwise we introduce a standard one-hot encoding using o(|lj|2) additional clauses.2 for some instances (cf. §4.1) the encoding can be simplified to a pure partial maxqbf problem if the following requirements hold: 1) the soft variables are only defined over two different levels and 2) for all soft variables the weight function assigns for one level 0 and for the other level a constant value c > 0. if this is the case we can add just one free variable per soft variable with the constraints: flj ⇒ (s l j ≡sj) and flj ⇒ (s k j ≡sj), where l is the preferred level with weight c and k is the level with weight 0. moreover, just one soft clause (flj) for each soft variable is added. 4 applications in this section we present several applications, mainly from verification and testing of circuits, covered by qbf with soft variables. in §4.1 we present optimization problems considering unknowns in a circuit, and in §4.2 we present further applications, for example optimal solutions for dependency schemes. the measurements for all case studies were performed on a machine using one core of a 3.3 ghz intel xeon, and limiting the memory to 4 gb. 4.1 maximizing unknowns in a circuit there are plenty of applications which ask for maximizing or optimizing unknown values within a circuit. there are two general problem statements, given a circuit together with a property which has to hold, we want to optimize: 1) the solution by introducing unknown values for the internal circuit lines or the inputs, and 2) secondary objectives in presence of unspecified values such that the property still holds. in the first case the unknown values generalize (or uniform) the solution, whereas in the second case some parts of the circuit are abstracted by introducing universal quantifications in an appropriate qbf and we want to optimize further objectives in presence of these unknowns. in the following part of this section we briefly review classical algorithms discussing differences to the qbf with soft variable formulation. finally, we introduce specific problem statements as well as first case studies for some application with our prototype solver. we define a metric representing the quality loss of heuristic methods compared to our approach as: loss(method) = 1− xm ethod xqbf where xmethod is the number of maximized unknowns computed by an approximate method, and xqbf is the value computed by qbf using soft variables. 4.1.1 comparison to previous work to model unknown values in a circuit, commonly 01x-encoding [jbm+00] applying sat-based methods is used. another popular sat-based heuristic is lifting [rs04] which was introduced for minimal counterexamples (cf. §4.1.6). this method does not need any 01x-encoding, instead the optimization is done directly on the extracted model of a satisfied sat instance. however, 01x-logic is a pessimistic abstraction. in many applications, more precise solutions which then need a qbf formulation for the unknown values [sb01] are preferred. and although in an optimal case the lifting technique yields solutions as exact as a qbf formulation, it does not guarantee optimal ones due to its heuristic methodology. in qbf each unknown value is associated to a universally quantified variable. in contrast to sat-based methods, the maximization with classical qbf-based methods is a harder problem, since the semantics of qbf binds each variable to its quantifier, i. e. the quantifier is statically declared and cannot be changed to the purpose of optimizing over unknown lines. 2 as shown in [sin05] the encoding for lt n,1 seq is superior to the näıve encoding for n > 5. 8 qbf with soft variables overcomes this issue. for any line which is part of the unknown maximization a soft variable is introduced, and this allows to switch between existential (known) and universal (unknown) quantification (values). shortly, the qbf with soft variables concept provides a compact representation for modelling unknowns, which is more precise than classical 01x-based approaches and guarantees optimal solution in general. more details of the encoding are presented in the following subsections. 4.1.2 uniform counterexamples exploiting partial designs is useful e. g. in the following cases: 1) abstraction of complex parts of the system, 2) early step of the design process where not all parts are done, and 3) for diagnosis – in case a bug is present in the design and it is still present while parts are removed, there must be errors outside the black boxes. there exist different encoding methods for these hidden parts (usually called black boxes ) [sb01], and the approach for using them in a bmc context [nsb07] is the so-called black box bounded model checking (bbbmc). one question in bbbmc is whether a property of the system is satisfied for each possible realization of the black boxes. a bbbmc can be written as the following qbf problem: ψ = ∃x1∀z1∃x2∀z2 ...∃xk∀zk.i0 ∧t0,1 ...∧tk−1,k ∧¬pk, where xi are the inputs of the transition relation and zi are the outputs of the black box at depth i. if the property cannot be fulfilled, it is interesting to obtain a counterexample for the inputs xi. using this encoding, only the assignments for the inputs x1 are the same for each possible black box implementation – all other inputs may differ depending on the black box implementation. to overcome this issue one can define a uniform qbf prefix as follows: ψuni = ∃x1 ...∃xk∀z1 ...∀zk.i0 ∧t0,1 ...∧tk−1,k∧¬pk. note that these two representations are not equivalent: ψ ensures that the primary inputs of each unrolling depth can “react” to the black box output, whereas in ψuni the inputs are independent from the black box implementation. hence, ψ is more accurate than ψuni, nonetheless ψuni returns a more general counterexample. in [nsb07] the authors specify partially uniform qbf, i. e., parts of a counterexample which can be generalized without losing accuracy are identified. the proposed method uses symbolic model checking modelling the unknown values with the pessimistic 01x-logic. qbf with soft variables formulation the uniform counterexample problem can be solved optimally in the number of inputs which are uniform by applying qbf with soft variables. let xij ∈xi and |xi| be the number of variables in xi. we state the qbf with soft variables problem as follows: ψ( æ {1,3}x 3 1,..., æ {1,3}x 3 |x3|,..., æ {1,k}x k |xk| ) = ∃x1∀z1∃∅∀z1 ...∃∅∀zk.i0∧t0,1 ...∧ tk−1,k∧¬pk, i. e. for each input variable at level i we introduce a soft variable trying to shift the quantifier to the first level. once a variable is quantified at the first level and the qbf is still satisfied, this input is independent from every black box and therefore uniform. we choose the score function σ such that level 1 is more advisable than level i, the solution of the qbf with soft variables problem is the optimal uniform counterexample. for this and all upcoming applications in §4.1, the score function assigns the same score for each variable, e. g. 1 for the preferred level and 0 for the non-preferred (cf. §3.2.3). in this case, we obtain a globally optimal result. but it would be also possible to prefer particular variables by assigning larger scores. 4.1.3 diagnosis as described in §4.1.2, black boxes can be used for diagnosis tasks: if a property of the system is violated regardless of the excluded parts, the failure has to occur in the non-excluded part. a challenge is to identify the black boxed part automatically, such that the remaining sub-circuit is as small as possible. in this case already the non-abstracted circuit is sufficient for the violation of 9 the property which would simplify the diagnosis task. to the best of our knowledge this problem statement is not tackled so far, even with pessimistic 01x-encoding. using qbf with soft variables using the standard tseitin-encoding [tse68] to produce a propositional formula, every line li is associated to a boolean variable. hence we can define a soft variable for each line3 obtaining the following qbf with soft variables: ψ( æ {2,3}l1,..., æ {2,3}lk) = ∃∅∀∅∃x1 ...∃xn.ϕ∧¬p, where xi are inputs of the circuit, ϕ its encoding, and ¬p the violated property. by preferring universal quantification in the score function, the result of the optimization problem indicates a maximal number of lines, which can be excluded such that the bug is still present. note, that this result is not accurate anymore in this scenario as discussed in §5. in order to reduce the complexity one may not consider every line but only specific ones, or consider different groups of lines separately and examine them incrementally. 4.1.4 circuit initialization the problem of circuit initialization is a well known problem in the area of testing [pr00] and is closely related to state reachability problems known from bmc [rssb14]. the problem asks whether a sequential circuit is initializable, i. e. all flip-flops can be set to a known value assuming the initial state is (completely) unknown. if this is not the case (which usually applies), one can seek for two related optimization questions: 1) starting from a unknown state what is the maximum number of initialized flip-flops, or 2) what is the smallest number of initially controlled flip-flops needed to initialize the complete circuit. for both objectives a minimal trace length is preferred. classical approaches either solve this problem heuristically (e. g. [pr00]) or are complete, but only with the pessimistic 01x-logic (cf. [rssb14]). so far there is no approach that applies a complete method using the accurate qbf modelling for the unknown values. using qbf with soft variables based on the method in [rssb14], we can define a bmc problem based on qbf with soft variables. let gij ∈gi be a variable representing the value of a flip-flop at depth i and |gi| the number of variables in gi. for the objective 1) we obtain: ψ( æ {1,2}g k 1,..., æ {1,2}g k |gk| ) = ∃∅∀g0∃g1 ...∃gk−1.i0 ∧t0,1 ...∧tk−1,k∧pk. if the score functions recommend to quantify a soft variable existentially on the first level, the maximum number of initialized flip-flops in time step k is given by the number of these existentially quantified variables. the second objective 2) can be expressed as: ψ( æ {2,3}g 0 1,..., æ {2,3}g 0 |g0|) =∃gk∀∅∃g1 ...∃gk−1.i0∧ t0,1 ...∧tk−1,k∧pk. here, gk is quantified on the first level since we have to ensure that the value for the flip-flops in the k’th time step are fixed to a specific known value independently from the potentially unknown flip-flop values of the initial time step 0. by applying a score function favoring the quantification of soft variables at the universal level 2, the result for this optimization problem is equivalent to the minimum number of controlled flip-flops in the first time step. note, in contrast to the method in [rssb14], this approach does not contain a proof whether more flip-flops can be initialized in further time steps, but it provides more accurate results as shown in the following case study. case study we applied the encoding to the benchmark b06 from the itc 99 benchmark series which is commonly used in the eda community and previously proven to be not completely initializable using 01x-encoding [rssb14]. however, using qbf with soft variables, we have identified an initialization sequence of 5 time steps driving each flip-flop to a specified value. 3 it may be meaningful to define groups of lines (e. g. buses or outputs of a specific module such as multiplier), which can be defined analogously. 10 b0 6 b0 7 b0 8 b0 9 b1 0 b11 b1 2 b1 3 b1 5 s0 11 9 6 s0 1 2 3 8 s0 1 4 2 3 s0 1 4 8 8 s0 1 4 9 4 s0 5 3 7 8 s1 3 2 0 7 s3 5 9 3 2 s3 8 4 1 7 0% 5% 10% 15% 20% 25% 01x lifting simulation figure 1: loss for test pattern relaxation using approximated methods 4.1.5 test pattern relaxation in the area of testing [jg03] and in particular automatic test pattern generation (atpg) the number of specified input bits in a test pattern is a major quality metric. partially specified test patterns, so-called test cubes, serve as a foundation for further post-processing steps controlling secondary objectives, e. g. compaction, or test power reduction. as the quality of these methods depends on the number of unspecified values, test patterns with a greater amount of unspecified inputs are preferred. using qbf with soft variables once a test pattern is found, we introduce soft variables for all inputs x1,...,xn in order to preferably treat them as unknowns. a resulting qbf may look like: ψ( æ {2,3}x1,..., æ {2,3}xn) = ∃∅∀∅∃y.ϕ, where ϕ is the encoding of the circuit using variables v and the property justifying the test pattern. if the score function is built favoring the universal quantification level, one obtains the maximum number of lines that can be excluded from the test pattern such that the fault is still visible. case study in [srp+13] an approach using an accurate qbf modeling was already presented, however without using the soft variable concept. for the common iscas 89 and itc 99 benchmark circuits we generated minimal test cubes for 100 test pattern detecting small delay faults [jg03]. we used qbf with soft variables to document the quality loss of common heuristics (01x, lifting, and simulation) in the number of unspecified inputs compared to the optimal solution. fig. 1 shows the quality loss for different benchmarks. as it can be seen, depending on the internal structure of the individual benchmark the heuristics can identify up to 23% less unspecified inputs for benchmark circuit b09. 4.1.6 minimal counterexamples sat-based bounded model checking (bmc) [bcc+03] is a formal verification technique for designs modeled as finite state machines (fsm). the transition relation of the fsm is unrolled step by step and a property is verified at the current depth. the depth k is incremented until either the property is violated for the given depth, or a user-defined bound for the depth is reached. a sat formula for the bmc problem can be written as: ϕ = i0∧t0,1∧...∧tk−1,k∧¬pk, where i0 is the initial state of the system, ti,i+1 is the transition relation for step i and pk is the property at step k. note that ϕ is true iff the property is violated. in case of a violated property the model of ϕ represents a full trace of assignments to the primary inputs of the transition relation (i.e. a counterexample) of the current unrolling depth. this trace can be used for diagnosis or abstraction refinements. in order to improve the diagnosis routines 11 table 1: results for hwmcc benchmarks qbf lifting family inst. inputs time x time x loss beemi* 14 / 0 489.71 0.60 17.50 4.01 17.50 0.00 beemsch* 16 / 0 320.38 1.03 13 0.68 12 0.31 bj* 12 / 1 16.27 0.07 14.36 0.02 14.36 0.00 brpp* 5 / 0 177.40 287.46 58.40 0.14 46.20 20.76 counter* 2 / 0 82.00 0.01 21.00 0.02 20.50 2.38 dme* 20 / 0 455.35 6.95 301.20 0.37 262.45 12.12 ken* 2 / 0 268.68 3.48 161.10 0.19 141.48 7.25 pci* 5 / 0 477.25 91.64 282.50 0.29 282.50 0.00 srg* 3 / 0 81.00 0.29 25.67 0.02 11.33 52.12 texas* 9 / 1 117.63 6.29 102.88 0.49 101.63 0.80 vis* 6 / 2 78.00 49.52 45.00 0.18 44.00 2.30 total 94 / 4 288.32 25.74 102.88 0.91 92.87 5.98 the number of primary inputs, which are needed to justify the violation of the property, can be delimited. note that the test pattern relaxation problem as described in §4.1.5 can be seen as a special case of the minimal counterexample problem. instead of asking whether a property is violated, we ask whether a property (detection of a fault) holds minimizing the number of specified inputs (test cube). using qbf with soft variables consider a bmc problem ϕ as stated above with a counterexample at depth k. we denote x = x1,...,xn as the variables representing all inputs of the transition relations and y = y1,...,ym all other variables in ϕ. in order to minimize the number of specified inputs (or maximize the unknown inputs), we state the following qbf with soft variables instance: ψ( æ {2,3}x1,..., æ {2,3}xn) =∃∅∀∅∃y.ϕ, i. e. a qbf containing only existentially quantified variables y on level 3 and the soft variables x. if we define the score function σ such that the universally quantified position gets a larger score than the existential position, the result of ω(ψ) returns the maximum number of inputs which can be excluded from the counterexample such the property is still unsatisfied. hence, we obtain a counterexample with a minimal number of specified inputs. case study we considered 94 unsatisfiable bmc benchmarks from 11 classes of the hardware model checking competitions (2010, 2011 and 2012). we selected the bounded model checker cip [klsb11] which is able to extract counterexamples from buggy benchmark designs. for some groups with smaller number of inputs we computed the minimal counterexamples for these benchmarks, and compared them with the results obtained by applying a lifting algorithm. the results are given in table 1. in the first three columns the family name, the number of overall / non-solved qbf instances within a timeout of 30 cpu minutes, and the average number of inputs of the original counterexample are given. in order to compare results, the following columns contains only results for the instances where the qbf approach was able to provide a solution. the following two columns show the average run time in seconds and the average number of inputs we can exclude from the counterexample using qbf with soft variables. the next two columns show the same for the lifting approach, and the last column indicates the average quality loss of the lifting approach. on average the loss of accuracy with lifting is about 6% compared to the exact qbf with soft variables. however, for some benchmarks the loss is over 70% (instance brpptimeonenegnv). the run times for these smaller examples are very reasonable with just 4 non-solved benchmarks, but our approach still has scaling issues, especially if the number of lines to maximize is large. 12 4.2 further applications for the task of finding optimal dependency schemes [sam08] one can use the optimization problem for qbf with soft variables. therefore, we declare a single existential variable of the original problem as soft variable allowing to be quantified on all existential prefix position. in the score function we prefer the position with the least dependencies on universally quantified variables as possible. another application area where qbf with soft variables may be a useful mechanism is planning and decision making, which are common problems evolving from the game theory domain. in a multi-agent environment, where more than one player is present, such problems ask to determine the best action. hence, the goal is to find the action model with the highest score. in [ywj07] a weighted maxsat solver is used to determine these models. but this approach is limited if we consider uncertainness of other players’ action, the environment or possibly unknown actions performed earlier. using maxqbf one’s own action score could be maximized with accuratly modeled behaviour of the enviroment. moreover, by using qbf with soft variables it can be determined whether the order of the actions can be altered or even if an action can be left out in order to decrease the overall costs. a related problem are two-players games [amn05], which can be naturally formulated with qbf logic by giving the existential quantifier (resp. the universal quantifier) the role of the system player (resp. the environment player). as in the planning problem one could try to make own moves independent from the opponent ones using qbf with soft variables for the existential variables. this would lead to more generalized winning strategies. this problem is related to the uniform counterexamples (cf. §4.1.2) and can be tackled in a similar manner. 5 conclusions we presented first results on the novel concept of soft variables for quantified boolean formulae. the related optimization problem allows to optimize the prefix according to a user-given preference. furthermore, we introduced a maxqbf solver and a sound and complete algorithm to solve qbf with soft variables using maxqbf. recent improvements in classical algorithms for sat and qbf lead to new research interests in answering beyond yes/no questions. such optimization problems using quantified formulas are often hard to encode due to the static prefix or rather predefined dependencies of the variables. the concept of soft variables overcomes this issues and opens a wide field of such applications requiring an accurate model. we demonstrated the applicability of our formalism by introducing several applications in the area of formal verification, debugging, testing and artificial intelligence. however, also qbf is limited if the abstracted part modeled by universally quantified variables either show sequential behavior or there are multiple black box parts with overlapping cones of the black box inputs and outputs. in these cases qbf (hence also qbf with soft variables) is not accurate anymore [grs+13]. to overcome the latter issue one can define explicit dependencies of the variables rather than defining a linear prefix. this extension is known as dependency qbf (dqbf) using so-called henkin quantifiers, where variables are quantified with a explicitly given variable set of dependencies [hen61]. the definition of a dqbf with soft variables is straightforward: instead of possible prefix positions a soft variable is allowed to be quantified with different dependency sets4. research interest starts on focusing dqbf algorithms and applications [grs+13], but the scalability of these algorithms is still not reasonable for tackling even more complex optimization problems (deciding pure dqbf is already nexptime-complete [pra01]). therefore we do not consider soft variables for dqbf in this paper, but it may become relevant if appropriate algorithms for solving dqbf are present. as future work we want to investigate the new application areas covered by our soft variable 4 actually, the prefix of a qbf is just a convenient notation for a linear dependency relation between the variables. 13 mechanism as well as dedicated solving mechanisms beyond the techniques used for maxsat/qbfbased algorithms to increase the scalability. [amn05] r. alur, p. madhusudan, w. nam. symbolic computational techniques for solving games. sttt 7(2):118–128, 2005. [bcc+03] a. biere, a. cimatti, e. m. clarke, o. strichman, y. zhu. bounded model checking. advances in computers 58:117–148, 2003. [belm12] b. becker, r. ehlers, m. lewis, p. marin. allqbf solving by computational learning. in atva. lncs 7561, pp. 370–384. springer, 2012. [bhmw09] a. biere, m. heule, h. van maaren, t. walsh (eds.). handbook of satisfiability. frontiers in artificial intelligence and applications 185. ios press, 2009. [blv08] m. benedetti, a. lallouet, j. vautard. quantified constraint optimization. in principles and practice of constraint programming. pp. 463–477. 2008. [cfls93] a. condon, j. feigenbaum, c. lund, p. shor. probabilistically checkable debate systems and approximation algorithms for pspace-hard functions. in proceedings of the 25th annual acm symposium on theory of computing. pp. 305–314. 1993. [cp04] h. chen, m. pál. optimization, games, and quantified constraint satisfaction. in mathematical foundations of computer science 2004. pp. 239–250. springer, 2004. [eb05] n. eén, a. biere. effective preprocessing in sat through variable and clause elimination. in sat. 2005. [gnt07] e. giunchiglia, m. narizzano, a. tacchella. quantifier structure in search-based procedures for qbfs. ieee trans. on cad of integrated circuits and systems 26(3):497– 507, 2007. [grs+13] k. gitina, s. reimer, m. sauer, r. wimmer, c. scholl, b. becker. equivalence checking of partial designs using dependency quantified boolean formulae. in proc. of the 31st ieee int’l conf. on computer design. pp. 396–403. 2013. [hb07] m. herbstritt, b. becker. on combining 01x-logic and qbf. in eurocast. lecture notes in computer science 4739, pp. 531–538. springer, 2007. [hen61] l. henkin. some remarks on infinitely long formulas. in infinitistic methods: proceedings of the 1959 symposium on foundations of mathematics. pp. 167–183. pergamon press, sept. 1961. [ijm13] a. ignatiev, m. janota, j. marques-silva. quantified maximum satisfiability. in sat. pp. 250–266. springer, 2013. [jbm+00] a. jain, v. boppana, r. mukherjee, j. jain, m. fujita, m. s. hsiao. testing, verification, and diagnosis in the presence of unknowns. in vlsi test symp. pp. 263–269. 2000. [jg03] n. k. jha, s. k. gupta. testing of digital systems. cambridge u. press, 2003. [klsb11] s. kupferschmid, m. lewis, t. schubert, b. becker. incremental preprocessing methods for use in bmc. formal methods in system design, pp. 1–20, 2011. 14 [mmb12] p. marin, c. miller, b. becker. incremental qbf preprocessing for partial design verification (poster presentation). in sat. lncs 7317. springer, 2012. [mmlb12] p. marin, c. miller, m. lewis, b. becker. verification of partial designs using incremental qbf solving. in date. pp. 623–628. 2012. [nsb07] t. nopper, c. scholl, b. becker. computation of minimal counterexamples by using black box techniques and symbolic methods. in iccad. pp. 273–280. 2007. [pr00] i. pomeranz, s. m. reddy. on synchronizable circuits and their synchronizing sequences. ieee trans. on cad of integrated circuits and systems 19(9):1086–1092, 2000. [pra01] g. peterson, j. reif, s. azhar. lower bounds for multiplayer non-cooperative games of incomplete information. computers & mathematics with applications 41(7–8):957– 992, 2001. [rpsb12] s. reimer, f. pigorsch, c. scholl, b. becker. enhanced integration of qbf solving techniques. in mbmv. pp. 133–143. 2012. [rs04] k. ravi, f. somenzi. minimal assignments for bounded model checking. in tacas. lecture notes in computer science 2988, pp. 31–45. springer, 2004. [rssb14] s. reimer, m. sauer, t. schubert, b. becker. using maxbmc for pareto-optimal circuit initialization. in date. 2014. [sam08] m. samer. variable dependencies of quantified csps. in logic for programming, artificial intelligence, and reasoning. pp. 512–527. 2008. [sb01] c. scholl, b. becker. checking equivalence for partial implementations. in design automation conference, 2001. proceedings. pp. 238 – 243. 2001. [sin05] c. sinz. towards an optimal cnf encoding of boolean cardinality constraints. in principles and practice of constraint programming-cp 2005. pp. 827–831. springer, 2005. [sm73] l. j. stockmeyer, a. r. meyer. word problems requiring exponential time (preliminary report). in proceedings of the fifth annual acm symposium on theory of computing. stoc ’73, pp. 1–9. acm, new york, ny, usa, 1973. [srp+13] m. sauer, s. reimer, i. polian, t. schubert, b. becker. provably optimal test cube generation using quantified boolean formula solving. in asp-dac. pp. 533–539. ieee, 2013. [tse68] g. tseitin. on the complexity of derivation in propositional calculus. studies in constructive mathematics and mathematical logic, 1968. [ywj07] q. yang, k. wu, y. jiang. learning action models from plan examples using weighted max-sat. artif. intell. 171(2-3):107–143, 2007. [zsm03] h. zhang, h. shen, f. manya. exact algorithms for max-sat. electronic notes in theoretical computer science 86(1):190–203, 2003. 15 introduction preliminaries qbf maxqbf qbf with soft variables soft variables algorithm solving qbf with soft variables solving maxqbf implementation details applications maximizing unknowns in a circuit comparison to previous work uniform counterexamples diagnosis circuit initialization test pattern relaxation minimal counterexamples further applications conclusions automated theorem proving for the systematic analysis of an infusion pump electronic communications of the easst volume 69 (2013) proceedings of the 5th international workshop on formal methods for interactive systems (fmis 2013) automated theorem proving for the systematic analysis of an infusion pump m.d. harrison,, p. masci, j. c. campos, p. curzon 12 pages guest editors: judy bowen, steve reeves managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst automated theorem proving for the systematic analysis of an infusion pump m.d. harrison1,2, p. masci2, j. c. campos3, p. curzon2 1 school of computing science, newcastle university, newcastle-upon-tyne, uk michael.harrison@ncl.ac.uk 2 queen mary university of london, school of electronic engineering & computer science, mile end, london e1 4ns, uk paolo.masci@eecs.qmul.ac.uk paul.curzon@eecs.qmul.ac.uk 3 dep. informática / universidade do minho braga and haslab / inesc tec braga, portugal jose.campos@di.uminho.pt abstract: this paper describes the use of an automated theorem prover to analyse properties of interactive behaviour. it offers an alternative to model checking for the analysis of interactive systems. there are situations, for example when demonstrating safety, in which alternative complementary analyses provide assurance to the regulator. the rigour and detail offered by theorem proving makes it possible to explore features of the design of the interactive system, as modelled, beyond those that would be revealed using model checking. theorem proving can also speed up proof in some circumstances. the paper illustrates how a theory generated as a basis for theorem proving (using pvs) was developed systematically from a mal model used to model check the same properties. it also shows how the ctl properties used to check the original model can be translated into theorems. keywords: interactive systems, formal verification, medical devices, model checking, mal, pvs 1 introduction the scaleable analysis of interactive devices using model checking techniques is now feasible [ch09, hcm13] and potentially fruitful. formal methods have the capability to demonstrate that safety requirements, as prescribed by regulators, are true of a candidate design. however a number of barriers prevent formal methods from being the technology of choice during the development and certification of interactive systems. these barriers include difficulty of use of the techniques and the time taken to prove properties of realistic models. work previously presented [hcm13] has demonstrated the use of the ivy tool to analyse a set of properties of interactive systems. the tool supports a relatively intuitive notation for specification and also supports template properties that can be easily instantiated to the specified model. there are limitations to the use of model checking however. one is performance. the state space generated 1 / 12 volume 69 (2013) mailto:michael.harrison@ncl.ac.uk mailto:paolo.masci@eecs.qmul.ac.uk mailto:paul.curzon@eecs.qmul.ac.uk mailto:jose.campos@di.uminho.pt automated theorem proving for the systematic analysis of an infusion pump while model checking can become extremely large and therefore properties can take so long to check that an iterative approach to analysis becomes impossible. harrison and others [hcm13] describe how model checking can be used to reveal inconsistencies in the interactive behaviour of two infusion pump designs. the focus of that analysis was a systematic consideration of information that was displayed in response to action and how the mode structures of the two interfaces affect their use. the two analysed designs were medical infusion pumps commonly used in hospitals. the results provide support for human factors specialists by raising potential design issues that result from exhaustive analysis. they provide evidence that the design satisfies requirements that, if true, would mitigate interaction failures. the ivy tool uses modal action logic (mal) to specify the effect of actions on state attributes, given preconditions. the mal is translated into smv to be analysed using nusmv [ccg+02]. the models were checked against a set of property patterns. these patterns use templates that concern: the consistency of actions, the visibility of feedback, the effect of modes, and the existence of actions that enable reversal of the effect of previous actions. the templates are instantiated to the state and actions of a particular model. if a property fails to be true of the model then the checker generates a trace that indicates a sequence of actions where (according to the model) the device fails to be consistent. the trace can then be analysed from a human factors and domain perspective. while this approach is valuable, in order to make model checking tractable for systems of this size it is necessary to make radical state abstractions. in the case of [hcm13] the domains used in number entry were abstracted for the two medical infusion pumps so that it was possible to focus on interface mode structures. this paper explores the complementary role that interactive theorem proving can play. in some cases it can improve performance. it can also identify features in the model or in the design that would not have been noticed through a model checking approach. it provides a second approach to analysis that can be used to assure of the safety of a proposed design. analysis can be used as part of an argument that risks are as low as reasonably practicable. since there are no theorem provers for mal or for smv, the models were translated into pvs. this paper takes the mal model of a version of the alaris infusion pump that was presented in [hcm13] and demonstrates that theorem proving based on pvs can be used to complement the analysis. the paper indicates how mal models can be translated into pvs, and ctl properties can be translated into pvs theorems. it is not the purpose of this paper to generate a formal mapping and to prove the equivalence. for this reason it should be seen as an initial exploration. the paper is structured as follows. in section 2 research on complementary approaches is briefly discussed. in section 3 the translation from mal to pvs is described. in section 4 the ctl properties are translated into theorems over the pvs models. 2 background motivation for this analysis has been a concern with the safety, particularly in relation to user interaction failure. the u.s. food and drug administration (fda) [us 10] is now encouraging the use of safety arguments based on formal justifications to provide evidence of the safety of medical devices. they have launched the generic infusion pump project to investigate solutions to safety problems in infusion pump software. their aim is to develop a set of safety reference proc. fmis 2013 2 / 12 eceasst models that can be used to assess safety of infusion pump software. an important element in safety arguments is to provide alternative arguments that a system is acceptably safe. multiple arguments increase confidence. in addition the need to abstract aspects of the model to assist tractability means that some feature of the design, for example the number entry, cannot be explored. recent developments in model checking have made the technique easier to use relative to other formal approaches as briefly discussed in the introduction. a range of property templates (see, for example, [dac99]) have been developed, empirically based on typical practice, that can be instantiated to the particular requirements of a device model. recent formal modelling work, relevant to medical devices, has focused on a number of aspects of their programming. for example, bolton and bass [bb10] use sal to analyse a model of the baxter ipump which takes into account user goals, tasks and aspects of the environment. they explore the packaging of an automated reasoning tool so that human factors engineering practitioners can specify a realistic interactive system and verify a variety of tasks. they performed the verification on a simplified model of the pump, as the state space of the full model exceeded the capabilities of the model checker. 2.1 complementary analysis approaches the integration of model checking with automated theorem proving has been a topic of research for many years. rajan and others [rss95], for example, discussed how useful logic fragments can be proved using decision procedures and graf and saidi [gs97] discussed how pvs could be used to construct abstract graphs. the focus of their work was to simplify proof by model checking parts of it, or using counter-examples, generated by the failure to check properties, to change the assumptions in the theorem that is being attempted (see kong and others [kosf05] and the automated verification approaches based on counterexample-guided refinement of abstractions [cgj+00], for example). our approach takes a different view. although the proofs are structurally complex, they can be proved with a fairly simple proof strategy based on case exploration and expansion of definitions for many cases. because of this, checking a proof by theorem proving can be much quicker (given relevant skills to control “case explosion”) than would be possible with a model checker. 2.2 the pvs language the automated theorem prover used in this paper is prototype verification system (pvs) [sors99]. it combines an expressive specification language based on higher-order logic with an interactive prover. pvs has been used extensively in several application domains. it is based on higher-order logic with the usual basic types such as boolean, integer and real. new types can be introduced either in a declarative form (these types are called uninterpreted), or through type constructors. examples of type constructors that will be used in the paper are function and record types. function types are denoted [d -> r], where d is the domain type and r is the range type. predicates are boolean-valued functions. record types are defined by listing the field names and their types between square brackets and hash symbols. predicate subtyping is a language mechanism used for restricting the domain of a type by 3 / 12 volume 69 (2013) automated theorem proving for the systematic analysis of an infusion pump using a predicate. an example of a subtype is {x:a | p(x)}, which introduces a new type as the subset of those elements of type a that satisfy the predicate p. the notation (p) is an abbreviation of the subtype expression above. predicate subtyping is useful for specifying partial functions. dependent subtypes can be defined, e.g., the range of a function or the type of a field in a record may depend on the value of a function argument or the value of another field in the record, respectively. specifications in pvs are expressed as a collection of theories, which consist of declarations of names for types and constants, and expressions associated with those names. theories can be parametrised with types and constants, and can use declarations of other theories by importing them. the prelude is a standard library automatically imported by pvs. it contains a large number of useful definitions and proved facts for types, including among others common base types such as booleans (bool) and numbers (e.g., nat, integer and real), functions, sets, and lists. 3 the pvs model of the infusion pump the mal models of the infusion pumps, referred to as a and b, in [hcm13] have been translated into pvs. the focus here is not rigorous translation, rather it is concerned with an intuitive description of how the approach works. for brevity this paper focuses on infusion pump a. 3.1 overview of the infusion pump most infusion pumps have three basic states: infusing, holding and off. in the infusing state the volume to be infused (vtbi) is pumped into the patient intravenously at a pre-determined infusion rate. while in the infusing state the vtbi can be exhausted, in which case the pump continues in kvo (keep vein open) mode and sets off an alarm. when the pump is in holding state, values and settings can be changed using a combination of function keys and chevron buttons (for the device layout, see figure 1). a subset of the features can also be changed when infusing. number entry is achieved by means of chevron buttons. these buttons are used to increase or decrease entered numbers incrementally. depending on current mode the chevron buttons can be used to change infusion rate, volume to be infused and time, or alternatively allow the user to move between options in a menu, for example in bag mode and in query mode. bag mode allows the user to select from a set of infusion bag options, thereby setting vtbi to a predetermined value. query mode, which is invoked by pressing the query button, generates a menu of set-up options. these options depend on how the device is configured by the manufacturer, and include the means of locking the infusion rate, or disabling the locking of it, or setting vtbi and time rather than vtbi and infusion rate. there is also the possibility of changing the units of volume and infusion rate. the device allows movement between display modes via three function keys (key1, key2 and key3). each function key has a display associated with it, indicating its present function. the infusion process can be captured in mal using an invariant over the state transition process. infusionrate > 0 → infusionrateaux = infusionrate (1) proc. fmis 2013 4 / 12 eceasst figure 1: the pump user interface and actions infusionrate > 0 → time = (vtbi/infusionrateaux) infusionrate = 0 → time = 0 this invariant asserts a relationship between vtbi, infusion rate and time to completion of the process. infusionrateaux, which takes values in the range 1..maxrate, is introduced to ensure division by zero cannot happen. to indicate the level of detail provided by the mal model a couple of sample axioms are included and translated into pvs. the tick action describes the steps in the process, and the alarms that occur when the volume to be infused is exhausted, or when the device has been left in a hold state for too long. as illustration the normal conditions for tick are described. (infusionstatus = infuse) & (infusionrate < vtbi)→ [tick] vtbi′ = vtbi−infusionrate & (2) elapsedtime′ = elapsedtime + 1 & volumeinfused′ = volumeinfused + infusionrate & keep(kvorate,kvoflag,infusionrate,infusionstatus) this axiom specifies what happens when the pump is infusing (that is infusionstatus = infuse) and when vtbi exceeds the rate, that is it will not be exhausted in this step. the axiom describes the action (in square brackets); the conditions that must be satisfied for the action to have the stated effect (left side of the implication) and the result of the action under these conditions. the priming of attributes indicates the value that will be determined in the next state. keep specifies those attributes that keep their values in the next state, otherwise the value is randomly determined. the pvs function tick, which is the translation of this action under the specified conditions, has domain that is a sub-type of the pump state that satisfies the same conditions. the range of the function is the set of all states. the attributes vtbi, time and volumeinfused are updated in a way that is analogous to axiom 2. the following describes that part of the tick function that is analogous to axiom 2. tick_case_infuse_and_infusionratelvtbi (st: {st: pump | infusing?(st) & vtbi(st) infusionrate(st) > 0}): pump = st with [ vtbi := vtbi(st) infusionrate(st), 5 / 12 volume 69 (2013) automated theorem proving for the systematic analysis of an infusion pump time := cond infusionrate(st) = 0 -> 0 else -> floor((vtbi(st) infusionrate(st))/infusionrate(st)) endcond, volumeinfused := cond volumeinfused(st) + infusionrate(st) <= maxinfuse -> volumeinfused(st) + infusionrate(st), else -> volumeinfused(st) endcond, elapsedtime := cond elapsedtime(st) < maxtime -> elapsedtime(st) + 1, else -> elapsedtime(st) endcond ] the invariant axiom 1 is replaced by an explicit specification: floor((vtbi(st) infusionrate(st)) / infusionrate(st)). the floor function ensures that the result is the truncated integer value associated with the quotient. the tick function in pvs describes the behaviour that is captured by a number of mal axioms defining [tick], given a variety of pre-conditions, including tick case infuse and infusionratelvtbi defined above. tick(st: {st: pump | per_tick(st)}): pump = cond infusing?(st) & infusionrate(st) < vtbi(st) -> tick_case_infuse_and_infusionratelvtbi(st), infusing?(st) & infusionrate(st) >= vtbi(st) & not kvoflag(st) -> tick_case_infuse_and_infusionrategevtbi_notkvoflag(st), infusing?(st) & infusionrate(st) >= vtbi(st) & kvoflag(st) -> tick_case_infuse_and_infusionrategevtbi_kvoflag(st), not infusing?(st) & elapse(st) >= timeout -> st with [ elapse := 0 ], not infusing?(st) & elapse(st) < timeout -> st with [ elapse := elapse(st) + 1 ] endcond 3.2 specifying the interface as discussed in [hcm13], the display is specified in the model as having three parts as shown in figure 1. topline describes the contents of the top line. this is represented in mal by a type that describes an enumeration of possible top line displays. iline = {holding,infusing,volume,dispvtbi,attention,vtbidone,dispkvo, setvtbi,locked,options,dispinfo,vtbitime,dispblank} middisp is a boolean array indicating which pump or other state attributes are visible (for example it indicates whether a menu is visible). fndisp1, fndisp2 and fndisp3 are state attributes that describe what is indicated by the three soft keys. further fragments of the original specification are now described to indicate the complexity of the model. the mal specification of the soft key 2, when the top line of the device shows “holding” (see figure 1), has two components. the first is a permission that describes when action key2 is permitted. if the condition is not true then the action cannot be invoked. the modal axiom describes what happens when key2 is invoked and topline indicates either holding or infusing. per(key2)→ (fndisp2 ! = fnull)& (3) topline in {holding,infusing,volume,dispvtbi} & device.poweredon this permission asserts that key2 can be invoked when the soft key has a value other than null, and the top line is one of holding, infusing, volume, dispvtbi, and the device is powered on. the effect of key2, when top line shows holding or infusing and vtbi has not been exhausted (as indicated by the fact that kvoflag is false), is as follows: proc. fmis 2013 6 / 12 eceasst (topline in {holding,infusing}) & !kvoflag → [key2] (4) topline′ = dispvtbi & oldvtbi′ = vtbi & middisp[dvtbi]′ & !middisp[dvol]′ & !middisp[dtime]′ & !middisp[dbags]′ & !middisp[dkvorate]′ & !middisp[dquery]′ & fndisp1′ = fok & fndisp2′ = fbags & fndisp3′ = fquit & entrymode′ = vtmode & effect(device.resetelapsed) & keep(onlight,runlight,pauselight,rdisabled,rlock) the translated pvs description includes the type definition for iline, the definition of the permission per key2, and the description of the effect in the particular situation described in the mal axiom. finally, to indicate the context of this particular condition, the top level cases, including the one that has been specified, are described in the function key2. the translations of the axioms for key2 from mal into pvs can be achieved systematically. iline: type = { holding, infusing, volume, dispvtbi, attention, vtbidone, dispkvo, setvtbi, locked, options, dispinfo, vtbitime, dispblank, clearsetup } per_key2(st: alaris): bool = not(fndisp2(st) = fnull) & (topline(st) = holding or topline(st) = infusing or topline(st) = volume or topline(st) = dispvtbi) & (device(st)‘powered_on?) key2_case_holding_infusing(st: (per_key2)): alaris = st with [ topline := dispvtbi, oldvtbi := device(st)‘vtbi, middisp := lambda(x: imid_type) cond x = dvtbi -> true, x = dvol -> false, x = dtime -> false, x = dbags -> false, x = dkvorate -> false, x = dquery -> false, x = drate -> false endcond, fndisp1 := fok, fndisp2 := fbags, fndisp3 := fquit, entrymode := vtmode, device := resetelapsed(device(st)) ] the key2 function combines all the individual mal axioms.the domain of this function is that set of states that are permitted by per key2. key2(st: (per_key2)): alaris = cond (topline(st) = holding or topline(st) = infusing) -> key2_case_holding_infusing(st), (topline(st) = volume) -> key2_case_volume(st), (topline(st) = dispvtbi or topline(st) = vtbitime) -> key2_case_dispvtbiorvtbitime(st), (topline(st) = setvtbi) -> key2_case_setvtbi(st) endcond 4 proving the property templates as theorems the model checking analysis was performed using an intel core rated at 3.2 ghz per processor with 24gb of ram. the pvs analysis used an intel core i5 rated at 2.4 ghz with 8 gb of ram. given the pvs version of the interactive device, sketched in the previous section, it is possible to prove the same properties that have been proved already using the ivy tool. these were described as being concerned with a number of characteristics of the device: • checking that the process represented in the innermost pump layer is visible through the device interface (mirroring the process in the interface). 7 / 12 volume 69 (2013) automated theorem proving for the systematic analysis of an infusion pump • checking that modes can be determined unambiguously from the interface (mode clarity). • checking that actions provide appropriate feedback, for example when they change mode or change the values of pump attributes. • ensuring consistency of use of the display, or of action (consistency of the interface). • checking ease of recovery from an action. • ensuring that activities described in the outer layer are supported (supporting activities). these properties have all been translated into pvs and proved of the translated specification using structural induction. proving that a property is true for all reachable states ag p is achieved by: showing first that it is true of the initial state of the device; and second that if the property is true of a state then it is true of any state that can be reached from that state by a single action. for space reasons only a sample of these ctl properties are considered to illustrate the approach. all the properties shown in [hcm13] have been proved, although in some cases it has involved a tightening of the mal model (which reflected a weakness of the mal model rather than a lack of tractability of the pvs approach). 4.1 mirroring the process in the interface the first set of properties to be considered determine how the underlying modes and variables of the pump process are reflected in the interface. for example, a question considered was whether the top line of the display adequately determined whether the mode of the device was infusing or holding. two properties were used to explore this. ag(device.poweredon & (5) (topline in {infusing,dispkvo,vtbidone} → device.infusingstate)) this proof generated a system diameter of 53. it reached 239.4686 states out of 292.1771. verification was completed in 1 hour 52 minutes. the costs of proof using model checking for the other properties are similar to this example. the run time associated with theorem proving will be indicated with each theorem. it must be emphasised that in some cases the real time, including human time, associated with theorem proving involved guiding the proof strategy and making sense of the cases where a proof failed. dealing with counter-examples when model checking is a much simpler task than the comparable activity when theorem proving. it has not been possible in this case to quantify the time involved, including the learning curve involved, in a first serious use of pvs by the first author. property 5 shows that when the top line displays “infusing”, “vtbi done” or “kvo” the pump is infusing. other top lines can appear in both infusing and holding states. for this reason property 6 that is concerned with hold excludes top lines of locked, volume, options, dispinfo and dispvtbi. ag(device.poweredon & (6) proc. fmis 2013 8 / 12 eceasst !(topline in {locked,volume,options,dispinfo,dispvtbi}) → (topline in {holding,setvtbi,attention,vtbitime,clearsetup} ↔ device.infusionstatus = hold)) the structural induction is achieved using alaris transitions, a function that relates pre: alaris to all states that can be reached through an action. alaris_transitions(pre, post: alaris): boolean = (per_sup(pre) & post = sup(pre)) or (per_fup(pre) & post = fup(pre)) or (per_sdown(pre) & post = sdown(pre)) or (per_fdown(pre) & post = fdown(pre)) or (per_tick(pre) & post = tick(pre)) or (per_key1(pre) & post = key1(pre)) or (per_key2(pre) & post = key2(pre)) or (per_key3(pre) & post = key3(pre)) or (per_query(pre) & post = query(pre)) or post = on(pre) or (per_run(pre) & post = run(pre)) or (per_pause(pre) & post = pause(pre)) note that the conjunction per action(pre) & post = action(pre) is required because the actions are defined in pvs with a domain that is a subtype of the alaris state. therefore any pre: alaris that is not in the subtype that is the domain of action produces an undefined value. properties 5 and 6 can be proved using the following predicates that transform the ctl properties. tlinfusionstatusinfuse(st: alaris): bool = (device(st)‘powered_on? and topline(st) = infusing and topline(st)=dispkvo and topline(st) = vtbidone) => device(st)‘infusing? tlinfusionstatushold(st: alaris): bool = (device(st)‘powered_on? and not(topline(st) = locked or topline(st) = volume or topline(st) = options or topline(st) = dispinfo or topline(st) = dispvtbi)) => ((topline(st) = holding or topline(st) = setvtbi or topline(st) = attention or topline(st) = vtbitime or topline(st) = clearsetup) <=> not device(st)‘infusing?) the theorem combines the two properties. the pvs proof is much quicker than the equivalent property checked using model checking. the standard tactic is to skolemise the property, split it so that the initial condition can be proved separately, expand alaris transitions and then split this into a case for each possible transition. these cases can then be proved relatively simply, or if they fail, the particular decomposition makes diagnosis of the problem relatively straightforward. % qed run time = 44.38 secs. 12/3/2013 tlinfusionstatus: theorem forall (pre, post: alaris): ((init?(pre) => tlinfusionstatusinfuse(pre) and tlinfusionstatushold(pre)) and ((alaris_transitions(pre, post) and tlinfusionstatusinfuse(pre) and tlinfusionstatushold(pre)) => tlinfusionstatusinfuse(post) and tlinfusionstatushold(post))) in proofs of this kind it was occasionally necessary to add a number of details to the theory. these were mainly in the form of additional permissions on actions to limit the states that could be in the domain of the action. this could be achieved while continuing to capture the properties of the device. there is not sufficient space in this preliminary paper to discuss the details of these additions. 9 / 12 volume 69 (2013) automated theorem proving for the systematic analysis of an infusion pump 4.2 checking consistency of action the second illustration is concerned with consistency in the use of the soft function keys. the ivy analysis explores two types of consistency: whether the same key is always associated with the same function and whether a particular soft display only appears associated with the same key. the first property is only true in some circumstances as can be specified by the ctl property. ag((((topline = dispvtbi)&(entrymode = vtmode)) | (7) ((topline = vtbitime)&(entrymode = vttmode)) | topline in {options,volume,dispinfo})↔ fndisp3 = fquit) property 7 can also be translated into a property in pvs and proved using structural induction. conditions_for_quitequiv(st:alaris) : bool = ((((topline(st) = dispvtbi) and (entrymode(st) = vtmode)) or ((topline(st) = vtbitime) and (entrymode(st) = vttmode)) or (topline(st) = options) or (topline(st) = dispinfo) or (topline(st) = volume)) <=> (fndisp3(st) = fquit)) with corresponding theorem: %qed run time = 77.97 secs. 15/5/2013 alwaysquitequiv: theorem forall (pre, post: alaris): (init?(pre) => conditions_for_quitequiv(pre)) and (alaris_transitions(pre, post) and conditions_for_quitequiv(pre) => conditions_for_quitequiv(post)) the second type, illustrated by property 8, ensures that quit can only appear when it is a soft key for key3: ag(fndisp1! = fquit & fndisp2! = fquit) (8) the translation of this property is: never_key1_key2_quit?(st:alaris): bool = fndisp1(st) /= fquit and fndisp2(st) /= fquit %qed 18.85 secs 27/2/13 onlykey3quit1x: theorem forall (pre, post: alaris): (init?(pre) => never_key1_key2_quit?(pre)) and (alaris_transitions(pre, post) and never_key1_key2_quit?(pre) => never_key1_key2_quit?(post)) the final consistency illustration, property 9, requires that if the top line is volume then the same soft function keys always appear. ag(topline = volume ↔ (fndisp1 = fnull & fndisp2 = fclear& fndisp3 = fquit)) (9) this is translated into: topline_volume_fndisp?(st:alaris): bool = topline(st)=volume <=> (fndisp1(st)=fnull and fndisp2(st)=fclear and fndisp3(st)=fquit) % q.e.d. run time = 70.79 secs. 12/3/13 toplinevolumedisplaysx: theorem forall (pre, post: alaris): (init?(pre) => topline_volume_fndisp?(pre)) and (alaris_transitions(pre, post) and topline_volume_fndisp?(pre) => topline_volume_fndisp?(post)) proc. fmis 2013 10 / 12 eceasst 4.3 checking ease of recovery the last illustrated property is concerned with ease of recovery. the mal model uses a much simplified domain of numbers (0...7) to make analysis tractable. in the case of the pvs model, the actual number space of the infusion device is modelled and the chevron keys have behaviour as implemented in the device. the standard form of the property is illustrated in ctl as property 10. ag(attribute = value → ax(action1 → ex(action2) & (10) ax(action2 → (attribute = value))))) two theorems illustrate instantiations of the general form. it was possible to prove the properties over all states. two illustrations are translated into pvs as follows: % q.e.d. run time = 5.91 secs. 27/2/13 undoinfusionratesupsdown: theorem (not rlock(st) and entrymode(st) = rmode and (topline(st) = holding or topline(st) = infusing) and (device(st)‘infusionrate > 0) and (per_sdown(st) and per_sup(sdown(st)))) => device(sup(sdown(st)))‘infusionrate = device(st)‘infusionrate % q.e.d. run time = 7.03 secs. 27/2/13 undoinfusionratesdownsup: theorem (not rlock(st) and entrymode(st) = rmode and (topline(st) = holding or topline(st) = infusing) and (device(st)‘infusionrate < maxrate) and (per_sup(st) and per_sdown(sup(st)))) => device(sdown(sup(st)))‘infusionrate = device(st)‘infusionrate 5 conclusion this paper has illustrated exploration of a currently informal process, transforming mal models into pvs [hcm13]. proof using interactive theorem proving for models of this kind is straightforward. however, when a proof fails, diagnosis requires expertise. the advantage of model checking is that properties can be explored by considering an ideal property and then restricting it by exploring a counter-example as discussed in [kosf05]. another mode in which the model checker can be used, that is difficult to achieve using the theorem prover, is to explore paths that achieve specific goals, considering counter-examples of properties such as ag(device.volumeinfused ! = n). future work will be particularly concerned with demonstrating how models satisfy regulatory requirements, demonstrating how an approach that combines mal with pvs can be used to prove systematically that these requirements can be proved. it is also concerned with adding tools to the ivy toolkit to enable the automatic development of pvs specifications based on mal models and assistance with the proofs of these properties. acknowledgements. chi+med, epsrc research grant ep/g059063/1 bibliography [bb10] m. l. bolton, e. j. bass. formally verifying human-automation interaction as part of a system model: limitations and tradeoffs. innovations in system and software engineering 6(3):219–231, 2010. 11 / 12 volume 69 (2013) automated theorem proving for the systematic analysis of an infusion pump [ccg+02] a. cimatti, e. clarke, e. giunchiglia, f. giunchiglia, m. pistore, m. roveri, r. sebastiani, a. tacchella. nusmv 2: an open source tool for symbolic model checking. in larsen and brinksma (eds.), computer-aided verification (cav ’02). lecture notes in computer science 2404. springer-verlag, 2002. [cgj+00] e. clarke, o. grumberg, s. jha, y. lu, h. veith. counterexample-guided abstraction refinement. in computer aided verification. pp. 154–169. springer berlin heidelberg, 2000. [ch09] j. c. campos, m. d. harrison. interaction engineering using the ivy tool. in calvary et al. (eds.), proceedings of the acm sigchi symposium on engineering interactive computing systems. pp. 35–44. acm press, 2009. [dac99] m. dwyer, g. avrunin, j. corbett. patterns in property specifications for finitestate verification. in 21st international conference on software engineering, los angeles, california. pp. 411–420. may 1999. [gs97] s. graf, h. saidi. construction of abstract state graphs with pvs. in computer aided verification. springer lecture notes in computer science 1254, pp. 72–83. springer-verlag, 1997. [hcm13] m. harrison, j. campos, p. masci. reusing models and properties in the analysis of similar interactive devices. innovations in systems and software engineering, 2013. doi:10.1007/s11334-013-0201-3 [kosf05] w. kong, k. ogata, t. seino, k. futatsugi. a lightweight integration of theorem proving and model checking for system verification. in proceedings of the 12th asia-pacific software engineering conferende (apsec’05). pp. 8 pp.–. 2005. [rss95] s. rajan, n. shankar, m. k. srivas. an integration of model checking with automated proof checking. in computer aided verification. springer lecture notes in computer science 939, pp. 84–97. springer-verlag, 1995. [sors99] n. shankar, s. owre, j. m. rushby, d. stringer-calvert. pvs system guide, pvs language reference, pvs prover guide, pvs prelude library, abstract datatypes in pvs, and theory interpretations in pvs. computer science laboratory, sri international, menlo park, ca, 1999. available at http://pvs.csl.sri.com/documentation. shtml. [us 10] us food and drug administration. infusion pump improvement initiative. technical report, center for devices and radiological health, april 2010. http://www.fda.gov/medicaldevices/productsandmedicalprocedures/ generalhospitaldevicesandsupplies/infusionpumps/ucm205424.htm proc. fmis 2013 12 / 12 http://dx.doi.org/10.1007/s11334-013-0201-3 http://pvs.csl.sri.com/documentation.shtml http://pvs.csl.sri.com/documentation.shtml http://www.fda.gov/medicaldevices/productsandmedicalprocedures/generalhospitaldevicesandsupplies/infusionpumps/ucm205424.htm http://www.fda.gov/medicaldevices/productsandmedicalprocedures/generalhospitaldevicesandsupplies/infusionpumps/ucm205424.htm introduction background complementary analysis approaches the pvs language the pvs model of the infusion pump overview of the infusion pump specifying the interface proving the property templates as theorems mirroring the process in the interface checking consistency of action checking ease of recovery conclusion microsoft word grabats06.doc electronic communications of the easst volume 1 (2006) guest editors: albert zündorf, daniel varró managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 proceedings of the third international workshop on graph based tools (grabats 2006) automation of java code analysis for programming exercises carsten köllmann, michael goedicke 11 pages eceasst 2 / 12 volume 1 (2006) automation of java code analysis for programming exercises carsten köllmann, michael goedicke university of duisburg-essen abstract: in this paper we present a tool environment for semi-automatic verification of basic programming exercises. we describe how graph transformation can be used for analysis of code structures and present an example from a current course. keywords: graph transformation, static analysis, agg, programming exercises, java, tool 1 introduction mapping problems to algorithmic solutions and to program code is a major challenge for first year students. the main problem is the development of an algorithm fitting to the given problem and deriving a corresponding program later on. experience shows that teaching of abstract structural concepts together with corresponding program structures is an adequate teaching concept. to internalize this kind of knowledge, numerous accompanying coding exercises are mandatory. manual correction of these exercises is a protracted work which needs a lot of manpower, especially when the large number of first year students (several hundreds in our case) has to be taken into account. therefore partial or, if possible, full automation of these corrections would generate a great benefit. exercises in the field of basic programming are characterized by the fact that a given problem mostly induces only a small number of principal solutions. furthermore in most cases only a set of similar “standard errors” occurs which can be derived from incorrect usage of the principal solutions the students learned before. in this paper we describe a graph transformation [eekr99] based java code analysis tool for the automatic check of java applications for “standard errors” specific to a given exercise, so the manual correction later on can focus on more individual problems. the tool supports the full java 5 syntax and shall provide the basis for more extensive analyses in the future. its application in the context of exercise testing for a big group of students has been done for collecting experience in a real world scenario. thus, we can benefit from the results in terms of scalability, the range of possible applications, usage conditions and performance. the support for structured representation, verification and modification of the java source code is provided by graph transformation techniques. graph transformation supports the description of syntax and the formalization of semantic aspects in one coherent formal technique. the representation of source code syntax in a graph structure and its modification by graph transformation has been done in several contexts like program refactoring [nd04] due to its ability of handling structures in a well defined way. furthermore by using graph transformation it is possible to introduce abstract views on concrete code by e.g. merging elements, or searching for code structures that can occur in arbitrary sequences without loosing automation of java code analysis for programming exercises proc. grabats 2006 3 / 12 the context of the original code. several existing graph transformation environments give related tool support which allows to actually apply the idea in practice. given these advantages we constructed a tool chain based on a general java to graph structure transformation, structured graph transformation and transformation back to java and applied this tool chain to the analysis problem sketched above. in the following we describe the workflow and tools used for the system. we focus on the static java code analysis by presenting our analysis approach, showing the buildup of an example exercise together with some corresponding verification tests. in addition we present a brief initial evaluation of our approach and justify the main design choices. at the end with give a brief description of our future work directed towards an additional dynamic analysis. 2 environment the workflow of our program verification system includes three main components: • teacher component: the teacher creates the coding exercises and corresponding verification tests. for static tests he primary defines the principal solutions of the exercise. later on graph rules for checking the code for corresponding structures have to be defined by him or a person experienced in creating graph rules. for runtime tests assertions have to be defined which a model checker can check later on. the component stores the rules and assertions for processing students’ solutions. • student component: the student uploads the source code of his solution to the server. after performing the checks he gets the information if his code is ok or what kind of standard flaws have been detected. now he can correct his code and check it again later on. • check component: the server gets the source code of the students, automatically processes the tests using the tool chain described below and stores the results. student browser server static analysis model checking teacher coding exercise result upload of source code definition of check rules for static analysis definition of assertions for model checking figure 1: environment for automatic exercise check the server component includes automatic verification of the uploaded solution code using rules and assertions defined by the teacher. to realize this fully automated back-end for code verification we combined graph tools for static code verification and for code modifications needed for the model checking [cs01] later on. in the following we describe the workflow realized by the back-end and present a more in-depth view of the tools. eceasst 4 / 12 volume 1 (2006) workflow of the server back-end: static analysis: after the source code has been uploaded and stored into a database it is transformed into a graph structure with java2ggx. next the graph rules of the specific exercise are applied to the source code graph by using the tool control for choosing the rule(s) to be applied and agg (attributed graph grammar system) [agg06] for actual processing the selected rule(s). if an error is detected a node is generated including information about the specific problem. after procession of all check-rules the resulting source code graph is parsed for these “error nodes” and their content is stored in the database for generating a report which can be accessed by the submitting student. if no error nodes are found the source code is marked as ok. preparing code for model checking: because of possible security problems during execution by the model checker java pathfinder (e.g. commands affecting the file system) only the usage of predefined libraries is allowed and has to be checked before with the static analysis techniques mentioned above. then the assertions a teacher has defined before are inserted into the source code of the student’s solution. the assertions are automatically placed in the given code after each assignment of a variable occurring in the assertion. all input operations are replaced with calls to the api of the model checker java pathfinder including the input range that shall be checked. after finishing these modifications the graph structure is retransformed into java code by ggx2java. runtime analysis: the prepared source code is compiled and the model checker java pathfinder will be started. if an error has been found the error path is displayed and will be stored into the database. the server back-end workflow (fig. 2) combines several existing tools and our own tools. the major challenge is the integration of the various tool formats in a way which assures a coherent presentation of the source code along the tool chain in order to generate useful hints related to the submitted original source code in the case of an error. in addition a good performance and scalability has to be accomplished which has been achieved by coupling the different tools as close as possible, e.g. by using directly the api of the graph transformation tool agg and not its graphical interface. thus the server back-end combines the following tools: • agg: agg [tae00] is a graph transformation tool where graph rules can be applied following the single push-out or double push-out approach [ehk+97]. graphs in this environment can be attributed by any kind of java object. automation of java code analysis for programming exercises proc. grabats 2006 5 / 12 j a v a c o d e g r a p h s t r u c t u r e a n a l y s i s r e s u l t r e s u l t s i n d b b y t e c o d e a n a l y s i s r e s u l t r e s u l t s i n d b g r a p h r u l e s f o r e x e r c i s e t r a n s f o r m a t i o n t o g r a p h f o r m a t a p p l i c a t i o n o f c h e c k r u l e s s t o r a g e m o d e l c h e c k i n g s t o r a g e s t a t i c a n a l y s i s : r u n t i m e a n a l y s i s : g r a p h s t r u c t u r e g r a p h s t r u c t u r e w i t h a s s e r t i o n s p r e p e r a t i o n f o r r u n t i m e a n a l y s i s : j a v a b y t e c o d ec o m p i l e g r a p h r u l e s c h e c k l i b r a r i e s & i n c l u d e a s s e r t i o n s j a v a s o u r c e c o d e t r a n s f o r m a t i o n t o j a v a c o d e figure 2: workflow implemented on server back-end • java2ggx: our tool transforms java source code into a graph structure and stores it in the graph description format ggx used by agg. the code is parsed by using the parser generator javacc [jcc06] including the java treebuilder which provides the abstract syntax tree (ast) of java. additional edges are introduced to express implicit dependencies in a source code. thus is a standard technique which allows easier formalisation of transformation rules. the resulting structure is stored in the ggx format. • ggx2java: our tool retransforms the ggx graph representation into java source code. • control: our tool uses the agg api to initiate the execution of a specific sequence of graph rules and therefore the sequence of the source code checks and modifications needed. • java pathfinder: java pathfinder [path06] is a model checking tool for java applications, checking assertions and concurrency faults. it executes all potential execution paths of a program for the whole range of possible input values for the application. the range of these values has to be predefined by the user as well as the assertions. 3 graph based code representation and graph transformation based verification graph transformations are based on graph grammars that consist of a graph (our java source code graph representation), and graph rules (our check rules) that perform the transformation. graph rules consist of a left hand side describing the pattern in a graph to be found, called match, and a right hand side describing the target structure of the transformation. the graph representation of the java code is based on its ast. additional dependencies to the ast are created to simplify the pattern matching for code verification later on. these dependencies include among others explicit edges from object usage to its instantiations and from there to its declaration, edges from method calls to the method declaration and nodes for eceasst 6 / 12 volume 1 (2006) explicitly defining the beginning and the end of logical blocks. an example of the source code representation is given in figure 3. the challenge we are facing with our approach for static source code analysis is how to statically test functional aspects of java programs that are coded in a very restrictive context. the main idea of our approach is to search for principal structures that should be used for solutions of an exercise and to define those as patterns for the left hand side of a rule. if none of these structures can be found, a possible error is indicated and an error node is created whose content is displayed to the student later on. searching for these solution patterns by graph rules gets more simple the more dependencies of the code have been made explicit. the patterns currently used can be applied to five main categories of program structures: • intra-method structures: major structures to be used in a method like different kinds of loops, recursion or condition statements are covered here. • inter-method structures: structures like method calls, parameters, or return statements are checked here. • intra-class attributes: the declaration and usage of variables and constants in a class is analysed by patterns covered by this category. • inter-class structures: here the local object instantiations are covered as well as the calls of methods and public attributes from outside. • combined structures: more in-depth checks often need a combination of the patterns used above. an example is the verification of the counter variable of a while loop combining an intra-method with an intra-class attributes check. 4 example of exercise creation in this chapter we present the definition of an example exercise and the creation of its principle solutions and corresponding rules. the exercise has been taken from an existing course teaching basic java programming. it includes the three steps: a) conceptual exercise formulation, b) definition of principal solutions and corresponding flaws, c) creation of check rules. problem statement: implement a dynamic fifo (first in first out) list with methods for insertion of an element, searching for an elements and deletion of an element. templates to be used: class element{ string text; element nf;} class list{ element head, foot; void insert (string text){…} void search (string text){…} void delete (string tetxt){…}} automation of java code analysis for programming exercises proc. grabats 2006 7 / 12 possible flaws to check (among others): 1. the implementation does not use the templates. 2. the insert method does not consider the head of the list correctly. 3. the search method includes a loop without a structural correct termination condition. 4. the delete method does not consider the correct handling of the list head. definition of check rules and rule flow: flaw 1: • check if the structure of the given templates appears (separately and in combination). • check if the methods are named correctly. flaw 2: • check if the method insert includes a condition containing the sub-term == and a class variable of type element before or after this expression. the identification of the element class has to be done by structure check, not by checking the class name. • check if the body of this condition includes assignments from an object of the type element that is dependent on the method parameter, to the class variable detected before. possible solution variant: class list{ element head, foot; public void insert (string text){ element e=new element; e.text=text; if(head==null){ head=e; … flaw 3: • check for loops included in the search method and check if there is a connection between the termination condition of the loop and the method parameter. • check if on the left or the right of the connected element an object of the element type appears, that points directly or indirectly to the class parameter text. possible solution variant (see also figure 3): class list{ public void search (string text){ ... while (!e.text.equals(text)) … eceasst 8 / 12 volume 1 (2006) flaw 4: • check for conditions included in the delete method and check if these conditions are connected to class variables • check if the corresponding bodies contain a) assignments from these variables and/or b) to these variables. possible solution variant: class list{ element head ,foot; public void delete (string text){ if (e==head){ //e represents the text containing element head=head.nf; … in the following we show the practical usage of our approach by presenting a description of our implementation for checking flaw 3. figures 3 and 4 show the main rules used to detect principal solution structures while figure 5 shows the graph of a possible implementation variant. the structure searched for to cover flaw 3 is highlighted here. all figures are from the agg tool. some dependency edges from variable usages to their declarations have been hidden in figure 5 for clarity. the graph contains the element class and the list class just including the search method. after the while node has been found the corresponding termination condition is analysed. the expression structure is traversed to find a connection to the method parameter text and the reference to the text definition in the element class. figure 3 shows the pattern used to match the reference to the text variable of the element class. the node mark is used for traversal through the termination condition (traversal rules are not shown here). we avoided to use the name of the variable in this rule. so even solutions using a different name than text for the variable in the element class are found. the bold text element of the possible solution expression while (!e.text.equals(text)) is e.g. found here. figure 3: rule to detect the usage of a variable declared in the element class the second main rule we used is presented in figure 4. here the dependency of an element in the termination condition of the while loop on the parameter text of the search method is detected. this rules explicitly searches for a method parameter named text that has to be used in the condition of the while loop. the bold text element of the possible solution expression while (!e.text.equals(text)) is e.g. found by this rule. automation of java code analysis for programming exercises proc. grabats 2006 9 / 12 figure 4: rule to detect the usage of the text parameter of the search method if the two rules described above find a match in the graph of the java code then the fact is verified, that the termination condition of the while loop contains the correct reference objects. further rules could now be used to analyse if these are connected with the method call equals of the string class. a disadvantage of these rules would be the limited number of possible solutions they cover, because students could e.g. use self written methods for checking the string equality. of course, more general rules can be formulated which cover more correct solutions variants. so far we presented the static part of the checking. the dynamic part, using pathfinder, is ongoing work. here the transformation abilities of agg are essential for the instrumentation of code with assertions. figure 5: graph representation of solution code with highlighted nodes for checking flaw 3 eceasst 10 / 12 volume 1 (2006) 5 evaluation in the first part of this chapter we desribe an initial experimental evaluation of our approach while in the second part we justify our main design choices. experimental evaluation we evaluated our approach by choosing typical exercises of an introductory programming course. here we describe two of them. the first one is used in the middle of the semester including the creation of a dynamic list, search for specific elements and deletion of elements in this list. the flaws we cover here have partly been presented in the exercise above. the second example is used at the end of the semester examining the handling of interfaces in java. here we checked among other things the valid connection between interfaces and classes and their correct instantiation. for our evaluation the exercises have been processed by 7 students. their solutions have been checked by using the tool environment described in chapter 2. because of the fact that our approach can not process a full semantic check, the solutions have been additionally analysed manually to investigate possible errors at a more detailed level. the table below includes the number of rules used for checking the whole exercise, the total number of flaws that can be checked by these rules, the number of flaws found during our experiment and the number of false negatives (the students used structures that we have not anticipated during rule creation) found in the student examples. we also counted the number of solutions containing errors that have not been found by our rules because they appeared at a very detailed level. interface example dynamic list example total number of rules used for structure check 9 19 total number of flaws covered 5 10 flaws found in student solutions 10 6 false negatives found in student solutions 2 2 errors not found in student solutions 2 1 it can be seen that we needed in both exercises approximately twice as many rules as the number of flaws. the flaws found included wrong class initialisations in the interface example, like squareclass q = new geometricobjectinterface(), which tries to instatiate an object by using an interface. further errors in the dynamic list example included a wrong usage of objects, like the statement head=head.nf for list traversal during the search for a specific element, which results in the loss of the head element of a dynamic list. other more simple flaws covered simply missing statements or missing implementation of demanded functionality. the false negatives in the interface example resulted from the usage of the valid array definition geometricobjektinterface o [] = {new circle(), new square()} not covered by our basic array initialisation check in the interface example. the false negatives of the list example resulted from the usage of internal methods not anticipated by us. the errors not found resulted from wrong usage of auxiliary variables. automation of java code analysis for programming exercises proc. grabats 2006 11 / 12 the result of this preliminary evaluation is encouraging, because of the significant number of flaws found compared to the number of false negatives. however, it can be seen that further abstraction is needed to cover also the false negatives detected here and the handling of auxiliary variables. of course, this abstraction must not result in false positives. during this evaluation no false positives have been detected. justification of the main design choices graph transformation is a good choice since it allows addressing structural errors in the context of the student’s solutions (see chapter 5). the representation of java 5 programs using graphs has been chosen to cover a wide range of applications (check and transformation of java programs). thus, it may seam that the structure is overly complex. however, the approach was to use the ast plus some additional information to allow a detailed representation. for areas in program checking where a lot of implementation variants have to be covered we use “coarsening” rules, which provide abstractions from the specific graph elements (see chapter 4). the usage of further abstraction techniques is planned to cover information about the software architecture at a more global level e.g. just regarding dependencies between methods and classes. 6 related work in [trb] a similar approach is presented checking java code for principal solutions based on the ast and a xml description of the solutions to be checked. the principal solutions are either given as concrete java code or as an abstract structure. the advantage of our graph transformation based approach is the possibility of using abstract elements together with concrete ones, so it is possible to generate check structures at a more advanced level. from the point of view of a general e-learning environment our testing tool helps to ensure the quality of a basic programming course by supporting students in their learning efforts and is therefore part of the quality process [str06]. other tools used in this context mostly focus either on staticor runtime analysis whereas we offer a combined solution. our approach for identification of principal solution structures in source code can be compared with approaches used for design pattern detection [acgj01] and the recognition of “bad smelling code” used for program refactoring [fbb+00]. while these techniques focus on the analysis of arbitrary code, patterns analysed are on a more abstract level like class dependencies or method interactions. because of the more specific context of our code we can create more in-depth analysis, including more semantic aspects. 7 remarks and future work in this paper we presented an approach for source code analysis by graph transformation and its applicability in a real world example. we focused on a tool environment combining several existing and self-implemented tools covering the complete java 5 syntax for verification of first year student exercises. currently we implemented the back end tool chain and generated several exercises. the next step is the implementation of the web access and checking the exercises of a whole semester. the verification environment will be used in the basic java programming course “programming” in semester 2006/2007 with about 500 students. eceasst 12 / 12 volume 1 (2006) further work will analyse the scalability of this approach detecting the limits of this “exercise specific” process verifying the functional aspects. furthermore we currently investigate the detection of problematical structures derived from non-functional aspects like performance, and maintainability. 8 references [acgj01] h. albin-amiot, p. cointe, y.-g. gueheneuc, and n. jussien. instantiating and detecting design patterns: putting bits and pieces together. in proceedings of 16th annual international conference of automated software engineering, pages 166-173. ieee computer society press, november 2001. [agg06] the agg web site. http://tfs.cs.tu-berlin.de/agg/, june 2006. [cs01] e. m. clarke, b. schlinglo, model checking, in a. robinson and a. voronkov, editors. handbook of automated reasoning, celsevier science publishers b.v., 2001. [eekr99] hartmut ehrig, gegor engels, hans-jörg kreowski, and grzegorz rozenberg, editors. handbook of graph grammars and computing by graph transformation, vol.2: applications, languages and tools. world scientific, signapore, 1999. [ehk+97] h. ehrig, r. heckel, m. korff, m. löwe, l. ribeiron, a. wagner, and a. corradini. algebraic approaches to graph transformation ii: single pushout approach and comparison with double pushout approach. in g. rozenberg editor. the handbook of graph grammar and computing by graph transformations, volume i: foundations.world scientific. 1996. [fbb+00] martin fowler, kent beck, john brant, william opdyke, don roberts, refactoring: improving the design of existing code, addison-wesley, 2000. [jcc06] the javacc web site. https://javacc.dev.java.net/. june 2006. [nd04] niels van eetvelde and dirk jannsens. extending graph rewriting for refactoring. in proceedings of international conference of graph transformation 2004. springer. september 2004. [path06] the java pathfinder web site. http://javapathfinder.sourceforge.net/. june 2006. [str06] c. stracke, process-oriented quality management. in j. pawlowski, u. ehlers, editors. european handbook for quality and standardisation in e-learning, pages 77-91, springer, 2006. [trb04] nghi truong, paul roe and peter bancroft, static analysis of students' java programs. in proc. sixth australasian computing education conference (ace2004), dunedin, new zealand. crpit, 30. lister, r. and young, a. l., eds., acs. 317-325. 2004. [tae00] gabriele taenzer. agg: a tool environment for algebraic graph transformation. in m.nagel, a.schürr, and m. münch, editors. application of graph transformation with industrial relevance: international workshop, agtive’99, kerlkerade, the netherlands, volume 1779, pages 481-488. springer, heidelberg, 2000. verification of model transformations electronic communications of the easst volume 29 (2010) proceedings of the ninth international workshop on graph transformation and visual modeling techniques (gt-vmt 2010) verification of model transformations bernhard schätz 13 pages guest editors: jochen küster, emilio tuosto managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst verification of model transformations bernhard schätz fortiss gmbh guerickestr. 25, 80805 mnchen, germany schaetz@fortiss.org abstract: with the increasing use of automatic transformations of models, the correctness of these transformations becomes an increasingly important issue. especially for model transformation generally defined using abstract description techniques like graph transformations or declarative relational specifications, however, establishing the soundness of those transformations by test-based approaches is not straight-forward. we show how formal verification of soundness conditions over such declarative relational style transformations can be performed using an interactive theorem prover. the relational style allows a direct translation of transformations as well as associated soundness conditions into corresponding axioms and theorems. using the isabelle theorem prover, the approach is demonstrated for a refactoring transformation and a connectedness soundness condition. keywords: model transformation, rule-based, verification, theorem prover 1 motivation the construction of increasingly sophisticated software products has led to widening gap between the required and supplied productivity in software development. to overcome the complexity of realistic software systems and thus increase productivity, current approaches increasingly focus on a model-based development using appropriate description techniques. besides increasing efficiency, these transformations can offer consistency ensuring modification of models, ranging from refactoring steps to improve the architecture of a system to the consistent integration of standard behavior. however, with the increased use of transformation, the question of the correctness of transformations arises: how can we verify that the models constructed via transformation are ‘well-formed’ given a ‘well-formed’ source model, e.g., by ensuring that no relevant elements of the source model are absent in the target model. obviously, testing is one possible way of ensuring the correctness of transformations. however, concepts like coverage etc. are not immediately transferable to model-transformations, especially if those are rules-based or declarative. in the following, a approach for the verification of transformations is introduced, supporting the formal proof of properties over these transformations. the approach uses a declarative relational style to provide a transformation mechanism, implemented on the eclipse/emf ecore platform, using a prolog rule-based interpretation. 1 / 13 volume 29 (2010) mailto:schaetz@fortiss.org verification of model transformations 1.1 related approaches verification of model transformations has been specifically investigated for graph-based transformation technquies (e.g., [ggl+06] and [str08]). in that respect, the presented approach is similar: the introduced transformation framework is used to describe graph transformations, using a relational calculus focused on basic constructs to manipulate nodes (elements) and edges (relations) of a conceptual model. a theorem prover based on on high-order logics is used to prove characteristics of the transformation by deducing properties of the target model from some properties of the source model. in contrast to other graph-based approaches like moflon/tgg [kks07], viatra [vp04], or fujaba [ggl05], however, here the specification of transformations is not based on triple graph-grammars or graphical, rule-based descriptions, but uses a textual description based on a relational, declarative calculus. therefore, in contrast to those approaches, the approach introduced here uses only a single formalism to describe basic transformations as well as their compositions.furthermore, only a single homogenous formalism with two simple construction/deconstruction operators to describe the basic transformation rules and their composition; complex analysis or transformation steps can be easily modularized since there are no side-effects or incremental changes during the transformation. thus, a specification can be immediately used for verification without complex translations; furthermore, proofs on the formal level more directly reflect intuitive reasoning about the transformation. this homogeneity is especially important for verification since is drastically simplifies the construction of proofs: [ggl+06] focusses on tgg-based translation and therefore uses substantial proof parts to model (and verify) the effective construction of correspondence graphs to describe the application of individual graph rules. furthermore – due to that approach – there structural induction over the pre/post-models is used which is less convenient when if non-translation transformations are verified. here, in contrast, induction over the transformation itself rather than the pre/post models is performed, thus having a more direct proof principle and avoiding the proof overhead of correspondence graphs and applicability conditions. similarly, [str08], – using isabelle as theorem proving support, too – also requires substantial effort to specify and verify correspondence graph and application conditions for single transformation rules as well their combination using while and case constructs. thus, the application and ordering of rules provided implicitly by a tgg approach has to be verified explicitly and using rather different proof principles. in contrast, here, a more direct and homogenous form of proof is supported by the declarative rule-based style. [cr09] uses a relational description of graphs similar to the presented approach as well as similar proof principles. however, neither is their formalism is supported by an executable implementation nor do they use mechanic proof support. a rule-based description of transformations. another advantage of the presented approach is its capability to interpret loose characterizations of the resulting model, supporting the exploration of a set of possible solutions. by making use of the back-tracking mechanism provided by prolog, alternative transformation results can not only be applied to automatically search for an optimized solution, e.g., balanced component hierarchies, using guiding metrics; the set of possible solutions can also be incrementally generated to allow the user to interactively identify and select the appropriate solution. proc. gt-vmt 2010 2 / 13 eceasst figure 1: example of hierarchical component model and corresponding conceptual model 1.2 overview and contribution as the main contribution, an approach to formally verify model transformations is presented in the following sections. the approach is based on a transformation of emf ecore models using a completely declarative relational style in a rule-based fashion, introduced in [sch08]. to provide such a form of transformations, the approach uses a term-based formalization of an emf model as shown in section 2. with this form of model representation, as shown in section 3 transformations can be described as declarative relations in prolog style, supporting rules similar to graph grammars as a specific description style. based on these previously established results, as new contribution in section 4 the suitability of this declarative relational style of defining models and transformation rules for the verification of transformations is shown: the formalization of (meta-)models and transformation rules can be directly translated in representations suited for theorem provers for predicate logic like isabelle; furthermore, due to the relational style correctness proofs of transformations can be performed by reasoning on the level of their specifications. section 5 highlights some benefits and open issues. 2 model structure to provide verified transformations of descriptions of systems, first the means of specifying a system in form of a system model is needed. the left-hand side of figure 1 shows such a model, describing the hierarchical structure of the components of a system: the system system, consisting of subcomponents subsystem, componentb, and siblingsystem, the first and the last with subcomponents componenta and componentc, resp.1 to construct formalized descriptions of a system under development, a ‘syntactic vocabulary’ is needed. this conceptual model2 characterizes all possible system models built from the modeling concepts and their relations used to construct a description of a system; typically, class 1 for simplification, here only components and their containment-relation is modeled; other typical aspects like interfaces or communication links are ignored. 2 in the context of technologies like the meta object facility, the class diagram-like definition of a conceptual model is generally called meta model. 3 / 13 volume 29 (2010) verification of model transformations diagrams are used to describe them. the right-hand side of figure 1 shows the corresponding conceptual model – with the concept of a component with an attribute name and a subcomprelation – used to describe the architectural structure of a system. 2.1 structure of the model the transformation framework provides mechanisms for a pure (i.e., side-effect free) declarative, rule-based approach to model transformation, accessing emf ecore-based models [sbpm07]. based on the conceptual model, a system model consists of sets of elements (each described as a conceptual entity and its attribute values) and relations (each described as a pair of conceptual entities), syntactically represented as a prolog term. since these elements and relations are instances of classes and associations taken from an emf ecore model, the structure of the prolog term – representing an instance model – is inferred from the structure of that model. the structure of the model is built using only simple elementary prolog constructs, namely compound functor terms and list terms. to access a model, the framework provides predicates to deconstruct and reconstruct a term representing a model. [sch08] describes the model in more detail. a model term describes an instance of a emf ecore model. each model term is a list of package terms, one for each packages of the emf ecore model. each package term, in turn, describes the content of the package instance. it consists of a functor, identifying the package, with a sub-packages term, a classes terms, and an associations term as its argument. the subpackages term describes the sub-packages of the package; it is a list of package terms. the classes term describes the eclasses of the corresponding package. it is a list of class terms, one for each eclass. each class term consists of a functor, identifying the class, and an elements term. an elements term describes the collection of objects instantiating this class, and thus is a list of element terms. finally, an element term consists of a functor, identifying the class this object belongs to, with an entity identifying the element and attributes as arguments. each of the attributes are atomic representations of the corresponding values of the attributes of the represented object. the entity is a regular atom, unique for each element term. similarly to an elements term, each associations term describes the associations, i.e., the instances of the ereferences of the eclasses, for the corresponding package. again, it is a list of association terms, with each association term consisting of a functor, identifying the association, and an relations term, describing the content of the association. the relations term is a list of relation terms, each relation term consisting of a functor, identifying the relation, and the entity identificators of the related objects. in detail, the prolog model term has the structure shown in table 1 in the bnf notation with corresponding non-terminals and terminals.3 the functors of the compound terms are deduced from the emf ecore model: the functor of a packageterm from the name of the epackage; the functor of a classterm from the name of the eclass; the functor of an associationterm from the name of the ereference. similarly, the atoms of the attributes are deduced from the instance of the emf ecore model, which the model term is representing: the entity atom corresponds to the object identificator of an instance of a eclass, while the attribute corresponds to the attribute value of an instance of an eclass. 3 while actually a modelterm consists of a set of packageterms, here for simplification purposes only one packageterm is assumed. proc. gt-vmt 2010 4 / 13 eceasst modelterm ::= packageterm packageterm ::= functor(packagesterm,classesterm,associationsterm) packagesterm ::= [] | [ packageterm (,packageterm)* ] classesterm ::= [] | [ classterm (,classterm)* ] classterm ::= functor(elementsterm) elementsterm ::= [] | [ elementterm (,elementterm)* ] elementterm ::= functor(entity(,attributevalue)*) entity ::= atom attributevalue ::= atom associationsterm ::= [] | [ associationterm(,associationterm)*] associationterm ::= functor(relationsterm) relationsterm ::= [] | [ relationterm(,relationterm)*] relationterm ::= functor(entity,entity) table 1: the prolog structure of a model term 2.2 construction predicates in a strictly declarative rule-based approach, the transformation is described in terms of a predicate, relating the models before and after the transformation. therefore, mechanisms are needed in form of predicates to deconstruct a model into its parts as well as to construct a model from its parts. as the structure of the model is defined using only compound functor terms and list terms, only two forms of predicates are needed: union and composition operations. 2.2.1 list construction the(de)construction of lists is managed by means of the union predicate union/3 with template4 union(?left,?right,?all) such that union(left,right,all) is true if all elements of list all are either elements of left or right, and vice versa. thus, e.g., union([1, 3,5],r,[1,2,3,4,5]) succeeds with r = [2,4]. 2.2.2 compound construction since the compound structures used to build the model instances depend on the actual structure of the emf ecore model, only the general schemata used are described. in all three schemata – package, class/element, or association/relation – the name of the package, class, or relation is used as the name of the predicate for the compound construction. packages for (de)construction of packages, package predicates of the form package/4 are used with template package(?package,?subpackages, ?classes,?associations) where package is the name of the package (de)constructed. thus, e.g., a package named architecture in the emf ecore model is represented by the compound constructor architecture. the predicate is true if package consists of subpackages subpackages, classes classes, and associations associations. 4 according to standard convention, arbitrary/input/output arguments of predicates are indicated by ?/+/-. 5 / 13 volume 29 (2010) verification of model transformations figure 2: example: result of clustering componentb and siblingsystem classes and elements for (de)construction of – non-abstract – classes/elements, class/element predicates of the form class/2 and class/n+2 are used where n is the number of the attributes of the corresponding class, with templates class(?class, ?elements) and class(?element,?entity,?attr1,...,?attrn) where class is the name of the class and element (de)constructed. thus, e.g., the class named compound in the emf ecore model in figure 1 is represented by the compound constructor compound. the class predicate is true if class is the list of objects; it is used to deconstruct a class into its list of objects, and vice versa. similarly, the element predicate is true if element is an entity with attributes attr1,. . . ,attrn; it can be used to deconstruct an element into its entity and attributes, to construct an element from an entity and attributes (e.g. to change the attributes of an element), or to construct a new element including its entity from the attributes. thus, e.g., compound(compounds,[sys,sub,sib]) is used to construct a class compounds from a list of objects sys, sub, and sib. similarly, compound(sub,subsys,"subsystem") is used to construct a new element sub with entity subsys, and name "subsystem". association and relation compounds for (de)construction of associations and relations, association and relation predicate of the form association/2 and association/3 are used with templates association(?association,?relations) and association(?relation,?entity1,?entity2) where association is the name of the association and relation constructed/deconstructed. thus, e.g., a relation named subcomp in the emf ecore model in figure 1 is represented by the compound constructor subcomp. the relation predicate is true if association is the list of relations; it is generally used to deconstruct an association into its list of relations, and vice versa. similarly, the relation predicate is true if relation associates entity1 and entity2; it is used to deconstruct a relation into its associated entities and vice versa. e.g., subcomp(subcomps,[subsys,sibsys]) is used to construct the subcomponent association subcomps from the list of relations subsys and sibsys. similarly, subcomp(subsys,sub,sys) is used to construct relation subsys with sub being the subcomponent of sys. proc. gt-vmt 2010 6 / 13 eceasst 1 cluster(pre,group,post) :− 2 architecture(pre,pack,preclass,preassoc), 3 compound(precomp,precomps),union(otherclass,[precomp],preclass), 4 subcomp(presub,presubs),union(otherassoc,[presub],preassoc), 5 link(presubs,group,preroot,outsubs), 6 compound(prerootcomp,preroot,name),union([prerootcomp],comps,precomps), 7 subcomp(newsub,postroot,preroot),union([newsub],outsubs,insubs), 8 compound(postrootcomp,postroot,name),union([prerootcomp,postrootcomp],comps,postcomps), 9 link(postsubs,group,postroot,insubs), 10 subcomp(postsub,postsubs),union(otherassoc,[postsub],postassoc), 11 compound(postcomp,postcomps),union(otherclass,[postcomp],postclass), 12 architecture(post,pack,postclass,postassoc). figure 3: cluster-transformation: rule for (de-)constructing the model 3 transformation definition the conceptual model and its structure defined in section 2 was introduced to define transformations of system models as shown in the left-hand side of figure 1. a typical transformation step is the clustering of a group of sibling components within a container component, making them subcomponents of that container. figure 2 shows the result of such a transformation clustering subcomponents componentb and siblingsystem of component system in figure 1 into a new system container. besides introducing the new additional component system and making it a subcomponent of the original system root component, the transformation also requires changing the supercomponent of componentb and siblingsystem. in a relational approach to model transformations, such a transformation is described as a relation between the model prior to the transformation (e.g., as given in the left-hand side of figure 1) and the model after the transformation (e.g., as given in figure 2). in this section, the basic principles of describing transformations as relations are described. 3.1 transformations as relations in case of the clustering operation, the relation describing the transformation has the interface cluster(pre,group,post) with parameter pre for the model before the transformation, parameter post for the model after the transformation, and parameter group for the group of components of the model to be clustered. in the relational approach presented here, a transformation is basically described by breaking down the pre-model into its constituents and build up the post-model from those constituents using the relations from section 2, potentially adding or removing elements and relations. with pre taken from the conceptual domain described in figure 1 and packaged in a single package architecture with no sub-packages, it can be decomposed in contained classes (e.g., compound) and associations (e.g., subcomp) as shown in figure 3, lines 2 to 4.5 in the same fashion, post can be composed in lines 12 to 10. lines 6 to 8 obtain the name of the common super-component with entity preroot of the group (line 6), provide 5 for ease of reading, quotes required in prolog for capital functor identifiers like architecture or compound are dropped. 7 / 13 volume 29 (2010) verification of model transformations 1 link(subs,[],root,subs). 2 link(insubs,group,root,outsubs) :− 3 subcomp(subrel,sub,root),union([sub],rest,group),union([subrel],subs,insubs), 4 link(subs,rest,root,outsubs). figure 4: cluster-transformation: rule for (un-)linking subcomponents a newly created compound container component postrootcomp this name and entity postroot (line 8), and make this preroot the super-component of postroot (line 7). note that the relation is bidirectional: besides clustering a group of siblings into a common container, it can also be used to uncluster the group of subcomponents contained in a common container. besides using the basic relations to construct and deconstruct models (and add or remove elements and relations, as shown in the next subsection), new relations can be defined to support a modular description of transformation, decomposing rules into sub-rules. e.g., in the cluster relation, the transformation can be decomposed into the addition of the new container component and the reallocation of the components to be clustered; for the latter, then a sub-relation link with corresponding rules is introduced, as shown in figure 4. note that link is effectively used in both directions in the cluster relation: in line 5, link is used to unlink subcomponents by removing the subcomp-associations between group elements and the original component preroot from presubs to obtain outsubs; in line 9, link is used to link subcomponents by adding the subcomp-associations between group elements and the new component postroot to insubs to obtain postsubs. 3.2 transformations as rules to define the transformation steps for (un)linking components and subcomponents, relation link(insubs,group,root,outsubs) is used, by making the set outsubs of associations the reduction of set insubs when removing all subcomp-associations between elements from group and root. the (un)linking of a group depends on whether the group is empty or not. therefore, in a declarative approach, two different – recursive – (un)link rules for those two cases are needed, each with the interface described above. to define these rules as shown in figure 4, the conceptual model and its structured representation introduced in section 2 are used. line 1 simply states that in case of an empty group the sets of associations are the same since no elements can be (un)linked. this case also handles the termination of the inductive rule definition. in case of a non-empty group, line 3 (un)links a sub element from the group – leaving a rest rest – and root, while line 4 repeats this (un)linking recursively for the rest of the group. note that this rule-based description allows to compose complex transformations by simple application of rules in the body of another rule (like link in cluster). in contrast, graphical specifications generally use additional forms of diagrams, e.g., state-transition diagrams. as shown in the following section, this direct combination of rules, however, is essential to simplify the formal verification of the correctness of transformations. proc. gt-vmt 2010 8 / 13 eceasst 4 verification the relational and declarative approach introduced in the previous sections supports an easy transition to formal reasoning. in this section, the formalization of an emf ecore meta-model in constructive type theory is presented, as well as the straight-forward formalization of transformations. based on these formalizations, the construction of formal correctness proof is demonstrated using the example of typical invariants. to support formal verification, the interactive theorem prover isabelle/hol [npw02] is applied. 4.1 meta-model formalization isabelle/hol supports the form of (typed) terms used to represent the emf models in the rulebased transformation process. thus, the transition from the specifications used in section 2 to isabelle/hol is straight-forward, as shown in the – syntactically slightly simplified – formalization of the meta-model of figure 1:6 1 typedecl ids 2 typedecl string 3 datatype comp = comp ids string, atom = atom ids string 4 datatype subcomp = subcomp ids ids 5 datatype cls = comp comp set | atom atom set 6 datatype asc = subcomp subcomp set 7 datatype architecture = architecture cls set asc set after introducing – via typedecl – uninterpreted ids and string types for representing entities and string attributes in lines 1 and 2, the corresponding element (line 3), relation (line 4), class (line 5), association (line 6), and package (line 7) term types are introduced simply by providing – via datatype – constructor functions, using the same scheme as introduced in subsection 2.1.7 based on these constructors and using the set operations provided by isabelle/hol, prolog model terms can be directly translated, thus enabling the translation of transformations. 4.2 transformation formalization besides type terms, isabelle also supports the definition of predicates in a rule-based fashion analogue to the prolog-based rules in the transformation approach. to define the transformation relations in isabelle, inductive definitions of predicates are used to allow recursive definitions. the non-recursive cluster relation of section 3 is – trivially inductively – defined via:8 1 inductive cluster :: architecture => ids set => model => bool where 2 pre = (architecture preclass preassoc) & 3 precomp = (comp precomps) & otherclass un {precomp} = preclass & 4 presub = (subcomp presubs) & otherassoc un {presub} = preassoc & 5 (link presubs group preroot outsubs) & 6 prerootcomp = (comp preroot name) & {prerootcomp} un comps = precomps & 7 newsub = (subcomp postroot preroot) & {newsub} un outsubs = insubs & 6 set introduces a set type, | a variant type, => a function type. 7 the compound and atomiccomponent element/class constructors are abbreviated to comp and atom, resp. 8 standard isabelle notation is used, including &, |, and --> for conjunction, disjunction, and implication; <= and : for the subset and element relation; ? for the existential quantor. 9 / 13 volume 29 (2010) verification of model transformations 8 postrootcomp = (comp postroot name) & {prerootcomp,postrootcomp} un comps = postcomps & 9 (link postsubs group postroot insubs) & 10 postsub = (subcomp postsubs) & otherassoc un {postsub} = postassoc & 11 postcomp = (comp postcomps) & otherclass un {postcomp} = postclass & 12 post = (model postclass postassoc) 13 −−> (cluster pre group post) obviously, again the transition from the specifications used in the previous sections to isabelle/hol is straight-forward: line 2 to 12 directly correspond to line 2 to line 12 in figure 3; in the former only a direct formalization with equality combined the constructors and set union is used, while the later uses (de)construction predicates. line 13 of the former corresponds to line 1 of the later. line 1 additionally defines the type of the predicate in isabelle/hol designated by “::”. in a similar fashion, the specification of link can be directly translated: 1 inductive link :: subcomp set => ids set => ids => subcomp set => bool where 2 (link subs {} root subs) | 3 (link subs rest root outsubs) −−> (link ({subcomp.subcomp sub root} un subs) ({sub} un rest) root outsubs) 4.3 proof construction using the formalization of the transformations introduced above, now correctness properties of the clustering operation can be defined. in the following, two conditions – one concerning class and one concerning association properties – are considered: 1. each compound element contained in the pre-model is also contained in the post model. 2. each subcomp relation between a component and some super-component in the pre-model has a counter-part in the post-model for the same component and some – potentially different – super-component. the first property is formalized as theorem keep comp cluster: 1 theorem keep comp cluster: 2 (cluster pre group post) & pre = (architecture preclass preassoc) & post = (architecture postclass postassoc) & 3 precomp = (comp precomps) & preatom = (atom preatoms) & {precomp, preatom} = preclass & 4 postcomp = (comp postcomps) & postatom = (atom postatoms) & {postcomp, postatom} = postclass & 5 (somecomp:precomps) −−> (somecomp:postcomps) this theorem is straightforward to prove, requiring no induction but only case distinction. therefore, the proof is mainly performed by applying isabelle’s automatic proof tactics (e.g., auto, clarify, clarsimp), rendering the theorem (or lemma) applicable in further proof steps: 1 apply auto 2 apply (erule pushpull.cases) 3 apply clarify 4 apply (drule equalityd1) 5 apply (drule equalityd2) 6 apply (drule un sub d) 7 apply (drule un sub d) 8 apply clarsimp proc. gt-vmt 2010 10 / 13 eceasst beside the case distinction (line 2), the proof requires three standard simplifications (lines 1, 3, 8 ) and four simple interactions deadline with equality and sub-set relation properties, where the latter could also be further automized by providing suitable rules. the second, more challenging property is formalized as theorem keep subcomp cluster: 1 theorem keep subcomp cluster: 2 (cluster pre group post) & pre = (architecture preclass preassoc) & post = (architecture postclass postassoc) & 3 presubcomp = (subcomp presubcomps) & {presubcomp} = preassoc & 4 postsubcomp = (subcomp postsubcomps) & {postsubcomp} = postassoc & 5 (? root. (subcomp some root):presubcomps) −−> (? root .(subcomp some root):postsubcomps) the proof script for theorem keep subcomp cluster uses the same steps as before; however, since the corresponding super-component in a subcomp-relation in the post-model is different whether the sub-component is in the group to be clustered or not, the proof requires one additional step – a lemma application – for distinction between these cases. to that end, corresponding lemmata are introduced and proved, e.g., keep link group to deal with the case on non-group elements. since this distinction essentially affects link, these lemmata operate on the link relation: 1 lemma keep link group: (link pre group old lsubs) & (link post group new rsubs) −−> (lsubs <= rsubs & some:group) 2 −−> (subcomp some root):pre −−> (subcomp some root):post since these lemmata make use of the inductively defined relation link, induction must be used. however, besides suggesting the use of the induction principle on the definition of link, again the proof can performed fully automatic. these lemmata can be combined in a single lemma keep link with a trivial proof: 1 lemma keep link: (link pre group old lsubs) & (link post group new rsubs) −−> lsubs <= rsubs 2 −−> (? root. (subcomp some root):pre) −−> (? root. (subcomp some root):post) in its proof, proven lemmata like keep link group can be applied in the form 1 apply (insert keep link group [of pre group old lsubs post new rsubs some]) the complete proof of theorem keep subcomp cluster consists of the proof of the lemmata with 23 steps and 10 steps for the proof of the theorem itself with the resulting keep link lemma. 5 conclusion and outlook the pete transformation framework – provided as an eclipse plugin [sch09] – supports the transformation of emf ecore models using a declarative relational style and allows a simple, precise, and modular specification of transformation relations on the problemrather than the implementation-level. by including operational aspects, the relational declarative form of specification can be tuned to ensure an efficient execution. in the application to problem from the embedded software domain, the approach has demonstrated practical feasibility for medium real-world sized models (e.g, refactoring models consisting of more than 3000 elements and more than 5000 relations within a few seconds). furthermore, debugging on the level of the specification supports the construction of transformations. the use of a declarative relational style of specifying transformations is an important asset for the formal verification of correctness conditions of these transformations: it allows the direct translation of the conceptual model as well as the transformation rules into a predicate-logical 11 / 13 volume 29 (2010) verification of model transformations formalization. since no indirections are introduced between the specifications on the execution and the verification level, the proof can be constructed following a natural argumentation. using a verification tool like isabelle/hol, the verification process can be automized to a large extent. while the previous sections have demonstrated the applicability of the approach, additional means of automation should be provided for a extensive application. this includes the mechanic translation of emf ecore models into the corresponding type definitions. furthermore, the translation should include the definition of the basic manipulation predicates in the (de)constructor format to allow the 1:1 use of the executable specification of transformations in the verification. additionally, general lemmata, tailor-made tactics, or using isar for more readable proof scripts should be provided to simplify proofs. also, other property languages like ocl and pre/post schemata should be included, to circumvent the specification of property conditions on the level of predicate logics. finally, the practicability of the verification approach requires the analysis of larger case studies to understand in which cases a formal verification of a rule-based transformation can be favorable, e.g., over a testing-based verification of a programming-level transformation. since the declarative relational style can also be used to support a search-based design-space exploration involving backtracking – e.g., when computing correct deployments in embedded systems – making test-based verification even more complex, simple formal verifiability of the correctness of such explorative transformations is especially helpful. bibliography [cr09] s. a. da costa, l. ribeiro. formal verification of graph grammars using mathematical induction. electronic notes in theoretical computer science 240:43–60, 2009. [ggl05] l. grunske, l. geiger, m. lawley. a graphical specification of model transformations with triple graph grammars. in hartman and kreische (eds.), model driven architecture. lncs 3748. springer, 2005. [ggl+06] h. giese, s. glesner, j. leitner, w. schfer, r. wagner. towards verified model transformations. in in proceedings of modeva workshop associated to models’06. pp. 78–93. 2006. [kks07] f. klar, a. königs, a. schürr. model transformation in the large. in esec/fse’07. acm press, 2007. [npw02] t. nipkow, l. c. paulson, m. wenzel. isabelle/hol a proof assistant for higherorder logic. lecture notes in computer science 2283. springer, 2002. [sbpm07] d. steinberg, f. budinsky, m. paternostro, e. merks. emf: eclipse modeling framework. addison wesley professional, 2007. second edition. [sch08] b. schätz. formalization and rule-based transformation of emf ecore-based models. in dragan gasevic (ed.), software language engineering. lncs. springer, 2008. proc. gt-vmt 2010 12 / 13 eceasst [sch09] b. schätz. prolog emf transformation eclipse-plugin. www4.in.tum.de/ ˜schaetz/pete, 2009. [str08] m. strecker. modeling and verifying graph transformations in proof assistants. electr. notes theor. comput. sci. 203(1):135–148, 2008. [vp04] d. varro, a. pataricza. generic and meta-transformations for model transformation engineering. in baar et al. (eds.), uml 2004. springer, 2004. lncs 3273. 13 / 13 volume 29 (2010) motivation related approaches overview and contribution model structure structure of the model construction predicates list construction compound construction transformation definition transformations as relations transformations as rules verification meta-model formalization transformation formalization proof construction conclusion and outlook process scenarios in open source software certification electronic communications of the easst volume 48 (2011) proceedings of the fifth international workshop on foundations and techniques for open source software certification (operncert 2011) process scenarios in open source software certification fabrizio fabbrini, mario fusani and eda marchetti 15 pages guest editors: luis soares barbosa, dimitrios settas managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst process scenarios in open source software certification fabrizio fabbrini1, mario fusani1 and eda marchetti 2 1 (fabrizio.fabbrini, mario.fusani)@isti.cnr.it, systems and software evaluation centre, isti cnr pisa italy 2 eda.marchetti@isti.cnr.it, software engineering laboratory, isti cnr pisa italy abstract: certification of open source software (oss) presents inherent trade-offs due to the necessity of precisely identifying both a product and an independent certification agent, and on the other of maintain the peculiar, valuable oss characteristic of being available to an unlimited multiplicity of actors for trial, use and change. this is an intriguing challenge, usually solved by removing from the picture the certifying agent and providing an intrinsic certification by means of rigorous, reapplicable property demonstrations, adopting formal methods (fm) in expressing and verifying the code. as such approach, yet quite valuable and good-promising, has some restrictions (such as the limited set of provable product qualities), we propose to tackle the problem by analysing the various processes executed by different oss stakeholders, including the process of an independent certification body. in the paper some kinds of representative scenarios in which such processes interleave are presented and discussed. the aim is to introduce a process-centered perspective for oss that can stimulate research to further understand and mitigate the mentioned trade-offs. keywords: open source software, certification, software process 1 introduction traditionally, software certification has been mainly associated with proprietary software or closed source software (css) with the aim of increasing the confidence that a software-related product or service actually possesses its declared behavioral and/or structural attributes. recently, the increasing adoption of open source software (oss) in new environments, such as public administrations, makes it even more urgent to evaluate the correctness and other software quality attributes, such as reliability and usability, of the software used. indeed, intrinsic product variability, context criticality, compliance to standards and typical constraints of specific domains evidence that certification is still a key factor in adopting oss software. commonly available solutions to this problem try to remove the activity of an independent certifying agent and provide intrinsic certification by means of rigorous demonstrations of software properties by adopting formal methods (fm) in expressing such properties and verifying the code against them. however as pointed out by [wal04], one task is to certify properties of a software item with respect to defined specifications, and another task is to certify related properties of a system (hardware and software) of which the software item is a continuously evolving component. sometimes the whole system is not available, and also when it is, it is not always easy just to express the ”global” properties of a software component (typically detectable as their impact into external system qualities), let alone to verify them. 1 / 15 volume 48 (2011) mailto:(fabrizio.fabbrini, mario.fusani)@isti.cnr.it mailto:eda.marchetti@isti.cnr.it scen. in oss cert. out of the fm, model checking techniques are typically adopted to demonstrate the characteristic of correctness (with sub-characteristics expressed in the form of provable/non-disprovable properties such as liveness and safety). then model checking, now rather feasible and intensively automated, can be used for certification [wal04] (an overview of some proposals is in section 2). however these approaches, rigorous and good-promising (thanks to availability of many tools)as they may be, cannot be extensively adopted because the set of provable product qualities is still limited and depends on the available specifications. moreover a recent survey [hsi10] on ongoing oss projects shows that testing is still almost the only way adopted to check product properties, even if these properties are validated only for the test conditions. from this considerations our proposal wants to tackle the problem by analyzing the various processes executed by different oss stakeholders, including an independent certification body. starting from the assumption that oss products have interesting, although unconventional, common process features that can be taken into account for certification, we introduce in this paper an approach to a sort of formalized view of the oss certification activities. motivated by recent trends in the italian reality of the public administration, that fosters the use of oss in automation of public offices, we want to investigate different related scenarios, evidencing the roles of the playing actors to find possibly standardizable yet feasible conditions that make an oss eligible for certification. we want to focus the reader’s attention on the processes performed during the oss life-cycle to stimulate research towards further understanding and mitigation of the trade-offs between the typical discipline requested by certification and the unconstrained nature of oss that makes it so appealing and objectively valuable. in this process-centered perspective, we show how the long-dated certification concept, gained with conventional products, can be re-defined and applied to the more complex and varying oss scenarios. we therefore highlight some of the oss development process evidences that can be used in a certification process and show that, even inside different scenarios, these processes do have interesting, although unconventional, common features that can be taken into account for product certification. the paper is organized as follows: in section 2, a sample of related literature is commented in the light of our objectives and the typical characteristics of the oss are summarised. in section 3, the concept of certification is re-visited and new evidences are proposed. in section 4, significant oss certification scenarios are presented and commented to point out the role of the main actors, their expected actions and mutual relationships. in section 5 an analysis of the proposed scenario is provided while conclusions are drawn in section 6. 2 related work from the vast literature of oss and certification, we selected some works describing the current trends. as noticed, oss certification is often related to the use of fm [km08] in transforming requirements into code and code into requirements, as it is the case of safety and security related properties [cs08, sc09]. model checking is a further proposed solution, sometimes considered as the most effective technique for oss analysis [cgr09]). alternative proposals are those focused on agile methodologies for keeping consistency between a product and the evidences of the product(for instance [cgr09, mtt09]). proc. opencert 2011 2 / 15 eceasst even though effective, the so far mentioned solutions are limited to specific properties of the oss software and can be dependent on the specifications. the advantages of independent certification management is introduced in [pb08], which suggests also mechanisms for doing it (granting/revoking certificates and performing continuous certification in a vulnerable environment) and enforced in [kks10], where an independent body (in the case, an association of developers and/or users) is expected to provide on-line services to oss component integrators for which a set of tools, also including reverse engineering tools, search engines and analysers, are being produced. however, so far the proposals for independent certification have been rather vague and certification against specific standard is reported as a drawback. in our view, certification can advantageously be performed at various levels and an independent entity, the certification body, can play different roles in its peculiar task of confidence and transfer it among stakeholders. the scenarios we propose try to figure out the various aspects and roles involved in a certification process and address issues for further research. 3 peculiarities of the certification of oss the literature analysis and the experience in product (css) evaluation and process (spice) assessment of our centre [iso08b] help us to highlight some peculiarities of the oss that should be taken into consideration for an oss certification process, typically: availability of usually free or not expensive source; possibility of downloading the oss from a public website; use of a development environment managed by a community of developers/testers/users, that eases rapid code change and re-use; possibility of measuring product characteristics such as correctness, reliability and maintainability. from this picture, the main factors influencing a oss certification process can be summarized as: • stakeholders: users and developers happen to work closely together and the boundaries among the roles become much more indistinct. • requirements specifications: in oss, specifications are not any more controlled by a single organisation and continuously evolve according to the needs of individuals or companies. often they can be collected from various sources such as developers forums or test cases. • verification and testing: oss properties mostly get verified by testing in operational environment, both in case of software component selection, and during actual service. testing before delivery is then only a fraction of the testing process. regarding static verification, we noticed in section 1, about fm techniques, the phenomenon of many proposals in literature and scarcely adopted in practice. moreover, verification of process documents, which in css is one of the best sources of information for a certification body, is only marginal in oss. • independent development: oss can be totally or partially cloned by various developers, also concurrently. this may rise new configuration management problems. 3 / 15 volume 48 (2011) scen. in oss cert. • traceability of products: oss are characterized by high variability and evolution (versioning) of the same product, evidencing some difficulties in identifying the product from its releases. • configuration management: configuration management life-cycle processes are still there ([omk08] and [hsi10]), and their actors are generally geographically distributed. • process-related work products: these are documents such as faqs, annotations, lessons learnt, bug logs, and so on, which evidence the importance and the interest for oss inside the community and the development effort behind the completion of the oss itself. a certification body should learn to deal with these work products instead of the traditional css documentation. from the above characteristics it becomes clear that the certification process is expected to continuously track evolving oss requirements specifications and take evidences from the operational environment. operational testing [l+96], that in css is extremely difficult to manage for cost and time constraints, becomes common practice ([mtt09], [hsi10]) and a precious contribution for improving the overall confidence in the oss product. thus one of the most important role in the assessment part of certification is played by the process-related work products such as blogs, faqs, annotations, bug logs and so on. that source of information can allow monitoring of product maturity, testing activity and properties implementations and is an essential element of the certification process. in particular, such information aimed to improve or decrease confidence about the product properties can be discovered by verification techniques such as dynamic testing, static analysis and model checking. to perform this process-related assessment, traditional document analysis cannot be used and new techniques must be devised, not excluding mining and natural language processing of raw text, as, for example, an evolution of the research proposed in [ysjs07]. certification process could also be influenced by independent development: versioning of the same oss and the different abilities of different developers are factors that can affect the final decision of a certification body. these evidences, as well as any other pieces of information derivable by the current available osi certification [osi08] have to be monitored in a certification process. in particular, due to the dynamic nature of oss products, the natural consequence is that certificates are associated to a certain evolution of the oss, thus related to a specific time and version. to collect the certified versions of the same oss products, while the certification is valid, and to reduce the complexity of the communications among the stakeholders, the concept of a virtual repository can be introduced. interactions with a virtual repository can happen only on a voluntary basis for example to get a (possibly dynamic) certificate. this way, registering an oss project to a virtual certification repository would be appealing and would ease the adoption of the software itself. the analysis of the influencing factors evidences that independent certification need new standards that do not disrupt the characteristic of free development while allowing an oss to be eligible for certification. these new standards should recognize collaborative working environments and propose rules to properly collect process evidence and certified products. proc. opencert 2011 4 / 15 eceasst in table table 1 some differences and similarities between css and oss certification processes are shown. in this partial list, the only significant similarity seems to be cb accreditation. 4 the scenarios context lifecycle aspects for oss certification have been extensively described in literature [tay09]. in this section we provide an attempt at schematizing two different certification scenarios considering, as mentioned in the introduction, the context of the italian public administration (pa) environment. as we cannot validate yet our proposal, representing and analyzing possible certification scenarios seems useful to see how the consequences of the factors mentioned in section 3 can work together. thus even if specific, we think that these domestic situations, once analyzed, can have many points in common with other international environments and can be easily generalized or adapted to any other context. in italy, as in other countries, there is an increasing interest by the central government in adopting oss systems for the development of public projects, in particular in the public administration context, so to keep costs reasonable and accelerate the completion of administrative system projects. however, due to some criticalities of the context and the many standards and constraints specific to the public environment, only certified products are eligible to be integrated or used in the existing systems. thus certification is still recognized as a key factor to persuade the various pa offices to adopt oss solutions. this opens up two possible scenarios: in the first one the pa itself, to assure that oss is compliant with the standards and the required level of quality, commissions the certification to an external certification body (cb)). in the second one, it is thinkable that developers can make available ready-to-use, certified oss to the pa, under the payment of a (perhaps only symbolic) certification fee. in this case even if the developers have to face certification expenses from the cb, they can have incomes from the widespread use of the certified product, as well as from installation and maintenance activity. we schematize the first scenario in section 4.1 where we consider the pa as customer/user stakeholder and the certification ordered to an external certification body, the second scenario is presented in section 4.2 where oss developer(s) would like to take the advantage pushing in the adoption of the oss from the pa, by proposing oss certified products on the market. 4.1 certification scenario: pa triggering the certification process in this section we provide details about a possible scenario in which the pa promotes the certification of an oss product that needs to be integrated in its administrative systems. in particular in figure 1 we schematize the main stakeholders of the scenario to outline their mutual relationships. we suppose the pa uses a public oss repository where developers provide oss (oss source artefacts in the figure) implementing different functionalities. the certification body (cb) has the role to certify, according to pa requests, conformity to applicable standards and quality constraints involved with the selected oss and to maintain a common certified oss repository. with 5 / 15 volume 48 (2011) scen. in oss cert. figure 1: simplified stakeholders scenario with pa no expectations to be exhaustive, a possible interaction between the above mentioned stakeholders during the certification process can be schematized as in figure 2. developers and pa, from different points of view, contribute to the requirement elicitation activity, which basically produces a list of constraints that can vary from operational systems specification to development environment constrains, performance and quality attributes and other more specific requests about the functionalities to be implemented. following the oss philosophy we consider not restrictive to represent the requirements elicitation as a free, open and not ruled activity, where exigencies coming from different actors and environments join together in common, publicly available (possibly textual) documents. the various requirements can then be implemented in parallel into oss product(s) or updated and refined by the pas. as a common practice, the oss repository will contain for each oss product the source code and possibly the oss storyboard, i.e. all the available source of information concerning the released oss (logs, comments, description of functionalities and so on). pa can therefore select from the oss repository the oss product considered eligible for certification and commission to cb the analyses and the management necessary for the certification itself. cb, following the standard procedure, will perform requirement analysis, possibly recovering data defined during the requirements elicitation, and collect all the available oss information (as described in section 3). then the cb can continue the certification activities that, as said in section3, may require further interaction with the developers and with independent verification laboratories. the process, whose requirements are listed in section 5, can produce three principal possible results: 1. cb declares the oss product not eligible for certification; 2. the certification is successfully concluded, with the certified oss transferred into the coss repository and the storyboard opportunely updated; 3. cb identifies required modifications or bugs fixing needs and communicates this to pa proc. opencert 2011 6 / 15 eceasst figure 2: simplified interaction scenario with pa that has commissioned the certification. this in turn can update the oss storyboard and possibly the bug log of the oss repository so that developers can release an improved version of the required system and let the certification restart for a new iteration of course there are variants, still in the perspective of continuous certification ([pb08], [cgr09]): for example, in case of successfully concluded certification, developers may go on independently updating the software, whose evolved version could draw the interest of the same pa or another public / private institution, which would trigger again the certification process. from this simple scenario the following considerations can be drawn: • the stakeholders act rather independently (see section 3), even if they must synchronize on various occasions. the repository itself, a passive entity, acts as a common channel. • cb, differently from all the other stakeholders, is bound to behavioral rules. as we already pointed out, it could (and should) be compliant to severe, even conventional standards, but this does not make its presence in an oss scenario disturbing. this scenario is a rather high-level one, and its representation hides many intermediate steps that would make the complete description quite a job (requirements elicitation, requirements analysis, certification activity and so on) that can be omitted here. 4.2 certification scenario: developer triggering the certification process in this section we provide details about a scenario in which the promoter for the certification of an oss product is the developer. here the main role of pa is to express the user needs and inter7 / 15 volume 48 (2011) scen. in oss cert. est in terms of requirements, while the role of developers is to implement certifiable products. certification of oss against the many standards and constraints specific to the public environment is considered a key factor to convince the various pa offices to adopt already developed oss. as a side effect, the ability to provide accredited products for the pa could be a means for the developers to increase the number of clients and to make profits (for instance from software installation, maintenance or other related activities). the stakeholders in this scenario are the same as in the previous one (figure 1). thus, again pa uses the public oss repository for requirements elicitation and developers are in charge of the oss implementation (oss source artefacts in the figure). on behalf of the developer, and not of pa as in the previous scenario, cb certifies the oss according to pa standards and quality constraints, and maintains a common certified oss repository. it is then possible to suppose that pa can download the certified oss software from the certified repository upon payment of a special symbolic fee. we schematize the interactions between developers, pa and cb during the certification process as shown in figure 3. as in the previous scenario, pa contributes to the requirement elicitation activity, which mainly consists of a list of constraints, quality attributes and/or other more specific requests about the functionalities to be implemented. then the various requirements can be implemented in parallel into oss products for which the source code and possibly the oss storyboard, similarly to the previous scenario, are made publicly available. at this step in the process only the developers who want to certify a version of oss developed product order the certification analysis to the certification body. note that in this case, cb can use possible information about the development process provided by the developer itself. thus, factors that are hardly exploitable in oss certification, such as, for instance, reference standards, life-cycle traditional standards, architectural requirements, or internal quality characteristics can now be used by cb for certification. as a consequence, the cb activity could be closer to that of a traditional css certification process. thus, cb, following the standard procedure, will perform a requirement analysis, integrating data about requirements elicitation (if any), available oss information and additional information provided by developer. then cb can continue the certification process, as described in the previous scenario, directly interacting with developer and possibly with independent verification laboratories. just as before, cb activity can produce three principal possible results: 1) cb declares the oss product not eligible for certification; 2) the certification is successfully concluded, with the certified oss transferred into the coss repository and the storyboard opportunely updated; 3) cb identifies required modifications or bugs fixing and communicates this to the developer that has commissioned the certification. only when the improved version of the required system is developed the certification process will restart for a new iteration. once committed in the certified oss repository, the certified version can be used by developer for its own marketing. the stakeholders of this scenario act more independently than in the previous one, so minimizing the points of synchronization and better reflecting the typical features of oss development. the oss repository is still independently updated upon request of any developers who ask for certification. for exploitation purposes and also for covering the certification expenses, it is proc. opencert 2011 8 / 15 eceasst figure 3: simplified interaction scenario with developer plausible that developers ask each user of the certified repository a symbolic fee. the scenarios have been presented to a rather high abstraction level, purposely avoiding intermediate steps that would disturb viewing of the overall picture of the proposal. 5 comparison and discussion by describing in this paper only two typical oss certification scenarios we intended to provide a first tentative to formalize the necessary steps of a the certification process, considering respectively two different triggering situations: one from the pa side and the other from the developer’s. even if, in the considered scenarios, the overall process shows no development but service only, even a slightly deeper inspection can reveal that process can be composed of various, typically interacting, processes, whose characteristics can be inspired to a process reference model such as in [iso08a]. in particular: the cb process structure includes lifecycle processes such as management (common to all stakeholders), requirements analysis, verification and testing; developer process include a more complete set of lifecycle processes, among which coding; pa process may include requirements elicitation (present also in the other stakeholders), prod9 / 15 volume 48 (2011) scen. in oss cert. uct acquisition and supplier monitoring. all these processes synchronize with each other, also through the oss repository, a passive entity that must have its access rules. it is a very high level synchronization with rather weak coupling features, even less compelling in the second scenario, so no deadlock conditions may occur. so, the overall certification process can be expected to be feasible and repeatable, provided it can rely on consolidate best practices. moreover, it has to be tailorable and able to be monitored even in dynamically evolving situations. indeed, due to the intrinsic characteristics of oss development, certification has to face the typical cactus-like versioning of the same product. as a a consequence, an important requirement emerging from both scenarios is that the certification policy should clearly establish the properties to be certified and the validity limits of the certificate itself. from both scenarios, the need for of an independent certification body, able to assess the quality level and the standard compliance of the source code and possibly of other work products with respect to the pa constraints, emerged clearly. as already noticed, the cb is the only stakeholder that has to comply to strict behavioral rules, such as requirements expressed in [iso04]. the main difference in the situations considered, is represented by the information that cb can use for its activities: in the first scenario (section 4.1) available data are minimal and mainly represented by the process-related work products; in the second one (section 4.2) cb could exploit also evidences about the development process provided by the developer itself. summarizing, cb should be responsible for the following technical activities, that it might also directly/indirectly perform. • assessment and verification of properties declared in a certification scope. specifically for the scenario presented in section 4.1, when little or no reference-model exists, such as quality / performance / functional requirements or expected attributes, the role of cb is more exploration than verification: in this case no certificate may be issued, as is not in case the verifications fail (see figures 2). • witnessed or monitored testing. in particular for the first scenario testing is executed by actors different from cb, such as developers or users. if testing procedures and reports are standardized and automated, then the monitoring part takes less effort by the cb. this could be true also for the second scenario (section 4.2), but the strict collaboration from cb and developer could assure more suitable testing info and make the certification process easier. • independent testing (e.g., executed by an accredited independent laboratory, possibly conformant to iso/iec 17025. this is possible in both the scenarios considered. • code analysis and inspection (possibly executed by reviewers independent of developers) • model checking (based on formal models as a source) and software model checking (based on code as a source). regarding testing, we already observed that in oss most of this activity is focused on operational testing (section 3), that typically can be considered as software validation. finally the two scenarios are different also for the purposes of the certification process. in the first scenario (secton 4.1) certification is a guarantee for the pa that the standards and constraints proc. opencert 2011 10 / 15 eceasst specific to the public environment are not compromised or invalidated by the adoption of a oss software. in the second scenario developers can exploit their certified ability in implementing accredited products for the pa for several beneficial side effects: • developers could increase the possible clients because their certified products can be adopted as a ready-to-use and cheap solution in the numerous pa(s) having the same necessities and constraints. • the certified skill of the developers could be a precious advertisment within the pa communities, and in general for any other oss community, to increase possible orders for different product development. • developers could ask for a symbolic fee for each download from the oss repository of the certified oss. this could refund the developer of the expenses sustained for the certification. • from the adoption of the oss certified product, developers could exploit the possibility of opening a new business market due to product diffusion, installation and maintenance activities. 6 conclusions in this paper we examined the frequently discussed issue of open source software (oss) certification. as our centre has been active in software product verification and process independent assessment since mid 1980’s (both as an applied research activity and a service provided to public administration and privates), but never in oss environment, we believe that this perspective could extend the centre’s scope of activity towards a promising business environment. from the experience gained so far with the centre, we think we know something about the basic nature of certification for traditional closed source (css) software, and we expect that the certification concept should be, in some parts, revised to adapt it to the nature of oss. in this paper we wanted to observe the process aspects of oss certification, because of our experience in process engineering and because the process concept includes more knowledge and practice besides the set of techniques adopted. generally speaking, a process uses its resources, including technology in the aspects of: appropriateness for the purpose, ability of modeling real situations, ability of providing methods of operation, partial/full automation of such methods by means of appropriated tools (to be integrated into the process), related human factors (role specialization, knowledge, training, skill, motivation, again to be integrated into the same process) and ability of successfully deploying the technology in real projects. out of these aspects, we addressed here some issues regarding key-roles behavior. we first re-discussed some aspects of the certification in the light of oss in terms of reference, standards, techniques, practices, role of stakeholders, examining what factors can positively or negatively impact on the main certification goals (section 3), then projected the overall certification process into the single processes executed by some significant stakeholders (developer, certification body and customer in the particular case of public administration) (section 4). 11 / 15 volume 48 (2011) scen. in oss cert. table 1: comparison of css and oss certification process certification process properties, practices and techniques css certification process oss certification process certification process compliant to standards (like iso/iec 17000) achieved through formal cb accreditation achieved through formal cb accreditation analysis and verification of life-cycle process documents, different from source code, such as: requirements, architecture, verification, testing, design reviews, quite feasible and opportune for certification usually not available analysis and verification of life-cycle process documents different from source code such as: field information, forums, blogs, usually not provided and if so, unimportant with respect to traditional lifecycle work products mostly available and useful. needs of some general rules and standards to analysis and verification of source code typically indirect: an assessment of developers’ code verification work direct code verification using inspection tools and reverse engineering close relationship with developers feasible and useful quite loose relationships available, if any: virtual repository can be an indirect relationship continuous certification (multiple versions) difficult and expensive often necessary use of virtual public repository often impossible quite opportune proc. opencert 2011 12 / 15 eceasst we made these processes, together with a passive process ”oss repository”, interact in a couple of possible significant scenarios, representing them as activity diagrams, and analyzed some pros and cons of the scenarios, trying to summarize a set of requirements for the ”oss certification process”. we also pointed out how the process executed by an independent certification body, bound by accreditation duty to follow some rigorous standards, can help to mitigate the trade-off between the intrinsic properties of the oss and the strict rules imposed by certification. we think this can be another, perhaps untried-before way to have a higher-level view of the possible activities playing around oss certification, that might be useful for search for more oss process certification features. we do not claim to be exhaustive in this formulation, nor particularly innovative. the aim of this paper is to introduce a process-centered perspective for oss that can help to understand possible different scenarios and to stimulate related research issues. bibliography [bcf+10] i. biscoglio, a. coco, m. fusani, s. gnesi, g. trentanni. an approach to ambiguity analysis in safety-related standards. in proc. of quatic 2010 (7th international conference on the quality of information and communications technology). september 2010. [bou10] a. boulanger. open-source versus proprietary software: is one more reliable and secure than the other? ibm systems journal 44(2):239–248, 2010. [cgr09] c. comar, f. gasperoni, j. ruiz. open-do: an open-source initiative for the development of safety-critical software. 2009. [cs08] a. cerone, s. a. shaikh. incorporating formal methods in the open source software development process. in proc. of the third international workshop on foundations and techniques for open source software certification. september 2008. [ffl06] f. fabbrini, m. fusani, g. lami. basic concepts of software certification. in proc. of 1st international workshop on software certification (certsoft’06). pp. 4–16. mcmaster university, 2006. [fus09] m. fusani. examining software engineering requirements in safety-related standards. in proc. of dessert (dependable systems, services and technologies). april, 2009. [hsi10] z. hashmi, s. shaikh, n. ikram. methodologies and tools for oss: current state of the practice. in proc. of the third international workshop on foundations and techniques for open source software certification. september 2010. [iso96] iso/iec. iso/iec guide 2:1996, standardization and related activities general vocabulary. iso/iec, 1996. 13 / 15 volume 48 (2011) scen. in oss cert. [iso04] iso/iec. iso/iec 17000: 2004, iso/iec 17000:2004, conformity assessment vocabulary and general principles. iso/iec, 2004. [iso08a] iso/iec. iso/iec 12207 information technology: software life cycle processes. iso/iec, 2008. [iso08b] iso/iec. iso/iec 15504-5:2006 – information technology – process assessment – part 5: an exemplar process assessment model. iso/iec, 2008. [iso08c] iso/iec. iso/iec tr 15504-6:2008 information technology – process assessment – part 6: an exemplar system life cycle process assessment model. iso/iec, 2008. [kks10] g. g. kakarontzas, p. katsaros, i. stamelos. component certification as a prerequisite forwidespread oss reuse. in proc. of the third international workshop on foundations and techniques for open source software certification. september 2010. [km08] a. khoroshilov, v. mutilin. formal methods for open source components certification. in proc. of the third international workshop on foundations and techniques for open source software certification. september 2008. [l+96] m. r. lyu et al. handbook of software reliability engineering. mcgraw-hill new york et al., 1996. [mtt09] s. morasca, d. taibi, d. tosi. towards certifying the testing process of open-source software: new challenges or old methodologies?. in proc. of the 2009 icse workshop on emerging trends in free/libre/open source software research and development. pp. 25–30. ieee computer society, 2009. [om09a] a. ocampo, j. muench. rationale modeling for software process evolution. software process. improvement and practice 14(2):85–105, 2009. [om09b] a. ocampo, j. muench. rationale modeling for software process evolution. volume 14(2). 2009. [omk08] t. otte, r. moreton, h. d. knoell. applied quality assurance methods under the open source development model. in proc. of the 32nd annual ieee international computer software and applications conference. pp. 1247–1252. compsac, 2008. [osi08] osi. osi certified open source software. opensource.org, 2008. [pb08] s. pickin, p. t. breuer. open source certification. in proc. of the third international workshop on foundations and techniques for open source software certification. september 2008. [sc09] s. a. shaikh, a. cerone. towards a metric for open source software quality. in proc. of the third international workshop on foundations and techniques for open source software certification. september 2009. proc. opencert 2011 14 / 15 eceasst [tay09] r. taylor. understanding how oss development models can influence assessment methods. in proc. of the third international workshop on foundations and techniques for open source software certification. march 2009. [tri02] l. tripp. software certification debate: benefits of certification. ieee computer, pp. 31–33, june 2002. [uni] unified modeling language. http://www.uml.org/. [voa00] j. voas. developing a usage-based software certification process. ieee computer 33:32–37, 2000. [wal03] k. c. wallnau. volume iii: a technology for predictable assembly from certifiable components. technical report, sei cmu, april 2003. [wal04] k. c. wallnau. software component certification: 10 useful distinctions. technical report, sei cmu, september 2004. [ysjs07] k. youngjoong, p. sooyong, s. jungyun, c. soonhwang. using classification techniques for informal requirements in the requirements analysis-supporting system. inf. softw. technol. 49:1128–1140, november 2007. 15 / 15 volume 48 (2011) http://www.uml.org/ introduction related work peculiarities of the certification of oss the scenarios context certification scenario: pa triggering the certification process certification scenario: developer triggering the certification process comparison and discussion conclusions exogenous model merging by means of model management operators electronic communications of the easst volume 3 (2006) proceedings of the third workshop on software evolution through transformations: embracing the change (setra 2006) exogenous model merging by means of model management operators artur boronat, josé á. carsı́ and isidro ramos 19 pages guest editors: jean-marie favre, reiko heckel, tom mens managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst exogenous model merging by means of model management operators artur boronat1, josé á. carsı́ 2 and isidro ramos3 1 aboronat@dsic.upv.es, 2 pcarsi@dsic.upv.es, 3 iramos@dsic.upv.es http://issi.dsic.upv.es information systems and computation department technical university of valencia, spain abstract: in model-driven engineering, model merging plays a relevant role in the maintenance and evolution of model-based software. depending on the amount of metamodels involved in a model merging process, we can classify model merging techniques in two categories: endogenous merging, when all the models to be merged conform to the same metamodel; and exogenous merging, when the models to be merged conform to different metamodels. moment (model management) is a framework that is integrated in the eclipse platform, and provides a collection of generic set-oriented operators to manipulate mof models, following the model management discipline. in this paper, we study how model transformations are useful in a model merging process and we provide a solution for both kinds of model merging by means of model management operators and the qvt relations language. keywords: model-driven architecture, model management, exogenous model merging, qvt relations 1 introduction software merging is an essential aspect of the maintenance and evolution of large-scale information systems. information systems can be specified by means of models in model-driven engineering. models collect the information that describes the information system at a high level of abstraction, which permits the development of the application in an automated way using generative programming techniques. the consolidation of the meta-object facility standard [omg04] as a four-layer architecture, where metamodels can be specified as a set of syntactical well-formedness rules to define models, permits the definition of modeling domains where merging processes can be performed. a model merging process can be defined over a metamodel. then, any two well-formed models in this metamodel can be merged. traditionally, the tasks that are involved in this process have usually been solved in an ad-hoc manner for a specific context or metamodel: relational databases [bln86, bdk92], xml schemas [beh00], owl-dl ontologies [hm05] , aspect-oriented modeling [sgs+04], uml models [owk03], etc. [men02] presents a classification of merge approaches, where domain independence and customizability of a generic merge operator to a specific domain are desired features. however, 1 / 19 volume 3 (2006) mailto:aboronat@dsic.upv.es mailto:pcarsi@dsic.upv.es mailto:iramos@dsic.upv.es http://issi.dsic.upv.es exogenous model merging by means of model management operators the definition of metamodels by means of a common metamodeling language (like mof, or any mof-like implementation) is a desired feature that should be preserved on the grounds that it permits the development of generic infrastructures to manipulate models. following this direction, model management [bhp00] is a new emergent discipline that pursues an abstract reusable solution for problems of this kind, independently of the metamodel under study. the model management discipline deals with software artifacts by means of generic operators that do not depend on their internal implementation because they work on mappings between models [ber03]. these operators treat models as first-class citizens and increase the level of abstraction of the solution avoiding programming tasks and improving the reusability of the solution. as stated in [bln86], a model merging process consists of three main phases: a model comparison phase, where elements of different models that are equivalent are found; a consistency checking phase, where conflicts that may appear if we merge equivalent elements are identified, defining a conflict resolution strategy to eliminate them; and a merging phase, where the equivalent elements that are found in the first step are merged taking into account the conflict strategy defined in the second step. generic model merging approaches provide support for these three phases in different ways. [ap03] uses mof identifiers to compare elements in different versions of a same base model. [bp03, bce+06] provide a set of model management operators to define equivalence relationships between elements of different models by means mappings, which are used by a merge operator later on. [kpp06] proposes several domain-specific languages to define model comparison and model merging over metamodels. the model comparison language permits the definition of equivalence relationships between elements of a metamodel that can be applied over elements of the corresponding models afterwards. the model merging language embeds the comparison language so that these equivalence relationships can be used in the merging process. in our approach, we propose a set of model management operators that use the qvt relations language [omg05] to perform model comparison and model transformation. in a model merging process where two models are involved, the comparison phase is achieved by defining relations between elements of the same metamodel. the consistency phase is solved by defining a model transformation that takes the two models to be merged as input models. finally, the merging phase is performed by a generic operator that uses the qvt relations programs defined in the previous phases. thus, we enhance the use of the qvt relations language within the model management field, avoiding the definition of a new dsl for every model management operator. in this paper, we show how this approach can be used by providing an example of exogenous model merging, where the models to be merged conform1 to different metamodels. the structure of the paper is as follows: section 2 presents the exogenous model merging problem; section 3 introduces the modelgen operator for model transformation; section 4 introduces the merge operator for model merging; section 5 provides the solution for the example in section 2; section 6 provides some related works. finally, section 7 summarizes the main contributions of the paper. 1 a model conforms to a metamodel if it is syntactically well-formed by using the constructs of the metamodel. proc. setra 2006 2 / 19 eceasst figure 1: exogenous model merging of a uml model and a relational schema. 2 exogenous model merging scenario when two models are merged, an equivalence relation must be defined between their corresponding metamodels, associating their elements using a set of relationships. these relationships are used to identify equivalent elements in different models in order to avoid duplicated information in the merged model. generic approaches to merge models use this concept of equivalence relation, but they do not usually differentiate between an endogenous and an exogenous model merging. in fig. 1, we provide an example of exogenous model merging: the integration of a uml model and a relational schema. we have used the ecore metamodel [bbm03] as an implementation for the uml class diagram metamodel, and the relational metamodel that appears in the query/view/transformation (qvt) standard specification [omg05]. in fig. 1, the relational schema is shown in a tree-like form. in this paper, we use this example to show that an exogenous model merging process is a generalization of an endogenous model merging process. therefore, it can be broken down into simpler processes, which can be solved by means of model management operators. our approach for solving the example consists of two steps: a model transformation that permits representing the uml model as a relational schema; and a model merging between relational schemas. we present how we deal with model transformation and endogenous model merging in the following sections. 3 the qvt relations language and the modelgen operator in the qvt relations language, a model transformation is defined among several metamodels, which are called the domains of the transformation. a qvt transformation is constituted by qvt relations, which become declarative transformation rules. a qvt relation specifies a relationship that must hold between the model elements of different candidate models. the direction of the transformation is defined when it is invoked by choosing a specific domain as target. if 3 / 19 volume 3 (2006) exogenous model merging by means of model management operators the target domain is defined in the qvt transformation as enforce, a transformation is performed by creating the corresponding elements in the target model. if the target domain is defined as checkonly, just a checking is performed without creating any new element in the target model. both kinds of transformations are used in our approach. a relation can be also constrained by two sets of predicates, a when clause and a where clause. the when clause specifies the conditions under which the relationship needs to hold. the where clause specifies the condition that must be satisfied by all model elements participating in the relation. a transformation contains two kinds of relations: top-level (marked with the top keyword) and non-top-level. the execution of a transformation requires that all its top-level relations hold, whereas non-top-level relations are required to hold only when they are invoked directly or transitively from the where clause of another relation. as example, we have taken the umltordbms transformation that is presented in the mof qvt final specification2. the top relation below specifies the transformation of a class into a table. by means of the where clause, the relation classtotable needs to hold only when the packagetoschema relation holds between the package containing the class and the schema containing the table. by means of the when clause, the classtotable relation holds, the relation attributetocolumn must also hold. top relation classtotable { classname: string; checkonly domain ecoredomain c: eclass { epackage = p:epackage {}, name=classname }; enforce domain rdbmsdomain t: table { schema = s:schema {}, name = classname, column = cl:column { name = classname + ’ tid’, type = ’number’ }, key = k:key { name = classname + ’ pk’, column=cl } }; when { packagetoschema(p, s); } where { attributetocolumn(c, t, classname); } } in moment, a model transformation can be applied to several source models, which may or may not conform to the same metamodel. when the transformation is invoked, it generates one target model and a set of traceability models. a traceability model contains a set of traces 2 in this paper, we are using a version of this transformation in which we consider ecore as an implementation of the uml class diagram metamodel. the version of the transformation that is used is presented in appendix b. proc. setra 2006 4 / 19 eceasst figure 2: traceeability editor in the moment framework. that relate the elements of the source model to the elements of the target model, indicating which transformation rule has been applied to each source element. a qvt relations enforced transformation is executed by means of the modelgen operator as follows: < out put model, trac1, ..., tracn >= modelgen(trans f ormation, input model1, ..., input modeln) where trans f ormation is the name of the qvt transformation; input model1, ..., input modeln are the input models, which may conform to different metamodels; out put model is the generated model; and trac1, ..., tracn are the trace models that are generated for each one of the corresponding input models. fig. 2 presents the traceability editor of the moment framework. this editor shows the trace model that is generated by the umltordbms transformation, when it is applied to the uml model that is defined in fig. 1. this transformation constitutes the first step of the exogenous model merging process. trace models in our framework conform to our traceability metamodel, which was presented in [bcr05]. the traceability editor is constituted by three main frames, the left frame shows an input model of the transformation, the right frame shows the output generated model and the frame in the middle shows the traces that relate elements of the input model to elements of the target model. traces also provide information about the transformation rule (or relation) that has been applied to source elements to generate the corresponding trace and the related target elements. 5 / 19 volume 3 (2006) exogenous model merging by means of model management operators 4 the merge operator the merge operator takes two models as input and produces a third one. if a and b are models that conform to the same metamodel, the application of the merge operator on them produces a model c, which consists of the members of a together with the members of b, i.e. the union of a and b. taking into account that duplicates are not allowed in a model, the union is disjoint. to understand the semantics of the merge operator in our example, we need to introduce two concepts: the equivalence relation, for finding duplicates by comparing models, and the conflict resolution strategy, for integrating them. 4.1 the equivalence relation in an endogenous model merging, an equivalence relation is defined between elements that belong to different models that conform to the same metamodel. to define an equivalence relation among the elements of a model in our approach, the user can use the qvt relation language in the checkonly mode. only checkonly transformations with two domains are accepted in this context. both domains have to refer to the same metamodel in our approach. for the example, we customize the merge operator to merge relational schemas, i.e., models that conform to the rdbms metamodel of appendix a. to do so we use a checkonly qvt transformation whose domains refer to the rdbms metamodel. the user can add a qvt relation for each of the classes that appear in the metamodel when it is desired. such qvt relations act as equivalence relationships that must hold over the elements of two rdbms models. these qvt relations are used in the merging process to check when two elements are equivalent in order to eliminate duplicates. for instance, the following relation can be defined to indicate that two tables are the same if they belong to the same schema and they have the same name by means of the tablename variable3: top relation tableequivalence { tablename: string; checkonly domain rdbmsdomain1 t1: table { schema = s1:schema {}, name=tablename }; checkonly domain rdbmsdomain2 t2: table { schema = s2:schema {}, name=tablename }; when { schemaequivalence(s1, s2); } } where the schemaequivalence is another qvt relation defined within the same transformation, describing when two schema instances are equivalent (for instance, by name). in our approach, this kind of equivalences may involve several instances of two models as in the above example, 3 we have chosen these criteria for the example. nevertheless, they can be customized to a specific metamodel by the user. nothing impedes us to add semantic annotations to the elements of a model and use this information to determine which elements are equals or not. proc. setra 2006 6 / 19 eceasst where table instances and schema instances are used to check whether two tables are equivalent or not. during the merging process, this checkonly transformation permits checking when groups of elements of different models represent duplicate elements so that they will be merged. in a checkonly qvt transformation, helper functions can be defined by using ocl expressions to manipulate and compare names, and to navigate the structure of the corresponding model. thus, the user only has to be aware of the standard qvt relations language and the domain-specific knowledge. 4.2 the conflict resolution strategy during a model merging process, when two software artifacts (each of which belongs to a different model) are supposed to be equivalent, one of them must be erased. their syntactical differences may cast doubt on which should be the syntactical structure for the merged element. here, the conflict resolution strategy comes into play. the conflict resolution strategy is a model transformation that has two input models and one output model, the merged one. the generic semantics of this strategy in our framework consists of the preferred model strategy. when the merge operator is applied to two models, one has to be chosen as preferred (the first argument of the merge operator). in this way, when two groups of elements (that belong to different models) are equivalent due to an equivalence relation, the elements of the preferred model prevail although they may differ syntactically. to refine the merge operator, the conflict resolution strategy can also be customized. during the merging process, when the merge operator finds two duplicates, they should be integrated. this integration involves a transformation process where information of both duplicates may be taken into account to define the merged model. thus, an enforced qvt transformation can be used to customize the conflict resolution strategy in the same way a checkonly qvt transformation is used to customize the generic equivalence relation. a qvt transformation that is used to define a specific conflict resolution strategy has three domains. all of them refer to the metamodel under study (rdbms in our example). the first two domains are defined as checkonly and they only query the two input models of the merge operator. the third domain is defined as enforce and is the one that produces merged elements. in the case study, when we integrate two tables that are equivalent (because they have the same name), we have to integrate their respective columns, primary keys and foreign keys. the following qvt relation is intended to perform this task: top relation tablemerging { tablename: string; checkonly domain rdbmsdomain1 t1: table { schema = s1:schema {}, name = tablename }; checkonly domain rdbmsdomain2 t2: table { schema = s2:schema {}, name = tablename }; enforce domain rdbmsdomain3 t3: table { schema = s3:schema {}, 7 / 19 volume 3 (2006) exogenous model merging by means of model management operators name = tablename }; when { schemamerging(s1, s2, s3); } where { columnmerging(t1, t2, t3); pkmerging(t1, t2, t3); fkmerging(t1, t2, t3); } } where the schemamerging qvt relation, which is invoked in the when clause, ensures that the container schemas of both table instances must be equivalent in order to apply the current relation to the involved tables. the qvt relations that are invoked in the where clause ensure that the merging process will go on by merging columns, primary keys and foreign keys of the involved tables. the enforce qvt transformation that the user defines to customize the conflict resolution strategy is automatically compiled into a modelgen equation as briefly introduced in the previous section 4. 4.3 the merge operator the merge operator takes two models that conform to the same metamodel as inputs. the outputs of the merge operator are a merged model (merged model) and two models of traces (trac1 and trac2) that relate the elements of each input model (model1 and model2) to the elements of the output merged model. the operator is used as follows: < merged model,trac1,trac2 >= merge(model1, model2) the merge operator uses the equivalence relation that is defined for a metamodel to detect duplicated elements between the two input models. when two duplicated elements are found, the conflict resolution strategy is applied to them in order to obtain merged elements, which are then added to the output model. the elements that belong to only one model, without being duplicated in the other one, are copied into the merged model. the two output trace models are automatically generated by the merge operator on the grounds that it reuses the model transformation mechanism that is described in section 3, through the conflict resolution strategy. these trace models provide full support for keeping traceability between the input models and the new merged one. the second step of the exogenous model merging in the example constitutes a merging process that involves the model rdbms’ and the model rdbms. the model rdbms’ is the result of applying the umltordbms transformation (defined in appendix b) to the model uml that is defined in fig. 1, as explained in section 3. the model rdbms is provided in fig. 1. in fig. 3, we show the trace model that is generated during this merging process for the rdmbs’ model (shown in the left frame of the editor). the model that appears in the right frame of the editor is the final merged relational schema. 4 more information about the semantics of the merge operator can be found in [bcrl06] proc. setra 2006 8 / 19 eceasst figure 3: trace model that is produced during the merging of the models rdbms’ and rdbms. 5 exogenous model merging in moment the exogenous model merging problem consists in the merging of two models that conform to different metamodels, as in the example in section 2. this problem can be divided into simpler ones that can be solved by two simple model management operators. a composite operator, called exogenousmerge, can be defined for this purpose by composing the merge operator and the modelgen operator. this operator has three arguments: the model a, which conforms to the metamodel mma (the ecore metamodel in our example); the model b, which conforms to the metamodel mmb (the rdbms metamodel in our example); and the name of the qvt transformation that must be defined between between the metamodels mma and mmb (umltordbms in our example). in the first step, model a is transformed into a model b’, which conforms to the metamodel mmb by means of the operator modelgen. this step has been performed in section 3. in the second step, models b and b’ are merged within the metamodel mmb. this step has been performed in section 4. finally, the merged model result is the output of the composite operator. the definition of the exogenousmerge composite operator is as follows: operator exogenousmerge (a : mma, b : mmb, t : transformation) = b′ > = modelgen(t, a) (1) b′ , mapa−>b> = merge (b’, b) (2) return (result) the exogenousmerge operator is defined independently of any metamodel so that it can be reused to merge two models that conform to any metamodel. in this example, we have not 9 / 19 volume 3 (2006) exogenous model merging by means of model management operators taken into account the trace models that are generated by the modelgen and merge operators. nevertheless, another version of the operator could generate traceability models as result of the exogenousmerge operator. figure 4: application of the exogenousmerge operator to the example in section 2. fig. 4 graphically represents the merging process that is performed by the operator exogenousmerge for solving the example that is shown in section 2. in the example, parameter a corresponds to the uml model and parameter b corresponds to the rdbms model in fig. 4. to be able to apply the operator, the equivalence relation for the rdbms metamodel and the transformation function between the uml and the relational metamodels must be previously defined by the user. 6 related work generic model merging approaches take into account the phases that were discussed in [bln86] to merge database schemas. these approaches can be differentiated by the mechanism that is used to perform model comparison. [ap03] uses mof identifiers to compare elements in different versions of a same base model. although this approach is effective, only versions of a same base model can be compared and merged. [bp03, bce+06] provide a set of model management operators to define equivalence relationships between elements of different models by means of mappings, which are used by a merge operator later on. in this approach, the merge operator receives two models (a and b) and a mapping model (mapab) between them as inputs, and it produces the merged model c and two new mapping models (mapac and mapbc): = merge (a, b, mapab). in the amma platform [fj05], the generic model weaver amw is a tool that permits the definition of mapping models (called weaving models) between mof models in the atlas proc. setra 2006 10 / 19 eceasst model management architecture. amw provides a basic weaving metamodel that can be extended to permit the definition of complex mappings. these mappings are usually defined by the user, although they may be inferred by means of heuristics, as in [mbr01]. these mapping models are used, together with the mapped models in a model transformation to perform a model composition. in moment, mapping models are introduced as trace models that are generated by model management operators. this is because operators do not have to rely on them to be applied to a set of models. in moment, mappings between the elements of two models are defined between the elements of their corresponding metamodels by means of checkonly qvt relations. this permits a clearer specification of composite operators. trace models are produced by the application of a simple operator to a set of models and keep information about the manipulation task that has been performed to a model. [kpp06] proposes several domain-specific languages to define model comparison and model merging over metamodels. the model comparison language enhances the definition of equivalence relationships between elements of a metamodel that can be applied over the elements of the corresponding models afterwards. in this language, a differentiation between matching and conformance is provided. while a matching mapping indicates when two elements are equivalent, a conformance mapping indicates when two elements are equivalent and consistent to be merged. in this approach, when an equivalence relationship based on names is used, two elements do not conform to each other if they have different types, for instance. in our approach, we use the qvt relations language to perform model comparison and model transformation. this feature aims at decreasing the learning curve of our framework since there is only one language, which has been specified as an standard. the qvt relation language does not provide such a differentiation between conformance and matching. since two elements that do not conform to each other are usually interpreted as an error, we collapse the conformance and matching conditions in a relation. however, a transformation with conformance relations could be defined for a specific metamodel. then, this transformation could be specialized with user-defined checkonly relations for defining equivalence relationships. 7 conclusions model merging plays a relevant role in the maintenance and evolution of model-based software. systems of this kind are usually represented by models that conform to different metamodels. thus, two kinds of merging processes arise by considering the amount of metamodels that are involved: endogenous merging and exogenous merging. in an endogenous merging process, the models that are merged conform to the same metamodel. in an exogenous merging process, the models that are merged conform to different metamodels. the moment framework is a model management framework that provides operators to manipulate models on top of a mof architecture, such as merge for model merging and modelgen for model transformations. in our approach, model management operators are defined independently of any metamodel, keeping a generic infrastructure, but they might be customized by an expert user with domain-specific knowledge by means of standard languages, such as ocl and qvt. 11 / 19 volume 3 (2006) exogenous model merging by means of model management operators in this paper, we have presented how model transformations are supported in moment through the qvt relations language and how model transformations play an important role in a model merging process. we have used the standard qvt relations for this purpose instead of providing new languages for model comparison and model merging. to study the aforementioned kinds of model merging, we have described a solution for an endogenous model merging process by using model transformations through the merge operator. finally, we have provided a generic solution for exogenous model merging by reusing model transformations and endogenous model merging. acknowledgements: this work was supported by the spanish government under the national program for research, development and innovation, dynamica project tic 2003-07804-c05-01. we are grateful to abel gómez, pascual queralt, joaquı́n oriente and luis hoyos for their effort in the development of the moment framework. bibliography [ap03] m. alanen, i. porres. difference and union of models. in stevens et al. (eds.), uml 2003 the unified modeling language. model languages and applications. 6th international conference, san francisco, ca, usa, october 2003, proceedings. lncs 2863, pp. 2–17. springer, 2003. [bbm03] f. budinsky, s. a. brodsky, e. merks. eclipse modeling framework. pearson education, 2003. [bce+06] g. brunet, m. chechik, s. easterbrook, s. nejati, n. niu, m. sabetzadeh. a manifesto for model merging. in gamma ’06: proceedings of the 2006 international workshop on global integrated model management. pp. 5–12. acm press, new york, ny, usa, 2006. [bcr05] a. boronat, j. a. carsı́, i. ramos. automatic support for traceability in a generic model management framework. in hartman and kreische (eds.), model driven architecture foundations and applications, first european conference, ecmda-fa 2005, nuremberg, germany, november 7-10, 2005. lecture notes in computer science 3748, pp. 316–330. springer, 2005. [bcrl06] a. boronat, j. a. carsı́, i. ramos, p. letelier. formal model merging applied to class diagram integration. electr. notes theor. comput. sci., 2006. [bdk92] p. buneman, s. b. davidson, a. kosky. theoretical aspects of schema merging. in extending database technology. pp. 152–167. 1992. [beh00] r. behrens. a grammar based model for xml schema integration. lecture notes in computer science 1832:172, 2000. proc. setra 2006 12 / 19 eceasst [ber03] p. a. bernstein. applying model management to classical meta data problems. in proceedings of the 1st biennial conference on innovative data systems research (cidr). 2003. [bhp00] p. a. bernstein, a. y. halevy, r. a. pottinger. a vision for management of complex models. sigmod record (acm special interest group on management of data) 29(4):55–63, 2000. [bln86] c. batini, m. lenzerini, s. b. navathe. a comparative analysis of methodologies for database schema integration. acm comput. surv. 18(4):323–364, 1986. [bp03] p. a. bernstein, r. a. pottinger. merging models based on given correspondences. in proceedings of the 29th vldb conference. berlin, 2003. http://www.cs.washington.edu/homes/rap/publications/pottinger-bernstein-vldb03. pdf [fj05] m. d. d. fabro, f. jouault. model transformation and weaving in the amma platform. in pre-proceedings of the generative and transformational techniques in software engineering (gttse’05), workshop. pp. 71–77. centro de ciências e tecnologias de computaao, departemento de informatica, universidade do minho, braga, portugal, 2005. [hm05] p. haase, b. motik. a mapping system for the integration of owl-dl ontologies. in ihis ’05: proceedings of the first international workshop on interoperability of heterogeneous information systems. pp. 9–16. acm press, new york, ny, usa, 2005. [kpp06] d. s. kolovos, r. f. paige, f. a. polack. model comparison: a foundation for model composition and model transformation testing. in gamma ’06: proceedings of the 2006 international workshop on global integrated model management. pp. 13–20. acm press, new york, ny, usa, 2006. [mbr01] j. madhavan, p. a. bernstein, e. rahm. generic schema matching using cupid. in proc. vldb 2001. pp. 49–58. 2001. http://www.research.microsoft.com/research/db/modelmgt/cupidvldb01.pdf [men02] t. mens. a state-of-the-art survey on software merging. ieee transactions on software engineering 28(5):449–462, 2002. [omg04] omg, object management group. meta object facility (mof) 2.0 core specification (ptc/04-10-15). 2004. http://www.omg.org/cgi-bin/doc?formal/2006-01-01 [omg05] omg, object management group. mof 2.0 qvt final adopted specification (ptc/0511-01). 2005. http://www.omg.org/cgi-bin/doc?ptc/2005-11-01 13 / 19 volume 3 (2006) http://www.cs.washington.edu/homes/rap/publications/pottinger-bernstein-vldb03.pdf http://www.cs.washington.edu/homes/rap/publications/pottinger-bernstein-vldb03.pdf http://www.research.microsoft.com/research/db/modelmgt/cupidvldb01.pdf http://www.omg.org/cgi-bin/doc?formal/2006-01-01 http://www.omg.org/cgi-bin/doc?ptc/2005-11-01 exogenous model merging by means of model management operators [owk03] d. ohst, m. welle, u. kelter. differences between versions of uml diagrams. in esec/fse-11: proceedings of the 9th european software engineering conference held jointly with 11th acm sigsoft international symposium on foundations of software engineering. pp. 227–236. acm press, new york, ny, usa, 2003. [sgs+04] g. straw, g. georg, e. song, s. ghosh, r. b. france, j. m. bieman. model composition directives. in uml. pp. 84–97. 2004. proc. setra 2006 14 / 19 eceasst a rdbms metamodel figure 5: rdbms metamodel. b an ecore to rdbms transformation by means of the qvt relations language transformation umltordbms(ecoredomain:ecore, rdbmsdomain:rdbms) { key schema {name}; key table {schema,name}; key column {owner,name}; key foreignkey {owner,name}; top relation packagetoschema { packagename: string; checkonly domain ecoredomain p:epackage { name=packagename }; enforce domain rdbmsdomain s:schema { name=packagename }; }//end packagetoschema top relation classtotable { classname: string; 15 / 19 volume 3 (2006) exogenous model merging by means of model management operators checkonly domain ecoredomain c: eclass { epackage = p:epackage {}, name=classname }; enforce domain rdbmsdomain t: table { schema = s:schema {}, name = classname, column = cl:column { name = classname + ’ tid’, type = ’number’ }, key = k:key { name = classname + ’ pk’, column=cl } }; when { packagetoschema(p, s); } where { attributetocolumn(c, t, classname); } }//end classtotable relation attributetocolumn { checkonly domain ecoredomain c:eclass {}; checkonly domain rdbmsdomain t:table {}; primitive domain prefix:string; where { primitiveattributetocolumn(c, t, prefix); superattributetocolumn(c, t, prefix); } }//end attributetocolumn relation primitiveattributetocolumn { attributename, columnname, sqltype: string; checkonly domain ecoredomain c:eclass { eattributes = a:eattribute {} }; checkonly domain rdbmsdomain t:table {}; primitive domain prefix:string; where { proc. setra 2006 16 / 19 eceasst primitiveattributetocolumneattributes(a,t,prefix); } }//end primitiveattributetocolumn relation primitiveattributetocolumneattributes { attributename, columnname, ecoretypename, sqltype: string; checkonly domain ecoredomain a:eattribute { name = attributename, etype = ecoretype: edatatype { name = ecoretypename } }; checkonly domain rdbmsdomain t:table{}; enforce domain rdbmsdomain cl:column { name = ( if (prefix = ”) then attributename else prefix + ’ ’ + attributename endif ), type = primitivetypetosqltype(ecoretypename), owner = t }; primitive domain prefix:string; when { isprimitivedatatype(ecoretypename); } }//end relation relation superattributetocolumn { checkonly domain ecoredomain c: eclass { esupertypes = sc:eclass {} }; checkonly domain rdbmsdomain t:table {}; primitive domain prefix: string; where { attributetocolumn(sc, t, prefix); } } top relation assoctofkey { 17 / 19 volume 3 (2006) exogenous model merging by means of model management operators srctbl, desttbl: table; pkey: key; referencename, sourceclassname, targetclassname: string; checkonly domain ecoredomain ref: ereference { name = referencename, econtainingclass = sc:eclass { name = sourceclassname }, etype = tc:eclass { name = targetclassname } }; enforce domain rdbmsdomain fk:foreignkey { name = sourceclassname + ’ ’ + referencename + ’ ’ + targetclassname, owner = srctbl, column = fkc:column { name = sourceclassname + ’ ’ + referencename + ’ ’ + targetclassname + ’ tid’, type = ’number’, owner = srctbl }, refersto = obtainreferredprimarykey(desttbl) }; when { classtotable(sc, srctbl); classtotable(tc, desttbl); } } function obtainreferredprimarykey(table: table):key { table.key } function isprimitivedatatype(datatype: string):bool { ((datatype = ’eint’) or (datatype = ’eboolean’) or (datatype = ’estring’) or (datatype = ’edate’)) } function primitivetypetosqltype(primitivetype:string):string { if (primitivetype=’eint’) then ’number’ else if (primitivetype=’eboolean’) proc. setra 2006 18 / 19 eceasst then ’boolean’ else ’varchar’ endif endif } function isdirectedreference(ref:ereference):bool { (ref.eopposite -> size() = 0) } } 19 / 19 volume 3 (2006) introduction exogenous model merging scenario the qvt relations language and the modelgen operator the merge operator the equivalence relation the conflict resolution strategy the merge operator exogenous model merging in moment related work conclusions rdbms metamodel an ecore to rdbms transformation by means of the qvt relations language conformance testing of cyber-physical systems: a comparative study electronic communications of the easst volume 70 (2014) proceedings of the 14th international workshop on automated verification of critical systems (avocs 2014) conformance testing of cyber-physical systems: a comparative study morteza mohaqeqi, mohammad reza mousavi and walid taha 16 pages guest editors: marieke huisman, jaco van de pol managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst conformance testing of cyber-physical systems: a comparative study morteza mohaqeqi1, mohammad reza mousavi2 and walid taha3 ∗ 1 m.mohaqeqi@ut.ac.ir school of electrical and computer engineering, university of tehran, iran center for research on embedded systems, halmstad university, sweden 2 m.r.mousavi@hh.se center for research on embedded systems, halmstad university, sweden 3 walid.taha@hh.se center for research on embedded systems, halmstad university, sweden rice university, usa abstract: for systematic and automatic testing of cyber-physical systems, in which a set of test cases is generated based on a formal specification, a number of notions of conformance testing have been proposed. in this paper, we review two existing theories of conformance testing for cyber-physical systems and compare them. we point out their fundamental differences, and prove under which assumptions they coincide. keywords: hybrid systems, conformance testing, (hybrid) timed state sequences, and hybrid labeled transition systems. 1 introduction cyber-physical systems are “integrations of computation, networking, and physical processes” [1]. such systems are interdisciplinary by their nature and hence, experts from different disciplines have brought in different techniques for their specification, design, and analysis. this enables cross-fertilization of approaches among several disciplines but to achieve that, it requires reconciliation among the different techniques. model-based testing of cyber-physical systems is a relatively new concept that has been studied by few researchers from different backgrounds, e.g., regarding the integration of discrete and continuous dynamics (i.e., the so-called hybrid systems) models for testing [bk06, vo06, vo09, abw09, bwa10, dan10, wlt13, ahf+14, afm14] and considering (asynchronous) networked systems and models and hence such a reconciliation has yet to take place. two notable examples of model-based testing theories for these systems in the literature are: the hioco relation by van osch in [vo06, vo09] and the conformance relation by abbas et al. in [ahf+14], which we refer to as hconf. (note that both approaches focus on the hybrid systems modeling aspect of cyber-physical systems and do not address their distributed and networked ∗ this author was supported by the us nsf cps award 1136099. 1 / 16 volume 70 (2014) mailto:m.mohaqeqi@ut.ac.ir mailto:m.r.mousavi@hh.se mailto:walid.taha@hh.se conformance testing of cyphy systems nature; for the latter, see, e.g., [ww09, sp10, nkm+14] .) the hioco theory is based on hybrid transition systems formalism, which allows to specify both discrete input and output actions, and continuous behavior. on the other hand, under hconf, the conformance relation is considered as a measure of distance between the observable discretized (sampled) behavior of systems. these two approaches are substantially different since they stem, respectively, from the computer scienceand control theory point of view on model-based testing. our general goal of research is to come up with a notion that reconciles these two views, and we start with a formal and in-depth comparison. concerning the specific research question addressed in this paper, we were mainly intrigued by the following statement from [ahf+14]: it can be verified that the hioco relation by van osch is an exact version of (t,j,(τ,ε))closeness (τ = ε = 0) with the role of inputs and outputs made explicit. we aimed at formalizing and proving this claim. (note that “the exact version of (t,j,(τ,ε))closeness” is what we call “hconf” in the remainder of this paper.)1 however, even if we set aside the issue of explicit input and output, it turns out there are other fundamental differences between the two notions that went unnoticed in this statement. hence, we will first point out the main differences between the two notions (which will also guide our future research in reconciling them) and subsequently, seek a restricted setting in which the above-mentioned claim does hold. we then formalize and prove the above-mentioned statement in this restricted setting. as a common ground for our comparison, we use a restricted subset of hybrid automata, of which the restrictions are given and motivated in the remainder of this paper. we then translate this subset into the semantic domains of the two notions of conformance and show that the notions of conformance for the translated hybrid automata coincide in both domains. 1.1 running example we consider a bouncing ball as a simple example of a system exhibiting both continuous and discrete behavior. the ball is dropped with an initial height and an initial velocity. naturally, it is under the force of gravity. however, a vertical force can also be applied to the ball, which is considered as the input to this system. collision with the floor leads to a bounce, which causes the ball to move in the reverse direction with the speed reduced by a factor ρ . the movement of the ball between two consecutive collisions is accounted as a continuous behavior, while the collision with the floor is considered a discrete jump. we can use a hybrid automaton to formally specify the behavior of the ball. we define three continuous variables h, v, and a for specifying the behavior of the ball, where h denotes the height, v denotes the vertical velocity, and a is the (vertical downward) acceleration caused by the force exerted on the ball. consequently, the dynamics of this system can be captured by a hybrid automaton with one location, as shown in fig. 1a. the dynamics associated to this location is specified as ḣ = v and v̇ =−g−a, where g is the gravity constant. figure 1b shows the behavior of the system, starting with initial condition h = 5 and v = 2, while no vertical force is applied to the system. 1 informally, two observed behavior satisfy (t,j,(τ,ε))-closeness relation if in each interval of length τ , there exists one point in each of them with difference less than ε . proc. avocs 2014 2 / 16 eceasst l0 ḣ = v v̇ =−g−a guard : { h = 0 v ≤ 0 reset : { h+ = 0 v+ =−ρ v (a) hybrid automaton 0 2 4 6 8 0 5 10 15 20 0 1 2 3 4 5 6 7 8 jumps f 3 f 2 time f 1 h e ig h t (h ) (b) a sample behavior of the ball figure 1: bouncing ball example 1.2 related work in the realm of model-based conformance testing, tretmans proposed the theory of input/output (i/o) conformance (ioco) testing for discrete event systems [tre96]. afterwards, this theory was extended to real-time systems [bb05], where in addition to discrete states of the system, the evolution of a continuous variable, namely time, is modeled. conformance testing for cyber-physical systems (of which formal models are called hybrid systems in this paper), also, has been approached by a relatively small number of studies. in addition to the two aforementioned studies [vo06] and [ahf+14], which will be explained in detail in the next sections, conformance testing of hybrid systems using some notion of overapproximation has been proposed in [abw09] and [bwa10]. these studies exploited a qualitative reasoning in order to obtain a discrete representation (abstraction) of a hybrid system. in a qualitative system, the continuous domains are abstracted into finite sets of quality levels and intervals. they proposed a method for obtaining a qualitative transition system from a hybrid system, which provides a discrete-event view to the system. then, the ioco relation is applied to the obtained transition system. while this approach leads to finite representation of the hybrid system, it suffers from information loss occurred in the abstraction step. bringmann et al. [bk06] used stream-processing functions [ms97] for specifying test cases for hybrid systems. in this formalism, the continuous behavior of the variables is captured by the notion of streams. a stream-processing function or component relates a stream on input variables to a stream of output ones. based on this notion, they propose a language for describing the test sets. they focus on how to specify test cases for hybrid systems. however, they provide no formal definition for conformance relation of hybrid systems. in addition, woehrle et al. [wlt13] investigated the problem of conformance testing of cyberphysical systems through measurement of a number of physical quantities like power consumption of the computing system. they employed timed automata to specify the system behavior. then, the measured physical variable is compared against the automata to verify that if the system behavior conforms to its specification. their method does not actually model the hybrid behavior of a system, but only considers time as a continuous variable. a conformance rela3 / 16 volume 70 (2014) conformance testing of cyphy systems tion for hybrid systems has been also defined based on the notion of hybrid automata in [dan10]. while the underlying formalism is different from the hybrid labeled transition system that is used by van osch [vo06], the semantic model of the two conformance relations is similar [dan10]. 1.3 paper organization the remainder of this paper is structured as follows. in section 2, we review the hioco and hconf theories and point out the fundamental differences both between their semantic models and their conformance relations. in order to show the equivalence of the two conformance relations under specific assumptions, we first provide a method for translating a given hybrid automaton (in the restricted semantic domain) to each of the models in section 3. then, in section 4, we show that, based on the proposed translation method, the two notions of conformance coincide. the paper concludes in section 5, where we also describe our plan for future work. 2 formal definitions and fundamental differences in this section, we first formally introduce system models that are used in the two aforementioned approaches, namely [vo06] and [ahf+14]. afterwards, we point out the fundamental differences in their modeling approach and their assumptions. these will motivate the assumptions that we have made to pave the way for a meaningful comparison between the two conformance relations. then, we review the conformance relations proposed by the two studies, and state the fundamental differences between them. 2.1 formal models in the following, we first introduce some basic definitions. then, we formally specify the system models employed in [vo06] and [ahf+14], namely, hybrid labeled transition system and hybridtimed state sequence model, respectively. 2.1.1 basic definitions a hybrid system is a system exhibiting both continuous and discrete behavior. the continuous behavior of the system is captured by the valuation of a set of continuous variables, denoted by v . we assume that v is partitioned into a set of input variables, denoted by vi , and a set of output variables, denoted by vo. a valuation on v is defined as a function which assigns a value to each variable v ∈ v ; here, only variables of type real are considered. the set of all valuations of v is denoted by val(v ) and is defined as the set of all functions v → r. to describe the (non-interrupted) continuous evolution of the system, we use the following notion of trajectory [lsv03]. definition 1 (trajectory [vo06]) let d ⊂r be an interval (here, singleton sets of numbers are also considered as intervals). a trajectory σ is a function σ : d→val(v ) that maps each element in interval d to a valuation. the set of all trajectories associated to v is denoted by trajs(v). proc. avocs 2014 4 / 16 eceasst beside continuous evolution, a hybrid system features discrete changes, called jumps or switches. a jump happens instantly, leading to a possibly noncontinuous change. further, we consider a restriction operator on the functions as follows. definition 2 (function restriction) consider an interval d ⊂ r, a set v of variables, and a function f : d → val(v ); we define the restricted function f ↓v ′ for some v ′⊆v as the function of type d → val(v ′), such that for each d ∈ d, f (d) ↓ v ′ is obtained from f (d) after removing variables not in v ′. 2.1.2 hybrid labeled transition system in the approach adopted by van osch [vo06], a hybrid system is modeled as a hybrid labeled transition system (hlts). an hlts, formally defined below, consists of a set of states with discrete (action) and continuous (trajectory) transitions between them. actions are partitioned into three classes, namely, input-, output-, and internal actions. the latter class is not observable from outside. definition 3 (hybrid labeled transition system [vo06]) a hybrid labeled transition system (hlts) h, over a given set a of actions, is a 5-tuple (s,s0,v,l,→), where • s is a (possibly infinite) set of states; • s0 ∈ s is the initial state; • v = vi ]vo is a set of (resp. input or output) continuous variables; • l = a]trajs(v) is a set of (resp. action or trajectory) labels; • →⊆s×(l∪{ξ})×s specifies the transition relation, where ξ denotes the internal action. we may write s l→ s′ instead of (s,l,s′)∈→. moreover, we define a notion of generalized transition relation for an hlts as follows. for the purpose of this paper, we assume the set of actions to be empty. we will also henceforth simplify the definitions for this restricted subset of hltss. definition 4 (generalized transition relation) consider an hlts h = (s,s0,v,l,→). a generalized transition relation for h is defined as the smallest relation ⇒⊆ s×(l)∗×s where • s ε⇒ s; • if s ξ → s′, then s ε⇒ s′, • ∀l ∈ l, if s l→ s, then s l⇒ s; • ∀α,β ∈ l∗, if s α⇒ s′′ and s′′ β ⇒ s′, then s α β ⇒ s′; we write s α⇒ to denote that there exists a s′ ∈ s such that s α⇒ s′. the behavior of a system is specified by its set of traces, which are finite sequences of trajectories. (the internal actions are abstracted away in the traces.) 5 / 16 volume 70 (2014) conformance testing of cyphy systems definition 5 (trace) for hlts h, a trace is a finite sequence α ∈ l∗ such that s0 α⇒, where s0 is the initial state of h. the length of a trace is defined as the number of elements of the sequence and is represented by |α|. we denote the set of all traces of h by traces(h). example 1 consider the bouncing ball example. collision with the floor can be considered as an internal action. also, the curves f1, f2, and f3 in fig. 1b denote some trajectories of the system (projected only to one variable h). hence, the sequences f1 f2 and f1 f2 f3 are two traces of this system. an hlts can be input-enabled, as defined in the following. definition 6 (input-enabled hlts) an hlts is input-enabled if ∀s ∈ s,∀τ ∈ trajs(vi) : ∃τ′ ∈ trajs(v ) such that τ′ ↓vi = τ ∧s τ ′ ⇒. 2.1.3 timed state sequence (tss) model the approach proposed in [ahf+14] specifies a hybrid system as a mapping from pairs of initial conditions and input signals to output signals. the input and output signals of the system are described through a notion of timed-state sequence (tss). (we slightly adapt the notation to make it consistent among the different semantic models.) definition 7 (hybrid-timed state sequence (tss) [ahf+14]) consider n ∈n, t = r≥0×n, and a set of variables v . a hybrid-timed state sequence (tss) is defined as pair (x,σ), where x ∈ (val(v ))n and σ ∈tn . the i th element of a tss (x,σ) is denoted by (xi,σ i), where σ i=(ti, ji)∈ t. also, we denote the set of all tsss defined over the set of variables v , considering a specific n ∈n, by tss(v,n). a tss describes the valuation of a set of (input/output) variables in a finite number of time instants. in this notion, a time instant is denoted by a pair (t, j), where t is a real number denoting the real time, and j is an integer which denotes the number of discrete jumps until that time instant. we refer to this semantic model as the tss model. example 2 the sequence ((1,1,1),((0,0),(4.5,0),(6,1))) is a tss for the running example, defined for the variable a, where the tuple (1,1,1) denotes the value of a in three time instants (0,0),(4.5,0), and (6,1). for instance, the pair (6,1) shows the instant that real time is 6 and the system has experienced one discrete jump. similarly, the sequence ((5,6.55,7.1,6.65,5.2,2.75,0.19),((0,0),(1,0),(2,0),(3,0),(4,0),(5,0),(6,1))) denotes an output tss for the considered system, denoting a valuation of the output variable h. assume a set of input variables vi with a corresponding compact set of possible values val(vi) and a set of output variables vo with a set of possible valuations val(vo). accordingly, the set of proc. avocs 2014 6 / 16 eceasst input tsss and output tsss can be respectively defined by tss(vi,n) and tss(vo,n). also, let h be the set of initial conditions. a hybrid system can be viewed as a mapping between the initial condition and the input tsss (u,σu)∈tss(vi,n) to the output tsss (y,σy)∈tss(vo,n). definition 8 (hybrid system [ahf+14]) hybrid system h is modeled as a mapping: h : h ×tss(vi,n) 7→tss(vo,n) we write yh(h0,(u,σu)) to denote the output tss to which the pair (u,σu) is mapped by h, considering h0 as the initial condition. in [ahf+14], it is assumed that the system is always input-enabled, with the following definition of input-enabledness. definition 9 (input-enabled system) a hybrid system h is input-enabled if ∀h0 ∈ h,∀(u,σu)∈tss(vi,n) : ∃(y,σy)∈tss(vo,n) such that (y,σy) = yh(h0,(u,σu)). in other words, the system is input-enabled if it produces an output for every initial condition and input tss. 2.2 differences in semantic models the following list provides an overview of the fundamental differences among the two underlying semantic models, reviewed in subsection 2.1. after explaining each difference, we state the assumption we have made for the common semantic domains that makes a meaningful comparison possible. • explicit discrete interactions vs. unlabeled jumps. in hltss, an explicit notion of input/output actions is introduced, while tsss provide no explicit means for modeling discrete input/output actions of the system. in order to have a unified semantic model for the two models, we do not consider explicit interactions in hltss and model all discrete jumps of the system as internal actions when using hltss. (a1) • partial specifications vs. input-enabled models. hltss used for hioco allow for partial specifications, in which the (output) response to certain (input) traces is left unspecified. however, the input-enabledness assumption made in the tss model implies that for every sequence of input signal, the model should specify an output behavior of the system, expressed in terms of an output tss. to allow for a meaningful comparison, we only consider input-enabled models. (a2) • unique initial state vs. arbitrary initial condition. hltss specify a unique initial state, while tsss allow for arbitrary initial conditions. in order to make the two models compatible, we assume a singleton set of initial condition for the tss model. (a3) • nondeterministic specifications vs. deterministic models. hltss allow for non-deteminism both in the discrete and the continuous behavior, as an abstraction mechanism for unspecified / irrelevant details. however, hybrid systems in the hconf model are mappings from input tsss to output tsss and hence, are deterministic in nature. to make the comparison possible, we only consider deterministic models. (a4) 7 / 16 volume 70 (2014) conformance testing of cyphy systems • continuous trajectories vs. discretized samples. hltss allow for specification of continuous trajectories while hybrid systems in the hconf theory are necessarily discretized. this alone may not be a major issue (i.e., hioco is also defined for discretized samples in [vo09, chapter 6]); however, in combination with determinism and input-enabledness this assumption has far-reaching consequences, namely, if two continuous input trajectories have the same discretized behavior for one arbitrary sampling, they should lead to the same output behavior. to make the comparison feasible, we assume the latter property in the models studied in the remainder of this paper. (a5) considering these differences one comes away with the impression that the two models have distinct purposes and strengths. in particular, hltss as the semantic models of hioco are suitable for high-level partial specifications that leave some room for future design decisions and also only specify certain aspects of the system. however, tsss used as the semantic models of hconf are suitable for low level specifications that provide a complete and deterministic (discretized) recipe for implementation. an ideal notion of conformance, in our view, should relax assumptions (a1)-(a5). in other words, an ideal theory of conformance should combine the liberal semantic domain of hioco with the practical conformance relation of hconf, as pointed out in the next section. 2.3 conformance relations in this subsection, we review the two designated notions of conformance testing for hybrid systems, based on the formal models defined in subsection 2.1. 2.3.1 hioco in this section, we review the hybrid input-output conformance (hioco) theory [vo06], simplified according to the assumptions made in section 2.2. definition 10 (after operator) for an hlts h and a trace α ∈ traces(h), we define h after α = { s ∣∣∣s0 α⇒ s} definition 11 (trajectories of a state) for an hlts h and a state s, traj(s) is defined as traj(s) = { σ ∈ trajs(v )| s σ⇒ } this definition can also be extended to a set of states c ⊆ s as traj(c) = ⋃ s∈c traj(s) using the above-given definitions, we are now ready to define the notion of hioco (simplified by neglecting discrete actions and restriction to input-enabled specifications). definition 12 (hybrid i/o conformance [vo06]) consider an hlts s; an input-enabled hlts i is said to be hybrid input-output conforming to s, denoted by ihioco s, if and only if for all traces α ∈ traces(s): proc. avocs 2014 8 / 16 eceasst traj (i after α)⊆ traj (s after α) the symmetric kernel of hioco, is denoted by =hioco. under the assumption of section 2.2, hioco is a pre-order and =hioco is an equivalence relation. 2.3.2 hconf to define the notion of conformance, the notion of (τ,ε)-closeness is defined to measure how much a given tss deviates from another tss. informally, two tsss are said to be (τ,ε)-close if, for any time interval of length τ , and each sampled point in one, there exists a sample point in the other such that the difference between the valuations in the two points is less than ε . based on this notion, two systems are conforming if, for all combinations of initial conditions and input tsss, the respective output tss of the two systems are close to each other. in order to be consistent with the hioco conformance relation, we only consider the conformance relation for tss models for (0,0)-closeness [ahf+14]. consider a maximum number of jumps n ∈n for which we are to perform the test. definition 13 (hconf [ahf+14]) two systems hm and hi are said to be conforming if for any input tss (u,σu)∈tss(vi,n) yhm (h0,(u,σu)) = yhi (h0,(u,σu)) we write hm hconf hi to denote that two systems hm and hi are conforming. 2.4 differences in conformance relations in addition to the fundamental differences in the semantic domain, which stated in subsection 2.2, there are also fundamental differences in the way the two conformance relations are defined. below, we provide a concise list of such fundamental differences: • pre-order vs. equivalence relation. the conformance relation hioco is a pre-order (for input-enabled specifications), while hconf is an equivalence relation. this stems from a fundamental difference in whether the implementation may choose from the alternative behaviors of the specification (pre-order view), or the implementation should implement the behavior prescribed by the specification (equivalence view). (the notion of closeness in hconf to some extent remedies this, and allows for deviations in the implementation.) in order to make our comparison possible, we consider the symmetric kernel of hioco for input-enabled specification, denoted by =hioco, and compare it with hconf. • projecting on specification traces/trajectories vs. considering all traces. since the semantic model of hioco allows for partial specification, the conformance relation also exploits that by comparing the behavior of the implementation and specification only with respect to those traces specified in the specification. this can potentially create major differences between hioco and hconf. however, since we restricted our specifications to input-enabled and deterministic ones, this difference is not visible in our results to follow. 9 / 16 volume 70 (2014) conformance testing of cyphy systems • exact vs. approximate comparison of trajectories. conformance relation hioco compares the continuous behaviors precisely, while hconf defines a notion of temporal and spatial closeness is used to represent and measure the deviation of the implementation from the specification. as indicated in the aforementioned claim of [ahf+14], we only consider the exact version of hconf and compare it with hioco. • sensitivity to quiescence. in order to reject implementations that do not produce any output when they should, the notion of quiescence is employed in hioco. also, to denote existence or absence of continuous trajectories the notion of agile states is introduced. these notion are altogether absent in hconf, because hconf does not allow for the absence of outputs. in the case of deterministic input-enabled models (both for specifications and implementations, implied by our assumptions (a1)-(a5)), this difference is immaterial; however, once the models are relaxed to allow for non-deterministic and/or partial models, this difference may differentiate between the two notions of conformance. 3 translating hybrid automata to the other models in this section, we employ the notion of hybrid automata as a general formalism for hybrid systems and show how a hybrid automaton satisfying assumptions (a1)-(a5) can be translated to each of the two considered semantic domains. for the purpose of this paper, we deal with a minimal definition of hybrid automaton as considered in [gst09], in which there is no distinction between input and output actions. definition 14 (hybrid automata [gst09]) a hybrid automaton is defined as a tuple (loc, v , (l0,v0), →, i, f ), where • loc is a finite set of locations; • v is the set of continuous variables; • l0 denotes the initial location and v0 is an initial valuation of v; • →⊆ loc×b(v )×reset(v )×loc is the set of jumps where: – b(v )⊆ val(v ) indicates the guards under which the switch may be performed, and – reset(v ) = ⋃ v ′⊆v val(v ′) is the set of all value assignments to all or a subset of the variables v ; • i : loc → b(v ) determines the allowed valuation of variables in each location (called the invariant of the location); • f : loc → b(v ⋃ v̇ ) describes some constraints on variables and their derivatives and specifies the allowed continuous behavior in each location. as before, we write l g,r → l′ for (l,g,r,l′)∈→. the dynamic behavior of a hybrid automaton can be specified by a set of solutions. a solution to a hybrid automaton is a function on a hybrid time domain, which is defined as follows. proc. avocs 2014 10 / 16 eceasst definition 15 (hybrid time domain [gt06, gst09]) a set e ⊂ r≥0 ×n is a hybrid time domain if either: • e = ⋃j−1 j=0([t j,t j+1], j), for a finite j, where t0 = 0 and t0 ≤ t1 ≤ t2 ≤ ...≤ tj , tj ≤ ∞; or • e = ⋃ ∞ j=0([t j,t j+1], j) , with t0 = 0 and t0 ≤ t1 ≤ t2 ≤ ... for a hybrid time domain, we define time interval i j to be [t j,t j+1]. a time instant in the hybrid time domain e is defined as a pair (t, j)∈ e. definition 16 (solution of a hybrid automaton [lem00]) a solution to the hybrid automaton ha = (loc,v,(l0,v0),→,i,f) is a function x : e → loc×val(v ), where e is a hybrid time domain partitioned into a finite number j of intervals, and • x(0,0) = (l0,v0); • for a fixed j, x(t, j) : t → l j ×val(v ) is a function over real time that satisfies i(l j) and f(l j); and • ∀ j ( j−1 > j ≥ 0) : ∃g ∈b(v ),r ∈ reset(v ) such that ( l j g,r −→ l j+1 ) ∧ (x(t j+1, j)↓v satisfies g) ∧ (x(t j+1, j + 1)↓v = r). the set of all solutions of a hybrid automaton ha is denoted by solutions(ha). for a given hybrid automaton ha, the determinism assumption (a4) yields: ∀s,s′ ∈ solutions(ha) : (s ↓vi = s′ ↓vi)⇒ (s ↓vo = s′ ↓vo) the length of a solution s is defined as the number of intervals in dom s. 3.1 translating hybrid automata to hybrid labeled transition systems according to definition 3 and definition 14, a hybrid automaton denotes an hlts, as follows. definition 17 (t.uhlt s [vo06]) a hybrid automaton ha = (loc,v,(l0,v0),→,i,f) can be converted to an equivalent hlts thauhlt s = (loc×val(v ),(l0,v0),trajs(v ),→), where • →={(l,u) σ→ (l′,u′)| ( ∃g,r : l g,r −→ l′ ) ∧(u ∈ g)∧(u ∈ i(l))∧(u′ ∈ r)∧(u′ ∈ i(l′))∧ (u = σ.fval∧u′ = σ.lval)} ⋃ {(l,u) σ→(l,u′)|∃σ∈trajs(v ) : (u = σ.fval)∧(u′ = σ.lval)∧(σ satisfies f(l))∧(∀t ∈dom(σ) : σ(t)∈ i(l))} where, σ.fval and σ.lval respectively denote the value of σ at its starting (first) point and ending (last) point. 3.2 translating hybrid automata to timed state sequences in order to convert a hybrid automaton to a tss, we use the concept of the solution of the hybrid automata. 11 / 16 volume 70 (2014) conformance testing of cyphy systems definition 18 (t.ut ss) consider a hybrid automaton ha with the set of input variables vi and the set of output variables vo. further, let solutions(ha) denote the set of all solutions of ha. thus, the tss model which is defined by ha, denoted by thautss, is the mapping: h : (u,σu) 7→ (y,σy) that is constructed from the set of solutions in such a way that, for any solution x∈solutions(ha), any input tss (u,σu) obtained by discretizing x ↓vi is mapped to an output tss (y,σy), where • σy = σu; • yi = x(ti, ji)↓vo, where (ti, ji) is the i th element of σu. 4 equivalence of hioco and hconf theorem 1 given a specification s in terms of a hybrid automaton and an implementation of which the behavior is expressed by a hybrid automaton i. if both s and i satisfy conditions a1-a5, then it holds that tsut ss hconf tiut ss if and only if tsuhlt s =hioco tiuhlt s. proof. the idea of the proof is that we define a notion of hybrid conformance relation for hybrid automata and show that both hioco and hconf are equivalent to this notion of conformance. the proof comprises the following two steps: 1. tsuhlt s =hioco tiuhlt s ⇔ ∀s ∈ solutions(s),∀s′ ∈ solutions(i) : (s ↓vi = s′ ↓vi)⇒ (s ↓vo = s′ ↓vo) 2. tsut ss hconf tiut ss ⇔ ∀s ∈ solutions(s),∀s′ ∈ solutions(i) : (s ↓vi = s′ ↓vi)⇒ (s ↓vo = s′ ↓vo) to prove step 1, we provide a method for converting a solution in a hybrid automaton h to an equivalent trace in the respective hlts, and conversely, to convert a trace to a corresponding solution. lemma 1 (traces and solutions equivalence) given a solution s ∈ solutions(h), one can uniquely obtain a trace τ ∈ traces(thuhlt s), with |τ|= |s|, and vice versa. proof. for a fixed n ≥ 0, consider a trace τ = α0α1...αn−1 ∈ traces(thu) with |τ| = n, and let d j denote the continuous time interval over which α j is defined. we can associate a solution s ∈ solutions(h) with τ as follows. we specify the domain of s as dom s = ⋃n−1 j=0 i j, where i j is defined as: • i0 = [d0,0]; • i j = ([t j,t j+1], j), where t j+1 = t j +|d j| for j > 0; proc. avocs 2014 12 / 16 eceasst in which |d j| denotes the length of time interval d j. furthermore, the value of the solution s at time instant (t, j) is specified by the value of the respective trajectory at that instant, i.e., s(t, j) = α j(t −t j). conversely, it can be shown that given a solution s ∈ solutions(h), one can uniquely obtain a trace τ ∈ traces(thuhlt s), with |τ|= |s|. next, we show that tsuhlt s =hioco tiuhlt s means that traces(tsuhlt s) = traces(tiuhlt s). then, using lemma 1, the first step of the proof can be readily concluded. lemma 2 consider two hybrid automata s and i. it holds that tsuhlt s =hioco tiuhlt s if and only if traces(tsuhlt s) = traces(tiuhlt s). proof. for an hlts h, let tracesn(h) denote the set of all traces of h which are of length n. in other words, tracesn(h) = {α ∈ traces(h) : |α|= n}. the goal is to show, given tsuhlt s =hioco tiuhlt s, that tracesn(tsuhlt s) = tracesn(tiuhlt s) for any n ≥ 0. we proceed by induction on n. we consider n = 0 as the base of induction, which includes empty trace ε . according to definition 4, and also with regard to definition 5, it holds that ε ∈ traces(tsuhlt s) and ε ∈ traces(tiuhlt s). therefore, traces0(tsuhlt s) = traces0(tiuhlt s). for the induction step, assuming that tracesn(s) = tracesn(i), we need to show tracesn+1(s) = tracesn+1(i). to this end, consider that tracesn+1(i) and tracesn+1(s), which can be defined as follows: tracesn+1(i) ={τ α | τ ∈ tracesn(i)∧α ∈ traj (i after τ)} and tracesn+1(s) ={τ α | τ ∈ tracesn(s)∧α ∈ traj (s after τ)} we have that tracesn(s) = tracesn(i), and also according to definition 12, traj (s after τ) = traj (i after τ), we have tracesn+1(s) = tracesn+1(i), which completes the induction step. (note that according to assumptions a2 and a4 in subsection 2.2, definition 12 establishes the former equality.) for step 2 of the proof of theorem 1, we first show that if solutions(s) = solutions(i) then tsut ss hconf tiut ss. note that the method for translating a hybrid automaton to a tss described in definition 18 is deterministic. moreover, the translation method constructs the respective tss solely based on the set of solutions of the hybrid automaton. therefore, for two hybrid automata s and i with the same set of solutions, the resultant tsss are trivially equal. according to definition 13, this means that tsut ss hconf tiut ss. to prove step 2, we further need to show that if tsut ss hconf tiut ss then solutions(s) = solutions(i). we proceed with proof by contradiction. assume that tsut ss hconf tiut ss and solutions(s) 6= solutions(i). therefore, it holds that ∃s ∈ solutions(i) such that ∀s′ ∈ solutions(s) : s 6= s′. but, due the assumption that the considered hybrid automata are input-enabled, there exists an s′ ∈ solutions(i) for which s ↓ vi = s′ ↓ vi . but, as s 6= s′, we can conclude s ↓ vo 6= s′ ↓ vo, which means that there is a time instant (t, j) for which s(t, j) 6= s′(t, j). consider the input tss 13 / 16 volume 70 (2014) conformance testing of cyphy systems obtained by discretization of s, denoted as u that includes time instant (t, j). according to the translation method from hybrid automaton to tss described in definition 18, the output tss to which tsut ss maps the input tss u differs from that of tiut ss, which contradicts with the assumption of tiut ss hconf tiut ss. 5 conclusion we studied two fundamental notions of conformance testing for cyber-physical systems, which are to our knowledge the most notable notions of their kind. we have pointed out fundamental differences, both in their semantic domains and in their definition of conformance. we identified a set of conditions under which the two notions are comparable. we proved that under such conditions, the two notions coincide. while hioco is based on a richer and more expressive semantic domain, it suffers from practical concerns, which are related to its underlying infinite state-space. on the other hand, hconf provides a more practical approach to checking conformance, but it ignores some important aspects in modeling, including explicit discrete interactions, nondeterminism, and partial specifications. the dichotomy reflected in the difference in the two notions suggests that a natural next step would be to define a more general notion of conformance testing for cyber-physical systems, which consolidates the theoretical expressiveness of hioco with the practical approach of hconf to conformance checking. defining a test-case generation algorithm and proving soundness and adequacy of the generated test cases (given some testing hypothesis) are among the future milestones. applying the resulting theory and tools to concrete cases of cyber-physical systems is a necessary step in validating our future research. acknowledgements: we would like to thank the anonymous reviewers of avocs’14, houssam abbas, harsh beohar, pieter cuijpers, jim kapinski, mehdi kargahi, and mahsa varshosaz for their helpful comments. bibliography [1] cyber-physical systems concept map, http://cyberphysicalsystems.org/ . retrieved october 2014. [ahf+14] h. abbas, b. hoxha, g. fainekos, j. v. deshmukh, j. kapinski, k. ueda. conformance testing as falsification for cyber-physical systems. in iccps. 2014. full paper available from: http://arxiv.org/abs/1401.5200 [afm14] h. abbas, g. fainekos, and h. mittelmann. formal property verification in a conformance testing framework. in memocode. 2014. [abw09] b. k. aichernig, h. brandl, f. wotawa. conformance testing of hybrid systems with qualitative reasoning models. entcs 253(2):53–69, oct. 2009. proc. avocs 2014 14 / 16 http://cyberphysicalsystems.org/ http://arxiv.org/abs/1401.5200 eceasst [ad94] r. alur, d. l. dill. a theory of timed automata. theoretical computer science 126(2):183–235, 1994. [bb05] l. b. briones, e. brinksma. a test generation framework for quiescent real-time systems. in proceedings of the 4th international conference on formal approaches to software testing. fates’04, pp. 64–78. springer-verlag, berlin, heidelberg, 2005. [bk06] e. bringmann, a. krämer. systematic testing of the continuous behavior of automotive systems. in proceedings of the 2006 international workshop on software engineering for automotive systems. seas ’06, pp. 13–20. acm, 2006. [bwa10] h. brandl, m. weiglhofer, b. aichernig. automated conformance verification of hybrid systems. in international conference on quality software (qsic). pp. 3–12. july 2010. [cr08] p. j. cuijpers, m. a. reniers. lost in translation: hybrid-time flows vs. real-time transitions. in hybrid systems: computation and control. pp. 116–129. springer, 2008. [crh02] p. j. l. cuijpers, m. a. reniers, w. p. m. h. heemels. hybrid transition systems. computer science reports 02-12, tu eindhoven, 2002. [dan10] t. dang. model-based testing of hybrid systems. monograph in model-based testing for embedded systems, crc press, 2010. [gst09] r. goebel, r. sanfelice, a. teel. hybrid dynamical systems. ieee control systems magazine 29(2):28–93, april 2009. [gt06] r. goebel, a. r. teel. solutions to hybrid inclusions via set and graphical convergence with stability theory applications. automatica 42(4):573–587, apr. 2006. [lem00] m. lemmon. on the existence of solutions to controlled hybrid automata. in hybrid systems: computation and control. lncs 1790, pp. 229–242. springer, 2000. [lib03] d. liberzon. switching in systems and control. springer, 2003. [lsv03] n. lynch, r. segala, f. vaandrager. hybrid i/o automata. information and computation 185(1):105–157, 2003. [ms97] o. müller, p. scholz. functional specification of real-time and hybrid systems. in hybrid and real-time systems. lncs 1201, pp. 273–285. springer, 1997. [nkm+14] n. noroozi, r. khosravi, m.r. mousavi, t.a.c. willemse. synchrony and asynchrony in conformance testing. journal of software and systems modeling, springer, 2014. in press. [vo06] m. van osch. hybrid input-output conformance and test generation. in formal approaches to software testing and runtime verification. lncs 4262, pp. 70–84. springer, 2006. 15 / 16 volume 70 (2014) conformance testing of cyphy systems [vo09] m. van osch. automated model-based testing of hybrid systems. faculty of mathematics and computer science, tu eindhoven, 2009. [sp10] a. simao, a. petrenko. from test purposes to asynchronous test cases. in proc. of icstw 2010, pp. 110. ieee cs, 2010. [tre96] j. tretmans. test generation with inputs, outputs and repetitive quiescence. software concepts and tools 17(3):103–120, 1996. [ww09] m. weiglhofer, f. wotawa. asynchronous input-output conformance testing. in proc. of compsac09, pp. 154159. ieee cs, 2009. [wlt13] m. woehrle, k. lampka, l. thiele. conformance testing for cyber-physical systems. acm trans. embed. comput. syst. 11(4):84:1–84:23, jan. 2013. proc. avocs 2014 16 / 16 introduction running example related work paper organization formal definitions and fundamental differences formal models basic definitions hybrid labeled transition system timed state sequence (tss) model differences in semantic models conformance relations hioco hconf differences in conformance relations translating hybrid automata to the other models translating hybrid automata to hybrid labeled transition systems translating hybrid automata to timed state sequences equivalence of hioco and hconf conclusion implementing a model-driven and iterative quality assessment life-cycle: a case study electronic communications of the easst volume 65 (2014) proceedings of the international workshop on software quality and maintainability (sqm 2014) implementing a model-driven and iterative quality assessment life-cycle: a case study benoı̂t vanderose, hajer ayed and naji habra 15 pages guest editors: lodewijk bergmans, tom mens, steven raemaekers managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst implementing a model-driven and iterative quality assessment life-cycle: a case study benoı̂t vanderose1, hajer ayed2 and naji habra3 1 benoit.vanderose@unamur.be 2 hajer.ayed@unamur.be 3 naji.habra@unamur.be precise research center university of namur, belgium abstract: assessing software quality through quantitative and reliable information is a major concern of software engineering. however, software is a complex product involving interrelated models with different abstraction levels targeting different stakeholders and requiring specific quality assurance methods. as a result, although software quality has gained maturity from a theoretical point of view, the practical quality assessment of software still does not fulfil enough involved actors’ expectations. in order to improve quality assurance in practice, a more integrated approach to assessment is required. this paper describes a case study in which a quality assessment framework (mocqa) relying on a model-driven and iterative methodology has been used to this end. for a year and a half, the framework has been used by the quality assurance team of a small it department to maintain and monitor a portfolio of projects in both production and development. the study shows the feasibility and the relevance of a model-driven and iterative quality assessment methodology in a professional environment. besides, although its results still require more generalisation, the study provides interesting insights on how such an approach may help ensure a continuous and explicit communication between stakeholders, leading to a more efficient quality assessment. keywords: quality assurance, model-driven, iterative approaches, case study 1 introduction in the context of a constantly evolving field like software engineering and with the steadily increasing level of complexity of software, software quality has become increasingly delicate to define and assess. as new fields and paradigms of software engineering have been appearing, quality concerns have been dispatched into several different and more or less independent subdomains managed by different stakeholders. quality assessment has therefore become a concern in every field of software engineering (from requirements engineering to design and coding). as a result, several quality assessment approaches (i.e., quality models, software measurement methods, etc.) have been proposed for the past three decades. 1 / 15 volume 65 (2014) mailto:benoit.vanderose@unamur.be mailto:hajer.ayed@unamur.be mailto:naji.habra@unamur.be implementing a model-driven and iterative quality assessment life-cycle despite the proficiency of research works addressing quality, the main observation remains the overall misguided or inefficient use of measures in industry, leading to costly [fn99], misused or useless measurement plans. some surveys (notably [kas06]) also show that software measurement tends to appeal more to the management than it does to the development team, therefore showing its inability to switch from a control-oriented paradigm to a guidance-oriented paradigm. this inability to satisfy the expectations of all stakeholders may be attributable to the lack of evolution in the way quality assessment is performed. in this paper, we argue that a key to improve quality assurance is to perform quality assessment through a model-driven and iterative methodology. by envisioning quality assessment as an iterative life-cycle performed in parallel to the software development and allowing for continuous refinements, we expect to circumvent most of the reluctance linked to quality assurance. this would in turn lead to a situation in which each type of stakeholders may contribute at different times of the life-cycle and therefore be satisfied by the quality assurance process. in order to illustrate the feasibility of such an approach, we report a case study in which the model-driven and iterative mocqa framework [van12] has been deployed and used in a professional environment. the study took place in the it department (d443) of the “direction générale opérationnelle de l’agriculture, des ressources naturelles et de l’environnement (dgarne)”, one of the department of the public administration of the walloon region. this it department counts 70 agents (including development teams, maintenance teams and a quality assurance team) and manage a pool of about 100 software applications used by a total of 2400 users in the dgarne. except for a few isolated cases, no metric or quantitative assessment of any sort was being used to monitor these products prior to the study. internal and specific quality standards were used to guarantee the global quality of projects. the remainder of this paper is organised as follows. section 2 discusses the benefits of a model-driven and iterative approach to quality assessment. section 3 describes the framework that has been used during the study. section 4 and 5 present the study that was carried out as well as its results. section 6 discusses the limitation of the study and, finally, section 7 provides conclusions and future work to be addressed. 2 model-driven and iterative quality assessment 2.1 quality assessment models the concept of model-driven assessment is not entirely new in software quality. in many regards, goal-driven measurement methods based on the gqm approach [bcr94] define an implicit model of the measurement to be performed. that measurement model guides the quality assurance and this approach may be considered model-driven. research efforts regarding quality metamodels [kln10, gsc+07] or software measurement modelling [mprg08] also contribute to quality modelling. those approaches allow the modelling of customised quality models and related quality indicators to fit a specific context. however the function of goal-driven measurement models may be pushed further by using quality assessment models designed to provide useful information to the different members involved in the development team as a reference regarding quality goals and related efforts. proc. sqm 2014 2 / 15 eceasst as for goal-driven measurement models, the main objective of quality assessment models is to assist the quality assurance team in the planning and execution of the quality assessment process for a specific development context [van12]. the models are therefore designed to record information on the quality goals and the evaluation methods that must be used. however, quality assessment models are also designed to record more specific information on the resources the development team is acting on and to relate these resources to the high-level quality requirements identified in the context. in order to help communicate with the managers or end users, quality assessment models also record information on the way high-level quality indicators should be interpreted and which actions should be taken in the software development process according to these interpretations. recording this heterogeneous information in a central model and using this model as a basis for the measurement process is the core of model-driven quality assessment. it pursues the goal of ensuring that the quality assessment performed is meaningful regarding the needs of all the relevant stakeholders. through quality assessment models, the quality assessment becomes a full-fledged model-driven process in the same way model-driven engineering relies on design-related models used through the implementation process to provide a software product all stakeholders can agree upon. 2.2 iterative and incremental methodologies in order to support a continuous model-driven quality assessment from the early stage of development and towards the maintenance process, it is crucial to address the possible emergence of new quality goals, and the refinement of existing assessment methods. considering software development methodologies, we may see that incremental and iterative approaches (such as the agile paradigm [bbb+01]) are now widely recognised as beneficial in order to deal with such situations. one of the main advantages offered by iterative/incremental approaches, is to provide a way to capture and react to the evolution of the context while keeping stakeholders involved [rea05]. another advantage of such approaches it to allow mistakes during the course of a process and their correction in a short frame of time [coc06]. any activity relying heavily on a human processing is prone to mistakes but addressing them and correcting them as they occur help people learn from the mistakes and is a beneficial process overall [boo04]. despite an increasing level of automation witnessed in software metrics, quality assessment still remains a process that relies heavily on human processing (e.g., prioritization of the quality goals, definition of the corrective actions to undertake, etc.) [bmb02]. as such, an iterative management of software quality may be beneficial. as a matter of fact, [dro96] already shows that quality models should be refined gradually to fit the goals and the context they are used in. the main hindrance to an early quality assessment is the fact that measurement plans often require a certain level of maturity in order to be applied. relying on an iterative quality assessment process makes the integration of less sophisticated measures possible during the early phases of the development. then, the methods are refined as the evaluated product gains in maturity. although the first iterations could integrate very rough and imprecise evaluation methods, they would at least provide indicators regarding the global direction in which the software quality is 3 / 15 volume 65 (2014) implementing a model-driven and iterative quality assessment life-cycle heading. on the other hand, addressing quality assessment through an incremental process let the quality assurance team avoid dealing with goals that are not yet clearly stated or measurable entities that are just not mature enough to undergo any relevant evaluation. 3 mocqa framework the mocqa framework has been designed to help plan and support quality assessment during software development (from the early stages of development to the maintenance and evolution processes) in a model-driven and iterative way [van12]. the framework defines a quality assessment metamodel that provides an abstract syntax for the systematic and consistent design of operational customised quality assessment models (or mocqa models) specifically designed for a defined software project and its particular environment. 3.1 mocqa models the main goal of mocqa models is to centralise the relevant information to support the quality assessment process. once defined, a mocqa model takes the role of a map that guides the execution of the quality assessment process and the subsequent exploitation of its results. it also serves as a central mechanism to the inclusion of any relevant stakeholder’s expectation in the quality assessment process. concretely, mocqa models aim at providing the required support thanks to the combination of: 1) a hierarchy of quality goals specifically designed for a given development environment (i.e., taking into account the specific environmental factors of the software project and the quality requirements of its stakeholders); 2) a set of customised measurement/estimation methods designed to monitor the level of satisfaction of the various quality goals; 3) a structured and detailed definition of the resources targeted by the measurement/estimation methods, taking into account their relations to each other and the multidimensional nature of the software project (i.e., multiple levels of abstraction/maturity for the resources). contrary to traditional quality models defining quality for a specific product, a mocqa model extends this limited scope by documenting all the relevant assessment-related aspects for a given project (i.e., what/how/why/for whom we measure and inspect different parts of the project). the underlying quality assessment metamodel has been designed to allow the alignment, tailoring and integration of quality models and measurement/estimation methods coming from different sources. it therefore grants that mocqa models are customised quality assessment models. the quality assessment metamodel also supports the detailed characterisation (i.e., relation between quality goals and stakeholders, status of a given measurement/estimation method regarding its validation, etc.) of the information contained in mocqa models so that they may be regarded as operational quality assessment models. finally, as an abstract syntax, the quality assessment metamodel eases the design and revision of the models. therefore, mocqa models proc. sqm 2014 4 / 15 eceasst are not set in stone and are bound to evolve during the software development life-cycle through their own quality assessment life-cycle. 3.2 mocqa methodology the introduction of mocqa models brings the quality assessment process closer to the modeldriven engineering of the product itself (i.e., design of a model based on elicited requirements, “implementation” of the quality assessment process through the measurement plan, “testing” of the quality profile with regard to the needs of the stakeholders). as a result, it is necessary to bind this conceptual model (mainly designed to communicate among stakeholders) to the actual (and possibly tool-assisted) measurement process. designing the model itself and acquiring the necessary knowledge from the stakeholders is another challenge raised by the model-driven nature of the approach. finally, the process involves a systematic reflection on the quality assessment process. in consequence, the framework defines a dedicated assessment methodology designed to support a quality assessment life-cycle built upon the design, exploitation and evolution of mocqa models. in order to implement an iterative and incremental approach, the mocqa methodology breaks the overall quality assessment life-cycle into successive quality assessment cycles, defined as “sequences of quality-related activities beginning with the planning of the assessment and leading to the actual assessment of a software project” [van12]. each quality assessment cycle therefore results in a set of decisions made by the development team about the forthcoming activities regarding the development life-cycle and the next quality assessment cycle. the fact that the mocqa methodology breaks down the process into iterative quality assessment cycles allows for a systematic revision of the quality goals and assessment methods. at the end of each cycle, the quality assurance team needs to reflect on the assessment performed so far and, together with the stakeholders, decide if the indicators and the way they are defined are relevant. additionally, the quality assessment methodology defined by the framework decomposes each quality assessment cycle into five successive steps (figure 1) described below. 1. acquiring contextual knowledge: this step focuses on the elicitation of relevant contextual information on the software development environment and on the specific quality requirements, as well as the classification of involved stakeholders. 2. designing the mocqa model: this step focuses on the creation and structural validation of a mocqa model by instantiation of the quality assessment metamodel. 3. tailoring of the measurement plan. this step addresses the definition of practical guidelines for the measurement and quality assessment, based on the conceptual definitions provided in the mocqa model. 4. assessing the software project: this is the step where the actual measurement-related and quality-related data (i.e., measurement results and indicators) are collected in order to produce a quality profile of the software project. 5. exploiting the quality profile: in this step the quality indicators are interpreted and used as input of the decision-making process related to the remainder of the development and/or the evolution processes and to the next quality assessment cycles. 5 / 15 volume 65 (2014) implementing a model-driven and iterative quality assessment life-cycle figure 1: the mocqa methodology through this assessment methodology, the framework provides the support needed to produce coherent and structurally valid mocqa models. the approach supports an effective use of measurement (i.e., a measurement that is tailored according to the goals of the stakeholders and focus on the satisfaction of their quality-related information needs). 4 description of the study 4.1 objectives the main objective of this study was to investigate whether the implementation of a modeldriven and iterative approach such as mocqa would fulfil the need of continuous quality assessment and improvement of the it department and be manageable by its quality assurance team. showing the applicability of such an approach requires to ensure that each step of the proposed methodology could be carried out. another goal of the study was to determine whether the iterative and model-driven methodology would be well received by all stakeholders involved in the development and maintenance process (i.e., developers, designers, etc.). 4.2 preliminary phase a preliminary learning phase was required to help the quality assurance team adopt the concepts of the framework. this learning phase was performed through several meetings with the quality assurance team leader, on the basis of the existing mocqa documentation. in turn, the team leader was in charge of informing his team (constituted of 4 additional members). this learning proc. sqm 2014 6 / 15 eceasst phase ultimately gave birth to an industrial mocqa deployment guide [han12]. following the learning phase, the quality assurance team of the d443 department started applying the mocqa framework on a daily basis. 4.3 first quality assessment cycle 4.3.1 acquisition amongst the many possible stakeholders to include in the process, 5 stakeholders were selected by the quality assurance team. this selection was based on the availability and role of the actors. the stakeholders were classified as either applicative stakeholders (i.e., any stakeholder that has to act on the software applications, regardless of his specific role in the process) or management stakeholders. out of the 5 stakeholders, 3 were coming from management and 2 were applicative stakeholders (i.e., development team leaders). the acquisition step was performed by the quality assurance team leader, through a round of individual interviews with each stakeholder. this process was formalised as a series of internal reports. this initial round of interviews lead to the elicitation of 26 quality goals/requirements. they were classified, organised and prioritised with the help of the head management of the d443 department, who may therefore be considered as an additional stakeholder. the priority was given to the “reliability” requirement for the first quality assessment cycle. 4.3.2 mocqa model design figure 2: example of quality issues expressed during the case study based on the structured list of quality requirements, the hierarchy of quality issues (i.e., “quality goals characterised by the quality factor they embody, the part of the software project they are relevant for, the stakeholders they are defined for, the indicators used to assess how they are satisfied and the way these indicators should be interpreted” [van12]) was designed (figure 2). as we may see, although the “reliability” quality factor may appear to originate from the iso/iec 9126 quality model [iso01], it is fact inherited from the internal standard of the organisation. therefore it is decomposed a the following series of specific sub-issues: • incidence of disturbance 7 / 15 volume 65 (2014) implementing a model-driven and iterative quality assessment life-cycle • availability (of the software application) • impact of the disturbance • deployment frequency these quality issues encompass all the relevant reliability aspects of a software application in production in the environment of the case study. the first quality issue is concerned by the frequency of unexpected behaviours from the software application. the second quality issue complements the first and is concerned by the overall availability of the application over time. the third issue intends to measure the criticality of the disturbances. finally, the deployment frequency quality issue intends to provide a sense of the number of times the system has to be modified and re-deployed, following a major disturbance. note that the names, although non conventional are inherited from the internal standards but could be aligned with other standards (e.g., the availability in this context may be aligned with the fault-tolerance characteristic of the iso/iec quality model). figure 3: example of quality indicator expressed during the case study during the first assessment cycle, only the “incidence of disturbance” quality issue was addressed. the mocqa model was completed with the description of the measured entities, measurement methods, functions and assessment models required to define relevant quality indicators for this issue. figure 3 provides an excerpt of the mocqa model showing the design of the quality indicator for the issue. as we may see, this quality indicator was based on two attributes of the assessed application (i.e., age and amount of disturbance). for this assessment model, the measurement methods were based on the behavioural observation of the assessed application (in order to evaluate the amount of disturbance) as well as a function deriving the age of the application based on its deployment date and the current date of the assessment (as shown in the complete model [van12]). at this stage, interpretation rules were provided based on “educated guesses” of the quality assurance team members. proc. sqm 2014 8 / 15 eceasst 4.3.3 measurement plan tailoring providing actual procedures to acquire measurement data was straightforward for the first indicator. two “repository-mining” procedures were defined. therefore, the relevant repositories to interrogate (one for the acquisition of the original deployment date and one for the report of disturbance) were identified by the quality assurance team. specific sql queries were also designed for each of the measurement methods. all other computations were performed manually, although the functions and assessment models were formalised in c#, in prevision of a future automation of the process. the data collection was planned using spreadsheets. 4.3.4 assessment and exploitation based on the mocqa model, the members of the quality assurance team were able to apply the model to the 56 software projects selected during the acquisition step. the first exploitation step was performed with the management stakeholders. they were explained the quality assessment process on the basis of the mocqa model. the quality assessment process was agreed upon and the assessment results analysed. the decisions taken on the basis of this first quality assessment cycle were mainly related to the continuation of the quality assessment life-cycle. modifications in the interpretation rules, including the addition of specific recommendations regarding required corrective actions, were proposed. however, the assessment results were perceived positively by the stakeholders as confirming intuitions on several software applications of the pool. 4.4 continuation of the quality assessment life-cycle the next quality assessment cycles focused on the refinement of the mocqa model in order to support corrective actions. during the second quality assessment cycle, exploitation occurred with the contribution of applicative stakeholders. new quality issues were added with each new quality assessment cycle. at the end of the study, 14 quality issues were monitored with the support of the mocqa framework. 5 results and discussion during the one year and a half lifespan of the study, each step of the mocqa methodology (section 3.2) has been applied several times. the quality assurance team leader reported his progress and results to the management of the d443 department on a regular basis, in order to define if the course of the project was considered satisfying and should be continued. subsequently, the quality assurance team leader provided us with reports on the events. details on these reports are available in [han12]. the relevance of the model-driven and iterative approach has therefore been assessed through the feedback of the stakeholders and the quality assurance team leader. no quantitative data has been collected to evaluate the level of satisfaction of the stakeholders but the application of the framework was not discarded by the management at any point. based on the reports provided by the quality assurance team leader, several points may be noted: 1) the iterative and incremental aspects of the methodology have been accepted and applied. although no case of quality indicator or measurement/estimation method deprecation was observed 9 / 15 volume 65 (2014) implementing a model-driven and iterative quality assessment life-cycle during the course of the study (and therefore no observation on how the framework handles such cases), the apparition of new quality requirements leading to new quality indicators occurred several times and was supported by the methodology. 2) the assessment performed on the basis of the mocqa methodology was considered relevant according to both the head management and the quality assurance team. the quality indicators defined during the quality assessment life-cycle of the study were accurate in their support for refinement. the quality assessment performed based on the mocqa models led to the inspection and maintenance of several software systems and to the refactoring of the help desk supporting repository. 3) the deployment of the mocqa framework in the context of the it department d443 also allowed to determine how manageable the assessment methodology is in terms of efforts. due to organisational requirements, efforts where recorded and communicated to us for the first quality assessment cycle of the two first quality issues investigated by the quality assurance team. for those two quality assessment cycles, the efforts were estimated to an average of 10 man-days1 per cycle. these efforts were reviewed by the quality assurance team and the management and considered acceptable (i.e., not inducing an unacceptable overhead). the main overhead was identified as the initial learning phase, evaluated to 14 man-days. 4) the framework has since been integrated in the d443 department as a full-fledged quality assessment support for the quality assurance team. regarding our initial goals (section 4.1), the study proves positive on both aspects. the modeldriven nature of the approach helped define the specific quality requirements in the studied environment. besides, the assessment results were well received and led to actual actions carried out in the studied environment. the framework was also reported to be used without any hindrance by the quality assurance team, past the learning phase. the effort estimation, although not providing general results, tends to show that the overhead induced by the methodology is not a stumbling block, in comparison to the benefits it provides. additionally, the reports provided us with several observations about the use of the mocqa framework and software quality in general. 5.1 impact of the use of quality indicators during the course of the study, we had the opportunity to observe the impact of the introduction of formalised quality indicators in the context. at the end of the first quality assessment cycle, the assessment results provided stakeholders with unsurprising conclusions. the problems reported by the quality assessment model were mostly known or sensed to some level by the management stakeholders. however, the introduction of quality indicators and the rationale behind these values helped reinforce the motivation to take actions in order to solve the problems. although the indicators introduced in the first quality assessment cycle were not very specific or refined, their impact was already important. moreover, the notion of iterative quality assessment lifecycle guarantees that problems reported at the beginning of the process will be reported again recurrently. this iterative mechanism acts as a reminder of known problems. 1 in the context of the d443 department, a man-day is assimilated to 7.6 hours of work for 1 employee proc. sqm 2014 10 / 15 eceasst the quality assessment process itself may also lead to interesting conclusions that impact the environment. since the exploitation step analyses both the assessment results and assessment process, it is possible to report valuable information while trying to improve the quality assessment process. for instance, the end of the first quality assessment cycle showed that the collection of data was hampered by the lack of a centralised repository to find the necessary data (i.e., mainly the reported disturbances).therefore, although no actual measurement was performed during this cycle, the exploitation step still led to a corrective action (i.e., centralise the information on the various software applications). regarding the interpretation of the quality indicators, the iterative methodology was also well received. the caveat with indicators in general is to avoid interpreting them without a critical view on what reality they encompass. the fact that the framework allows for a critical revision of quality indicators (e.g., modify the threshold of over-demanding quality indicators) and provides the formalised rationale behind the quality indicator was beneficial for the fine-tuning of quality assessment over time. 5.2 human aspects the course of the study also helped confront the approach to the perception of the various stakeholders. some reluctance or scepticism towards the introduction of a formalised quality assessment framework appeared during the first and second quality assessment cycles. this circumspection took different forms depending on the type of stakeholders. the management mainly worried about the return on investment of the application of the mocqa methodology. the concern was thus the amount of time and effort the deployment of the framework would require. the conclusion of the first quality assessment cycle provided reassuring answers to this concern. the applicative stakeholders (i.e., development team leaders) were more concerned by the quality indicators themselves, raising the issue that the quality indicators may not reflect the truth of the applications they were responsible for. this reaction is not surprising since individuals tend to dislike the notion of quality control [wr05]. during the second exploitation phase, explaining to them the fact that taking into account their feedback on the results and interpretation was part of the process helped solve the issue. a transversal issue regarding the deployment of the framework was also raised during the first quality assessment cycle. this issue was related to the perceived “subjectivity” of the quality assessment process. the choice of reliability as a first quality issue was questioned by other stakeholders. the same occurred with the way quality issues were assessed. this concern was integrated into the decision-making regarding the quality assessment process. therefore, the input of stakeholders that were not concerned by the reliability was used to decide which quality issue should be investigated next. the assessment process for reliability was maintained after exchanges between the quality assurance team and the aforementioned stakeholders as expected, another important aspect of the deployment of a quality assessment plan was to communicate on the target of the assessment. the key to a successful assessment is to prevent individuals from feeling assessed themselves. the availability of the mocqa model provided a transparent way to clearly define the goals of the assessment. through the consultation of 11 / 15 volume 65 (2014) implementing a model-driven and iterative quality assessment life-cycle the model, each member of the department (even if they are not listed as stakeholders) may understand the process. mocqa models provide many constructs but clearly none of them is designed to assess individuals. therefore, the quality assessment process was well received in the context of the study. 5.3 stakeholder classification as explained previously, a simple classification was proposed in the context of it department d443. this dual categorisation turned out to be sufficient during the course of the case study. the two categories of stakeholders clearly elicited different goals and, as seen in the previous section, different worries regarding the quality assessment process. the dual classification management/applicative stakeholders also led to an interesting observation. indeed, the way measurement and assessment results are introduced to the type of stakeholder varies slightly. basically, we distinguished two tendencies: 1) managerial stakeholders are more prone to react positively to dashboards. although the presence of the mocqa model itself is reassuring, the outcome management stakeholders are expecting is a set of indicators. 2) applicative stakeholders are more prone to react negatively to dashboards. providing a set of values to the individuals that actually act on the software applications raises concerns on the origin of the values and how they were computed. in that case, the support of the mocqa model helps provide a good understanding of the rationale behind the indicators in a format that is familiar to the applicative stakeholders (i.e., models). 5.4 support from the management the case study also showed that quality assessment must be management-driven in order to be productive. although the framework provides many elements to counter the reluctance or the scepticism from the development team (i.e., participative and iterative methodology), the framework must be applied with the full support of the management. during the course of the study, the support from the management helped the quality assurance team motivate and decide the development team to take part in the quality assessment and improvement processes. this observation reinforces the considerations provided by [wr05]. the fact that each quality indicator is defined with a given purpose (originating from the management) helps reinforce the perception that quality assessment is a useful process. additionally, the management has to clearly support the guidance-oriented perspective of quality assessment. the fact that the management supported the deployment of a framework that relies on this “guiding over control” philosophy helped greatly in reassuring the applicative stakeholders in the studied environment. 6 threat to validity although the results of this case study are positive, they only show that the approach is applicable in this specific context. the effort estimation cannot be generalised at this point since this aspect is highly sensitive to the context of use and the complexity of the designed mocqa model. the proc. sqm 2014 12 / 15 eceasst support provided by the management was crucial to the success of this deployment. besides, the views of the quality assurance team (i.e., guiding over control) were already close to the underlying concepts of the framework. in other words, the environment of the case study was suited to introduce a model-driven and iterative framework such as mocqa. results therefore call for experimentation in other contexts in order to generalise these results. additionally, the case study does not provide quantitative data regarding the criteria that have been assessed. future industrial case studies should focus on obtaining more quantitative results regarding the validation process. obtaining data regarding the productivity and effort in an industrial context is a complicated task. each project is unique and therefore, the comparison of quality assessment efforts across projects is not relevant. future studies could however address the problem of quantitative validation thanks to more structured approaches such as satisfaction surveys to determine the level of satisfaction of the stakeholders. 7 conclusion and future work the case study carried out in the d443 department reinforces the hypothesis that model-driven and iterative approaches allow for more focused and relevant quality assessment. as we have seen, the iterative nature of the framework deployed in the d443 department provided several advantages regarding the success of its adoption. the methodology helped circumvent some reluctance from the stakeholders and provided a way to react to their input in a satisfactory way. the availability of a quality assessment model upon which the assessment would be performed also insured a continuous and explicit communication between all the actors. among the risks inherent to such approaches, we have seen that the learning curve was the most notable overhead during the study. based on this observation, a way to improve the approach may be to integrate it more tightly with already known patterns such as the agile paradigm. explaining the concepts of the iterative quality assessment methodology in terms of agile concepts would help reduce the learning curve. as it is, the methodology proposed by the mocqa framework already bears several similarities with agile concepts. for instance, the exploitation step may be assimilated to a retrospective while a cycle is basically a quality-oriented agile iteration. furthermore, like the mocqa framework, agile quality management promotes the guidance-oriented perspective and the ”inspect-and-adapt” cycles. efforts should be carried out to make these similarities explicit. these similarities could also contribute to the field of agile methods customisation. indeed, the problem of customising agile methods is to provide objective ways to select the adequate methodological elements [avh12]. a model-driven agile methods quality-integrated customisation framework (am-quick) integrating concepts from the mocqa framework has already been proposed in [avh12]. am-quick comprises an agile metamodel adapted from wellknown process metamodels (i.e, spem, opf and smsdm [hg05]), designed to support agile methodologists during the construction of context-specific methods and to provide guidance throughout their assessment and refinement. the agile metamodel integrates a subset of the mocqa metamodel in order to map the measurement process with the software process elements. for instance, in the case of an agile method construction based on measurement values, the selection of the appropriate process element may be regarded as a hierarchy of quality is13 / 15 volume 65 (2014) implementing a model-driven and iterative quality assessment life-cycle sues. the stakeholders for these quality issues are the “agile methodologists” whereas their scope would be the different part of the project where specific process elements are used. this integration could be pushed forward regarding the integration of the mocqa framework with am-quick. indeed, the mocqa methodology, due to its iterative nature, could be merged with the agile methods customisation framework life-cycle which is based on the quality improvement paradigm (qip). finally, at this stage, we cannot guarantee that every context will allow a suitable integration of a model-driven and iterative quality assessment. only through repeated empirical studies in various contexts will the approach collect enough evidence of its advantages, or reveal other shortcomings that the approach needs to overcome. additionally, the case study described in this paper mainly focused on the feasibility of quality assessment processes relying on the mocqa framework. future case studies should therefore investigate the efficiency of the approach (i.e., whether or not the approach actually increases the productivity and the cost-effectiveness of quality assessment). acknowledgements: this research has been co-funded by the european regional development fund (erdf) and wallonia, belgium. the research is also partially supported by the e-government chair of the university of namur. bibliography [avh12] h. ayed, b. vanderose, n. habra. a metamodel-based approach for customizing and assessing agile methods. in proceedings of the 8th international conference on the quality of information and communications technology (quatic 2012). 2012. [bbb+01] k. beck, m. beedle, a. van bennekum, a. cockburn, w. cunningham, m. fowler, j. grenning, j. highsmith, a. hunt, r. jeffries, j. kern, b. marick, r. c. martin, s. mellor, k. schwaber, j. sutherland, d. thomas. manifesto for agile software development. 2001. [bcr94] v. basili, g. caldiera, d. h. rombach. the goal question metric approach. 1994. [bmb02] l. c. briand, s. morasca, v. r. basili. an operational process for goal-driven definition of measures. ieee trans. softw. eng. 28(12):1106–1125, 2002. [boo04] g. booch. object-oriented analysis and design with applications (3rd edition). addison wesley longman publishing co., inc., redwood city, ca, usa, 2004. [coc06] a. cockburn. agile software development: the cooperative game (2nd edition) (agile software development series). addison-wesley professional, 2006. [dro96] r. g. dromey. cornering the chimera. ieee softw. 13(1):33–43, 1996. [fn99] n. e. fenton, m. neil. software metrics: success, failures and new directions. j. syst. softw. 47(2-3):149–157, 1999. proc. sqm 2014 14 / 15 eceasst [gsc+07] f. garcı́a, m. serrano, j. cruz-lemus, f. ruı́z, m. piattini. managing software process measurement: a metamodel-based approach. information sciences 177(12):2570–2586, june 2007. [han12] s. hanoteau. déploiement de l´approche mocqa en environnement professionnel. master’s thesis, university of namur, 2012. [hg05] b. henderson-sellers, c. gonzalez-perez. a comparison of four process metamodels and the creation of a new generic standard. information and software technology 47(1):49–65, 2005. [iso01] iso/iec. 9126-1, software engineering product quality part 1: quality model. 2001. [kas06] m. kasunic. the state of software measurement practice: results of 2006 survey. technical report, software engineering institute, 2006. [kln10] m. klaes, c. lampasona, s. nunnenmacher. how to evaluate meta-models for software quality? in proceedings of the 20th international workshop on software measurement (iwsm2010). 2010. [mprg08] b. mora, m. piattini, f. ruiz, f. garcia. smml: software measurement modeling language. in proceedings of the 8th workshop on domain-specific modeling (dsm’2008). 2008. [omg08] omg. software & systems process engineering metamodel specification (spem) version 2. 2008. [opf09] opfro. open process framework. 2009. [rea05] d. read. iterative development: key technique for managing software developments. in proceedings of ict wa ’05. 2005. [van12] b. vanderose. supporting a model-driven and iterative quality assessment methodology: the mocqa framework. phd thesis, university of namur, 2012. [wr05] l. westfall, c. road. 12 steps to useful software metrics. proceedings of the seventeenth annual pacific northwest software quality conference 57 suppl 1(may 2006):s40–3, 2005. 15 / 15 volume 65 (2014) introduction model-driven and iterative quality assessment quality assessment models iterative and incremental methodologies mocqa framework mocqa models mocqa methodology description of the study objectives preliminary phase first quality assessment cycle acquisition mocqa model design measurement plan tailoring assessment and exploitation continuation of the quality assessment life-cycle results and discussion impact of the use of quality indicators human aspects stakeholder classification support from the management threat to validity conclusion and future work replex: a model-based reengineering tool for plex telecommunication systems electronic communications of the easst volume 1 (2006) proceedings of the third international workshop on graph based tools (grabats 2006) replex: a model-based reengineering tool for plex telecommunication systems christian fuss, christof mosler, marcel pettau 12 pages guest editors: albert zündorf, daniel varró managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst replex: a model-based reengineering tool for plex telecommunication systems christian fuss, christof mosler, marcel pettau [fuss|mosler|pettau]@i3.informatik.rwth-aachen.de http://www.se.rwth-aachen.de department of computer science 3 (software engineering) rwth aachen university, germany abstract: maintenance of complex legacy software systems is a challenging task. in the first place, maintenance requires understanding the system. reverse engineering and reengineering tools, which make the design of the current system available on-line and which support planning and performing changes to the system, are urgently needed. we present a new tool for reengineering telecommunication systems, recovering the current architecture, and extracting state machines reflecting the system behavior. the tool is based on a structure graph of the architecture and allows architectural modifications with according code changes. the modifications are specified as graph transformations using fujaba enabling the generation of a java prototype, which is accessible via a gui based on the graphical editor framework (gef) plug-in for the eclipse workbench. keywords: model-driven development, graph-based reengineering tools 1 introduction the reverse engineering and restructuring of large and complex software systems is a difficult task. e-cares1 is a research project at rwth aachen university, department of computer science 3 in cooperation with ericsson eurolab deutschland gmbh (eed), to study methods and tools for reengineering of complex legacy systems implemented in plex. the programming language plex [wen99] was developed in the 70s at ericsson and is still used within the company for developing telecommunication infrastructure. it is an asynchronous concurrent real-time language using the signaling paradigm, i.e. only incoming signals can trigger code execution. the current system under study is ericsson’s axe10, a mobile-service switching center (msc) comprising more than ten million lines of code. generally speaking, the reengineering process can be divided into three phases. in the reverse engineering phase, engineers analyse the legacy systems to improve understanding and gain more information about its current state, often by representing the software structure on a high abstraction level (e.g. as an architecture graph). during the restructuring phase, engineers perform re-design transformations to improve the software architecture. finally, the source code has to be modified according to the changes performed on design level. 1 e-cares is the acronym for ericsson communication architecture for embedded systems 1 / 12 volume 1 (2006) mailto:[fuss$|$mosler$|$pettau]@i3.informatik.rwth-aachen.de http://www.se.rwth-aachen.de replex: a model-based reengineering tool for representation and analysis of the legacy systems, we follow a graph-based approach, i.e. all underlying structures are graphs and editing operations are specified by graph transformation rules. our goal was to provide an interactive reengineering environment, which should allow a flexible and easy addition of new functionality (e.g. new analyses and transformations). this paper is structured as follows: our approach and motivation for using graph-based tools for software reengineering are described in section 2. in section 3, we present more details about the realization of the replex reengineering tool as a plug-in for the eclipse ide [ecl06] using the fujaba tool suite. we focus on the graph-based aspects of the tool, and explain the parser and source code transformations only very briefly. in section 4, a description and walk-through from user perspective is presented. the paper closes with a summary and an outlook. 2 approach 2.1 reengineering process the reengineering process comprises three phases: reverse engineering, re-design and source code transformation. all of them are supported by our tool environment, shown in figure 1. in the reverse engineering phase, we use different sources of information. the most important and reliable one is the source code of the plex system. we parse the source code and create a textual structure document describing the system structure, comprising its communication, control flow, and data flow. furthermore, we use some other sources of information, e.g. signal lists2, and add it to the structure document. additional information (e.g. signal lists) plex code plex parser unparser txl rule engine modified plex code annotated plexcode structure document replex structure editor figure 1: replex tool environment with source, intermediate and target documents. after parsing, the replex structure editor instantiates a graph from the structure document. on this graph, the user can perform various types of analyses by using different visualization and query techniques. in addition, different metrics can be used to obtain more quantitative characterizations of the analyzed system. these features support the reverse engineering of the analysed systems. the tool supports the re-design phase by offering some complex algorithms for suggesting how to improve the legacy software. the user can then interactively adapt the suggested re2 a signal list is a textual file, which provides the names of the blocks to which outgoing signals are sent during runtime. in plex, signal receivers are often initialized dynamically. by considering the signal list, we are able to exclude any signal edges from the graph which are potentially possible, but never actually used. proc. grabats 2006 2 / 12 eceasst design transformations taking the semantics of the software into account. during this process, the graph structure and attributes of the nodes can change. of course, the tool supports manual re-design of the structure graph by providing basic editing functionalities as well. after the re-design, the tool propagates modifications from the design level to the implementation level. first, an unparser writes information about the modified software structure into a textual file combining the original source code and annotations indicating what text transformations must be preformed. in the last step, the new source code is generated by a txl-based tool processing the annotations. 2.2 graph-based reengineering as shown, the reengineering process comprises graph-based and source code-based steps. representing software architectures by graphs is a natural choice, because in this manner not only the hierarchical structures but also all other relations between code artifacts can be represented directly. therefore using visual and graph-based languages for building corresponding reengineering tools is obviously advantageous. on the other hand, of course also the source code must be processed. by using both abstraction levels in our process, we can clearly divide the process into phases which are performed automatically and manually. the parsing and unparsing of the source code can be done automatically. during the re-design phase, the interactive process can be performed in a much more convenient and effective way on the graph-level. at the same time, we are exclusively interested in architectural aspects. hence, we analyze and restructure the software on a relatively high abstraction level without taking into account every single statement. in our graph model, we consider only larger code parts, such as subroutines, signal entries, and variable declarations, and go into detail only when necessary, for example when dealing with statements sending signals. furthermore, the separation of the graph and the source code levels should allow an easy integration of new programming languages into the replex tool suite. while the model extensions should comprise mainly the algorithmic aspects required for the re-design process, the language specific parsers and unparsers will comprise most of the details needed for the actual source code transformation. 2.3 related work there exist several graph-based reengineering tools. the comparison with other projects following a graph-based approach, such as rigi [mwt94], bauhaus [kos00], and gupro [ekrw02], shows that most of these tools lack the support provided by a high-level specification language. hence, graph transformations cannot be specified in a declarative way. these projects also concentrate on reverse engineering and do not support software restructuring. the approach in [mvdj05] shows how refactorings for object-oriented software can be defined by using graph rewrite rules using fujaba and agg [tae99] for tool validation. agg is a general tool environment for algebraic graph transformation following the interpretative approach. the agg environment consists of a graphical user interface and an interpreter, which can be used for the specification and prototypical implementation of java applications with complex graph-structured data. the paper at hand presents a very similar approach but aims at the 3 / 12 volume 1 (2006) replex: a model-based reengineering tool reengineering of programs written in a different kind of programming language. as we consider the software on a higher architectural level, without going into a detailed analysis of every single statement, the studied re-design transformations are also different. the fujaba tool suite re [fuj05] is a collection of reengineering tools and plug-ins. it allows the parsing of java source code and supports different kinds of static and dynamic analyses, such as recognition of design patterns and anti-patterns [nsw+02]. 3 realization based on knowledge from a former prototype implemented with progres we started developing the new tool replex3 within a graduate course for computer science students at rwth aachen university. the new prototype focuses on the forward portion of the reengineering process offering features for typical re-design tasks on plex code, whereas the old one focused on the reverse portion with abstracting from source code level and a plentitude of analyses. in the following sections, we describe some aspects of the realization in detail, particularly the specification of re-design features with fujaba, construction of the editor interface as eclipse plug-in with gef and text-transformation parsers and unparsers with the help of jay and txl. 3.1 parsing plex code the main unit of a plex program is a block corresponding to one source file. many source files make up a system, which might be divided into subsystems containing further subsystems or blocks. the structure of a system and its subsystems can be derived from the directory structure of the source code. all nodes in the structure graph comprise different types of attributes describing where the corresponding software parts can be found and what their characteristics are. major parts of the replex prototype are based on formal specifications from which they are generated. on the source code level, scanners, parsers, and unparsers are generated automatically. the structure of the plex system below block-level is determined by the pre-existing plex-parser on jay basis. this parser was generated automatically by use of the lexical analyzer generator jlex [ber00] and the parser generator jay [sk06], which are java correlatives of the gnu lex/yacc compiler-compilers. during parsing, many details from the plex code are abstracted away, putting only structurally relevant information into the structure graph, e.g. subroutines, statement sequences, signal entries, and data objects. the primary relation of elements is the contains-relation, taken directly from the nesting of the abstract syntax tree, but additionally references from the plex code are introduced as own edges into the structure graph, e.g. goto, calls, from source, to target edges. the parser outputs a description of the abstracted structure graph as python script or xml file, which can then be read by the structure editor. 3 the acronym replex combines the two words reengineering and plex. proc. grabats 2006 4 / 12 eceasst 3.2 specifying re-design features with fujaba as outlined in section 2.2, a graph-based approach is well-fitted for the interactive re-design of the structure graph of plex systems. there are several tools for performing the desired graph transformations. some come from the class of environments for specifying visual notations like diagen [min02], or metaedit+ [klr96]. others are general-purpose graph transformation environments like progres [swz99], agg [tae99], or fujaba [fuj99]. there were many reasons to choose fujaba as realization environment: it has a strong reengineering background [fuj05], enabling the integration with tools from related projects. from its roots, fujaba is closely related to progres, which served as environment for the specification of our old prototype and it allows easy integration with java code, particularly through the possibility to adapt the code generation with little effort. finally, specifying with fujaba is very easy to learn for novices like the students involved in the project, due to its resemblance of uml class and activity diagrams. a fujaba specification is two-parted and consists of a meta-model of the notation, defined as uml class diagram, and so-called story diagrams [fntz98] describing the operations on the elements, in our case re-design operations for the according plex structure elements. from this specification, the java code is generated with the fujaba plug-in codegen2. meta model figure 2 depicts the core of our meta model, directly reflecting the structure extracted by the parser as described in section 3.1. every element in the graph is derived from graphobject, managing the unique ids of all graph elements. graphobject is a specialization of observableobject, providing the event-handling for the eclipse/gef user interface (see section 3.3 for details). plexsystem subsystem << reference >> observableobject graphobject relation plexobject structuralrelation semanticrelation containsrelation hasrelation dataflowrelation controlflowrelation signalrelation block subroutine statementsequence signalentry dataobject * 0..1fromsource * 0..1totarget figure 2: core of the structure graph model, reflecting the structure graph produced by the plex parser. relations are directed and attributed; they are modeled as edge-node-edge constructs with 5 / 12 volume 1 (2006) replex: a model-based reengineering tool fromsource and totarget associations. the contains and has relations are structural relations. relations derived from references within the plex code fall into the class of semantic relations which is specialized into dataflowrelation (e.g. readsvariable, writesvariable), controlflowrelation (e.g. goto, call), and signalrelation (e.g. local signal, global inter-block signal). story diagrams the fujaba story diagrams, used to describe the re-design transformations, are a combination of uml activity and collaboration diagrams. story diagrams can be read as activity diagrams with a particular activity type called the story-activity, which enables describing interaction of objects during the operational sequence of the program or the time-flow of program execution. in terms of methods of classes, it means that every method in a class is described by a story diagram. for the control flow of a method, elements of uml activity diagrams are used, e.g. start and end points, transitions, and control structures. within the control flow, so called story patterns are used, modeling the transformation of the object structure. each method consists of a start point, several story patterns, and at least one end point, all connected by transitions. fujaba supports negative application conditions, restrictions, optional objects, and set-valued objects within story patterns. figure 3 shows an exemplary story diagram implementing the method mergesubsystems of the class subsystem. each subsystem object offers the method mergesubsystems which moves all contained blocks to another subsystem, given as a parameter, and then destroys itself. in the left part of the story diagram, we search for containsrelation objects connecting blocks to the current subsystem. for each relation we find, the fromsource edge is moved to the second subsystem4. the right part of the diagram shows the destruction of the current subsystem object and its containsrelation object to the plexsystem node. ]each time[ ]end[ totarget fromsource plexsystem:system «destroy» containsrelation:relation «destroy» this totarget containsrelation:containsrelation block:block this fromsource subsystem::mergesubsystems (subsystem: subsystem): void containsrelation «create» fromsource subsystem figure 3: story diagram for the merge method of the subsystem class 4 since the fromsource relation has a 0..1 cardinality, the old edge is destroyed implicitly and thus not marked with �destroy� proc. grabats 2006 6 / 12 eceasst 3.3 implementing the editor gui with gef the core features of the replex prototype were generated from the fujaba documents. yet, the graphical user interface had to be implemented by hand. we chose to integrate the tool into the eclipse ide [ecl06] and used the graphical editing framework (gef) [gef06] for realization. gef is a model-view-controller (mvc) framework that can be plugged into the eclipse ide to implement graphical editors for underlying models easily. gef offers rich support for the controller part of mvc, dictating a standard gef architecture. for the view part, it depends on the lightweight graphic system draw2d, also available as an eclipse plug-in. the underlying model can be chosen arbitrarily, it merely has to offer event notification so that the controllers can register with the model entities. since standard generated fujaba classes do not support event notification, we had to adapt the code generation using the fujaba plug-in codegen2 [gsr], which allows modification of the templates used to generate the code. we used the observer pattern and implemented a general observable class for the housekeeping of notification queues etc. all generated java classes for the model entities are then derived from the observable class and the code generation templates insert notifications into all modifiers. the current implementation of the model representation with gef deploys only two parameterizable representations for model entities: one for nodes and one for edges (actually, these are edge-node-edge constructs, cf. figure 2). the view parts for these are parameterized by the type of the associated entity. the functionality offered for a node can also be parameterized by the type of the entity. this is possible through the gef mechanism of requests and editpolicies, because editpolicies contain a mapping of requests to editing commands. the mapping can be implemented to pick the commands dynamically depending on the elements type. the different choices of parameterization have yet been coded into the prototype by hand, but with the upgrade framework [bjsw02] for progres prototypes, it has proven viable to generate a complete parameterizable gui from the specification of a graph transformation prototype. this should also be possible for fujaba prototypes in the future. 3.4 unparsing and code transformations after re-design, the tool propagates the improvements on structural level to the implementation level. the information about the improved software architecture is stored in the structure graph. this graph only forms an instantiated representation of the system, it does not contain all the information required for the generation of new source code. each graph node representing data of a control structure stores its original file name and its line numbers but not the actual source code. therefore, to obtain the changed program we resort to the original source code files and enhance them by adding information extracted from the modified graph, describing how the particular parts should be transformed. the syntax of this code and the corresponding transformations are defined in the rule-based programming language txl [chp91]. the txl transformation system parses the enhanced source code files (see figure 5) and performs the transformations on the created abstract syntax tree. a txl rule can define, for instance, transformations between different types of signals and 7 / 12 volume 1 (2006) replex: a model-based reengineering tool signal entries (e.g. local and global). in the case of moving blocks to other subsystems, only some comments are modified and the new source code is copied to the corresponding subsystem directory. during the transformation process, txl parses the original source code files which is a huge advantage of using this tool. as not all information required for generating the new source code are stored in the graph model, more details must be extracted from the source code. we should remark that txl could also be used as a parser for extracting the structure document in the reverse engineering phase. but as a jay-based parser for plex was already available from former projects, we decided to use the pre-existing one. more detailed information about the txl-based tool can be found in [mos06]. 4 using the replex tool the replex tool offers complex functionality, specified with the high-level mechanism offered by fujaba, that can easily be accessed through the gui of an eclipse plug-in. figure 4 shows the replex gui integrated into the eclipse ide. in this perspective it consists of a navigator view ia , strucure graph editor ib , tool bar ic and editing palette id as well as property viewie and code view if . figure 4: the replex tool in the navigator view ia one can see the directory structure of the replex project after the plex code has been parsed. it contains a separate directory for plex code and parsed structure proc. grabats 2006 8 / 12 eceasst documents (one for each plex block file). the project contains a third directory for modified plex code after generating plex code from a modified structure graph. by choosing a structure document in the navigator view, the corresponding structure graph is shown in the structure graph editor ib . in the figure, you can see a cutout of the structure graph of the gmsc block. the graph consists of the block node, and nodes for different program parts of the block. to make the analysis of a structure graph as convenient as possible, the tool baric offers many functions for viewing, e.g. zooming, outline, and layout algorithms. all these features allow effective reverse engineering of the analysed systems. the editing palette id offers simple functionality for the modification of structure graphs. in particular, one can manually create, destroy, and modify single nodes and edges. using the selection tool, one can also get more information on the selected element from the property viewie , which shows all attributes of an element, and the code view if , where the corresponding lines in the plex source code are highlighted. more complex reengineering and re-design analyses and transformations are available from the according entries in the menu bar at the top of the window. e.g. from the redesign menu one can trigger the inclusion of the signal list (cf. p. 2) as additional information into the structure graph. for each exchanged signal between block nodes, an edge is generated which is labeled with numbers indicating how many signals are exchanged between these blocks. this allows to abstract from block content and to regard only the block external signal flow, which is helpful when a large amount of blocks is considered. the tool also offers different kinds of re-designs, such as merging of two or more subsystems, splitting of a subsystem into two subsystems, and moving one or more blocks to another subsystem. similar re-designs for the contents of single blocks exist as well. the algorithms are based on different clustering techniques and effectively support the process of improving the system architecture. each re-design is separated into two steps. first, the graph is analyzed and a re-design transformation suggested which still can be manipulated by the user after considering the semantics of the program. in the second step, the actual graph transformation is performed. figure 5: the annotated plex source code after modifying the structure graph, the changes must be propagated to implementation level. from the current graph structure and the node attributes, the tool can derive changes, which must be performed on source code level. as described in section 2, we first generate an annotated version of the plex code by adding information about the required changes. figure 5 shows how the information is stored in the code. in this example, we performed a rename operation. we 9 / 12 volume 1 (2006) replex: a model-based reengineering tool rename the variable mscmoind from figure 4 to mscmo2ind. each modification is enclosed by two lines: the first line defines the modification type and the parameters, the second marks the end of the source code area to be considered during the transformation. the txl-specific command lines are surrounded by [* *]. these files are the input for the txl transformation tool, which generates the new plex code, containing all re-design modifications. figure 6 shows another feature of the replex tool: a state machine extracted from the plex code of the gmsc block. in the telecommunication industry, the behavior of software components is often modeled in terms of state machines. each state machine is realized in one plex block; by convention, their behavior is simulated by the enumeration variable state that changes its value every time a signal arrives or leaves the block. by analyzing access to this variable, we can derive a state machine from the structure graph to allow further analysis in the reverse engineering process. marburger [mar04] describes the algorithm in detail. state machines are visualized in an own view, the dfa tab. this view can be opened by selecting a block and using the dfaextractor from the tool bar. figure 6: the state machine for block gmsc this overview showed only a small part of the currently implemented and future functionality, partly already realized in the former progres prototype [mos06]. 5 conclusion & outlook in this paper, we presented a graph-based tool for reengineering telecommunication systems. we explained the underlying object-oriented model and how we use graph transformation rules with fujaba to specify the tool’s functionality. the tool supports the reverse engineering and restructuring process by recovering the actual architecture and propagating the modifications from the architecture level back to plex source code. from the fujaba specification a java prototype is generated, which is accessible via a gui based on the graphical editor framework plug-in for the eclipse workbench. from our experience with the formal specification of functionality with high level specification languages, we can draw the conclusion that languages like fujaba or progres allow even proc. grabats 2006 10 / 12 eceasst novice developers to realize a complex tool within short time. after first orientation in fujaba, the basic specification took two students roughly two days. further complex features could be added within hours. the implementation of the gui with gef was straight forward and fairly easy, but quite some hand-coding was necessary. this took ten students about eight workdays. we believe that a parameterizable gui could be generated from the fujaba specification in the future. further work concerns the development of more re-design transformations, partly already implemented for the progres-based prototype. in the context of the e-cares project, especially re-design modifications improving the real-time performance of plex systems are interesting. on the other hand, our approach for the txl-based source code transformation must be generalized. the tool is already able to generate new plex code for the given set of corresponding graph modifications, but we are still missing a prove that our approach can handle all possible architecture modifications. bibliography [ber00] e. berk. jlex: a lexical analyzer generator for java(tm). department of computer science, princeton university, sept. 2000. http://www.cs.princeton.edu/ appel/modern/java/jlex/current/manual.html. [bjsw02] b. böhlen, d. jäger, a. schleicher, b. westfechtel. upgrade: a framework for building graph-based interactive tools. electr. notes theor. comput. sci. 72(2), 2002. [chp91] j. r. cordy, c. d. halpern-hamu, e. promislow. txl: a rapid prototyping system for programming language dialects. computer languages 16(1):97–107, jan. 1991. [ecl06] eclipse consortium. eclipse. 2006. http://www.eclipse.org. [ekrw02] j. ebert, b. kullbach, v. riediger, a. winter. gupro – generic understanding of programs: an overview. electronic notes in theoretical computer science 72(2), 2002. url: http://www.elsevier.nl/locate/entcs/volume72.html. [fntz98] t. fischer, j. niere, l. torunski, a. zündorf. story diagrams: a new graph rewrite language based on the unified modeling language. in engels and rozenberg (eds.), proc. of the 6th international workshop on theory and application of graph transformation (tagt), paderborn, germany. lncs 1764, pp. 296–309. springer, nov. 1998. [fuj99] fujaba – from uml to java and back again. 1999. http://www.fujaba.de/. [fuj05] fujaba tool suite re. 2005. http://wwwcs.uni-paderborn.de/cs/fujaba/ projects/reengineering/. [gef06] gef – graphical editing framework. 2006. http://www.eclipse.org/gef/. 11 / 12 volume 1 (2006) replex: a model-based reengineering tool [gsr] l. geiger, c. schneider, c. record. templateand modelbased code generation for mda-tools. 3rd international fujaba days 2005, paderborn, germany. [klr96] s. kelly, k. lyytinen, m. rossi. metaedit+: a fully configurable multi-user and multi-tool case and came environment. in constantopoulos et al. (eds.), caise. lecture notes in computer science 1080, pp. 1–21. springer, 1996. [kos00] r. koschke. atomic architectural component recovery for program understanding and evolution. doctoral thesis, institute of computer science, university of stuttgart: stuttgart, germany, stuttgart, germany, 2000. 414 pp. [mar04] a. marburger. reverse engineering of complex legacy telecommunication systems. shaker verlag, aachen, germany, 2004. isbn 3-8322-4154-x. [min02] m. minas. specifying graph-like diagrams with diagen. electr. notes theor. comput. sci. 72(2), 2002. [mos06] c. mosler. e-cares project: reengineering of telecommunication systems. in lmmel et al. (eds.), proceedings of the summer school on generative and transformational techniques in software engineering (gttse’05). lncs 4143, pp. 437– 448. springer, braga, portugal, 2006. [mvdj05] t. mens, n. van eetvelde, s. demeyer, d. janssens. formalizing refactorings with graph transformations. journal on software maintenance and evolution: research and practice, pp. 247–276, 2005. [mwt94] h. a. müller, k. wong, s. r. tilley. understanding software systems using reverse engineering technology. in the 62nd congress of l’association canadienne francaise pour l’avancement des sciences acfas 1994. pp. 41–48. montreal, canada, may 1994. [nsw+02] j. niere, w. schäfer, j. p. wadsack, l. wendehals, j. welsh. towards pattern-based design recovery. in proc. of the 24th international conference on software engineering (icse), orlando, florida, usa. pp. 338–348. acm press, may 2002. [sk06] a.-t. schreiner, b. kühl. jay – a yacc for java. homepage, 2006. url: http://www.informatik.uni-osnabrueck.de/alumni/bernd/jay/. [swz99] a. schürr, a. j. winter, a. zündorf. the progres approach: language and environment. in ehrig et al. (eds.), handbook on graph grammars and computing by graph transformation: applications, languages, and tools. volume 2, pp. 487– 550. world scientific: singapore, 1999. [tae99] g. taentzer. agg: a tool environment for algebraic graph transformation. in proceedings agtive 99. lncs 1779, pp. 481–488. springer: heidelberg, germany, kerkrade, netherlands, 1999. [wen99] j. wennersten. plex-c language description. ericsson telecom ab, 1999. en/lzb 101 1903 r4b. proc. grabats 2006 12 / 12 introduction approach reengineering process graph-based reengineering related work realization parsing plex code specifying re-design features with fujaba implementing the editor gui with gef unparsing and code transformations using the replex tool conclusion & outlook microsoft word ocl2011-3.doc electronic communications of the easst volume 44 (2011) guest editors: jordi cabot, robert clariso, martin gogolla, burkhart wolff managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 proceedings of the workshop on ocl and textual modelling (ocl 2011) extending assl: making uml metamodel-based workflows executable jens brüning, lars hamann, andreas wolff 12 pages ocl 2011 1 / 12 proc. ocl 2011 extending assl: making uml metamodel-based workflows executable jens brüning1, lars hamann2, andreas wolff1 1 university of rostock, department of computer science, d-18059 rostock, germany {jens.bruening, andreas.wolff}@uni-rostock.de 2 university of bremen, department of computer science, d-28334 bremen, germany lhamann@informatik.uni-bremen.de abstract. assl is a language that enables uml developers to test and certify uml and ocl models [5]. snapshots of system states are semi-automatically created and main parts of the uml action semantics is implemented by the language. its interpreter is the well-known uml modeling tool use. the article proposes a number of language extensions to assl. these include (sub-) procedure calls and preand postcondition checks on entering and exiting of operations using ocl. the paper motivates the need for these extensions as well as their usage and development along the problem of metamodel-based execution of workflow models. executable workflow models, driven by assl procedures, are introduced in detail to present the usage of assl and our extensions. keywords: model validation, model execution, a snapshot sequence language, workflow metamodels 1 introduction the uml-based specification environment (use) [6] is a tool that can generate uml object diagrams from class diagrams manually or semi-automatically. these derived object diagrams can be seen as snapshots of a running system. use enables a developer to specify declarative ocl constraints in class diagrams. during runtime, these constraints, like e.g. invariants for system states or preand postconditions for uml operations, are permanently checked against the current snapshot. use provides a language called a snapshot sequence language (assl) [6]. assl has the ability to semi-automatically generate object diagrams. in this process all possible assignment combinations of objects and variables are attempted to find a stable state which satisfies every defined constraint [5]. if no assignment meets all ocl invariants the assl generation procedure finishes without results. for finding valid snapshots the special command try provides the possibility to assign values to assl variables that are further used for generating valid snapshots. the special command any assigns any value of a set to a variable. to generate eceasst volume 44 (2011) 2 / 12 object diagrams assl procedures must represent imperative specifications. it implements a large part of the uml action semantics including the creation or deletion of objects and links and the setting of attribute values in uml object diagrams. this is crucial for testing as well as executing uml models. the approach of this paper relies on those operations as basis for executing workflow models. assl has been implemented in combination with the parser generator antlr [11]. however, this article does not focus on implementation details. it rather explains how we use the extensions in the context of uml metamodel-based workflow execution. we are confident that there is a number of further promising applications of the proposed assl extensions. especially the area of model testing and certification in connection with the unique commands try and any for semi-automatic snapshot generation seems to bear good prospects for use. the workflow modeling and execution approach is a new application for the use tool and assl. the presented approach comprises of a declarative and an imperative part, while the focus of this article is on the imperative part. our approach enables us to express the workflow patterns presented in [12]. in contrast to established workflow languages like epcs, uml activity diagrams or bpmn the modeling approach has a flexible background driven by design principles. all execution sequences of the process model are allowed if they are not forbidden by ocl constraints. in contrast, the established languages uses a more petri net-like modeling approach in which only the allowed execution flows are determined. the developer defines action sequences that may restrict the user too much while executing the workflow [13]. in our view, the work presented in this paper is a new direction in the context of workflow languages with a declarative metamodel-based approach. the rest of the article is structured as follows. section 2 introduces our metamodel for workflows. we model an example workflow on basis of that. also we present a design time plugin to use that captures workflow models as assl instantiation procedures. this way we can reuse these models at runtime. section 3 introduces the workflow plugin that presents the workflow to the developer for interaction. we also go into details about assl and our assl extensions as they are the basis for workflow executions. a uml sequence diagram shows the relevant assl procedure calls. section 4 discusses related work and section 5 concludes the work. 2 workflow modeling with uml metamodel in this section we introduce the metamodel for workflows and demonstrate how workflows are modeled by means of the use tool. we introduce a design time plugin of use that persistently stores the workflow models for later reuse by generating assl procedures. 2.1 uml metamodel for workflows an earlier version of our metamodel for workflows was introduced in [2]. figure 1 shows an extended version that now supports all original 20 workflow patterns [12]. besides the class model, the metamodel contains of ocl invariants and preand postconditions to express the semantics of most metamodel elements declaratively. behaviors of the temporal or causal relations are also expressed imperatively. this particular part of the metamodel is implemented ocl 2011 3 / 12 proc. ocl 2011 as assl code. it will be explained in section 3 and is the main contribution of this paper. the following is intended as an overview to roughly explain the metamodel, as this is the key to understanding the semantics implemented in assl. fig. 1. a) the metamodel shown as uml class diagram b) uml state diagram showing life cycle of objects of the class activity c) object life cycle of the objects of the class iteration an analysis of how far our metamodel supports the workflow patterns is beyond the scope of this paper. however, a first discussion of this matter can be found in [2]. the pivotal class of the metamodel is activity, shown in the center of figure 1a). enumeration state lists the possible execution states of an activity. figure 1b) shows a life cycle of an activity as uml state diagram. in our work state transitions are expressed by ocl preand postconditions. for instance the precondition of the start() operation requires the object to be in the state waiting. its postcondition consequently assures that the state has changed to running. states of activities can be changed by calling operations of the classes activity, iterationgroup, cancel and cancelprocess. they are implemented with assl. eceasst volume 44 (2011) 4 / 12 note that not all operations changing an activity’s state are declared in that class. for example, an object of iterationgroup can initiate another iteration through the operation nextiteration(). this would store all execution data of the current iteration to the archive and reset all included activities to waiting. class activity itself does not directly provide an operation for resetting its instances’ state. the state diagram of the class iteration is shown in figure 1c). it differs from activity’s (see figure 1b) in that new iterations can be started after one is finished without resetting the activity. if an iteration object is in the state running and the operation finish is called a new iteration can be started directly by calling start again. the behavior of iteration is described more deeply in [7]. operation execution can have side effects on other activities, depending on causal or temporal relation between them. assl procedures implement those. if for example an activity starts and this activity is member of a deferredchoice group all other activities of that group are skipped. thus, the other activities cannot be started anymore and the choice was done implicitly. explicit decisions are expressed through the class decision and its subclasses. the criteria to select follow-up activities here are declared in the association class guard. the selection is user-driven and executed at runtime. this process will be discussed in subsection 3.1. 2.2 workflow model shown as uml object diagram figure 2 exemplifies the use of the workflow metamodel for the case of a medical emergency process. it essentially shows a screenshot of the use tool, which provides the modeling environment and thereby an abstract syntax for workflow models. the main process object is arranged topmost left in figure 2. it serves as root object to which all other model objects are connected; either direct or indirect through transitive associations. there is an ocl operation to collect all these elements through calculating the transitive closure. the operation also is part of the metamodel but not explicitly listed in figure 1a). the emergency process begins with the delivery of the patient. she can either be transported by helicopter or ambulance. for this initial part of the workflow the hospital staff is not responsible to decide what transport type should be taken. therefore both available transportation activities are modeled in a deferredchoice relationship [2]. after the patient has arrived at the hospital, she has to be checked whether she has to be operated immediately or if there is time to prepare a normal surgery. this check is done by a doctor at the hospital. depending on its decision, an immediate or a normal surgery takes place. the normalsurgery as well as the emergencysurgery is assisted by nurses and an anesthetist. this fact is modeled by assist activities that are related together with the respective surgery activities in parallel relationships. afterwards, the patient wakes up which has to be observed by the hospital staff and is represented as an activity in the workflow model. during the whole process the medication of the patient proceeds and has to be continuously documented. this fact is modeled by adjustmedication that activity is an iteration and thus can be executed several times during process execution. no further temporal constraints to other process fragments are to be observed here. ocl 2011 5 / 12 proc. ocl 2011 fig. 2. example process model with the abstract syntax provided by use 2.3 use design time plugin use is capable of storing the current snapshot of models. but use is not able to duplicate a snapshot in the object diagram. in the following a process and a developed plugin for use is proposed to enable the user to instantiate a workflow model several times. thus, instances of a process model can run in parallel after they have been instantiated. for this purpose a specialized plugin to use had to be developed. we call it “design time plugin” as this describes the time when it is applied in contrast to the “runtime plugin” that we introduce in subsection 3.1. it persistently stores the workflow model as assl instantiation procedures. a process developer will invoke the plugin after she completed modeling the workflow. the plugin provides a dialog to choose an assl file into which the assl instantiation procedure is generated. listing 1 shows parts of an assl instantiation procedure that was generated from our sample workflow model. when executed, the procedure recreates the objects and associations of the model shown in figure 2. furthermore, the states of the activity objects are set to the initial state waiting according to the state diagrams of the metamodel of figure 1. to use these instantiation procedures for executable workflows, another use plugin was developed, the “workflow runtime plugin”. among other things, in this plugin a user can select the desired assl file and the included workflow instantiation procedure to invoke it and consequently instantiate the workflow. original assl commands, as presented in [5], are sufficient for this purpose. only some procedures of the workflow execution require assl language extensions, which will be discussed in section 3. one characteristic of assl is the use of square brackets to enclose ocl expressions. they may contain and use assl variables declared and initialized earlier in that assl procedure. ocl expressions may become quite complex as, e.g., shown in listing 3. eceasst volume 44 (2011) 6 / 12 listing 1. excerpt of an assl workflow instantiation procedure procedure instantiateemergencyprocess() var a1:activity, a2:activity, d1:deferredchoice ...; begin a1 := create(activity); [a1].name := [‘helicopterdelivery’]; [a1].state := [#waiting]; a2 := create(activity); [a2].name := [‘ambulancedelivery’]; [a2].state := [#waiting]; d1 := create(deferredchoice); insert(group, [d1], [a1]); insert(group, [d1], [a2]); ... end; 3 workflow model execution this section introduces the execution of workflow models using the workflow runtime plugin. this plugin presents a workflow instance to its user in an appropriate way and provides a gui to invoke the assl procedures. subsection 3.2 introduces the assl extensions that provide the basis to implement the execution semantics of the workflow models. subsection 3.3 discusses the assl implementations for model execution. a non-plugin feature, but nevertheless very handy is use’s ability to log the assl procedure executions and present them as a sequence diagram. this is demonstrated in subsection 3.4. 3.1 workflow runtime plugin figure 3 is a screenshot of the workflow runtime plugin presenting an instance of the example workflow of figure 2. the activity list uses colors to indicate the state of each activity. the workflow plugin distinguishes between waiting and enabled activities. enabled activities appear in a light green color. waiting activities that are forbidden to be executed by ocl constraints are colored in a darker green color. the workflow plugin checks the enabled property of activities in a preprocessing step. currently, in the scenario of figure 3 the activity checkpatientcondition is running which is expressed by the blue color. this activity is a decision. this decision is to be made by the user, thus, a further interactive window is generated by the workflow plugin to request the user’s decision interactively. the available options or alternatives and its selection criteria are declared in the workflow model. having selected the appropriate criterion, the decision activity ought to be finished by clicking on the corresponding button at the bottom of figure 3. consequently the plugin invokes the assl finish procedure on the selected activity. those buttons represent the activity operations as shown in the metamodel of figure 1. assl is used to implement those operations. details on this matter are in subsection 3.3. ocl 2011 7 / 12 proc. ocl 2011 fig. 3. workflow runtime plugin showing a workflow instance 3.2 assl language extensions table 1 lists our assl extensions, primarily new commands. asslcall provides a command to invoke procedures. this provides the ability for recursive procedure calls. table 1. new assl commands new assl commands explanations asslcall (); calling another assl procedure (in the same assl file). the arguments are separated by comma. openter

(); enters an operation with the op-name in the context of the object identified by its oid. arguments are separated by comma. use checks the ocl preconditions. opexit; exits the running operation that lies on top of the (operation) call stack and use checks the ocl postconditions. openter steps into the given operation of a certain specified object. openter only checks the ocl preconditions of the declared operation and object, but is not executing the operation. instead it pushes the operation on top of the general (operation) call stack which is administered by use. command opexit specifies that the given operation is finished and the ocl postconditions ought to be checked. the developer can neither declare an object nor an operation to exit. the use environment checks the postconditions of the operation lying on top of the call stack. this is the last operation that was started with an openter command before. eceasst volume 44 (2011) 8 / 12 3.3 assl procedures for the workflow model execution several assl procedures implement the base operations of the workflow metamodel classes. some operations get overridden by specified implementations in subclasses. for example the start() operation of activity behaves differently than the start() operation of iteration. overriding operations is achieved by ordering the procedures in the assl file in a certain way. procedures with more specialized types as arguments are declared before the ones with more general types. the semantics of finding a procedure with a fitting signature is as follows. by invoking an assl procedure use parses the assl file top-down. the first procedure with a signature fitting to the called procedure name and passed on arguments, is selected for execution. thus, we would order a procedure start(i:iteration) before start(a:activity). then, if start() is invoked with an activity object the first signature would not fit but the second one does, so consequently start(a:activity) is used. ordering the procedures the other way round implies that start(a:activity) also fits with iteration objects because of the substitution principle [8]. consequently, use would never execute start(i:iteration) with iteration objects. listing 2. excerpt of the assl start procedure for class activity procedure start(a:activity) var seta:set(activity); begin -checking precondition of operation openter [a] start(); -changing state to running [a].state:=[#running]; for gr:group in [a.group->assequence] begin -skipping all deferred choice activities if [gr.oclistypeof(deferredchoice)] then begin seta := [gr.activity ->select(a2|a2.state=#waiting)]; for a2:activity in [seta->assequence] begin asslcall skip([a2]); end; end; -starting all parallel activities if [gr.oclistypeof(parallel)] then begin seta := [gr.activity->select(a2| a2<>a and a2.state<>#running)]; for a2:activity in [seta->assequence] begin asslcall start([a2]); end; end; end; ... opexit; end listing 2 shows an excerpt of the assl start(a:activity) procedure and demonstrates the use of the assl language extensions of table 1. at the beginning of this procedure the openter command causes the preconditions to be checked. then a change of the activity’s state is specified, from waiting to running. following up, side effects on other activities are ocl 2011 9 / 12 proc. ocl 2011 implemented. all activities related within the same deferredchoice group are skipped and all parallel activities are started. finally, the opexit command initiates the postconditions checks. as discussed earlier the ordering of assl-procedures in a command file is of importance. consequently, procedure finish(d:decision) precedes finish(a:activity) in the assl file. a call finish(checkpatientcondition) (see workflow model of figure 2) matches the assl procedure for decisions and use would select that implementation for execution. listing 3 declares the behaviour of it. a special characteristic of that procedure is that it causes side effects on subsequent activities. non-selected activities and groups of activities are skipped because they must not be executed afterwards. in contrast, selected activities are enabled for execution. listing 3. excerpt of the assl finish procedure for class decision procedure finish(d:decision) var setag:set(activitygroup), seta:set(activity); begin openter [d] finish(); [d].state := [#done]; -get all non-selected activities and groups setag:=[d.option->select(a| a[option].guard.selected <> true)]; -collect all non-selected activities seta:=[setag.oclastype(activity) ->select(isdefined()) ->union(setag.oclastype(group) ->select(isdefined()).activity)->asset()]; -skip all non-selected activities for a:activity in [seta->assequence] begin asslcall skip([a]); end; ... opexit; end; 3.4 uml sequence diagram showing the assl procedure calls figure 4 shows a scenario of a workflow execution. use has logged the assl commands openter and opexit as they occurred and presents the chronology of executed calls as a sequence diagram. this scenario, started with a helicopterdelivery. as shown in the start() procedure’s implementation all activities that are related in a deferredchoice were skipped implicitly. according to the assl implementation use skipped ambulancedelivery for this case. after arriving at the hospital, a doctor has checked the patient. finishing that decision activity caused any non-selected activity to be skipped. this semantic is implemented in the assl finish() procedure shown in listing 3. here, normalsurgery was skipped. calling the assl skip() procedure has the consequence that all parallel activities are skipped, too. thus, assistnormalsurgery is also skipped. the same applies for the start() and finish() operation of activity emergencysurgery and assistemergencysurgery. eceasst volume 44 (2011) 10 / 12 fig. 4. a workflow execution scenario shown in a uml sequence diagram 4 related work there exist several other languages that implement the uml action semantics, a well-known example is qvt [9]. kermeta [1] is an open source metamodelling environment that has been designed as an extension to the metadata language emof [9] with an action language for specifying semantics and behavior of metamodels. parallel to this work of extending assl, the ocl-based imperative programming language soil (simple ocl-based imperative language) has been developed [3] that can also be interpreted by the use tool. as mentioned in the introduction, assl can be used for semi-automatically generate snapshots of object diagrams in contrast to the languages listed above. for workflow modeling some metamodel-based approaches exist like for example the emf metamodel-based bflow [7] tool in which event-driven process chains (epc) are used as workflow language. bflow checks static properties of the workflow models but lacks execution semantics. execution semantics used with a metamodel approach for uml activity diagrams is presented in [4]. following the uml specification [10 (section 12)], this approach uses a petri net-like token flow semantics. in contrast, the approach presented in this paper is, to our knowledge, the only one that uses a pragmatic uml metamodel-based declarative approach to express the workflow patterns and execute the workflow models on basis of imperative assl code. ocl 2011 11 / 12 proc. ocl 2011 5 conclusion this article presented extensions of the assl language: (sub-) procedure calls as well as precondition checks on entering operations and postcondition checks on exiting are now possible with assl. the assl language extensions were introduced in the context of the metamodel-based workflow modeling and execution. the workflow approach comprises a declarative part with ocl invariants, preand postconditions and an imperative part with assl procedures for the model execution. use provides a modeling and a runtime environment for workflows. a newly developed workflow plugin to use presents the workflow instance to the developer in an appropriate way. by clicking on buttons that represent operations of the metamodel, the user invokes assl procedures implementing the selected activity. thus, the developer can execute scenarios and test dynamic control flow properties of its workflow models. use logs the scenarios as a sequence diagram to visualize the workflow executions for further analysis. references 1. baudry, b., nebut, c., le traon, y.: model-driven engineering for requirements analysis, 11th enterprise distributed object computing conference (edoc 2007), ieee international (2007) 2. brüning, j., gogolla, m., forbrig, p.: formally checking workflow properties using uml and ocl. 9th international conference on perspectives in business informatics research (bir 2010), springer, lnbip vol. 64 (2010) 3. büttner, f., gogolla, m.: reusing ocl in the definition of imperative languages. http://www.db.informatik.uni-bremen.de/publications/intern/fb_mg_soil_2010.pdf (accessed: 04/01/2011) 4. engels, g., soltenborn, c., wehrheim, h.: analysis of uml activities using dynamic meta modeling. conference on formal methods for open object-based distributed systems (fmoods 2006), springer, lncs vol. 4468 (2007) 5. gogolla, m., bohling, j., richters, m.: validating uml and ocl models in use by automatic snapshot generation. software and system modeling, 4(4):386–398 (2005) 6. gogolla, m., büttner, f., richters, m.: use: a uml-based specification environment for validating uml and ocl. science of computer programming, 69:27-34 (2007) 7. kühne, s., kern, h., gruhn, v., laue, r.: business process modeling with continuous validation, journal of software maintenance and evolution: research and practice, volume 22, issue 6-7, pages 547–566 doi: 10.1002/smr.517 (2010) 8. liskov, b., wing, w.: a behavioral notion of subtyping. acm transactions on programming languages and systems, 16:1811-1841 (1994) 9. object management group. meta object facility (mof) 2.0 query/view/transformation specification. omg document formal/08-04-03, (2008) http://www.omg.org/spec/mof/2.0/pdf (visited: 04/01/11) 10.object management group. unified modeling language (uml) version 2.3. omg document formal/2010-05-05 (2010) , http://www.omg.org/spec/uml/2.3/superstructure/pdf (accessed: 04/01/11) eceasst volume 44 (2011) 12 / 12 11.parr, t.: the definitive antlr reference guide: building domain-specific languages, pragmatic programmers (2007) 12.van der aalst, w.m.p., ter hofstede, a.h.m., kiepuszewski, b., barros, a.p.: workflow patterns. distributed and parallel databases, 14(3):5-51 (2003) 13.van der aalst, w., pesic, m., schonenberg, h.: declarative workflows balancing between flexibility and support. computer science research and development, 23(2):99–113, 2009. minimizing finite automata with graph programswork of the second and third author was done while visiting the university of york. funding by the department of computer science at york is gratefully acknowledged. electronic communications of the easst volume 39 (2011) graph computation models selected revised papers from the third international workshop on graph computation models (gcm 2010) minimizing finite automata with graph programs detlef plump, robin suri, and ambuj singh 15 pages guest editors: rachid echahed, annegret habel, mohamed mosbah managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst minimizing finite automata with graph programs∗ detlef plump1, robin suri2, and ambuj singh3 1 the university of york, uk 2 indian institute of technology roorkee, india 3 indian institute of technology kanpur, india abstract: gp (for graph programs) is a rule-based, nondeterministic programming language for solving graph problems at a high level of abstraction, freeing programmers from dealing with low-level data structures. in this case study, we present a graph program which minimizes finite automata. the program represents an automaton by its transition diagram, computes the state equivalence relation, and merges equivalent states such that the resulting automaton is minimal and equivalent to the input automaton. we illustrate how the program works by a running example and argue that it correctly implements the minimization algorithm of hopcroft, motwani and ullman. we also prove a quadratic upper bound for the number of rule schema applications used by the program. keywords: graph programs, automata minimization, rule-based programming, correctness proofs 1 introduction gp is an experimental nondeterministic programming language for high-level problem solving in the domain of graphs. the language is based on conditional rule schemata for graph transformation, freeing programmers from implementing and handling low-level data structures for graphs. the prototype implementation of gp compiles graph programs into bytecode for an abstract machine, and comes with a graphical editor for programs and graphs. we refer to [plu09] for an overview of the language and to [mp08] for a description of the current implementation. in this paper, we present a case study about solving a problem with gp that as first sight may not appear to be a graph problem: the minimization of finite automata. it is natural though to represent finite automata by their transition diagrams and to view the minimization process as a sequence of transformation steps on these diagrams. programmers can visually construct corresponding rule schemata and control the application of these schemata by gp’s commands. we implement the minimization algorithm of hopcroft, motwani and ullman [hmu07] (see also [sha09]). this algorithm first computes the indistinguishability relation among states, called state equivalence, and then merges equivalent states to obtain a minimal automaton that is equivalent to the input automaton. two states are equivalent if processing strings from either state will have the same result with respect to acceptance. while state equivalence is usually computed by a table-filling algorithm, in our case we directly connect equivalent states with special edges. once the equivalent states have been determined, we merge them by redirecting edges and removing isolated nodes. ∗ work of the second and third author was done while visiting the university of york. funding by the department of computer science at york is gratefully acknowledged. 1 / 15 volume 39 (2011) minimizing finite automata with graph programs in section 5, we argue that our implementation is correct in that the graph program will transform every input automaton into an equivalent and minimal output automaton. this involves showing that the program terminates, that it correctly computes the state equivalence relation, and that the merging phase produces an automaton in which each equivalence class of states is represented by a unique state. we also show, in section 6, that the maximal number of rule schema applications used by our program is quadratic in the size of the input automaton. this paper is a revised and extended version of [pss10]. 2 graph programs we briefly review gp’s conditional rule schemata and control constructs. technical details (including the abstract syntax and operational semantics of gp) can be found in [plu09], as well as a number of example programs. conditional rule schemata are the “building blocks” of graph programs: a program is essentially a list of declarations of conditional rule schemata together with a command sequence for controlling the application of the schemata. rule schemata generalise graph transformation rules in the double-pushout approach with relabelling [hp02], in that labels can contain expressions over parameters of type integer or string. figure 1 shows a conditional rule schema consisting of the identifier bridge followed by the declaration of formal parameters, the left and right graphs of the schema, the node identifiers 1, 2, 3 specifying which nodes are preserved, and the keyword where followed by the condition notedge(1,3). bridge(a,b,x,y,z: int) x 1 y 2 z 3 a b ⇒ x 1 y 2 3 z 3 a+b a b where notedge(1,3) figure 1: a conditional rule schema in the gp programming system [mp08], rule schemata are constructed with a graphical editor. labels in the left graph comprise only variables and constants because their values at execution time are determined by graph matching. the condition of a rule schema is a boolean expression built from arithmetic expressions and the special predicate edge, where all variables occurring in the condition must also occur in the left graph. the predicate edge demands the (non-)existence of an edge between two nodes in the graph to which the rule schema is applied. for example, the expression notedge(1,3) in the condition of figure 1 forbids an edge from node 1 to node 3 when the left graph is matched. conditional rule schemata represent possibly infinite sets of conditional graph transformation rules, and are applied according to the double-pushout approach with relabelling. a rule schema l⇒r with condition γ represents conditional rules 〈〈lα ←k →rα〉, γα,g〉, where k consists of gcm 2010 2 / 15 eceasst the preserved nodes (which are unlabelled) and γα,g is a predicate on graph morphisms g : lα → g (see [plu09]). gp’s commands for controlling rule-schema applications include the non-deterministic onestep application of a rule schema, the non-deterministic one-step application of a set {r1,...,rn} of rule schemata, the sequential composition p; q of programs p and q, the as-long-as-possible iteration p! of a program p, and the branching statement if c then p else q for programs c, p and q. the first four of these commands have the expected effects. the branching command first checks if executing c on the current graph g can produce a graph; if this is the case, then p is executed on g, otherwise q is executed on g. 1 2 3 4 1 2 3 → bridge! 1 2 3 4 1 2 3 36 5 figure 2: an execution of the program bridge! for example, figure 2 shows an execution of the program bridge!. this program makes an input graph transitive in that for every directed path of the input, the output graph contains an edge from the first node to the last node of the path. note that the edge with label 6 can be produced by applying bridge in two different ways, performing either the addition 3 + 3 or 1 + 5. in general, a program may produce many different output graphs for the same input. the semantics of gp assigns to every input graph the set of all possible output graphs (see [plu09, ps10]). 3 automata minimization our starting point is the abstract minimization algorithm of hopcroft, motwani and ullman [hmu07] (see also [sha09]). to fix notation, we consider a deterministic finite automaton (dfa) as a system a = (q,σ,δ ,q0,f) where q is the finite set of states, σ is the input alphabet, δ : q× σ → q is the transition function, q0 is the initial state, and f is the set of final (or accepting) states. the extension of δ to strings is denoted by δ∗ : q×σ∗→ q. definition 1 states p and q of an automaton are equivalent if for all strings w ∈ σ∗, δ∗(p,w)∈ f if and only if δ∗(q,w) ∈ f . note that this indeed defines an equivalence relation. we say that states p and q are distinguishable if they are not equivalent, that is, there must be some string w ∈ σ∗ such that either δ∗(p,w) ∈ f and δ∗(q,w) /∈ f , or vice-versa. the following minimization algorithm first marks all unordered pairs of distinguishable states of an automaton a—thus representing state equivalence implicitly by all unmarked pairs of states. in a second phase, equivalent states are merged to form the states of the minimal automaton â. 3 / 15 volume 39 (2011) minimizing finite automata with graph programs algorithm 1 ([hmu07]) marking phase stage 1: for each p ∈ f and q ∈ q−f do mark the pair {p,q} stage 2: repeat for each non-marked pair {p,q} do for each a ∈ σ do if {δ (p,a), δ (q,a)} is marked then mark {p,q} until no new pair is marked {for each state p, the equivalence class of p consists of all states q for which the pair {p,q} is not marked.} merging phase construct â = (q̂,σ,δ̂ ,q̂0,f̂) as follows: – q̂ consists of the state equivalence classes. – q̂0 is the equivalence class containing q0. – for each x ∈ q̂ and a ∈ σ, pick any p ∈ x and set δ̂ (x,a) = y , where y is the equivalence class containing δ (p,a). – f̂ consists of the equivalence classes containing states from f . by the following lemma, the marking phase of algorithm 1 correctly computes the state equivalence. lemma 1 ([hmu07, sha09]) a pair of states is not marked by the marking phase of algorithm 1 if and only if the states are equivalent. using lemma 1, the correctness of algorithm 1 can be established. theorem 1 ([hmu07]) the automaton â produced by algorithm 1 accepts the same language as a and is minimal. in the next section, we present an implementation of algorithm 1 in gp. the correctness of the implementation is proved in section 5. 4 implementation in gp we represent automata by their transition diagrams, that is, graphs in which nodes represent states and edges represent transitions. in the following, the terms ‘node’ and ‘state’, respectively ‘edge’ and ‘transition’ will often be used synonymously. we make the following assumptions about an input automaton: gcm 2010 4 / 15 eceasst 1. the states have labels of the form x i, where x is some integer and i ∈{0,1}. the component i is called a tag1, we require that final states have tag 1 and that non-final states have tag 0. the integer x is arbitrary, except that the initial state, and only this state, has a label of the form 1 i. 2. the transitions are labelled with strings which represent the symbols in σ. 3. to keep the presentation simple, we assume that all states are reachable from the initial state. (it is straightforward to write a graph program that removes all unreachable states.) the graph program implementing algorithm 1 is shown in figure 3, where mark, merge and clean up are macros. the rule schemata contained in the macros are discussed below. main = mark; merge; clean up mark = distinguish!; propagate!; equate! merge = init; add tag!; (choose; add tag!)!; disconnect!; redirect! clean up = remove edge!; remove node!; untag! figure 3: gp program for automata minimization we will explain each stage of the program in figure 3, using as running example the minimization of the automaton in figure 4. this automaton accepts all strings over {a,b} that end in two b’s. 1 0 3 0 4 1 2 0b a b a b a a b figure 4: sample automaton with alphabet {a,b} 4.1 marking phase we first need to determine which states are equivalent. for this, we implement the marking phase of algorithm 1 in the macro mark. the macro’s rule schemata are shown in figure 5. the subprogram distinguish! implements stage 1 of algorithm 1. given two states such that one is a final state and the other is not, by assumption, the states carry tags 1 and 0 respectively. in this case we mark the states as distinguishable by connecting them with two 1labelled edges of opposite direction (drawn as a single edge with two arrowheads). the condition notedge(1,2,1) in distinguish forbids a 1-labelled edge between nodes 1 and 2 to make sure that distinguish! terminates. the ternary edge predicate refines the binary predicate 1 in general, a label in gp has the form x1 x2 ... xnwhere each xi is either an integer or a character string. 5 / 15 volume 39 (2011) minimizing finite automata with graph programs distinguish(x,y,i,j: int) x i 1 y j 2 ⇒ x i 1 y j 2 1 where i 6= j and notedge(1,2,1) propagate(x,y,u,v,i,j,m,n: int;s: str) x i 1 u m 3 y j 2 v n 4 s s 1 ⇒ x i 1 u m 3 y j 2 v n 4 s s 11 where notedge(1,2,1) all matches equate(x,y,i,j: int) x i 1 y j 2 ⇒ x i 1 y j 2 0 where notedge(1,2,1) and notedge(1,2,0) figure 5: rule schemata of the macro mark discussed in section 2 in that it allows to specify the label of the forbidden edge.2 see figure 6 for the effect of distinguish! on the sample automaton, where we typeset new labels in italics. next, the rule schema propagate looks for pairs of states that have not yet been discovered as distinguishable (and so are not linked by a 1-edge). the states must have outgoing transitions with the same symbol, leading to states that have already been discovered as distinguishable. again, a newly discovered pair of distinguishable states is marked by 1-labelled edges with opposite directions. the subprogram propagate! thus implements the repeat-loop of algorithm 1. rule schema propagate has the ‘all matches’ attribute, meaning that nodes of the schema can be merged before the schema is applied. an alternative view is that propagate can be applied using non-injective graph morphisms. (see [hmp01] for details and the equivalence of both views.) for the benefit of the reader, figure 7 lists the standard rule schemata represented by propagate that are possibly applicable to an automaton. other schemata obtained by node merging can be ruled out because our automata do not contain 1-labelled loops and do not have 2 this predicate is not yet implemented in gp but will be included in the next release. gcm 2010 6 / 15 eceasst 1 0 3 0 4 1 2 0b a b a b a a b 1 1 1 figure 6: sample automaton after distinguish! states with multiple outgoing transitions labelled with the same symbol. lemma 1 guarantees that after termination of propagate!, all pairs of distinguishable states have been discovered. thus we can mark the remaining pairs as equivalent, linking their states with 0-labelled edges in the subprogram equate!. the effect of propagate! and equate! on the sample automaton is shown in figure 8a and figure 8b. we remark that 0-edges create a structure similar to the “equivalent states layer” in the fire station tool for regular language visualisation [fcw05]. 4.2 merging phase after termination of the macro mark, the states of the input automaton are partitoned into equivalence classes: these are the subsets of states that are pairwise linked by 0-labelled edges. next we have to merge all the states in each partition into one state representing the partition. we need to ensure that all transitions to states that are not representing partitions are redirected to the unique states representing the partitions. transitions outgoing from non-representative states can be removed, as can these states themselves. the merging process is implemented by the macro merge, whose rule schemata are shown in figure 9. we first consider the partition containing the initial state. the rule schema init marks this state as the unique representative of its partition by adding an extra 0-tag to the state’s label. then the loop add tag! marks all other states in the initial partition with an extra 1-tag. this marking procedure is repeated for all other partitions, by the nested loop (choose; add tag!)!. in each iteration of the outer loop, some unmarked state is chosen as the unique representative of its partition and subsequently all other states in the partition are marked as non-representative states. after all states have been marked as representatives or non-representatives, the rule schemata disconnect and redirect take care of the transitions leaving and reaching non-representative states. the loop disconnect! removes all outgoing transitions (including loops), as these are no longer needed, while redirect! redirects each transition reaching a non-representative state to the unique representative of that state’s partition. note that by the ‘all matches’ attribute of redirect, transitions between equivalent states become loops at the representatives. the effect of init; add tag! and the whole macro merge on the sample automaton is shown in figure 8c and figure 8d. 7 / 15 volume 39 (2011) minimizing finite automata with graph programs propagate 1(x,y,u,v,i,j,m,n: int; s: str) x i 1 u m 3 y j 2 v n 4 s s 11 ⇒ x i 1 u m 3 y j 2 v n 4 s s 111 where notedge(1,2,1) propagate 2(x,u,v,i,m,n: int; s: str) x i 1 u m 3 v n 4 s s 11 ⇒ x i 1 u m 3 v n 4 s s 11 1 where notedge(1,4,1) propagate 3(x,u,v,i,m,n: int; s: str) x i 1 u m 3 v n 4 s 1 s ⇒ x i 1 u m 3 v n 4 s 1 1 s where notedge(1,3,1) figure 7: rule schemata represented by propagate using ‘all matches’ finally, the rule schema clean up exhaustively applies the rule schemata shown in figure 10. the loop remove edge! deletes all integer-labelled edges, as these auxiliary structures are no longer needed. then remove node! deletes all non-representative states—these states have become isolated. the remaining states are the unique representatives of their equivalence classes. last but not least, untag! removes the auxiliary second tag of each state so that the remaining tag indicates, as before, whether a state is final or not. the resulting automaton is the unique minimal automaton equivalent to the input automaton (see next section). the automata resulting from remove edge! and the overall program in our running example are shown in figure 8e and figure 8f. gcm 2010 8 / 15 eceasst 1 0 3 0 4 1 2 0b a b a b a a b 1 1 1 1 1 (a) after propagate! 1 0 3 0 4 1 2 0b a b a b a a b 1 1 1 1 10 (b) after equate! 1 0 0 3 0 1 4 1 2 0b a b a b a a b 1 1 1 1 10 (c) after init; add tag! 1 0 0 3 0 1 4 1 0 2 0 0b b b 1 1 1 1 10 a a a (d) after redirect! 1 0 0 3 0 1 4 1 0 2 0 0 b b b a a a (e) after remove edge! 1 0 4 1 2 0 b b b a a a (f) after untag! figure 8: snapshots of the sample automaton 5 correctness of the implementation in this section we argue that the graph program of figure 3 correctly implements algorithm 1. lemma 2 the program of figure 3 terminates for every input automaton. proof. by the conditions of the rule schemata distinguish and propagate, each application of these schemata reduces the number of state pairs that are not linked by 1-labelled edges 9 / 15 volume 39 (2011) minimizing finite automata with graph programs init(i: int) 1 i 1 ⇒ 1 i 0 1 add tag(x,y,i,j: int) x i 0 1 y j 2 0 ⇒ x i 0 1 y j 1 2 0 choose(x,i: int) x i 1 ⇒ x i 0 1 disconnect(x,u,i,m,p: int; s: str) u m p 2 x i 1 1 s ⇒ u m p 2 x i 1 1 all matches redirect(x,y,u,i,j,m: int; s: str) u m 0 2 x i 1 1 y j 0 3 s 0 ⇒ u m 0 2 x i 1 1 y j 0 3 s 0 all matches figure 9: rule schemata of the macro merge of opposite direction. similarly, each application of equate reduces the number of state pairs that are not linked by 0-labelled edges of opposite direction. thus the macro mark terminates. each application of the rule schema add tag reduces the number of states that do not have gcm 2010 10 / 15 eceasst remove edge(x,y,i,j,k,m,n: int) x i k 1 y j m 2 n ⇒ x i k 1 y j m 2 remove node(x,i: int) x i 1 ⇒ /0 untag(x,i: int) x i 0 1 ⇒ x i 1 figure 10: rule schemata of the macro clean up a label of the form x i 1, where x and i are integers. hence both the first loop add tag! and the nested loop (choose; add tag!)! terminate (note that choose does not affect labels of the form x i 1). the loop disconnect! is trivially terminating as each application of disconnect reduces the number of edges in a graph. the loop redirect! terminates because each application of redirect reduces the sum of the degrees of nodes with a label of the form x i 1. thus the macro merge terminates, too. the termination of the three loops in the macro clean up is similarly easy to see. the rule schemata of the first two loops reduce the number of edges respectively the number of nodes, and each iteration of the loop untag! reduces the number of nodes with three tags. lemma 3 the macro mark links two distinct states by a 0-labelled edge if and only if the states are equivalent. proof. the loop distinguish! implements stage 1 of the marking phase of algorithm 1 in that it links final states with non-final states by a 1-labelled edge, marking such pairs as nonequivalent. also, propagate! implements stage 2 of the marking phase: the three standard rule schemata represented by propagate (see figure 7) cover the possible relations between the state pairs {p,q} and {δ (p,a), δ (q,a)} in the repeat-loop of algorithm 1. in particular, they cover the special cases p = δ (p,a), q = δ (q,a), p = δ (q,a) and q = δ (p,a). hence lemma 1 implies that after termination of propagate!, two states are linked by a 1-labelled edge if and only if they are not equivalent. the loop equate! then links two distinct states by a 0-labelled edge if and only if they are not linked by a 1-labelled edge, implying the proposition. lemma 4 after termination of the macro clean up, two states are equivalent if and only if they are equal. 11 / 15 volume 39 (2011) minimizing finite automata with graph programs proof. consider an equivalence class of states of the input automaton. exactly one state in this class is selected either by the rule schema init (in the case of the initial state’s class) or by the rule schema choose (in all other cases), and a 0-tag is appended to the state’s label. then the loop add tag! marks all other states in the equivalence class with an extra 1-tag. subsequently, disconnect! removes all transitions outgoing from 1-tagged states and redirect! redirects away all transitions leading to 1-tagged states. hence, after termination of the macro merge, 1-tagged states can be incident only to edges labelled with 0 or 1. all these edges are deleted by the loop remove edge!, so the 1-tagged states become isolated and are eventually removed by remove node!. thus, upon termination of the macro clean up, from each equivalence class exactly one state remains in the resulting automaton. theorem 2 for every input automaton a, the automaton â produced by the program of figure 3 is equivalent to a and minimal. proof. by theorem 1, lemma 2 and lemma 3, it suffices to show that the subprogram merge; clean up correctly implements the merging phase of algorithm 1. this can be seen as follows: • by lemma 4, each equivalence class of a is represented by its unique representative element in â. • the rule schema init selects the initial state of a as the representative of its class and untag makes this state the initial state of â. • consider any equivalence class of states x , its representative p ∈ x and any a ∈ σ. if δ (p,a) is the representative of its equivalence class, then both states are marked with a 0-tag in merge and the transition from p to δ (p,a) is preserved by the subprogram disconnect!; redirect!. otherwise, if δ (p,a) does not represent its class, then it is marked with a 1-tag in merge. in this case redirect! redirects the transition p → δ (p,a) to the unique representative of the class of δ (p,a). hence δ̂ (x,a), the equivalence class of δ (p,a), does not depend on the choice of p and thus is well-defined. • in an equivalence class containing a final state, all states are final as otherwise the loop distinguish! would have linked the non-final states with the final state by 1-labelled edges. hence the representative of such a class is a final state. 6 time complexity in this section we establish an upper bound for the number of rule schema applications of the minimization program, in terms of the size of the input automaton. this provides a worst-case estimate for the running time of our program, where we abstract from the cost of rule schema matching.3 3 the complexity of rule schema matching is beyond the scope of this paper. gcm 2010 12 / 15 eceasst as before, let σ be the alphabet of an input automaton and q its set of states. we show that each loop in the program of figure 3 terminates after at most |q|2 or |σ|·|q| rule schema applications. in the following lemmata, n always refers to the number of states (nodes) in an input automaton. our proofs tacitly rely on the fact that none of the rule schemata of the minimization program increases the number of nodes in a graph. lemma 5 the loops distinguish!, propagate! and equate! each terminate after at most n2 rule schema applications. proof. given a graph x , let #x be the number of pairs 〈u,v〉 of nodes such that there is no edge with label 1 from u to v. then #x ≤ n2 and for every step g→distinguish h and g→propagate h , we have #g > #h . this implies the claim for distinguish! and propagate!. the same argument works for equate! if we redefine #x as the number of pairs 〈u,v〉 such that there is no edge with label 0 from u to v. lemma 6 the loops add tag! and (choose;add tag!)! each terminate after at most n rule schema applications. proof. given a graph x , let #x be the number of nodes with a label of the form i j, where i and j are integers. then #x ≤ n and every step g →add tag h and g →choose h satisfies #g > #h . this implies the claim. the complexity of the loops for disconnecting nodes and redirecting edges depends not only on the number of nodes (states) but also on the size of the alphabet σ. lemma 7 the loops disconnect! and redirect! each terminate after at most |σ| ·n rule schema applications. proof. each node of an input automaton has |σ| outgoing edges labelled with symbols from σ (represented as strings), and no rule schema removes or creates such edges before disconnect! is executed. hence disconnect! terminates after |σ| ·n rule schema applications. given a graph x , let #x be the number of σ-labelled edges whose target nodes have labels of the form i j 1 for some integers i and j. then #x ≤|σ|·n and every step g →redirect h satisfies #g > #h . hence redirect! terminates after at most |σ| ·n rule schema applications. lemma 8 the loop remove edge! terminates after at most n2 rule schema applications. proof. the following invariant of the minimization program is easy to prove: in each graph of a computation, each pair of distinct nodes is connected by at most one pair of opposite edges labelled with 1 or 0. (note that an input automaton does not possess such edges.) this invariant clearly implies the claim. lemma 9 the loops remove node! and untag! each terminate after at most n rule schema applications. proof. the claim is obvious in the case of remove node. for untag, it follows from the fact 13 / 15 volume 39 (2011) minimizing finite automata with graph programs that every step g →untag h reduces the number of nodes labelled i j k for some integers i, j and k. summarising the above lemmata, we can see that the number of rule schema applications used by the minimization program is quadratic in the size of the input automaton. theorem 3 the program of figure 3 terminates after at most o(|q|2 + |σ| · |q|) rule schema applications. 7 conclusion we have shown how to minimize finite automata with rule-based, visual programming. programmers need not be concerned with low-level data structures such as state tables but can directly manipulate the transition diagrams of automata. moreover, gp’s rule schemata and control constructs provide a convenient language for reasoning about the correctness and the complexity of the implementation. last but not least, the all matches option for rule schemata has proved to be useful for keeping the number of rule schemata small, and an extended edge predicate has been crucial for forbidding particular edges in the conditions of rule schemata. the macro merge merges equivalent states by choosing representatives of equivalence classes, removing and redirecting transitions, and removing isolated states. a simpler implementation would use non-injective rule schemata to merge states directly—but such rule schemata are not available in gp. non-injective rule schemata are also useful in other applications and may be realised in a future version of gp. finally, this case study could be extended by implementing more efficient automata minimization algorithms. we chose the algorithm of hopcroft, motwani and ullman because of its simplicity, but its cubic running time is not optimal. more efficient algorithms include the quadratic algorithm of hopcroft and ullman [hu79] and hopcroft’s nlogn algorithm [hop71]. acknowledgements: we are grateful for the comments of the anonymous referees which helped to improve the presentation of this paper. bibliography [fcw05] m. frishert, l. g. cleophas, b. w. watson. fire station: an environment for manipulating finite automata and regular expression views. in implementation and application of automata (ciaa 2004), revised selected papers. lecture notes in computer science 3317, pp. 125–133. springer-verlag, 2005. [hmp01] a. habel, j. müller, d. plump. double-pushout graph transformation revisited. mathematical structures in computer science 11(5):637–688, 2001. [hmu07] j. e. hopcroft, r. motwani, j. d. ullman. introduction to automata theory, languages, and computation. addison-wesley, third edition, 2007. gcm 2010 14 / 15 eceasst [hop71] j. e. hopcroft. an nlogn algorithm for minimizing the states in a finite automaton. in kohavi (ed.), the theory of machines and computations. pp. 189–196. academic press, 1971. [hp02] a. habel, d. plump. relabelling in graph transformation. in proc. international conference on graph transformation (icgt 2002). lecture notes in computer science 2505, pp. 135–147. springer-verlag, 2002. [hu79] j. e. hopcroft, j. d. ullman. introduction to automata theory, languages, and computation. addison-wesley, 1979. [mp08] g. manning, d. plump. the gp programming system. in proc. graph transformation and visual modelling techniques (gt-vmt 2008). electronic communications of the easst 10. 2008. [plu09] d. plump. the graph programming language gp. in proc. algebraic informatics (cai 2009). lecture notes in computer science 5725, pp. 99–122. springer-verlag, 2009. [ps10] d. plump, s. steinert. the semantics of graph programs. in proc. rule-based programming (rule 2009). electronic proceedings in theoretical computer science 21, pp. 27–38. 2010. [pss10] d. plump, r. suri, a. singh. minimizing finite automata with graph programs. in proc. graph computation models (gcm 2010). ctit workshop proceedings wp 2010-05, pp. 97–110. university of twente, 2010. [sha09] j. shallit. a second course in formal languages and automata theory. cambridge university press, 2009. 15 / 15 volume 39 (2011) introduction graph programs automata minimization implementation in gp marking phase merging phase correctness of the implementation time complexity conclusion non-deterministic matching algorithm for net transformations electronic communications of the easst volume 68 (2014) proceedings of the 8th international workshop on graph-based tools (grabats 2014) non-deterministic matching algorithm for net transformations mathias blumreiter and julia padberg 14 pages guest editors: matthias tichy, bernhard westfechtel managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst non-deterministic matching algorithm for net transformations mathias blumreiter1 and julia padberg2 1 technical university hamburg-harburg, germany 2 hamburg university of applied sciences, germany julia.padberg@haw-hamburg.de abstract: modeling and simulating dynamic systems require to represent their processes and the system changes within one model. to that effect, reconfigurable petri nets consist of a place/transition net and a set of rules that can modify the petri net. the application of a rule is based on finding a suitable match of the rule in the given net. this match is an isomorphic subnet that has to be located meeting requirements of the rule application as well as the simulation. in this paper a non-deterministic algorithm is presented for the matching in reconfigurable petri nets. it is an extension of the vf2 algorithm for graph (sub-)isomorphisms. we show that this extension is correct and complete. non-determinism ensures that during simulation different matches can be found for each transformation step and is hence crucial for the simulation. but non-determinism has not been present in the vf2 algorithm. for the matching algorithm non-determinism is proven. keywords: reconfigurable petri nets, matching algorithm, non-determinism, simulation, net transformation 1 introduction motivation for reconfigurable petri nets, a family of formal modeling techniques (e.g., in [ep03, lo04, kcd10]) is the observation that in increasingly many application areas the underlying system has to be dynamic in a structural sense. complex coordination and structural adaptation at run-time (e.g., mobile ad-hoc networks, communication spaces, ubiquitous computing) are main features that need to be modeled adequately. the distinction between the net behavior and the dynamic change of its net structure is the characteristic feature that makes reconfigurable petri nets so suitable for systems with dynamic structures. reconfigurable petri nets consist of marked petri nets, i.e., a net with a marking, and a set of rules whose application modifies the net’s structure at runtime. for the sake of the main focus we subsequently consider only a small and abstract example. more complex nets and rules can be found in case studies for the applications of reconfigurable petri nets (see [gab14, mod12, rei12]). as an example of a dynamic system we use a cyclic process that can either be executed or modified. these modifications change the process by inserting additional sequential steps using rule sequential_ext in fig. 1(a) or by forking into parallel steps rule parallel_ext in fig. 1(b). the colors of the places and transitions indicate the mappings within the rule. the net in fig. 2(a) describes a cyclic process that can execute one step and then returns to the start. the left-hand side of the rule is the net l and shows the places 1 / 14 volume 68 (2014) mailto:julia.padberg@haw-hamburg.de non-deterministic matching algorithm for net transformations (a) rule sequential_ext (b) rule parallel_ext figure 1: rules that need to be in the context and the transition that is deleted. in the right hand side of the rule is the net r and shows the added place and transitions as well as the context. for reasons of space we have omitted the intermediate net k that denotes the context explicitly. the rule sequential_ext is the first rule that can be applied by matching l in net start_net in fig. 2(a). reconfigurable petri nets allow the application of these rules together with the firing of the transitions. let the application of rule sequential_ext_s be the first step, followed by a firing step. this results in the net in fig. 2(b). the resulting net has an additional place and an additional transition, denoting the process to have been modified by inserting a sequential step. moreover, the next step has already been executed by firing the transition in the post-domain of the first place. these steps are chosen non-deterministically, so the start net in fig. 2(a) may evolve in 20 steps to the net in fig. 2(c) by firing transitions or applying rules. (a) net start_net (b) net after 2 steps (c) net after 20 steps figure 2: start and intermediate nets proc. grabats 2014 2 / 14 eceasst the simulation of reconfigurable petri nets has to cover the full behavior. if this is not the case, not all possible runs can be simulated and the simulation is not coherent with the semantics of reconfigurable petri nets. hence, it is crucial that the search of the match is non-deterministic. the match is the occurrence of a left hand side l of a rule to a target net n and is given by an injective net morphism. so, the main contribution of this paper is the presentation and implementation of the non-deterministic algorithm pnvf2. this algorithm is an adaption of the vf2 algorithm [cfsv04b] for subgraph isomorphism, because a match, that is the injective occurrence morphism, can be considered to be equivalent to a net l being isomorphic to subnet of n. the pnvf2 algorithm is correct and complete and in contrast to the vf2 algorithm it is non-deterministic. the paper is organized as follows: first we define reconfigurable petri nets based on place/ transition nets. in the next section we outline the algorithm, called pnvf2, that finds nondeterministically a match of the left hand side of a given rule in a given net. we explain its main function and the data structures for the representation of the state space. in section 4 we show that the algorithm is correct and complete, state its non-determinism and discuss its complexity. n section 5 we then discuss related and ongoing work. 2 reconfigurable petri nets we use the algebraic approach to petri nets, so a marked place/transition net is given by n = (p,t, pre, post,m) with preand post-domain functions pre, post : t → p⊕ and a marking m∈ p⊕, where p⊕ is the free commutative monoid over the set p of places. markings m1,m2 ∈ p⊕ are given by multisets or linear sums of places, defined by the free commutative monoid over the set p of places. accordingly, we can extend relations (≤), addition (⊕) and substraction ( ) to markings. e.g., we have m1 ≤ m2 if m1( p) ≤ m2( p) for all p ∈ p. a transition t ∈ t is m-enabled for a marking m ∈ p⊕ if we have pre(t) ≤ m, and in this case the follower marking m′ is given by m′ = m pre(t)⊕ post(t) and m[t〉m′ is called firing step. to obtain the weight of an arc from a place to a transition t the pre-domain function is restricted to that place, i.e. pre(t)|p = λp ∈n for pre(t) = ∑ p∈p λp p; analogously the weight of an arc from a transition to a place is given by the restriction of the post-domain function. note, that in [blu13] as well as reconnet1 decorated nets are considered. for the sake of brevity we here merely consider place/transition nets. place/transition nets yield an m-adhesive hlr category. m-adhesive hlr systems can be considered as a unifying framework for graph and petri net transformations providing enough structure that most notions and results from algebraic graph transformation systems are available: results on parallelism and concurrency of rules and transformations, results on negative application conditions and constraints, and so on (e.g., in [eept06]). net morphisms are given as a pair of mappings for the places and the transitions, so that the structure and the decoration and the marking are preserved. so, a net morphism f : n1 → n2 between two place/transition nets ni = (pi,ti, prei, posti,mi,) for i ∈{1,2} is given by f = ( fp : p1 → p2, ft : t1 → t2), so that pre2◦ ft = f ⊕p ◦ pre1 and post2◦ ft = f ⊕ p ◦ post1 and m1( p) ≤ m2( fp( p)) for all p ∈ p1. moreover, the morphism f is called strict if both fp and ft are injective and m1( p) = m2( fp( p)) holds for all p ∈ p1. 1 the tool reconnet has been developed at the haw hamburg in various students projects (see [ehop12]). 3 / 14 volume 68 (2014) non-deterministic matching algorithm for net transformations a rule in the dpo-approach given by three nets called left hand side l, interface k and right hand side r, respectively, and a span2 of two strict net morphisms k → l and k → r. then a match (or occurrence) morphism o : l → n is required that identifies the relevant parts of the left hand side in the given net n. then a transformation step n (r,o) =⇒ n′ via rule r can be constructed in two steps. given a rule with a match o : l → n the gluing conditions have to be satisfied in order l o �� (1) koo // �� (2) r �� n doo // n′ figure 3: net transformation to apply a rule at a given match. these conditions ensure the result is again a well-defined net. in this case, we obtain a net n′ leading to a direct transformation n (r,o) =⇒ n′ consisting of the pushouts (1) and (2) in the category of place/transition nets (see fig. 3). so, we combine one place/transition net n together with a set of net transformation rules leading to reconfigurable place/transition nets. definition 1 (reconfigurable nets) a reconfigurable place/transition net rn = (n,r) is given by a place/transition net n and a set of net transformation rules r. 3 matching algorithm pnvf2 in this section we outline an algorithm that finds a match of a left hand side l of a rule in a given net n. this match being an injective net morphism implies specific requirements the algorithm has to satisfy the preservation of the net structure, that is preservation of the transitions preand post-domain as well as the preservation of the marking. it has to discover only adequate matches with respect to gluing conditions and it has to deliver correct matches, including the possibility of delivering all matches and ensuring the non-determinism of the simulation. for graphs one of the efficient algorithms for subgraph isomorphism is the vf2 that allows the satisfaction of the above mentioned requirements. 3.1 outline of the algorithm the adaptation of the vf2 algorithm [cfsv04b] to petri nets, called pnvf2 algorithm [blu13], uses of an intricate data structure. in contrast to the vf2 algorithm the pnvf2 algorithm needs to consider the preand post-domain of transitions. given two nets n j = (p j,t j, pre j, post j,m j) for j ∈ {1,2} with preand post-domain functions pre j, post j : t → p⊕ we are looking for an injective morphism, the match m = (mp : p1 → p2, mt : t1 → t2). for convenience we use m as a relation m = {(v,w) | v 7→ w} as well, especially the two sets m1 = {v | (v,w) ∈ m} and m2 = {w | (v,w) ∈ m}. as a small example (in subsect. 3.2) we consider the nets given in fig. 4 on page 9 and search a match of n1 in n2, where the indices of places and transitions represent an fixed, but arbitrary order. the match is computed by searching recursively the possible mappings of places and transitions. in the algorithm the match m describes an injective partial morphism defined by the 2 actually, reconnet implements the co-span dpo approach, but for the matching algorithm this is irrelevant . proc. grabats 2014 4 / 14 eceasst current match. for the computation of the match m the pnvf2 performs a recursive depth-first search. the possible mappings of the nodes constitute the search space. at each level of recursion, the algorithm tries to map a source node from net n1 to different target nodes in n2. for the computation of the match we do not differentiate between places and transitions, as the search space is a combination of the place and the transition mappings. at each recursion level only one type of nodes, either places or transitions, is investigated. the node type is chosen nondeterministically, yielding candidate pairs of places or transitions. these are possible mappings and they are checked for feasibility. this feasibility comprises several conditions that ensure the preservation of the net structure, that is preservation of the transitions preand post-domain and the preservation of the marking. for each state s of the matching process there is a corresponding partial match m(s) = (mp(s) : p1 → p2, mt (s) : t1 → t2), which contains only a subset of the complete m. algorithm 1 pnvf2 establish arbitrary order for places and for transitions in both nets initialize m(s0) = ∅ initialize arrays core,in and out function match( intermediate state si) if (p1 ∪t1) = m1(si) then match m(si) is complete return . termination with a match else compute terminal and residual node sets compute set of candidate pairs p(si) for all (v,w) ∈ p(si) do if f easible(si,v,w) = true then compute si+1 by m(si+1) = m(si)∪{(v,w)} update arrays core,in and out match(si+1) restore arrays core,in and out end if end for if i > 0 then backtrack to si−1 else no match found return . termination without a match end if end if end function after the successful mapping of a candidate the algorithm examines a new pair at the next recursion level. in this way increasing parts of the match are computed. at each recursion level 5 / 14 volume 68 (2014) non-deterministic matching algorithm for net transformations the terminal and the residual node sets are computed. for j ∈ {1,2} the sets t in|outp j|t j (s) 3are based on the inand outgoing arcs (in or out) of the current match to places and transitions for the view from net n1 or net n2. e.g., t outp1 (s) = {p ∈ (p1 − m1) | p ≤ post1(t) for t ∈ m1(s)} is the set of places, that are reached from the nodes (i.e., transitions) of net n1, that already belong to the current partial match m(s). the corresponding terminal sets t termj (s) = t in p j (s)∪t outp j (s)∪ t int j (s)∪t out t j (s) unite the inand outgoing places and transitions. the residual node sets p̃ j|t j contain those nodes of n j for j ∈ {1,2} that are neither in the current match nor connected to any node of the current match, e.g., p̃2(s) = p2 − m2(s)−t term2 (s). based on these sets the set of candidate pairs is computed. according to the pre-defined order, that has been fixed during initialization, the smallest place and the smallest transition of net n1 is examined next. the possible candidate pairs of terminal nodes are given by pt in|outx = {min t in|outx1 (s)}×t in|out x2 (s) for x ∈ {p,t}. analogously, the possible candidate pairs of residual nodes are given for x ∈ {p,t} by px̃ = {min x̃1(s)}× x̃2(s). for the example (in subsect. 3.2) the empty match of the first state s0 is given by m(s0) = ∅ and p(s0) = pp̃(s0) = {( p1, pa),( p1, pb),( p1, pc)} and the first candidate is the pair ( p1, pa), as p1 and pa are the first places of the corresponding order. the pnvf2 examines the terminal out sets pt outp and pt outt first. if they are empty, the candidates given in the terminal in sets pt inp and pt int are used. lastly, the candidates of the residual node sets are considered for x ∈ {p,t}: p(s) =  pt outx (s) if pt outp (s)∪pt outt (s) ,∅ pt inx (s) if pt out p (s)∪pt outt (s) = ∅∧pt inp (s)∪pt int (s) ,∅ px̃ (s) if pt outp (s)∪pt outt (s) = ∅∧pt inp (s)∪pt int (s) = ∅ (1) for the candidate pair ( p1, pa) from the example (in subsect. 3.2) we have p(s1) = pt outt (s1) = {t1}, pt int (s1) = {t2} and pt̃ (s1) = {t3} in state s1. since petri nets are bipartite, the corresponding sets for places are empty. these candidate pairs are not necessarily matching pairs. similarly to vf2 [cfsv04b], the feasibility function preserves the net structure and prunes the search space. f easible(s,v,w) depends on the state s and a candidate pair (v,w) ∈ p(s), that is either a pair of places or a pair of transitions, so for x ∈ {p,t} we have f easible(s,v,w) = f easiblex (s,v,w) with (v,w) ∈ x1 ×x2. the conditions for the feasibility are presented in six rules (see [blu13]), which may differ for places and transitions defined below. the first rules are concerned with the preservation of the net structure, so that the found match is an injective net morphism. • rulesem,p states that the marking needs to preserved. • rulesem,t states that the number of inand outgoing arcs of both transitions must be the same. rulesem,p ≡ m1( p1) ≤ m2( p2) rulesem,t ≡ cardpre1 (t1) = cardpre2 (t2)∧cardpost1 (t1) = cardpost2 (t2) (2) 3 t in|outp j|t j is a short notation for t in p j , t outp j , t in t j or t outt j . proc. grabats 2014 6 / 14 eceasst • rulepred,p and rulepred,t examine the predecessors of the candidate pair. rulepred,p(s, p1, p2) ensures that for each transition t1 of n1 in the current match there is a transition t2 of n2 in the current match so that post1(t1)|p1 = post2(t2)|p2 . so, rulepred,t (s,t1,t2) ensures that for each place p1 of n1 in the match there is a place p2 = m(s)( p1) of n2 in the match so that pre1(t1)|p1 = pre2(t2)|p2 . • analogously, rulesucc,p and rulesucc,t examine the successors of the candidate pair. rulepred,p(s, p1, p2) ≡∀t1 ∈ m1(s)∩t1 : post1(t1)|p1 = post2(m(s)(t1))|p2 rulepred,t (s,t1,t2) ≡∀p1 ∈ m1(s)∩p1 : pre1(t1)|p1 = pre2(t2)|m(s)(p1) rulesucc,p(s, p1, p2) ≡∀t1 ∈ m1(s)∩t1 : pre1(t1)|p1 = pre2(m(s)(t1))|p2 rulesucc,t (s,t1,t2) ≡∀p1 ∈ m1(s)∩p1 : post1(t1)|p1 = post2(t2)|m(s)( p1) (3) each pair that satisfies the rules (2) and (3) leads to a correct partial match if added to the current state. however, the pursuit of all following states does not necessarily pay off. the following rules check the possibility of mapping the neighborhood of the candidates and hence prune the search space. • the rules rulein,t |p and ruleout,t |p perform a lookahead of size one for places and for transitions in the searching process by checking that there are at least as many adjacent nodes in the corresponding terminal sets of net n2 as there are in the sets of net n1. since net morphisms preserve the preand post domain of the transitions the number of adjacent places must match. • the rules rulenew,t |p perform a lookahead of size two as it checks the amount of adjacent nodes in the residual node sets. rulein|out,p(sn, p1, p2) ≡ |{t1 | t1 ∈ t in|out t1 ∧ post1(t1)|p1 > 0}|≤ |{t2 | t2 ∈ t in|out t2 ∧ post2(t2)|p2 > 0}| ∧|{t1 | t1 ∈ t in|out t1 ∧ pre1(t1)|p1 > 0}|≤ |{t2 | t2 ∈ t in|out t2 ∧ pre2(t2)|p2 > 0}| rulein|out,t (sn,t1,t2) ≡ |{p1 | p1 ∈ t in|out p1 ∧ pre1(t1)|p1 > 0}| = |{p2 | p2 ∈ t in|out p2 ∧ pre1(t2)|p2 > 0}| ∧|{p1 | p1 ∈ t in|out p1 ∧ post1(t1)|p1 > 0}| = |{p2 | p2 ∈ t in|out p2 ∧ post2(t2)|p2 > 0}| rulenew,p(sn, p1, p2) ≡ |{t1 | t1 ∈ t̃1 ∧ post1(t1)|p1 > 0}|≤ |{t2 | t2 ∈ t̃2 ∧ post2(t2)|p2 > 0}| ∧|{t1 | t1 ∈ t̃1 ∧ pre1(t1)|p1 > 0}|≤ |{t2 | t2 ∈ t̃2 ∧ pre2(t2)|p2 > 0}| rulenew,t (sn,t1,t2) ≡ |{p1 | p1 ∈ p̃1 ∧ pre1(t1)|p1 > 0}| = |{p2 | p2 ∈ p̃2 ∧ pre1(t2)|p2 > 0}| ∧|{p1 | p1 ∈ p̃1 ∧ post1(t1)|p1 > 0}| = |{p2 | p2 ∈ p̃2 ∧ post2(t2)|p2 > 0}| (4) accordingly, feasibility of pairs of places is given by f easiblep ≡ rulesem,p ∧rulepred,p ∧rulesucc,p ∧rulein,p ∧ruleout,p ∧rulenew,p (5) 7 / 14 volume 68 (2014) non-deterministic matching algorithm for net transformations and feasibility of pairs of transitions is given by f easiblet ≡ rulesem,t ∧rulepred,t ∧rulesucc,t ∧rulein,t ∧ruleout,t ∧rulenew,t (6) looking at the example (in subsect. 4) the pair (t1,tb) cannot be considered for the match since f easiblet (s1,t1,tb) ≡ f alse. this results from rulesem,t because t1 has less incoming and outgoings arcs than tb. the representation of the state uses six integer arrays for each net n j, namely core j,x,in j,x,out j,x for j ∈ {1,2} and x ∈ {p,t}. these arrays are shared among all states, so if the algorithm backtracks, it restores the previous value for these arrays. the elements of these arrays are ordered according to the (arbitrary, but fixed during initialization) order of the nodes, i.e., the second element of core1,p refers to the second place of net n1 and the third element of in2,t refers to the third transition in net n2. in subsect. 4 the six core array are presented by tables for different states in fig. 4. in state s1 the array core1 and the array core2 are presented in the second row. the order of the nodes in both nets is given by the implicit order of their indices. so, p2 of net n1 is represented in the third column, and td of net n2 in the last column. the core arrays are used for the mappings from the perspective of each net. the elements position in the core array refers to the position of the node in the corresponding net, whereas the value refers to the mapped node in the other net. the elements of core1 and core2 point mutually to each other. the in and out arrays manage the terminal and residual node sets. adding a pair of nodes to the current state changes the values of in and out for the neighboring nodes. the value coincides with the recursion depth, in which a node enters the terminal node set. if a pair of nodes is added to the state only those fields are set to the current depth that do not have a value. the combination of core, in and out arrays, the terminal and residual node sets can be computed. in state s2 (see subsect. 3.2) the mapping of p1 in net n1 to the place pc in net n2 leads to core1,p[1] = 3 and core2,p[3] = 1 and the mapping of t1 to tc leads to core1,t [1] = 3 and core2,t [3] = 1. 3.2 example for the nets given in fig. 4, the empty match of the first state s0 is given by m(s0) = ∅ and p(s0) = pp̃(s0) = {( p1, pa),(p1, pb),(p1, pc)}. hence, the arrays are empty as well. according to the predefined order (given by the obvious order of the indices) the candidate pair ( p1, pa) is chosen. as f easiblep(s0, p1, pa) holds, m(s1) = {( p1, pa)} with the corresponding core, in and out arrays for state s1 in fig. 4. then p(s1) = pt (s1) = {(t1,tb)} is computed, but f easiblet (s1,t1,tb) ≡ f alse∧···≡ f alse. so, the algorithm backtracks and computes a new state s1 based on p(s0) = pp(s0) = {( p1, pb),( p1, pc)} leading to m(s1) = {( p1, pc)} and the arrays of state s1 in fig. 4. next we obtain p(s1) = pt (s1) = {(t1,tb),(t1,tc)} with f easiblet (s1,t1,tb) ≡ f alse and f easiblet (s1,t1,tc) ≡ true. the next recursion step yields m(s2) = {( p1, pc),(t1,tc)} and the arrays of state s2. then p(s2) = pp(s2) = {( p2, pb)} and f easiblep(s2, p2, pb) ≡ true. this leads to m(s3) = {( p1, pc),(t1,tc),(p2, pb)} and the candidate pairs p(s3) = {(t2,ta),(t2,tb),(t2,td )} and f easiblet (s3,t2,ta) holds. there is no more backtracking necessary and the last state is s5 with m(s5) = {( p1, pc),(t1,tc),(p2, pb),(t2,ta),(t3,td )} being an injective net morphism. the corresponding arrays for state s5 are given in fig. 4. proc. grabats 2014 8 / 14 eceasst s1 n1 n2 p t p t core1 1 core2 1 in1 1 1 in2 1 1 out1 1 1 out2 1 1 new s1 n1 n2 p t p t core1 3 core2 1 in1 1 1 in2 1 1 out1 1 1 out2 1 1 1 s2 n1 n2 p t p t core1 3 3 core2 1 1 in1 1 2 1 in2 1 1 2 out1 1 2 1 out2 2 1 1 1 s5 n1 n2 p t p t core1 3 2 3 1 4 core2 2 1 2 1 3 in1 1 3 2 1 5 in2 3 1 1 3 2 5 out1 1 2 1 3 3 out2 2 1 4 1 1 3 figure 4: nets n1 and n2 and some states 4 evaluation of pnvf2 4.1 correctness both the vf2 and the pnvf2 guarantee the correctness of the found matches. a match is considered to be correct if the structure of the source net and its annotations are preserved. and the match has to be an injective morphism. to satisfy these conditions, the algorithms examine the candidates before they add them to the respective part of the match. the candidate selection during the recursive descent makes sure that the mapping is injective. and the function f easible ensures structural and semantic compatibility. the correctness of pnvf2 is stated explicitly in theorem 1. for lemma 1 we need at each state the corresponding partial nets4. in these partial nets the sets of places and the sets of transitions are restricted to the matched places and transitions. given j ∈ {1,2} and 0 ≤ i ≤ |p1|+ |t1| we define q j,i with places p j ∩ m j(si) and transitions t j∩m j(si), and the preand post-domain are given by pre j|t j∩m j(si) and post j|t j∩m j(si) and the other functions accordingly. obviously, the partial nets q j,i are well-defined. then each state computed by pnvf2 leads to an injective net morphism between the corresponding partial nets. 4 note, that these nets are subgraphs but there are not necessarily net morphisms form q j,i to n j. 9 / 14 volume 68 (2014) non-deterministic matching algorithm for net transformations lemma 1 (correctness of f easible) let 1 ≤ i ≤ n = |p1|+ |t1| be given. 1. if m(si−1) : q1,i−1 → q2,i−1 is an injective net morphism and f easible(si−1,v,w) holds for (v,w) ∈ p(si−1) and m(si) = m(si−1)∪{(v,w)}, then m(si) : q1,i → q2,i is an injective net morphism as well. 2. if f easible(si,v,w) = f alse, there is no injective net morphism f : n1 → n2 with fq := f|q1,i+1 : q1,i+1 → q2,i+1, where q j,i+1 are the partial nets induced by the match m(si+1) = m(si)∪{(v,w)}. proof sketch 1. since m(si−1) : q1,i−1 → q2,i−1 is an injective net morphism, it is an injective mapping of places and an injective mapping of transitions. the addition of a pair of places (or transitions) that are not in the current sets of places (or transitions), yields again an injective mapping. for (v,w) ∈ p1×p2 f easiblep(si−1,v,w) holds (equation 5), hence the marking is preserved (rule 2). moreover, the net structure is preserved (rule 3). similarily, for (v,w) ∈ t1×t2 f easiblet (si−1,v,w) holds (equation 6), hence the number of inand outgoing arcs of both transitions are the same. moreover, the net structure is preserved (rule 3). hence, m(si) : q1,i → q2,i is an injective net morphism. 2. failure of f easible(si,v,w) (equation 5) implies that there is no injective morphisms with fq : q1,i+1 → q2,i+1, and hence no f : n1 → n2 with f|q1,i+1 = fq. this lemma allows us to deduce that the result of pnvf2 is an injective net morphism. theorem 1 (pnvf2 is correct and complete.) let be given two place/transition nets n j with j ∈ {1,2} and n = |p1|+ |t1|. pnvf2 yields m(sn) if and only if there exists an injective net morphism from f : n1 → n2. proof sketch if: if the algorithm yields m(sn) then f = m(sn) : n1 → n2 is an injective net morphism is shown by induction over n = |p1|+ |t1| the size of n1. base m(s0) = ∅ is an injective net morphism for n1 being the empty net. hyp. if pnvf2 yields m(sn−1) for a net n1 of size n−1 = |p1|+ |t1|, then each m(si) : q1,i → q2,i is an injective net morphism for i ≤ n−1 . step for for a net n1 of size n = |p′1|+ |t ′ 1| we have two cases |p′1| = |p1|+ 1 and |t ′ 1| = |t1|. since pnvf2 yields m(sn) and by induction hypothesis there is m(sn−1) : q1,n−1 → q2,n−1 an injective net morphism. since pnvf2 yields m(sn), there is some p′1, p ′ 2 ∈ p(sn−1) so that f easiblep(sn−1, p ′ 1, p ′ 2) holds. we have then m(sn) : q1,n → q2,n = m(sn) : n1 → n2 and due to lemma 1 this is an injective net morphism. |t′1| = |t1|+ 1 and |p ′ 1| = |p1| analogously. only if: if pnvf2 does not yield m(sn), then there is a step in each recursion path, where f easible(si,v,w) fails and due to lemma 1 there is no injective net morphism f : n1 → n2. proc. grabats 2014 10 / 14 eceasst 4.2 non-determinism the non-determinism of the matches is paramount for the simulation of reconfigurable nets, since the full potential behavior should be captured. in a situation where several different matches are possible, the algorithm has to deliver different matches for different runs. after sufficiently many runs the algorithm must have delivered each of the possible matches. a very inefficient strategy would be to compute first all possible mappings and to choose then one non-deterministically. instead we have realized non-deterministic choice at each possible step of the algorithm. implementing non-determinism at every level results in mapping source nodes randomly to target nodes. however, this strategy has also the disadvantage that it is very inefficient, as choosing random pairs the algorithm ignores the structure of the net to a large extent. this causes the matching to fail more often in larger depths of the recursion. the vf2 follows the strategy to map adjacent components to the destination net. for this purpose nodes of the terminal sets are preferred. for the sake of reasonable runtime of the pnvf2, this strategy is maintained. the vf2 algorithm requires a fixed order on the the source nodes and an order on the target nodes. this order determines the sequence in which nodes of the corresponding sets are processed and it ensures that the algorithm does not generate the same states via different execution paths. any possible order of the nodes is sufficient, as long as it remains stable during the run. we use this fact as the main realization of non-determinism by permuting all places and transitions of both nets at each start of the algorithm. another, but less influential, implementation of nondeterminism is the random choice of the node type (i.e., choosing places or transitions) at each level of the recursion. in order to prove that the algorithm is non-deterministic, i.e., it can compute any injective net morphism between two given nets, we need to state an order of the places and transitions that leads to a given injective net morphism. then this order is compatible with the given morphism. lemma 2 (compatible order) let an injective net morphism f : n1 → n2 be given. for orders ρ = (ρx j ) : x j →{1,..., |x j|} with x ∈ {p,t} and j ∈ {1,2} with ρp1 ( p) = ρp2 ( fp(p)) and ρt1 (t) = ρt2 ( ft (t)) we have for all 0 ≤ i ≤ n = |p1|+ |t1| and all (v,w) ∈ m(si): there exists a match m(si), so that we have ρx1 (v) = ρx2 (w) if we need not to differentiate between places and transitions we use ρi instead of ρxi . proof sketch induction over i for 0 ≤ i ≤ n = |p1|+ |t1|: base at state s0 we have m(s0) = ∅. step by induction hypothesis we have m(si) and ρ1(v) = ρ2(w) for all (v,w) ∈ m(si). then there is minimal ρ1(x) with ρ1(x) = min x1 and x1 ∈ {t in|out p1|t1 ,t̃1, p̃1}. since f (x) = ρ−12 (ρ1(x)) and since the terminal and residual nodes sets are constructed similarly, we have that x ∈ x1 implies ρ−12 (ρ1(x)) ∈ x2 for x j ∈ {t in|out p j|t j ,t̃ j, p̃ j | j ∈ {1,2}}. so, there is one candidate pair (x,ρ−12 (ρ1(x)) ∈ p(si). as f is an injective net morphism, the rules rulesem, rulepred and rulesucc hold (see rules 2 and 3). rulein, ruleout and rulenew (see rule 4) hold, because the neighboring nodes can be mapped, as f is an injective net morphism. hence ( f easible(si, x,ρ−12 (ρ1(x))) holds. 11 / 14 volume 68 (2014) non-deterministic matching algorithm for net transformations last, let m(si+1) = m(si)∪(x,ρ−12 (ρ1(x)). theorem 2 (pnvf2 is non-deterministic.) given f : n1 → n2 an injective net morphism, then pnvf2 can yield m(sn) : n1 → n2, so that m(sn) = f . from lemma 2 we directly obtain a match m(sn) = f . 4.3 complexity one of the most important properties of an algorithm is its complexity. in [cfsv04b] the space and time complexity of vf2 has been given for graph isomorphisms by θ(n) and θ(n2) for the best case and by θ(n) and θ(n! n) for the worst case on the number of nodes n. in principle we have the same complexity measures. nevertheless, for a more precise investigation of the complexity differences of both algorithms the complexity measures have been computed explicitly for the subgraph isomorphisms in [blu13]. in the following we assume that the execution of an elementary operation, as the reading and setting of the arrays, is done in θ(1). time complexity of the vf2 is based on the number of nodes of the source graph n and of the target graph m, and time complexity of the pnvf2 is based on the number of places p1 and transitions t1 of the source net and of the target net p2 and t2. for the pnvf2 the best case occurs if two equally sized nets without any arcs are considered. due to the lack of arcs any mapping of places (resp. transitions) is a valid match. the worst case occurs if there are two almost complete nets whose search area needs to be investigated completely. in contrast to the best case, the amount of nodes in the target can be significantly higher than in the source. the analysis of the space complexity refers only to the data structures of the algorithms. as a representation of the current matching state, both algorithms use the same instance at each recursion level, namely the arrays core, in and out. therefore the memory is allocated only once. for each graphs three arrays of length n and m are managed. and the three arrays for each of the nets have the length p1 + t1 and p2 + t2. due to the reduced search space, as nets are bipartite graphs, we can expect the complexity results to be slightly better. comparing the complexity measures, we consider a net as a graph, and hence have n = p1 + t1 and m = p2 + t2. then we can rate p2t2 · ( p2 p1 ) · p1! · ( t2 t1 ) ·t1! ≤ (p2 + t2)2 · p1! ·t1! · ( p2 p1 ) · ( t2 t1 ) ≤ ( p2 + t2)2 · ( p2 p1 ) · ( t2 t1 ) ·( p1 + t1)! ≤ m2 · ( m n ) n! so, we obtain tpnv f2( p1 + t1, p2 + t2)∈o(n!·n), since we have by induction nm 2 · ( m n ) n!≤ n n!, and hence p2t2 · ( p2 p1 ) · p1! · ( t2 t1 ) · t1! ≤ m 2 · ( m n ) ·n! ≤ n · n! for n = p1 + t1, m = p2 + t2 and for n = n + m. 5 related work and conclusion obviously, reconfigurable petri nets are closely related to graph transformations (see [mee10]). agg [agg13] and its derivations as the ron-editor [bems08] and cpeditor [mod12], translate petri nets into attributed graphs and net rules to attributed graph rules. but they do not consider directly petri nets, and hence do not support the separation of dynamics. an extensive proc. grabats 2014 12 / 14 eceasst discussion of various matching algorithms has been presented in [cfsv04a] comprising exact as well as inexact algorithms. due to the nature of the requirements we have investigated merely exact algorithms [mb00, ull76, dz09]. for more details see [blu13]. the extension the vf2 algorithm by domain-specific information has been in order to speed up the pattern matching process. these search plan driven graph pattern matching techniques have been investigated in [ghs09, gbg+06, gsr05]. the ullmann algorithm has been the basis of the reconnet’s previous implementation, that was faulty with respect to the non-determinism and moreover did not provide means for the realization of negative application conditions, whereas, the pnvf2 has been adapted accordingly. ongoing work concerns model checking by translating nets and rules into rewrite logic maude and an explicit representation of an abstract reachability graph based on [pad12]. future work includes the investigation of the runtime behavior and memory consumption of the implemented algorithm and an experimental comparison with the vf2 algorithm to evaluate the implementation. another fruitful extension of reconnet are control structures, as the extension of rules with negative application conditions or the introduction of transformation units. acknowledgements: we are grateful to the referees for their valuable remarks. references [agg13] agg. the attributed graph grammar system. 2013. revision: 02/10/2013 15:25:28. http://user.cs.tu-berlin.de/~gragra/agg/ [bems08] e. biermann, c. ermel, t. modica, p. sylopp. implementing petri net transformations using graph transformation tools. eceasst 14, 2008. [blu13] m. blumreiter. algorithmus zum nichtdeterministischen matching in rekonfigurierbaren petrinetzen. bachelor’s thesis, hamburg university of applied sciences, germany, 2013. [cfsv04a] d. conte, p. foggia, c. sansone, m. vento. thirty years of graph matching in pattern recognition. international journal of pattern recognition and artificial intelligence 18(3):265–298, 2004. [cfsv04b] l. p. cordella, p. foggia, c. sansone, m. vento. a (sub)graph isomorphism algorithm for matching large graphs. pattern analysis and machine intelligence, ieee transactions on 26(10):1367 – 1372, oct. 2004. [dz09] y.-t. dai, s.-y. zhang. a fast labeled graph matching algorithm based on edge matching and guided by search route. in international conference on wavelet analysis and pattern recognition. pp. 1–7. 2009. [eept06] h. ehrig, k. ehrig, u. prange, g. taentzer. fundamentals of algebraic graph transformation. eatcs monographs in tcs. springer, 2006. [ehop12] m. ede, k. hoffmann, g. oelker, j. padberg. reconnet: a tool for modeling and simulating with reconfigurable place/transition nets. in krause and westfechtel (eds.), proc. of the seventh international workshop on graph-based tools. volume 54. electronic communications of the easst, 2012. 13 / 14 volume 68 (2014) http://user.cs.tu-berlin.de/~gragra/agg/ non-deterministic matching algorithm for net transformations [ep03] h. ehrig, j. padberg. graph grammars and petri net transformations. in desel et al. (eds.), lectures on concurrency and petri nets. lecture notes in computer science 3098, pp. 496– 536. springer, 2003. [gab14] k. gabriel. interaction on human-centric communication platforms: modelling and analysis using algebraic high-level nets and processes. phd thesis, technische universität berlin, 2014. [gbg+06] r. geiß, g. v. batz, d. grund, s. hack, a. szalkowski. grgen: a fast spo-based graph rewriting tool. in corradini et al. (eds.), third international conference on graph transformations. lecture notes in computer science 4178, pp. 383–397. springer, 2006. [ghs09] h. giese, s. hildebrandt, a. seibel. improved flexibility and scalability by interpreting story diagrams. eceasst 18, 2009. [gsr05] l. geiger, c. schneider, c. reckord. templateand model-based code generation for mdatools. in giese and zündorf (eds.), proceedings of the 3rd international fujaba days, pp. 57–62. 2005. [kcd10] l. kahloul, a. chaoui, k. djouani. modeling and analysis of reconfigurable systems using flexible petri nets. in 4th ieee international symposium on theoretical aspects of software engineering. pp. 107–116. 2010. [lo04] m. llorens, j. oliver. structural and dynamic changes in concurrent systems: reconfigurable petri nets. ieee trans. computers 53(9):1147–1158, 2004. [mb00] b. t. messmer, h. bunke. efficient subgraph isomorphism detection: a decomposition approach. knowledge and data engineering, ieee transactions on 12(2):307–323, 2000. [mee10] m. maximova, h. ehrig, c. ermel. formal relationship between petri net and graph transformation systems based on functors between m-adhesive categories. eceasst 40, 2010. [mod12] t. modica. formal modeling, simulation, and validation of communication platforms. phd thesis, technical university of berlin, 2012. [pad12] j. padberg. abstract interleaving semantics for reconfigurable petri nets. eceasst 51, 2012. [rei12] f. reiter. modellierung und analyse von szenarien des living place mit rekonfigurierbaren petrinetzen. bachelor thesis, hochschule für angewandte wissenschaften hamburg, 2012. [ull76] j. r. ullmann. an algorithm for subgraph isomorphism. j. acm 23(1):31–42, jan. 1976. proc. grabats 2014 14 / 14 introduction reconfigurable petri nets matching algorithm pnvf2 outline of the algorithm example evaluation of pnvf2 correctness non-determinism complexity related work and conclusion distributed port automata electronic communications of the easst volume 41 (2011) proceedings of the tenth international workshop on graph transformation and visual modeling techniques (gtvmt 2011) distributed port automata christian krause 14 pages guest editors: fabio gadducci, leonardo mariani managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst distributed port automata christian krause∗ christian.krause@hpi.uni-potsdam.de hasso plattner institute (hpi), university of potsdam, germany abstract: dynamic reconfigurations are a powerful approach for the adaption of component-based or service-oriented software systems at runtime. important issues in this area are the problems of state transfer and state consistency, i.e., to determine the system state after a reconfiguration and to ensure that it is valid. to deal with these problems, we introduce distributed port automata in this paper. distributed port automata combine structural and behavioral system properties and therefore allow to reason about dynamic reconfigurations. in our approach, we use an automatabased model for describing the behavior of the primitive building blocks in a system, and a graph-based model for describing its structure in terms of a network. we demonstrate how to derive the system semantics of a distributed port automaton and show that it is compositional. we consider an encoding of the coordination language reo and show a new result on compositionality of flattening for distributed graphs. keywords: dynamic reconfiguration, distributed graph transformation, reo 1 introduction a common approach in component-based and service-oriented software is to divide the system model into two orthogonal aspects: (i) the computation performed by a set of (black-boxed) components or services, and (ii) their coordination using some kind of ‘glue code’. the specification of the components or services is usually based on a behavioral, e.g. an automata-based, model. however, the composition and coordination of these functional building blocks is often done using graphical models, e.g. petri nets or reo connectors [arb04]. dynamic reconfigurations of such systems involve structural changes to these models at runtime. however, it is non-trivial to verify the impact of these structural modifications on the execution of the system. specifically, when performing dynamic reconfigurations, two issues have to be dealt with: (i) the structural and logical integrity of the system has to be maintained, and (ii) it must be ensured that the system is in a consistent state after the reconfiguration (state transfer and consistency). for instance, it should be guaranteed that the reconfiguration is not performed within a critical section (e.g. a transaction), and that the system is not brought into a deadlock state. in this paper, we introduce distributed port automata – an integrated structural and behavioral model for service and component coordination. we specify primitives using so-called port automata and combine them in a structural model based on distributed graphs. specifically, we use the framework of distributed graph transformation [tae99, eop06], which enables us to model reconfigurations using algebraic graph transformation based on the double pushout approach [cmr+97]. we then derive a semantics functor and show that it is compositional. for ∗ supported by the research school in ‘service-oriented systems engineering’ at the hasso plattner institute (hpi). 1 / 14 volume 41 (2011) mailto:christian.krause@hpi.uni-potsdam.de distributed port automata this purpose, we show that the flattening functor for distributed graphs is cocontinuous, i.e., it preserves colimits, which are the basis for gluing operations of (distributed) graphs. as applications, we consider a distributed port automata encoding of reo and discuss a number of problems in the area of dynamic reconfigurations. the work in this paper is a generalization of the approach in [kra09]. specifically, we replace the ad hoc connector model in [kra09] by distributed graphs. organization: the rest of this paper is organized as follows. section 2 recalls the basics of distributed graph transformation and includes a new result regarding flattening. section 3 contains a brief introduction to reo and the semantical model of port automata. section 4 introduces distributed port automata and includes a discussion on composition and dynamic reconfiguration. finally, section 6 and 7 contain related work and conclusions. acknowledgements: the author of this paper is very grateful to erik de vink and ulrike golas for their proofreading. 2 distributed graph transformation we use the framework of distributed graph transformation, as introduced by taentzer [tae99], and later generalized to a notion of transformation of distributed objects by ehrig et al. [eop06]. in this section, we recall the basic notions of this framework and present a new result on compositionality of the flattening functor for distributed graph transformation. distribution of graphs can be described by adding a second layer of abstraction, namely by modeling the topology of a system using a so-called network graph. the nodes in a network graph consist of local graphs and the edges are morphisms of local graphs. the idea is that a node models a physical or logical location of a local graph, whereas an edge indicates an occurrence of the source graph in the target graph. in particular, multiple outgoing edges from one local graph model the fact that the source graph is shared among the target graphs. we consider directed graphs g = (v, e, s,t) with s,t : e →v source and target functions, and componentwise morphisms. then, a distributed graph is defined as follows. definition 1 (distributed graph) a distributed graph (n, d) consists of a graph n, called the network graph, and a commutative functor d : n → graph, where n is interpreted as a category. the network graph n describes the topology of the system. the functor or diagram d associates to every node n in n a local graph d(n) and to every edge n e−→ n′ in n a graph morphism d(e) : d(n) → d(n′). following [eop06], this functor is required to be commutative, i.e., for any two paths p1, p2 : n ∗−→ n′ in n, it must hold that d(p1) = d(p2). this arises from the assumption that the morphisms associated with edges represent the sharing of the local graphs. we now recall the definition of morphisms for distributed graphs. definition 2 (distributed graph morphism) for two distributed graphs (n1, d1) and (n2, d2), a morphism f = ( fn , fd) : (n1, d1) → (n2, d2) consists of a graph morphism fn : n1 → n2 and a natural transformation fd : d1 → d2 ◦ fn . proc. gtvmt 2011 2 / 14 eceasst for brevity, we will just write f for the network morphism fn . by definition, the natural transformation fd assigns to every node n of the network graph n1 a graph morphism fn : d1(n) → d2( f (n)) which is called the local graph morphism of n. furthermore, for every edge n e−→ n′ in n1 the following diagram commutes. d1(n) d1(e) // fn �� d1(n′) fn′ �� d2( f (n)) d2( f (e)) // d2( f (n′)) (1) distributed graphs and their morphisms form the category dis(graph). due to the categorical definition, the concept of distribution can be generalized to other structures by considering functors d : n →c into a category c, giving rise to a category dis(c) of distributed objects [eop06]. flattening of distributed graphs the flattening operation for distributed graphs glues together all local graphs along their shared subgraphs. it is a well-known fact that the flattening of a distributed graph or object (n, d) can be achieved by considering the colimit of d [tae99] and that this extends to a functor f : dis(c) → c, assuming c is cocomplete [lt05]. this definition is rather elegant since it defines flattening in terms of a universal property, and not by an algorithm or referring to an operational semantics. considering flattening of distributed graphs or objects is in particular interesting when distribution is used for representing a logical partitioning of an otherwise flat system. the distributed model can be interpreted as a more high-level view on a flat structure. in this perspective it is crucial to know whether flattening interacts well with composition. composing two distributed objects in dis(c) and flattening the result should yield the same outcome as first flattening both distributed objects and then composing them in c. formally, we need to show that the flattening functor f preserves pushouts, or more generally, colimits. theorem 1 (flattening preserves colimits) let c be a cocomplete category. the flattening functor f : dis(c) → c has a right adjoint and is therefore cocontinuous. proof. a detailed proof is given in the appendix. distributed graphs or, more generally, distributed objects can be used to describe a logical partitioning of an otherwise flat structure. due to theorem 1, composition and transformation of distributed objects can be transparently implemented on the underlying flat structure. this result will also be crucial for the compositional semantics of distributed port automata in section 4. 3 channel-based coordination with reo reo [arb04] is a channel-based coordination language, with applications in component-based and service-oriented software systems. channels in reo are entities that have exactly two ends, which can be either source or sink ends. source ends accept data into, and sink ends dispense data out of their channel. channels may impose constraints on the data flow at their ends. for instance, the communication through channels can be (a)synchronous and (un)buffered. for the scope of this paper, we consider only a small set of primitives, summarized in table 1. the sync channel consumes data items at its source end and dispenses them at its sink end. the i/o operations are performed synchronously and without any buffering. thus, the channel 3 / 14 volume 41 (2011) distributed port automata sync fifo1 merger replicator graphical notation a b a b a b c a b c port automaton /0 {a, b} {a} {b} /0 /0 {a,c} {b,c} /0 {a, b,c} /0 table 1: graphical notation and port automata for some basic reo primitives blocks if the party at the sink end is not ready to receive data. the fifo1 channel is a directed, asynchronous channel with a buffer of size one. it reads a data item from its source ends, buffers it, and releases it again at its sink end. channels in reo can be joined together using nodes, which read data items from sink ends and write data items to source ends of channels that coincide in it. nodes behave as non-deterministic mergers on the sink ends and as (synchronous) replicators on the source ends. this means that a node non-deterministically reads a data item from one of the incoming sink ends and replicates it to all outgoing source ends without buffering it. 3.1 building connectors in reo, channels and nodes are joined together to build so-called connectors which act as glue code between components or services and essentially enforce a communication protocol among them. this coordination of components and services is performed from outside and without their knowledge, which is, therefore, referred to as exogenous coordination. an important aspect of reo is that nodes do not buffer data items and, thus, allow synchrony to propagate through the connector. for instance, a sequence of n sync channels joined together using nodes has the same qualitative behavior as a single sync. note also that reo allows an arbitrary mixing of synchrony and asynchrony, which is also indicated by our first example. example 1 we consider a simple instant messenger application, shown in figure 1. two client components exchange messages via a connector. messages are sent into fifo1 channels and are thus buffered. when they leave the buffer, they are synchronously replicated by the node behind the fifo1 and sent to both clients. this can succeed only when both clients are ready to accept figure 1: instant messenger application modeled in reo proc. gtvmt 2011 4 / 14 eceasst data. in a nutshell, this connector ensures that clients get –as an acknowledgment– a copy of their own message when the other client has successfully received it. in figure 1, a message, depicted as a green token, is already buffered in the upper fifo1 and is about to be sent to both clients. this synchronous dataflow is indicated by the blue highlighted parts of the connector. note that the nodes x and y are replicators, whereas b and c act as mergers. 3.2 port automata semantics port automata [kc09] are the most basic semantical model for reo. although they cannot model data constraints, port automata already capture some of the key concepts required for defining channels and other primitives, i.e., synchrony, mutual exclusion and state. port automata come equipped with a join-operator for composition, which allows to compute the semantics of a connector given the semantics of the primitives it is comprised of. port automata have been introduced in [kc09] as an abstraction of constraint automata [bsar06] and offer, because of their conciseness, the possibility of better comparison with other semantical models, such as reo automata [bcs09]. in the following we define port automata formally. definition 3 (port automaton) a port automaton pa = (q, n, t, q0) consists of a set of states q, a set of port names n, a transition relation t ⊆ q×2n ×q, and an initial state q0 ∈ q. we usually write transitions as p s−→ q with p, q ∈ q source and target states, s ⊆ n the set of synchronously firing ports. the port automata for the primitives are given in the lower part of table 1. we see immediately that the sync channel as well as nodes (modeled using merger and replicator primitives) are stateless, i.e., they have only one state. note that replicators basically synchronize all ends, whereas mergers essentially implement mutual exclusion of the incoming ends. note that the port automata for the primitives include explicit τ -transitions via the empty set of port names. 4 the category of port automata to establish a categorical framework suitable for applying graph transformation methods, we introduce a notion of simulations for port automata in the following. a port automata simulation essentially consists of a mapping of states and transitions, and an inverse mapping of port names. we ensure consistency of firing events using a condition on the transitions of the port automata. definition 4 (port automata simulation) let pa1 = (q1, n1, t1, q10) and pa2 = (q2, n2, t2, q 2 0) be two port automata. a simulation f = ( fq, fn , ft ) consists of functions fq : q1 → q2, fn : n2 → n1 and ft : t1 → t2, such that: • fq(q10) = q 2 0 • ft ( q1 s1−→p1 ) = ( q2 s2−→p2 ) implies q2 = fq(q1), p2 = fq(p1) and s2 = f −1 n (s1) note that port names are mapped in the opposite direction and that the condition s2 = f −1 n (s1) ensures consistency of firing events on all shared port names. we now consider an example. 5 / 14 volume 41 (2011) distributed port automata example 2 an example of a port automata simulation is depicted in figure 2. states q0, q2 are both mapped to p0, and q1 is mapped to p1. the port name function is the inclusion map in the opposite direction. the transition via {b,c} in the source is mapped to the transition via {b}. the transition via {c} corresponds to the τ -step in the target automaton. q0 q1 {a} q2 {b,c}{c} p0 p1 {a} {b} /0 figure 2: a port automata simulation note that mapping a normal, i.e., non-empty transition to a τ -step essentially allows us to model interleaved semantics. intuitively, the source automaton performs an (observable) step, whereas the target automaton takes a (silent) τ -transition. we define composition and identity of port automata simulations componentwise. the following lemma states that port automata and simulations form a category. lemma 1 (category of port automata) port automata and port automata simulations give rise to a category, denoted by pa. proof. we verify the consistency condition of firing events for the identity: s = id−1n (s). similarly, for the composition of f : pa1 → pa2 and g : pa2 → pa3 it holds that: (g◦ f )−1n (s1) = g −1 n ( f−1n (s1) ) = g−1n (s2) = s3 the port automaton with one state, an empty port name set and a τ -transition is the final object in pa, denoted by 1. if there is a morphism between two port automata pa1 and pa2, we may also write pa1 � pa2 for short. similarly, if there exists a (categorical) isomorphism, we denote this by pa1 ∼= pa2. note that this notion of behavioral equivalence is stronger than standard equivalences based on, e.g., bisimulation [mil89]. we define the composition of port automata now using pullbacks in pa. note that since we model τ -steps explicitly, the composition is based on mere synchronization only. interleavings of actions are modeled by synchronizations of an action and a τ -transition in the other automaton. theorem 2 (pullbacks of port automata) pa has pullbacks which can be constructed componentwise. for a cospan pa1 → pa0 ← pa2 the pullback object is pa3 = (q3, n3, t3, q30) with: • q3 = q1 ×q0 q2 (pullback in set) • n3 = n1 +n0 n2 (pushout in set) • q30 = 〈q 1 0, q 2 0〉, and • t3 defined by the following rule: pa0 pa1 f1oo pa2 f2 oo pa3 g1 oo g2oo x h1 ]] h2 dd h aa f1,t ( q1 s1−→p1 ) = f2,t ( q2 s2−→p2 ) s0 = f −1 1,n (s1) = f −1 2,n (s2) s3 = s1 +s0 s2 〈q1, q2〉 s3−→3〈p1, p2〉 (2) proc. gtvmt 2011 6 / 14 eceasst proof. due to the componentwise construction in set, we only need to show that g1, g2 and h are valid pa-morphisms, i.e., we need to check the consistency condition for the firing ports. for g1 we have by construction: g −1 1,n (s3) = g −1 1,n (s1 +s0 s2) = s1, and analogously for g2. for h, assume there is a transition via s in x that is, w.l.o.g., mapped to a transition via si in pai with i = 1, 2. we need to show that there is a corresponding transition via s3 in pa3. since the hi are by assumption valid pa-morphisms, we have: h−1i,n (s) = si. moreover, f1◦h1 = f2◦h2 and thus: f−11,n (s1) = f −1 2,n (s2). therefore, the premise of rule (2) is fulfilled and the transition exists. since hi = gi ◦h we also know that h−1n (s) = s3. thus, the consistency condition holds also for h. note that f1,t (q1 s1−→ p1) = f2,t (q2 s2−→ p2) implies f1,q(q1) = f2,q(q2) and f1,q(p1) = f2,q(p2). port automata pullbacks generalize the join operator for constraint automata of [bsar06], since they allow to join two automata not just over a set of shared port names, but over a whole automaton, which can be seen as a shared context. the semantics of the original join operator is a special case where pa0 is stateless, i.e., it has only one state. note also that the new composition operator is derived from our notion of simulation and phrased in terms of a universal property. example 3 an example of a port automata pullback is depicted in figure 3(b). the state maps are indicated by state names. note that the resulting automaton in the bottom right actually includes more states which are suppressed here since they are unreachable. the automata in this pullback can be modeled using fifo1 channels. in fact, the automata correspond to reo connectors and the whole pullback corresponds to a structural gluing of these connectors, as shown in the pushout of reo graphs in figure 3(a). (a) connector graph pushout q1 p1 q2 p2 {a} {b,c} {b} {b} {c} {c}pq {a} {a,c} {b} {b,c} {c}{c} q1 q2 p1 p2 {c} {a} {b} {a,c} {c} {a} q11 p21 q22 {c} {a} {b} (b) port automata pullback figure 3: categorical composition of connectors and port automata we use the default notation for pullbacks of port automata, i.e., pa3 = pa1 ×pa0 pa2. note that we have indirectly shown that pa has general limits, since it has pullbacks and a final object. the categorical construction using pullbacks furthermore includes the morphisms into the original port automata and thereby relates them with the result using simulations, which will be helpful in the context of dynamic reconfigurations. 7 / 14 volume 41 (2011) distributed port automata 5 the category of distributed port automata example 3 in the previous section already indicated a connection between the graph-based model of reo connectors and the semantical counterpart in the category of port automata. we now provide a categorical model which integrates the structural aspects, i.e., the topology of a connector or network, and the semantics of the primitives it is comprised of. we use the theory of distributed graph transformation as in section 2. specifically, we consider the following category. definition 5 (category of distributed port automata) the category of distributed port automata is defined as dis(paop). note that we consider dis(paop) and not dis(pa) since the pa-semantics is contravariant to the graph structure of networks, as indicated also in example 3 where a pushout of reo connectors is mapped to a pullback of the corresponding port automata. however, before investigating the properties of dis(paop), we first show how to encode reo into this model. 5.1 reo connectors as distributed port automata to encode reo in dis(paop) we map every primitive in a connector to its corresponding port automaton (cf. table 1), and every node x to a stateless port automaton with one transition via x and one via the empty port name set. note again that mergers have to be modeled explicitly. the port automata for primitives and nodes are now considered as vertices in a network graph n. for every pair of a node and a connected primitive we create an edge between the corresponding vertices in the network graph. the edge points towards the port automaton of the primitive. however, it corresponds to the pa-simulation in the opposite direction which maps all transitions of the primitive that involve the connected node x to the self loop transition that includes x , and all other transitions to /0. the reason for inverting the edges is, formally, the fact that we consider the category dis(paop). informally, it can be motivated by arguing that the edges in the network graph represent primarily structural mappings of the node names, which are contravariant for port automata simulations. example 4 figure 4 depicts the distributed port automaton for the instant messenger in example 1. for simplicity, we have modeled the replicator nodes x and y using a single port and omitted the port automata for the nodes b and c, and all τ -transitions. note also that the edges in the distributed port automaton correspond to inverse simulations. this is due to the fact that the edges model, primarily, structural mappings of ports. 5.2 composing distributed port automata our goal is to use double pushout graph transformation [cmr+97] for realizing reconfigurations of connectors modeled using distributed port automata. in essence, we are aiming at applying the theory of distributed graph transformation to our automata-based framework for component connectors. to enable composition and reconfiguration in our setting, we need to ensure that the category of distributed port automata, as defined above, has pushouts. we do this in the following lemma. proc. gtvmt 2011 8 / 14 eceasst {a} {x} {a} {b1} {b2} {b1, b} {b2, b} {x , b1} {y, b2} {x} {y} {x ,c1} {y,c2} {d} {y} {c1} {c2} {d} {c1,c} {c2,c} figure 4: instant messenger modeled as distributed port automaton lemma 2 the category dis(paop) is cocomplete. proof. pa is complete since it has pullbacks and a final object. hence, paop is cocomplete. if c is (co)complete, then so is dis(c) [eop06]. thus, dis(paop) is cocomplete. in figure 3(a) we have shown how pushouts can be used to glue reo networks along a common subconnector. note that this gluing is of a pure structural nature. in section 5.1 and in particular in figure 4 we have seen how reo connectors can be encoded as distributed port automata. an important aspect of this encoding was that the topology of the network is modeled by the network graph of the distributed port automaton. moreover, the local port automata model each primitive in the network. since dis(paop) is cocomplete, we can compose distributed port automata using pushouts. usually, the semantics of primitives is fixed. therefore, the local morphisms (port automata simulations) are isomorphisms. this is, for instance, the case for reo networks, but also for petri nets. in this situation, the primitive port automata in the network nodes are not changed when composing two distributed port automata using pushouts. thus, the composition is performed only on the network level and is of purely structural nature. the case where a local port automata morphism is not an isomorphism has applications as well. essentially, it allows to model a refinement of primitives, e.g. refining a buffer with bag semantics to one with fifo semantics. 5.3 semantics of distributed port automata distributed port automata capture the semantics of each primitive and the topology of the connector. the semantics of a connector modeled as a distributed port automaton (n, d)∈ dis(paop) is given by the port automaton that corresponds to the colimit of the diagram d. this colimit glues together all node names and, since we have reversed the arrows, corresponds to a limit in pa. as discussed in section 2, the colimit over a distributed graph or object can be interpreted as a flattening operation, which, moreover, extends to a flattening functor f : dis(c) → c. in the case of distributed port automata, i.e., in the category dis(paop), the flattening using colimits can, thus, be used to define the composite behavior of connectors in terms of a semantics functor. 9 / 14 volume 41 (2011) distributed port automata definition 6 (semantics functor) let f : dis(paop) → paop the flattening functor for distributed port automata. by reverting the arrows, this induces the following contravariant functor: sem : dis(paop) → pa which is called the semantics functor for distributed port automata. the following lemma states that the semantics of distributed port automata is compositional, i.e., it is compatible with composition of distributed port automata using pushouts, or more generally, with colimits. lemma 3 (compositional semantics) the semantics functor sem : dis(paop) → pa is compositional, i.e., it maps colimits of distributed port automata to limits of port automata. proof. this holds since the flattening functor is cocontinuous (cf. theorem 1). thus, we have shown that a structural gluing of connectors in dis(paop) which is realized as a pushout of the network graphs has a corresponding semantical join operation, i.e., a pullback of the respective port automata. furthermore, theorem 1 shows that structure and semantics of distributed port automata form a pair of adjoint functors. 5.4 towards dynamic reconfigurations since distributed port automata integrate the structure and semantics of, e.g., reo connectors and petri nets, they can be used for problems occurring in the area of dynamic reconfigurations. an important issue is to determine the state of the system after a reconfiguration, which we refer to as the problem of state transfer. moreover, it is crucial to ensure that the new system state is indeed a valid one, which we refer to as the problem of state consistency. distributed port automata provide means for reasoning about state transfer and state consistency. to illustrate this, we revisit example 3 which shows how a pushout of reo networks at the structural level (figure 3(a)) corresponds to a pullback of port automata at the semantical level (figure 3(b)). we now interpret this as an application of a simple reconfiguration rule which adds a full fifo1 between the matched nodes c and a. essentially, we assume that figure 3(a) is the right part of a dpo diagram. in this view, the corresponding pullback of port automata can be seen as an application of a ‘semantical reconfiguration rule’ in the category of port automata. in such an approach, we can deduce the effect of an application of a purely structural reconfiguration rule on the connector semantics. for instance, assume that the connector to be reconfigured (lower left automaton in figure 3(b)) is in its initial state q1, in which both fifo1s are empty. the image in the left-hand side of the rule (upper left automaton) is state q. moreover, we assume that the fifo1 to be added by the rule is initially full, i.e., the selected state in the right-hand side of the rule is q1. this information is sufficient to deduce the state of the connector after the reconfiguration. the pullback construction given in theorem 2 yields as new target state q11 in the resulting automaton. thus, we can determine the state after a reconfiguration, which provides us with a means to solve the problem of state transfer. now assume that before the reconfiguration, the fifo1(a, b) and fifo1(b,c) are already full, i.e., the automaton in the upper right part is in state p1 and the automaton in the lower left proc. gtvmt 2011 10 / 14 eceasst part is in state p2. both states are mapped to state p in the upper left automaton, and therefore correspond to state p12 in the lower right automaton, which is not shown because it is unreachable from the initial state. in this particular state, all three fifo1s are full and the connector would run into a deadlock. therefore, it is crucial to check in which state the connector currently is, before reconfiguring it. in essence, this is the problem of state consistency. in the distributed port automata approach, we can characterize reconfigurations which yield consistent connector states by demanding that the target state of the reconfigured connector must be reachable from the initial (or the current) state. 6 related work constraint automata [bsar06] are a compositional model for reo [arb04]. our port automata are an abstraction of constraint automata where data constraints are ignored. the compositionality result in [bsar06] says that the semantics of a connector can be computed out of the semantics of its constituent primitives. our notion of compositionality is more general since it works with arbitrary gluings of connector graphs. in fact, we generalize the join operation of [bsar06] by allowing to join two automata along a common context automaton. graph transformation based reconfigurations for reo are considered in [kmla11]. reasoning about dynamic reconfigurations is accomplished by modeling both the execution and the reconfiguration semantics as graph transformations. this enables state space generation and analysis using model checking. however, the approach is not compositional, since graph grammars in general are not compositional. a model for distributed connectors and their reconfigurations is suggested in [kav09]. similar to the approach in this paper, the distributed connector model is based on distributed graph transformation. however, the semantics of connectors is not considered and, thus, dynamic reconfigurations cannot be modeled. a basic logic for reasoning about connector reconfigurations in reo, including a model checking algorithm is the topic of [cla08]. different than the work in this paper, the author uses a formalization of connectors, which is particularly not a graph model. moreover, the reconfiguration operations are rather low-level and provide no means for a rule-based definition of reconfigurations. we also mention some related work on petri nets. a marking graph semantics of petri nets is considered in [per01]. similarly to our approach the authors show compositionality of this semantics using a pair of adjoint functors. a compositional semantics for open petri nets based on deterministic processes is considered in [bceh05]. a categorical approach to automatabased semantics for petri nets is considered in [ds02]. however, this approach is more restrictive than our port automata model, since concurrent actions imply interleaved semantics. 7 conclusions we have presented distributed port automata – a model for component-based software systems, which uses (i) an automata-based model for specifying the semantics of the primitives, e.g. channels and components, and (ii) a graph-based model to describe the structure of the system in 11 / 14 volume 41 (2011) distributed port automata terms of a connector or a network. we have shown that the flattening functor for distributed graphs can be used to derive the semantics of distributed port automata and, moreover, that it is compositional. for this purpose, we have shown that the flattening functor has a right-adjoint. as future work, we plan to extend our approach to exploit the full theory of algebraic graph transformation. since our model is based on distributed graph transformation, we expect to be able to apply existing results for this purpose. bibliography [arb04] f. arbab. reo: a channel-based coordination model for component composition. mathematical structures in computer science 14:329–366, 2004. doi:10.1017/s0960129504004153 [bceh05] p. baldan, a. corradini, h. ehrig, r. heckel. compositional semantics for open petri nets based on deterministic processes. mathematical structures in computer science 15:1–35, 2005. [bcs09] m. bonsangue, d. clarke, a. silva. automata for context-dependent connectors. in coordination models and languages. lncs 5521, pp. 184–203. springer, 2009. [bsar06] c. baier, m. sirjani, f. arbab, j. rutten. modeling component connectors in reo by constraint automata. science of computer programming 61(2):75–113, 2006. doi:10.1016/j.scico.2005.10.008 [cla08] d. clarke. a basic logic for reasoning about connector reconfiguration. fundamenta informaticae 82(4):361–390, 2008. [cmr+97] a. corradini, u. montanari, f. rossi, h. ehrig, r. heckel, m. löwe. handbook of graph grammars and computing by graph transformation. chapter algebraic approaches to graph transformation i: basic concepts and double pushout approach, pp. 163–245. world scientific, 1997. [ds02] m. droste, r. m. shortt. from petri nets to automata with concurrency. applied categorical structures 10(2):173–191, 2002. doi:10.1023/a:1014305610452 [eop06] h. ehrig, f. orejas, u. prange. categorical foundations of distributed graph transformation. in icgt’06. lncs 4178, pp. 215–229. springer, 2006. doi:10.1007/11841883 [kav09] c. koehler, f. arbab, e. de vink. reconfiguring distributed reo connectors. in wadt’09. lncs 5486, pp. 221–235. springer, 2009. doi:10.1007/978-3-642-03429-9 [kc09] c. koehler, d. clarke. decomposing port automata. in sac’09. pp. 1369–1373. acm, new york, ny, usa, 2009. doi:10.1145/1529282.1529587 proc. gtvmt 2011 12 / 14 http://dx.doi.org/10.1017/s0960129504004153 http://dx.doi.org/10.1016/j.scico.2005.10.008 http://dx.doi.org/10.1023/a:1014305610452 http://dx.doi.org/10.1007/11841883 http://dx.doi.org/10.1007/978-3-642-03429-9 http://dx.doi.org/10.1145/1529282.1529587 eceasst [kmla11] c. krause, z. maraikar, a. lazovik, f. arbab. modeling dynamic reconfigurations in reo using high-level replacement systems. science of computer programming 76(1):23–36, 2011. doi:10.1016/j.scico.2009.10.006 [kra09] c. krause. integrated structure and semantics for reo connectors and petri nets. in ice’09. eptcs 12, p. 57. 2009. [lt05] j. de lara, g. taentzer. modelling and analysis of distributed simulation protocols with distributed graph transformation. in acsd’05. pp. 144–153. 2005. doi:10.1109/acsd.2005.27 [mil89] r. milner. communication and concurrency. prentice hall international, 1989. [per01] j. padberg, h. ehrig, g. rozenberg. behavior and realization construction for petri nets based on free monoid and power set graphs. in unifying petri nets, advances in petri nets. lncs 2128, pp. 230–249. springer, 2001. [tae99] g. taentzer. distributed graphs and graph transformation. applied categorical structures 7:431–462, 1999. doi:10.1023/a:1008683005045 a proof for theorem 1 proof. we consider the functor g : c → dis(c) which maps an object x ∈ c to the distributed object (1, (1 7→ x )) ∈ dis(c) and a morphism f : x → x′ to (id1, ( f )), where 1 is the terminal object in graph. we have f a g since there is a bijective correspondence: φx ,y : homc(fy, x ) → homdis(c)(y, gx ) that is natural in x ∈ c and y = (n, d) ∈ dis(c). the flattening functor f associates the colimit to a distributed object. thus, fy is the colimit of the diagram d together with c-morphisms (yn : d(n) → fy )n∈n . now, for a c-morphism h : fy → x we have the dis(c)-morphism φx ,y (h) = (!n , (h◦yn)n∈n ) : y → gx where !n : n → 1 is the terminal map for n in graph. the mapping φx ,y is bijective since all dis(c)-morphisms y → gx are of the above form. now let f : x → x′ a c-morphism and g : y ′ → y a dis(c)-morphism. the morphism gf : gx → gx′ is given as above. fg : fy ′→ fy is the unique morphism into the colimit object fy . now we need to show the following naturality condition: gf ◦φx ,y (h)◦g ! = φx′,y ′( f ◦h◦fg) : y ′ → gx′ we write y ′ = (n′, d′) and g = (gn′, (gm)m∈n′). moreover, let (y′m : d ′(m) → fy ′)m∈n′ the c-morphisms into the colimit of y ′. we now exploit the componentwise composition of dis(c)13 / 14 volume 41 (2011) http://dx.doi.org/10.1016/j.scico.2009.10.006 http://dx.doi.org/10.1109/acsd.2005.27 http://dx.doi.org/10.1023/a:1008683005045 distributed port automata morphisms: gf ◦φx ,y (h)◦g = (id1, ( f ))◦(!n , (h◦yn)n∈n )◦ ( gn′, (gm)m∈n′ ) = ( id1◦!n◦gn′, ( f ◦h◦ygn′(m)◦gm)m∈n′ ) = ( !n′, ( f ◦h◦ygn′(m)◦gm)m∈n′ ) = ( !n′, ( f ◦h◦fg◦y′m)m∈n′ ) (3) = φx′,y ′( f ◦h◦fg) equality (3) holds since fg is the unique morphism into the colimit fy . proc. gtvmt 2011 14 / 14 introduction distributed graph transformation channel-based coordination with reo building connectors port automata semantics the category of port automata the category of distributed port automata reo connectors as distributed port automata composing distributed port automata semantics of distributed port automata towards dynamic reconfigurations related work conclusions proof for theorem 1 incremental update of constraint-compliant policy rules electronic communications of the easst volume 39 (2011) graph computation models selected revised papers from the third international workshop on graph computation models (gcm 2010) incremental update of constraint-compliant policy rules paolo bottoni, andrew fish, francesco parisi presicce 18 pages guest editors: rachid echahed, annegret habel, mohamed mosbah managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst incremental update of constraint-compliant policy rules paolo bottoni1, andrew fish2, francesco parisi presicce1 department of computer science, sapienza university of rome, italy1, school of computing, engineering and mathematics, university of brighton, uk2 abstract: organizations typically define policies to describe (positive or negative) requirements about strategic objectives. examples are policies relative to the security of information systems in general or to the control of access to an organization’s resources. often, the form used to specify policies is in terms of general constraints (what and why) to be enforced via the use of rules (how and when). the consistency of the rule system (transforming valid states into valid states) can be compromised and rules can violate some constraints when constraints are updated due to changing requirements. here, we explore a number of issues related to constraint update, in particular proposing a systematic way to update rules as a consequence of modifications of constraints, by identifying which components of the rule have to be updated. moreover, we show the construction of sets of rules, directly derived from a positive constraint, to guarantee constraint preservation and constraint enforcement. keywords: constraints, incremental construction of rules, rule update. 1 introduction graph constraints and graph transformations provide a formal model for defining and managing strategic policies adopted by organisations with respect to security or access control issues. policies can be specified with constraints, while rules of a graph transformation system are used for consistent management of these policies. in both cases, the specifications are given within the framework of typed attributed graphs, with special attributes defining the relevant properties, while rules exploit application conditions to enforce consistency. by consistency, we mean that rules can only cause transformations from valid states to valid states. as a consequence, the class of graphs generated, starting from a valid graph, by using the rule is a subset of the class of graphs satisfying the constraints. usually, policies and rules are not fixed, but can evolve independently, following the introduction, revision or deletion of constraints and rules. in any case, at each moment the current set of constraints must be satisfied by the current collection of rules. two cases can be considered in which the consistency of the system can be compromised: introduction of new rules – which must be adapted to the current constraints – and definition of new constraints, again requiring rule adaptation. the identification of the modifications needed to adapt rules to constraints has been the subject of several studies [kmp05, hp09]. however, these usually require the complete analysis of each rule after each modification, without the possibility to adopt an incremental approach, taking into account the relations between the previous sets of constraints and rules. in this paper, we explore this problem offering two major contributions. first, we define a procedure which constructs a new collection of rules from the specification of a positive constraint, 1 / 18 volume 39 (2011) update of policy rules where each rule is guaranteed to preserve the constraint. second, we show how these rules can be incrementally updated when the constraint from which they were created is modified. the paper is complemented by two further contributions. first, we produce a set of rules to check and repair a model with respect to the introduction of a new constraint. second, we present a technique for checking if a rule, not generated by the procedure, has to be updated when a constraint is modified, and for computing the relevant updates. paper organisation. after presenting related work in section 2, we provide background notions on graph constraints and graph transformations in section 3. section 4 introduces the running example for the paper, while section 5 recalls the notion of security policy and presents a procedure for the construction of a collection of rules realising a policy. section 6 discusses modifications to rules derived from the procedure and section 7 draws conclusions and points to future work. 2 related work in [kmp05], a security policy framework is defined by giving a type graph, a set of (named) graph transformation rules, and two sets of simple positive and negative constraints, expressed as morphisms from a premise to a conclusion. a framework was considered to be (positive/negative) coherent if all the graphs derivable from the rules and consistent with the type graph satisfied all the (positive/negative) constraints. a number of constructions were given for repairing possible violations, by modifying rules with application conditions, in situations where different policy frameworks were merged. based on this approach, [kp06] defines a uml language to specify access control policies and exploits graph transformations to give a semantics and a verification method for such specifications. this line of research has also led to defining basic rules for controlling access in workflows [wwp08]. rules allow the addition/removal of tasks and roles, plus the execution of tasks, and application conditions are defined based on existing constraints. in [bfp10], we considered the construction of transformation units ensuring coherence with a simple form of nested constraints, admitting a single alternation of universal and existential quantifiers. the units were defined starting with the simple addition of an element, and producing repair rules to restore violated constraints. the procedures presented in this paper can also be exploited in transformation units, but each rule is guaranteed not to violate any constraint. habel and pennemann have extensively treated the problem of making rules compatible with nested constraints by adding positive and negative application conditions. in [hp09] they unify theories about application conditions [eehp06] and nested graph conditions [ren04], lifting them to high-level transformations. an existing rule is transformed to make it constraint preserving or constraint guaranteeing, but no direct construction of rules from constraints is given. orejas is investigating a new approach, called symbolic attributed graphs, relating attributed graph constraints with attribute evaluation (for a summary see [ol10]). for our restricted form of attributed evaluation, the presented techniques should be applicable with the same results. some works have studied the problem of constructing instances of metamodels, specialised by additional constraints. in [jkw08] constraints are given in a logical language, while [ektw06] uses ocl and tests constraints after rule derivation from the metamodel. using the terminology of [jkw08], ours is a soundness-preserving, rather than completeness-preserving, construction. while [kmp05] studied the modifications required by introducing new constraints, or merging gcm 2010 2 / 18 eceasst constraint systems, the consequences of modifying (weakening or strengthening) existing constraints were not analysed, nor does this problem seem to have been treated by other authors. 3 background we adopt the framework of attributed typed graphs. a graph g = (v,e,s,t) consists of a set of nodes v = v (g), a set of edges e = e(g), and source and target functions, s,t : e →v . for a set s, its cardinality is denoted by ∣ s ∣ and we use the notations ∣ g ∣v =∣v (g) ∣ and ∣ g ∣e=∣ e(g) ∣. in a type graph t g = (vt ,et ,st ,t t ), vt and et are sets of node and edge types, while the functions st : et →vt and t t : et →vt define source and target node types for each edge type. for g a typed graph on t g, there is a graph morphism type : g → t g, with typev : v →vt and typee : e → et s.t. typev (s(e)) = st (typee(e)) and typev (t(e)) = t t (typee(e)). to introduce attributes, we follow [eehp06], but we consider attributes only on nodes. intuitively, we partition v into vg and vd (d for domain), the sets of graph and value nodes, respectively, while e is partitioned into eg and ea (a for attribute). graph edges eg are equivalent to those for non-attributed graphs, while an attribute edge in the set ea defines the assignment of a value to an attribute of a node. moreover, we have s = sv ∪sa, with sv : eg → vg and sa : ea →vg; and t = tv ∪ta, with tv : eg →vg and ta : ea →vd. in a similar way, t g has distinct sets v gt and v d t of graph and value node types respectively, as well as distinct sets e g t and e at for graph and attribute edge types. given t ∈v g t , all nodes of type t are associated with the same subset a(t)⊂ e at of edge types, corresponding to the set of attribute names for t. formally: ∀t ∈ v gt [∃!a(t) ⊂ e a t [∀n ∈ vg[typev (n) = t =⇒ {typee(e) ∣ e ∈ ea ∧sa(e) = n} = a(t)]]] 1. values in vd are taken over the disjoint union of the set of sorts in a data signature dsig. in what follows, we call the structural part of g, its projection to elements typed on v gt and e g t . we use graph transformations according to the double pushout (dpo) approach [eept06]. a dpo rule has the form p : l l← k r→ r where l, k and r are called left-hand side, interface and right-hand side graphs, respectively, k contains the elements preserved by the rule application, and the morphisms l : k → l and r : k → r model the embedding of k in l and r. the left of figure 1 shows a dpo direct derivation diagram, modeling the application of a rule2 p : l l← k r→ r to a host graph g to produce a target graph h. first, the pushout complement d is evaluated. this is the unique graph for which morphisms k → d → g exist s.t. square (1) is a pushout (i.e. g is the union of l and d through their common elements in k). in particular, d contains the elements of g which are not in the image of the elements in l∖k. the pushout (2) is then computed, adding to d new elements to form h, viz. the elements in r∖k. we denote the application of the rule p on a match m : l → g by g ⇒mp h and write g ⇒p h to denote that h can be derived from g by applying p with respect to some match m for l in g. dpo rules for typed graphs are lifted to attributed typed graphs by considering algebras on some signature including the sorts for vd. since morphisms can only identify values in vd present in l and r, the modification of the value of an attribute a for a given node n from v1 to v2 is represented by removing an edge e1 of type a from n to v1 (i.e. e appears in l but not in k), and creating an edge e2 of the same type a from n to v2 (i.e. e2 appears in r but not in k). 1 in the graphs of this paper, some attributes may not be present for some node, indicating “don’t care” situations. 2 where no ambiguity arises, we will omit explicit mention of morphisms l and r. 3 / 18 volume 39 (2011) update of policy rules l m �� (1) k (2) loo r // k �� r m∗ �� yi j oi j // = xi ni ,, = yi j oo l m �� (1) xioo k (2) loo r // k �� r m∗ �� g dl∗oo r∗ // h g dl∗oo r∗ // h figure 1: dpo direct derivation diagram for simple rules (left) and with ac (right). in this paper we consider only rules which are only increasing (l = k) or only decreasing (k = r) in their structural parts. however, from proposition 1, rules of this form can be combined to express any dpo rule. to this end, the construction of an e-concurrent production (see figure 2), denoted by ∗e , is required, for an appropriate choice of the e-dependency relation [eept06]. proposition 1 any rule p : l lp← k rp→ r is equivalent to the e-concurrent production of two rules, one increasing and one decreasing. proof. with reference to figure 2, and with all unnamed morphisms identities, we have: 1. if p1 : l lp← k ik→ k and p2 : k ik← k rp→ r, then p1 is only decreasing, p2 is only increasing, and p = p1 ∗k p2. (in this case the role of e is performed by k.) 2. if l rq1→ q lq2← r is the pushout of l lp← k rp→ r and k is also its pullback (as in our case since l lp← k is injective), then q1 : l il← l rq1→ q is only increasing, q2 : q lq2← r ir→ r is only decreasing, and p = q1 ∗q q2. (in this case the role of e is performed by q.) case 1 proves the ⇒ direction and case 2 proves the ⇐ direction. k ||yyy y ""e eee q ||yyy y ""e eee l �� k �� lpoo // k ""e eee k ||yyy y koo rp // �� r �� l �� l �� oo rq1 // q ""e eee q ||yyy y r lq2oo // �� r �� l k lpoo // k koo rp // r l loo rq1 // q r lq2oo // r k iisssssssss 55lllllllll klp iirrrrrrrrr rp 55lllllllll figure 2: decomposing (left) and constructing (right) a rule with increasing and decreasing parts. an atomic constraint is a morphism3 of typed attributed graphs c : x →y . a graph g satisfies c, noted g ⊨ c, if for each match morphism m : x → g there exists a morphism y : y → g s.t. y∘c = m. if c : x →y is an atomic constraint, ¬c is an atomic constraint, and g ⊨ ¬c iff g ⊭ c. an atomic constraint of the form ¬ix : x → x , where ix is the identity, is called a negative atomic constraint, and is represented by simply showing x . we call m(c) = {g ∣ g ⊨ c} the set of models for c, and assume that a constraint system c is consistent, i.e. ∩ ci∈c m(ci) ∕= /0. the right of figure 1 shows that an atomic constraint can be associated with a rule in the form of an application condition ac, of the form {xi : l → xi,{yi j : xi → yi j} j∈ji}i∈i , for a match 3 except typing morphisms, all graph morphisms in the paper are inclusions. gcm 2010 4 / 18 eceasst m : l → g of the lhs of a rule, where i and ji are index sets for each i ∈ i. an ac is satisfied by m if, for each ni : xi → g s.t. ni ∘xi = m, there exists some oi j : yi j → g s.t. oi j ∘yi j = ni. a negative application condition (nac) derives from a negative application constraint: for the rule to be applicable, xi must not be present. 4 a scenario for policy update we consider policies on type graphs which are instances of the metamodel mm in figure 3 (left). here, document, personnel and resource are meta-types for graph node types, defining the structural elements involved in a policy, while state and level are metatypes for attribute types. in this case, the structural nodes are those whose type is an instance of document, personnel or resource. figure 3 (right) presents the specific type graph for the paper, where type doc is an instance of document, mgr, representing managers, is an instance of personnel, and the printer type is an instance of resource. the attribute types denote a document authorisation state and different types of access levels associated with structural elements. a concrete representation is adopted, where rectangular boxes represent instances of structural nodes in vg and ovals represent attribute values. attribute edges are distinguished from graph edges by the arrow end. figure 3: metamodel for security policies (left) and type graph for the scenario (right). a simple scenario illustrates the type of problems considered, introducing the notation exploited in the paper, consider an organisation in which the policy for document authentication requires that, for a document d to be authenticated, it must have been signed off by two managers, one of level lv1 and one of level lv2, lv2 being higher than lv1 in the organisation hierarchy. moreover, a general policy requires that documents signed off by lv2 managers must have also been signed off by an lv1 manager. figure 4 illustrates the two resulting constraints. 1:doc auth 1:doc auth :mgr :mgr lv1 lv2 1:doc :mgr 2:mgr lv2 lv11:doc 2:mgr lv2 1 x 1 c 2c 1 y 2y2x figure 4: the two original constraints for document authentication. the organisation adopts a collection of rules for authentication which is presented in figure 5. 5 / 18 volume 39 (2011) update of policy rules first an lv1 manager will provide a reference for the document, and then an lv2 manager will authorise it. the rules are equipped with nacs to avoid that the same manager reviews the same document twice. note that a rule which requires a simultaneous authorisation by both managers would also be consistent with the constraints in figure 4. 1:doc 2:mgr lv1 1:doc 2:mgr lv1 1:doc 3:mgr lv2 2:mgr lv1 1:doc 3:mgr lv2 2:mgr lv1 auth 1:doc 3:mgr lv2 2:mgr lv11:doc 2:mgr lv1 2,1 n 1,1 n 1 l 2l1r 2r 1 r 2 r figure 5: the two original rules for document authentication. realising that the current implementation of the policy does not prevent work on the same document from being duplicated, the organisation decides to forbid a document from being authorised twice, or referenced by two or more managers of the same level. such conditions could be added as nacs to the rules, but a decision is made for these to be defined as negative constraints – shown in figure 6 as forbidden graphs – ¬i : x3 → x3, ¬i : x4 → x4, and ¬i : x5 → x5, respectively, becoming part of the general policy for document management. x3 :doc :mgr :mgr lv1 x4 :doc :mgr :mgr lv2 :doc auth x5 figure 6: negative atomic constraints for the authentication policy. rules r1 and r2 of figure 5 are no longer consistent with the current configuration of constraints and must be amended by adding nacs to them. in particular, rule r1 must be upgraded with the nac n1,2 requiring that no other manager of level lv1 has already pre-approved the document, while rule r2 is upgraded using n2,2 to check that no authorisation already exists, besides requiring that no other lv2 manager has approved the document. figure 7 shows the new versions of the two rules. in a second moment, a general revision of the authorisation policies is issued, now requiring that two lv1 managers must approve a document, while maintaining the request for lv2 authentication, represented by the constraint c6 : x6 →y6 in figure 8, which subsumes c1 : x1 →y1. moreover, the constraint defined by the forbidden graph x4 must be dropped to ensure the overall satisfiability of the system of constraints. this modification has impact on both rules r1 and r2 in figure 7. indeed, condition n1,2 for gcm 2010 6 / 18 eceasst 1:doc 2:mgr lv1 1:doc 2:mgr lv1 :mgr lv1 1:doc 3:mgr lv2 2:mgr lv1 1:doc 3:mgr lv2 2:mgr lv1 auth 1:doc 3:mgr lv2 2:mgr lv1 1:doc 2:mgr lv1 1:doc 2:mgr lv1 1:doc 3:mgr lv2 2:mgr lv1 auth 1,1 n 1,2 n 2,2 n 2,1 n 1 l 2 l 1 r 2 r 1 r 2 r figure 7: the modified rules with nacs. 1:doc auth x6 y6 1:doc auth :mgr :mgr lv2 c6 :mgr lv1 figure 8: revising authorisation constraints. r1, which was derived from the forbidden graph x4, now dropped, would prevent the satisfaction of constraint c6 : x6 →y6. moreover, the right-hand side of rule r2 would not be consistent with c6, as it might lead to approval of documents without the signature of two lv1 managers. while the solution to the first problem is simple (remove n1,2), the second problem can be addressed in different modes: by requiring concurrent approval by the additional lv1 manager and the lv2 one, by sequentialising the approvals of the manager according to the level (i.e. simultaneous approval of both lv1 managers and subsequent lv2 approval) or by considering a sequential process, where the second lv1 and the lv2 approval can occur in any order. note that since c2 : x2 → y2 still holds, it remains impossible to have a collection of rules which leads to lv2 approval without prior or concurrent lv1 approval. 5 constraint-compliant policy rules we define the construction of sets of rules for enforcing consistency with policies, where rules are only increasing or decreasing in the structural part and may use only equality or inequality 7 / 18 volume 39 (2011) update of policy rules as operations on attributes. we first propose a procedure for deriving a collection of increasing (in the structural part) rules consistent with a positive constraint, based on the initial pushout construction in the category of attributed typed graphs [eept06]. given the square in figure 9 (left), this is the initial pushout over c : x → y , iff for every other pushout formed with x ← z → t → y , there exist morphisms x′ → z and q → t such that all the squares in figure 9 (right) commute. in the adopted framework, the boundary object x′ is computed as the discrete graph formed by the structural nodes in x which are attached to edges in e(y )∖e(c(x)), and the context of c is the attributed typed graph q which is the pushout complement along x′ for x′ x→ x c→y . x′ x // q′ �� x c �� x′ // q′ �� x ++z // �� x c �� q y // y q // y 33t // y figure 9: (left) boundary and context for a constraint. (right) initiality of pushout. we work on a restricted form of positive constraints c : x →y , for which we can derive a set of constraint-preserving rules. in particular, we define policy constraints on single secured nodes, describing the conditions under which such a node can be in certain states, as in the examples from section 4. in particular, structural edges are in e(y )∖e(x) only if both their source and target are in vg(y )∖c(vg(x)), or if one of them is the secured node. 5.1 the procedure for incremental satisfaction given a policy constraint c : x → y , constructrules(c) generates a collection p(c) of increasing rules preserving c. each rule constructs a subgraph of y , in such a way that until an occurrence of y is built no occurrence of x is produced in the host graph. to this end, it first constructs the rules for producing graphs intermediate between the boundary object x′ and the context q in the construction of the initial pushout over c, and then produces rules allowing the construction of intermediate graphs between q and y . after this, nacs are added to prevent the premature formation of y and to force the application of the most specialised rule in case of conflicts. finally, the rules are completed to include attribute assignment. function constructrules(c:constraint):setofrules = [q,h ] := fromboundarytocontext(c); pq(c) := frommorphismstorules(q,h ); p′(c) := completetoconclusion(pq(c),y ); p′′(c) := completewithnacs(p′(c)) p(c) := updateattributes(p′′(c)) fromboundarytocontext(c:constraint):graphset×morphset constructs the uniquely determined (up to isomorphism) sets q = {q0, ..., qk} and h = {h j i : qi → q j} of all and only the graphs and associated morphisms s.t. the following are jointly satisfied: gcm 2010 8 / 18 eceasst ∙ q0 = x′ and qk = q; ∙ for each i = 1,...,k, there exist inclusions4; hix′ : x ′ → qi and h q i : qi → q; ∙ for each i = 1,...,k, for j > i s.t. h ji : qi → q j exists, h j x′ = h j i ∘h i x′ and h q i = h q j ∘h j i ; ∙ q is the colimit of the diagram obtained from graphs in q and morphisms in h ; ∙ given h ji : qi → q j we have that: ea ∈ ea(q j)∖ea(qi) =⇒ sa(ea)∈vg(q j)∖vg(qi) 5. frommorphismstorules(q:graphset,h :morphset):setofrules produces the intermediate rule set pq(c) ={p(h j i ) : qi l ← qi r → q j∣r = h j i : qi →q j ∈h }, under the conditions: 1. given qi,q j,ql ∈ q and h j i ,h l i,h l j ∈ h , we have h l i = h l j ∘h j i =⇒ p(h l i) ∕∈ pq(c); 2. either q j = qk or eg(q j) ∕= eg(q), i.e. the structural part of the right hand-side is equal to the structural part of the context q only in rules which add some structural edge. completetoconclusion(int:setofrules,conc:graph):setofrules builds the set p′(c) by generating the set iqy of all the graphs z s.t. inclusions k1 : q → z and k2 : z → y exist, but no inclusion k3 : x → z exists. the set hiqy of morphisms hzq : q → z, hyz : z →y , s.t. y is the colimit of the diagram formed with nodes in iqy ∪{q} and morphisms in hiqy ∪{y : q→y}, is concurrently built as before. in particular, as for each e∈e(y )∖e(c(x)) we have e ∈ e(q), graphs in iqy ∖{y} can only differ from q by: (i) structural nodes in v (x) not connected with the secured node in y ; (ii) structural edges attached to such nodes; and (iii) attribute edges already present in x (hence neither in x′ nor in q). the structural parts of rules in a new set py (c) is built through the same construction as in frommorphismstorules for cases (i) and (ii). for case (iii), for any attribute edge ea ∈ ea(w ) s.t. w ∈ iqy ∧∄e′a ∈ q, with hwq (e ′ a) = ea, we produce a primed version q ′ i for each graph qi ∈ q s.t. ∃v ∈ v (qi), with hwq (h q i (v)) = s(ea) ∈ v (w ), i.e. we have e ′ a ∈ e(q′i) with s(e′a) = v and t(e ′ a) = t(ea). as a consequence, q ′ is still the colimit of the diagram for the primed versions of the graphs in q. we then correspondingly update the rules with the attribute parts for all the rules derived from morphisms involving qi. the function then returns the union of the modified versions of py (c) and pq(c), forming the set p′(c). the rules in p′(c) are underspecified. given morphisms h ji and h i l , both rules derived from them in p′(c) are applicable on any match for h ji . completewithnacs(rls:setofrules): setofrules constructs a nac forcing the application of the more specific rule. given pi : ql l← ql r→ qi ∈ p′(c), we add a nac qi ni← ql for each hil . moreover, nacs are added to prevent the formation of the premise x in rules with p : l l← l r→ r ∕= y . in particular, we define the graph w s.t. y ,,x′oo // l //w is a pushout and add the nac w n← l to p. finally, updateattributes(rls:setofrules):setofrules takes care of attribute update for the secured node, producing the final set p(c). this is needed for the case where the 4 in order to emphasize x′ = q0 and q = qk we abuse notation, writing h q i for h k i : qi → q and h i x′ for h i 0 : x ′ → qi. 5 as value nodes are assumed to always exist, we leave them implicit when not associated with structural elements. 9 / 18 volume 39 (2011) update of policy rules constraint concerns the assignment of a value d for an attribute of the secured node v, i.e. ∃ea ∈ ea(x) with s(ea) = v and t(ea) = d. any rule p : z =← z r→y is such that ea ∈ ea(y )∖ea(r(z)), but v ∈ vg(z). however, for a host graph g and a match m : z → g, there can be an edge e′a ∈ e(g) with s(e′a) = m(v) and t(ea) = d, for some d ∈ v da, d ∕= d, where v da is the set of values of sort a in the domain d. the application of p would then produce two values for the same attribute. to avoid this problem, we transform any such rule into a version with attribute update zd l← z r→y , for each d ∈v da. in particular, zd contains an edge ea with s(ea) = v and t(ea) = d, so that the overall effect of the rule is to produce an occurrence of y while updating the previous attribute assignment for v. we call rules with r = y final. following theorem 1, given a constraint c the resulting set p(c) is consistent with c. theorem 1 given a constraint c : x →y , a graph g with g ∣= c, and a rule p : l = k → r ∈ p(c), for any graph h s.t. g ⇒p h we have h ∣= c. proof. if g ∣= c, then one of two cases occur. 1. ∃m : x → g,g : y → g, with m = g∘c. as all rules are increasing and c is positive, each application of p preserves m and g. we are left to prove that no further match m′ : x →g is created for which a match g′ : y → g with m′ = g′∘c does not exist. we first observe that an additional match would require the addition of an edge (either structural or attribute) e to g, with s(e) = v, v = m′(v). but, due to the construction in completetoconclusion and the nacs added in completewithnacs, this only happens in a final rule, which would also generate the required part to complete the match g′. 2. ∄m : x → g. by the same argument as before, we observe that any non final rule would not create such a match, while a final rule would also create the required match g : y → g. no other case can occur and this concludes the proof. to maintain consistency over the whole policy, a rule p : l =← l r→ r ∈ p(c) should be checked against any constraint c′ : x′ →y ′, with c′ ∕= c, for situations where applying p would cause the formation of x′ without ensuring the formation of y ′. figure 10 shows the possible solutions (for reasons of space we omit the morphisms l =← l). the first (left) generates a nac where w ′ is a graph s.t. the span r w′← w ′ w→ x′ exists and r rz→ z′ ← x′ is the cospan s.t. the resulting square is a pushout. then the nac n : l → n is generated, with n the pushout complement of l r→ r rz→ z′. this construction can be applied both for negative and positive constraints. alternatively, in figure 10 (center), one extends l and r by adding to both of them the “missing part” of y ′. the morphisms l r→ r and w ′ w ′ → r are jointly surjective on r, the triangle commutes, and all squares are pushouts. l′ is constructed as the pushout complement for l r→r rw→r′. these constructions (adapted from those in [kp06]) can be applied if the required pushout complements exist. otherwise, figure 10 (right) presents an alternative construction generating a more restrictive nac, with n = rz ∘r. a negative constraint can only generate a nac. a word on complexity is in order. the upper bound for ∣ q ∣ is ∣ q ∣e ×2(∣q∣v−∣x ′∣v ) (reached when all node types are different). however, given the form of the constraints we are considergcm 2010 10 / 18 eceasst l n �� r // r rz �� w ′ w′oo w �� l r // �� r rw �� w ′ w′oo w �� // x′ c′�� l r // n ��; ;; ;; ;; r rz �� w ′ w �� oo n // z′ x′oo c′ // y ′ l′ r′ // r′ y ′oo z′ x′oo c′ // y ′ figure 10: permissive nac (left), rule extension (centre) and restrictive nac (right) for c′. ing, that security policies are usually not exceedingly large in their structural size, and that the procedure has to be computed once, the approach remains feasible in many practical situations. example figure 11 shows the construction of the boundary and context graphs for c1 : x1 →y1 from figure 4, while figure 12 presents the construction of the sets q and h for this case. we have indicated only direct morphisms, and omitted those which can be derived by transitivity. 1:doc auth 1:doc auth :mgr :mgr lv1 lv2 1:doc 1:doc :mgr :mgr lv1 lv2 'q 1 'x 1 x 1y 1 c complement.pdf figure 11: the construction of the context for c1 : x1 →y1 in figure 4. the top of figure 13 shows how the last rule derived from morphism hq6 would be modified. as the whole context for c : x →y is present, we can complete the right-hand side to be the full y , i.e. presenting also an instance of x . underneath this rule, we show one of its possible final versions, assuming that preauth ∈ authstate. such a rule would be generated only if such a state is compatible with the presence of the association of the document with a manager of level 1, i.e. if the preauth state is not associated with some constraint forbidding the presence of the association with such a manager. in the policy in our original scenario, the constraint c2 : x2 →y2 from figure 4 will have to be used to modify the rules p(h42) and p(h q 5 ). 5.2 repairing inconsistencies the above procedure ensures that secured elements are treated consistently with respect to constraints, while the constructions described in the next section can be used to modify rules in a way consistent with policy updates. however, it is also possible that after the adoption of a new policy, some occurrence of the secured element v is in an inconsistent state for a new constraint c : x →y , i.e. with g a graph describing the current situation of the organisation, we would have 11 / 18 volume 39 (2011) update of policy rules 1:doc 1:doc 2:mgr lv1 1:doc 2:mgr lv1 1:doc 3:mgr lv2 1:doc :2mgr :3mgr lv1 lv2 1:doc 3:mgr lv2 1:doc 3:mgr lv2 2:mgr lv1 1:doc 3:mgr lv2 2:mgr lv1 1:doc 3:mgr 2:mgr lv1 lv2 4 2 h 7 2 h 7 1 h 3 1 h 6 3 h5 4 h 5 7 h 6 7 h 5 q h 6 q h q 1 'x 2 q 4 q 5 q 3 q 6 q 1 q 1 2 'x h 1 1 'x h 7 q figure 12: the sets q and h in constructrules(c1). a match x : x → g, but no match y : y → g s.t. x = y∘c. considering figure 4 (left), a document which was authorised after being reviewed only by a manager of level 1 would be inconsistent with the new policy. there are two possible ways to repair this inconsistency. the first is to complete the configuration, so that the missing review is provided. this is achievable by forcing the application of a sequence of rules, constructed in a similar manner to that of the procedure above, to produce an instance of the conclusion for the existing instance of the premise. an alternative method destroys all the occurrences of the premise, so that a securing process can now be applied according to the new policy. given a positive constraint c : x → y , and depending on the form of the premise x , two possible types of modification can be identified. 1. if v is associated in x with some attribute, the rule x l← x′ r→ x′ (with x′ boundary object for the initial pushout over c) removes all the associations of this element with its attributes. 2. if the secured element has a set s of structural edges incident with it in x , generate the collection of edge-removing rules rs = {x l← x′ r→ x′ ∣ e(x′) ⊈ e(x)}. each rule constructed in either way can be associated with a nac of the form n : x →y and applied to g. if the nac fails, then c is satisfied, as the occurrence of x is associated with an occurrence of y and no modification is required. otherwise, the rule is applied on a match for x , but its application invalidates this match. with reference to the construction of p(c), we can observe that a match for some qi ∈ q has now been generated, so that a consistent model can be restored by applying some rule in p(c) with l = qi. gcm 2010 12 / 18 eceasst 1:doc 3:mgr lv2 2:mgr lv1 1:doc :2mgr :3mgr lv1 lv2auth lastrule.pdf 1:doc 3:mgr lv2 2:mgr lv1 1:doc :2mgr :3mgr lv1 lv2authpreauth 1:doc :2mgr :3mgr lv1 lv2 lastrulemodified.pdf figure 13: ensuring constraint c1 (top) and one version updating the state (bottom). 5.3 rule-constraint conflict in this subsection, we complete our study by considering possible conflicts between decreasing rules and arbitrary atomic constraints (i.e. positive or negative). while a deleting rule never violates a negative constraint, since it does not add forbidden graph elements, it may violate a positive constraint if the rule deletes conditionally required graph elements (parts of the conclusion) but preserves the premise of the constraint. one way to resolve conflicts between rules p and constraints c : x →y is by adding nacs to the rules p. we present next the construction of these nacs in a general case (generalising that in figure 10) and then show how it is used to resolve conflicts. definition 1 (conversion) given a rule p : l lp← k rp→ r and a constraint c : x → y , let s be a nonempty overlap between r and the conclusion y (preserving x ) as in the diagram of figure 14 (left). let d = r +s y be the pushout object of s1 : s → r and c∘s2 : s → y , and let d p−1,h ⇒ n be the derivation with the inverse rule p−1 : r rp← k lp→ l with match h. define ac(p,c) = {n : l → n∣ d (p−1,h) ⇒ n, d = r +s y for some overlap s}. the rule pc consists of the original rule p : l lp← k rp→ r together with the set ac(p,c) of nacs, and is called the conversion of p by c. l n �� k lpoo rp // �� r h �� s s1oo s2 // x c �� l m �� r = k lpoo �� n m r∗p //oo c yoo g h l∗poo xkoo c �� y q′ bbdddddddddq dd figure 14: construction for conflicts. nacs (left) and satisfaction by conversion (right). the construction considers arbitrary rules and constraints, i.e., it is not restricted to deleting 13 / 18 volume 39 (2011) update of policy rules or expanding rules, and it reduces to the one in [hw95] if c : x →y is the identity morphism. this construction may generate redundant application conditions, in the case, for example, where the overlap s → r can be decomposed into s → k → r. the graph n generated from such an overlap can be eliminated by requiring only overlaps s for which s1(s)∩(r∖rp(k)) ∕= /0. another form of redundancy stems from the fact that if s1 and s2 are overlaps with s1 ⊆ s2 and compatible morphisms si1 and s i 2 with i = 1,2, then d2 = r +s2 y ⊆ d1 = r +s1 y and thus n2 ⊆ n1. hence, if a match l → g satisfies (l,n2), then it also satisfies (l,n1) and the application condition (l,n1) can be removed from ac(p,c). a negative constraint is a morphism !c : x → y , and g ∣=!c iff no morphism m : x → g can be extended to a morphism m′ : y → g s.t. m = m′∘!c. in the special case where !c is the identity we obtain what we called forbidden graphs. there can be no real conflict between a deleting rule p : l lp← k = r and a negative constraint !c : x →y , since the deleting rule may remove parts of y , in which case !c is trivially satisfied, or parts of x , in which case !c is vacuously satisfied. for the potential conflict between deleting rules and positive constraints we can add nacs to prevent the rule from destroying the conclusion y , by preventing the applicability if x is present and part of the conclusion y is intended to be deleted by the rule. theorem 2 (satisfaction by conversion) let p : l lp← k = r be a deleting rule and let ac(idl, idy )) be the nacs constructed as in definition 1 for the rule idl : l → l with respect to the constraint idy : y →y . define pc = (p,a(idl,c)). if g ∣= c : x →y and g pc ⇒ h is a derivation with pc, then h ∣= c. proof. in figure 14 (right), let g p ⇒ h via the matching morphism m : l → g and k : x → h a morphism. since p is deleting, the derivation induces a morphism l∗p : h → g and therefore a morphism k′ = l∗p ∘k : x → h → g. by the assumption that g ∣= c, there exists a morphism q : y → g s.t. q∘c = k′. to complete the proof we need to show that there is a q′ : y → h s.t. k = q′∘c. since l∗p is injective, it is sufficient to show that q(y)∈ l∗p(h) for every y ∈y . suppose this is not the case. then, ∃y ∈ y,l ∈ l∖ lp(r) s.t. q(y) = m(l) and therefore this y defines an overlap of l and y , contradicting the assumption that m satisfies the nac ac(idl,c) of pc. 6 incremental update we analyse the problem of incrementally updating the rules in p(c) when the original positive constraint c : x → y is replaced by a new one, cu : x u → y u, according to one of the following modifications, with inequalities indicating inclusion from the smallest to the biggest graph. we study modifications preserving the image of the original premise in the original conclusion for the common parts of x and x u and of y and y u, and in particular preserving the secured node. 1. (conclusion expansion) x = x u, y < y u 2. (conclusion reduction) x = x u, y > y u 3. (premise expansion) x < x u, y = y u gcm 2010 14 / 18 eceasst 4. (premise reduction) x > x u, y = y u 5. (semantic reduction) x > x u, y < y u 6. (semantic expansion) x < x u, y > y u 7. (common expansion) x < x u, y < y u 8. (common reduction) x > x u, y > y u we do not consider modifications which simultaneously add some elements and delete others from the premise or the conclusion of a constraint. hence, if a premise is expanded, the conclusion is reduced only by removing parts neither in the original nor in the expanded premise. we consider the creation of new rules or updates of the existing l, r or nac parts of the rules, while new nacs can be generated according to the constructions in the section 5. from figure 15 (left), modeling premise expansion, we observe that if a graph g satisfies c non trivially, i.e. g has a subgraph which is a match for y , it will also satisfy cu under the same match. on the other hand, the only rules in p(c) which can produce an occurrence of x u are final rules (producing the corresponding original occurrence of x by placing an edge attached to the secured node), so no modification is required to them. for the case of conclusion reduction, centre of figure 15, we observe that we can only remove elements which are not in x . hence, we can simply modify a rule p : l l→ r ∈ p(c) by removing all elements in v (y )∖v (y u)∪e(y )∖e(y u) from both l and r. the combination of premise expansion and conclusion reduction defines what is called semantic expansion, as m(c) ⊂ m(cu). indeed, considering the diagram on the right of figure 15, we observe that for each graph g, g ∣= c =⇒ g ∣= cu. on the other hand, we can have a graph g with g ∕∣= c (i.e. a match m : x → g exists which cannot be extended to a match y : y → g) and g ∣= cu, if no match mu : xu → g exists (i.e. g trivially satisfies cu). x u ��< << << << cu && xoo c // �� y �� x cu &&c // ��: :: :: :: y �� y uoo �� x u m′ &&mm mm mm mm mm mm cu ** xoo c // m ��: :: :: :: y �� y uoo xxr r r r r r g g g figure 15: premise expansion (left), conclusion reduction (centre), semantic expansion (right). figure 16 (left) presents premise reduction, where one notices that the evaluation of the initial pushout for cu would give a smaller x u′ and a bigger qu. hence, one has to perform a construction similar to that of fromboundarytocontext and frommorphismstorules to generate the rules creating the intermediate graphs between x u′ and x′. furthermore, for a rule p : l l← l r→ r ∈ p(c) with x u included in l or r, a new rule p′ is created with each such occurrence of x u replaced by an occurrence of x u′. for conclusion expansion, figure 16 (center), one notes that the construction of the initial pushout would now give a qu greater than q. hence, we have to construct the rules for the morphisms for graphs intermediate between q and qu and between qu and y u, while removing 15 / 18 volume 39 (2011) update of policy rules those derived from graphs intermediate between q and y . these can be easily identified, as they present any of the elements in y u and not in y , but they do not present at least one element in x . semantic reduction in figure 16 (right) combines premise reduction and conclusion expansion. the relative modifications can be derived from the composition of the two processes. x u ��< << << << cu &&// x c // �� y �� x cu &&c // ��: :: :: :: y �� // y u �� x u &&mm mm mm mm mm mm cu **// x c // ��: :: :: :: y �� // y u xxr r r r r r g g g figure 16: premise reduction (left), conclusion expansion (centre), semantic reduction (right). in a similar way, common expansion and common reduction can be obtained by combining the above processes, in the following order: ∙ for common expansion, expand y to y u first, and then expand x to x u, in both cases expanding the morphism so as to preserve the image of x in y . ∙ for common reduction, reduce x to x u first, and then reduce y to y u, in both cases reducing the morphism so as to preserve the image of x in y . one wonders whether a similar construction can be defined when simultaneously removing and including elements in both premise and conclusion (while preserving the secured node). figure 17 illustrates the problem with this. in order to maintain incrementality, one needs to first identify the intersections x′ and y ′ between the original and the updated versions, update under common reduction for x′→y ′, and then use common expansion to generate p(cu) for cu : x u → y u (left). alternatively, one can first use common expansions and then common reduction, where the intersections are x′′ and y ′′ (right). but in this case there is no guarantee that the nodes which receive the additional edges in y and y ′ are the same. hence, depending on the order in which the transformations are applied, one can obtain different rule sets. x′ �� // y ′ �� < << << << x′ xoo c // y // y ′ x u cu 55x c // y y u x u oo cu 55x′′oo oo // y ′′ oo // y u oo figure 17: incorrect constructions for simultaneous removal and increment. example considering the scenario in section 4, figure 8 presents a case of conclusion expansion, making stricter requests on the authorisation process. following the algorithm above, the construction of the new rules for this policy starts with the identification of the rules in l ∈ ly1 ; in this case rule r2 : l2 → r2 in figure 7 (omitting the study of the modification of nacs). we then need to replace r2 with the set of rules constructing the intermediate graphs between l2 and gcm 2010 16 / 18 eceasst the modified conclusion y6, with the proviso that x can appear only in the right-hand side of the rule building the whole y6. figure 18 shows the process replacing rule r2 with rules r′2 and r 2 2 . 1:doc 3:mgr lv2 2:mgr lv1 1:doc 3:mgr lv2 2:mgr lv1 auth 𝐿2 𝑅2 𝑟2 1:doc 3:mgr lv2 2:mgr lv1 :mgr 1:doc 3:mgr lv2 2:mgr lv1 4:mgr 1:doc 3:mgr lv2 2:mgr lv1 4:mgr auth 𝑟2 2 𝑅2 2 𝐿2 2 𝑅2 ′ 𝑟2 ′ figure 18: revising rule r2 from the scenario. 7 conclusions and future work we have presented an approach to the construction of incremental procedures ensuring the application of rules consistently with atomic constraints and to the modification of such procedures in an incremental way after the modification of the original constraints. the approach works under a number of assumptions, which are reasonably met in practical cases. first, conclusions in constraints are defined by graphs with a specific relation with the premise, viz. only one node can receive additional edges. second, constraint updates preserve the images for the preserved elements in the premise (i.e. we do not deal with revocation [hjpw01]). third, constraints and rules are typed according to a metamodel maintaining distinct finite domains for each attribute and allowing only equality comparison operations among values. the procedures are defined as sets of rules, which can be exploited in different contexts, or organised into transformation units, typically consistent with the partial order induced by injections on structural parts of graphs. the study of more general cases is a complex one. we prevent rules from creating matches for x if they are not final rules. however, if we relax the form of the constraints to consider secured configurations instead of secured nodes, situations may arise in which matches can be created other than just the one for which the extension to y is provided. in this case more complex repair actions must be defined. also, one needs to consider what happens when arbitrary graph morphisms are considered instead of only injective ones. this problem can be investigated in versions where arbitrary morphisms can be used for matches of constraints, of rules, or both. a final line of investigation concerns the possibility of lifting the constructions in the paper to high level structures. while we basically rely on pushouts (in particular the initial pushout) and colimits for the construction of the incremental procedure, we require a form for constraints which is related to their setting in the category of graphs. the study of a more general type of constraints could then give indications on how to generalise the approach. 17 / 18 volume 39 (2011) update of policy rules acknowledgments. partially funded by progetto sapienza 2007: ”sistemi interattivi per la fruizione e la produzione di eventi culturali”. bibliography [bfp10] p. bottoni, a. fish, f. parisi-presicce. preserving constraints in horizontal model transformations. eceasst 29, 2010. [eehp06] h. ehrig, k. ehrig, a. habel, k.-h. pennemann. theory of constraints and application conditions: from graphs to high-level structures. fundam. inform. 74(1):135–166, 2006. [eept06] h. ehrig, k. ehrig, u. prange, g. taentzer. fundamentals of algebraic graph transformation. springer, 2006. [ektw06] k. ehrig, j. m. küster, g. taentzer, j. winkelmann. generating instance models from meta models. in proc. fmoods 2006. lncs 4037, pp. 156–170. springer, 2006. [hjpw01] å. hagström, s. jajodia, f. parisi-presicce, d. wijesekera. revocations-a classification. in csfw. pp. 44–58. 2001. [hp09] a. habel, k.-h. pennemann. correctness of high-level transformation systems relative to nested conditions. mathematical structures in computer science 19(2):245– 296, 2009. [hw95] r. heckel, a. wagner. ensuring consistency of conditional graph rewriting a constructive approach. entcs 2:118–126, 1995. [jkw08] m. janota, v. kuzina, a. wasowski. model construction with external constraints: an interactive journey from semantics to syntax. in proc. models 2008. pp. 431– 445. 2008. [kmp05] m. koch, l. v. mancini, f. parisi-presicce. graph-based specification of access control policies. j. comput. syst. sci. 71(1):1–33, 2005. [kp06] m. koch, f. parisi-presicce. uml specification of access control policies and their formal verification. software and system modeling 5(4):429–447, 2006. [ol10] f. orejas, l. lambers. symbolic attributed graphs for attributed graph transformation. eceasst 30, 2010. [ren04] a. rensink. representing first-order logic using graphs. in proc. icgt. lncs 3256, pp. 319–335. springer, 2004. [wwp08] y. wei, c. wang, w. peng. graph transformations for the specification of access control in workflow. in proc. wicom ’08. pp. 1–5. 2008. gcm 2010 18 / 18 introduction related work background a scenario for policy update constraint-compliant policy rules the procedure for incremental satisfaction repairing inconsistencies rule-constraint conflict incremental update conclusions and future work verifying a mix net in csp electronic communications of the easst volume 66 (2013) proceedings of the automated verification of critical systems (avocs 2013) verifying a mix net in csp efstathios stathakidis, david m. williams and james heather 15 pages guest editors: steve schneider, helen treharne managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst verifying a mix net in csp efstathios stathakidis1∗, david m. williams2† and james heather1 1 {e.stathakidis, j.heather}@surrey.ac.uk department of computing, university of surrey, guildford, uk 2 d.m.williams@vu.nl theoretical computer science, vu university amsterdam, the netherlands abstract: a mix net is a cryptographic protocol that tries to unlink the correspondence between its inputs and its outputs. in this paper, we formally analyse a mix net using the process algebra csp and its associated model checker fdr. the protocol that we verify removes the reliance on a web bulletin board during the mixing process: rather than communicating via a web bulletin board, the protocol allows the mix servers to communicate directly, exchanging signed messages and maintaining their own records of the messages they have received. mix net analyses in the literature are invariably focused on safety properties; important liveness properties, such as deadlock freedom, are wholly neglected. this is an unhappy omission, however, since a mix net that produces no results is of little use. here we verify that the mix net is guaranteed to terminate, outputting a provably valid mix agreed upon by a majority of mix servers, under the assumption that a majority of them act according to the protocol. keywords: mix nets, formal methods, model-checking, csp, fdr 1 introduction a mix net is a cryptographic protocol which conceals the correspondence between the initial vector of encrypted input values and the permuted vector of decrypted values given as output. no protocol participant should be able to link a single encrypted input to its specific corresponding decrypted output, although all participants must be assured that a bijective relationship between inputs and outputs exists. it was first introduced by chaum [cha81] for anonymous mail. usually, a mix net consists of a number of mix servers that collectively execute a protocol; most recent mix nets rely on a public-key encryption scheme, such as elgamal [gam85], that allows re-encryption of ciphertexts. the inputs are submitted under the joint public key of the mix net, and each individual mix server receives a list of encrypted messages (ciphertexts), re-encrypts each of them, permutes the resulting vector and outputs the re-encrypted and re-ordered list to the web bulletin board (wbb). the re-encryption and mixing is peformed by each mix server sequentially. to ensure the correctness of the operation to the other mix servers, each mix server produces a “proof of shuffle”. the output of the last mix server may be decrypted by a threshold number of tellers and then posted on the wbb for public verification. golle et al. [gjjs04] outline such a mix net. ∗ author sponsored by the epsrc under the trustworthy voting systems (tvs) project. † author sponsored by the nwo under the design and analysis of secure distibuted protocols (dasdip) project. 1 / 15 volume 66 (2013) mailto:\protect \t1\textbraceleft e.stathakidis, j.heather\protect \t1\textbraceright @surrey.ac.uk mailto:d.m.williams@vu.nl verifying a mix net in csp mix nets have been proposed for use in real-life applications, including anonymous web browsing and electronic cash payments, rfid tags and untraceable mail systems. their main application is electronic-voting [adi08, rbh+09, bch+12], where they are used to ensure that a voter’s vote cannot be tracked and revealed throughout the process, providing voter privacy and anonymity. although their anonymity has been exhaustively analysed and proved, early mix nets were not fault-tolerant as a dishonest mix server could corrupt the execution in order to stop the whole process or result in an invalid or inconsistent output. in this work we are interested in both liveness and safety properties that a mix net should fulfil, namely robustness and privacy as described in section 4. furthermore, one assumption often made in the mix net literature is the existence of a publicly verifiable and trusted site, called a web bulletin board (wbb) [hl08, wg06, wik04]. the mix servers communicate with each other via the wbb and the mix net achieves universal verifiability as anyone has read access to it and can verify the stored information. however, the bulletin board has proved notoriously slippery to construct in practice. here, we replace this assumption with two others that are far easier to realise: first, that all communication is performed over authenticated channels; and secondly, the honest majority assumption, under which strictly more than half of the mix servers act according to the protocol. on this basis, we remove the need for a wbb during mixing, and verify a mix net that allows direct communication between the mix servers. in what follows, we will retain some notion of a wbb for publication of the final mix data from each server. this is simply because the final result of the mix needs somehow to be published; obviously if there is no way at all of making something available permanently for public consumption then there is no way of effectively completing the mix. however, this is a much weaker assumption than that of its existence during mixing. the final publication problem can be solved by putting the mix data up, suitably signed, on various news organisations’ web sites, for example, or releasing it on bittorrent; but these mechanisms are not appropriate for live communication between mix servers during the mixing process. essentially, the wbb that we use to publish the final mix data corresponds simply to an assumption that after the mix servers have done their work, the honest servers have a reliable way of getting the message ‘out there’. our contributions. our primary contribution is the formal analysis of a mix net that performs mixing with no centralised trusted authority in place but instead enables direct communication between the mix servers using authenticated channels. rather than posting to, and reading from, a central wbb that records a consistent record of all messages sent, each mix server maintains its own local perspective throughout the rounds of mixing, receiving signed messages broadcast to them by other mix servers and broadcasting their own signed messages to all others. secondly, we verify that our proposed protocol meets its requirements using the csp process algebra and the fdr model-checker. we analyse our protocol in the presence of a realistic intruder model, based on roscoe and goldsmith’s perfect spy [rg97]. it is important to analyse mix nets’ security properties before using them, as many constructions have been broken after they were introduced. combined, our results show that our protocol guarantees to terminate and guarantees consensus among a majority of mix servers of the final chain of mixes in the presence of a minority of dishonest mix servers that do not faithfully follow the protocol. proc. avocs 2013 2 / 15 eceasst organisation. we begin, in section 2, by discussing previous work on mix nets. in section 3, we describe a subset of the csp process algebra that is sufficient for constructing our model. we propose our protocol in section 4 that removes the need of the wbb during mixing. we then construct a csp model of our mix net in section 5. results of the formal analysis of the model are given in section 6, and we conclude the paper in section 7 with a discussion of possible future research directions. 2 previous work in this section, we survey previous work in mix nets where liveness is of major concern. robustness is the liveness property regarding successful termination in the presence of faulty mix servers. the first mix net introduced by chaum [cha81] is not robust, as in the case where one of the mix servers does not work, the execution stops and no output is obtained. sako and kilian [sk95] proposed mix net constructions that are not robust either: if at least one mix server stops responding, then the entire system stops without outputting a result. jakobsson [jak98] presented a practical mix net which was believed to be robust until desmedt and kurosawa [dk00] found an attack such that at least one malicious mix server can prevent the mix net from computing the correct result. in these approaches the mixing can not proceed if a single mix server is unavailable. distributed consensus protocols, such as [psl80], guarantee agreement on a vector of values that includes those of all honest nodes. our requirements of mix nets need not be this strong: we require that some mix of threshold length be agreed by a majority of mix servers, although all honest mix servers’ mixes need not be included. another weakness in the mix net literature is the assumption of the existence of a wbb that supervises the mixing process. each mix server reads what is posted on the wbb, operates on what was read and posts back to the wbb. most of the constructions are based on the strong assumption that the wbb is authenticated, tamper-proof and resistant to denial-of-service attacks. wisktröm and groth [wg06] proposed an adaptively secure mix net based on ideal functionalities for a wbb [wik04]. the existence of such a publicly verifiable site is not realistic and practical in real-life applications, however, as it is a single point of failure. if it is unavailable, the entire process stops and the mix net does not complete and does not produce an output. although they are the building blocks for constructing secure real-life applications, mix nets have been proposed without formal analysis and automated verification. wikström [wik04] proved that his verificatum mix net is secure in the universal composable symbolic model, but his analysis excludes constructions with proofs of shuffles. moreover, his scheme does not satisfy the liveness property, as when a mix server raises a complaint about another’s honesty, then the whole process stops and manual intervention is needed in order to exclude the faulty mix server. process algebras like π -calculus [af01] have been used to analyse electronic voting schemes with very limited references to mix nets. kremer et al. [krs10] and delaune et al. [dkr09] used the π -calculus language to model and analyse important voting properties like voter-privacy, coercion-resistance, receipt-freeness and verfiability in the presence of an ideal wbb-based mix net, and the use of csp and its associated refinement checker fdr have proved successful in finding previously unknown flaws in security protocols [low96, rs01]. we use the csp/fdr approach to analyse the robustness of a mix net, the first such analysis for a mix net. 3 / 15 volume 66 (2013) verifying a mix net in csp 3 preliminaries communicating sequential processes (csp) is a process algebra used for verifying complex concurrent systems. the core of the csp algebra is a process, which is described by the way it communicates with its environment. processes proceed from one state to another by engaging in events. the alphabet of a process p, denoted α p, records the set of all visible events that this process may perform. the set of all possible events is denoted by σ. in csp, all the communication events are instantaneous and they happen only when both the processes and the environment agree on their occurrence. for a more detailed explanation of csp we refer the reader to [ros98]. stop is the simplest csp process, which does nothing. the process a → p is initially willing to communicate a and then behaves like p. p 2 q can act either as p or q, the choice of which is in the hands of the environment. replicated external choice replicates the choice over the set a , and is denoted by 2 x∈a p(x). by p ‖ a q we denote generalised parallel, which synchronises p and q on events lying in the set a . alphabetised parallel is denoted by p ‖ α p α q q, and synchronises p and q on events lying in the intersection of α p and α q. we write ‖i∈i [α p]p(i) for the replicated alphabetised parallel composition of processes p(i) indexed over i, where each p(i) is allowed to perform events from α p and the processes are synchronised on the common events. in hiding, p \ a , the internal events from a are hidden from the environment. in renaming, [[a/b]], the events b occurring in the process are replaced by the events a. for two decades the failures/divergences refinement (fdr) checker has been the principal tool for verifying properties of models expressed in csp. fdr tests whether the csp model of the system being analysed refines some specification of the system’s desired behaviour, which is also written in csp. we omit details of the datatypes and channel definitions in the csp model of a mix net presented in section 5, as they can be inferred from the data values ascribed to them; however, we shall provide definitions of certain sets and functions used throughout the model. the set of all mix servers is denoted by p and is defined to be h ∪d , where h (resp. d ) denotes the set of all honest (resp. dishonest) mix servers. by max(d), we denote the dishonest mix server with the highest identity. by |a |, we denote the cardinality of a set a , by pa we denote the powerset function as applied to a set a , and we use a 8b to denote set difference, subtracting all elements of a set b from a set a . honest mix servers send broadcast messages to all other mix servers at once, whereas the intruder is able to send different messages to individual mix servers. thus, it is useful to define a set r = {x ∈ pp | |x| = n −1 or|x| = 1} of the possible message recipients, where n is the total number of mix servers. by α , we denote an unmixed vector. by mj(m), we denote the vector m mixed using mix server j’s secret permutaion value, where m is either the unmixed vector α or some mix thereof. by ρ(mj(m)) we denote the zero knowledge proof that the operation producing mj(m) from m was performed as attested to. messages, also referred to as chains, then have the form sj(mj(m),ρ(mj(m)),s), where s is its corresponding sub-chain. chains are so called, as they are extended at each mixing stage, although a better analogy is of a matryoshka nesting doll. the mix from a previously received chain (or α in the base case) is mixed, the mixing operation attested to and the whole of the previously received chain are all signed together, such that a proof of each operation in the chain is nested within each ‘layer’ of the message. the length of a message m is denoted by #m and is calculated by counting these layers of signatures, i.e., proc. avocs 2013 4 / 15 eceasst sub-chains. messages cannot be longer than the total number of mix servers. the set of all messages that can be feasibly sent and received in a protocol run is denoted by m . messages do not require every mix server to be included, signing some sub-chain within the chain, but the signatures throughout a chain are required to be in strictly increasing order. moreover, it is not possible for a mix server to deduce how a vector of values has been mixed, even with knowledge of the values before and after mixing as well as the zero knowledge proof. an honest mix server will never sign a mix chain unless it has produced the final mix in the chain. this is not necessarily true of the dishonest mix servers. the message space of m takes these properties into account, omitting messages that could not feasibly be sent in a protocol run. the outer signatory of a message is verified using the corresponding public key; we use a function outer(m) to return the signatory of a given message m. likewise, seq(m) returns the outer mix sequence of m. the set of all possible output mixes, o, is taken to be {seq(m) | m ∈ m}. 4 our proposed mix net in this section we propose our mix net, which avoids use of the wbb for communication between mix servers during the mixing process. our protocol is guaranteed to terminate in the presence of a dishonest minority. upon termination of the mixing process, the mix servers post partial decryptions to the wbb and at least one valid chain of threshold length will be fully decrypted/agreed upon by a majority of mix servers. the primary difference from current mix nets found in the literature is that each mix server maintains their own ‘local’ record of the chain of mixes instead of maintaining a consistent ‘global’ record via the wbb. 4.1 requirements an honest mix server follows the protocol without deviating from it, produces correct shuffles and valid proofs. it sends the same message to all other mix servers using authenticated channels. conversely, a dishonest mix server tries to disrupt the protocol such that it does not terminate, or otherwise, upon termination, causes a dispute among the honest mix servers. to try and achieve these goals, the intruder acts as a byzantine faulty node under the limitation of a perfect cryptography assumption, i.e., the intruder can refuse to send messages, it need not send messages to all other mix servers, and can try to send messages that it can construct but that do not necessarily follow the protocol. the intruder may send different messages to different mix servers. the output of a mix net should be a complete chain of provably valid mixes. a chain is considered complete if its length is strictly greater than n2 , where n is the number of servers, and each mix is a proven valid mix of the mix in its sub-chain. we consider the mix net robust if it always returns such output, regardless of the behaviour of the dishonest minority. it is conceivable that not every honest server has a mix represented in the final chain; it is a requirement, however, that at least one mix has been produced by an honest server to maintain privacy. 4.2 protocol description when the protocol starts, all mix servers are provided with the initial list of unmixed ciphertexts, α , as the initial candidate mix to be mixed. each mix server has a unique identity between 1 and 5 / 15 volume 66 (2013) verifying a mix net in csp 2 1 3 s2(m2,s1(m1,α)) s1(m1,α) s3(m3,s2(m2,s1(m1,α))) figure 1: a mix net with three honest mix servers the total number n of mix servers. mix server 1 is the first mixer and all mix servers maintains a counter to record the identity of the current mix server. initially, mix server 1 re-encrypts α using new randomness and shuffles using its own local and secret permutation, thus producing the mix m1(α). to prove the correctness of the re-encryption and shuffling, it proves, in zero-knowledge, that m1(α) was formed correctly from α , producing the proof ρ(m1(α)). it then signs those two values along with α , with its own signing key, to produce s1(m1(α),ρ(m1(α)),α). we shall call such messages chains, where the length of this chain is said to be 1, as it has just one layer of mixing and signing. the other mix servers acting as checkers wait to receive the first mixer’s signed output or for a timeout to occur. each checker extracts the message from inside the signature and checks the proofs against the latest mix. in later rounds they will also have to do this for the inner signatures and inner proofs. if any of the proofs do not check out, then the message is rejected and the checker waits for a message containing valid proofs to arrive or for a timeout to occur. if the message is valid, i.e., is a chain containing a complete sequence of valid proofs, then the length of the chain is calculated by counting the number of layers of signatures. if the length of the chain is equal to or exceeds the length of the checker’s current candidate chain, the current candidate chain is updated to be the most recently received chain. otherwise it remains unaltered. they increment the counter and, if it is their turn, they do the mixing. having received the message s1(m1(α),ρ(m1(α)),α) and verified the signature and proof of mixing, the second mix server mixes m1(α) to produce m2(m1(α)) and must also produce the associated zero knowledge proof ρ(m2(m1(α))). he signs this to produce the message s2(m2(m1(α)),ρ(m2(m1(α))),s1(m1(α),ρ(m1(α)),α)), which is a complete chain of length two. as chains get longer throughout the protocol, we abbreviate this to s2(m2,s1(m1,α)). figure 1 illustrates the messages exchanged in a run of the protocol in the presence of three honest mix servers faithfully following the protocol. following receipt of the first two messages, the third mix server acts as mixer and sends s3(m3,s2(m2,s1(m1,α))) to the other two mix servers. all the mix servers maintain a record of the valid chains that they sent or received during the protocol that are longer than n2 . subsequently, they shall post all such chains, partially decrypted, onto the wbb. hence, a polynomial number of different outputs will appear on the wbb. any chain that has been partially decrypted by at least a majority of mix servers can be used as the final output, with preference given to the longest. proc. avocs 2013 6 / 15 eceasst 5 modelling and formal analysis in csp in this section, we present the processes and specifications used to model and analyse our mix net. we describe the processes modelling the honest and dishonest mix servers, and then compose them into models to be checked for robustness and privacy. the complete script can be found at http://www.tvsproject.org/csp/mixnet.csp. 5.1 honest mix servers the behaviour of the honest mix servers can be split into four phases: checking before mixing; mixing; checking after mixing; and posting the results to the wbb. the first mixer will of course perform no checking before mixing and the final mixer will do no checking after mixing. chk1(me,curr,tobemixed) = if curr < me then  timeout → chk1(me,curr + 1,tobemixed) 2 2 m∈{m′∈m |outer(m′)=curr}   recv.m → timeout → if #m ≥ #tobemixed then chk1(me,curr + 1,m) else chk1(me,curr + 1,tobemixed)     else mix(me,curr,tobemixed) chk1 models the initial phase of checking before mixing. using tobemixed, the honest checker keeps track of the chain that it will use once it becomes mixer, and also records the identity of the current mixer, curr. the checkers are willing to receive any valid mix, represented in chk1 by the external choice over valid chains signed by the current mixer, but block receipt of invalid mixes, and mixes signed by a server who is not the current mixer. this abstracts away the behaviour of receiving a mix containing an invalid proof, or an incorrectly signed message. if a checker times out before (resp. after) receiving a valid chain, then tobemixed remains the same (resp. is updated with the new chain if not shorter than the last) and curr is incremented. mix(me,curr,tobemixed) =  send.sme(mme,tobemixed)→timeout → chk2(me,curr + 1)   chk2(me,curr) = if curr ≤ n then  timeout → chk2(me,curr + 1) 2 2 m∈{m′∈m |outer(m′)=curr}   recv.m →timeout → chk2(me,curr + 1)     else done → stop if the mix server counter is its own, the mix server enters the mixing phase. it performs the mixing using tobemixed, and sends a new chain to the other mix servers. honest mix servers do not time out before sending a message (we assume that the timeout value is sufficiently large that an honest mix server will have time to complete its work and send the result out). thereafter, the mix server need not keep track of tobemixed as it will not need to perform any more mixing. the current mix server counter is incremented by one, and the mix server continues to be involved in checking other servers’ mixes (that is, it continues on to the chk2 process). in the checking after mixing phase, checkers can time out before or after receiving a valid chain, in a similar manner to the previous checking phase. once curr exceeds the total number 7 / 15 volume 66 (2013) http://www.tvsproject.org/csp/mixnet.csp verifying a mix net in csp of mix servers, the mixing protocol terminates as modelled by the done event. the mix server is now ready to post its results to the wbb. each mix server must record all chains it sent or received during mixing, and post partial decryptions of those with length greater than n2 . a particular mix could become known to a mix server in a number of ways. it could feasibly have arrived several times, in messages signed by different mix servers. like the various learnable facts in roscoe and goldsmith’s perfect spy [ros98], a mix server starts off being ignorant of each possible mix, as modelled by ign. note that ign is defined in terms of a mix, sq, and not a message. the mix can be learnt, after which it becomes known; thereafter it can be said. the mix server could also calculate the mix themselves from its tobemixed value, modelled here as say, which can only occur in synchrony with the mix process. otherwise, the protocol terminates before the occurrence of a learn or say of this mix and the process deadlocks. once known, a mix could potentially be learnt or said again in the knw process, without changing the state. following a done event, the mix can be posted (to the wbb), as long as the chain is over the threshold length, as defined in pst . ign(sq) =  done → stop2 learn.sq → knw(sq) 2 say.sq → knw(sq)   knw(sq) =  done → pst(sq)2 learn.sq → knw(sq) 2 say.sq → knw(sq)   pst(sq) =  if #sq > n2 thenpost.sq → pst(sq) else stop   to realise when a mix is received via a message, we rename each learn.sq to all possible recv.m in which the message would return the corresponding mix, and likewise we rename say.sq to all possible send.m. the renamings of all ign processes, one for each possible mix, are composed in parallel, synchronising only on the one event their alphabets share, namely done. subsequently all send, recv and done events are synchronised with the process chk1(me,1,α), which initialises the local perspective of the mix server, me, with the current mix server counter set to the first mixer and the tobemixed parameter set to the unmixed value α . hon(me) = chk1(me,1,α)‖ {|send,recv,done|} (‖sq∈o[{done}]ign(sq)[[ recm.m,send.m/learn.sq,say.sq m∈m ,seq(m)=sq ]]) a global perspective of the honest mix server does not just send and recv messages. instead it is defined in terms of the connections a mix server shares with others. hence, each send is renamed to an outgoing comm.me.p8{me}, distributing the sent message to all mix servers other than me. likewise, each recv is renamed to an incoming comm.x.z, where x is some mix server other than me, and z is either the singleton set containing only me or the set of all mix servers other than x. honest mix servers will send to everyone, whereas the dishonest mix server could choose to send different messages to different mix servers or choose to send messages to some mix servers but not others. the mix server does not know how the message arrived: he sees the protocol only in terms of the hon process. however, when analysing the system, we can see which messages were distributed to whom by synchronising the various renhon processes, which gives a view of the protocol from a networking perspective. the post event is renamed in a similar fashion such that groups of mix servers can synchronise on an agree event, modelling the threshold decryption. renhon(me) = hon(me)[[ comm.me.p8{me}.m/send.m m∈m ]] [[ comm.x.z.m/recv.m m∈m ,x∈p8{me},z∈r,x 6∈z,me∈z ]] [[ agree.z.sq/post.sq sq∈o,z∈pp,|z|> n2 ,#sq> n 2 ]] our final models are constructed using alphabetised parallel composition. as things stand, if both are honest, mix server 1 will communicate with mix server 2 each time 1 sends a mix to proc. avocs 2013 8 / 15 eceasst all mix servers via comm.1.p8{1}. however, although mix server 2 is willing to receive this message, it is also willing to communicate via comm.1.{2} as, locally, it is unable to distinguish the two types of communication. the alphabetised parallel composition will ensure that no events comm.1.{2} ever occur in the model, as long as we define appropriate alphabets. the alphabet of mix server me is defined below. α hon(me) ={comm.me.z.m |m∈m ,z∈r,me6∈z}∪{comm.y.z.m |m∈m ,y∈p8{me},z∈r,me∈z,y 6∈z} ∪{agree.z.m |m∈m ,z∈pp,|z|> n2 ,me∈z,#m> n2 }∪{timeout,done} we can already compose a system in which all mix servers are honest, that is d = /0. allhon =‖i∈h [α hon(i)]renhon(i) to perform a more rigorous analysis we must of course include an intruder model. 5.2 dishonest mix servers we use the roscoe and goldsmith’s perfect spy process [rg97], more specifically its encoding in [ros98], as the basis of the intruder (dishonest mix server) behaviour, although we use a different renaming as we are not considering a dolev yao attacker [dy83]. the spy can receive messages sent to it over learn, infer events based on messages received and its initial knowledge and say messages that it has inferred that may be accepted by the honest mix servers. upon receipt of a message, the intruder can sometimes make a number of independent inferences in any order. roscoe and goldsmith’s perfect spy avoids refinement checking an unnecessarily large state space caused by this combinatorial explosion. whenever an inference is made, the intruder does not lose the ability to perform any action that could be done prior to the inference. this observation allows one to force the intruder immediately to perform every possible inference in some arbitrary order before taking any other action. this causes no observable difference in the intruder’s behaviour, but avoids otherwise troublesome state space explosion. furthermore, deductions need only be made for the misbehaving agent’s set of learnable facts. that is, the intruder can never learn a fact that it knew initially or that cannot be deduced from its initial knowledge and all the messages it could hear. roscoe and goldsmith’s spy elegantly omits inferences of such facts. each deduction function operates on a subset of the set of facts conforming to a particular type. two deduction rules are sufficient for our purpose. the first allows a signed fact to be learnt from knowledge of the fact and the signing key, and to deduce the fact from knowledge of the signed fact and the signatory’s public key. the second allows a sub-chain to be deduced from a chain. remember s2(m2,s1(m1,α)) abbreviates s2(m2(m1(α)),ρ(m2(m1(α))),s1(m1(α),ρ(m1(α)),α)). from knowledge of this message and mix server 2’s public key the intruder can extract a sequence of three values: the mix, the proof and the sub-chain. even with knowledge of the mixed values before and after this round of mixing, as well as the zero knowledge proof, the mixer’s secret permutation value is not revealed. hence, in our abstract representation of this message, the intruder cannot deduce the value m2, but can deduce the sub-chain included in this chain, or the chain as signed by the intruder, or can extend the chain with an extra mix as signed by the intruder. deductions1(x) ={({m,sk(i)},si(m)),({si(m),dual(sk(i))},m) | si(m)∈ x} deductions2(x) ={({m,m′},(m,m′)),({(m,m′)},m′) | (m,m′)∈ x} the only other change we make to spy is to redefine the intruder’s initial knowledge. this consists of all mix server identities, the secret permutation values of all dishonest mix servers, all mix servers’ public keys for verifying signatures, and the initial unmixed vector of values. 9 / 15 volume 66 (2013) verifying a mix net in csp known′ = p ∪{mi,sk(i) | i ∈ d}∪{pk(i) | i ∈ p}∪{α} the spy process has in its alphabet learn allowing information to be received and say allowing messages to be sent. internally, infer actions allow messages to be inferred such that additional say actions may become possible, i.e., additional messages can be sent once they have been deduced by the intruder. in order to compose spy with the honest mix server processes renhon, we must rename spy such that it appropriately communicates with the other mix servers. renspy = spy[[ comm.x.p8{x}.m,say.m,comm.max(d).{x}.m/learn.m,say.m,say.m m∈m ,x∈h ]] [[ agree.z.seq(m)/say.m m∈m ,z∈pp,|z|> n2 ,z8h 6=/0,#m> n 2 ]] each say event is renamed to comm.max(d).{x}. locally, the mix servers are unable to distinguish where messages originated from, and so it does not matter which of the identities of the dishonest mix servers the intruder uses to send messages. as such, we reduce the number of transitions by enabling the intruder to use only the highest numbered dishonest mix server, without limiting the intruder’s capability to attack the protocol. the intruder can send different messages to different mix servers, so each message is sent to an individual mix server—that is, to the singleton set {x}, where x is the identity of some honest mix server. if the intruder wishes, like the honest servers, to send the same message to all mix servers, he simply unicasts the same message to each honest mix server. the intruder learns all messages sent to any of the dishonest mix servers’ identities, so it is not necessary for, say, dishonest mix server 1 to send messages to dishonest mix server 2. as the intruder hears all messages sent to any of the mix servers identities, and all honest mix servers send to all mix servers other than themselves, learn events are renamed to comm.x.p8{x} where x is again the identity of some honest mix server. we may wish our intruder to contribute to the group agreements of the final output, so the say events should also be renamed to agree.z events, where z is any set of servers that contains the identity of at least one dishonest mix server. our use of the alphabetised composition operator ensures that the mix servers are synchronised on appropriate events. α spy ={comm.y.p8{y}.m |m∈m ,y∈h }∪{comm.x.z.m |m∈m ,x∈d,z∈r,x 6∈z} ∪{agree.z.m |m∈m ,z∈pp,|z|> n2 ,z8h 6=/0,#m> n2 } now that we have constructed processes that capture the behaviour of the honest and dishonest mix servers, we can compose them together for analysis. 5.3 requirements and assertions we shall construct three systems for the analysis of the protocol. each system involves a set of honest mix servers that follow the protocol faithfully, and may include an intruder that has control over a subset of mix servers, receiving any message sent to these mix servers. initially, we analyse allhon, in which all mix servers faithfully follow the protocol. in this case, we expect all servers to agree on the longest of the mix chains that is sent on the network, received in the final round. each mix server partially decrypts this chain and publishes the result. if more than half of the mix servers post a partial decryption of the same chain to the wbb, then this decrypted chain of mixes will be considered as the final output of the mix. this output is modelled in our system as a synchronous agree event among a majority of mix servers agreeing on the output message. we wish to check that it is guaranteed that some agree event occurs. proc. avocs 2013 10 / 15 eceasst rbst = agreement → rbst rbst vfd (allhon \ σ8{| agree |})[[agreement/agree.x.sq |x∈pp,sq∈o ]] using the failures/divergences model (fd), we check that it is not possible for our model to diverge or deadlock before the occurrence of the agreement event. as all events other than agree have been hidden and all agree events renamed to agreement, this checks that no loops or deadlocks exist prior to the performance of some agree. thus, this captures our robustness requirement that agreement on some complete and valid mix is guaranteed. once we introduce the intruder model, it will be possible that some chains have been received by some mix servers but not by others. we check the same robustness requirement of this model. rbst vfd((allhon ‖α allhon α spy renspy)\ σ8{agree})[[ agreement /agree.x.sq |x∈pp,sq∈o ]] where α allhon = ⋃ ({α hon(i) | i ∈ h }) we perform the same check on a model in which the intruder outputs no chain, in an attempt to stop any chain being agreed upon by a threshold of mix servers. rbst vfd((allhon ‖α allhon α spy (renspy ‖ {|agree|} stop))\ σ8{agree})[[agreement/agree.x.sq |x∈pp,sq∈o ]] we also require a message to be private as described in section 4.1. for this we check that no majority of mix servers can agree on a non-private mix. priv = 2 x∈pp y∈{sq∈o|private(sq),#sq> n2 } agree.x.y → priv priv vt (allhon ‖α allhon α spy renspy)\ σ8{agree} these assertions are sufficient for guaranteeing that our protocol terminates and guarantees consensus among a majority of mix servers of a complete chain of mixes in the presence of fewer than n2 mix servers that do not faithfully follow the protocol. we check these assertions in fdr, considering all possible combinations of honest and dishonest mix servers, with up to five mix servers in total, and a majority of them being honest. in all cases fdr confirmed that our models satisfy the specified requirements. 6 results of analysis in this section, we verify the protocol against liveness and safety properties. we start with all mix servers being honest. when we check the protocol with five honest mix servers, as expected, we find that they all agree on the same chain of valid mixes. moreover, the privacy of the mixes is guaranteed. the trace below illustrates this behaviour. each of the traces discussed in this section were obtained via simulation of the models in probe, a csp animator that allows a user to explore how a process behaves. in this first trace, each honest mix server times out when sending out a new signed message. 〈comm.1.{2,3,4,5}.s1(m1,α), timeout, comm.5.{1,3,4,5}.s2(m2,s1(m1,α)), timeout, comm.3.{1,2,4,5}.s3(m3,s2(m2,s1(m1,α))), timeout, comm.4.{1,2,3,5}.s4(m4,s3(m3,s2(m2,s1(m1,α)))), timeout, comm.5.{1,2,3,4}.s5(m5,s4(m4,s3(m3,s2(m2,s1(m1,α))))), timeout, done, agree.{1,2,3,4,5}.m5(m4(m3(m2(m1(α)))))〉 11 / 15 volume 66 (2013) verifying a mix net in csp in fact, after the done event, any subset of mix servers larger than three can agree on any of the three candidate mixes, m5(m4(m3(m2(m1(α))))), m4(m3(m2(m1(α)))) or m3(m2(m1(α))). in this case m5(m4(m3(m2(m1(α))))) will be considered the final output as it is the longest mix agreed upon by a majority of mix servers. more interesting traces result from checking the protocol with three honest and two dishonest mix servers. analysing the protocol with the two last mix servers being dishonest leads to a larger state space because (i) the intruder learns to say more throughout the execution, and (ii) the honest mix servers accept longer messages and therefore many more messages throughout time, so the intruder has lots of choices about what to send in the last two rounds. the intruder can send different messages to different mix servers or can follow the protocol faithfully. in the latter, we end up with the same trace as above. when the intruder behaves dishonestly, we guarantee that a sufficient number of mix servers agree on the same output and at least one of them is honest, which means that the privacy is satisfied. in the case where the dishonest mix servers simply time out, all of them or any subset of length four or three would agree on the chain produced by the honest mix servers, e.g., agree.{1,2,3}.m3(m2(m1(α))). a more curious behaviour is illustrated below. here, the intruder acting as dishonest mix server 2 times out without sending any message. later, acting as 5, the intruder sends a valid but short message to an honest mix server, and sends two valid but differing messages to the other honest mix servers. honest mix servers 1, 3 and 4 follow the protocol faithfully: 1 constructs the initial mix, 3 mixes what it received directly from 1 following the timing out of 2, and 4 mixes what it received from 3. dishonest 5 then proceeds to send the valid but differing mixes to the honest mix servers. 〈comm.1.{2,3,4,5}.s1(m1,α), timeout, timeout, comm.3.{1,2,4,5}.s3(m3,s1(m1,α)), timeout, comm.4.{1,2,3,5}.s4(m4,s3(m3,s1(m1,α))), timeout, comm.5.{1}.s5(m5,α), comm.5.{3}.s5(m2,s4(m4,s3(m3,s1(m1,α)))), comm.5.{4}.s5(m5,s4(m4,s3(m3,s1(m1,α)))), timeout, done, agree.{1,3,4}.m4(m3(m1(α)))〉 if the dishonest mix servers refrain from posting any partial decryptions then, as illustrated in the trace, the only possible output is a chain of valid mixes mixed only by the honest mix servers. if the dishonest mix servers are willing to post partial decryptions, then it is possible that other mixes will be agreed upon as the final output. dishonest 2 and 5 are able to agree with honest 3 (resp. 4) on the mix m2(m4(m3(m1(α)))) (resp. m5(m4(m3(m1(α))))). as 2 received a mix that was shorter than a mix previously received, the only threshold length mix he is willing to decrypt is m4(m3(m1(α))). in any case the privacy is maintained, as each of these possible outputs include mixing by all three honest mix servers. a more interesting behaviour occurs when the dishonest mix servers swap valid mixes constructed by honest mix servers with valid mixes generated by dishonest mix servers. the reader should note that the dishonest 2 can swap a valid mix by the first mix server with a valid mix generated by himself and send it to all honest mix servers. honest 3 mixes and signs what it received from the second mix server and forward it to the others; honest 4 then does likewise. on the other hand, dishonest 5 replaces what it received from honest 4 with his own valid mix and sends the corresponding complete and valid chain to the other mix servers. proc. avocs 2013 12 / 15 eceasst 〈comm.1.{2,3,4,5}.s1(m1,α), timeout, comm.5.{1}.s2(m2,α), comm.5.{3}.s2(m2,α), comm.5.{4}.s2(m2,α), timeout, comm.3.{1,2,4,5}.s3(m3,s2(m2,α)), timeout, comm.4.{1,2,3,5}.s4(m4,s3(m3,s2(m2,α))), timeout, comm.5.{1}.s5(m5,s3(m3,s2(m2,α))), comm.5.{3}.s5(m5,s3(m3,s2(m2,α))), comm.5.{4}.s5(m5,s3(m3,s2(m2,α))), timeout, done, agree.{1,2,3,4,5}.m5(m3(m2(α)))〉 in this case, as in the other, three or more mix servers agree upon mixes of threshold length, i.e., length three or more. the best the intruders can do is to swap valid mixes, such that the agreed output m5(m3(m2(α))) excludes the mixes of honest 1 and 4. honest 3’s mix is still guaranteed to be a mix within the agreed upon chain, maintaining privacy. it is also possible that an agreement is made on m4(m3(m2(α))) as all mix servers also have this valid mix, which is equal in length to m5(m3(m2(α))). either, or both, can be agreed to be the final output of the mix net as both mixes decrypt to the same vector of values, only ordered differently. moreover, both are of threshold length include a mix by at least one honest mix server. all these traces arise from our specification of the protocol and might not have been appreciated without this formal analysis. however, none of them breaks the requirements. the best the intruder could do was to replace some but not all of the honest mix servers’ mixes with valid mixes of his own. 7 conclusion and future directions for the first time, we have conducted a formal analysis of a mix net, using csp/fdr. we showed how to remove the need of a trusted authority during the mixing phase, and instead introduced direct communication between the mix servers. our analysis demonstrates that our mix net is guaranteed to terminate, and output a provably valid mix agreed upon by a majority of mix servers, as long as a majority of them act according to the protocol. moreover, at least one honest mix server’s mix operation is guaranteed to be included in the output chain of mixes. in our model, we included an intruder based on roscoe and goldsmith’s perfect spy that is able to control some minority of mix servers. the dishonest mix servers can collaborate by sharing knowledge between them. we have shown that our system remains free of deadlocks and infinite loops, and is guaranteed to output a chain of valid mixes of length at least equal to the number of honest mix servers. we included three different intruder models and verified the protocol against them. in all cases we proved that its liveness and safety properties hold. thanks to the data-independence results by lazic and roscoe [lr99], a correctness result on a mix net with x messages applies to mix nets with an arbitrary number of messages. the number of mix servers we have used in this paper is typical for applications like electronic voting. in victoria [bch+12], the election commission will be running the elections with five mix servers, under the assumption that at least four of them are honest. our analysis covers this real-world case and more. one future goal is to analyse the protocol under a stronger intruder model. to introduce a 13 / 15 volume 66 (2013) verifying a mix net in csp dolev-yao attacker that has full control of the network [dy83], and that could intercept and block every message, would clearly violate robustness. it is therefore of interest to consider to what extent the assumptions made about the threat environment can be relaxed whilst still maintaining the properties we have checked. for example, it may be pertinent to replace the current synchronous communication between the honest mix servers with asynchronous communication over resilient channels in the manner proposed in [wrf12]. here, the intruder can intercept a message sent between the honest mix servers and delay it from arriving, but cannot indefinitely block the message’s receipt, as long as the recipient is always willing to receive it. there remains outstanding work to scale the approach proposed in [wrf12] to cover our models, which have state space and alphabets that are currently too large to be feasibly checked in this manner. acknowledgements: we would like to thank chris culnane and steve schneider, university of surrey, and wan fokkink, vu university amsterdam, for their pertinent comments. we also thank the insightful remarks of the anonymous reviewers. bibliography [adi08] b. adida. helios: web-based open-audit voting. in proceedings of the 17th usenix security symposium (security ’08). 2008. [af01] m. abadi, c. fournet. mobile values, new names, and secure communication. in hankin and schmidt (eds.), popl. pp. 104–115. acm, 2001. [bch+12] c. burton, c. culnane, j. heather, t. peacock, p. y. a. ryan, s. schneider, s. srinivasan, v. teague, r. wen, z. xia. a supervised verifiable voting protocol for the victorian electoral commission. in kripp et al. (eds.), electronic voting. lni 205, pp. 81–94. gi, 2012. [cha81] d. chaum. untraceable electronic mail, return addresses, and digital pseudonyms. commun. acm 24(2):84–88, 1981. [dk00] y. desmedt, k. kurosawa. how to break a practical mix and design a new one. in preneel (ed.), eurocrypt. lncs 1807, pp. 557–572. springer, 2000. [dkr09] s. delaune, s. kremer, m. ryan. verifying privacy-type properties of electronic voting protocols. journal of computer security 17(4):435–487, 2009. [dy83] d. dolev, a. c.-c. yao. on the security of public key protocols. ieee transactions on information theory 29(2):198–207, 1983. [gam85] t. e. gamal. a public key cryptosystem and a signature scheme based on discrete logarithms. ieee transactions on information theory 31(4):469–472, 1985. [gjjs04] p. golle, m. jakobsson, a. juels, p. f. syverson. universal re-encryption for mixnets. in okamoto (ed.), ct-rsa. lncs 2964, pp. 163–178. springer, 2004. proc. avocs 2013 14 / 15 eceasst [hl08] j. heather, d. lundin. the append-only web bulletin board. in degano et al. (eds.), formal aspects in security and trust. lncs 5491, pp. 242–256. springer, 2008. [jak98] m. jakobsson. a practical mix. in advances in cryptology – eurocrypt ’98. pp. 448–461. springer-verlag, london, uk, 1998. [krs10] s. kremer, m. ryan, b. smyth. election verifiability in electronic voting protocols. in gritzalis et al. (eds.), esorics. lncs 6345, pp. 389–404. springer, 2010. [low96] g. lowe. breaking and fixing the needham-schroeder public-key protocol using fdr. in margaria and steffen (eds.), tacas. lecture notes in computer science 1055, pp. 147–166. springer, 1996. [lr99] r. lazic, b. roscoe. data independence with generalised predicate symbols. in arabnia (ed.), pdpta. pp. 319–326. csrea press, 1999. [psl80] m. c. pease, r. e. shostak, l. lamport. reaching agreement in the presence of faults. j. acm 27(2):228–234, 1980. [rbh+09] p. y. a. ryan, d. bismark, j. heather, s. schneider, z. xia. prêt à voter: a voterverifiable voting system. ieee transactions on information forensics and security 4(4):662–673, 2009. [rg97] a. w. roscoe, m. goldsmith. the perfect spy for model-checking crypto-protocols. in proceedings of dimacs workshop on the design and formal verification of crypto-protocols. 1997. [ros98] a. w. roscoe. the theory and practice of concurrency. prentice hall, 1998. [rs01] p. y. a. ryan, s. a. schneider. modelling and analysis of security protocols. addison-wesley-longman, 2001. [sk95] k. sako, j. kilian. receipt-free mix-type voting scheme a practical solution to the implementation of a voting booth. in guillou and quisquater (eds.), eurocrypt. lncs 921, pp. 393–403. springer, 1995. [wg06] d. wikström, j. groth. an adaptively secure mix-net without erasures. in bugliesi et al. (eds.), icalp (2). lncs 4052, pp. 276–287. springer, 2006. [wik04] d. wikström. a universally composable mix-net. in naor (ed.), tcc. lncs 2951, pp. 317–335. springer, 2004. [wrf12] d. m. williams, j. de ruiter, w. fokkink. model checking under fairness in prob and its application to fair exchange protocols. in roychoudhury and d’souza (eds.), ictac. lecture notes in computer science 7521, pp. 168–182. springer, 2012. 15 / 15 volume 66 (2013) introduction previous work preliminaries our proposed mix net requirements protocol description modelling and formal analysis in csp honest mix servers dishonest mix servers requirements and assertions results of analysis conclusion and future directions integrating formal methods with informal digital hardware development electronic communications of the easst volume 35 (2010) proceedings of the 10th international workshop on automated verification of critical systems (avocs 2010) integrating formal methods with informal digital hardware development neil evans 16 pages guest editors: jens bendisposto, michael leuschel, markus roggenbach managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst integrating formal methods with informal digital hardware development neil evans neil.evans@awe.co.uk awe, aldermaston, united kingdom abstract: this paper presents some results from an industrial project to develop high-integrity digital hardware by integrating formal methods with a more traditional informal approach. the ultimate goal of the project team was to produce sythesisable vhdl that could be proven to meet given requirements for an embedded controller. the burden was on the formal methods experts to integrate themselves into the team. this paper describes the formal approach that was developed as a result. keywords: refinement, vhdl, csp, the b method, csp ‖ b 1 introduction and background integrating formal methods practitioners into teams comprising engineers from other disciplines is a challenge because formal methods tend to demand complete allegiance from their users, which is perhaps unrealistic in such a context. this paper presents firsthand experience of a multi-discipline project to build an embedded controller. digital hardware experts employed an informal approach to write vhdl and, consequently, the formal methods experts were tasked to verify the resulting code with respect to a set of informal requirements. because of the nature of the requirements, csp [hoa85] was chosen as the formal language. a translation from vhdl to csp is developed using the csp ‖ b approach [st05], which is a combination of csp and the b method [abr96]. in particular, traditional csp ‖ b ‘lifting’ techniques [st05] are employed to produce a csp representation of the vhdl code via b. the approach is repeatable, scalable and could be automated. automation minimises the risks involved in adopting such an approach by eliminating the need for a deep understanding of formal methods. 1.1 very high speed ic hardware description language (vhdl) vhdl [iee02] is a language for describing digital electronic circuits. the language is rich in structure and other syntactic sugar. elaboration removes the syntactic sugar to leave a set of concurrent processes connected via signals. each process typically includes signal assignment statements that change the value of signals, and is accompanied by a sensitivity list of signals which causes the process to react to changes to signals in the sensitivity list. the semantics of elaborated vhdl code is based on the execution of the code during simulation (as defined in [iee02]). each simulation cycle consists of two phases: a process execution 1 / 16 volume 35 (2010) mailto:neil.evans@awe.co.uk integrating formal methods with informal digital hardware development phase and a signal update phase. the notion of a delta-delay distinguishes simulation cycles that occur at the same global clock time. a simulation begins by initiating a process execution phase in which every process is active. a process execution phase ends when all active processes have suspended. signal updates (arising from signal assignments) take place during the subsequent signal update phase. whenever a signal is updated with a new value, an event is said to have occurred. a process reacts to such an event if the signal is present in its sensitivity list, and it resumes its execution during the next process execution phase. in this way signal updates drive the execution of processes, and the execution of processes drive the signal updates. note, it is possible for multiple processes to update the same signal during the same process execution phase. this situation is resolved in vhdl with so-called resolution functions. although this does not arise in the example presented below, it is not precluded by the approach taken in this paper. for illustrative purposes, we shall consider a road junction controlled by traffic lights. the vhdl controller can be in one of eight possible states: • both red, in which all traffic lights are red. • major ready, in which the major road traffic is forewarned that it can go. • major go allows traffic on the major road to proceed. • major end, in which the major road traffic is forewarned that it must stop. • swap, in which control transfers from the major road to the minor road. • minor ready, in which the minor road traffic is forewarned that it can go. • minor go allows traffic on the minor road to proceed. • minor end, in which the minor road traffic is forewarned that it must stop. the process fsm is responsible for assigning values to the light signals. it is defined as a case statement on the signal state. the (abbreviated) process is: process fsm(state, ready_delay, grn_delay, end_delay) begin case (state) is when both_red => red_maj <= ’1’; yel_maj <= ’0’; grn_maj <= ’0’; red_min <= ’1’; yel_min <= ’0’; grn_min <= ’0’; next_state <= major_ready; when major_ready => yel_maj <= ’1’; proc. avocs 2010 2 / 16 eceasst if (ready_delay = ’1’) then next_state <= major_go; end if; when major_go => ... when major_end => ... when swap => ... when minor_ready => ... when minor_go => ... when minor_end => ... end case; end process; the when clauses delimit the cases, and signals are assigned using the <= operator. in addition to the light signals, fsm updates the value of next state. this can depend on the value of one of the delay signals (described below) as well as state. consequently, the sensitivity list of the process includes the signal state and the delay signals. accompanying the process fsm is the process new state: process new_state(clock) begin if (clock’event and clock = ’1’) then if (reset = ’1’) then state <= both_red; else state <= next_state; end if; end if; end process; which is sensitive to changes to the signal clock. the process checks for a rising edge of clock (i.e., a change from 0 to 1) and, depending on the synchronous reset, sets state to both red or the value of next state. the ready delay signal determines how long the controller waits in a ready state, and end delay determines how long the controller waits in an end state. the following process increments the signal yel count if one of the yellow signals is 1. the ready delay and end delay signals are dependent on its value. process yellow_counter(clock) begin if (clock’event and clock = ’1’) then if (reset = ’1’) then yel_count <= "000"; else if (yel_maj = ’1’ or yel_min = ’1’) then 3 / 16 volume 35 (2010) integrating formal methods with informal digital hardware development yel_count <= unsigned(yel_count) + 1; else yel_count <= "000"; end if; end if; end if; end process; note that yel count is defined to be a 3-bit bit vector. the ready delay and end delay signals are assigned by the following (one line) processes: ready_delay <= yel_count(1); end_delay <= yel_count(2); the ready delay signal is assigned to be the middle bit of the bit vector, and end delay is assigned to be the leftmost bit. the final two processes are defined similarly, in which grn delay (and grn count) determine how long the controller remains in a green state. process green_counter(clock) begin if (clock’event and clock = ’1’) then if (reset = ’1’) then grn_count <= "0000000"; else if (grn_maj = ’1’ or grn_min = ’1’) then grn_count <= unsigned(grn_count) + 1; else grn_count <= "0000000"; end if; end if; end if; end process; grn_delay <= grn_count(6); 1.2 communicating sequential processes (csp) the language of csp has its own notion of process and event. a csp process is a formal object which interacts with its environment by performing atomic events. a notion of input and output can be introduced by allowing structured events: the process c!v → p outputs the value v on channel c and then behaves as p, and the process c?x → px is prepared to input any value x (of c’s type) and then behave as the process px. both input and output can occur within the same event (as in the event d?x!y). if p and q are processes then p 2 q is a process that behaves as p or q (the choice is made by the environment), and p|[ a ]|q is the parallel composition of p and q such that they synchronise proc. avocs 2010 4 / 16 eceasst on the events in set a. the hiding operator removes events from a process interface: p \ a is the process that behaves like p except the events in a are no longer visible. event renaming also changes the visible events of a process. relational renaming [sch99] uses a binary relation to transform events: if p can perform an event a and r is binary relation that contains the pair (a, b) then p[[r]] can perform b instead. many semantic models exist for csp, but we focus on those associated with csp’s model checker fdr [for]: the traces model, the failures model and the failures-divergences model (see [hoa85]). 1.3 the b method the b method is a formal approach to specifying, designing and implementing software. a specification consists of one or more modular units called machines. each machine comprises a set of local state variables, an invariant which defines the properties of the variables, and a set of operations which modify the variables. an initialisation clause gives the variables their initial values. various structuring mechanisms are available that allow machines to affect other machines within a specification. a sees clause gives read access to another machine, whilst includes also allows a machine to change the values of another machine’s variables, but only via the included machine’s operations. 1.4 csp ‖ b in csp ‖ b the events of a csp process trigger operation calls of a b machine. structured events are used to pass values between the controller process and the b machine. an event e!x?y corresponds to an operation call y ←− e(x) that inputs x and outputs a value y. a csp ‖ b specification can have multiple process/machine pairs [st02]. csp ‖ b primarily makes use of fdr for analysis. as we shall see in section 3.3, to do so it is often necessary to ‘lift’ state information from a b machine to a csp process. in order to mimic the behaviour of a b machine in csp, we parameterise a process p with state information i, to produce an augmented process pi. then the events of pi are decorated with assertions that relate i to their input values. for example, the assertion {x > i} in a decorated event e?x{x > i} of pi says the value input on e must be greater than i, otherwise the process diverges. the purpose of such assertions is to expose problems in the original csp ‖ b model by using fdr to find behaviours that violate them. 2 formalising requirements for small project teams, requirements engineers will typically have other roles in the implementation of the system and, hence, will have a preconceived bias towards a particular solution. this will probably result in an overly prescriptive set of requirements. csp is a good language for formalising such requirements because its operators give an explicit representation of control flow. as an example, we construct a csp specification of a traffic controller which simply describes our everyday experience of traffic lights (in the uk): 5 / 16 volume 35 (2010) integrating formal methods with informal digital hardware development spec rr = both red to maj red yel → spec mjry(max rdy) spec mjry(0) = maj red yel to grn → spec mjg(max grn) spec mjry(n) = tock → spec mjry(n−1) spec mjg(0) = maj grn to yel → spec mje(max end) spec mjg(n) = tock → spec mjg(n−1) spec mje(0) = maj yel to both red → spec swap spec mje(n) = tock → spec mje(n−1) spec swap = both red to min red yel → spec mnry(max rdy) spec mnry(0) = min red yel to grn → spec mng(max grn) spec mnry(n) = tock → spec mnry(n−1) spec mng(0) = min grn to yel → spec mne(max end) spec mng(n) = tock → spec mng(n−1) spec mne(0) = min yel to both red → spec rr spec mne(n) = tock → spec mne(n−1) the constants max rdy, max grn and max end represent the delays in the sequence of traffic light signals, and tock represents the passage of time [sch99]. 3 formalising vhdl for model checking by specifying desirable properties in a formal language and translating vhdl code to the same language, we are able to check its behaviour with respect to the properties. therefore, we would like to translate the vhdl code to csp so that it can be checked against the specification defined above. to achieve this, we begin by translating the vhdl code to csp ‖ b. then we can use traditional csp ‖ b ‘lifting’ techniques to incorporate the b components into csp. it should be noted that this intermediate representation is presented here only to justify the resulting csp process definitions. it is not integral to the approach, and would be unnecessary in an automation of the translation. 3.1 translating vhdl into csp ‖ b in addition to translating the user-defined vhdl processes, we need to model vhdl’s simulation semantics. there is a natural correspondence between vhdl and b. however, to model signals using b variables it is necessary to model each vhdl signal as two b variables: one representing the current signal value, and one representing the next signal value. the b operations that model signal assignments do so by assigning values to the next state variables, but only via expressions that use current state variables. hence the current state variables need to be proc. avocs 2010 6 / 16 eceasst b machine ‘next’ state b machine ‘next’ state b machine ‘next’ state b machine ‘next’ state b machine ‘current’ state b machine ‘current’ state b machine ‘current’ state b machine ‘current’ state process csp controller process csp controller process csp controller process csp controller b machine top−level figure 1: csp ‖ b architecture seen by the next state b machines. an example of this structuring is shown in the two rows of b machines at the bottom of figure 1. csp is used to model vhdl’s signal update phase. csp processes determine when all active b operations have completed (i.e., the b operations modelling the active vhdl processes in any given process execution phase). the csp processes then synchronise to initiate the update of the current state variables with the values held in the next state variables. this requires an additional top-level b machine with write access to the current state b machines, and read access to all of the next state b machines. this structure is shown in figure 1. the top-level b machine is connected to the ‘current’ state b machines with a solid line to indicate write access. it is connected to the ‘next’ state b machines with dashed arrows to indicate read access. the dotted lines from the csp controller processes to the ‘next’ state b machines indicate their control over the operations within those machines. the solid line from the csp processes to the top-level b machine indicates that the csp controllers synchronise to cause the update of the ‘current’ state b variables. 7 / 16 volume 35 (2010) integrating formal methods with informal digital hardware development 3.2 translating the traffic controller the mapping from user-defined vhdl processes to b operations is straightforward. the operation corresponding to the vhdl process fsm is as follows (only one case is shown to save space, but the others are very similar): fsm =̂ case s.state of either all red then red maj := 1 ‖ yel maj := 0 ‖ grn maj := 0 ‖ red min := 1 ‖ yel min := 0 ‖ grn min := 0 ‖ next state := major ready or major ready then ... note, we have prefixed the current state variable state with a unique identifier (s) to distinguish it from the other (next state) instance of the same variable. the translations of the other vhdl processes follow a similar pattern with one or two subtleties. consider the vhdl process yellow counter: yellow counter =̂ if ( clock event = true ∧ clock = 1 ) then if ( reset = 1 ) then yel count := 0 else if ( yel maj = 1 ∨ yel min = 1) then yel count := y.yel count + 1 else yel count := 0 end end end rather than using a bit vector, the variable yel count is declared to be a natural number in the range 0 to 7 in the b model. in order to prove that yellow counter maintains this typing invariant, it is necessary to add a precondition to say that the addition can happen only when y.yel count is less than 7. otherwise the operation could increment yel count outside its range.1 the precondition is generated automatically by taking the conjunction of the conditions that lead to the increment of yel count. yellow counter =̂ pre ( clock event = true ∧ clock = 1 ∧ reset = 0 ∧ ( yel maj = 1 ∨ yel min = 1 ) ) ⇒ y.yel count < 7 then ... 1 alternatively, we could use the mod operator to model ‘wrap around’ behaviour. proc. avocs 2010 8 / 16 eceasst it is necessary to add a precondition to the b translation of green counter for similar reasons but, in this case, grn count’s range is 0 to 127. the two one-line vhdl processes that update ready delay and end delay are translated to (equally succinct) b operations. however, we are obliged to give them names: set ready delay =̂ ready delay := bit ( y.yel count, 1 ); set end delay =̂ end delay := bit ( y.yel count, 2 ) the function bit(x, y), which returns the yth bit of value x, is not part of the b language. hence it is necessary to define it within the b model. in order to update the current state variables with their next state values, it is necessary to define operations within the current state b machines. these have a uniform structure in which the next state values are passed as input parameters, and the body of the operations are simple assignments of these values to the current state variables. also, a list of boolean values are output from the operation to indicate when the values of current state variables have changed. this information can be used to model the sensitivity lists so that the appropriate b operations are called in the next process execution phase. consider the operation update fsm: dymj, dgmj, dymn, dgmn ←− update fsm ( rj, yj, gj, rn, yn, gn, ns ) =̂ pre rj ∈ std logic ∧ yj ∈ std logic ∧ gj ∈ std logic ∧ rn ∈ std logic ∧ yn ∈ std logic ∧ gn ∈ std logic ∧ ns ∈ state then red maj := rj ‖ yel maj := yj ‖ grn maj := gj ‖ red min := rn ‖ yel min := yn ‖ grn min := gn ‖ next state := ns ‖ dymj := bool ( yel maj 6= yj ) ‖ dgmj := bool ( grn maj 6= gj ) ‖ dymn := bool ( yel min 6= yn ) ‖ dgmn := bool ( grn min 6= gn ) end where std logic is a b representation of vhdl’s std logic type and state is the b representation of the controller state. note, there are no outputs concerning changes to the red signals because nothing is sensitive to such changes. the top-level b machine contains a single b operation called dd which calls all the current state update operations with the necessary input parameters. it also accumulates all of the boolean outputs from these individual operations, and uses them as its own output. this single operation is capable of updating all current state variables simultaneously and provides the necessary information to say which variables have changed. the (abbreviated) definition of the top level b machine is shown below. note, the operation dd calls update fsm with the actual values of the next state variables in next fsm. (the other operation calls, input parameters, and output parameters are not shown.) machine top level sees n.next fsm, . . . includes curr fsm, . . . operations 9 / 16 volume 35 (2010) integrating formal methods with informal digital hardware development dymj, dgmj, dymn, dgmn, . . . ←− dd =̂ begin dymj, dgmj, dymn, dgmn ←− update fsm (n.red maj, . . . ) ‖ . . . from figure 1, we see that it is necessary to define csp processes that control the calling of the various b operations. the idea is to mimic the simulation cycle within the csp processes. hence, each controller process begins by calling its associated next state b operation. on completion, the process is ready to call the top-level b operation dd to update the current state b variables. however, it must wait until all processes are prepared to call dd. when dd occurs, each process can view the outputs from the dd operation to determine which variables’ values have changed and, hence, whether it needs to call its associated next state b operation. if it does not then it waits for the next dd operation call. consider the csp process fsm (other controller processes are similar): fsm = fsm → fsm′ fsm′ = dd?bb1?...?bbn → if (bbi1 or bbi2 or ··· or bbim) then fsm else fsm′ 3.3 ‘lifting’ the b components into csp in order to use fdr, lifting is the way important state information is taken from b into csp. this entails, among other things, parameterising the csp processes. the effects of the b operations are then modelled as updates to the parameters. the lifted b operation fsm comprises a choice of guarded processes to represent the case statement(one process for each case): fsm(st, rdly, gdly, edly, rmj, ymj, gmj, rmn, ymn, gmn, nst) = (st = all red) & let rmj′ = 1 ymj′ = 0 gmj′ = 0 rmn′ = 1 ymn′ = 0 gmn′ = 0 nst′ = major ready within fsm′(st, rdly, gdly, edly, rmj′, ymj′, gmj′, rmn′, ymn′, gmn′, nst′) 2 (st = major ready) & let ymj′ = 1 nst′ = if (rdly = 1) then major go else nst within fsm′(st, rdly, gdly, edly, rmj, ymj′, gmj, rmn, ymn, gmn, nst′) 2 . . . note that the call to fsm′ in this definition is parameterised with signal values. this is necessary to keep track of the values as they are distributed among the processes. in order to model the sensitivity list, a conditional statement is introduced into fsm′ to check if the new values arriving proc. avocs 2010 10 / 16 eceasst on dd differ from the values held by the process. if so then fsm is called, otherwise control is passed back to fsm′. note, in the definition of fsm′ below we show the relevant arguments of dd only. in this case, the values of state, ready delay, grn delay and end delay are relevant because they appear in fsm’s sensitivity list. fsm′(st, rmj, ymj, gmj, rmn, ymn, gmn, nst, rdly, gdly, edly) = dd . . .?st′ . . .?rdly′?gdly′?edly′ → if (st′ 6= st or rdly′ 6= rdly or gdly′ 6= gdly or edly′ 6= edly) then fsm(st′, rdly′, gdly′, edly′, rmj, ymj, gmj, rmn, ymn, gmn, nst) else fsm′(st, rdly, gdly, edly, rmj, ymj, gmj, rmn, ymn, gmn, nst) the vhdl process yellow counter is sensitive to changes in the clock signal. like most processes that are sensitive to the clock signal, the conditional statement within the process checks for a clock edge (in this case a rising edge). consequently, such conditional statements will never evaluate to true unless they have been preceded by a signal update phase that changed the clock signal. in our formal model, the signal update phase is modelled by the csp event dd. hence, for yellow counter (and the formalisation of other clock-sensitive processes) we begin with the dd event. the definitions of yellow counter and green counter in the b model included preconditions that, when evaluated to false, result in unpredictable (divergent) behaviour. it is necessary, therefore, to include these preconditions as diverging assertions in csp in order to ‘lift’ the b operations completely. yellow counter(yel count) = dd . . .?yel maj?yel min? . . .   clock event = true∧clock = 1 ∧ reset = 0∧(yel maj = 1∨yel min = 1) ⇒ yel count < 7  → if (clock event) then yellow counter′(clock, reset, yel maj, yel min, yel count) else yellow counter(yel count) yellow counter′(clock, reset, yel maj, yel min, yel count) = let yel count′ = if (clock = 1) then if (reset = 1) then 0 else if (yel maj = 1∨yel min = 1) then yel count + 1 else 0 else yel count within yellow counter(yel count′) the lifting technique is applied to the other b operations in a similar way. this completes the lifting procedure. unfortunately this is not in a form that can be accepted by fdr. in particular, each process contributes relatively few arguments to the event dd, and the eager manner in which fdr builds the transition graph means that the fdr compiler is overwhelmed by enumerating all possible instances of dd prior to parallel composition. this effort is 11 / 16 volume 35 (2010) integrating formal methods with informal digital hardware development largely unnecessary because the parallel composition is such that very few of the instances will be exercised during the analysis. hence, optimisation steps are needed. 3.4 optimising the csp for model checking we begin by merging each unprimed/primed process pair into single process definitions. this results in processes with a uniform structure that will make optimisation easier. consider the lifted csp process new state: new state(state) = dd . . .?clock event?clock?reset!state?next state . . . → if (clock event) then new state′(clock, reset, state, next state) else new state(state) we can remove the conditional statement by pattern matching on clock event: new state(state) = dd . . .!true?clock?reset!state?next state . . . → new state′(clock, . . .) 2 dd . . .!false?clock?reset!state?next state . . . → new state(state) we then incorporate the process new state′ by updating the parameter state in an appropriate way. this results in an external choice of dd events: new state(state) = dd . . .!true!1!1!state?next state . . . → new state(both red) 2 dd . . .!true!1!0!state?next state . . . → new state(next state) 2 dd . . .!true!0? !state?next state . . . → new state(state) 2 dd . . .!false? ? !state?next state . . . → new state(state) the first dd event handles the case when the clock is 1 and the reset is 1, and results in the both red state. the second dd event handles the case when the clock is 1 and the reset is 0. this replaces the current state with the value bound to the next state argument of dd. the remaining cases keep the current state value. if we transform yellow counter and green counter in a similar manner, we have to somehow incorporate the diverging assertions into the modified process definition. this is done by pattern matching on the processes’ parameters. first recall the lifted definition of yellow counter: yellow counter(yel count) = dd . . .?yel maj?yel min . . .   clock event = true∧clock = 1 ∧ reset = 0∧(yel maj = 1∨yel min = 1) ⇒ yel count < 7  → ... when the parameter yel count is not 7 the diverging assertion is true, and can be ignored. however, when it is 7 then the antecedent of the implication in the diverging assertion must be shown to be false (i.e., we negate the antecedent and use it as a new diverging assertion): proc. avocs 2010 12 / 16 eceasst yellow counter(7) = dd . . .?yel maj?yel min . . . { clock event = false∨clock = 0 ∨ reset = 1∨(yel maj = 0∧yel min = 0) } → ... once again, we incorporate yellow counter′ to produce a process comprising an external choice of unique dd events, but for each case we check whether the diverging assertion is true or false and define the process’s subsequent behaviour accordingly: yellow counter(7) = dd . . .!true!1!1 . . .? ? . . . → yellow counter(0) 2 dd . . .!true!1!0 . . .!0!0 . . . → yellow counter(0) 2 dd . . .!true!1!0 . . .!1!0 . . . → div 2 dd . . .!true!1!0 . . .!0!1 . . . → div 2 dd . . .!true!1!0 . . .!1!1 . . . → div 2 dd . . .!true!0? . . .? ? . . . → yellow counter(7) 2 dd . . .!false? ? . . .? ? . . . → yellow counter(7) the process div diverges immediately. each branch that ends with this process begins with an instance of dd whose arguments falsify the diverging assertion. there are three cases that cause divergent behaviour, that would otherwise increment yel count out of bounds. the instance of yellow counter when yel count is not 7 is identical except the calls to div are replaced by calls to yellow counter(yel count + 1) (i.e., there is no divergent behaviour). there are corresponding definitions for green counter. the (abbreviated) definition of fsm shown below is the result of incorporating fsm′ into the ‘lifted’ definition of fsm. by pattern matching on the current state argument of dd we once again get a process that is an external choice of unique instances of dd, each of which is followed by a conditional statement to determine the next course of action. note that each branch has the same structure as the body of fsm′. fsm(st, rmj, ymj, gmj, rmn, ymn, gmn, ns, rdly, gdly, edly) = dd . . .!both red!rmj!ymj!gmj!rmn!ymn!gmn!ns?rdly′?gdly′?edly′ → (if (st 6= both red∨rdly 6= rdly′∨gdly 6= gdly′∨edly 6= edly′) then fsm(both red, 1, 0, 0, 1, 0, 0, major ready, rdly′, gdly′, edly′) else fsm(st, rmj, ymj, gmj, rmn, ymn, gmn, ns, rdly, gdly, edly)) 2 dd . . .!major ready!rmj!ymj!gmj!rmn!ymn!gmn!ns!0?gdly′?edly′ → (if (st 6= major ready∨rdly 6= 0∨gdly 6= gdly′∨edly 6= edly′) then fsm(major ready, rmj, 1, gmj, rmn, ymn, gmn, ns, 0, gdly′, edly′) else fsm(st, rmj, ymj, gmj, rmn, ymn, gmn, ns, rdly, gdly, edly)) 2 . . . the delay processes (not shown) are transformed in a similar manner. now we are in a position to optimise the parallel composition of the above processes. the solution adopted in this paper is to merge process definitions to reduce the number of processes synchronising on dd and increase the number of arguments that individual processes contribute. 13 / 16 volume 35 (2010) integrating formal methods with informal digital hardware development we illustrate this by merging the new state process with the counter processes and delay processes because, individually, these process contribute one argument each to dd; collectively, they contribute six arguments. when merging processes, the divergent process div takes precedence: if any single process diverges in a given state then the entire process diverges. merging preserves the structure of the processes derived in the previous step (i.e., an external choice of dd events), so merging can be repeated as often as necessary. in this instance, we shall call the resulting process ns yc gc dly . in its most general form, the merged process is: ns yc gc dly(0, st, yc, gc, rdly, gdly, edly) = dd!true!1!1!st? ? ? ? ? ? ? !rdly!gdly!edly → ns yc gc dly(1, both red, 0, 0, bit(yc, 1), bit(gc, 6), bit(yc, 2)) 2 dd!true!1!0!st? !1!1? ? ? ?ns!rdly!gdly!edly → ns yc gc dly(1, ns, yc + 1, gc + 1, bit(yc, 1), bit(gc, 6), bit(yc, 2)) 2 dd!true!1!0!st? !0!1? !0? ?ns!rdly!gdly!edly → ns yc gc dly(1, ns, 0, gc + 1, bit(yc, 1), bit(gc, 6), bit(yc, 2)) 2 dd!true!1!0!st? !1!0? ? !0?ns!rdly!gdly!edly → ns yc gc dly(1, ns, yc + 1, 0, bit(yc, 1), bit(gc, 6), bit(yc, 2)) 2 . . . note that, due to the merging of the counter processes and the delay processes, the count parameters (yc and gc) are no longer needed outside this process. hence, they are removed from the arguments of dd. there are three other (pattern matching) instances of this process that exhibit some divergent behaviour. 4 model checking our controller can now defined as: controller = fsm(both red, 1, 0, 0, 1, 0, 0, major ready, 0, 0, 0) |[{| dd |}]|ns yc gc dly(0, both red, 0, 0, 0, 0, 0) the values of the parameters are the same values that would have been assigned by the next state b operations. hence, the initial state of controller corresponds to the vhdl prior to its first signal update phase. we rename controller so that we can use fdr to check that it refines spec rr. for example, dd!true!1!0!both red!1!0!0!1!0!0!major ready? is renamed as both red to maj red yel. if ren is the entire renaming then by hiding the remaining dd events we can perform a refinement check in fdr: assert spec rr vt controller[[ren]] \{| dd |} which succeeds. it also succeeds if we perform the same check in the failures model. this shows that the controller is as ’live’ as the specification that it implements. another important check is to determine whether it is possible for the controller to cause a divergence by reaching a div state. this can be achieved by performing a livelock-free check on controller. note proc. avocs 2010 14 / 16 eceasst that we are not hiding any events, so if the check fails then it is by virtue of a div process. the livelock-free check succeeds, and we conclude that the controller does not attempt to increment one of its counters out of bounds. 5 conclusion the challenge that prompted this work was to combine formal and informal approaches to produce verified hardware. the proposed solution allows the hardware developers to continue to use their informal approaches, but complements this with a method for translating vhdl to formal notations for analysis. of all the related work, perhaps the most relevant is [zt05] (in combination with [bgr00]) which translates b specifications and existing vhdl to acl2 for analysis. however, in our case, the project requirements influenced the choice of formal approach considerably. csp was used because it is a good language to formalise requirements of this form. the b method was less suitable in this respect because, at its most abstract level, control flow is implicit. the language of the b method is, however, very similar to vhdl, and translating from vhdl to b is quite straightforward. csp can also be used to provide the necessary control, which motivates a csp ‖ b approach. the prob [lb03] tool is available to do trace refinement checks, but other kinds of checks (such as those described in section 4) are not available. the approach presented here uses the existing csp ‖ b techniques to ‘lift’ the b components into csp in order to use fdr. another piece of work using csp in a vhdl context is [ch97], but this focuses on synthesis. the problem with using fdr lies in its eager approach to building transition graphs. an optimisation technique has been proposed in this paper to circumvent this problem. in this respect, prob would be better because it uses a lazy approach. scalability is always a key issue with formal methods. the optimisation can be repeated as necessary, so it works for larger specifications with more processes. automation of the approach is ongoing work. a lot of work has been done on the formal semantics of vhdl (including [fm95]). this work provides useful insights into vhdl itself, but cannot be deployed in an industrial context directly. acknowledgements: the author is very grateful to the anonymous referees and workshop participants for their useful comments. bibliography [abr96] j. r. abrial. the b book: assigning programs to meaning. cup, 1996. [bgr00] d. borrione, p. georgelin, v. rodrigues. using macros to mimic vhdl. in kaufmann et al. (eds.), computer-aided reasoning acl2 case studies. kluwer academic publishers, 2000. 15 / 16 volume 35 (2010) integrating formal methods with informal digital hardware development [ch97] r. chapman, d. h. hwang. a formally verified high-level synthesis front-end: translation of vhdl to dependence flow graphs. in eurodac ’97. acm, 1997. [fm95] m. fuchs, m. mendler. a functional semantics for delta-delay vhdl based on focus. in kloos and breuer (eds.), formal semantics for vhdl. kluwer academic publishers, 1995. [for] formal systems (europe) ltd. failures-divergences refinement: fdr2 manual. [hoa85] c. a. r. hoare. communicating sequential processes. prentice hall, 1985. [iee02] ieee comp. society. ieee standards: vhdl language reference manual. 2002. [lb03] m. leuschel, m. butler. prob: a model checker for b. in araki et al. (eds.), fm’2003: formal methods. lncs 2805. springer, 2003. [sch99] s. schneider. concurrent and real-time systems: the csp approach. wiley, 1999. [st02] s. schneider, h. treharne. communicating b machines. in zb2002. lncs 2272. springer, 2002. [st05] s. schneider, h. treharne. csp theorems for communicating b machines. formal aspects of computing 17:390–422, 2005. [zt05] y. zimmermann, d. toma. component reuse in b using acl2. in zb2005. lncs 3455. springer, 2005. proc. avocs 2010 16 / 16 introduction and background very high speed ic hardware description language (vhdl) communicating sequential processes (csp) the b method csp "026b30d b formalising requirements formalising vhdl for model checking translating vhdl into csp "026b30d b translating the traffic controller `lifting' the b components into csp optimising the csp for model checking model checking conclusion simplifying proofs of linearisability using layers of abstraction electronic communications of the easst volume 66 (2013) proceedings of the automated verification of critical systems (avocs 2013) simplifying proofs of linearisability using layers of abstraction brijesh dongol and john derrick 15 pages guest editors: steve schneider, helen treharne managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ simplifying proofs of linearisability using layers of abstraction brijesh dongol and john derrick department of computer science the university of sheffield, s1 4dp, uk b.dongol@sheffield.ac.uk, j.derrick@dcs.shef.ac.uk abstract: linearisability has become the standard correctness criterion for concurrent data structures, ensuring that every history of invocations and responses of concurrent operations has a matching sequential history. existing proofs of linearisability require one to identify so-called linearisation points within the operations under consideration, which are atomic statements whose execution causes the effect of an operation to be felt. however, identification of linearisation points is a nontrivial task, requiring a high degree of expertise. for sophisticated algorithms such as heller et al’s lazy set, it even is possible for an operation to be linearised by the concurrent execution of a statement outside the operation being verified. this paper proposes a method for verifying linearisability that does not require identification of linearisation points. instead, using an interval-based logic, we show that every behaviour of each concrete operation over any interval is a possible behaviour of a corresponding abstraction that executes with coarse-grained atomicity. this approach is applied to heller et al’s lazy set to show that verification of linearisability is possible without having to consider linearisation points within the program code. keywords: linearisability, interval-based verification, fine-grained atomicity 1 introduction development of correct fine-grained concurrent data structures has received an increasing amount of attention over the past few years as the popularity of multi/many-core architectures has increased. an important correctness criterion for such data structures is linearisability [hw90], which guarantees that every history of invocations and responses of the concurrent operations on the data structure can be rearranged without violating the ordering within a process such that the rearranged history is a valid sequential history. a number of proof techniques developed over the years match concurrent and sequential histories by identifying an atomic linearising statement within the concrete code of each operation, whose execution corresponds to the effect of the operation taking place. however, due to the subtlety and complexity of concurrent data structures, identification of linearising statements within the concrete code is a non-trivial task, and it is even possible for an operation to be linearised by the execution of other concurrent operations. an example of such behaviour occurs in heller et al’s lazy set algorithm, which implements a set as a sorted linked list [hhl+07] (see fig. 1). in particular, its contains operation may be linearised by the execution of a concurrent add or remove operation and the precise location of the linearisation point is dependent on how much of the list has been traversed by the contains operation. in this paper, we present a method for simplifying proofs of linearisability using heller 1 et al’s lazy set as an example. an early attempt at verifying linearisability of heller et al’s lazy set is that of vafeiadis et al, who extend each linearising statement with code corresponding to the execution of the abstract operation so that execution of a linearising statement causes the corresponding abstract operation to be executed [vhhs06]. however, this technique is incomplete and cannot be used to verify the contains operation, and hence, its correctness is only treated informally [vhhs06]. these difficulties reappear in more recent techniques: “in [heller et al’s lazy set] algorithm, the correct abstraction map lies outside of the abstract domain of our implementation and, hence, was not found.” [vaf10]. the first complete linearisability proof of the lazy set was given by colvin et al [cglm06], who map the concrete program to an abstract set representation using simulation to prove data refinement. to verify the contains operation, a combination of forwards and backwards simulation is used, which involves the development of an intermediate program ip such that there is a backwards simulation from the abstract representation to ip, and a forwards simulation from ip to the concrete program. more recently, o’hearn et al use a so-called hindsight lemma (related to backwards simulation) to verify a variant of heller’s lazy set algorithm [orv+10]. derrick et al use a method based on non-atomic refinement, which allows a single atomic step of the concrete program to be mapped to several steps of the abstract [dsw11]. application of the proof methods in [vhhs06, cglm06, orv+10, dsw11] remains difficult because one must acquire a high degree of expertise of the program being verified to correctly identify its linearising statements. for complicated proofs, it is difficult to determine whether the implementation is erroneous or the linearising statements have been incorrectly chosen. hence, we propose an approach that eliminates the need for identification of linearising statements in the concrete code by establishing a refinement between the fine-grained implementation and an abstraction that executes with coarse-grained atomicity [dd12]. the idea of mapping fine-grained programs to a coarse-grained abstraction has been proposed by groves [gro08] and separately elmas et al [eqs+10], where the refinements are justified using reduction [lip75]. however, unlike our approach, their methods must consider each pair of interleavings, and hence, are not compositional. turon and wand present a method of abstraction in a compositional rely/guarantee framework with separation logic [tw11], but only verify a stack algorithm that does not require backwards reasoning. capturing the behaviour of a program over its interval of execution is crucial to proving linearisability of concurrent data structures. in fact, as colvin et al point out: “the key to proving that [heller et al’s] lazy set is linearisable is to show that, for any failed contains(x) operation, x is absent from the set at some point during its execution.” [cglm06]. hence, it seems counterintuitive to use logics that are only able to refer to the pre and post states of each statement (as done in [vhhs06, cglm06, dsw11, vaf10]). instead, we use a framework based on [ddh12] that allows reasoning about the fine-grained atomicity of pointer-based programs over their intervals of execution. by considering complete intervals, i.e., those that cover both the invocation and response of an operation, one is able to determine the future behaviour of a program, and hence, backwards reasoning can often be avoided. for example, bäumler et al [bstr11] use an interval-based approach to verify a lock-free queue without resorting to backwards reasoning, as is required by frameworks that only consider the pre/post states of a statement [dglm04]. however, unlike our approach, bäumler et al must identify the linearising statements in the concrete program, which is a non-trivial step. 2 add(x): a1: (n1, n3) := locate(x); a2: if n3.val != x a3: n2:= new node(x); a4: n2.nxt := n3; a5: n1.nxt := n2; a6: res := true a7: else res := false endif; a8: n1.unlock(); a9: n3.unlock(); a10: return res remove(x): r1: (n1, n2) := locate(x); r2: if n2.val = x r3: n2.mrk := true; r4: n3 := n2.nxt; r5: n1.nxt := n3; r6: res := true r7: else res := false endif; r8: n1.unlock(); r9: n2.unlock(); r10: return res contains(x): c1: n1 := head; c2: while (n1.val < x) c3: n1 := n1.nxt enddo; c4: res := (n1.val = x) and !n1.mrk c5: return res locate(x): while (true) do l1: pred := head; l2: curr := pred.nxt; l3: while (curr.val < x) do l4: pred := curr; l5: curr := pred.nxt enddo; l6: pred.lock(); l7: curr.lock(); l8: if !pred.mrk and !curr.mrk and pred.nxt = curr l9: return (pred, curr) l10: else pred.unlock(); l11: curr.unlock() endif enddo figure 1: a lazy set algorithm [hhl+07] an important difference between our framework and those mentioned above is that we assume a truly concurrent execution model and only require interleaving for conflicting memory accesses [dd12, ddh12]. each of the other frameworks mentioned above assume a strict interleaving between program statements. thus, our approach captures the behaviour of program in a multicore/multiprocesor architecture more faithfully. the main contribution of this paper is the use of the techniques in [dd12] to simplify verification of a complex set algorithm [hhl+07]. this algorithm presents a challenge for linearisability because the linearisation point of the contains operation is potentially outside the operation itself [dsw11]. we propose a method in which the proof is split into several layers of abstraction so that linearisation points of the fine-grained implementation need not be identified. as summarised in fig. 3, one must additionally prove that the coarse-grained abstraction is linearisable, however, due to the coarse granularity of atomicity, the linearising statements are straightforward to identify and the linearisability proof itself is simpler [dd12]. other contributions of this paper include a method for reasoning about truly concurrent program executions and an extension of the framework in [ddh12] to enable reasoning about pointer-based programs, which includes methods for reasoning about expressions non-deterministically [hbdj13]. 2 a list-based concurrent set heller et al [hhl+07] implement a set as a concurrent algorithm operating on a shared data structure (see fig. 1) with operations add and remove to insert and delete elements from the set, and an operation contains to check whether an element is in the set. the concurrent 3 ∆u add(x) ∆ ′ q add(y)remove(x) ∆q lazyset ∆ s ∆p contains(x) v c1 (c2 ; c3)ω c4 return true return true〈x ∈ absset〉 figure 2: contains(x) execution over ∆p returning true abstract sequential program behaviour refinement fine-grained implementation coarse-grained abstraction linearisability proof figure 3: proof steps implementation uses a shared linked list of node objects with fields val,nxt,mrk, and lck, where val stores the value of the node, nxt is a pointer to the next node in the list, mrk denotes the marked bit and lck stores the identifier of the process that currently holds the lock to the node (if any) [hhl+07]. the list is sorted in strictly ascending values order (including marked nodes). operation locate(x) is used to obtain pointers to two nodes whose values may be used to determine whether or not x is in the list — the value of the predecessor node pred must always be less than x, and the value of the current node curr may either be greater than x (if x is not in the list) or equal to x (if x is in the list). operation add(x) calls locate(x), then if x is not already in the list (i.e., value of the current node n3 is strictly greater than x), a new node n2 with value field x is inserted into the list between n1 and n3 and true is returned. if x is already in the list, the add(x) operation does nothing and returns false. operation remove(x) also starts by calling locate(x), then if x is in the list the current node n2 is removed and true is returned to indicate that x was found and removed. if x is not in the list, the remove operation does nothing and returns false. note that operation remove(x) distinguishes between a logical removal, which sets the marked field of n2 (the node corresponding to x), and a physical removal, which updates the nxt field of n1 so that n2 is no longer reachable. operation contains(x) iterates through the list and if a node with value greater or equal to x is found, it returns true if the node is unmarked and its value is equal to x, otherwise returns false. the complete specification consists of a number of processes, each of which may execute its operation on the shared data structure. for the concrete implementation, therefore, the set operations can be executed concurrently by a number of processes, and hence, the intervals in which the different operations execute may overlap. our basic semantic model uses interval predicates (see section 3), which allows formalisation of a program’s behaviour with respect to an interval (which is a contiguous set of times), and an infinite stream (that maps each time to a state). for example, consider fig. 2, which depicts an execution of the lazy set over interval ∆ in stream s, a process p that executes a contains(x) that returns true over ∆p, a process q that executes remove(x) and add(y) over intervals ∆q and ∆′q, respectively, and a process u that executes add(x) over interval ∆u. hence, the shared data structure may be changing over ∆p while process p is checking to see whether x is in the set. correctness of such concurrent executions is judged with respect to linearisability, the crux of which requires the existence of an atomic linearisation point within each interval of an operation’s execution, corresponding to the point at which the effect of the operation takes place 4 [hw90]. the ordering of linearisation points defines a sequential ordering of the concurrent operations and linearisability requires that this sequential ordering is valid with respect to the data structure being implemented. for the execution in fig. 2, assuming that the set is initially empty, because contains(x) returns true, a valid linearisation corresponds to a sequential execution seq1 “=add(x); contains(x); remove(x); add(y) obtained by picking linearisation points within ∆u, ∆p, ∆q and ∆′q in order. note that a single concurrent history may be linearised by more than one valid sequential history, e.g., the execution in fig. 2 can correspond to the sequential execution seq2 “=remove(x); add(x); contains(x); add(y). the abstract sets after completion of seq1 and seq2 are {y} and {x,y}, respectively. unlike seq1, operation remove(x) in seq2 returns false. note that a linearisation of ∆′q cannot occur before ∆q because remove(x) responds before the invocation of add(y). herlihy and wing formalise linearisability in terms of histories of invocation and response events of the operations on the data structure in question [hw90]. reasoning about such histories directly is infeasible, and hence, existing methods (e.g., [cglm06, dsw11, vhhs06]) prove linearisability by identifying an atomic linearising statement within the operation being verified and showing that this statement can be mapped to the execution of a corresponding abstract operation. however, due to the fine granularity of the atomicity and inherent non-determinism of concurrent algorithms, identification of such a statement is difficult. the linearising statement for some operations may actually be outside the operation, e.g., none of the statements c1-c5 are valid linearising statements of contains(x); instead contains(x) is linearised by the execution of a statement within add(x) or remove(x) [dsw11]. as summarised in fig. 3, we decompose proofs of linearisability into two steps, the first of which proves that a fine-grained implementation refines a program that executes the same operations but with coarse-grained atomicity. the second step of the proof is to show that the abstraction is linearisable. the atomicity of a coarse-grained abstraction cannot be guaranteed in hardware (without the use of contention inducing locks), however, its linearisability proof is much simpler [ddh12]. because we prove behaviour refinement, any behaviour of the finegrained implementation is a possible behaviour of the coarse-grained abstraction, and hence, an implementation is linearisable whenever the abstraction is linearisable. our technique does not require identification of the linearising statements in the implementation. a possible coarse-grained abstraction of contains(x) is an operation that is able to test whether x is in the set in a single atomic step (see fig. 6), unlike the implementation in fig. 1, which uses a sequence of atomic steps to iterate through the list to search for a node with value x. therefore, as depicted in fig. 2, an execution of contains that returns true, i.e., c1; (c2; c3)ω ; c4 ; return true, is required to refine a coarse-grained abstraction 〈x ∈ absset〉 ; return true, where c1 c4 are the labels of contains in fig. 1 and 〈x ∈ absset〉 is a guard that is atomically able to test whether x is in the abstract set. in particular, 〈x ∈ absset〉 holds in an interval ω and stream s iff there is a time t in ω such that x ∈ absset.(s.t). streams are formalised in section 3. note that both 〈x ∈ absset〉 and 〈x 6∈ absset〉 may hold within ∆p; the refinement in fig. 2 would only be invalid if for all t ∈ ∆p, x 6∈ absset.(s.t) holds. proving refinement between a coarse-grained abstraction and an implementation is non-trivial due to the execution of other (interfering) concurrent processes. furthermore, our execution model allows non-conflicting statements (e.g., concurrent writes to different locations) to be executed in a truly concurrent manner. we use compositional rely/guarantee-style reasoning 5 cloop(p,x) =̂ ([(n1p 7→ val) < x] ; n1p := (n1p 7→ nxt))ω ; [(n1p 7→ val)≥ x] contains(p,x) =̂ cl1: n1p := head ; cl2: cloop(p,x) ; cl3: resp := (¬(n1p 7→ mrk)∧ (n1p 7→ val) = x) htinit =̂ (head 7−→ (−∞,tail,false,null))∧ (tail 7−→ (∞,null,false,null)) s(p) =̂ jn1p,n2p,n3p,resp ( d x:z add(p,x)uremove(p,x)ucontains(p,x)) ωk set(p) =̂ jhead,tail rely ←−−−− htinit • ‖p:p s(p)k figure 4: formal model of the lazy set operations [jon83] to formalise the behaviour of the environment of a process and allow the execution of an arbitrary number of processes in the environment. note that unlike jones [jon83], who assumes rely conditions are two-state relations, rely conditions in our framework are interval predicates that are able to refer to an arbitrary number of states because the size of the interval is not fixed. 3 interval-based framework to simplify reasoning about the linked list structure of the lazy list, the domain of each state distinguishes between variables and addresses. we use a language with an abstract syntax that closely resembles program code, and use interval predicates to formalise interval-based behaviour. fractional permissions are used to control conflicting accesses to shared locations. commands. we assume variable names are taken from the set var, values have type val, addresses have type addr “= n, var∩addr = ∅ and addr ⊆ val. a state over va ⊆ var∪addr has type stateva “= va → val and a state predicate has type stateva →b. the objects of a data structure may contain fields, which we assume are of type field. we assume that every object with m fields is assigned m contiguous blocks of memory and use offset: field →n to obtain the offset of f ∈ field within this block [vaf07], e.g., for the fields of a node object, we assume that offset.val = 0, offset.nxt = 1, offset.mrk = 2 and offset.lck = 3. we assume the existence of a function eval that evaluates a given expression in a given state. the full details of expression evaluation are elided. to simplify modelling of pointer-based programs, for an address-valued expression ae, we introduce expressions ∗ae, which returns the value at address ae, ae·f , which returns the address of f with respect to ae. for a state σ , we define eval.(∗ae).σ “= σ.(eval.ae.σ) and (ae·f ).σ “= eval.ae.σ + offset.f . we also define shorthand ae 7→ f “=∗(ae·f ), which returns the value at ae·f in state σ . assuming that proc denotes the set of process ids, for a set of variables z, state predicate c, variable or address-valued expression vae, expression e, label l, and set of processes p ⊆ proc, the abstract syntax of a command is given by cmd below, where c,c1,c2,cp ∈ cmd. cmd ::= idle | [c] | 〈c〉 | vae := e | c1 ; c2 | c1 uc2 | cω | ‖p:p cp | jz ck | l: c hence a command is either idle, a guard [c], an atomically evaluated guard 〈c〉, an assignment vae := e, a sequential composition c1 ; c2, a non-deterministic choice c1uc2, a possibly infinite iteration cω , a parallel composition ‖p:p cp, a command c within a context z (denotedjz ck), or a labelled command l: c. in jz ck, the context z is the set of variables that c may modify. 6 a formalisation of part of the lazy set [hhl+07] using the syntax above is given in fig. 4, where p ⊆ proc. operations add(x), remove(x) and contains(x) executed by process p are modelled by commands add(p,x), remove(p,x) and contains(p,x), respectively. we assume that n 7−→ (vv,nn,mm,ll) denotes (n 7→ val = vv)∧ (n 7→ nxt = nn)∧ (n 7→ mrk = mm)∧ (n 7→ lck = ll). details of add(p,x) and remove(p,x) are elided and the rely construct is formalised in section 5. note that unlike the methods in [cglm06, dsw11], where labels identify the atomicity, we use labels to simplify formalisation of the rely conditions of each process, and may correspond to a number of atomic steps. furthermore, guard evaluation is formalised with respect to the set of states apparent to a process (see section 4), and hence, unlike [vhhs06, cglm06, dsw11], we need not split complex expressions into their atomic components. for example, in [vhhs06, cglm06, dsw11], the expression at c4 (fig. 1) must be split into two expressions curr.val = x and !curr.mrk to explicitly model the fact that interference may occur between accesses to curr.val and curr.mrk. interval predicates. a (discrete) interval (of type intv) is a contiguous set of time (of type time “= z), i.e., intv “={∆ ⊆ time |∀t,t′: ∆•∀u: time • t ≤ u ≤ t′⇒ u ∈ ∆}. using ‘.’ for function application, we let lub.∆ and glb.∆ denote the least upper and greatest lower bounds of an interval ∆, respectively, where lub.∅ “=−∞ and glb.∅ “= ∞. we define inf.∆ “= (lub.∆ = ∞), fin.∆ “=¬inf.∆ and empty.∆ “= (∆ = ∅). for a set k and i,j ∈ k, we let [i,j]k “= {k: k | i ≤ k ≤ j} denote the closed interval from i to j containing elements from k. one must often reason about two adjoining intervals, i.e., intervals that immediately precede or follow a given interval. we say ∆ adjoins ∆′ iff ∆ ∝ ∆′, where ∆ ∝ ∆′ “= (∀t: ∆,t′: ∆′ • t < t′)∧ (∆∪∆′ ∈ intv) note that adjoining intervals ∆ and ∆′ must be disjoint, and by conjunct ∆∪∆′ ∈ intv, the union of ∆ and ∆′ must be contiguous. note that both ∆ ∝∅ and ∅∝ ∆ hold trivially for any interval ∆. a stream of behaviours over va ⊆ var∪addr is given by a total function of type streamva “= time → stateva, which maps each time to a state over va. to reason about specific portions of a stream, we use interval predicates, which have type intvpredva “= intv → streamva → b. note that because a stream encodes the behaviour over all time, interval predicates may be used to refer to the states outside a given interval. we assume pointwise lifting of operators on stream and interval predicates in the normal manner, define universal implication g1 v g2 “= ∀∆: intv,s: stream• g1.∆.s ⇒ g2.∆.s for interval predicates g1 and g2, and say g1 ≡ g2 holds iff both g1 v g2 and g2 v g1 hold. like interval temporal logic [mos00], we may define a number of operators on interval predicates, e.g., if g ∈ intvpredva, ∆ ∈ intv and s ∈ streamva: (2g).∆.s “= ∀∆′: intv• ∆′ ⊆ ∆ ⇒ g.∆′.s (�g).∆.s “= ∃∆′ • ∆′∝ ∆ ∧ g.∆′.s we define two operators on interval predicates: chop, which is used to formalise sequential composition, and ω -iteration, which is used to formalise a possibly infinite iteration (e.g., a while loop). the chop operator ‘;’ is a basic operator on two interval predicates [mos00, ddh12, dh12], where (g1 ; g2).∆ holds iff either interval ∆ may be split into two parts so that g1 holds in the first and g2 holds in the second, or the least upper bound of ∆ is ∞ and g1 holds in ∆. the latter disjunct allows g1 to formalise an execution that does not terminate. using chop, we define the possibly infinite iteration (denoted gω ) of an interval predicate g as the greatest fixed point of z = (g ; z) ∨ empty, where the interval predicates are ordered using ‘v’ (see [dhms12] for details). thus, we have: 7 (g1 ; g2).∆.s “= ç∃∆1,∆2: intv•(∆ = ∆1 ∪∆2)∧ (∆1 ∝ ∆2)∧ g1.∆1.s ∧ g2.∆2.s å ∨ (inf ∧ g1).∆.s gω “= ν z•(g ; z)∨ empty in the definition of g1 ; g2, interval ∆1 may be empty, in which case ∆2 = ∆, and similarly ∆2 may empty, in which case ∆1 = ∆. hence, both (empty ; g) ≡ g and g ≡ (g ; empty) trivially hold. an iteration gω of g may iterate g a finite (including zero) number of times, but also allows an infinite number of iterations [dhms12]. permissions and interference. to model true concurrency, the behaviour of the parallel composition between two processes in an interval ∆ is modelled by the conjunction of the behaviours of both processes executing within ∆. because this potentially allows conflicting accesses to shared variables, we incorporate fractional permissions into our framework [boy03, ddh12]. we assume the existence of a permission variable in every state σ ∈ stateva of type va → proc → [0,1]q, where va ⊆ var∪addr and q denotes the set of rationals. a process p ∈ proc has writepermission to location va ∈ va in σ ∈ stateva iff σ.π.va.p = 1; has read-permission to va in σ iff 0 < σ.π.va.p < 1; and has no-permission to access va in σ iff σ.π.va.p = 0. we define r.va.p.σ “= (0 < σ.π.va.p < 1) and w .va.p.σ “= (σ.π.va.p = 1) and d.va.p.σ “= (σ.π.va.p = 0) to be state predicates on permissions. in the context of a stream s, for any time t ∈ z, process p may only write to and read from va in the transition step from s.(t−1) to s.t if w .va.p.(s.t) and r.va.p.(s.t) hold, respectively. thus, w .va.p.(s.t) does not give p permission to write to va in the transition from s.t to s.(t + 1) (and similarly r.va.p). for example, to state that process p updates variable v to value k at time t of stream s, the effect of the update should imply ((v = k)∧ w .v.p).(s.t). one may introduce healthiness conditions on streams that formalise our assumptions on the underlying hardware. we assume that at most one process has write permission to a location va at any time, which is guaranteed by ensuring the sum of the permissions of the processes on va at all times is at most 1, i.e., ∀s: stream,t: time•((σp∈procπ.va.p)≤ 1).(s.t). other conditions may be introduced to model further restrictions as required [ddh12]. 4 evaluating state predicates over intervals the set of times within an interval corresponds to a set of states with respect to a given stream. hence, if one assumes that expression evaluation is non-atomic (i.e., takes time), one must consider evaluation with respect to a set of states, as opposed to a single state. it turns out that there are a number of possible ways in which such an evaluation can take place, with varying degrees of non-determinism [hbdj13]. in this paper, we consider actual states evaluation, which evaluates an expression with respect to the set of actual states that occur within an interval and apparent states evaluation, which considers the set of states apparent to a given process. actual states evaluation allow one to reason about the true state of a system, and evaluates an expression instantaneously at a single point in time. however, a process executing with finegrained atomicity can only read a single variable at a time, and hence, will seldom be able to view an actual state because interference may occur between two successive reads. for example, a process p evaluating ecl3 (the expression at cl3) cannot read both n1p 7→ mrk and n1p 7→ val in a single atomic step, and hence, may obtain a value for ecl3 that is different from any actual value of 8 ecl3 because interference may occur between reads to n1p 7→ mrk and n1p 7→ val. therefore, we define an apparent states evaluator that models fine-grained expression evaluation over intervals. our definition of apparent states evaluation does not fix the order in which n1p 7→ mrk and n1p 7→ val are read. we see this as advantageous over frameworks that must make the atomicity explicit (e.g., [vhhs06, cglm06, dsw11]), which require an ordering to be chosen, even if an evaluation order is not specified by the corresponding implementation (e.g., [hhl+07]). in [vhhs06, cglm06, dsw11], if the order of evaluation is modified, the linearisability proof must be redone, whereas our proof is more general because it shows that any order of evaluation is valid. evaluation over actual states. to formalise evaluators over actual states, for an interval ∆ and stream s ∈ streamva, we define states.∆.s “= {σ : stateva | ∃t: ∆• σ = s.t}. two useful operators for a sets of actual states of a state predicate c are �c and �c, which specify that c holds in some and all actual state of the given stream within the given interval, respectively. ( �c).∆.s “=∃σ : states.∆.s• c.σ (�c).∆.s “=∀σ : states.∆.s• c.σ example 1. suppose v is a variable, fa and fb are fields, and s is a stream such that the expression (v 7→ fa,v 7→ fb) always evaluates to (0,0), (1,0) and (1,1) within intervals [1,4]n, [5,10]n and [11,16]n, respectively, i.e., for example �((v 7→ fa,v 7→ fb) = (0,0)).[1,4]n.s. thus, both �((v 7→ fa)≥ (v 7→ fb)).[1,16]n.s and �((v 7→ fa) > (v 7→ fb)).[1,16]n.s may be deduced. using �, we define ←−c and −→c , which hold iff c holds at the beginning and end of the given interval, respectively. ←−c “= (�c ∧¬empty) ; true −→c “= true ; (�c ∧¬empty) operators � and � cannot accurately model fine-grained interleaving in which processes are able to access at most one location in a single atomic step. however, both � and � are useful for modelling the actual behaviour of the system as well as the behaviour of the coarse-grained abstractions that we develop. we may use � to define stability of a variable v, and invariance of a state predicate c as follows: stable.v “=∃k • �(−−−→va = k)∧�(va = k) inv.c “= �−→c ⇒�c such definitions of stability and invariance are necessary because adjoining intervals are assumed to be disjoint, i.e., do not share a point of overlap. therefore, one must refer to the values at the end of some immediately preceding interval. evaluation over states apparent to a process. assuming the same setup as example 1, if p is only able to access at most one location at a time, evaluating (v 7→ fa) < (v 7→ fb) using the states apparent to process p over the interval [1,16]n may result in true, e.g., if the value at v·fa is read within interval [1,4]n and the value at v·fb read within [11,16]n. reasoning about the apparent states with respect to a process p using function apparent is not always adequate because it is not enough for an apparent state to exist; process p must also be able to read the relevant variables in this apparent state. typically, it is not necessary for a process to be able to read all of the state variables to determine the apparent value of a given state predicate. in fact, in the presence of local variables (of other processes), it will be impossible for p to read the value of each variable. hence, we define a function apparentp,w , where w ⊆var∪addr is the set of locations whose values process p needs to determine to evaluate the given state predicate. apparentp,w.∆.s “= {σ : statew | ∀va: w •∃t: ∆•(σ.va = s.t.va)∧ r.va.p.(s.t)} 9 using this function, we are able to determine whether state predicates definitely and possibly hold with respect to the apparent states of a process. for a state predicate c, interval ∆, stream s and state σ , we let accessed.c.σ denote the smallest set of locations (variables and addresses) that must be accessed in order to evaluate c in state σ and define locs.c.∆.s “= ⋃t∈∆ accessed.c.(s.t). for a process p, this is used to define (�p c).∆.s, which states that c holds in all states apparent to p in s within ∆. (similarly ( �p c).∆.s.) (�p c).∆.s “= let w = locs.c.∆.s in∀σ : apparentp,w.∆.s• c.σ ( �p c).∆.s “= let w = locs.c.∆.s in∃σ : apparentp,w.∆.s• c.σ continuing example 1, if c “= ((v 7→ fa) ≥ (v 7→ fb)), we have (¬�p c).[1,16]n.s holds, i.e., ( �p¬c).[1,16]n.s even though (�c).[1,16]n.s holds (cf. [ddh12, hbdj13]). one may establish a number of properties on �, �, � and � [hbdj13], for example �p(c∧d) v �pc∧ �pd holds. furthermore, for any process p, variable v, field f and constant k, stable.v ∧ �p((v 7→ f ) = k)⇒ �((v 7→ f ) = k) (1) 5 behaviours and refinement the behaviour of a command c executed by a non-empty set of processes p in a context z ⊆ var is given by interval predicate behp,z.c, which is defined inductively in fig. 5. we use behp,z to denote beh{p},z and assume the existence of a program counter variable pcp for each process p. we define shorthand fin idle “= enf fin• idle and inf idle “= enf inf• idle to denote finite and infinite idling, respectively and use the interval predicates below to formalise the semantics of the commands in fig. 5. evalp,z.c “= �p c ∧ behp,z.idle updatep,z(va,k) “= ®behp,z\{va}.idle ∧¬empty ∧�(va = k ∧ wp.va) if va ∈ varbehp,z\{va}.idle ∧¬empty ∧�((∗va) = k ∧ wp.va) if va ∈ addr to enable compositional reasoning, for interval predicates r and g, and command c, we introduce two additional constructs rely r • c and enf g• c, which denote a command c with a rely condition r and an enforced condition g, respectively [ddh12]. we say that a concrete command c is a refinement of an abstract command a iff every possible behaviour of c is a possible behaviour of a. command c may use additional variables to those in a, hence, we define refinement in terms of sets of variables corresponding to the contexts of a and c. in particular, we say a with context y is refined by c with context z with respect to a set of processes p (denoted a vy,zp c) iff behp,z.c v behp,y.a holds. thus, any behaviour of the concrete command c is a possible behaviour of the abstract command a. this is akin to operation refinement [re96], however, our definition is with respect to the intervals over which the commands execute, as opposed to their pre/post states. we write a vzp c for a v z,z p c, write a vp c for a v∅p c, and write a v y,z p c for a v y,z {p} c. the next lemma states that an assignment of state predicate c to a variable v may be decomposed to a guard [c] followed by an assignment of true to v and a guard [¬c] followed by an assignment of false to v. furthermore, one may move the frame of a command into the refinement relation. 10 behp,z.idle =̂ ∀va: z •�¬w .va.p behp,z.[c] =̂ �p c ∧ behp,z.idle behp,z.〈c〉 =̂ �c ∧ behp,z.idle behp,z.cω =̂ (behp,z.c)ω behp,z.(l: c) =̂ �(pcp = l)∧ behp,z.c behp,z.(c1 ; c2) =̂ behp,z.c1 ; behp,z.c2 behp,z.(c1 uc2) =̂ behp,z.c1 ∨ behp,z.c2 behp,z.(rely r • c) =̂ r ⇒ behp,z.c behp,z.(enf g• c) =̂ g ∧ behp,z.c behp,z.(vae := e) =̂ ß ∃k • evalp,z.(e = k) ; updatep,z(v,k) if vae ∈ var ∃k,a• evalp,z.(vae = a ∧ e = k) ; updatep,z(a,k) otherwise behp,z.(‖p:p cp) =̂  true if p = ∅ behp,z.cp if p ={p} ∃p1,p2,s1,s2 •(p1 ∪p2 = p)∧ (p1 ∩p2 = ∅)∧ p1 6= ∅∧ p2 6= ∅∧ s1 ∈{fin idle, inf idle}∧ s2 ∈{fin idle, inf idle}∧ (s1 = inf idle ⇒ s2 6= inf idle)∧ behp1,z.((‖p:p1 cp) ; s1)∧ behp2,z.((‖p:p2 cp) ; s2) otherwise behp,z.jy ck =̂ (z ∩y = ∅)∧ behp,z∪y .c figure 5: formalisation of behaviour function lemma 1 suppose c is a state predicate, v ∈ var, w,x ⊆ var, y,z ⊆ var∪addr, p ∈ proc, p ⊆ proc and a and c are commands. then 1. v := c vzp ([c] ; v := true)u([¬c] ; v := false), and 2. jw ak vy,zp jx ck provided a v w∪y,x∪z p c and w ⊆ (x∪z) and w ∩y = ∅ = x∩z. the next theorem establishes a galois connection between rely and enforced conditions [ddh12]. theorem 1 (rely r • a)vy,zp c ⇔ a v y,z p (enf r • c) when modelling a lock-free algorithm [cglm06, dsw11, vhhs06], one assumes that each process repeatedly executes operations of the data structure, and hence the processes of the system only differ in terms of the process ids. for such programs, a proof of the parallel composition may be decomposed using the following theorem [dd12]. theorem 2 if p ∈ proc, y,z ⊆ var∪addr, and a(p) and c(p) are commands parameterised by p, then (rely g•‖p:p a(p)) v y,z p (‖p:p c(p)) holds if for some interval predicate r and some p ∈ p and q “= p\{p} both of the following hold. rely g ∧ r • a(p) vy,zp c(p) (2) g ∧ behq,z.(‖q:q c(q)) v r (3) 6 verification of the lazy set details of the proof are presented in [dd13]. here, we only present a high-level overview of the proof and its decomposition (see section 7). furthermore, because (as already mentioned) verification of linearisability of contains is known to be difficult using frameworks that only 11 ϕ k+1.ua.σ =̂ if(k = 0) then ua else eval.((ϕ k.ua.σ) 7→ nxt).σ re.ua.vb.σ =̂ ∃k:n• ϕ k.ua.σ = vb setaddr.σ =̂ { a: addr re.head.a.σ ∧¬eval.(a 7→ mrk).σ } absset.σ =̂ { v: val ∃a: setaddr.σ • v = eval.(a 7→ val).σ } cgcon(p,x) =̂ (〈x ∈ absset〉; resp := true)u(〈x 6∈ absset〉; resp := false) cgs(p) =̂ jresp ( d x:z (cgadd(p,x)ucgrem(p,x)ucgcon(p,x))) ωk cgset(p) =̂ jhead,tail rely ←−−−− htinit • ‖p:p cgs(p)k figure 6: a coarse-grained abstraction of contains rely r • cgcon(p,x) vl,mp contains(p,x) vl,mp rely r • cgrem(p,x) remove(p,x) vl,mp rely r • cgadd(p,x) add(p,x) rely r • cgs(p) vhtp s(p) lemma 1theorem 2 lemma 1 set(p) vp cgset(p) behq,ht.(‖q:q s(q)) v r figure 7: proof decomposition for the lazy set verification consider the pre/post states [cglm06, dsw11, vaf10, vhhs06], we focus on its proof. a coarse-grained abstraction of set(p) in fig. 4 is given by cgset(p) in fig. 6, where for example, contains is replaced by cgcon, which tests to see if x is in the set using an atomic (coarsegrained) guard, then updates the return value to true or false depending on the outcome of the test. details of cgadd and cgrem are elided; we ask the interested reader to consult [dd13]. to prove refinement for contains(p,x) in fig. 7, we use lemma 1 to replace contains(p,x) by cl ; ((clt3:([in] ; resp := true))u(clf3:([¬in] ; resp := false))) where label cl3 has been split into clt3 and clf3 for the true and false cases, respectively, and in “=¬(n1p 7→ mrk)∧ ((n1p 7→ val) = x) cl “= cl1:(n1p := head) ; cl2: cloop(p,x) we then distribute cl within the ‘u’, use monotonicity to match the abstract and concrete true and false branches, then use monotonicity again to remove the assignments to resp from both sides of the refinement. thus, we are required to prove the following properties. rely r •〈x ∈ absset〉 vl,mp cl ; clt3:[in] (4) rely r •〈x 6∈ absset〉 vl,mp cl ; clf3:[¬in] (5) proof of (4). this condition states that there must be an actual state σ within the interval in which cl ; clt3:[in] executes, such that x ∈ absset.σ holds, i.e., there is a point at which the abstract set contains x. it may be the case that a process q 6= p has removed x from the set by the time process p returns from the contains operation. in fact, x may be added and removed several times by concurrent add and remove operations before process p completes execution of contains(p,x). however, this does not affect linearisability of contains(p,x) because a state 12 for which x ∈ absset holds has been found. an execution of contains(p,x) that returns true would only be incorrect (not linearisable) if true is returned and �(x 6∈ absset) holds for the interval in which cl ; clt3:[in] executes. similarly, we prove correctness of (5) by showing that is impossible for there to be an execution that returns false if �(x ∈ absset) holds in the interval of execution. proof of (5). using theorem 1, we transfer the rely condition r to the right hand side as an enforced property, define inv “= re.head.n1p ∨ (n1p 7→mrk), and require that r implies: inv.inv ∧ 2(�(pcp = cl3)⇒ inv.(n1p 7→ mrk)∧∀k: val• inv.((n1p 7→ val) = k)) (6) the behaviour of the right hand side of (4) simplifies to the following interval predicate using assumption (6) and that r is assumed to split. (r ∧ behp,l.idle) ; (r ∧ (�inv ; ( �¬(n1p 7→ mrk)∧ �((n1p 7→ val) = x)))) using assumption (6), it is possible to show that the second part of the chop implies the following, where inset(ua,x) “= re.head.ua ∧¬(ua 7→ mrk) ∧ (ua 7→ val = x) holds iff ua with value x is in the abstract set. ∃a: addr • −−−−−−−−−−−→ inset(head,a,x) ; (�(n1p = a)∧ �¬(a 7→ mrk)∧ �((a 7→ val) = x)) this trivially implies the required result, i.e., that �(x ∈ absset). to prove (5), as with (4), we use theorem 1 to transfer the rely condition r to the right hand side as an enforced property. by logic, the right hand side of (5) is equivalent to command enf r ∧ (�(x ∈ absset)∨ �(x 6∈ absset))• cl ; clf3:[¬in]. the �(x 6∈ absset) case is trivially true. for case �(x ∈ absset), we require that r satisfies: 2(�(x ∈ absset)⇒∃a: addr •�inset(head,a,x)) (7) 2(∀k:n• ϕ k.head 6= tail ⇒ (ϕ k.head 7→ val) < (ϕ k+1.head 7→ val)) (8) �(re.n1p.tail) (9) by (7), in any interval, if the value x is in the set throughout the interval, there is an address that can be reached from head, the marked bit corresponding to the node at this address is unmarked and the value field contains x. by (8) the reachable nodes of the list (including marked nodes) must be sorted in strictly ascending order and by (9) the tail node must be reachable from n1p. conditions (7), (8) and (9) together imply that there cannot be a terminating execution of cloop(p,x) such that clf3:[¬in] holds, i.e., the behaviour is equivalent to false. the rely condition r for the proof of contains must imply each of (6), (7), (8) and (9). we choose to take the weakest possible instantiation and let r be the conjunction (6) ∧ (7) ∧ (8) ∧ (9), which, as shown in fig. 7, must be satisfied by the rest of the program. this proof is straightforward by expanding the definitions of the behaviours and its details are elided. 7 conclusions we have developed a framework, based on [ddh12], for reasoning about the behaviour of a command over an interval that enables reasoning about pointer-based programs where processes 13 may refer to states that are apparent to a process [hbdj13]. parallel composition is defined using conjunction and conflicting access to shared state is disallowed using fractional permissions, which models truly concurrent behaviour. we formalise behaviour refinement in our framework, which can be used to show that a fine-grained implementation is a refinement of a coarsegrained abstraction. one is only required to identify linearising statements of the abstraction (as opposed to the implementation) and the proof of linearisability itself is simplified due to the coarse-granularity of commands. for the coarse-grained contains operation in fig. 6, the guard 〈x ∈ absset〉 is the linearising statement for an execution that returns true and 〈x 6∈ absset〉 the linearising statement of an execution that returns false. our proof method is compositional (in the sense of rely/guarantee) and in addition, we develop the rely conditions necessary to prove correctness incrementally. as an example, we have shown refinement between the contains operation of the lazy set [hhl+07] and an abstraction of the contains operation that executes with coarse-grained atomicity. acknowledgements. this work is supported by epsrc grant ep/j003727/1. we thank gerhard schellhorn and bogdan tofan for useful discussions, and anonymous reviewers for their insightful comments. bibliography [boy03] j. boyland. checking interference with fractional permissions. in cousot (ed.), sas. lncs 2694, pp. 55–72. springer, 2003. [bstr11] s. bäumler, g. schellhorn, b. tofan, w. reif. proving linearizability with temporal logic. formal asp. comput. 23(1):91–112, 2011. [cglm06] r. colvin, l. groves, v. luchangco, m. moir. formal verification of a lazy concurrent list-based set algorithm. in ball and jones (eds.), cav. lncs 4144, pp. 475–488. springer, 2006. [dd12] b. dongol, j. derrick. proving linearisability via coarse-grained abstraction. corr abs/1212.5116, 2012. [dd13] b. dongol, j. derrick. simplifying proofs of linearisability using layers of abstraction. corr abs/1307.6958, 2013. [ddh12] b. dongol, j. derrick, i. j. hayes. fractional permissions and non-deterministic evaluators in interval temporal logic. eceasst 53, 2012. [dglm04] s. doherty, l. groves, v. luchangco, m. moir. formal verification of a practical lock-free queue algorithm. in frutos-escrig and núñez (eds.), forte. lncs 3235, pp. 97–114. springer, 2004. [dh12] b. dongol, i. j. hayes. deriving real-time action systems controllers from multiscale system specifications. in gibbons and nogueira (eds.), mpc. lncs 7342, pp. 102–131. springer, 2012. [dhms12] b. dongol, i. j. hayes, l. meinicke, k. solin. towards an algebra for real-time programs. in kahl and griffin (eds.), ramics. lncs 7560, pp. 50–65. 2012. 14 [dsw11] j. derrick, g. schellhorn, h. wehrheim. verifying linearisability with potential linearisation points. in butler and schulte (eds.), fm. lncs 6664, pp. 323–337. springer, 2011. [eqs+10] t. elmas, s. qadeer, a. sezgin, o. subasi, s. tasiran. simplifying linearizability proofs with reduction and abstraction. in esparza and majumdar (eds.), tacas. lncs 6015, pp. 296–311. springer, 2010. [gro08] l. groves. verifying michael and scott’s lock-free queue algorithm using trace reduction. in harland and manyem (eds.), cats. crpit 77, pp. 133–142. 2008. [hbdj13] i. j. hayes, a. burns, b. dongol, c. b. jones. comparing degrees of nondeterminism in expression evaluation. comput. j. 56(6):741–755, 2013. [hhl+07] s. heller, m. herlihy, v. luchangco, m. moir, w. n. s. iii, n. shavit. a lazy concurrent list-based set algorithm. parallel processing letters 17(4):411–424, 2007. [hw90] m. p. herlihy, j. m. wing. linearizability: a correctness condition for concurrent objects. acm trans. program. lang. syst. 12(3):463–492, 1990. [jon83] c. b. jones. tentative steps toward a development method for interfering programs. acm trans. prog. lang. and syst. 5(4):596–619, 1983. [lip75] r. j. lipton. reduction: a method of proving properties of parallel programs. commun. acm 18(12):717–721, 1975. [mos00] b. c. moszkowski. a complete axiomatization of interval temporal logic with infinite time. in lics. pp. 241–252. 2000. [orv+10] p. w. o’hearn, n. rinetzky, m. t. vechev, e. yahav, g. yorsh. verifying linearizability with hindsight. in richa and guerraoui (eds.), podc. pp. 85–94. acm, 2010. [re96] w. p. de roever, k. engelhardt. data refinement: model-oriented proof methods and their comparison. cambridge tracts in theor. comp. sci. 47. cambridge university press, 1996. [tw11] a. j. turon, m. wand. a separation logic for refining concurrent objects. in ball and sagiv (eds.), popl. pp. 247–258. acm, 2011. [vaf07] v. vafeiadis. modular fine-grained concurrency verification. phd thesis, university of cambridge, 2007. [vaf10] v. vafeiadis. automatically proving linearizability. in touili et al. (eds.), cav. lncs 6174, pp. 450–464. springer, 2010. [vhhs06] v. vafeiadis, m. herlihy, t. hoare, m. shapiro. proving correctness of highlyconcurrent linearisable objects. in torrellas and chatterjee (eds.), ppopp. pp. 129– 136. 2006. 15 introduction a list-based concurrent set interval-based framework evaluating state predicates over intervals behaviours and refinement verification of the lazy set conclusions on software quality-motivated design of a real-time framework for complex robot control systems electronic communications of the easst volume 60 (2013) proceedings of the seventh international workshop on software quality and maintainability bridging the gap between end user expectations, vendors’ business prospects, and software engineers’ requirements on the ground (sqm 2013) on software quality-motivated design of a real-time framework for complex robot control systems max reichardt, tobias föhst, karsten berns 20 pages guest editors: eric bouwers, yijun yu managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst on software quality-motivated design of a real-time framework for complex robot control systems max reichardt1, tobias föhst1, karsten berns1 1 robotics research lab department of computer science university of kaiserslautern, germany {reichardt, foehst, berns}@cs.uni-kl.de abstract: frameworks have fundamental impact on software quality of robot control systems. we propose systematic framework design aiming at high levels of support for all quality attributes that are relevant in the robotics domain. design decisions are taken accordingly. we argue that certain areas of design are especially critical, as changing decisions there would likely require rewriting significant parts of the implementation. for these areas, quality-motivated solutions and benefits for actual applications are discussed. we illustrate and evaluate their implementations in our framework finroc – after briefly introducing it. this includes a highly modular framework core and a well-performing, lock-free, zero-copying communication mechanism. finroc is being used in complex and also in commercial robotic projects – which evinces that the approaches are suitable for real-world applications. keywords: software quality, robotics, framework design, software maintenance 1 motivation reaching high levels of software quality is in many ways a decisive factor for success when developing robot control systems – especially when systems grow beyond a certain size. with the intent to commercially develop and sell increasingly complex autonomous service robots on emerging (mass) markets, importance of this topic will rise even further. certification for safety is a central requirement in this context. complex robot control software is typically implemented based on a robotic framework, toolkit, or middleware. as these terms overlap, “framework” will be used in the remainder of this document. by defining a component model and dealing with many common problems, the selected framework has fundamental impact on the quality of robot control software: for example, if the framework is portable, efficient, or scalable, robot control software will more likely be too. in fact, we observe the framework as a central adjustable factor determining software quality – with significant potential to introduce measures that actually guarantee or enforce certain quality requirements. from this point of view, frameworks are an important research topic for making progress in robotics software development. due to its special nature, characteristics, and constraints (e.g. autonomy in complex dynamic environments), it is worthwhile to investigate this topic specifically for the service robotics domain, as possibilities and difficulties differ from other areas of (embedded) software development. 1 / 20 volume 60 (2013) on software quality-motivated design of a real-time framework for robotics table 1: relevant quality attributes in robotics software execution qualities evolution qualities performance efficiency maintainability responsiveness (latency) reusability safety and reliability portability robustness and adaptability flexibility recoverability extensibility scalability modularity usability and predictability changeability functional correctness integrability interoperability testability in order to implement quality measures and perform experiments, it is sometimes necessary to have full control over the framework core, architecture, tools, or code repositories. therefore, using a framework developed and maintained by a third party can be a limiting factor. thus, we implemented finroc1 (see section 4) considering factors altering software quality from the initial design phase in 2008. nonetheless, as this is in fact a software quality attribute as well, we pay close attention that our efforts are interoperable with other projects in the open source robotics community. the fact that finroc is being used in complex and also in commercial robotic projects (see section 6) evinces that the presented approaches are actually suitable for real-world applications. with respect to effort spent on software quality assurance, professional product development and most research groups are two different worlds. in academics, spending time on this task is typically not rewarded – as long as systems run sufficiently robust and efficient. in robotics, however, systems often have considerable complexity. keeping them maintainable across multiple generations of phd students is a major challenge. in practice, many systems are abandoned when their developers leave. due to time constraints in this context, measures to raise software quality are of particular interest if they cause only little extra effort in application development. again, we see measures and policies implemented in the framework as a promising area to work on. 2 software quality in robotics software quality is strongly related to non-functional requirements, as these “characterize software quality and enable software reuse” [bs09]. “although the term ‘non-functional requirement’ has been in use for more than 20 years” and there is consensus that they are important, “there is still no consensus in the requirements engineering community what non-functional requirements are” [gli07]. international standards such as iso/iec 9126 and iso/iec 25010 structure non-functional requirements in quality characteristics and subcharacteristics. mari and eila [me03] distinguish between “execution qualities” and “evolution qualities”. following this, 1 http://www.finroc.org proc. sqm 2013 2 / 20 http://www.finroc.org eceasst we believe the quality attributes collected in table 1 are especially relevant across a wide range of complex control systems for service robots. various publications on robotics software deal with the necessity and difficulties reaching these quality attributes, such as software reuse [vg07, bs09, bdwl11], robustness and reliability [sma07], scalability [shrk11], or interoperability and integration [clr07, sb11]. clearly, it is challenging for a software developer to consider all these attributes when designing a robotic application. using a suitable framework can simplify this task significantly. we distinguish three levels of framework support: • in the ideal case, quality attributes can be ensured “seamlessly”. e.g. if the framework provides convenient facilities for efficient, scalable, and robust inter-component data exchange – possibly providing real-time guarantees – the developer does not need to worry and the resulting application will not have deficiencies in this respect. interoperability is another example. • if bad code or bad component behavior can be detected automatically, requirements can be enforced by notifying the developer. this way, for instance, memory allocation or locking can be prevented in real-time code. introducing a total ordering on locks – as shown in [wil12] – avoids dead-locks. • there are many other measures to support certain software quality attributes that do not provide any guarantees though. promoting good software development practices such as separating framework-independent from framework-dependent code will increase reusability and portability of software artifacts. with finroc as an object of study and validation, we investigate measures that can be implemented in a framework to support or even guarantee certain quality attributes. 3 critical areas of design many important decisions must be taken when designing a framework – often involving tradeoffs. ideally, those decisions are well-founded. this requires a thorough understanding of the available options. studying existing solutions, we identified alternatives, best practices, and lessons learnt with respect to different areas of design. their implications on a robot control’s quality attributes were evaluated carefully. notably, design decisions greatly differ in criticality. in fact, some decisions can easily be changed later should other options seem superior. others, however, can only be undone with immense development effort, which might not be realistic as this would often require rewriting major parts of a framework. adding real-time support to a framework that was not designed with this in mind is an example. it is important to be aware of this fact. fig. 1 is an attempt to rate features and areas of design with respect to their criticality. note that these ratings assume that a highly modular framework core is used (see section 3.2): e.g. a network transport mechanism is only easily exchangeable if it is clearly separated from the rest of the framework. as long as the framework is implemented in a portable programming language and depends – if at all – on platform-independent libraries, portability is not a major 3 / 20 volume 60 (2013) on software quality-motivated design of a real-time framework for robotics difficult to simple to add or change add or change real-time support script language support overall architecture network transport runtime construction interoperability modular framework core web interface efficient, lock-free communication tooling portability api and application constraints figure 1: subjective criticality ratings for areas of design issue. furthermore, any binary serialization mechanisms should take care of endianness. the api can always be extended with little effort. however, changing it can become laborious once a considerable amount of components and applications exist. having identified critical areas of design, we focused on getting those right in the initial finroc release. as we believe that all the features on the left – real-time support, a modular framework core, runtime construction, and efficient, lock-free communication – are beneficial to software quality, they are all supported. as it turned out, it is somewhat challenging to implement those features in combination. finroc is actually the only framework we are aware of that supports them all. as this is not always obvious, their relevance for the service robotics domain is briefly discussed in the following. 3.1 efficient, lock-free real-time implementation less computational overhead leads to lower latency and lower power consumption of a robot control. more tasks can be executed on a computing node – or smaller, cheaper nodes can be used. nesnas [nes07] shares the view that communication overhead is critical: “an application framework must pay particular attention to avoiding unnecessary copying of data when exchanging information among modules”. due to the modular application style, using a framework will always induce computational overhead compared to a perfectly engineered monolithic solution. however, frameworks such as orocos [soe06] show that computational overhead can be low, despite a relatively loose coupling. in practice, as soon as it comes to buffer management or multithreading, we often observe that framework-based solutions actually outperform custom standalone code – sometimes drastically. this is due the fact that efficient, lock-free buffer management is complex to implement. as monolithic implementations are furthermore detrimental with respect to reusability, maintainability, and tool support, they are no alternative to using an efficient framework for realizing complex robot control software. efficiency also determines limits on the maximum number of components that are feasible and therewith component granularity. in our research on large behavior-based networks, for instance, we develop systems that consist of far more than thousand components. notably, locking can be an even bigger issue with respect to latency and scalability – as we proc. sqm 2013 4 / 20 eceasst experienced exchanging data via blackboards in mca2 [sag01]. although based on an efficient shared-memory implementation, locking them exclusively from different components quickly causes significant, varying delays. such delays in the image processing components of our humanoid robot roman, for instance, hindered natural interaction. furthermore, overall cycle times are high. being able to use shorter cycle times in finroc immediately solved several problems we had with a lateral controller steering an agricultural vehicle. lock-free implementations are certainly advantageous. finally, functionality with real-time requirements can only be realized without completely bypassing the framework (and taking care of multithreading and lock-free data sharing manually) if the framework provides real-time support. while real-time requirements can often be neglected in scientific experiments, this is a central topic for safety-critical parts of commercial robot control systems in order to guarantee that a robot will always react in time to certain events. for our bucket excavator thor (see section 6) this is certainly critical. notably, it is possible to separate the component communication mechanism (“transport”) from the rest of the framework to make it exchangeable later – an approach taken in orocos. this might seem to contradict the criticality rating in fig. 1. however, it does not as the framework must be deliberately designed for this. apart from that, the common api for all transports can limit efficiency: e.g. if empty buffers are not obtained from the api, unnecessary copying cannot be avoided in multithreaded applications. 3.2 modular framework core makarenko et al. [mbk07] discuss the many benefits of frameworks having a slim and clearly structured code base – especially regarding development and maintainability of a framework itself. a modular framework core is furthermore beneficial regarding flexibility, extensibility, and changeability of a framework and the resulting robot control systems. furthermore, portability is increased, as many advanced features such as script language support or a web interface can be made optional. this allows creating slim – possibly single-threaded – configurations of a framework with minimal library dependencies that are suitable for small computing nodes. generally, this configurability can allow to tailor a framework to applications, computing hardware, and network topology. in the end, this makes the framework suitable for a broader range of systems. the concept of “stacks” in ros [qcg+09] goes into this direction. several frameworks feature an exchangeable network transport layer. the player project is an early example [gvh03]. few are completely transport-independent, such as orocos [soe06]. in contrast, as mca2 was tightly coupled to a custom tcp-based protocol, we encountered limitations with respect to robustness and efficiency that could not easily be resolved – especially in the context of teleoperation over weak wireless connections and the internet. with respect to ratings in fig. 1, a modular framework implementation with a clear separation of concerns is essential in order to classify design areas as simple to change. 3.3 runtime construction the term “runtime construction” refers to the possibility to instantiate, connect, and delete components at application runtime. some frameworks support this on a process level: processes 5 / 20 volume 60 (2013) on software quality-motivated design of a real-time framework for robotics containing components can be started and terminated. if performance is not to be sacrificed, however, runtime construction is also relevant for components located inside the same process. whether or not a framework should support the latter is a controversial topic – due to limited advantages and significantly complicating the framework implementation. we see some use cases for dynamic application structure: • when operating in smart environments, robots typically need to condense the available sensor information in homogeneous views of the environment. suitable components to perform such tasks can be created as sensors are encountered. • smart [sma07] proposes graceful degradation in order to increase robustness of systems. this includes dynamic rewiring of components in the case of sensor failure. • if developers can modify an application while a robot is running – possibly using a graphical tool – effort for recompiling and restarting robot controls during experiments can be reduced significantly. • it simplifies implementations – e.g. of network transport plugins with a dynamic set of i/os. furthermore, it provides the necessary facilities to handle application structure in e.g. xml files instead of source code. this has the advantage that structure changes do not require recompiling and tools for round-trip engineering are simpler to realize. thus, runtime construction contributes to adaptability and flexibility of a system. 4 finroc implementation and evaluation for the past decade, we have been using mca2 [sag01] for developing robot controls, and learned to appreciate many of its qualities – such as real-time support, its scalability, and its application style. by distinguishing between sensor and controller data, it is well-suited for application visualization. mca2 was originally developed at the fzi2 (“forschungszentrum informatik”) in karlsruhe. over the years, we realized various modifications and enhancements in the mca2-kl branch3. as its kernel is monolithic, difficulties improving several of the areas listed in fig. 1 were encountered. unable to find an open source framework with the properties we rate critical (see section 3), we decided to implement finroc. as makarenko et al. [mbk07] argue, developing and maintaining a framework can be feasible. system decomposition is similar to mca2: applications are structured in “modules” (components), “groups” (composite components), and “parts” (os processes). the interfaces of modules, groups, and parts are a set of ports. these can be connected if their types are compatible. a finroc application consists of a set of interconnected modules and can be visualized as a data flow graph. “groups” encapsulate sets of modules (or other groups) that fulfil a common task. they structure an application. modules and groups can be placed in “thread containers” to assign them to operating system threads. unlike in mca2, it is also possible to trigger execution by asynchronous events – as nesnas [nes07] recommends to support. 2 http://www.fzi.de/ 3 http://rrlib.cs.uni-kl.de/ proc. sqm 2013 6 / 20 http://www.fzi.de/ http://rrlib.cs.uni-kl.de/ eceasst furthermore, we separate framework-dependent from framework-independent code – as also [mbk07, roc, qcg+09] encourage. in our experience, this is the best way to make software artifacts portable and reusable across research institutions. in fact, most of our code base are actually framework-independent libraries (called rrlibs). over the last decade, we developed a considerable collection of drivers and libraries for robot controls available as rrlibs. many of them have already been integrated in finroc. there is a c++11 and also a native java implementation of finroc. the c++11 version currently depends on the platform-independent boost libraries4. we will remove this dependency, as soon as compilers on our systems have sufficient c++11 support. c++11 being the first c++ standard with a multithreading-aware memory model [wil12], it is preferable to c++03 for safe, lock-free implementations. notably, lock-free code that is safe on one cpu architecture might not be on another, due to different behavior with respect to memory ordering. finroc works well on arm-based platforms such as gumstix5 or the pandaboard6. furthermore, finroc’s java implementation compiles on android, so apps can utilize it to communicate with robots. 4.1 lock-free, zero-copy intra-process communication aiming to maximize (intra-process) communication efficiency, finroc features a lock-free implementation that does not copy data. it is illustrated in fig. 2a. the implementation supports input queues and allows switching between pushing and pulling data at application runtime. notably, port connections can be changed without blocking threads that currently publish data via the same ports. ports allow n:m connections – although connecting multiple output ports to one input port is typically discouraged. module image output port module input port module bu�er pool bu�er 1 bu�er 2 bu�er 3 bu�er n ... routing port group input port input queue void mdemo::update() { tportdataptr im = port.getpointer(); ... } (a) standard implementation module pose output port module input port module pose3d bu�er pool bu�er 1 bu�er 2 bu�er n ... routing port group input port input queue void mdemo::update() { tpose3d pose = port.get(); ... } thread i (b) optimized implementation for cheaply copied types figure 2: finroc’s lock-free, zero-copy data exchange 4 http://www.boost.org/ 5 http://www.gumstix.com/ 6 http://pandaboard.org/ 7 / 20 volume 60 (2013) http://www.boost.org/ http://www.gumstix.com/ http://pandaboard.org/ on software quality-motivated design of a real-time framework for robotics 4.1.1 implementation the lock-free implementation is based on buffer pools, typically managed by output ports. apart from the actual data, buffers contain storage for a timestamp and management data such as a reference counter. in order to publish data via an output port, an unused buffer is obtained from the port and filled with the data to be published. if all buffers are in use, another buffer is allocated and added to the pool. for real-time code, pools need to contain sufficient buffers so that this does not occur. ports contain atomic pointers, pointing to the ports’ current values (symbolized by small orange squares in fig. 2a). publishing data replaces these pointers and updates reference counters. obtaining the current buffer from a port is the tricky part: the pointer to the current buffer is read in one atomic operation and the reference counter is increased in another. in a naive implementation things can go wrong if the buffer is returned to the buffer pool (and possibly published again) in between these two operations. therefore, we use tagged pointers and tagged reference counters. the reference counter may only be increased if it is not zero and if tags match. otherwise, a new buffer has arrived and the procedure is repeated. once published, buffers are immutable (get operations on ports return const pointers). almost any c++ type can be used in ports – including types without copy constructor and assignment operator, as well as std::vectors of them. merely, stream operators for binary serialization need to be provided. if the type has no default constructor, a template needs to be specialized so that buffers of this type can be instantiated. lock-free buffer pool management and atomics-based reference counting causes some computational overhead. therefore, finroc uses an optimized port implementation for small data types of constant size (see fig. 2b). for such types, thread-local buffer pools are used and only the owner thread accesses the reference counter. again, pointers are tagged in order to avoid the aba problem. 4.1.2 benchmarks in order to evaluate our implementation’s impact on computational overhead, a benchmark with uncompressed, high-resolution camera images was set up – as they are quite costly to copy. references are mca2-kl and rock/orocos with a state-of-the-art, intra-process communication model – either locked or lock-free with copying. a producer-consumer scenario was set up in each of these frameworks7: one producer sends hd rgb24 images (1920×1080) at 50 fps to several consumer tasks – filling the image buffers via memcpy8. consumers are port-driven and calculate the arriving frames per second. cpu load and memory consumption were determined via htop. only thread-safe communication mechanisms were used. the results are shown in table 2. using lock-free communication in orocos, cpu load and memory consumption grow drastically with an increasing number of consumers. as the authors noted, the lock-free transport is optimized for safe real-time operation and less for high 7 all benchmarks were performed on an intel core i7 @2.67 ghz pc running ubuntu 12.04, 32-bit 8 notably, this is not always necessary in finroc. consumers directly receive the buffers obtained from the v4l2 driver, for instance. proc. sqm 2013 8 / 20 eceasst table 2: results of image transport benchmark framework consumers øfps cpu ram 0 n/a 9 % 35 mib orocos 1 50.00 40 % 52 mib locked 7 50.00 40 % 52 mib 15 50.00 41 % 52 mib 0 n/a 2 % 29 mib orocos 1 50.00 11 % 61 mib lock-free 7 50.00 49 % 202 mib 15 49.20 100 % 392 mib finroc 0 n/a 6 % 32 mib 1 50.00 6 % 32 mib 7 50.00 6 % 33 mib 15 50.00 7 % 36 mib mca2-kl 0 n/a 6 % 19 mib 1 50.00 6 % 19 mib 7 50.00 6 % 19 mib 15 50.00 7 % 19 mib throughput. in finroc on the other hand, adding consumers has minimal impact on cpu load or memory usage. possibly, an orocos transport plugin based on the mechanism presented here would be feasible. mca2-kl uses only a single buffer and therefore has the lowest memory footprint. it has, however, issues with blocking (see section 3.1). to measure the theoretical limits imposed by computational overhead from intra-process communication, five simple modules were connected to a control loop – each module reading and publishing a 4×4-matrix in every cycle. this control cycle can be executed with more than 1 mhz by a single thread that never pauses. 4.2 highly modular framework core targeting a high level of modularity with a clear separation of concerns, we opted for a plugin architecture in finroc. furthermore, framework-independent functionality was realized as independent rrlibs. fig. 3 illustrates how this currently looks like for a selection of plugins9. functionality that is not needed in every application is generally implemented in optional plugins. by combining plugins with the relevant functionality, finroc can be tailored to the requirements of an application. furthermore, functionality that supports developers can be added via plugins during the development process of a system. when software is to be deployed – possibly on small embedded nodes – this functionality can simply be removed. as motivated by makarenko et al. [mbk07], a central target is keeping the code base of finroc’s core components slim, as less code means lower maintenance effort and fewer errors. quality assurance can be focused on important and relatively small core components. experimental enhancements are ideally realized in plugins with no impact on quality of the core components that are used in important projects. 9 lines of code were counted using david a. wheeler’s ’sloccount’ 9 / 20 volume 60 (2013) on software quality-motivated design of a real-time framework for robotics util (899 sloc) design_patterns (790 sloc) time (692 sloc) xml (670 sloc) logging (1.4 ksloc) serialization (3.1 ksloc) rtti (1.9 ksloc)concurrent_containers (2.1 ksloc) bu�er_pools (602 sloc) core (3.9 ksloc) data_ports (6.0 ksloc) parameters (1.9 ksloc) scheduling (567 sloc) runtime_construction (2.1 ksloc) structure (833 sloc) blackboard (1.8 ksloc) tcp (4.2 ksloc) urbiscript (1.0 ksloc) rrlibs core plugins ib2c (1.3 ksloc) thread (1.6 ksloc) rpc_ports (1.9 ksloc) ros (1.3 ksloc) figure 3: finroc’s modular core with a selection of plugins as depicted in fig. 3, finroc consists of many small independent software entities. these typically consist of only a few thousand lines of code. hence, they can be reimplemented with reasonable effort. as long as interfaces stay the same, each of these entities can be replaced with alternative implementations – possibly optimized for certain hardware, application constraints, or in some way certified. single-threaded implementations, for instance, would be simpler and more efficient. the plugins data ports, rpc ports, and blackboard provide different mechanisms for component interaction. data ports contains the implementation presented in section 4.1 and is the primary mechanism for data exchange. the rrlibs concurrent containers and buffer pools comprise lock-free utility classes that are central for its implementation. structure is the default finroc api and provides the base classes for modules, groups, and parts as introduced in section 4, whereas ib2c contains the component types for different kinds of behaviors in our ib2c architecture [plb10]. urbiscript adds experimental support for the scripting language from the urbi framework [bai07]. ros enables interoperability with ros [qcg+09]. tcp provides a slim tcp-based peer-to-peer network transport supporting the publisher/subscriber pattern and featuring simple quality of service. it is currently the default in finroc. runtime construction contains functionality presented in 4.3. there are four fundamental classes in the finroc core (see fig. 4). we tried to come up with a simple structure to which the elements in mca2, the finroc api, and possibly other frameworks can be mapped. the central one is tframeworkelement. it is the base class for all components, ports, and structural entities. framework elements are arranged in a hierarchy. in our tooling, this hierarchy is typically shown in a tree view on the left (see fig. 5). then there is tabstractport. ports of compatible data types can be connected – the core allows n:m. such connections are networktransparent. the root framework element is the truntimeenvironment singleton. proc. sqm 2013 10 / 20 eceasst tframeworkelement tabstractport truntimeenvironment tannotation 1 * outgoing * incoming * 1 * figure 4: central classes in core several plugins need to attach information to framework elements – such as parameter links to config files or tasks that need to be scheduled. allowing the attachment of arbitrary annotations appears to be a fortunate design choice with respect to decoupling. 4.3 runtime construction decisions on support for concurrency significantly influence the effort required to implement runtime construction. in finroc, two threads cannot make changes to the application structure (component hierarchy and port connections) at the same time. all operations required in control loops, however, execute concurrently so that real-time threads in particular are not blocked performing their tasks. this requires using lists that allow iteration concurrently to modifications in several core classes. furthermore, it is critical to ensure that no thread accesses a port or component when deleting it. with these preparations in the core, the runtime construction plugin has three central tasks. first of all, it manages a global list of instantiable component types. by default, finroc component classes register on application startup providing class name and callback for construction. applications do not necessarily need to be linked against the shared library files containing the components that are used. they can also be loaded dynamically at runtime using this plugin. based on these mechanisms, components can be instantiated, connected, and removed graphically at application runtime using the finstruct tool (see fig. 5). finally, it allows to store the current application structure together with changes made to it in a simple xml format and to restore it on the next run. notably, these xml files can easily be generated, interpreted, and changed by external tools as well. using finstruct is optional. components can also be constructed and connected in source code. this can be more flexible if application structure is to be generated at runtime. as structure created via finstruct is marked and handled separately by the finroc runtime environment, using both mechanisms in parallel works well. if the interfaces of components change, it might no longer be possible to instantiate all elements as stored in xml files. in this case, components or edges that have become invalid are discarded and possibly need to be recreated. elements are automatically arranged utilizing graphviz10. apart from that, finstruct is the 10 http://www.graphviz.org/ 11 / 20 volume 60 (2013) http://www.graphviz.org/ on software quality-motivated design of a real-time framework for robotics figure 5: finstruct: application visualization, inspection, and construction tool to visualize and inspect applications. it can display and change the current values of all ports and parameters with supported data types. this includes unknown data types which can be serialized to strings or to xml. finstruct is the counterpart to mcabrowser in mca2. 5 policies to increase maintainability frequent changes are a typical characteristic of software projects in the service robotics domain, and it is important to keep the resulting effort for software maintenance low. with projects growing beyond a certain size, this is certainly (also) critical in university groups with the main developers always leaving after a few years. framework design and policies have significant influence on this issue. in the following, we briefly discuss some of our experience and decisions we have taken in finroc in this respect. 5.1 application interface and constraints an interesting question is whether imposing contraints on application structure is good practice – and also what they should look like. frameworks such as ros [qcg+09], player [gvh03], or orca [bkm+07] strive to prescribe as little as possible or necessary, as unnecessary contraints can be a nuisance and lead to ugly workarounds. in mca2, for instance, it is forbidden to connect modules in a way that lead to cycles in data dependencies. this led to inserting loopback modules to realize such cycles in many applications. on the other hand, strict guidelines help to avoid chaotic implementations. in our university group, many developers contribute to projects and libraries. most existing code is from developers no longer working here. experience shows that not all developers write clean code. enforcing guidelines contributes significantly to keeping large software systems maintainable. furthermore, controls of different robots have increased similarities, which facilitates reuse. apart from proc. sqm 2013 12 / 20 eceasst that, guidelines such as separating sensor and controller data in mca2 allow visualizing applications in a clearer way – compared to using a typical layout algorithm on a “raw” data flow graph. since different kinds of apis and programming styles are suitable for different levels of robot controls – e.g. claraty [nes07] explicitly separates a functional from a decisional layer – we decided to add apis (e.g. component types and communication mechanisms) via plugins. this way, they are clearly separated from the framework core. relatively strict constraints and guidelines are enforced in those apis only, while the core prescribes as little as possible. ideally, the relevant api classes can all be mapped on the basic primitives the core provides. this allows using the same tools to interact with application parts based on different apis – an advantage compared to using unrelated subframeworks. 5.2 size of libraries and components having refactored a considerable amount of code from members that are no longer in our group, we experienced that – as a rule of thumb – reusable libraries with up to 5000 sloc are typically comfortable to maintain and can be understood relatively quickly. so we try to keep all our libraries – including the framework core and its plugins – below this boundary (see 4.2). when a library becomes larger, it is checked whether there is a good way of splitting it up – targeting a low coupling between the new software entities. sometimes libraries contain relatively independent functionality. in other cases, core functionality and optional extensions can be identified. dependencies among libraries may only be one-way. cycles in the dependency graph are are not allowed. with these policies, we hope to support a clear separation of concerns and avoid heavyweight software artifacts as well as feature bloat. this also increases suitability for embedded systems. 5.3 separating framework-independent code in our experience, reuse of software artifacts across research institutions works best with code that is framework-independent. the opencv library [bra00] is a good example. developers of some frameworks explicitly encourage separating framework-independent code ([mbk07, roc, qcg+09]) – and we fully agree. over the years, a considerable repository of reusable mca2 libraries for all kinds of applications evolved. before porting them to finroc, we decided to separate the frameworkindependent code. as it turned out, most of the code actually is – leaving only thin modules that wrap this code for mca2. equivalent finroc modules are even thinner. notably, using it in an adtf [sch07] component for an industrial partner was not a problem either. so this appears to be good practice for migration and for avoiding framework lock-in: if most of the code is independent, migrating existing projects to other frameworks becomes much less of an issue. 5.4 coping with variability a major challenge with respect to reusable software artifacts is handling variability across a broad range of projects (as discussed in [bdwl11]). we try to cope with this issue primarily 13 / 20 volume 60 (2013) on software quality-motivated design of a real-time framework for robotics using c++11 templates. in our view, this is a very powerful and appropriate mechanism allowing amazing designs – without any additional tooling – and providing strict type-safety along with high flexibility by decomposing type-behavior into policies [ale01]. on the downside, however, code can be hard to read for developers not familiar with these concepts. 5.5 code generation custom code generators are sometimes integrated into a framework’s build toolchain with the intention to reduce development effort. in our experience, constraints, unforeseen side-effects and reduced transparency when tracking bugs can quickly outweigh any benefits – so adoption must be considered carefully. we deliberately minimized the amount of code generated by the framework to optional string constants for enums and port names. with respect to transparency, we want the complete system behavior to be evident from plain, versioned c++ code that an ide such as eclipse can index. developing separate versions of the framework in java and c++11 causes development overhead – an issue with respect to maintenance. notably, the first versions of finroc were developed in a subset of java – automatically generating respective c++ code via a custom eclipse plugin. this approach actually worked and produced clean, readable code. it was, however, dropped due to limitations. for instance, policy-based design, the raii idiom, or move-semantics could not really be exploited for the c++11 implementation, whereas the java implementation was more complicated than necessary. fixing c++-specific bugs required changing the java implementation and regenerating code. today, primary development is performed on the c++11 version. the java version is typically somewhat behind. as the main tooling is implemented in java, important parts are adapted immediately though. we attempt to cope with this issue by keeping the implementation slim and relatively stable. 5.6 stability of central software artifacts a common issue in software development are changes to software artifacts that many other artifacts depend on – especially when they involve modifications to their interfaces. projects follow different policies with respect to stability and backward-compatibility. with respect to robotic frameworks, diverse new requirements typically emerge when applications and plugins are developed. significant refactorings can be the best way to maintain a clean design. however, these can require changes to a lot of components – possibly major effort and a potential source of errors. with most of the component code currently under our control, we perform such changes in finroc if a positive impact on long-term quality of framework and applications is expected. adapting existing code causes considerable effort though. with a growing number of projects and users, backward-compatibility will rise in importance – although stable finroc releases are not affected by such changes. 6 current applications the autonomous mobile bucket excavator thor (see fig. 6 and 7) is the first major project we ported to finroc. apart from that, we are successfully using it in projects on agricultural maproc. sqm 2013 14 / 20 eceasst figure 6: the autonomous mobile bucket excavator thor figure 7: user interface created in fingui tool connected to simulated robot chinery as well as several mobile indoor platforms. further projects are currently being migrated. as mentioned in section 4.2, there is a finroc-based implementation of our behavior-based architecture ib2c. for the first time, the rules and guidelines worked out in [plb10] are properly and automatically checked and enforced. furthermore, model transformation and model checking approaches were realized [akrb13]. robot makers gmbh11, use finroc in their product lineup. this includes the mobile offroad robot viona (vehicle for intelligent outdoor navigation) – a commercially available robot platform with double-ackermann-kinematics (see fig. 8). furthermore, they have developed finroc support for the ethercat12 real-time bus. this facilitates integrating standard components from automation industry. 11 http://www.robotmakers.de 12 http://www.ethercat.org/ 15 / 20 volume 60 (2013) http://www.robotmakers.de http://www.ethercat.org/ on software quality-motivated design of a real-time framework for robotics figure 8: robot viona developed by robot makers gmbh 7 other frameworks numerous frameworks for robotics exists. however, we are not aware of any solution providing all the features we identified as critical in section 3 in combination. with a similar component style and support for efficient intra-process communication as well as real-time requirements, openrtm-aist [ask08], opros [jlj+10], orocos [soe06], and the derived robot construction kit (rock) [roc] probably come closest. none of them, however, features the same level of modularity in their implementation. only openrtm-aist provides intra-process runtime construction of components. notably, the rt component model used in openrtm-aist has been standardized by the omg [obj12]. the “robot operating system” (ros) [qcg+09] is currently the best-known and most widespread solution in academic institutions. several frameworks are interoperable with it. in this way, ros has contributed to reusability and integrability of available robotics software. several frameworks including ros sacrifice performance for the benefits of an extremely loose coupling: components usually run in separate threads and exchange data exclusively via network sockets. should the computational overhead be an issue in ros, it is possible to use frameworks such as orocos or finroc inside a ros node – making them somewhat complementary. alternatively, ros itself also has limited support for intra-process communication. this is, however, less sophisticated with respect to buffer management and also components need to be adapted. because of the limitations of mca2, its original developer – the fzi in karlsruhe – started working on mca3 [ugo+11]. the many other robotic frameworks include urbi [bai07], microsoft robotics developer studio13, claraty [nes07], or yarp [fmn08]. urbi features urbiscript – an integrated scripting language tailored to the requirements in robotics. similar to ros, it does not provide support for hard real-time applications. both urbi and yarp feature efficient intra-process communication. yarp focuses on middleware aspects and particularly targets to ease interoperability with software artifacts based on other frameworks and technology. microsoft robotics developer studio 13 http://www.microsoft.com/robotics/ proc. sqm 2013 16 / 20 http://www.microsoft.com/robotics/ eceasst is a robotics development environment including a visual programming language and a powerful simulator. limited to windows platforms and featuring an architecture similar to web services, its popularity in the robotics community is, however, moderate. claraty is an efficient framework whose developing institutions include the nasa jet propulsion laboratory. it is explicitly divided into a functional and a decisional layer. the latter is programmed in lisp. judging from the website, the constricted public efforts have been discontinued – with latest entries and releases from 2008. ardx features a particularly efficient inter-process communication mechanism [hb13]. notably, the implementation is based on ring buffers which is simpler and somewhat less flexible than reference counted buffers, as presented in section 4.1. major parts of framework and applications are implemented in the scripting language racket14 which is especially suitable for integrating domain-specific languages [bäu13]. ardx is currently not available to the public. adtf [sch07] is a solution with somewhat similar concepts used in the automotive industry. in this domain, autosar (automotive open system architecture)15 is an emerging architecture for the many control systems in vehicles sold on the mass market. it therefore needs to be slim and provide the high quality standards necessary for safety-critical applications. its complexity, however, is an issue that currently hinders adoption. model-driven software development provides possibilities to increase various quality attributes of robot control systems. among others, schlegel et al. [ssl12] elaborately propose adopting respective approaches in robotics, as they have done in smartsoft. 8 conclusion and outlook in this paper, we discuss the impact of a framework on software quality of robot control systems and propose systematic framework design aiming at high levels of support for all relevant quality attributes. in the scope of this document, we limit discussions to areas we identified as especially critical for initial design. further areas are investigated in [rfb13] – involving a detailed discussion on the state of the art. the sections on the approaches implemented in finroc show how solutions for these areas can look like. applications in research and industry indicate that the presented concepts work well in practice. however, it should be noted that these are not necessarily the best solutions. over the years, considerable effort was spent on reengineering and modularizing the framework. we hope to convey valuable experience gained during this process. in its current state, we believe that finroc provides the necessary means to conveniently create efficient, complex robot control systems. being interoperable with ros, our behaviorbased architecture, for instance, may also be used inside ros nodes. future activities will include supporting further standards and evaluating third-party component models for possible intergration. in order to increase portability and maintainability, we target reducing implementation size even further while preserving the same set of features. regarding measures to support software quality, the ones implemented are only the very beginning. there is certainly a lot more potential. identifying, implementing, and evaluating suitable such measures should be subject of future research. 14 http://racket-lang.org 15 http://www.autosar.org/ 17 / 20 volume 60 (2013) http://racket-lang.org http://www.autosar.org/ on software quality-motivated design of a real-time framework for robotics notably, relevance is not limited to robotics. in a very different domain, cast research recently concluded that there is a significant correlation between java ee frameworks and application quality [ssc13]. furthermore, ”frameworks do in fact help develop applications of predictable quality”. regarding the presented approaches, a modular framework has benefits in virtually any domain. with its small core, the eclipse ide was a prominent archetype when reasoning about finroc’s design. the efficient realization of data flow ports together with runtime construction, on the other hand, is more specific to concurrent, data-flow-oriented applications that require a certain level of flexibility. bibliography [akrb13] c. armbrust, l. kiekbusch, t. ropertz, k. berns. tool-assisted verification of behaviour networks. in proceedings of the 2013 ieee international conference on robotics and automation (icra 2013). karlsruhe, germany, may 6-10 2013. [ale01] a. alexandrescu. modern c++ design: generic programming and design patterns applied. addison-wesley longman publishing co., inc., boston, ma, usa, 2001. [ask08] n. ando, t. suehiro, t. kotoku. a software platform for component based rtsystem development: openrtm-aist. in carpin et al. (eds.), simulation, modeling, and programming for autonomous robots. lecture notes in computer science 5325, pp. 87–98. springer berlin / heidelberg, 2008. [bai07] j.-c. baillie. design principles for a universal robotic software platform and application to urbi. in 2nd national workshop on control architectures of robots (car’07). pp. 150–155. paris, france, may 31-june 1 2007. [bäu13] b. bäuml. one for (almost) all: using a modern programmable programming language in robotics. in brugali (ed.), proceedings of the eighth full-day workshop on software development and integration in robotics (sdir viii), in conjunction with the ieee international conference on robotics and automation (icra). karlsruhe, germany, may 2013. [bdwl11] c. r. baker, j. m. dolan, s. wang, b. b. litkouhi. toward adaptation and reuse of advanced robotic software. in ieee international conference on robotics and automation (icra). pp. 6071–6077. shanghai, china, may 9-13 2011. [bkm+07] a. brooks, t. kaupp, a. makarenko, s. b. williams, a. orebäck. orca: a component model and repository. in [bru07]. [bra00] g. bradski. the opencv library. dr. dobbs journal of software tools 25(11):120, 122–125, nov 2000. [bru07] d. brugali (ed.). software engineering for experimental robotics. springer tracts in advanced robotics 30. springer verlag, berlin / heidelberg, april 2007. proc. sqm 2013 18 / 20 eceasst [bs09] d. brugali, p. scandurra. component-based robotic engineering part i: reusable building blocks. robotics automation magazine, ieee 16(4):84–96, december 2009. [clr07] c. cote, d. letourneau, c. ra. using marie for mobile robot component development and integration. in [bru07]. [fmn08] p. fitzpatrick, g. metta, l. natale. towards long-lived robot genes. robotics and autonomous systems 56(1):29–45, january 2008. [gli07] m. glinz. on non-functional requirements. in 15th ieee international requirements engineering conference. re ’07. pp. 21–26. new delhi, india, october 15-19 2007. [gvh03] b. p. gerkey, r. t. vaughan, a. howard. the player/stage project: tools for multirobot and distributed sensor systems. in 11th international conference on advanced robotics (icar 2003). coimbra, portugal, june 30 july 3 2003. [hb13] t. hammer, b. bäuml. raw performance of robotic software middleware: a comparison and ardx’s new realtime communication layer. in brugali (ed.), proceedings of the eighth full-day workshop on software development and integration in robotics (sdir viii), in conjunction with the ieee international conference on robotics and automation (icra). karlsruhe, germany, may 2013. [jlj+10] c. jang, s.-i. lee, s.-w. jung, b. song, r. kim, s. kim, c.-h. lee. opros: a new component-based robot software platform. etri journal 32:646–656, 2010. [mbk07] a. makarenko, a. brooks, t. kaupp. on the benefits of making robotic software frameworks thin. in ieee/rsj international conference on intelligent robots and systems (iros 2007). san diego, california, usa, october 29-november 2 2007. [me03] m. mari, n. eila. the impact of maintainability on component-based software systems. in proceedings of the 29th conference on euromicro. euromicro ’03, pp. 25–32. ieee computer society, washington, dc, usa, 2003. [nes07] i. a. nesnas. the claraty project: coping with hardware and software heterogeneity. in [bru07]. [obj12] object management group, inc. robotic technology component (rtc) – version 1.1. framingham, massachusetts, usa, september 2012. [plb10] m. proetzsch, t. luksch, k. berns. development of complex robotic systems using the behavior-based control architecture ib2c. robotics and autonomous systems 58(1):46–67, january 2010. doi:10.1016/j.robot.2009.07.027. [qcg+09] m. quigley, k. conley, b. p. gerkey, j. faust, t. foote, j. leibs, r. wheeler, a. y. ng. ros: an open-source robot operating system. in proceedings of the workshop on open source software in robotics, in conjunction with the ieee international conference on robotics and automation (icra). kobe, japan, may 12-17 2009. 19 / 20 volume 60 (2013) on software quality-motivated design of a real-time framework for robotics [rfb13] m. reichardt, t. föhst, k. berns. design principles in robot control frameworks. in informatik 2013. lecture notes in informatics (lni). springer, koblenz, germany, september 16-20 2013. [roc] the robot construction kit. http://rock-robotics.org/. [sag01] k.-u. scholl, j. albiez, b. gassmann. mcaan expandable modular controller architecture. in 3rd real-time linux workshop. milano, italy, 2001. [sb11] r. smits, h. bruyninckx. composition of complex robot applications via data flow integration. in robotics and automation (icra), 2011 ieee international conference on. pp. 5576–5580. may 2011. [sch07] r. schabenberger. adtf: framework for driver assistance and safety systems. in international congress of electronics in motor vehicles. baden-baden, germany, 2007. [shrk11] a. shakhimardanov, n. hochgeschwender, m. reckhaus, g. k. kraetzschmar. analysis of software connectors in robotics. in ieee/rsj international conference on intelligent robots and systems (iros). pp. 1030–1035. san francisco, ca, usa, september 25-30 2011. [sma07] w. d. smart. writing code in the field: implications for robot software development. in [bru07]. [soe06] p. soetens. a software framework for real-time and distributed robot and machine control. phd thesis, department of mechanical engineering, katholieke universiteit leuven, belgium, may 2006. [ssc13] j. sappidi, a. szynkarski, b. curtis. crash special report – impact of java ee frameworks on the structural quality of applications. cast research labs, april 2013. http://www.castsoftware.com/research-labs/crash-reports. [ssl12] c. schlegel, a. steck, a. lotz. robotic systems applications, control and programming. chapter 23. robotic software systems: from code-driven to modeldriven software development. intech, http://www.intechopen.com/books/roboticsystems-applications-control-and-programming/robotic-software-systems-fromcode-driven-to-model-driven-software-development, 2012. isbn: 978-953-307941-7, intech, doi: 10.5772/25896. [ugo+11] k. uhl, m. göller, j. oberländer, l. pfotzer, a. rönnau, r. dillmann. ein softwareframework für modulare, rekonfigurierbare satelliten. in 60. deutscher luftund raumfahrtkongress 2011. bremen, germany, september 27-29 2011. [vg07] r. vaughan, b. gerkey. reusable robot software and the player/stage project. in [bru07]. [wil12] a. williams. c++ concurrency in action: practical multithreading. manning pubs co series. manning publications, shelter island, ny, usa, february 2012. proc. sqm 2013 20 / 20 http://rock-robotics.org/ http://www.castsoftware.com/research-labs/crash-reports motivation software quality in robotics critical areas of design efficient, lock-free real-time implementation modular framework core runtime construction finroc implementation and evaluation lock-free, zero-copy intra-process communication implementation benchmarks highly modular framework core runtime construction policies to increase maintainability application interface and constraints size of libraries and components separating framework-independent code coping with variability code generation stability of central software artifacts current applications other frameworks conclusion and outlook graph algebras for bigraphswork funded by miur prin project ``sister'', prot. 20088hxmyn. dedicated to the memory of robin milner (13 january 1934 -20 march 2010). electronic communications of the easst volume 29 (2010) proceedings of the ninth international workshop on graph transformation and visual modeling techniques (gt-vmt 2010) graph algebras for bigraphs davide grohmann, marino miculan 17 pages guest editors: jochen küster, emilio tuosto managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst graph algebras for bigraphs∗ davide grohmann1, marino miculan2 1 grohmann@dimi.uniud.it, 2 miculan@dimi.uniud.it department of mathematics and computer science, university of udine, italy abstract: binding bigraphs are a graphical formalism intended to be a meta-model for mobile, concurrent and communicating systems. in this paper we present an algebra of typed graph terms which correspond precisely to binding bigraphs over a given signature. as particular cases, pure bigraphs and local bigraphs are described by two sublanguages which can be given a simple syntactic characterization. moreover, we give a formal connection between these languages and synchronized hyperedge replacement algebras and the hierarchical graphs used in architectural design rewriting. this allows to transfer results and constructions among formalisms which have been developed independently, e.g., the systematic definition of congruent bisimulations for shr graphs via the ipo construction. keywords: bigraphs, graph grammars, types. 1 introduction bigraphical reactive systems (brss) [mil01] have been proposed as a promising meta-model for ubiquitous, mobile systems. the key feature of brss is that their states are bigraphs, semistructured data which can represent at once both the (physical, logical) location and the connections of the components of a system. the dynamics of the system is given by a set of rewrite rules on this semi-structured data. bigraphs have been successfully used for representing many domain-specific calculi and models, from traditional programming languages, to process calculi for concurrency and mobility, from context-aware systems to web-service orchestration languages—see e.g. [jm03, lm06, bde+06, gm07, bgh+08]. in fact, many variants of bigraphs have been proposed: the original pure bigraphs have been later generalized into binding bigraphs, allowing also for name scoping; other variants have been proposed, such as local bigraphs used for studying the λ -calculus. in this paper, we propose a general typed language for binding bigraphs, which we recall in section 2. more precisely, in section 3 we define an algebra of typed graph terms, so that welltyped terms correspond to binding bigraphs, and congruence captures bigraphic equality; this interpretation and corresponding properties are exposed in section 4. moreover, as we will show in section 5, the important subcategories of pure, local and prime bigraphs can be described by suitable sublanguages which can be given a simple and effective syntactic characterization. finally, we show how this language can be tailored to formalisms introduced in literature (for quite different purposes). in section 6 we consider hypergraphs used in synchronized hyperedge rewriting [fhl+05] and the “designs” of architectural design rewriting [blmt07]. ∗ work funded by miur prin project “sister”, prot. 20088hxmyn. dedicated to the memory of robin milner (13 january 1934 – 20 march 2010). 1 / 17 volume 29 (2010) mailto:grohmann@dimi.uniud.it mailto:miculan@dimi.uniud.it graph algebras for bigraphs we have implemented the resulting algorithm in our bpl tool, which we briefly describe in section 6. we also present an example of a bigraphical reactive system, an encoding of the polyadic π calculus, and show how it can be used to simulate a simple model of a mobile phone system. bigraphical reactive systems are related to general graph transformation systems; ehrig et al. [10] provide a recent comprehensive overview of graph transformation systems. in particular, bigraph matching is related to the general graph pattern matching (gpm) problem, so general gpm algorithms might also be applicable to bigraphs [11, 14, 20, 21]. as an alternative to implementing matching for bigraphs, one could try to formalize bigraphical reactive systems as graph transformation systems and then use an existing implementation of graph transformation systems. some promising steps in this direction have been taken [19], but they have so far fallen short of capturing precisely all the aspects of binding bigraphs. for a more detailed account of related work, in particular on relations between brss, graph transformations, term rewriting and term graph rewriting, see the thesis of damgaard [8, section 6]. the remainder of this paper is organized as follows. in section 2 we give an informal presentation of bigraphical reactive systems and in section 3 we present our matching algorithm: we first recall the graph-based inductive characterization, then we develop a term-based inductive characterization, which forms the basis for our implementation of matching. in section 4 we describe how our implementation deals with the remaining nondeterminism and in section 5 we discuss a couple of auxiliary technologies needed for the implementation of the term-based matching rules. in section 6 we finally describe the bpl tool and present an example use of it. we conclude and discuss future work in section 7. 2. bigraphs and reactive systems in the following, we present bigraphs informally; for a formal definition, see the work by jensen and milner [13] and damgaard and birkedal [9]. 2.1. concrete bigraphs a concrete binding bigraph g consists of a place graph gp and a link graph gl. the place graph is an ordered list of trees indicating location, with roots r0, . . . , rn, nodes v0, . . . , vk, and a number of special leaves s0, . . . , sm called sites, while the link graph is a general graph over the node set v0, . . . , vk extended with inner names x0, . . . , xl , and equipped with hyper edges, indicating connectivity. we usually illustrate the place graph by nesting nodes, as shown in the upper part of figure 1 (ignore for now the interfaces denoted by “ : · →· ”). a link is a hyper edge of the link graph, either an internal edge e or a name y. links bigraph g : �3, [{},{},{x0, x2}], x� → �2, [{y0},{}],y � 0 1 2 y0 y1 y2 x0 x2 x1 e2 v0 v1 v2 v3 e1 x ={x0, x1, x2} y ={y0, y1, y2} place graph gp : 3 → 2 roots: sites: r0 v0 v1 s0 v2 r1 v3 s2 s1 link graph gl : x → y names: inner names: y0 y1 y2 v0 v1 v2 v3 x0 x2 x1 e1 e2 fig. 1. example bigraph illustrated by nesting and as place and link graph. 2 figure 1: a binding bigraph (picture taken from [bdgm07]). these results are useful for several reasons. first, the typed algebra we propose can be used as a language for binding, pure, local and prime bigraphs, alternative to the bigraph algebra [jm03]. moreover, we confirm once more that bigraphs are a quite expressive general framework of ubiquitous systems. these connections pave the way for transferring results and constructions from bigraphs to the shr and adr frameworks, and vice versa, as suggested in section 7. 2 binding bigraphs in this section we recall milner’s binding bigraphs [jm03, jm04]. intuitively, a binding bigraph represents an open system, so it has an inner and an outer interface to “interact” with subsystems and the surrounding environment (figure 1). the width of the outer interface describes the roots, that is, the various locations containing the system components; the width of the inner interface describes the sites, that is, the holes where other bigraphs can be inserted. on the other hand, the names in the interfaces describe free links, that is end points where links from the outside world can be pasted, creating new links among nodes. in particular, we consider binding bigraphs with (possibly) multiply localized names, as in [mil04] and slightly generalizing [jm03, jm04]. more formally, let k be a binding signature of controls (i.e., node types), and ar : k → n×n be the arity function. the arity pair (h, k) (written h → k) consists of the binding arity h and the free arity k, indexing respectively the binding and the free ports of a control. definition 1 (interfaces) an interface is a pair 〈m, x〉 where m is a finite ordinal (called width), x is a finite set of names. a binding interface is a triple 〈m, loc, x〉, where 〈m, x〉 is an interface and loc ⊆ m×x is a locality map associating a subset of the names in x with sites in m. if (s, x) ∈ loc then x is located at s, or local to s; x is global if, ∀s, (s, x) /∈ loc. proc. gt-vmt 2010 2 / 17 eceasst sometime, we shall represent the locality map as a vector ~x = (x0, . . . , xm−1) of subsets, where xs is the set of names local to s; thus x \~x = x \(x0 ∪···∪xm−1) are the global names. we call an interface local (resp. global) if all its names are local (resp. global). we denote by ] the union of already disjoint sets, i.e., s]t , s∪t if s∩t = /0, otherwise it is undefined. definition 2 (pure and binding bigraphs) a (pure) bigraph g : 〈m, x〉→〈n,y〉 is composed by a place graph gp and a link graph gl describing node nesting and (hyper-)links among nodes: g = (v, e, ctrl, gp, gl) : 〈m, x〉→〈n,y〉 (pure bigraph) gp = (v, ctrl, prnt) : m → n (place graph) gl = (v, e, ctrl, link) : x →y (link graph) where v, e are the sets of nodes and edges respectively; ctrl : v → k is the control map, which assigns a control to each node; prnt : m]v → v ]n is the (acyclic) parent map (often written also as <); link : x ]p → e ]b]y is the link map, where p = ∑v∈v π1(ar(ctrl(v))) is the set of ports and b = ∑v∈v π2(ar(ctrl(v))) is the set of bindings (associated to all nodes). a link l ∈ x ]p is bound if link(l) ∈ b; it is free if link(l) ∈y ]e. a binding bigraph g : 〈m, loc, x〉→〈n, loc′,y〉 is a (pure) bigraph gu : 〈m, x〉→〈n,y〉 satisfying the following locality conditions: 1. if a link is bound, then the names and ports linked to it must lie within the node that binds it; 2. if a link is free, with outer name x, then x must be located in every region that contains any inner name or port of the link. definition 3 (binding bigraph category) the category of binding bigraphs over a signature k (written bbg(k )) has local interfaces as objects, and binding bigraphs as morphisms. given two binding bigraphs g : 〈m, loc, x〉→ 〈n, loc′,y〉, h : 〈n, loc′,y〉→ 〈k, loc′′, z〉, the composition h◦g : 〈m, loc, x〉→〈k, loc′′, z〉 is defined by composing their place and link graphs, whenever they have disjoint node and edge sets: 1. the composition of gp : m → n and h p : n → k is defined as h p ◦gp = (vg ]vh , ctrlg ]ctrlh , (idvg ] prnth )◦(prntg ]idvh )) : n → k; 2. the composition of gl : x →y and h l : y → z is defined as h l ◦gl = (vg ]vh , eg ]eh , ctrlg ]ctrlh , (ideg ]linkh )◦(linkg ]idph )) : x → z. definition 4 (pure, local and prime bigraphs) the category of pure bigraphs (big) is the full subcategory of bbg whose objects are of the form 〈n, ( /0), x〉 (often shorten as 〈n, x〉). the category of local bigraphs (lbg) is the full subcategory of binding bigraphs whose objects are of the form 〈n, (~x ),⋃~x〉 (often shorten as (~x )). the category of prime bigraphs (pbg) is the full subcategory of local bigraphs whose objects are of the form 〈n, (~x ),⋃~x〉, with n ∈{0, 1}, (often shorten as before: (~x )). intuitively, in pure bigraphs all names are global, whilst in local bigraphs all names are local, finally prime bigraphs are all the local bigraphs with one root, and one or zero holes. 3 / 17 volume 29 (2010) graph algebras for bigraphs an important operation about (bi)graphs, is the tensor product. intuitively, the tensor product puts “side by side” two bigraphs, given g : 〈m, (~x ), x〉→〈n, (~y ),y〉 and h : 〈m′, (~x′), x′〉→ 〈n′, (~y ′),y ′〉, their tensor product is a bigraph g⊗h : 〈m+m′, (~x~x′), x∪x′〉→〈n+n′, (~y~y ′),y ∪ y ′〉 defined when global names in x , x′ and y,y ′ are disjoint. two useful variants of tensor product can be defined using tensor and composition: the parallel product ‖, which merges shared names between two bigraphs, and the prime product |, that also merges all roots in a single one. as shown in [mil04, db06], all bigraphs can be constructed by composition and tensor product from a set of elementary bigraphs: • 1 : 〈0, ( /0), /0〉→〈1, ( /0), /0〉 is the barren (i.e., empty) root; • mergen : 〈n, ( /0), /0〉→〈1, ( /0), /0〉 merges n roots into a single one; • γm,n,(~x ,~y ) : 〈m + n, (~x~y ), ( ⋃ ~x )∪(⋃~y )〉→〈m + n, (~y ~x ), (⋃~x )∪(⋃~y )〉 permutes the first m roots having local names in ~x with the following n roots with local names in ~y . • /x : 〈0, ( /0),{x}〉→〈0, ( /0), /0〉 is a closure, that is it maps x to an edge; • y/x : 〈0, ( /0), x〉→〈0, ( /0),{y}〉 substitutes the names in x with y, i.e., it maps the whole set x to y; as a shortcuts, we write ~y/~x to mean y0/x0 ⊗. . .⊗yn−1/xn−1; • px q : 〈1, (x ), x〉→〈1, ( /0), x〉 means that names in x are switched from local to global • conversely, (x ) : 〈1, ( /0), x〉→〈1, (x ), x〉 localizes the global names of x . • finally, k ~x(~x ) : 〈1, (x ), /0〉→〈1, ( /0),~x〉 is a control which may contain other graphs, and it has free ports linked to the name in ~x, whilst the names ~x are connected to its binding ports. we use the convention that local names are enclosed in parenthesises. bigraphs can be given always in discrete normal form: the idea of this normal form is to separate wirings (i.e., linkings) from discrete bigraphs (i.e., nesting of nodes). the following is an easy generalization of [db06, theorem 1] to the case of bigraphs with multiply located names. theorem 1 (discrete normal form (dnf)) 1. any binding bigraph g : i →〈n,~yb, ( ⋃ ~yb)]yf〉 can be expressed as g = (⊗ i t [a] where f is the operator symbol (possibly with mixfix notation where argument placeholders are denoted with underscores), tl is a (possibly empty, blank separated) list of domain sorts, t is the sort of the co-domain, and a is a set of equational attributes (e.g. associativity, commutativity). we shall present a signature σ containing sorts and operators for describing models as collections of attributed, interrelated objects (i.e. attributed graphs). proc. gtvmt 2011 4 / 14 eceasst equations that cannot be declared as equational attributes must be treated as functions defined by a set of confluent and terminating (possibly conditional) equations of the form ceq t = t’ if c, where t, t’ are σ-terms, and c is an application condition. when the application condition is vacuous, the simpler syntax eq t = t’ can be used. roughly, an equational rule can be applied to a term t’’ if we find a match for t at some place in t’’ such that c holds (after the application of the substitution induced by the match). the effect is that of substituting the matched part with t’ (after the application of the substitution induced by the match). one major advantage of maude is that it includes tools for checking confluence, termination and completeness of equational logic specifications. the main equations of the theories we use allow us to treat object collections as multisets of objects, i.e. modulo associativity, commutativity, and identity (all treated as equational attributes), therefore axiomatising their graph-theoretic nature. a membership predicate is of the form cmb t : t if c, where t is a σ-term of some supersort t’ of t and c is a predicate over t conditioning the membership statement. roughly, a membership predicate states that if we are able to match a term t’ with t such that c holds then t’ has sort t. membership predicates provide a subtyping mechanism that we can use, for instance, to check conformance wrt. to certain meta-model (e.g. typegraph). rewrite rules are of the form crl t => t’ if c, where t, t’ are σ-terms, and c is an application condition (a predicate on the terms involved in the rewrite, further rewrites whose result can be reused, membership predicates, etc.). when the application condition is vacuous, the simpler syntax rl t => t’ can be used. matching and rule application are similar to the case of equations with the main difference being that rules are not required to be confluent and terminating (as they represent possibly non-deterministic concurrent actions). equational simplification has precedence over rule application in order to simulate rule application modulo equational equivalence. rewrite rules can be used to program the behaviour of a system in a declarative way (e.g. in graph transformation style). graphs as object collections we summarize the previously mentioned algebra of object collections that is used to represent models as attributed graphs. in our setting a system configuration is a collection of attributed objects. maude already provides a signature for this purpose, called object-based signature [cde+07], which we tend to follow with slight modifications aimed to ease the presentation. each object represents an entity (an individual component) and its properties. technically, an object is defined by its identifier (of sort oid), it’s class (of sort cid) and its attributes (of sort attset). objects are built with an operation < : | > with functional type oid cid attset -> obj. object and class identifiers will be defined by ad-hoc constructors. for instance in our running example we use the operation m : nat -> oid to use natural numbers to construct object identifiers for male individuals like m(1) or m(2), and the constants male, female and message of sort cid to denote the classes of men, women and messages, respectively. the attributes of an object define its properties and relations to other objects. they are basically of two kinds: datatype attributes and relation attributes. datatype attributes take the form n: v, where n is the attribute name and v is the attribute value. for instance, in our running example we shall consider an attribute status with domain in {single,waiting,married} (constants of sort status), representing respectively whether a person is single, is waiting for a response or is married. similarly, we will consider an attribute 5 / 14 volume 41 (2011) towards a maude tool for model checking temporal graph properties figure 3: a graphical representation of a state. body with domain in {proposal,divorce,accept,refuse} (sort messagebody) for denoting respectively whether a message notifies a marriage proposal, a divorce or the acceptance or the refusal of a marriage proposal. as an example of an attributed object, consider figures 1 and 3, whose format is reminiscent of the uml notation, with rounded boxes representing objects where the top frame contains the object identifier and its class, and the bottom frame is reserved for datatype attributes. focusing only on the datatype kind of attributes, the man m(1) on the top-left of figure 3 is denoted in maude syntax with < m(1) : male | status: waiting >. in a configuration, objects are interrelated. relations between objects can be represented in different ways. a very intuitive approach is to use a reference (a term of sort oid) as value of an attribute. so if an object o1 has a relation r with object o2, then o1 will be equipped with an attribute r containing o2 in its value. consider objects of class message, they have a sender and a receiver. the message msg(1) of figure 3 is a marriage proposal sent from the man m(1) for the woman f(1). the message is hence denoted as < msg(1) : message | body: proposal , from: m(1) , for: f(1) >. note that each relation is graphically denoted in figure 3 with an arrow labelled with the name of the relation, which goes from the referring object to referred one. even more complex relations can be graphically denoted in the same intuitive way. for example we represent the rankings of males and of females with an arrow labeled with the position of the referred man (woman) in the ranking of the referring woman (man). an arrow with label n from a woman f(i) to a man m(j) hence indicates that m(j) is in the n-th position of the ranking of f(i). a configuration can thus be thought of as a multi-sorted graph with attributes, where nodes correspond to objects, node attributes correspond to datatype attributes and labeled edges correspond to reference attributes. an object can be equipped with any number of attributes. actually, the attributes of an object form a set built out of singleton attributes, the empty set (none) and union set (denoted with , ). object configurations are essentially sets of objects. the sort for configurations is called conf and its constructors are the empty configuration (none), singleton objects (as obj is declared as subsort of conf) and set union (denoted with juxtaposition). as an example the whole configuration of figure 3 is denoted with < msg(1) : message | body: proposal , from: m(1) , for: f(1) > < f(1) : female | status: single , ranking: (m(1) |-> 1 , m(2) |-> 2) > < f(2) : female | status: married , ranking: (m(1) |-> 2 , m(2) |-> 1) , marriedwith: m(2) > proc. gtvmt 2011 6 / 14 eceasst < m(1) : male | status: waiting , ranking: (f(1) |-> 1 , f(2) |-> 2) > < m(2) : male | status: married , ranking: (f(1) |-> 2 , f(2) |-> 1) , marriedwith: f(2) > in order to distinguish a system configuration from the collection of objects that forms it, we wrap object collections together into a system with operation << >> : conf -> system. graph rewrite rules to compositionally specify concurrent systems, we offer an object oriented language, based on an implementation of the double pushout approach (dpo) to graph rewriting: our systems can be hence seen as graph transformation systems specified by an initial state and a set of term rewrite rules given in dpo style. the main idea is that each rule has a left-hand side and a right-hand side pattern, each one composed by a set of objects (nodes) possibly interrelated by means of relation attributes (edges). in our tool we implement a two-level rule scheme: at the lowest level we have a set of local rules specific for every system, while at the top level we have a uniquely defined global rule that takes care of local rule application at the global level. a local rule can be applied to a model whenever the left-hand side can be matched with part of the model, i.e. each object in the left-hand side is (injectively) identified with an object of the model respecting its relations. the global rule can be applied to a model whenever a local rule can be applied to part of the model and some additional application conditions hold, including the no dangling edges condition typical of graph transformation flavours like dpo. the choice of dpo is arbitrary and not a restriction, as we could also mimick other styles by changing the rule format, e.g. following spo as in [bhm09]. following our counterpart approach to the semantics of second-order µ -calculus proposed in [glv10], we do not implicitly identify elements of different systems, meaning that we do not have an implicit unique domain of objects, instead we enrich the rules with a partial morphism relating the objects matching the left-hand side pattern with the objects matching the right-hand side pattern. this morphism amounts to the trace morphism in graph rewriting and is used to intuitively express the preservation/renaming, deletion or fusion of objects, respectively if an object is mapped, it is not mapped, or more objects are mapped in the same one. an object appearing in the right-hand side pattern but not involved in the morphism is considered as a newly created one. considering our running example, the sending of marriage proposals is formalized by the local rule: crl [makeproposal] : < idm : male | status: single , ranking: (idf |-> nt , rankm) , nexttry: nt , problemsize: size > < idf : female | attset1 > => {morphism}( < idm : male | status: waiting , ranking: (idf |-> nt , rankm) , nexttry: (s(nt) rem size) , problemsize: size > < idf : female | attset1 > < {new(0)} : message | body: proposal , from: idm , for: idf > ) if morphism := (idm |-> idm , idf |-> idf) . in this simple rule, a single man sends a marriage proposal to the “next most preferred woman”. the status and the nexttry counter of the involved man are hence updated, and a new object of 7 / 14 volume 41 (2011) towards a maude tool for model checking temporal graph properties figure 4: a graphical representation for the rule “makeproposal”. class message is created. the morphism also tells us that the man and the woman are preserved. the rule is intuitively graphically represented in figure 4. the global rule is instead defined as: crl [global] : << conf remconf >> => {extmorphism} << conf3 conf4 >> if conf => {morphism} conf3 /\ nodanglingedges(morphism , conf , remconf) /\ extmorphism := extend(morphism,remconf) /\ conf4 := applytoconfiguration(extmorphism , remconf) . the global rule rewrites a system composed by the configurations conf and remconf into a system composed by the configurations conf3 and conf4, correlating the two systems by the morphism extmorphism if 1) conf can be rewritten by a local rule in {morphism}conf3; 2) morphism does not delete objects of conf referred by objects in remconf (generating dangling edges); and 3) conf4 is obtained applying extmorphism to remconf, where extmorphism is the extension of morphism with the identities in remconf. in other words, the global rule implements the pushout computation. object creation is allowed and the consequent state explosion problem is partly mitigated by using name reuse, one of the more characterizing features approach, which allow us to deal with size bounded systems in case of systems with bounded resource allocation. 4 counterpart semantics for a second-order µ -calculus many logics have been proposed to reason about the evolution of systems. in [glv10] we introduced our own contribution with a novel semantics for a second-order µ -calculus based on the counterpart theory proposed by lewis and further developed in [haz79]. our proposal allows for a simple definition of the semantical universe by means of counterpart models, namely kripke models enriched with partial homomorphisms between connected worlds, called counterpart relations. figure 5 denotes with dotted lines the counterpart relation between the states s1 (top-right) and s2 (bottom-right) of figure 2. intuitively, everything is preserved except for the message m(1) which is thus deleted and recreated evolving from state s1 to state s2. the two messages are not related: they share the same name, but represent two distinct components. it is important to notice that in the counterpart approach, the identifiers are local to the worlds they belong to. in different worlds, the same identifier may represent distinct elements. proc. gtvmt 2011 8 / 14 eceasst figure 5: a graphical representation of the counterpart relation between two states. standard kripke models identify elements through different worlds (trans-world identity), with implicitly defined identity morphisms, having as result a unique domain for the elements of the worlds. the presence of the unique domain, which is indeed just a technical solution, enforces restrictions of the evolution of states, making it difficult, or even forbidding to express merging, renaming, creation and deletion of elements. enriching our models with the counterpart relations we avoid these limitations. for example, two elements are merged if they are mapped in the same element, while an element is a newly created one if it appears in the target state, but it is not involved in the counterpart function. in this manner counterpart models are well suited for modeling systems with dynamic structure. moreover, since our semantics evaluates formulae with variables as sets of variable assignments for each world, instead of just worlds as in propositional logics and some non-propositional ones, it allows for a straightforward interpretation of fixed points and for their smooth integration with the evaluation of quantifiers, which are often dealt with by restricting the class of admissible models to those with no name reuse or merging. the resulting semantics is a streamlined and intuitively appealing one, yet it is general enough to cover most of the alternative proposals we are aware of . now we briefly recall the syntax and semantics of our logic. definition 1 (formulae) let σ be a signature (e.g. a signature for graphs), z a set of fix-point variables, and x , x (denumerable) sets of firstand second-order variables typed over σ (e.g. node and node set variables). the set fς of formulae of our logic is inductively generated by: ψ ::= tt | ε : τ ∈τ χτ | ¬ψ | ψ ∨ ψ | ∃xτ .ψ | ∃χτ .ψ | ♦ψ | z | µ z.ψ where ε : τ is a term over σx of type τ , ∈τ is a family of membership predicates typed over sς indicating that (the evaluation of) a term with sort τ belongs to (the evaluation of) a second-order variable with the same sort τ , and µ denotes the least fixed point operator. we shall also derive the symbols ∧ ,→ , ↔ , ∀, as well as well-known temporal operators like � (all next steps), ag or af (for all departing paths, always or eventually), and the greatest fix-point operator ν derived as ν z.ψ ≡ ¬µ z.¬ψ[¬z/z], where ψ[¬z/z] stands for ψ where all occurrences of z have been negated. moreover, as it is standard, we restrict to monotonic formulae, i.e. such that each fix-point variable z occurs under the scope of an even number of negations. this is a sufficient condition for the fixed points to be well-defined. note that the logic is simple, yet 9 / 14 volume 41 (2011) towards a maude tool for model checking temporal graph properties reasonably expressive. for instance, binary equivalence can also be defined as a derived operator, namely, ε1 : τ =τ ε2 : τ is defined as ∀χτ . (ε1 : τ ∈τ χτ ↔ ε2 : τ ∈τ χτ ). our semantics does not evaluate naked formulae, but formulae in context, that is formulae enriched with informations about the free variables appearing in them. the context of a formula has two components: γ and ∆ containing respectively firstand second-order variables. reminiscent of the semantics of temporal formulae over sets of constraints introduced in [ghk00], the evaluation of a formula with context [γ; ∆] consists in a set of pairs (σw,w) where the domain of σw, a variable assignment for the world w, is defined exactly for the variables in [γ; ∆]. we indicate with ω[γ;∆] the set of all the pairs of a model with assignments defined exactly for [γ; ∆]. the evaluation of a formula with empty context is hence just a set { (λ ,w) } ⊆ ω[/0; /0], for λ the empty variable assignment over the world w. such an evaluation characterises a set of worlds, ensuring that our proposal properly extends the standard semantics of propositional modal logics. the formulae of our logic are evaluated against counterpart models, which can be intuitively thought of as the graph transition system obtained by unfolding a graph transformation system. intuitively, a counterpart model contains the informations graphically encoded both in figure 2, and in figure 5. thus a counterpart model contains informations about the states of the system and their internal structure, and informations about the accessibility relation between the states, annotating explicitly the mappings between components of the distinct but connected states. definition 2 (semantics) let ψ[γ; ∆] be a formula-in-context (e.g stating some properties about the evolution of a graph), and m be a counterpart model (e.g. the state transition graph obtained by unfolding a graph transformation system). the evaluation of ψ[γ; ∆] in m under the assignment ρ : z → 2ω [γ;∆] is given by the function j·kρ : f [γ;∆] → ω[γ;∆] defined as jtt[γ; ∆]kρ = ω[γ;∆] j(ε : τ ∈τ χτ )[γ; ∆]kρ = {(σ,w) ∈ ω[γ;∆] | σ(ε) ∈ σ(χτ )} j¬ψ[γ; ∆]kρ = ω[γ;∆] \ jψ[γ; ∆]kρ jψ1 ∨ ψ2[γ; ∆]kρ = jψ1[γ; ∆]kρ ∪ jψ2[γ; ∆]kρ j∃xτ . ψ[γ; ∆]kρ = 2↓xτ (jψ[γ,xτ ; ∆]k(2↑x ◦ρ)) j∃χτ . ψ[γ; ∆]kρ = 2↓χτ (jψ[γ; ∆, χτ ]k(2↑χ ◦ρ)) j♦ψ[γ; ∆]kρ = {(σ,w) ∈ ω[γ;∆] | ∃(σ ′,w′) ∈ jψ[γ; ∆]kρ . σ [γ;∆] σ ′} jz[γ; ∆]kρ = ρ(z) jµ z.ψ[γ; ∆]kρ = lfp(λy.jψ[γ; ∆]kρ [y /z]) note that in the evaluation of the membership predicate, σ(ε) denotes the lifting of the substitution σ to the set of terms over σx . in the evaluation of the quantifiers, we make use of the functions 2↑x,2↑χ , 2↓x,2↓χ to respectively extend or restrict sets of pairs with the variable x or χ . restricting a subset of ω[γ,x;∆] respect to a variable x we obtain a subset of ω[γ;∆]. specularly, extending a subset of ω[γ;∆] with a variable x we obtain a subset of ω[γ,x;∆]. it is pivotal to require that the assignment ρ for fix-point variables is extended to ensure a proper sorting of ρ(z), since it must now belong to the subsets of ω[γ,x;∆] (ω[γ;∆,χ] in the second-order case). in the evaluation of the modal operator, the “renaming” of values across worlds is ensured by requiring that the assignments σ and σ ′ are in counterpart relation, meaning intuitively that σ ′ respects σ for the variables in [γ; ∆]. hence all elements of w assigned by σ to the variables in [γ; ∆] are mapped in w′ by the counterpart relation, respecting the operations on them. thus, our semantics discards those worlds that are reachable but are not in counterpart with respect to the current context to proc. gtvmt 2011 10 / 14 eceasst avoid claims about non-existing elements (see [glv10] for a detailed explanation). 5 counterpart model generation and model checking our tool represents the first step towards a framework supporting our approach for the semantics of second-order µ -calculi introduced in [glv10]. we developed it aiming at assessing the feasibility of our approach providing a direct instantiation of it, leaving for future works concerns about efficiency and usability. given that the formulae of our logic have to be checked against counterpart models, we first focused on their generation, and then we developed a model checker working on counterpart models. counterpart model generation counterpart models, as the well-known kripke models, are defined by a triple (w, d, rc) where, w is a set of worlds, d is a function assigning a set of interrelated objects (a configuration) to each world in w, and rc is the accessibility relation between worlds. respect to kripke models, accessibility relations in counterpart models are equipped with partial homomorphisms, explicitly correlating elements of connected worlds. an entry of rc has the form of w(i) =morphism=> w(j) . the procedure starts from a counterpart model containing only a world associated to an initial state and the empty accessibility relation. then it keeps adding states and entries of the accessibility relation to the model up to completion of the state space. in particular, only two cases can arise after the generation of a state: the state is not already in the model, in which case a new world, the state and an accessibility relation entry are added to the model, or, in the second case, the state is already in the model, thus only the accessibility relation entry is added, if not already present. these two cases are captured by the following conditional rules: crl (( w (d,(wsource |-> ssource)) rc)) => (( (newworld,w ) *** w (d,(wsource |-> ssource), (newworld |-> sdest)) *** d (rc, wsource =morphism=> newworld) )) *** rc if ssource => {morphism}sdest /\ systemnotind(sdest , (d,(wsource |-> ssource))) . crl ( (w ((wsource |-> ssource), (wdest |-> sdest) , d) rc) ) => ( ( w *** w ((wsource |-> ssource) , (wdest |-> sdest) , d) *** d ( wsource = morphism => wdest , rc) )) *** rc if ssource => {morphism}sdest /\ notconnected(wsource, morphism, wdest, rc) . it is worth to note that, the identification of syntactically identical states (equal graphs) is based on the reuse of object identifiers which allows us to obtain finite counterpart models in systems with bounded resource allocation. this happens, for instance in our example where the number of objects around is always bounded by a constant due to the message consumption and generation strategies. more powerful strategies based, e.g. on identifying symmetric states (isomorphic graphs) are under study. considering our running example, the counterpart model is built with the command rew initializectmodel(<< initsmp(n) >>), where initsmp(n) generates an initial state with n 11 / 14 volume 41 (2011) towards a maude tool for model checking temporal graph properties males (and females), and initializectmodel generates the counterpart model containing only the initial state. model checking given a counterpart model m and an assignment for fix-point variables, our tool evaluates the semantics of a second order µ -calculus formula as the set of pairs (σw,w) satisfying it, where w is a world of m, and σw a variable assignment for w defined exactly for the variables in the context of the formula. in doing so we first defined the operation op valid taking as arguments a formula in context, a pair, a fix-point variable assignment and a counterpart model. the operation reduces to true if the pair validates the formula in context, false otherwise. finally, we evaluate the semantics of a formula in context with the operation op [| |] , taking as arguments a formula in context, an initial state of the system (from which the counterpart model will be built), and an assignment for fix-point variables. considering [γ; ∆] as context of the formula, the operation generates all the pairs in the set ω[γ;∆], and adds to the semantics of the formula only the ones for which valid is true. 6 examples the aim of this section is to illustrate the use of the tool to verify properties of the evolution of software systems, focusing on properties of individuals. for the rest of this section we fix an instance of our running example with n = 2, where all the people of the same gender have the same ranking. individual response property. in the algorithm sketched in section 2, people get married and divorced with the aim of finding particular marriages. an interesting property is the one stating that every time a male becomes single, he will later on become married. more formally, the property can be expressed as “for all male, whenever the male is single, it eventually becomes married”. we can express the property with the formula ψ forall xmale(0). ag((status(xmale(0)) = status: single) -> (af(status(xmale(0)) = status: married))) using the reduce command of maude, we evaluate the semantics of ψ with reduce [|ψ|] <> , empty. as result we obtain a set of pairs (λ ,w(i)) for all w(i) ∈ w , where λ is the empty assignment. this tells us that the property holds in every state of the model. individual mutual exclusion. other interesting properties regard the consistency of marriages. a meaningful example is “is it possible for two males to claim to be married with the same female?”, expressed by the formula not(xmale(0) = xmale(1)) and (marriedwith(xmale(0)) = marriedwith(xmale(1))) evaluating the property we find out that it holds in a world of the model, with the following assignment: xmale(0) |-> < {m(2)} : male | marriedwith: {f(1)}, ... > xmale(1) |-> < {m(1)} : male | marriedwith: {f(1)}, ... > proc. gtvmt 2011 12 / 14 eceasst this can seem an erroneous scenario, but actually it happens because of the asynchronous and distributed fashion of the modelled algorithm: when a married woman accepts a new marriage proposal, she sends a divorce notification to the former partner and an accept notification to the new partner. in the case in which the accept notification is handled before the divorce one we have two males claiming to be married with the same woman. the consistency is restored at the next step, after the handling of the divorce notification. different is the case in which we check the same property, but from the females perspective, just substituting xmale with xfemale. evaluating the formula we obtain the empty set, meaning that it never happens in the model that two females claim to be married with the same male. 7 conclusions and further works quantified modal logics have been studied in the realm of description logics (e.g. [ft03]), graph transformation (e.g. [bckl07]), process algebras (e.g. [cai04]) and model checking ([ren06]) to cite a few. for a more comprehensive and detailed list we refer to [glv10], where we also describe the differences with respect to our approach. here we just mention that, as far as we know, graph transformation tools are not yet equipped with model checking capabilities for temporal logic other than propositional ones. amongst them groove1 and augur2 seem the most promising one, since their authors have already produced interesting contributions to the theoretical foundations of model checking systems with dynamic structure using quantified temporal logics [ren06, ren03, dkr04, bckl07]. the present paper introduces our prototypical tool to verify temporal graph properties, expressed in a quantified temporal logic. our tool is based in the semantics for second-order µ calculus we introduced in [glv10], which with respect to other approaches, allows for a simple definition of the semantical universe by means of counterpart models. the idea of associating to (open) formulae sets of assignments, instead of just worlds, allows for a straightforward interpretation of fixed points and for their smooth integration with the evaluation of quantifiers. our tool provides an instantiation of our approach, where formulae of our logic are checked against system specifications described in a graph-based dialect of maude. in particular, we use a very popular maude (sub)language for describing systems in a declarative, object-based style which essentially corresponds to graph rewriting. such specifications can be analysed with maude tools as usual, using for instance the critical pair analysis based confluence checker, the reachability analyzer or the propositional ltl model checker. our implementation provides a finer model checker for formulae in a second-order µ -calculus that allows to express more subtle properties like individual mutual exclusion or individual request-response. in its current form, the model checker generates the entire counterpart model for a given specification and checks formulae on it. that is, our model checker does not yet verify properties on-the-fly, neither it does apply optimisation techniques based on symmetry or abstraction reduction. these issues are subject of current work as they could push our approach beyond its current bounded model checking form. 1 http://groove.cs.utwente.nl/ 2 http://www.ti.inf.uni-due.de/research/augur/ 13 / 14 volume 41 (2011) towards a maude tool for model checking temporal graph properties bibliography [bckl07] p. baldan, a. corradini, b. könig, a. lluch lafuente. a temporal graph logic for verification of graph transformation systems. in fiadeiro and schobbens (eds.), 18th international workshop on recent trends in algebraic development techniques (wadt’06). lncs 4409, pp. 1–20. springer, 2007. [bhm09] a. boronat, r. heckel, j. meseguer. rewriting logic semantics and verification of model transformations. in proceedings of the international conference on fundamental aspects of software engineering (fase’09). lncs 5503. springer, 2009. [cai04] l. caires. behavioral and spatial observations in a logic for the π -calculus. in walukiewicz (ed.), 7th international conference on foundations of software science and computation structures (fossacs’04). lncs 2987. springer, 2004. [cde+07] m. clavel, f. durán, s. eker, p. lincoln, n. martı́-oliet, j. meseguer, c. l. talcott. all about maude. lncs 4350. springer, 2007. [dkr04] d. distefano, j.-p. katoen, a. rensink. who is pointing when to whom? in al. (ed.), 32nd international conference on foundations of software technology and theoretical computer science (fsttcs’04). lncs 3328. springer, 2004. [ft03] e. franconi, d. toman. fixpoint extensions of temporal description logics. in calvanese et al. (eds.), 16th international workshop on description logics (dl’03). ceur workshop proceedings 81. ceur-ws.org, 2003. [ghk00] f. gadducci, r. heckel, m. koch. a fully abstract model for graph-interpreted temporal logic. in ehrig et al. (eds.), 6th international workshop on theory and application of graph transformations (tagt’98). lncs 1764. springer, 2000. [gi89] d. gusfield, r. w. irving. the stable marriage problem: structure and algorithms. mit press, cambridge, ma, usa, 1989. [glv10] f. gadducci, a. lluch lafuente, a. vandin. counterpart semantics for a secondorder µ -calculus. in ehrig et al. (eds.), 5th international conference on graph transformation (icgt’10). lncs 6372, pp. 282–297. springer, 2010. [haz79] a. hazen. counterpart-theoretic semantics for modal logic. the journal of philosophy 76(6):pp. 319–338, 1979. [ren03] a. rensink. towards model checking graph grammars. in leuschel et al. (eds.), 3rd workshop on automated verification of critical systems. university of southampton technical reports dsse–tr–2003–2, pp. 150–160. 2003. [ren06] a. rensink. model checking quantified computation tree logic. in baier and hermanns (eds.), 17th international conference on concurrency theory (concur’06). lncs 4137, pp. 110–125. springer, 2006. proc. gtvmt 2011 14 / 14 introduction running example graph rewriting with maude counterpart semantics for a second-order -calculus counterpart model generation and model checking examples conclusions and further works verifying total correctness of graph programs electronic communications of the easst volume 61 (2013) selected revised papers from the 4th international workshop on graph computation models (gcm 2012) verifying total correctness of graph programs christopher m. poskitt and detlef plump 20 pages guest editors: rachid echahed, annegret habel, mohamed mosbah managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst verifying total correctness of graph programs christopher m. poskitt1 and detlef plump2 1 eth zürich, switzerland 2 the university of york, uk abstract: gp 2 is an experimental nondeterministic programming language based on graph transformation rules, allowing for visual programming and the solving of graph problems at a high-level of abstraction. in previous work we demonstrated how to verify graph programs using a hoare-style proof calculus, but only partial correctness was considered. in this paper, we add new proof rules and termination functions, which allow for proofs to additionally guarantee that program executions always terminate (weak total correctness), or that programs always terminate and do so without failure (total correctness). we show that the new proof rules are sound with respect to the operational semantics of gp 2, complete for termination, and demonstrate their use on some example programs. keywords: graph programs, verification, hoare logic, total correctness, termination 1 introduction the verification of graph transformation systems is an area of active and growing interest, motivated by the many applications of graph transformation to specification and programming. whilst much of the research in this area has focused on sets of rules or graph grammars (see e.g. [bck08, bhe09, ke10, cr12]), the challenge of verifying graph-based programming languages is also beginning to be addressed. in particular, habel, pennemann, and rensink [hpr06, hp09] contributed a verification framework – based on weakest preconditions – for a simple graph transformation language, expressing graph properties with nested conditions (a formalism based on graph morphisms). their language however does not support important practical features such as computation on labels, and their weakest precondition calculus generates infinite preconditions for loops. in [pp12a] we considered the verification of gp [plu09], a nondeterministic programming language based on graph transformation. the states are directed labelled graphs, which are manipulated via the application of (conditional) rule schemata. these generalise double-pushout rules with relabelling and expressions. the verification framework of the paper is a hoare calculus for partial correctness, with which one can prove that programs executed on graphs satisfying given preconditions will only ever result in graphs satisfying given postconditions. however, the calculus cannot be used to prove that such programs do eventually terminate, and cannot be used to prove the absence of failing executions. addressing these two issues is the focus of this paper. we define two notions of total correctness: a weaker one accounting for termination, and a stronger one accounting for termination as well as for absence of failures. we define two calculi for these notions of total correctness, using termination functions (that map graphs to natural 1 / 20 volume 61 (2013) verifying total correctness of graph programs numbers) in the new proof rule for the iteration command. we demonstrate the proof calculi on programs that have loops and potential failure points, before proving the calculi to be sound as well as complete for termination. in contrast to our previous papers, we present the work here in the setting of gp 2 [plu12] (henceforth referred to as simply gp). this extended version of the language has an improved type system, a marking (shading) mechanism for nodes and edges, a new conditional construct, and a simplified semantics for branching and iteration to support a more efficient implementation. our previous verification work has been updated in [pos13] to support these new features, but due to space limitations we cannot present all of the revised definitions here. we attempt to make the intuition behind each concept clear, but refer the interested reader to [pos13] for the full technical details and further explanations. section 2 reviews some technical preliminaries. section 3 is an informal introduction to graph programs. section 4 reviews our assertion language and the partial correctness proof rules of our previous calculus. section 5 formalises the notion of (weak) total correctness and presents new proof rules which allow one to prove these properties. section 6 demonstrates the use of the new calculi on some example programs. section 7 presents a proof that the new calculi are sound for (weak) total correctness, and also a proof that the calculi are complete for termination. finally, we conclude in section 8. this paper is a revised and extended version of [pp12b]. 2 preliminaries graph transformation in gp is based on the double-pushout (dpo) approach with relabelling [hp02], i.e. an approach in which both node and edge labels can be relabelled. this framework deals with rules containing partially labelled graphs, the definition of which we recall below. in this section we treat the label alphabet as a parameter because we will require two different alphabets for two classes of graphs: “syntactic” graphs labelled with expressions, and “semantic” graphs labelled with lists composed of integers and strings. we also introduce assignments which translate syntactic graphs into semantic graphs. a graph over a label alphabet c is a system g = (vg,eg,sg,tg,lg,mg), where vg and eg are finite sets of nodes (or vertices) and edges, sg,tg : eg → vg are the source and target functions for edges, lg : vg → c is the partial 1 node labelling function and mg : eg → c is the (total) edge labelling function (edges can be relabelled by deletion and re-insertion, hence unlabelled edges are not necessary). given a node v, we write lg(v) = ⊥ to express that lg(v) is undefined. graph g is totally labelled if lg is a total function. we write g (c ) for the set of all totally labelled graphs over c , and g (c⊥) for the set of all graphs over c . the empty graph, denoted by /0, has empty node and edge sets. a graph morphism g : g → h between graphs g,h in g (c⊥) consists of two functions gv : vg → vh and ge : eg → eh that preserve sources, targets and labels; that is, sh ◦ ge = gv ◦ sg, th ◦ ge = gv ◦ tg, mh ◦ ge = mg, and lh(g(v)) = lg(v) for all v such that lg(v) 6= ⊥. morphism g is an inclusion if g(x) = x for all nodes and edges x. it is injective (surjective) if gv and ge are injective (surjective). it is an isomorphism if it is injective, surjective, and satisfies 1 unlabelled nodes appear in the interfaces of rule schemata to allow relabelling, see [pp12a, pos13]. selected revised papers from gcm 2012 2 / 20 eceasst lh(gv (v)) = ⊥ for all nodes v with lg(v) = ⊥. in this case g and h are isomorphic, which is denoted by g ∼= h. we consider graphs over two distinct label alphabets. graph programs and our assertion language contain graphs labelled with expressions, while the graphs on which programs operate are labelled with lists composed of integers and character strings. in both cases nodes and edges can be marked; marked nodes are displayed as shaded, and marked edges are displayed as dashed (see figure 2). we consider graphs of the first type as syntactic objects and graphs of the second type as semantic objects, and aim to clearly separate these levels of syntax and semantics. let z denote the set of integers and char a finite set of characters. we fix the label alphabet: l = (z∪ char∗)∗ ×b where b = {true,false}, i.e. all sequences over integers and character strings, along with a boolean value indicating whether the node or edge is marked or not. occasionally we will refer only to the list component (z∪ char∗)∗, which shall be denoted by l. the other label alphabet we are using, label, consists of a mark component and (colon delimited) sequences of arithmetical expressions and strings. these may contain variables from a set denoted by varid. variables represent values in l, i.e. lists, and can be constrained in rule schemata to represent integers, strings, or atoms (an integer or a string). these types correspond to the semantic domains in figure 1, in which we identify atoms and unit-length lists to establish a subtype hierarchy. list atom int string ⊆ ⊆ ⊇ (z∪ char∗)∗ z∪ char∗ z char∗ ⊆ ⊆ ⊇ figure 1: subtype hierarchy for lists we write g (label) to denote the set of all graphs labelled over label (grammars defining the label alphabet are given in [plu12, pos13]). examples of list components of labels in g (label) include x*5 and ”root” : y (the variable x may only be instantiated to integers, whereas y be instantiated to any value in l, unless otherwise constrained). each graph in g (label) represents a possibly infinite set of graphs in g (l ). the latter are obtained by instantiating variables with values from l and evaluating expressions. an assignment is a partial function α : varid → l. for a rule schema (see the next section), α must satisfy for all variables x with type int (resp. string, atom, list), α(x) ∈ z (resp. char∗, z∪ char∗, l). for assertions (see section 4), we require that α is well-typed for the expressions to which it is applied, i.e. it assigns values to variables of types determined by their contexts. for example, a well-typed assignment for x+y:z (with + interpreted as addition) must map x,y to integers. 3 / 20 volume 61 (2013) verifying total correctness of graph programs given a (well-typed) assignment α and label (e b) with e a list and b ∈ b, we define (e b)α = (eα ,b) where the value eα ∈ l is inductively defined as follows. if e is the empty list, then eα is the empty sequence. if e is a numeral or a sequence of characters, then eα is the integer or character string represented by e. (note that the empty list and empty character string are distinct values.) if e is a variable identifier, then eα = α(e). for arithmetic and string expressions, eα is defined inductively in the usual way. finally, if e has the form e1 : e2 with e1,e2 list expressions, then eα = eα1 e α 2 (the concatenation of the sequences e α 1 and e α 2 ). given a graph g in g (label) and an assignment α well-typed for all expressions in g, we write gα for the graph in g (l ) that is obtained from g by replacing each label l with lα (note that gα has the same nodes, edges, source and target functions as g). if g : g → h is a graph morphism with g,h ∈ g (label), then gα denotes the morphism 〈gv ,ge〉: g α → h α . remark 1 in [plu12], variables belong to one of four distinct sets of variables – one set for each type – and assignments are families of mappings from the these sets to the appropriate semantic domains. we use a different definition in this paper, taking all variables to be members of the set varid, and interpreting type declarations in rule schemata as constraints on possible assignments. this definition allows us to treat variables in rule schemata and our assertion language more uniformly, simplifying the presentation of this paper. additionally, though gp 2 introduced indegree and outdegree functions in expressions, we do not consider them in this paper, as applicability properties of rule schemata that use them cannot be expressed by our assertion language. 3 graph programs we introduce graph programs informally and by example in this section. for technical details, further examples, and more discussion on the operational semantics, refer to [plu12]. the “building blocks” of graph programs are (conditional) rule schemata: a program is essentially a list of declarations of (conditional) rule schemata together with a command sequence for controlling their application. rule schemata generalise graph transformation rules, in that labels contain (sequences of) expressions and relabelling is supported. expressions may contain variables, which in rule schemata are associated with types integer, string, atom, or list, constraining the possible mappings for assignments. conditional rule schemata further constrain assignments with a condition: one use is in requiring relations between expressions (e.g. x < y + z), but they can also be used to require (the absence of) edges between nodes in a match (e.g. not edge(1,2)). as the values of variables at execution are determined by graph matching, we require that expressions in the left graph have a simple shape: (1) expressions contain no arithmetic operators; (2) expressions contain at most one occurrence of a list variable; and (3) each string expression contains at most one occurrence of a string variable. in figure 2 we give an example of a conditional rule schema and a possible application of it. the first row of the diagram (in the box) contains the conditional rule schema. there is an identifier, here bridge, and a declaration of variables with their types. the leftand right-hand graphs describe the rule with the small numbers indicating which nodes correspond to each other. here, bridge is applied to a path of length two across nodes in which only the first is marked, and across unmarked string-labelled edges, provided that there is not already a direct edge from selected revised papers from gcm 2012 4 / 20 eceasst the first node to the third (as per the condition). the effect of applying bridge is to add a marked edge from the first node to the third, removing the mark from the former whilst adding a mark to the latter, and taking the composition of their list components for the new edge. the conditional rule schema describes an infinite number of “concrete” graph transformation rules with labels fitting the pattern described by the schema. the second row of the diagram shows one such rule, obtained by evaluating expressions according to the assignment: α = {a 7→ “ab”,b 7→ “bc”,x 7→ 0 : 1 : 2,y 7→ 3,z 7→ 4} which adheres to the constraints of the type declaration. the bottom row shows an application of bridge to a graph via the same assignment α and an injective morphism g. it is applied in the double-pushout approach with relabelling [hp02], which intuitively means that nodes can be relabelled in an arbitrary context (edges can simply be deleted and reinserted with the new labels), and that the application is side-effect free (i.e. it is forbidden to delete a node unless the rule schema explicitly deletes all edges it is incident to). bridge(a,b: string; x,y,z: list) x 1 y 2 z 3 a b ⇒ x 1 y 2 3 z 3 x : z a b where notedge(1, 3) 7→ α,g 7→ α,g 0:1:2 1 3 2 4 3 “ab” “bc” ⇒ 0:1:2 1 3 2 4 3 0:1:2:4 “ab” “bc” ↓ g ↓ 0:1:2 3 4 2 “ab” “bc” “cd”“da” ⇒ 0:1:2 3 4 2 0:1:2:4 “ab” “bc” “cd”“da” figure 2: a conditional rule schema and a possible application of it the application of a rule schema r to a graph g ∈ g (l ) that yields a graph isomorphic to 5 / 20 volume 61 (2013) verifying total correctness of graph programs h ∈ g (l ), denoted g ⇒r h, proceeds roughly as follows: 1. match the left graph l of r with a subgraph of g, ignoring labels, by means of a so-called premorphism g : l → g. (a premorphism is a graph morphism that does not need to preserve labels.) 2. check whether there is an assignment α of values to all the variables in r (adhering to the declared types) such that after evaluating the expressions in l, g is label-preserving. 3. if r is a conditional rule schema, check that the condition evaluates to true with respect to α and g (conditions are evaluated in the obvious way, with edge(m,n)α,g = true for node identifiers m,n if and only if there is an edge with source gv (m) and target gv (n)). 4. apply the rule rα (obtained from r by evaluating2 all expressions in the left and right graph) to g with match g via the double-pushout approach with relabelling. we also write g ⇒r h for a set of (conditional) rule schemata r if there is some r ∈ r such that g ⇒r h. declarations of (conditional) rule schemata are, in graph programs, applied according to a number of simple control constructs. gp provides non-deterministic choice, sequential composition, conditional constructs, and as-long-as-possible iteration. we demonstrate these informally with two example programs. the program colouring in figure 3 produces a colouring (assignment of integers to nodes such that adjacent nodes have different colours), provided that the input graph consists of unmarked items only, and the list components of nodes are atomic. colours are recorded as socalled tags, i.e. information stored in a label by extending the list component. the program initially colours each node with 0 by applying the rule schema init as long as possible, using the iteration operator ’!’. it then repeatedly increments the target colour of edges with the same colour at both ends. note that this process is nondeterministic: figure 3 shows two possible executions. the program reachable? in figure 4 checks whether or not there is a path from one distinguished node (tagged with 1) to another (tagged with 2), again provided that the input graph contains unmarked items only and the list components of nodes are atoms (except for the distinguished nodes). an execution of reachable? returns the original input graph if there exists such a path, otherwise it returns the same graph but with an additional edge linking the distinguished nodes. with propagate!, the program iteratively tags nodes with 0 that are reachable from the 1-tagged node. an if-then-else conditional is then encountered: if its “guard” reachable can be applied (to a copy of the graph), then skip is executed; otherwise addlink. the idea is as follows: if reachable can be applied, then there must be a tagged node adjacent to the second distinguished node, indicating the existence of a path. in this case, skip is applied which does not change the graph. if reachable cannot be applied, then there must not exist a path, and so addlink is applied to add an edge directly between the distinguished nodes. in both cases, the 0-tags used in the computation are removed by the iteration of undo. 2 the evaluation of full gp 2 expressions (with inand outdegree functions) depends on g as well as α . selected revised papers from gcm 2012 6 / 20 eceasst main = init!; inc! init(x: atom) inc(i: int; k: list; x,y: atom) 1 x ⇒ 1 x:0 x:i y:i 1 2 k ⇒ x:i y:i+1 1 2 k 3 3 33 3 3 33 ⇒+ 3:0 3:1 3:03:1 3 3 33 ⇒ + 3:0 3:1 3:23:1 3 3 33 figure 3: the program colouring and two of its executions the formal semantics of gp is given in the style of structural operational semantics. inference rules inductively define a small-step transition relation → on configurations. in our setting, a configuration is either a command sequence (comseq) together with a graph (i.e. an unfinished computation), just a graph, or the special element fail (representing a failure state). the meaning of graph programs is summarised by a semantic function j k, which assigns to every program p the function jpk mapping an input graph g to the set of all possible results of running p on g. the result set may contain, besides proper results in the form of graphs, the special values fail and ⊥. the value fail indicates a failed program run whilst ⊥ indicates a non-terminating or stuck computation. the semantic function j k : comseq → (g (l ) → 2g (l )∪{fail,⊥}) is defined by: jpkg = {x ∈ (g (l )∪{fail}) | 〈p, g〉 + →x}∪{⊥ | p can diverge or get stuck from g} where p can diverge from g if there is an infinite sequence 〈p, g〉 → 〈p1, g1〉 → 〈p2, g2〉 → ..., and p can get stuck from g if there is a terminal configuration 〈q, h〉 such that 〈p, g〉 →∗ 〈q, h〉 where the rest program q cannot be executed because no inference rule is applicable. a program can get stuck if it contains a non-terminating subprogram in a loop or in a conditional. figure 5 shows the inference rules of commands in gp 2. each rule consists of a premise and a conclusion separated by a horizontal bar. both parts contain meta-variables for command sequences and graphs, where r stands for a rule schema set call, c,p,p′,q stand for command sequences, and g,h stand for graphs in g (l ). meta-variables are considered to be universally quantified. the notation g 6⇒r expresses that for graph g in g (l ) there is no graph h such that g ⇒r h. derived commands such as skip can be expressed by semantically equivalent 7 / 20 volume 61 (2013) verifying total correctness of graph programs main = propagate!; (if reachable then skip else addlink); undo! propagate(a: list; x,z: atom; y: int) reachable(a: list; x,z: atom; y: int) x:y z 1 2 a ⇒ x:y z:0 1 2 a x:y z:2 1 2 a ⇒ x:y z:2 1 2 a where y=1 or y=0 addlink(x,y: atom) undo(x: atom) x:1 y:2 1 2 ⇒ x:1 y:2 1 2 1 x:0 ⇒ 1 x figure 4: the program reachable? programs made up of core commands only (in this case, the rule schema /0 ⇒ /0). we refer to [plu12] for details. 4 proving partial correctness in this section we first review e-conditions, the assertion language of our proof calculi. then, we review the partial correctness proof calculus presented in previous work (updated for gp 2, e.g. the new [try] proof rule). nested graph conditions with expressions (or e-conditions) are a morphism-based formalism for expressing both structural properties of graphs and properties about their labels. e-conditions [pp12a] extend the nested conditions of [hpr06] with expressions for labels and assignment constraints, which are simple boolean expressions used to restrict the instantiations of variables to values of particular types, or values that hold in particular relations. a simple example of an e-condition is: ¬∃( x | int(x)) which is satisfied by graphs that do not have any unmarked integer-labelled nodes. the formalism combines logical quantifiers with graph structure and constraints on labels: e-conditions demand the (non-)existence of particular subgraphs, subject to some constraint on the labels (the vertical bar can be read as “such that”). more generally, the formalism exploits nesting to allow universally quantified expressions. for example, ∀( x 1 | atom(x),∃( 1 x )∨∃( x 1 )) which expresses that every unmarked atom-labelled node is incident to a loop. here, the number selected revised papers from gcm 2012 8 / 20 eceasst [call1] g ⇒r h 〈r, g〉 → h [call2] g 6⇒r 〈r, g〉 → fail [seq1] 〈p, g〉 → 〈p′, h〉〈p; q, g〉 → 〈p′; q, h〉 [seq2] 〈p, g〉 → h 〈p; q, g〉 → 〈q, h〉 [seq3] 〈p, g〉 → fail 〈p; q, g〉 → fail [if1] 〈c, g〉 →+ h 〈if c then p else q, g〉 → 〈p, g〉 [if2] 〈c, g〉 →+ fail 〈if c then p else q, g〉 → 〈q, g〉 [try1] 〈c, g〉 →+ h 〈try c then p else q, g〉 → 〈p, h〉 [try2] 〈c, g〉 →+ fail 〈try c then p else q, g〉 → 〈q, g〉 [alap1] 〈p, g〉 →+ h 〈p!, g〉 → 〈p!, h〉 [alap2] 〈p, g〉 →+ fail 〈p!, g〉 → g figure 5: inference rules for core commands identifies the nodes as being the same; the nesting adds more detail about the required context of the particular subgraph. similarly to rule schemata, in checking whether a graph satisfies a property described by an e-condition, a suitable assignment α must be found for the label expressions and assignment constraint. note however that unlike in rule schemata, we are not declaring types for variables, but rather using predicates about types within assignment constraints. for example, we could write not int(x) as an assignment constraint, or even omit type predicates completely. due to space limitations we do not give a formal syntax or semantics of assignment constraints (we refer the reader to [pp12a, pos13]) – there are several examples in this paper however. example 1 includes a simple assignment constraint, x > y. an assignment is well-typed for this if it maps both x and y to integers. such an assignment constraint γ is evaluated with respect to a well-typed assignment α , denoted γ α , by instantiating variables with the values given by α and then replacing function and relation symbols with the obvious functions and relations. in our formal definition of e-conditions, the part of the formalism immediately after each quantifier is a morphism – not simply a graph. in our examples, we draw only the codomains; in general there are chains of morphisms along the nesting (starting from the empty graph in this paper). we discuss this aspect of e-conditions in more detail shortly. definition 1 (e-condition) an e-condition c over a graph p is of the form true or ∃(a | γ, c′), where a : p →֒ c is an injective graph morphism with p,c ∈ g (label), γ is an assignment constraint, and c′ is an e-condition over c. boolean formulae over e-conditions over p yield econditions over p, that is, ¬c and c1 ∧ c2 are e-conditions over p if c,c1,c2 are e-conditions over p. 9 / 20 volume 61 (2013) verifying total correctness of graph programs in order to define the satisfaction relation for e-conditions, we first define substitutions to allow the replacement of variables with lists (this is used to enforce equal assignment of variables in the nesting of e-conditions). a substitution is a partial function σ : varid → list. given a label (e b) with e a list and b a mark, σ is well-typed for e if it does not replace variables in arithmetic (resp. string) expressions with string (resp. arithmetic) expressions. in this case, the list eσ is obtained from e by replacing every variable x for which σ is defined with σ(x) (if σ is not defined for a variable x, then xσ = x). given a graph g in g (label) such that σ is well-typed for all lists in g, we write gσ for the graph in g (label) that is obtained by replacing each list e with eσ . if g : g → h is a graph morphism between graphs in g (label), then gσ denotes the morphism 〈gv ,ge〉: g σ → h σ . a substitution σ : varid → list can be applied to an assignment constraint γ , if it is well-typed for all expressions in γ . the resulting assignment constraint, denoted by γ σ , is simply γ with each expression e replaced by eσ . given an assignment α : varid → l, the substitution σα : varid → list induced by α maps every variable x to the expression that is obtained from α(x) by replacing integers and strings with their syntactic counterparts. for example, if α(x) is the integer 23, then σα (x) is 23 (the syntactic digits). consider another example: if α(x) is the sequence 56 : “a” : “bc” , where 56 is an integer and “a” and “bc” are strings, then σα (x) = 56: ”a” : ”bc”. the satisfaction of e-conditions by injective graph morphisms between graphs in g (l ) is defined inductively. every such morphism satisfies the e-condition true. an injective graph morphism s : s →֒ g with s,g ∈ g (l ) satisfies the e-condition c = ∃(a : p →֒ c | γ,c′), denoted s |= c, if there exists an assignment α that is well-typed for all expressions in p,c,γ and is undefined for variables present only in c′, such that s = pα , and such that there is an injective graph morphism q : cα →֒ g with q ◦ aα = s, γ α = true, and q |= (c′)σα . here, σα is the substitution induced by α , which we require to be well-typed for all expressions in c′. if such an assignment α and morphism q exist, we say that s satisfies c by α , and write s |=α c. the satisfaction of boolean formulae over e-conditions is defined inductively, in the obvious way. for brevity, we write false for ¬true, ∃(a | γ) for ∃(a | γ,true), ∃(a,c′) for ∃(a | true,c′), and ∀(a | γ,c′) for ¬∃(a | γ,¬c′). in our examples, when the domain of morphism a : p →֒ c can unambiguously be inferred, we write only the codomain c. for instance, an e-condition ∃(/0 →֒ c,∃(c →֒ c′)) can be written as ∃(c,∃(c′)), where the domain of the outermost morphism is the empty graph, and the domain of the nested morphism is the codomain of the encapsulating e-condition’s morphism. an e-condition over a graph morphism whose domain is the empty graph is referred to as an e-constraint. example 1 the e-constraint ∀( x y 1 2 k | x > y,∃( x y 1 2 l k )) expresses that every pair of unmarked integer-labelled nodes linked by an unmarked edge with the source label greater than the target label, has an unmarked loop incident to the source node. the (fully) unabbreviated version of the e-constraint is as follows: ¬∃(/0 →֒ x 1 y 2 k | x > y, ¬∃( x 1 2 y k →֒ 1 x 2 y l k | true, true)). a graph g in g (l ) satisfies an e-constraint c, denoted g |= c, if the morphism /0 →֒ g satisfies c. selected revised papers from gcm 2012 10 / 20 eceasst definition 2 (partial correctness) a graph program p is partially correct with respect to a precondition c and postcondition d (both of which are e-constraints), denoted |=par {c} p {d}, if for every graph g ∈ g (l ), g |= c implies h |= d for every graph h in jpkg. in [pp12a] we defined axioms and inference rules for proving partial correctness specifications about graph programs. these are given in figure 6 (with [try] new for gp 2), where r (resp. r) ranges over conditional rule schemata (resp. sets of conditional rule schemata), c,c′,d,d′,e,inv over e-constraints, and p,q over graph programs. together, the axioms and rules define a proof system for partial correctness. if a hoare triple {c} p {d} can be proved via the axioms and inference rules (by constructing a proof tree, as in section 6), we write ⊢par {c} p {d}. the proof system is sound in the sense of partial correctness, that is, ⊢par {c} p {d} implies |=par {c} p {d} (see [pp12a] for gp 1, and [pos13] for an analogous gp 2 proof). [ruleapp] {pre(r,c)} r {c} [nonapp] {¬app(r)} r {false} {c} r {d} for each r ∈ r [ruleset] {c} r {d} {inv} r {inv} [!] {inv} r! {inv ∧¬app(r)} {c} p {e}, {e} q {d} [comp] {c} p; q {d} c ⇒ c′, {c′} p {d′}, d′ ⇒ d [cons] {c} p {d} {c ∧ app(r)} p {d}, {c ∧¬app(r)} q {d} [if] {c} if r then p else q {d} {c ∧ app(r)} r; p {d}, {c ∧¬app(r)} q {d} [try] {c} try r then p else q {d} figure 6: partial correctness proof rules for core commands two transformations – app and pre – appear in the axioms and rules. intuitively, app takes as input a set r of conditional rule schemata, and transforms it into an e-condition satisfied only by graphs for which at least one rule schema in r is applicable. pre on the other hand constructs an e-condition such that if g |= pre(r,c), and the application of r to g results in a graph h, then h |= c. formal constructions of the transformations are omitted from this paper, but can be found in [pp12a] for gp 1 (and for gp 2, in [pos13]). we remark that the proof system is for a strict subset of graph programs. specifically, as-longas-possible iteration can only be applied to sets of rule schemata, and the guards of conditionals are restricted to sets of rule schemata (in both cases the semantics of gp allows arbitrary pro11 / 20 volume 61 (2013) verifying total correctness of graph programs grams). without this restriction, the proof rules would require an assertion language able to express that an arbitrary program will not fail. 5 proving total correctness if ⊢par {c} p {d}, then if p is executed on a graph g satisfying c, we can be sure that any graph resulting will satisfy d. what we cannot be sure about is whether an execution of p will ever terminate (i.e. whether an execution might diverge or not). moreover, if an execution of p does in fact terminate, we cannot be sure that it does so without failure. when referring to total correctness, we follow [apt84] in meaning both absence of divergence and failure; and when referring to weak total correctness, we mean only absence of divergence. definition 3 (weak total correctness) a graph program p is weakly totally correct with respect to a precondition c and postcondition d (both of which are e-constraints), denoted |=wtot {c} p {d}, if |=par {c} p {d} and for every graph g ∈ g (l ) such that g |= c, we have ⊥ /∈ jpkg. definition 4 (total correctness) a graph program p is totally correct with respect to a precondition c and postcondition d (both of which are e-constraints), denoted |=tot {c} p {d}, if |=wtot {c} p {d}, and for every graph g ∈ g (l ) such that g |= c, we have fail /∈ jpkg. a weakly totally correct program executed on a graph satisfying the precondition will either produce an output graph or terminate with failure (it cannot diverge or get stuck). a totally correct program however has the additional guarantee that it will not fail, that is, a graph will eventually result from its execution. our proof system for weak total correctness is formed from the proof rules of figure 6, but with [!]tot in figure 7 substituted for [!]. if a triple {c} p {d} can be obtained from this proof system, we write ⊢wtot {c} p {d}. the issue of termination is localised to the proof rule for aslong-as-possible iteration: [!]tot has an additional premise to [!] which handles this. it requires, for a given rule schema set, that there is a function assigning natural numbers to graphs such that these naturals are decreasing along rule applications. such a function # is called a termination function. if the #-values of graphs satisfying the invariant inv decrease under applications of r, we say that r is #-decreasing under inv. these definitions are given more precisely below. ⊢par {inv} r {inv}, r is #-decreasing under inv [!]tot {inv} r! {inv ∧¬app(r)} c ⇒ app(r), ⊢par {c} r {d} for each r ∈ r [ruleset]tot {c} r {d} figure 7: total correctness proof rules for two core gp commands selected revised papers from gcm 2012 12 / 20 eceasst definition 5 (termination function; #-decreasing) a termination function is a mapping # : g (l ) → n from (semantic) graphs to natural numbers. given an e-constraint c, a set of conditional rule schemata r is #-decreasing under c if for all graphs g,h in g (l ) with g |= c and h |= c, g ⇒r h implies #g > #h. in an application of [!]tot, one must find a suitable termination function # that returns smaller natural numbers along the graphs of direct derivations. the problem of deciding whether a set of rule schemata has a termination function or not is undecidable in general [plu98]. often however simple termination functions will suffice in several contexts. for example, a useful, intuitive termination function would be one that maps a graph to its size (e.g. total number of nodes and edges). if a rule schemata set is reducing the size of a graph upon each application, then clearly the iteration cannot continue indefinitely, and this is reflected by the output of # tending towards zero. however, in cases when rule schemata are not decreasing the size of the graph, less obvious termination functions may be needed (one such example will be discussed in section 6). note that the rule [!]tot requires only that # is decreasing for graphs that satisfy the invariant inv, i.e. it need not be decreasing for other graphs. our proof system for total correctness is formed of [comp], [cons], [if], [try], and the proof rules of figure 7. if a triple {c} p {d} can be derived from this proof system, we write ⊢tot {c} p {d}. (we do not include a proof rule for a program that is just a single rule schema r, because this case is captured by proving ⊢tot {c} {r} {d}.) this proof system allows one to prove that all program executions terminate without failure. essentially, this is achieved by ensuring that the preconditions of rule schema sets imply their applicability, when they are applied outside of iterations or the guards of conditionals. hence if graphs satisfy the preconditions, by implication the rule schema sets are applicable to those graphs, and thus we can be certain that no execution will fail. the proof rule [ruleset]tot separates the issues of failure and partial correctness. in using the proof rule, one must show (outside the calculus) that the applicability of r is logically implied by the precondition c. in showing that this premise holds, we can be sure that at least one rule schema in r can be applied to a graph satisfying c, hence no execution on that graph will fail. separately, it must be shown that ⊢par {c} r {d} for each r ∈ r, that is, each rule schema in the set is partially correct with respect to the preand postcondition. together, we derive that every execution of r will yield a graph, and that the graph will satisfy the postcondition. the axiom [nonapp] is excluded from our proof system for total correctness, as the specification {¬app(r)} r {false} does not hold in the sense of total correctness. suppose that it did. then r would never fail on graphs satisfying the precondition. but satisfying ¬app(r) implies that r fails on that graph – a contradiction. 6 example proofs in this section, we return to the example graph programs from section 3, and demonstrate how to prove (weak) total correctness properties using our new proof calculi. 13 / 20 volume 61 (2013) verifying total correctness of graph programs first, we revisit the program colouring of figure 3. though the program contains no failure points (since if a rule schema under as-long-as-possible iteration cannot be applied, the execution simply moves on to the next command), the iteration operator can introduce non-termination. in [pp12a] we proved that colouring is partially correct, in the sense that any graph resulting is properly coloured. in figure 8, we strengthen this to ⊢tot {c} colouring {d ∧¬app({inc})}, i.e. if the program is executed on a graph containing only atom-labelled nodes, then (1) a graph will eventually be returned; (2) it will be properly coloured; and (3) for any colour n in the graph, every colour k with 0 ≤ k < n is also in the graph. (the specification ignores marked nodes and edges for simplicity.) note that the e-conditions resulting from pre, implications in instances of [cons], and their justifications, are omitted to preserve space – but can be found in [pos13]. [ruleapp] {pre(init,e)} init {e} [cons] ⊢par {e} init {e} x [!]tot {e} init! {e ∧¬app({init})} [cons] {c} init! {d} [ruleapp] {pre(inc,d)} inc {d} [cons] ⊢par {d} inc {d} y [!]tot {d} inc! {d ∧¬app({inc})} [comp] ⊢tot {c} init!; inc! {d ∧¬app({inc})} x : init is #init-decreasing under e; y : inc is #inc-decreasing under d c = ∀( a 1 ,∃( a 1 | atom(a))) d = ∀( a 1 ,∃( a 1 | a = b:c and atom(b) and c >= 0)) ∧ ∀( b:c 1 | atom(b),∃( b:c 1 | c = 0) ∨ ∃( b:c 1 d:c-1 | atom(d))) e = ∀( a 1 ,∃( a 1 | atom(a)) ∨ ∃( a 1 | a = b:c and atom(b) and c >= 0)) ∧ ∀( b:c 1 | atom(b),∃( b:c 1 | c = 0) ∨ ∃( b:c 1 d:c-1 | atom(d))) ¬app({init}) = ¬∃( x | atom(x)) ¬app({inc}) = ¬∃( x:i y:i k | atom(x,y) and int(i)) figure 8: a proof tree for the program colouring of figure 3 the key revision in the proof tree is in the two uses of [!]tot, which unlike its partial correctness counterpart requires the definition of termination functions. for init, we define #init : g (l ) → n to map graphs to the number of their nodes labelled by an atom. the rule schema is clearly #init-decreasing under e, since every application of init reduces by one the number of nodes with such labels. the rule schema inc however requires a less obvious termination function selected revised papers from gcm 2012 14 / 20 eceasst #inc : g (l ) → n. for a graph g ∈ g (l ), we define: #inc(g) = |vg| ∑ i=0 i − ∑ v∈vg colour(v) where colour(v) for a node v ∈ vg is defined: colour(v) = { i if lg(v) = x : i with x ∈ z∪ char ∗, i ∈ n; 0 otherwise. we show that inc is #inc-decreasing under inv. observe that if g is a graph with colour(v) = 0 for every node v in vg, then for every derivation g ⇒ ∗ inc h there is some 0 ≤ k < |vh| such that k is the largest tag in vh . we obtain an upper bound for the second summation: ∑ v∈vh colour(v) ≤ 0 + 1 + ···+(|vh|− 1) = 0 + 1 + ···+(|vg|− 1) < |vg| ∑ i=0 i. since ∑v∈vh colour(v) equals the number of rule schema applications in g ⇒ ∗ inc h, it follows that inc must eventually terminate (as it approaches the upper bound). by subtracting the summation from the upper bound, we instead have a number decreasing towards 0 after every application of inc. hence #inc is a suitable termination function, and inc is #inc-decreasing under inv. we remark that inc! will terminate on any graph – not just those satisfying inv. a termination function however is harder to write without the assumptions the invariant allows us to make about the graphs. now, we return to the program reachable? of figure 4, which unlike earlier, can fail on some input graphs (in particular, those graphs omitting the pair of 1and 2-tagged nodes). we give a proof tree3 for ⊢tot {c} reachable? {c} in figure 9, where the e-constraints are as in figure 10. for clarity, we let visited(p) abbreviate: p = a:0 and atom(a) where a is a fresh variable. if the program is executed on a graph that contains only atom-labelled nodes but with one tagged 1 and another tagged 2, then (1) the program is guaranteed to return a graph eventually; and (2) that graph will satisfy the same condition (i.e. an invariant). again, due to space limitations, we have omitted the implications in instances of [cons] and their justifications. moreover, we have only provided one of the e-constraints generated by pre. in this proof tree, there are simple suitable termination functions #p,#u. we define the termination function #p : g (l ) → n (resp. #u) to return the number of nodes in a graph that are labelled by an atom (resp. number of atom-labelled nodes tagged with a 0). that is, both termination functions exploit that each application of their respective rule schema explicitly reduces the number of remaining matches. 3 for simplicity we use an obvious additional axiom [skip]: ⊢tot {c} skip {c}. 15 / 20 volume 61 (2013) v e ri fy in g t o ta l c o rr e c tn e s s o f g ra p h p ro g ra m s let p = if reachable then skip else addlink [ruleapp] {pre(propagate,e)} propagate {e} [cons] ⊢par {e} propagate {e} propagate is #p-decreasing under e [!]tot {e} propagate! {e ∧¬app({propagate})} [cons] {c} propagate! {e} subtree x [comp] ⊢tot {c} propagate!; p; undo! {c} subtree x : [skip] {e} skip {e} [cons] {e ∧ app({reachable})} skip {e} subtree y [if] {e} p {e} [ruleapp] {pre(undo,e)} undo {e} [cons] ⊢par {e} undo {e} undo is #u-decreasing under e [!]tot {e} undo! {e ∧¬app({undo})} [cons] {e} undo! {c} [comp] {e} p; undo! {c} subtree y : e ∧¬app({reachable}) ⇒ app({addlink}) [ruleapp] {pre(addlink,e)} addlink {e} [cons] ⊢par {e ∧¬app({reachable}} addlink {e} [ruleset]tot {e ∧¬app({reachable})} addlink {e} figure 9: total correctness proof tree for the program reachable? of figure 4 s e le c te d r e v is e d p a p e rs fr o m g c m 2 0 1 2 1 6 / 2 0 eceasst c = ∃( x:1 1 y:2 2 | atom(x,y), ¬∃( x:1 1 y:2 2 p | not atom(p))) e = ∃( x:1 y:2 | atom(x,y), ¬∃( x:1 y:2 p | not atom(p) and not visited(p))) app({reachable}) = ∃( x:y z:2 a | atom(x,z) and int(y)) app({addlink}) = ∃( x:1 y:2 | atom(x,y)) ¬app({propagate}) = ¬∃( x:y z a | atom(x,z), ∃( x:y z a | y = 1) ∨ ∃( x:y z a | y = 0)) ¬app({undo}) = ¬∃( x:0 | atom(x)) pre(undo,e) ≡ ∀( x:0 | atom(x),∃( x:0 y:1 z:2 | atom(y,z), ¬∃( x:0 y:1 z:2 p | not atom(p) and not visited(p)))) figure 10: partial list of e-constraints for figure 9 the rule schema addlink is the only potential failure point of the program, and is addressed in the proof tree by the application of [ruleset]tot. it must be shown that the precondition at that point implies the applicability of addlink. from figure 10, it is clear that satisfying e is sufficient to deduce the applicability of addlink. 7 soundness and completeness for termination in this section we revise our soundness proof from [pp12a] to account for (weak) total correctness, before showing that any iterating rule schemata set that terminates can be proven to terminate by the rule [!]tot. soundness is relative to the operational semantics of the language. an updated version of the soundness proof for partial correctness with regards to the gp 2 semantics can be found in [pos13]. theorem 1 (soundness of ⊢wtot) for all graph programs p and e-constraints c,d, we have that ⊢wtot {c} p {d} implies |=wtot {c} p {d}. proof. for all weak total correctness proof rules except [!]tot, this follows from (1) the soundness result for partial correctness in [pp12a], and (2) the semantics of graph programs, from which it is clear that only as-long-as-possible iteration can introduce divergence. let r be a set of (conditional) rule schemata, inv an e-constraint, and # a termination function. assume ⊢par {inv} r {inv}. by soundness for partial correctness, we have |=par {inv} r! {inv ∧ ¬app(r)}. assume also that r is #-decreasing under inv. by definition 5, for all graphs 17 / 20 volume 61 (2013) verifying total correctness of graph programs g,h ∈ g (l ) with g |= inv and h |= inv, g ⇒r h implies #g > #h. assume that r! diverges for any such g. since r is #-decreasing under inv, every derivation step yields a graph for which # returns a smaller natural number. since r! diverges, there are infinitely many derivation steps. but from any natural n, there are only finitely many smaller numbers. a contradiction. it cannot be the case that r! diverges from any such g. hence |=wtot {inv} r! {inv ∧¬app(r)}. theorem 2 (soundness of ⊢tot) for all graph programs p and e-constraints c,d, we have that ⊢tot {c} p {d} implies |=tot {c} p {d}. proof. for the proof rules [comp], [cons], [if], [try], [!]tot, this follows from (1) the soundness of ⊢wtot (see theorem 1), and (2) the semantics of graph programs, from which it is clear that these proof rules are sound in the sense of total correctness. what remains to be shown is the soundness of [ruleset]tot in the sense of total correctness. let r denote a set of (conditional) rule schemata and c,d denote e-constraints. assume that ⊢par {c} r {d} for each r ∈ r. then by soundness for partial correctness, we have |=par {c} r {d}. now assume the validity of c ⇒ app(r). then if a graph g ∈ g (l ) satisfies c, by assumption it will satisfy app(r). by proposition 7.1 of [pp12a] (updated for the gp 2 syntax in [pos13]), there is a graph h such that g ⇒r h. then the semantic rule [call1] will be applied (and in particular, [call2] will not be), hence a graph is guaranteed from the execution and failure is avoided. we yield |=tot {c} r {d}. now, we show that every iterating set of rule schemata that terminates can be proven to terminate using [!]tot, by showing that there always exists a termination function for which the rule schemata set is decreasing under its invariant. theorem 3 (completeness of [!]tot for termination) let r be a set of conditional rule schemata and c be an e-constraint such that for every graph g in g (l ), g |= c implies that r! cannot diverge from g. then there exists a termination function # such that r is #-decreasing under c. proof. let g be a graph such that g |= c. then there cannot exist an infinite sequence g ⇒r g1 ⇒r g2 ⇒r ... as otherwise, by the semantics of gp, there would be an infinite sequence 〈r!, g〉 → 〈r!, g1〉 → 〈r!, g2〉.... to define the termination function #, we show that the length of ⇒r -derivations starting from g is bounded. (note that, in general, a terminating relation need not be bounded.) we exploit that ⇒r is closed under isomorphism in the following sense: given graphs m,m ′,n and n′ such that m ∼= m′ and n ∼= n′, then m ⇒r n implies m ′ ⇒r n ′. hence we can lift ⇒r to a relation on isomorphism classes of graphs by defining: [m] ⇒r [n] if m ⇒r n. then, since r is finite, for every isomorphism class [m] the set {[n] | [m] ⇒r [n]} is finite. now, since there is no infinite sequence of ⇒r -steps starting from [g], it follows from könig’s lemma [kön36] that the length of ⇒r -derivations starting from [g] is bounded. (in the tree of all derivations starting from [g], all nodes have a finite degree. hence the tree cannot be infinite, as otherwise it would contain an infinite derivation.) hence the length of ⇒r -derivations starting from g is bounded as well. in general, given any graph m in g (l ), let #m be the length of a longest ⇒r -derivation starting from m if m |= c, and #m = 0 otherwise. then if m,n |= c and selected revised papers from gcm 2012 18 / 20 eceasst m ⇒r n, we have #m > #n. thus r is #-decreasing under c. 8 conclusion in this paper we have presented two hoare calculi which allow one to prove (weak) total correctness. both proof systems have been shown to be sound. we have shown how to reason about termination via termination functions, and shown that the proof rule for termination is complete in the sense that all terminating loops (having a set of conditional rule schemata as the body) can be proven to be terminating. finally, we have demonstrated the use of the proof systems on two non-trivial graph programs, showing how to prove the absence of divergence and failure. future work will explore how to implement the proof calculi in an interactive proof system. a first step towards this is made in [pos13], in which translations from e-conditions to manysorted formulae (and back) are defined, providing a suitable front-end logic for an implemented verification system. future work will also address the question of whether or not the calculi are (relatively) complete. it would also be worthwhile to integrate a stronger assertion language into the calculi that can express non-local properties, such as the hyperedge-replacement conditions of [hr10]. acknowledgements: we thank the anonymous referees for their comments which helped to improve the final version of this paper. most of this work was completed whilst the first author was a ph.d. student at the university of york, where he was supported by a scholarship of the engineering and physical sciences research council. since january 2013 he has been based at eth zürich, where he is supported with funding from the european research council (erc grant agreement no. 291389). bibliography [apt84] k. r. apt. ten years of hoare’s logic: a survey part ii: nondeterminism. theoretical computer science 28:83–109, 1984. [bck08] p. baldan, a. corradini, b. könig. a framework for the verification of infinite-state graph transformation systems. information and computation 206(7):869–907, 2008. [bhe09] d. bisztray, r. heckel, h. ehrig. compositional verification of architectural refactorings. in proc. architecting dependable systems vi (wads 2008). volume 5835, pp. 308–333. springer-verlag, 2009. [cr12] s. a. da costa, l. ribeiro. verification of graph grammars using a logical approach. science of computer programming 77(4):480–504, 2012. [hp02] a. habel, d. plump. relabelling in graph transformation. in proc. international conference on graph transformation (icgt 2002). volume 2505, pp. 135–147. springerverlag, 2002. 19 / 20 volume 61 (2013) verifying total correctness of graph programs [hp09] a. habel, k.-h. pennemann. correctness of high-level transformation systems relative to nested conditions. mathematical structures in computer science 19(2):245–296, 2009. [hpr06] a. habel, k.-h. pennemann, a. rensink. weakest preconditions for high-level programs. in proc. international conference on graph transformation (icgt 2006). volume 4178, pp. 445–460. springer-verlag, 2006. [hr10] a. habel, h. radke. expressiveness of graph conditions with variables. in proc. colloquium on graph and model transformation on the occasion of the 65th birthday of hartmut ehrig. electronic communications of the easst 30. 2010. [ke10] b. könig, j. esparza. verification of graph transformation systems with contextfree specifications. in proc. international conference on graph transformation (icgt 2010). volume 6372, pp. 107–122. springer-verlag, 2010. [kön36] d. könig. sur les correspondances multivoques des ensembles. fundamenta mathematicae 8:114–134, 1936. [plu98] d. plump. termination of graph rewriting is undecidable. fundamenta informaticae 33(2):201–209, 1998. [plu09] d. plump. the graph programming language gp. in proc. algebraic informatics (cai 2009). volume 5725, pp. 99–122. springer-verlag, 2009. [plu12] d. plump. the design of gp 2. in proc. international workshop on reduction strategies in rewriting and programming (wrs 2011). electronic proceedings in theoretical computer science 82, pp. 1–16. 2012. [pos13] c. m. poskitt. verification of graph programs. phd thesis, the university of york, 2013. to appear. [pp12a] c. m. poskitt, d. plump. hoare-style verification of graph programs. fundamenta informaticae 118(1-2):135–175, 2012. [pp12b] c. m. poskitt, d. plump. verifying total correctness of graph programs. in proc. international workshop on graph computation models (gcm 2012). 2012. available from http://gcm2012.imag.fr/. selected revised papers from gcm 2012 20 / 20 http://gcm2012.imag.fr/ introduction preliminaries graph programs proving partial correctness proving total correctness example proofs soundness and completeness for termination conclusion a formal co-simulation approach for wireless sensor network development electronic communications of the easst volume 70 (2014) proceedings of the 14th international workshop on automated verification of critical systems (avocs 2014) a formal co-simulation approach for wireless sensor network development adisak intana, michael r. poppleton, geoff v. merrett 15 pages guest editors: marieke huisman, jaco van de pol managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst a formal co-simulation approach for wireless sensor network development adisak intana, michael r. poppleton, geoff v. merrett ai1n10,mrp,gvm@ecs.soton.ac.uk electronics and computer science university of southampton, southampton, so17 1bj, uk abstract: this paper proposes a formal co-simulation (focosim-wsn) framework to provide a good software engineering practice for wireless sensor networks (wsns) including high-level abstraction, separation of concerns, strong verification and validation (v&v) techniques. this provides an iterative interworking framework which combines the benefits of existing simulation and proof-based formal verification approaches. the complexity of software development for the sensor node controller is reduced by separating the controller model from the simulation environment. controller algorithms from application through network and mac layers can be formally developed and verified in a layered manner using the refinement method of the event-b language and its rodin toolkit. the absence of certain classes of faults in controller models which cannot be guaranteed by simulation testing techniques, can be proved by formal methods. on the other hand, the mixim simulation of physical environment provides full confidence about reliability and performance analysis through long running simulation via wireless channels. our prototype development confirms the flexibility of the framework for interworking between formal, simulation and co-simulation modelling. keywords: formal modelling and analysis, event-b, proof, simulation, wireless sensor network, co-simulation 1 introduction a wireless sensor network (wsn) is a distributed system of cooperating devices that performs distributed monitoring applications in a physical environment over a self-organised wireless network topology. in traditional wsn development, wsn requirements are tackled with a “codeand-fix” process [pie10] in which the code is implemented on the real hardware. the wsn application is developed under the constraints of display-less, low-level specific platform and lowpower design. in safety-critical application domains where wsns are increasingly being adopted from healthcare to military the demand on verification is high [pie10, brwr10, acb10]. functional requirements including safety/liveness properties have to be considered together with performance and reliability requirements of the network. simulation is usually used at an early stage of designing and testing communication protocols because it provides the higher level of abstraction [km07, ish10]. it abstracts away from specific operating system platforms whereas other testing techniques such as emulation and laboratory testbeds do not. in current simulation practice, protocols and algorithms are layered to 1 / 15 volume 70 (2014) mailto:{ai1n10,mrp,gvm}@ecs.soton.ac.uk a formal co-simulation approach for wireless sensor network development create a communication networking protocol suite by a standard protocol stack scheme. these are integrated with a stochastic environment framework of wireless channel, radio and analogue models to generate the long running testing scenarios. the simulation and performance analysis such as network latency and energy consumption are conducted independently from any specific platform. however, code for simulation is developed monolithically; current practice is a long way from model-based software engineering process. the specification of the behaviours of the software controller algorithm and the behaviour of the environment are implemented in simulation at the same time. this gives significant complexity to manage during development and makes it hard to understand the code. thus, a clear separation of concerns is required in this aspect. furthermore, critical design errors are not guaranteed to be discovered during simulation. this technique cannot guarantee the absence of certain classes of faults as discovered in [ipm13]. formal methods have been considered to design and verify the wsn application and protocol. for example, formal analysis is proposed in [mrdd10] to detect critical network elements with omnet++. the framework proposed by [wbls09] also indicates the translated formal specification in pvs (prototype verification system) from the logic-based network datalog language (ndlog) to guarantee the protocol behaviour. in [ipm13], the proof-based formal method gives a strong guarantee for the absence of faults. certain functional requirements and safety properties are encoded as invariants in event-b and it is proved that this invariant is always satisfied by the system behaviours before actual implementation. however, the complexity and scalability of applications need long running simulation behaviours to give full confidence about reliability and performance requirements in formal models. to increase the quality of current se practice for wsn development, this paper is implementing the vision proposed in [pm12]. we construct the infrastructure for co-simulation between formal event-b wsn models and mixim environment simulation engines. this provides an integrated set of methodologies for wsns: (s)imulation, (f)ormal and (c)o-simulation;see figure 1. the focosim-wsn framework is proposed which is a formal co-simualtion method for event-b and mixim for wsns. (s) s-style development is the traditional wsn development style that layers the protocol algorithms and evaluates the network performance as mentioned earlier. target code based on the simulation model is generated together with standard platform-specific libraries. node level simulation or emulation takes place to test the correctness and performance of the real code before the real world deployment. (f) f-style modelling represents the requirement specification, modelling and verification in a formal modelling language [ipm13, abr07, abhv06]. each protocol algorithm is layered and verified through refinement steps at network level development. the verified network model is produced before different refinement paths are encoded with requirements for the specific dependent platform at node level. the final, verified node code is generated with standard libraries for a specific hardware platform from this verified node model. (c) our c-style prototype framework enables the complexity of development to be reduced by separating the software controller from the environment. formal methods provide the controller, a formal model of code in the real nodes, containing the protocol algorithms proc. avocs 2014 2 / 15 eceasst separately. an environment simulator provides stochastic sensed data and radio environment, allowing simulation scenarios to be defined as required. the verified controller model for each layer of protocol stack ultimately, down to verified generated code is co-simulated with the environment model to perform the performance analysis. a master co-simulation language and algorithm is required to integrate and manage the component simulators. the formal event-b controller model simulated by prob can co-simulate with a sensor environment provided by mixim via this master. figure 1: vision of co-simulation approach for wsn development in this work, our focosim-wsn framework cosimulates between node controller models on the event-b simulation and sensor environment models on mixim simulation. each network algorithm at each protocol layer is separated from the wireless and physical environment and modelled in event-b language. a master algorithm is developed by groovy language to coordinate between network algorithm and environment models. as mixim can provide a socket interface in order to integrate its network models together with other simulation environment such as the vehicles in network simulation (veins) [sgd11] framework1, we mock-up our own interfaces for mixim containing a socket interface for co-simulation. this work focuses on the network level of the development. we exercise our focosim-wsn framework with the two abstraction layers at the network level development, application (app) and network (net). the two lower layers, mac and physical (phy), are our work in progress. the node level development remains work for the future. the remainder of this paper is organised as follows. sections 2 and 3 discuss related work and introduce the running case study, an environment monitor system. in section 4, we demonstrate the strengths and weaknesses of s-style development. section 5 discusses the f-style approach showing the benefit of specifying and verifying the network algorithm model. we apply a shared-event decomposition to separate the controller from the environment. the main section is section 6 which introduces our prototype c-style framework (focosim-wsn) for co-simulation and demonstrate with the case study. finally section 7 gives some conclusion and future work. 1 see veins -http://veins.car2x.org/ 3 / 15 volume 70 (2014) a formal co-simulation approach for wireless sensor network development 2 related work recently, co-simulation frameworks have been proposed in order to co-ordinate between the software controller model and physical simulation environment. destecs 2 [bkl+10] is an integrative co-simulation framework for co-modelling and co-simulating between discrete-event (de) and continuous-time (ct) of physical models via xml-rpc interface. the formal simulation of advance3 [adv13] provides a framework for integrating multi cyber-physical systems using different simulation engines via functional mock-up interfaces (fmis)4. a master-slave algorithm to execute the co-simulation is implemented in the groovy language of the prob tool. a hybrid design framework is needed for wsn development when the wsn application closely interacting physical environments has become more complex. the model-based system design (mbsd) framework for wsns proposed by [wb12] co-simulates event-triggered components illustrating network algorithms together with continuous dynamic behaviour exhibited by physical environment. hybridsim[wb13] adopts fmi standard to co-simulate between sensor application models provided by tinyos and simulation environment generated by modelica. sysml (based on uml) is applied to the work described above [wb12, wb13] to express the application abstraction. their work is similar to our work in which the model of the node is co-simulated with the environment. however, their node models do not contain formal elements that leads to lack of formal precise semantics. the closest to our co-simulation framework is nmlab [hsb10] which provides a co-simulation framework for matlab and ns-2 simulator. the system controller implemented in matlab co-simulates with the network models provided by ns-2 by using socket interfaces. similar to this, harvwsnet [dbms13], a framework for energy harvesting wsns, combines the strengths of two development toolkits via a standard socket interface. the power management model is implemented in matlab to communicate to the wireless sensor network communication model provided by wsnet. however, the communication algorithms at each protocol layer are still implemented in wsnet simulator. 3 case study to demonstrate the effectiveness of our approach, we have extended an environment monitoring system from our preliminary work [ipm13]. this case study is derived from deployed projects described in [bis+08]. each sensor node in a network senses data such as temperature and wind speed periodically. this environmental data is regularly sensed and routed wirelessly via multihop from the source node to a sink node. as a small number of nodes was initially deployed in sensorscope project to evaluate the first use of multi-hop [bis+08], we implemented our preliminary models consisting of 7 nodes (6 sensor nodes with node 0 representing a sink in figure 2a) to evaluate the first demonstration of a multi-hop network. nodes in the simulation represent the wireless devices with their protocol stacks as shown in figure 2b. the data that has to be sent to a data sink is collected by application layer before sending down to lower layers. the task of the network layer is to manage the route tree used to 2 see destecs -http://www.destecs.org/ 3 see advance -http://www.advance-ict.eu/ 4 see fmis -https://www.fmi-standard.org/ proc. avocs 2014 4 / 15 eceasst figure 2: an example of (a) a multi-hop network topology and (b) node’s structure decide the next hop for transmission towards the sink. mac layer manages power consumption by switching radio on/off to sending/receiving packets and provides an acknowledgement (ack) mechanism for reliable transmission. the lowest layer, the physical layer, performs the radio propagation for packet sending and receiving. in this work, we focus on the experiment at the two upper layers, application and network layers. sensorapp, a periodic sensing protocol in which the sensed packet is transmitted periodically down to the lower layer, is chosen to implement at the application layer. for the network layer, mintroute, a link quality protocol is selected to be an efficient routing protocol. mintroute [wtc03] is a routing algorithm to build the route tree from every node towards a sink. the route tree is dynamically changed based on the link quality between nodes. this link quality is adjusted by the successful rate of transmitted packet delivery. mintroute performs four major steps: (1) neighbourhood discovery one neighbour discovers another neighbour based on broadcast beacon messages, (2) link quality estimation the estimation of reception link quality ratio is calculated periodically by observing the successful rate of receiving packets, (3) route broadcast the transmission link quality ratio of each neighbour is estimated periodically based on the reception link quality ratio attached in “route update message”, and (4) parent selection this is performed periodically to specify one of the neighbours for routing. the path cost towards a sink is calculated based on both two ratios (reception and transmission). link which has these two ratios less than the quality threshold is not considered. a neighbour with the smallest path cost is chosen as a parent. 4 s-style modelling to explore the benefits and drawbacks of s-style development, this section describes the simulation experiment on the case study described in the previous section. mixim5[ksw+08] provides a development framework for the simulation and performance analysis of wireless networks including wsns. it provides generic and flexible component architecture for models based on a standard network simulation engine, omnet++6. this layers the development environment into the standard ip protocol stack as shown in figure 2b. each 5 see mixim -http://mixim.sourceforge.net/ 6 see omnet++ -http://www.omnetpp.org/ 5 / 15 volume 70 (2014) a formal co-simulation approach for wireless sensor network development layer can communicate with the adjacent layer via communication interfaces named gates. in our simulation model, we extended the base modules (the general structure) for application and network layers provided by mixim to implement sensorapp and mintroute respectively. the configuration parameters were replicated from the real configuration used in sensorscope [bis+08], as discussed in our previous work [ipm13]. this exercise expresses the strength and weakness of s-style development. the network algorithms can be analysed with the performance evaluation such as the load distribution of the network and the network latency as described in the introduction. however, based on our previous work [ipm13], simulation enables us to discover the loop problem occurring in the route tree but this problem cannot be revealed at all running experiments we performed. this leads us to fix and prove this problem in formal models. thus, simulation cannot guarantee that the fault in the algorithm will be discovered. furthermore, this modelling style causes complexity in development. the controller representing the specific protocol algorithm for each layer in protocol stack has to be completed together with environment elements provided by the standard interface in simulation toolkit (wireless channel communication and connectivity, the library functions implementing sending/receiving packet and packet encapsulation/decapsulation) to form a single simulation model. this leads us to encounter difficulties of managing such a complex simulation model (especially in mintroute algorithm implemented at the network layer). the next section will demonstrate how to reduce this complexity by using event-b modelling techniques. each single controller for each protocol stack in a simulation model is separated and implemented into multiple layers by using the refinement technique. 5 f-style modelling 5.1 overview of event-b modelling event-b [abr07] is a proof-based formal method for specification and verification based on set theory and first order predicate logic. an event-b model consists of two parts: context and machine. the context describing the static part contains carrier sets, constants and axioms. the machine represents the behavioural part which consists of three elements: variables, invariants and events. states are described by typed variables. invariants that state the guaranteed properties of the model express the functional requirement and safety property. events in event-b give a state transition. each event contains guard(s) and action(s). the event guards express the necessary conditions that enable the event to successfully and usefully trigger, and actions describe the state transitions over the variables. proof obligations (pos) are used to state that invariants are satisfied by every event. event-b tool: rodin [abhv06] is an open tool platform based on eclipse. this extensible tool was developed by the european union ict project deploy7(2008-2012). rodin includes editors, a proof obligation generator (po-generator), graphical front ends, theorem provers and the prob8 animator and model checker. 7 see deploy industrial deployment of system engineering methods providing high dependability and productivity: fp7 project 214158 http://www.event-b.org 8 see prob http://www.stups.uni-duesseldorf.de/prob/ proc. avocs 2014 6 / 15 eceasst refinement: refinement is a method that allows software engineers to manage the complexity of the development by layering the abstraction of the models. a simple abstract view of essential requirements is implemented first. more requirement or design detail is added at each refinement step until implementation, data structure and algorithm are added to the concrete model in order to bring the model to become close to the real implementation. refinement pos state that concrete refining events must correctly implement their counterpart abstract refined events. shared-event model decomposition: the complexity of large system development is managed by breaking a single machine into sub-machines [but09, sphb11]. these sub-machines interact by exchanging messages via shared events. the shared-event decomposition rodin plugin9 is applied to this work to decompose a software controller from a sensor environment. 5.2 wsn development in event-b the benefit of using the f-style for wsn development described in section 1 is presented in this section. event-b is used to create a wsn specification and its verification. the development approach can be shown in figure 3. the two upper layers: application and network layers are implemented. the event-b refinement technique is used to layer the model which corresponds to each layer of protocol stack. we apply our mintroute models proposed in [ipm13]. the refinement structure and some events are adjusted to support our co-simulation framework. six refinement models are created. this begins with a very simple abstract model (m0) in which the data packet is transmitted to a sink in one atomic step. then, the first and second refinement models (m1-m2) fulfill the operation for sensorapp. these refinement models define the neighbour node to determine multi-hop network for broadcasting mechanism before they are refined down to implement mintroute. each step of mintroute protocol is layered (as in m3-m5, figure 3) from neighbourhood discovery to parent selection as described in section 3. the models for the c-style of co-simulation development are also prepared by separating the software controller from the environment for both layer protocols. shared event decomposition technique is applied to decompose the second and fifth refinement models corresponding to application and routing layers respectively. note that separated environment models env2 and env5 are used for the controller verification and validation before decomposition. in the c-style development, they are replaced with the concrete simulation environment implemented in mixim. for the route tree construction verification, we create safety invariants as shown in figure 4. this shows us the benefit of proof to indicate no-loop property as a necessary invariant proved after simulation revealed it. we apply the definition of transitive closure (tcl) and the no-loop property proposed by abrial[abr10] and applied in [dba08, hkba09]. we define the route tree in @inv3 2. the initialisation of variable nodes contains only a sink ({sink}) and the route tree (croutetree) is initialised to be an empty set. as soon as a node is explored to discover its parent, it is recorded in nodes with a pair between this node and its parent put in croutetree. flag completedroute in invariant @inv3 3 indicates the completion of route tree construction. thus, invariants @inv3 2 and @inv3 3 represents that when the route tree is finished, each sensor node must have its own parent. furthermore, safety invariant @saf3 1 illustrates the no-loop property. this can guarantee that there are no loops in the routing tree. theorem @mth3 3 confirms every 9 see shared-event decomposition plug-in http://wiki.event-b.org/index.php/decomposition plug-in user guide 7 / 15 volume 70 (2014) a formal co-simulation approach for wireless sensor network development figure 3: event-b development approach node must have a route to a sink. theorems @mth3 1 and @mth3 2 are introduced to help the proof of @mth3 3. figure 4: safety invariants regarding the route tree in the fifth refinement model (m5). 5.3 model decomposition, verification and validation as wsn is a distributed system in which each node exchanges data via a channel interface, shared event decomposition [but09, sphb11] is used to separate software controller from environment as shown in figure 5. the software controller contains the necessary variables and events expressing communication networking protocols and algorithms such as sensorapp and mintroute whereas environment consists of variables and events regarding the connectivity, channel and sensing environment. we design these two subcomponents to exchange messages via shared events. the steps of communication can be described as follows: (p1) the environment activates each sensor node in the controller to sense and create a data packet via a shared event (sensing). (p2) each sensor node transmits a data packet down to the channel. the shared event (send down) passes the forwarder node id and packet information as channel parameters (chnpar). (p3) the channel indicates the neighbour of the current forwarder. (p4) the channel returns the neighbour list and the forwarded packet to every neighbour controller via the shared event (send up) to indicate the operation transmitting a packet up to specific receivers. (p5) each neighbour node (including a sink, e.g. nodes 0,1,4,3 of sender node 2, figure 5) receives a forwarded packet (receive pkt and sink recv pkt) or detects a duplicated packet (receive dup pkt). proc. avocs 2014 8 / 15 eceasst figure 5: steps of communication between a software controller and environment model verification by pos: we verify the properties of a machine by proving that every event still satisfies invariants. 330 pos were discharged, in which 85 percent of the total number of pos were proved automatically by rodin. this includes the invariant to guarantee that no packets are lost under the perfect network. furthermore, the safety invariant regarding the absence of loop problem was discharged automatically. however, the remaining were proved interactively. this is because invariants and tcl properties include quantified predicates and graph properties. model animation and validation: we create the testing scenarios affecting the different link quality ratios that satisfy all desired requirements and strategies. these are used to animate and trace the list of operations to validate the formal model on prob. 6 c-style co-modelling 6.1 focosim-wsn framework for wsns we develop a prototype focosim-wsn framework of node controller models on the event-b simulation and sensor environment models on mixim simulation as shown in figure 6. event-b layers each communication protocol and algorithm to create and verify node controller models through refinement steps, whereas each protocol layer in mixim environments only contains gates (without any protocol algorithms) for communicating with the adjacent layer. in order to co-simulate these models, a master is implemented in groovy language of the prob tool. here we describe the implementation of our master. to schedule the event in the event-b model, we implement multiple threads in the master. each thread creates the instance of the event-b model representing the controller of each sensor node which corresponds to each virtual node in the mixim environment. mixim provides periodic timers such as a sensing timer and route broadcast timer, which allows the event-b controller and mixim environment models to exchange input/output periodically. tcp sockets are implemented as data exchange interfaces on both sides. we mock-up our own interfaces for mixim. fminterface is the front-end interface which contains the synchronization event which corresponds to the shared-event defined in event-b. this event is scheduled at fixed intervals and dedicated to maintain the data synchronization between the event-b controller and mixim environment. our protocol algorithms communicate with a sensor environment by exchanging the packet information (chnpar) and the receiving neighbour lists (nbrlst) together with the forwarded packet via the socket program implemented in the master. simmanager is the backend interface where the parameters passed from fminterface are transited down to/up from the channel (accessed by module channelaccess) via the protocol stack. 9 / 15 volume 70 (2014) a formal co-simulation approach for wireless sensor network development figure 6: focosim-wsn co-simulation framework during the initialization phase, mixim initializes the physical environment such as interval time, ratio propagation, max transmission power and path loss coefficient alpha from the configuration file. virtual nodes are created and placed on the simulation area (playground) generated by module worldutility in mixim. the connection between them is established by method updatenicconnection() in mixim’s connectionmanager. only nodes that are placed within the maximal interference distance of each other can be connected. this forms the network topology. then, fminterface starts requesting a connection to the event-b controller via sockets implemented in the master. once the connection is established, fminterface sends the necessary information extracted from the configuration file such as the number of nodes (numnodes) and identified sink id (sinkid) to a master. the master creates multiple threads corresponding to the number of virtual nodes generated in the mixim environment before it starts creating, initialising and loading the instance of event-b controller model into each thread. furthermore, each thread contains a timertask which is used to schedule the sequence of the events in the event-b model. then, the master relays the completion of the event-b model initialisation to fminterface in mixim via a socket. the example of the above mentioned initialization phase can be expressed in figure 8. at the simulation phase, the mixim begins to simulate at time 0. every periodic time, mixim sends the information to tell each controller node to start performing the operation such as sensing and creating a packet. mixim generates sense data to the required random distribution for each node controller. when each node creates a packet, the channel information (chnpar) including the initial source of packet, the sequence number, the forwarder and the destination node id (setting to -1 for broadcasting mechanism) is synchronized between the output shared event in event-b controller (e.g. event send down, figure 5) and the synchronization event in fminterface. the virtual packet containing this correspondent input parameter is created and transmitted to the virtual neighbour node via the protocol stack. the receiving neighbour lists in mixim of the forwarder node are synchronized back from the synchronization event in fminterface to the input shared event in event-b controller (e.g. event send up, figure 5) of each thread of node controller. after receiving the neighbour lists, each node controller will perform the next operation (e.g the receiving events described in step p5, figure 5). then, the receiving node that is not the destination forwards/rebroadcasts a received packet to its neighbours. the steps of this communication are the same as described for packet creation and transmission mechanism. proc. avocs 2014 10 / 15 eceasst 6.2 co-simulation case study modelling this section describes how to use our general focosim-wsn framework to implement the specific models in our case study. (a) sensorapp co-models (b) mintroute co-models figure 7: co-simulation models. the c-style model for mixed (event-b/mixim) co-simulation is developed by reuse of f-style formal-based and s-style simulation-based developments. our prototype co-simulation framework exercises two levels of abstraction application and network layers as shown in figure 7. we reuse node controller models, m2(sensorapp) and m5(mintroute), in f-style development to implement in this mixed co-simulation. in the mixim environment, we develop two protocol layers, simpleapp and simplenet by removing the protocol algorithms from sensorapp and mintroute modules in s-style. these modules are a standard module extending the base modules in mixim containing only packet en/decapsulation functions and gates. this enables the corresponding event-b controller representing the upper layer model to be able to communicate with the lower layer in mixim environment via fminterface and simmanager. to demonstrate the iterative co-model development for each layer protocol, we start exercising at the application layer in which only the sensorapp algorithm is separated from the simulation environment and implemented in event-b. in mixim, module simpleapp is used as a gate for communicating between sensorapp controller in event-b and lower layers retaining protocol algorithms mintroute and s-mac as illustrated in figure 7a. figure 7b shows the co-simulation at the network layer, the co-models are implemented in the same way as in the application layer. module simplenet in mixim is used to coordinate between the mintroute controller in eventb and the lower layer. s-mac is still retained in mixim’s mac layer. as in this event-b controller also contains the concrete model of sensorapp protocol containing unicast data packet forwarding mechanism via the route, this model also co-simulates with module simpleapp in mixim. figure 8 shows the master algorithm interaction expanding on figure 7a to demonstrate one sensing cycle for sensorapp. this interaction corresponds to communication steps in figure 5. as we use the same event-b controller, we design steps r1, r2 and r4 to be the same as steps p1, p2 and p4. the input/output parameters are passed from/to shared event (send down/send up) in order to exchange information between the controller and environment. then, these parameters are passed by a socket sending and receiving mechanisms (methods send and recv) as shown in steps r2 and r4. step r5 is implemented for a receiving node to receive the forwarded data 11 / 15 volume 70 (2014) a formal co-simulation approach for wireless sensor network development figure 8: master algorithm for sensorapp protocol co-simulation (a) (b) figure 9: example of performance analysis results of some nodes packet, method anyevent provided by prob groovy is used to create alternative choices among events receive pkt, receive dup pkt or sink recv pkt. note that we do not describe the master algorithm for the mintroute protocol. this is because it has the co-simulation interaction step to exchange the same input/output parameters for beacon and route packet transmission. considering step r3 which performs concrete operations of step p3 in figure 5, after each node in mixim environment receives channel information from fminterface via simmanager, the packet is generated based on this information and transmitted down to lower layers and finally a channel. note that virtual nodes in the mixim environment are generated by module simpleapp (the same as simplenet for the network layer) containing only gates for transmitting/receiving a data packet to/from lower layers. the forwarding node uses method senddown to relay a current packet down to the lower layer and finally to the channel. method handlelowermsg is used by receiving nodes for receiving a forwarded packet from the lower layer. simmanager collects information from receiving nodes to generate neighbour list. finally, this neighbour list is sent to fminterface and relayed to the event-b controller via the master. 6.3 co-simulation prototype validation in order to validate our c-style prototype, we ran our c-style co-models within 1400 seconds of simulation time with different network topologies varying from 1-hop to 3-hop network containing 4 to 7 nodes respectively. these simulation networks were generated from the parameters configured in the mixim configuration file. this performs eleven cycles of sensing periods, toproc. avocs 2014 12 / 15 eceasst gether with three cycles of parent selection. we compared the performance analysis results in c-style with that of s-style to identify the difference and weakness of c-style and s-style. however, we only found the randomness of the routing algorithm to discover the route tree. figure 9, for example, shows one of our co-simulation results from the network containing the topology illustrated in figure 2a. as shown in figure 9a for both styles, the latency of node 2 is always low as it always chooses a sink to be a parent. however, in figure 9b, at two-thirds of running simulation time, the latency of node 5 in s-style simulation is considerably high. this is because its parent had the highest number of forwarded data packets compared to that of c-style. 6.4 engineering process for c-style development based on our experience, our prototype focosim-wsn enables three flexible modes of working in which formal and simulation can be integrated easily. this can start from the pure event-b model (f-style) development in which the protocol algorithm can be modelled through the refinement steps. system engineers can develop either an early model for some high level or a refined model for more detailed level of functional abstraction. then, the software controller illustrating the protocol algorithm can be separated from a sensor environment by using the decomposition technique. this separated controller is also prepared for c-style co-simulation. on the other hand, the developed controller algorithm in pure s-style simulation model can be separated from the environment and implemented in the event-b model in the same way. the separated environment, which will be used by c-style co-simulation, still retains only the communication gates (no algorithm) together with the standard function in mixim such as packet encapsulation and decapsulation. however, instead of developing the sensor environment from scratch, reusing our standard module for communicating between two upper layers (such as simpleapp and simplenet) is another alternative way to prepare simulation environment. the next step is c-style co-simulation in focosim-wsn framework. the event-b controller model from f-style and the separated sensor environment from s-style are co-simulated via a master. to support the development with reuse, our master is modularized into the different interfaces such as wsnsocket, timertask and eventbctl for encapsulating the functionality of the socket program, scheduling events for multiple threads and event-b controller model interface respectively. in order to develop a specific master algorithm, the system engineers only customize the eventbctl to be compatible with their event-b model (as we have done for our proposed co-simulation models for different layers). during implementing a master algorithm, the synchronization (shared) events for communicating between these two models are needed to be identified. however, the automatic master code generation is still left for future work. this work has accomplished the generic modules for only two upper layers: application and network. the lower standard modules for the lower layer such as mac is still required and is work in progress. 7 conclusion and future work this paper has demonstrated the co-simulation approach to the extension of current se for wsn development. our prototype development shows that the framework integration for (f)ormal, (s)imulation and (c)osimulation can combine the benefits between two modelling approaches. 13 / 15 volume 70 (2014) a formal co-simulation approach for wireless sensor network development the complexity to manage in communication protocol and algorithm development can be reduced by the refinement approach provided by event-b. furthermore, event-b offers strong v&v in which the absence of certain classes of faults such as the loop problem in the route tree can be guaranteed by pos. whereas a stochastic environment framework of wireless channel, radio and analogue models provided by simulation can help engineers to analyse and evaluate the performance of the network such as network latency and congestion. our prototype focosimwsn framework provides an iterative interworking scheme through multiple refinement levels. system engineers also can work either for s-style development before the separated controller and environment are combined and co-simulated into our prototype framework. this framework can be flexible and utilized to integrate between f-, sand c-style modelling. system engineers can implement their models cross over into these three flexible modes of working easily. in the future, we will perform the experimentation of this preliminary prototype framework through long running testing scenarios. the real network deployment problem will be addressed by this prototype framework as expressed in [ipm13]. node failure, unreliable connection and buffer overflow scenarios will be injected into our co-simulation. the bottleneck problem will be tackled by limiting the queue size through long running simulation. “killer” traces will be seeked to validate formal event-b models. more dense network models will be considered in order to evaluate the reliability of this framework and explore the network congestion problem. code generation experiments from the node controller for the real node is still promising for our future work. open research issues are the node level co-simulation development and the extension for multi-cosimulation. bibliography [abhv06] j.-r. abrial, m. j. butler, s. hallerstede, l. voisin. an open extensible tool environment for event-b. in icfem. pp. 588–605. 2006. [abr07] j.-r. abrial. formal methods : theory becoming practice. journal of universal computer science 13(5):619–628, 2007. [abr10] j.-r. abrial. modeling in event-b: system and software engineering. cambridge university press, ny, usa, 1st edition, 2010. [acb10] m. allen, g. challen, j. brusey. designing for deployment. in guara et al. (eds.), wireless sensor networks. 2010. [adv13] advance. advance deliverable d4.2 (issue 2): methods and tools for simulation and testing i. technical report, march 2013. http://www.advance-ict.eu/sites/www.advance-ict.eu/files/advanced4.2-issue2. pdf [bis+08] g. barrenetxea, f. ingelrest, g. schaefer, m. vetterli, o. couach, m. parlange. sensorscope: out-of-the-box environmental monitoring. in ipsn. pp. 332–343. 2008. [bkl+10] j. f. broenink, c. kleijn, p. g. larsen, d. jovanovic, m. verhoef, k. pierce. design support and tooling for dependable embedded control software. in serene. pp. 77–82. 2010. proc. avocs 2014 14 / 15 http://www.advance-ict.eu/sites/www.advance-ict.eu/files/advanced4.2-issue2.pdf http://www.advance-ict.eu/sites/www.advance-ict.eu/files/advanced4.2-issue2.pdf eceasst [brwr10] j. beutel, k. roemer, m. woehrle, m. ringwald. deployment techniques for sensor networks. in sensor networks: where theory meets practice. pp. 219–248. 2010. [but09] m. butler. decomposition structures for event-b. in ifm. pp. 20–38. 2009. [dba08] k. damchoom, m. j. butler, j.-r. abrial. modelling and proof of a tree-structured file system in event-b and rodin. in icfem. pp. 25–44. 2008. [dbms13] a. didioui, c. bernier, d. morche, o. sentieys. harvwsnet:a co-simulation framework for energy harvesting wireless sensor networks. in icnc. pp. 808–812. 2013. [hkba09] t. s. hoang, h. kuruma, d. a. basin, j.-r. abrial. developing topology discovery in event-b. sci. comput. program. 74(11-12):879–899, 2009. [hsb10] o. heimlich, r. sailer, l. budzisz. nmlab: a co-simulation framework for matlab and ns-2. simul 0:152–157, 2010. [ipm13] a. intana, m. r. poppleton, g. v. merrett. adding value to wsn simulation through formal modelling and analysis. in sesena ’13. pp. 24–29. ieee, 2013. [ish10] m. imran, a. m. said, h. hasbullah. a survey of simulators, emulators and testbeds for wireless sensor networks. in itsim. pp. 897–902. 2010. [km07] w. kiess, m. mauve. a survey on real-world implementations of mobile ad-hoc networks. ad hoc netw. 5(3):324–339, apr. 2007. [ksw+08] a. köpke, m. swigulski, k. wessel, d. willkomm, p. t. k. haneveld, t. e. v. parker, o. w. visser, h. s. lichte, s. valentin. simulating wireless and mobile networks in omnet++ the mixim vision. in simutools. pp. 71:1–71:8. 2008. [mrdd10] p. matouek, o. ryav, g. s. de, m. danko. combination of simulation and formal methods to analyse network survivability. in simutools. p. 6. 2010. [pie10] g. p. pietro. software engineering and wireless sensor networks: happy marriage or consensual divorce? in foser. volume 4, pp. 283–286. 2010. [pm12] m. poppleton, g. merrett. towards a principled and evolvable approach to software development for future wireless sensor networks. in sesena. 2012. [sgd11] c. sommer, r. german, f. dressler. bidirectionally coupled network and road traffic simulation for improved ivc analysis. ieee tmc 10(1):3–15, 2011. [sphb11] r. silva, c. pascal, t. s. hoang, m. butler. decomposition tool for event-b. spe 41(2):199–208, 2011. [wb12] b. wang, j. s. baras. integrated modeling and simulation framework for wireless sensor networks. wetict 0:268–273, 2012. [wb13] b. wang, j. s. baras. hybridsim: a modeling and co-simulation toolchain for cyber-physical systems. ds-rt ’13 0:33–40, 2013. [wbls09] a. wang, p. basu, b. t. loo, o. sokolsky. declarative network verification. in padl ’09. pp. 61–75. 2009. [wtc03] a. woo, t. tong, d. culler. taming the underlying challenges of reliable multihop routing in sensor networks. in sensys. pp. 14–27. 2003. 15 / 15 volume 70 (2014) introduction related work case study s-style modelling f-style modelling overview of event-b modelling wsn development in event-b model decomposition, verification and validation c-style co-modelling focosim-wsn framework for wsns co-simulation case study modelling co-simulation prototype validation engineering process for c-style development conclusion and future work verification of safety requirements for program code using data abstraction electronic communications of the easst volume 23 (2009) proceedings of the ninth international workshop on automated verification of critical systems (avocs 2009) verification of safety requirements for program code using data abstraction f.p.m. stappers and m.a. reniers 17 pages guest editor: markus roggenbach managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst verification of safety requirements for program code using data abstraction f.p.m. stappers1 and m.a. reniers2 1 f.p.m.stappers@tue.nl 2 m.a.reniers@tue.nl department of mathematics and computer science, tu/e, p.o. box 513, 5600 mb eindhoven, the netherlands abstract: large systems in modern development consist of many concurrent processes. to prove safety properties formal modelling techniques are needed. when source code is the only available documentation for deriving the system’s behaviour, it is a difficult task to create a suitable model. implementations of a system usually describe behaviour in too much detail for a formal verification. therefore automated methods are needed that directly abstract from the implementation, but maintain enough information for a formal system analysis. this paper describes and illustrates a method by which systems with a high degree of parallelism can be verified. the method consists of creating an over-approximation of the behaviour by abstracting from the values of program variables. the derived model, consisting of interface calls between processes, is checked for various safety properties with the mcrl2 tool set. keywords: verification, safety requirements, translation, data abstraction, case study 1 introduction subcontracting, buying off-the-shelf-components, and outsourcing are common in companies that develop and build embedded systems [10, 21, 30]. these companies require high quality and fault free components. regrettably, when integrating components from different suppliers, unforeseen errors occur or unexpected behaviour is encountered [25]. since the number of components in industrial systems grow, more lines of code are needed to control the system’s behaviour [27]. to ensure that shipped systems are fault-free, tests are performed. unfortunately, the absence of errors cannot be guaranteed by executing tests. to prove the correctness of a system formal methods like model checking are needed [7]. usually, these models are built from the available documentation. however, if a system is developed under pressure (e.g., prototyping, limited resources, etc.) or hardly any information is available, the implementation often becomes the main source for deriving behavioural models. deriving models from documentation is hard. creating usable models from source code is even harder. without any abstraction techniques, the models are too big to be used for the analysis of behavioural properties. we observe that many relevant properties can be stated in terms of the interface calls between processes. by abstracting from internal actions, it is possible to combat state space explosions. nevertheless, the resulting models are still too large, because conditions (depending on values of program variables) determine if interface calls take place. 1 / 17 volume 23 (2009) mailto:f.p.m.stappers@tue.nl mailto:m.a.reniers@tue.nl verification of safety requirements for program code using data abstraction in this approach we abstract from variables and assignments and therefore systematically explore every alternative for every condition. this way an over-approximation of the possible interactions between the components is created, preserving a simulation relation [29]. the approach can be used for verifying safety requirements [19] on the interface communication in the sense that any safety requirement that holds for the over-approximation also holds for the real system. the goal of this paper is to assess the feasibility of the method sketched above by means of a case study. since modern languages consist of many features and hierarchical structures, this paper assumes that the source code for the control software of embedded systems is written in a simplified concurrency programming language (scpl, section 3). scpl incorporates the core features for describing concurrent imperative programs and the constructs found in the studied application. note that we do not incorporate object oriented design and complex data structures issues such as classes, inheritance and templates. we conjecture that most contemporary programming languages can be translated to mcrl2, though this needs further investigation. we also argue that it is possible to extend scpl, such that it explicitly deals with communication. in order to prove the practical value of the method it has been executed by hand on a large case study consisting of 236 parallel threads. based on our case study, we see no problems to automate the method. programs written in scpl are transformed to models in mcrl2 [14] for which safety requirements are verified. to show feasibility, the method is demonstrated on the implementation of a controller for a printer that manufactures printed circuit boards (pcbs). this paper is structured as follows. section 2 gives a brief introduction to the relevant fragments of the language mcrl2 and the modal µ -calculus. section 3 describes the translation from scpl to mcrl2 used to acquire the model for the different components. in section 4 and section 5 the abstraction technique is applied on an industrial system. it describes the system and the framework on which the case study is demonstrated. the case study demonstrates that we were able to prove useful requirements for this complex system. section 6 discusses related work. section 7 concludes with our results, discussion and future work. 2 preliminaries 2.1 syntax and semantics of mcrl2 an mcrl2 process is built from data-parameterised multi-actions and a collection of process operators. in this paper, a fragment of the syntax of the un-timed mcrl2 language is used. it is given by the following bnf: p ::= α p p + p p p·p p p‖p p ∂b(p) p γv (p) p x α ::= τ p a(~d) p α | α the small p indicates a choice between symbols in the expression of the bnf. in this syntax α denotes a multi-action. a multi-action consists of actions combined by the big |. the empty multi-action is denoted by τ . an action a(~d) consists of an action name a and possibility a data parameter vector ~d (the syntax of which is left unspecified). a multi-action represents the simultaneous execution of the constituent actions. proc. avocs 2009 2 / 17 eceasst processes are denoted by p. for processes, + denotes non-deterministic choice, i.e., a choice between behaviours, · denotes sequential composition, i.e., a process followed by another process, and ‖ denotes parallel composition, i.e., the interleaved execution of both processes. the operator ∂b blocks all actions from set b of action names, i.e., prevents the occurrence of the specified actions. γv applies the communications described by the set v to a process. a communication in the set v is of the form a1 | ··· | an → a. application of γv to a process means that any occurrence of the multi-action a1(~d) | ··· | an(~d) is replaced by a(~d), for any ~d. x is a reference to a process definition of the form x = p, i.e., the process x behaves as prescribed by p. the semantics associated with an mcrl2 process, as used in the mcrl2 tool set, is a transition system where the transitions are labelled by multi-actions. a more elaborate description of the syntax and (timed) semantics are given in [13, 14]. 2.2 modal µ -calculus modal µ -calculus formulae are used to describe behavioural properties. these properties are then automatically verified against a behavioural model described in mcrl2. modal formulae are specified in a variant of the modal µ -calculus extended with regular expressions [12] and data. the restricted fragment of the modal µ -calculus used in this paper is as follows: φ ::= false p [ρ]φ ρ ::= a p ρ ·ρ p ρ∗ a ::= a(~d) p ¬a(~d) p true in this syntax, φ represents a property, ρ represents a set of sequences of actions and a represents the presence of a data parameterised action a(~d), the absence of a data parameterised action ¬a(~d), or any given action (represented as true). the property false holds for no model. the property [ρ]φ states the property that φ holds in all states that can be reached by a sequence described by ρ . to describe action sequences concatenation and iteration can be used. a more elaborate description of the µ -calculus and its semantics can be found in [5, 12]. 3 modelling the systems behaviour creating a model that preserves the essentials of a system, which is still useful for simulation or verification purposes is difficult. depending on the requirements that are to be verified, different approaches and abstraction techniques need to be used. for large systems, the abstraction needs to be chosen such, that these properties can still be verified. in this paper, we try to verify safety requirements for a system, for which the behaviour is specified in more than 200 concurrent processes. if all statements are translated without a proper abstraction, it is merely impossible to verify properties due to the well-known state space explosion problem. therefore a systematic method is required that transforms code into a useful model, appropriate for current model checking techniques [7]. because the requirements can be formulated in terms of interface calls between concurrent processes, the abstraction is performed on the internal operations of the individual processes. by abstracting from internal data (e.g., values of variables), conditions cannot 3 / 17 volume 23 (2009) verification of safety requirements for program code using data abstraction be evaluated accurately. therefore, conditionals are replaced by non-deterministic choices between the alternatives. this creates an over-approximation of the systems behaviour, because potentially more behaviour can happen. if a safety property holds for the over-approximation, it must hold for the real system. on the other hand, if a safety property does not hold for the over-approximation, it may still hold for the real system. as indicated in the introduction, we describe our approach in simplified concurrency programming language (scpl). with scpl it is possible to specify a parallel program, because it has a notion of concurrency. the syntax of scpl is described by the following bnf: 〈program〉 ::= 〈program〉〈process〉 p 〈process〉〈process〉 ::= proc c = 〈statement〉 return 〈statement〉 ::= call n p x := e p 〈statement〉;〈statement〉 p if b then 〈statement〉 else 〈statement〉 fi p while b do 〈statement〉 od p do 〈statement〉 od p suspend p resume n a program consists of at least one process. a process consists of a unique identifier, the process identifier, and a body: a process with process identifier c and body of statements s is specified by means of proc c = s return. it is assumed that each program contains a process with process identifier init that represents the process that is to be activated initially. the body of a process consists of statements that denote calls to other processes call n (where n is a non-empty set of process identifiers), multi-assignments x := e, sequential compositions s; s′, conditionals if b then s else s′ fi, the (in)finite repetitions while b do s od and do s od; and statements suspend and resume n for the suspension and the continuation of (sets of) processes. we do not present a formal semantics of this language, because these programming constructs are relatively well-known. an informal semantics is given in the upcoming sections. 3.1 translation scheme the translation function a takes a program written in scpl and produces an mcrl2 specification, i.e., a tuple consisting of an initial process in mcrl2 and a set of mcrl2 process equations. for each process with identifier c in the scpl program, there exists a process equation defining the recursion variable xc in mcrl2. in the translation the following actions are used • starts(c) denotes a request for starting process c; • startr(c) denotes acceptance of the request for starting process c (by process c); • dones(c) denotes the return of process c (by c); • doner(c) denotes notification of termination for a run of process c; • suspends(c) denotes the suspension of process c. if a process gets suspended the calling process interprets the suspend signal as the relevant part of the process is finished and the calling process can continue; proc. avocs 2009 4 / 17 eceasst • resumer(c) denotes the acceptance of the request to resume process c; • resumes(c) denotes the request to resume process c that is suspended. start, done, suspend and resume denote the synchronizing actions between corresponding requests, which will be explained later in this section. assuming that the name of the initial procedure is init, the translation function a is defined as: a (p1 ···pk) = (∂bl (γe (γb(starts(init)·doner(init)‖( ∥∥ c∈pd xc)))), ⋃k i=1a ′ χi (pi)) where • bl ={starts, startr, dones, doner, resumes, resumer, suspends} denotes the set of blocked actions; • b = {starts | startr → start, dones | doner → done} denotes primitive communications; • e ={suspends | doner → suspend, resumes | resumer → resume} denotes the set of additional communications; • ∥∥ j∈j x j describes the processes running in parallel and is recursively defined as:∥∥ j∈/0 x j = τ, ∥∥ j∈j∪{k} x j = xk ‖ (∥∥ j∈j\{k} x j ) ; • the sets χi of process identifiers are pairwise disjoint and are disjoint from the set of recursion variables used to capture the processes defined within the program; • a ′ denotes the translation function for processes which is defined in the rest of this section. the encapsulation operator ∂bl and communication operators γe and γb are applied to the parallel composition of the processes to synchronize successful interface calls between processes and to block individual non-successful interface calls. the different local communication operators γe and γb are required to guarantee unique solutions. for example, γ{a|b→c,a|d→e}(a|b|d) has multiple outcomes, namely c|d and e|b. each process of the program is associated with at least one mcrl2 process equation by means of the translation function a ′ χi : one of these corresponds to the translated process, while the others are introduced to capture repetitions in the body of a process. to ensure that the introduced recursion variables differ from other recursion variables, the translation function is parameterized by a set of recursion variables χi that are free to be used and are chosen sufficiently large. we assume that the initialization process init can only be called from outside the system. 3.2 processes processes decompose the system’s functionality into smaller manageable parts, where each process carries out a specific task. if a task is too complex for a single process it is often refined by invoking other more basic processes. the behaviour of a process can be implemented as a 5 / 17 volume 23 (2009) verification of safety requirements for program code using data abstraction function, subroutine, procedure or some functional behaviour. the behaviour of an individual process is defined by statements placed in some order. let proc c = s return denote the implementation of a process, where c defines the process identifier and s defines the control flow and data transformations. a process can be invoked by using a call and when the process completes the set of tasks it will notify the calling process with a return. in scpl all processes that can be addressed are defined in the program. a process is either busy (by performing tasks) or idle. a busy process can become temporarily idle, until another process addresses the suspended process to continue. for processes that not have been suspended (e.g., are idle), the resume will not activate the execution of a process (e.g., the process stays idle). the translation function for a process is denoted by a ′ χ , where χ denotes the set of available recursion variables. the translation function for process identifier c and statement s is given by: a ′ χ (proc c = s return) = { xc = startr(c)·tp ·dones(c)·xc + resumer(c)·dones(c)·xc } ∪ep where (tp, ep) = a ′′χ,c(s) and a ′′ χ,c is the translation function for statements as defined in the following subsection. the first summand of the equation specifies the starting of the process. the second summand is used to reflect the call for resuming an idle process. the translation function is parameterised by the identifier c of the process that is being translated. this identifier is later used to notify that a process is suspended. 3.3 statements in this subsection the transformation a ′′ χ,c of statements is discussed. let p and q denote statements and b a boolean expression. interface calls an interface call contains a non-empty set of process identifiers. if the set contains one element, it behaves as a call to a single process. if the set contains more elements, it behaves like a call to multiple process, which need to be executed concurrently. a call simultaneously enables the start of the processes referred to in the set n. processes can only be started if they are idle. if a call is addressed to a busy process, the call is postponed until the process becomes idle after completing the current task entirely. for processes that are temporarily idle the call is also postponed. a process that performs a call, resumes after all called processes have either suspended or completed their tasks. the interface call statement is translated as follows: a ′′ χ,c(call n) = ( |n∈n starts(n)·|n∈n doner(n), ∅ ) where |n∈n α(n) is inductively defined as: |n∈∅ α(n) = τ, |n∈n∪{k} α(n) = α(k) | |n∈n\{k} α(n). since there is no need to introduce additional process equations, the second element is empty. proc. avocs 2009 6 / 17 eceasst assignments the multi-assignment statement x := e defines the atomic value update for the variables x1, . . . , xn with the values of e1, . . . , en. as discussed earlier, we choose to abstract from variables and the assignments to those. a multi-assignment is translated as follows: a ′′ χ,c(x := e) = (τ, ∅) where the assignment itself is translated to an internal non-observable action; there is no need for additional process equations. sequential composition almost every imperative programming language allows the execution of statements in a sequential order. it is evident, that the control flow depends on the sequential order and needs to be preserved. the translation for the sequential composition is as follows: a ′′ χ,c(p ; q) = (a ′′ φ ,c(p)·a ′′ ψ,c(q), ep ∪eq) where φ and ψ are sets of recursion variables such that φ ∩ψ = /0 and φ ∪ψ ⊆ χ . these sets can always be chosen large enough to allow for the subsequent translations to have enough fresh recursion variables available. take for example the set of recursion variables that contains a unique variable for each loop. conditionals the evaluation of a conditional depends on the values of variables. by abstracting from the values of variables, it is impossible to determine the outcome of a condition. therefore, conditionals are modelled as non-deterministic choices. the conditional statement is translated as follows: a ′′ χ,c(if b then p else q fi) = (a ′′ φ ,c(p) + a ′′ ψ,c(q), ep ∪eq) where φ and ψ are sets of recursion variables such that φ ∩ψ = /0 and φ ∪ψ ⊆ χ . these sets can always be chosen large enough to allow for the subsequent translations to have enough fresh recursion variables available. loops loops are used to repeat statements that need to be carried out several times in succession. loops are either used for computational purposes (for which they need to be finite) or for controlling the control flow (possibly infinite). loops are modelled by means of recursion variables. if a control loop is finite, it has a condition which determines whether or not to abort the loop. such a conditional choice is modelled as a non-deterministic choice (as is the case for conditionals). of course, for infinite loops, there is no reason to introduce such non-determinism. the reason for having infinite loops in scpl is that virtually all systems have a part that needs to run continuously during executing and for which it is not possible to abort this process. in these circumstances it must not be possible to end the control flow. an infinite loop and a finite loop are translated as follows: a ′′ χ,c(do p od) = (y,{ y = tp ·y}∪ep) a ′′ χ,c(while b do p od) = (y,{ y = tp ·y + τ}∪ep) 7 / 17 volume 23 (2009) verification of safety requirements for program code using data abstraction where y denotes a fresh recursion variable from χ , and tp and ep are defined as (tp, ep) = a ′′ χ\{y},c(p). note that an additional τ is required for a finite loop to make a non-deterministic choice between loop continuation or loop termination. processes suspension if a system runs multiple parallel processes, it is often desired to suspend the execution of a process before it may proceed. for this reason scpl has a statement that suspends a process. a ′′ χ,c(suspend) = (suspends(c)·resumer(c), ∅). process continuation processes that are suspended become (temporarily) idle, until another process requires the continuation. scpl offers a solution, that enables the continuation of a suspended processes by means of a resume statement. note, that when a process is idle (after completing a task), it cannot be resumed or started by a resume. as for interface calls, multiple processes can be resumed (concurrently) by a single resume. the resume statement is translated as follows: a ′′ χ,c(resume n) = ( |n∈n resumes(n)·|n∈n doner(n), ∅ ) . to illustrate the translation, consider the following example. example 1 (translation by example) consider a system with two concurrent processes init and p. process p has two computational parts, that should be suspended in between. init calls p and waits until p finishes the first computational part. when finished, the init process resumes p in order to execute the second part. proc init = call p; proc p = b:= true; resume p suspend; return b := false return after applying the transformation we obtain the following mcrl2 specification: xinit = startr(init)·starts(p)·doner(p)·resumes(p)·doner(p)·dones(init)·xinit + resumer(init)·dones(init)·xinit xp = startr(p)·τ ·suspends(p)·resumer(p)·τ ·dones(p)·xp + resumer(p)·dones(p)·xp with the following initialization: ∂bl (γe (γb(starts(init)·doner(init)‖xinit ‖xp))). the corresponding labelled transition system is depicted below: start(init) start(p) τ suspend(p) resume(p) τ done(p) done(init) proc. avocs 2009 8 / 17 eceasst 4 industrial application to test the approach, it is applied on an industrial system, called “lunaris” [26]. the lunaris is an etch resist printer, intended to operate in the manufacturing of printed circuit boards (pcbs). in current pcb production processes, the substrate is laminated with a photo resist and using a lithographic process the desired photo mask is created on the substrate. with the development of the lunaris, it is possible to skip the expensive task of creating the mask that is required for illuminating the photo resist. by directly printing the resist in the desired pattern, it is possible to create customized and individual pcbs at lower costs. this prototype printer has been developed for one year and has been extensively tested within this period. while the system has many physical components, we limit ourselves to verify behavioural system requirements at the level of the controller. at controller level, the lunaris consists of 245 multi-threaded tasks (running in parallel) that are implemented in c# [1]. the tasks specify behaviour for amongst others printing, movement of physical components, logging and error handling. in total 170.000 lines of code are needed to implement the behaviour. the code is distributed over 120 classes in 40 files. translating the code to mcrl2 directly is possible, however this will make any exhaustive verification technique useless. a brief analysis shows that more than 101000 transitions are needed, if we want to incorporate all behaviour. for this reason we apply the abstraction techniques proposed in section 3. the lunaris has 7 different axes over which mechanical components move. the areas in which they operate overlap each other. if two such mechanical components operate in the same area they may collide and cause damage to the system. by means of special rules in the controller this should be prevented. the controller must be defined by using a predefined set of tasks. in turn, these tasks can execute other tasks, which are not directly available to the controller. since we do not have access to the implementation of the controller, we allow the predefined tasks to be executed in arbitrary order, when performing the verification. different tasks run in parallel, but it is not possible to run the same task simultaneously multiple times. every task belongs to a certain activity type, e.g., logging, error handling, time delaying, ignore errors, operate hardware, etc. the tasks are called via a master-slave protocol. a task is a master if the task itself requests execution of another task. a task is a slave if another task requests its execution. we assume that the communication takes place over non-lossy channels. the following message types are communicated between tasks: start a master wants to start a task on a slave. done a slave indicates that a task has been successfully terminated. resume a master wants to resume a task on a slave. suspend a slave suspends the current process and notifies the master. by means of several simplifications we obtain processes described in scpl from the c# code for tasks. first, we only consider the tasks that are relevant for manufacturing a product. therefore, nodes that are exclusively used for logging and error-handling local to components are 9 / 17 volume 23 (2009) verification of safety requirements for program code using data abstraction excluded. this can be decided based on the activity types of the tasks. second, we only consider “good weather” behaviour. “good weather” behaviour is the assumption that the components behave without faults. this means that a printhead is not broken, the system prints when it is supposed to, communication channels are not lossy, etc. third, we assume that protocols used for communication are handled correctly by the framework and the embedded software is implemented according to the specification. for this reason we do not have to specify and verify the software that provides the communication or the software on the embedded systems. fourth, the execution of a task requires a certain amount of time. we decide not to model time aspects. this way, we prove that the correctness of the controller is not affected by performance. note that this decisions prohibits us to verify performance properties. fifth, for the initialization we assume the system is turned off and all components are positioned such that they reside in their initial position. finally, we apply a pre-processing step to the classes. we know for every class the number of objects it produces. therefore we can transform the object oriented program into a procedural multi-threaded program. after these simplifications, we obtain 236 single threaded process, running in parallel. based on their type of behaviour, the task templates can be decomposed into “execute tasks” and “switch tasks.” 4.1 execute tasks an execute task is a task that is executed once. an example of an execute task is moving the printhead device to a given position. when started, an execute task automatically completes after a finite amount of processing time. the semantic structure of an execute task becomes as the hierarchical state machine depicted in figure 1. a sub-task is indicated by a rectangle. single lined boxes indicate that the sub task consists of a single state. double lined boxes indicate that the sub task is a hierarchical state machine, which can send and receive different types of calls. idle executing start/-/done idle executing enabledstopping resume/start/-/suspend resume/-/done figure 1: state diagrams of an execute task and switch task the behaviour of an execute task with identifier c can be mapped to a process of the form: proc c = “executing” return proc. avocs 2009 10 / 17 eceasst 4.2 switch task a switch task is a task that whenever started, needs to be stopped explicitly. switch tasks are often used to enable hardware components (e.g., to enable controllers if the system reaches a certain run-level). if a switch task is invoked, it first executes some behaviour, after which it comes into a stable enabled state. there it waits, until it receives an external signal to resume and finalize the task. tasks that call a switch task, continue after the called switch task reaches the stable enabled state. a switch task can be mapped to the hierarchical state machine depicted in the right of figure 1. the behaviour of a switch task with identifier c is mapped to a process of the form: proc c = “executing”; suspend; “stopping” return 5 verification of framework properties to validate that the technique can be used to verify safety requirements, this section discusses the requirements that have been verified with the help of the obtained mcrl2 specification. the actions used in the formulae are obtained from the mcrl2 specification. to ensure correct behaviour, safety rules are formulated for the architecture. a safety rule is a condition that may not be violated by the execution of an action. the lunaris has two kinds of safety rules. the first set consists of eight rules which represents warnings. if such a rule is violated, the system will raise a warning, but will continue to operate. these safety requirements are of the form: the “switch task (st )” must be running if the “execute task (et )” is executed. such properties are expressed by the following formulae template: • an execute task et may not be started before the switch task st is “enabled:” [(¬suspend(st ))∗ ·start(et )]false ∧ [true∗ ·start(st )·(¬suspend(st ))∗ ·start(et )]false • an execute task et may not be stopped after the switch task st is being stopped: [true∗ ·start(et )·(¬done(et ))∗ ·resume(st )]false ∧ [true∗ ·start(et )·(¬done(et ))∗ ·done(st )]false the analysis shows that three of the eight safety rules are superfluous, i.e., a warning can not arise in any behaviour of the system (and hence do not occur if the controller implementation is without any flaws). the second class of rules consists of 30 safety properties which only allow the execution of a task (t ), if it is safe to do so. these tasks involve the movement of the printhead calibration system or shuttle. since they physically operate in each other’s workspace, it is possible that the system can incur physical damage if such a safety property is violated. as a result the system halts, if a rule is violated. to verify that the rules are valid throughout execution, temporal logic formulae of the conjunction of the following forms have been constructed (s, t , and u are actions), [true∗ ·s ·(¬t )∗ ·u ]false 11 / 17 volume 23 (2009) verification of safety requirements for program code using data abstraction where t is the task that may not be executed between tasks s and u . all of the formulae have been checked and four requirements are violated in the model. since the verification has been performed with a controller that is in no way restricted, the controller should contain restricted behaviour (e.g., should never perform tasks in a certain order) in order to rule out the requirement violations. translating the code by hand to the model, has been achieved by taking incremental steps that add more and more involved c#-files until we obtained a model without any deadlocks. if a deadlock was encountered in the model, it meant that the model was incomplete, e.g., a communication between interfaces was missing. in order to verify temporal formulae the specification is linearised to a linearised process specification. for all the requirements, this linearisation step has been executed just once. this took approximately 53 minutes on a computer with an intelr pentiumr d930 processor and 2 gb ram running linux. the subsequent verification for a single requirement took less than 15 minutes. 6 related work to determine if a system is free from programming bugs, inconsistencies, run-time errors, or non-portable constructs various tools like lint [9, 17], polyspace [16], and qa-c++ [24] can act as an extension to standard debuggers. when it comes to the verification of dynamic properties (deadlocks, unexpected behaviour) tools like java pathfinder [23] or steam [20] can be used. these tools use a virtual machine in which models are translated to byte code, and executed afterwards to verify properties. unfortunately, the size of the code is related to the underlying state space that needs to be explored, e.g., it becomes harder, or even impossible to verify dynamic safety properties. as stated by java pathfinder: “while software model checking in theory sounds like a safe and robust verification method, reality shows that it does not scale well.” one can argue that the work presented here is comparable to the theory of abstract interpretation. in abstract interpretation [22], abstract values are chosen for variables. behavioural models obtained via this approach depend on the (initial) values of data variables. consequently, it requires manipulation of the data variables. for relatively small systems, this method is fruitful. however, for larger systems, this may lead to a state space explosion, due to the number of parallel processes combined with the number of possible abstract data values. in order to verify larger systems, either a more coarse grained abstraction is required (thereby losing information) as we do in this paper or state space reduction techniques (symmetry reduction, bisimulation reduction, etc.) need to be applied. since almost every thread specifies unique behaviour, we could not benefit greatly from symmetry reduction. the application of bisimulation reduction techniques requires the generation of the underlying state space. without any abstraction techniques, the approximated size of the state space should roughly be 101000 states. work related to our method can also be found in the bandera tool set [8]. the bandera tool set translates java source code to a model, which is used to verify properties about the system by model checking techniques. unfortunately, large (software) systems lead to state spaces that are beyond today’s computational power. the bandera tool set itself, only accepts closed code. for proc. avocs 2009 12 / 17 eceasst this reason the system needs to be complete before it can be verified. with help of extensions it is possible to verify open systems (e.g., an environment generator for bandera [28]), but it still requires a full and correct implementation of a source code unit. since our method abstracts from variables we can deal with partly implemented units and code skeletons. the author of [18] presents a way for checking component behaviour compatibility, written in behaviour protocols and checked with the spin model checker afterwards. using ltl formulae, they manage to verify properties on a well documented system of 20 components. in our case study we tackled a bigger system running 230 concurrent processes, and performed a successful verification with a different tool set. next to that the semantics of our components differs: we cope with processes that can be suspended and need to be resumed afterwards, while the components mentioned in [18] do not facilitate this mechanism. work presented in [15] shows a method for directly deriving a promela specification from c code. this technique creates for every command a corresponding action in a promela specification. in [31] another approach is taken with promela. here experiments are conducted with a virtual machine based approach for state space generation. by evaluating the byte-code language, they provide a way to efficiently execute operational semantics for modelling and programming languages. undoubtedly, these techniques perform well on small toy examples for examining specific code constructs. however when changing the scope from specific code constructs to the control flow for examining larger concurrent systems, more rigorous techniques are required. in that sense, the method described in this paper can be viewed as an extension to their techniques. notice that our work shares resemblance with slam by ball et al. [3]. one of the slam approaches is based on refining the abstractions (in order to rule out spurious counter-examples), and turns software implementations into boolean programs [2]. the basic idea is to leave out data initially, and include it when needed later on. data that is included in the refinement applies to variables that are used in conditions. with help of a theorem prover and additional iterations for refinement the slam method tries to determine if it can solve the equations, thereby terminating the loop. in rare cases, it is possible that the theorem prover used by slam cannot solve the equations, which leads to a non-terminating algorithm. consequently, verifying safety requirements becomes impossible. our method does not use a theorem prover. if variables of a loop condition can change their values we assume that the condition eventually is violated, by which the loop terminates. counterexample-guided abstraction refinement (cegar) (see [6]) is an automatic iterative abstraction-refinement methodology for which a datapath abstraction results in an approximation of the original design, i.e., if the approximation turns out to be too coarse, the approximation is automatically refined up to a point for which it can either generate a counter example or disprove it. while this technique is adaptive, our method is not. therefore our approach can be seen as an instantiation of a first time right for cegar. in d-finder [4], a compositional method for checking invariance properties is presented. the basis of the method is an algorithm that iteratively computes invariants of components until they are strong enough to imply a global invariant that needs to be checked. in contrast with our method, where an over-approximation of the model is obtained, the method used in d-finder over-approximates the local properties of the components. another approach related to ours, can be found in verisoft [11]. their approach consists of a systematic exploration of a state space by executing arbitrary code written in any language. 13 / 17 volume 23 (2009) verification of safety requirements for program code using data abstraction they guarantee complete state space coverage up to some depth, hence a partial state space exploration. consequently, this only guarantees safety properties up to a certain depth/bound and not for the entire system. another related approach is program slicing [32]. this technique selects parts of the source code which are of interest to the values of specific variables. our approach takes this to the extreme, by abstracting from all the variables and focus on calls between interfaces. perhaps the technique of program slicing could also have been instrumental in abstracting from less relevant aspects of the model such as the logging of events. 7 concluding remarks in this paper, we have shown how safety properties can be verified for complex systems consisting of over more than 200 processes running in parallel. in particular, we have proposed a procedure for translating code specifying behaviour into mcrl2, with the help of an intermediate programming language preserving a simulation relation. although we explicit mention the use of mcrl2 model checker, this method can also be incorporated by other model checkers. the smallest state space that we were able to derive from the model consisted of 76256 unique states and 253145 transitions for 236 tasks running in parallel. the rather small amount of states results from the dependencies between the mutual nodes. in this paper, the method is described in terms of a general programming language scpl and modelling language mcrl2. in principle, the method can be used in combination with many implementation languages (c, c++, c#, pascal, delphi, java . . .) and verification languages that have similar constructs for describing behaviour such as synchronized communication, sorts to encode different processes and non-determinism. the semantics-preserving translation of a reallife programming language to mcrl2 is considered future work. another possibility for future work is to add resources in the model e.g., time to complete a task, power consumption or the network traffic weight. by adding these it is possible to check whether the model exceeds maximal outer limits or claim more resources than available. future research can be conducted in the area of model refinement. if a safety property does not hold, it might be that the property is violated as a result of the over-approximation. the same holds for a liveness property that is fulfilled. to determine if these are artifacts the relevant conditions and variables need to be incorporated in the model. while this is feasible to do by hand for small systems, it is impossible for industrial sized systems. therefore automatic model refinement, may be included in future research activities. finally, we are considering to study the over-approximation technique in isolation. for this approach, existing mcrl2 models that depend on data and for which the requirements are expressed independently of the data may be considered. on such models we may conduct experiments that indicate whether applying the abstraction technique from this paper significantly reduces the number of states and whether this helps in verifying requirements. acknowledgements this work is supported as part of the itea project twins 05004. we would like to thank nbg industrial automation for the opportunity to conduct the experiments on the lunaris, muck van weerdenburg for his assistance in obtaining the temporal formulae, proc. avocs 2009 14 / 17 eceasst and the reviewers for their constructive suggestions and valuable contributions. bibliography [1] tom archer and andrew whitechapel. inside c#. pro-developer series. microsoft press, second edition edition, 2002. [2] thomas ball and sriram k. rajamani. bebop: a symbolic model checker for boolean programs. in klaus havelund, john penix, and willem visser, editors, proceedings of the 7th international spin workshop on spin model checking and software verification (spin’00), stanford, ca, usa, volume 1885 of lncs, pages 113–130. springer, 2000. [3] thomas ball and sriram k. rajamani. automatically validating temporal safety properties of interfaces. in matthew b. dwyer, editor, proceedings of the 8th international spin workshop on model checking software (spin’01), toronto, ontario, canada, volume 2057 of lncs, pages 103–122. springer, 2001. [4] saddek bensalem, marius bozga, thanh-hung nguyen, and joseph sifakis. d-finder: a tool for compositional deadlock detection and verification. in ahmed bouajjani and oded maler, editors, proceedings of the 21st international conference on computer aided verification (cav 2009), grenoble, france, volume 5643 of lncs, pages 614–619. springer, 2009. [5] julian charles bradfield. verifying temporal properties of systems. progress in theoretical computer science. birkhäuser, 1992. [6] edmund clarke, orna grumberg, somesh jha, yuan lu, and helmut veith. counterexample-guided abstraction refinement for symbolic model checking. journal of the acm, 50(5):752–794, 2003. [7] edmund m. clarke, orna grumberg, and doron a. peled. model checking. mit press, 2000. [8] james c. corbett, matthew b. dwyer, john hatcliff, shawn laubach, corina s. pasareanu, robby, and hongjun zheng. bandera: extracting finite-state models from java source code. in proceedings of the 22nd international conference on software engineering (icse 2000), limerick, ireland, pages 439–448, 2000. [9] ian f. darwin. checking c programs with lint. o’reilly & associates, inc., sebastopol, ca, usa, 1988. [10] g. reza djavanshir. surveying the risks and benefits of it outsourcing. it professional, 7(6):32–37, 2005. [11] patrice godefroid. model checking for programming languages using verisoft. in proceedings of the 24th acm sigplan-sigact symposium on principles of programming languages (popl’97), paris, france, pages 174–186. acm press, 1997. 15 / 17 volume 23 (2009) verification of safety requirements for program code using data abstraction [12] jan friso groote and radu mateescu. verification of temporal properties of processes in a setting with data. in armando martin haeberer, editor, proceedings of the 7th international conference on algebraic methodology and software technology (amast 1998), amazonia, brasil, volume 1548 of lncs, pages 74–90. springer, 1999. [13] jan friso groote, aad mathijssen, michel reniers, yaroslav usenko, and muck van weerdenburg. the formal specification language mcrl2. in ed brinksma, david harel, angelika mader, perdita stevens, and roel wieringa, editors, methods for modelling software systems (mmoss), number 06351 in dagstuhl seminar proceedings, dagstuhl, germany, 2007. internationales begegnungsund forschungszentrum fuer informatik (ibfi), schloss dagstuhl, germany. [14] jan friso groote, aad h.j. mathijssen, michel a. reniers, yaroslav s. usenko, and muck j. van weerdenburg. analysis of distributed systems with mcrl2. in m. alexander and w. gardner, editors, process algebra for parallel and distributed processing, chapter 4, pages 99–128. taylor & francis group, 2009. [15] gerard j. holzmann. from code to models. in proceedings of the second international conference on application of concurrency to system design (acsd 2001), newcastle upon tyne, uk, pages 3–10. ieee computer society press, 2001. [16] polyspace inc. polyspace verification toolsuite. http://www.polyspace.com. [17] stephen curtis johnson. lint, a c program checker. technical report comp. sci. tech. rep. 65, bell laboratories, 1978. [18] jan kofron. checking software component behavior using behavior protocols and spin. in yookun cho, roger l. wainwright, hisham haddad, sung y. shin, and yong wan koo, editors, proceedings of the 2007 acm symposium on applied computing (sac’07), seoul, korea, pages 1513–1517. acm press, 2007. [19] leslie lamport. proving the correctness of multiprocess programs. ieee transactions on software engineering, 3(2):125–143, 1977. [20] peter leven, tilman mehler, and stefan edelkamp. directed error detection in c++ with the assembly-level model checker steam. in susanne graf and laurent mounier, editors, proceedings of the 11th international spin workshop on model checking software (spin), barcelona, spain, volume 2989 of lncs, pages 39–56. springer, 2004. [21] sesh murthy, rama akkiraju, richard goodwin, pinar keskinocak, john rachlin, frederick wu, james yeh, robert fuhrer, santhosh kumaran, alok aggarwal, martin sturzenbecker, ranga jayaraman, robert daigle, and jan a. van mieghem. coordinating investment, production, and subcontracting. manage. sci., 45(7):954–971, 1999. [22] flemming nielson, hanne r. nielson, and chris hankin. principles of program analysis. springer, 1999. [23] java pathfinder, august 2008. http://javapathfinder.sourceforge.net. proc. avocs 2009 16 / 17 eceasst [24] prqa. qa-c++ toolsuite. http://www.programmingresearch.com/. [25] c.v. ramamoorthy, c. chandra, h.g. kim, y.c. shim, and v. vij. systems integration: problems and approaches. in proceedings of the second international conference onsystems integration (icsi’92), morristown, nj, usa, pages 522–529, 1992. [26] nieke roos. océ geeft aanzet tot open innovatie in inkjet, august 2007. mechatronica magazine. [27] d.p. siewiorek, r. chillarege, and z.t. kalbarczyk. reflections on industry trends and experimental research in dependability. ieee transactions on dependable and secure computing, 1(2):109–127, april-june 2004. [28] oksana tkachuk, matthew b. dwyer, and corina s. pasareanu. automated environment generation for software model checking. in proceedings of the 18th ieee international conference on automated software engineering (ase 2003), montreal, canada, pages 116–129. ieee computer society press, 2003. [29] rob j. van glabbeek and ursula goltz. equivalence notions for concurrent systems and refinement of actions (extended abstract). in antoni kreczmar and grazyna mirkowska, editors, proceedings of mathematical foundations of computer science 1989 (mfcs’89), porabka-kozubnik, poland, volume 379 of lncs, pages 237–248. springer, 1989. [30] joost van lier, inneke van nieuwenhuyse, liesje de boeck, ton dohmen, nico vandaele, and marc lambrecht. benefits management and strategic alignment in an it outsourcing context. in proceedings of the 40th hawaii international international conference on systems science (hicss-40 2007), waikoloa, big island, hi, usa. ieee computer society press, 2007. [31] m. weber. an embeddable virtual machine for state space generation. in d. bosnacki and s. edelkamp, editors, proceedings of the 14th international spin workshop on model checking software (spin), berlin, germany, volume 4595 of lncs, pages 168–186. springer, 2007. [32] mark weiser. program slicing. in proceedings of the 5th international conference on software engineering (icse’81), san diego, ca, usa, pages 439–449. ieee computer society press, 1981. 17 / 17 volume 23 (2009) introduction preliminaries syntax and semantics of mcrl2 modal -calculus modelling the systems behaviour translation scheme processes statements industrial application execute tasks switch task verification of framework properties related work concluding remarks july 25th, 2014, university of york, uk electronic communications of the easst volume 68 (2014) proceedings of the 8th international workshop on graph-based tools (grabats 2014) july 25th, 2014, university of york, uk a satellite event of icgt’14 guest editors: matthias tichy, bernhard westfechtel managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst preface a wide variety of graph-based tools have emerged, including e.g. tools for visual languages, model driven development (editing, analysis, simulation, and transformation of models), data analysis, pattern recognition, software evolution, and efficient graph algorithms. in all of these areas, tools are developed that retrieve, store, transform, and display graphs. it is the purpose of this workshop to survey the state of the art of graph-based tools, bring together developers of graph-based tools in different application fields and to encourage new tool development cooperations. this volume contains the proceedings of grabats 2014, the 8th international workshop on graph based tools. grabats 2014 was held as a workshop co-located with icgt 2014, the 7th international conference on graph transformation, in york, uk. this workshop continues the grabats series of workshops that serve as a forum for researchers and practitioners interested in the development and application of practical graph-based tools. previous workshops were held in 2002 (barcelona, spain), 2004 (rome, italy), 2006 (natal, brazil), 2008 (leicester, uk), 2009 (zurich, switzerland), 2010 (enschede, the netherlands), and 2012 (bremen, germany). the format of the workshop varied over the years. in most issues (as in the current one), papers were presented and collected in workshop proceedings. in 2008/2009, grabats was held as a tool transformation contest, which was continued as a separate event and was held in parallel under the joint umbrella of staf 2014. this year we received 10 regular submissions. from these, 4 papers were accepted for the grabats proceedings. we would like to thank the members of the program committee and the external reviewers for their excellent work. we are also indebted to the members of the icgt/staf organization committee who provided outstanding support for running the grabats workshop smoothly. last but not least, we would like to express our thanks to tobias heindel, who enriched the grabats program by his invited talk. september 2014 matthias tichy, bernhard westfechtel pc chairs of grabats 2014 1 / 2 volume 68 (2014) preface of grabats 2014 program committee • artur boronat, university of leicester (uk) • claudia ermel, technical university of berlin (germany) • joel greenyer, university of hannover (germany) • esther guerra, universidad autónoma de madrid (spain) • dimitris kolovos, university of york (uk) • christian krause, sap innovation center potsdam (germany) • tihamér levendovszky, vanderbilt university (usa) • mark minas, universität der bundeswehr münchen (germany) • arend rensink, university of twente (the netherlands) • gabriele taentzer, philipps-universität marburg (germany) • matthias tichy, chalmers university / university of gothenburg (sweden) • pieter van gorp, eindhoven university of technology (the netherlands) • hans vangheluwe, university of antwerp (belgium) / mcgill university (canada) • gergely varró, technische universität darmstadt (germany) • bernhard westfechtel, university of bayreuth (germany) • andreas winter, carl von ossietzky university, oldenburg (germany) • albert zündorf, university of kassel (germany) external reviewers tobias george, marcel hahn proc. grabats 2014 2 / 2 perface electronic communications of the easst volume 48 (2011) proceedings of the fifth international workshop on foundations and techniques for open source software certification (operncert 2011) preface 2 pages guest editors: luis soares barbosa, dimitrios settas managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst preface over the past decade, the free/libre/open source software (floss) phenomenon has had a global impact on the way software systems and software-based services are developed, distributed and deployed. widely acknowledged benefits of floss include reliability, low development and maintenance costs, as well as rapid code turnover. linux distributions, apache and mysql server, among many other examples, can be mentioned as a testimony to its success and resilience. such a success has brought with it an increasing interest to use floss for complex and industrial-strength applications. however, state-of-the-art oss, by the very nature of its open, unconventional, distributed development model, make software quality assessment, let alone full certification, particularly hard to achieve and raises important challenges both from the technical/methodological and the managerial points of view. in such a context, the aim of the opencert series of workshops is to bring together researchers from the academia and the industry interested in the quality assessment of floss, and ultimately provide a platform for the establishment of a coherent certification process for floss. the 1st international workshop on foundations and techniques for open source software certification (opencert 2007) was held on 31 march 2007 in braga, portugal, as a satellite event of etaps 2007. from then on opencert run regularly every year. in 2008, jointly with the international workshop on foundations and techniques bringing together free/libre open source software and formal methods (floss-fm 2008), was held as a satellite event of oss 2008, in mlian, italy. in 2009 it was organised again as a satellite event of etaps, in york, united kingdom. finally, in 2010, the 4th opencert workshop took place in pisa, italy, as a satellite event of sefm. the post-proceedings were published in volume 33 of the electronic communications of the easst. a special issue collecting the most significative papers of previous workshops is currently under preparation to appear in science of computer programming. this volume contains the post-proceedings of the 5th international workshop on foundations and techniques for open source software certification (opencert 2011) held on 15 november 2011, in montevideo, uruguay, as a satellite event of sefm’2011, the 9th international conference on software engineering and formal methods. it includes a total of four regular papers and two short contributions, which were selected among ten submissions, each of them reviewed by at least two program committee members. it also includes the full text of two invited talks, one by antonio cerone, from unu-iist, and another by ezequiel bazan eixarch, gustavo betarte and carlos luna, from universidad nacional de rosario, argentina, and universidad de la república, uruguay, respectively. the editors would like to express their gratitude to all members of the program committee for their hard work and support. the result in your hands would not have been possible without their effort and commitment. 1 / 2 volume 48 (2011) preface thanks extend, of course, to all members of the sefm’2011 organising committee, in particular to alberto pardo, sefm conference chair, who was most helpful in all occasions, and the staff at the universidad de la república, montevideo, for their logistical, administrative and technical support. luı́s soares barbosa (inesc tec, universidade do minho) dimitrios settas (unu-iist, united nations university) proc. opencert 2011 2 / 2 symbol elimination for automated generation of program properties electronic communications of the easst volume 70 (2014) proceedings of the 14th international workshop on automated verification of critical systems (avocs 2014) symbol elimination for automated generation of program properties laura kovács 2 pages guest editors: marieke huisman, jaco van de pol managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst symbol elimination for automated generation of program properties laura kovács∗ chalmers university of technology abstract: automatic understanding of the intended meaning of computer programs is a very hard problem, requiring intelligence and reasoning. in this talk we describe applications of our symbol elimination methods in automated proram analysis. symbol elimination uses first-order theorem proving techniques in conjunction with symbolic computation methods, and derives nontrivial program properties, such as loop invariants and loop bounds, in a fully automatic way. moreover, symbol elimination can be used as an alternative to interpolation for software verification. keywords: program analysis, symbolic computation, automated reasoning, interpolation, invariant generation extended abstract individuals, organizations, industries, and nations are increasingly depending on software and systems using software. this software is large and complex and integrated in a continuously changing complex environment. new languages, libraries and tools increase productivity of programmers, creating even more software, but the reliability, safety and security of the software that they produce is still low. we are getting used to the fact that computer systems are errorprone and insecure. software errors cost world economies billions of euros. they may even result in loss of human lives, for example by causing airplane or car crashes, or malfunctioning medical equipment. to improve software and methods of software development one can use a variety of approaches, including automated software verification and static analysis of programs. the results summarised in this abstract describe how the combination of automated reasoning and symbolic computation methods can be used for automatic program analysis. program analysis aims to discover program properties preventing programmers from introducing errors while making software changes and can drastically cut the time needed for program development, making thus a crucial step to automated verification. the common method of all results presented here is the so-called symbol elimination method. although the symbol elimination terminology has been introduced only recently by us, we argue that symbol elimination can be viewed as a general framework for software verification. that is, various techniques used in software verification, such as gröbner basis computation or quantifier elimination, can be seen as application of symbol elimination to safety verification of programs. in a nutshell, symbol elimination is based on the following ideas. suppose we have a program p with a set of variables v . the set v defines the language of p. we extend the language p to ∗ this work was partially supported by swedish vr grant d0497701 and the austrian reserach projects fwf s11410n23 and wwtf ict c-050. 1 / 2 volume 70 (2014) symbol elimination for automated generation of program properties a richer language p0 by adding functions and predicates, such as loop counters. after that, we automatically generate a set π of first-order properties of the program in the extended language p0, by using techniques from symbolic computation and theorem proving. these properties are valid properties of the program, however they use the extended language p0. at a last step of symbol elimination we derive from π program properties in the original language p, thus “eliminating” the symbols in p0 \ p. the work summarized in this abstract is concerned with the algorithmic treatment of symbol elimination for generating computer program properties such as loop invariants, loop iteration bounds, interpolants, and postconditions. we start by first presenting how symbol elimination is used in symbolic computation for analysing program loops and inferring loop invariants and postconditions. our work uses algorithmic combinatorics and algebraic techniques, namely solving linear recurrences with constant coefficients, computing algebraic relations among exponential sequences, and eliminating variables from a system of polynomial equations using gröbner basis computation and quantifier elimination techniques. we also describe applications of symbol elimination in the timing analysis of programs, or, more generally, for analysing the worse-case execution times of programs. we further extend our work and present how symbol elimination is applied in first-order theorem proving for generating quantified loop invariants and interpolants. unlike all previously known techniques, our method allows one to generate first-order invariants containing alternations of quantifiers. the method is based on automatic analysis of the so-called update predicates of loops. we observe that many properties of update predicates can be extracted automatically from the loop description and loop properties obtained by other methods such as a simple analysis of counters occurring in the loop, recurrence solving and quantifier elimination over loop variables. the key ingredient of symbol elimination for generating quantified program properties is then first-order saturation theorem proving. after observing that symbol-eliminating inferences extracted from first-order proofs of program properties can be used for automatic invariant generation and that interpolants obtained from proofs seem to be better for predicate abstraction and invariant generation than those obtained by quantifier elimination, we conclude that symbol elimination can be a key concept for applications of program analysis and verification. acknowledgements: the results described in this abstract are based on a joint work with ioan dragan (tu vienna), jens knoop (tu vienna), andrei voronkov (u. manchester), and jakob zwirchmayr (irit). proc. avocs 2014 2 / 2 clang and coccinelle: synergising program analysis tools for cert c secure coding standard certification electronic communications of the easst volume 33 (2010) proceedings of the fourth international workshop on foundations and techniques for open source software certification (opencert 2010) clang and coccinelle: synergising program analysis tools for cert c secure coding standard certification mads chr. olesen, rené rydhof hansen, julia l. lawall, nicolas palix 18 pages guest editors: luis s. barbosa, antonio cerone, siraj a. shaikh managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst clang and coccinelle: synergising program analysis tools for cert c secure coding standard certification mads chr. olesen1, rené rydhof hansen1, julia l. lawall2, nicolas palix2 1rrh,mchro@cs.aau.dk, http://www.cs.aau.dk 2julia,npalix@diku.dk, http://www.diku.dk abstract: writing correct c programs is well-known to be hard, not least due to the many language features intrinsic to c. writing secure c programs is even harder and, at times, seemingly impossible. to improve on this situation the us cert has developed and published a set of coding standards, the “cert c secure coding standard”, that (in the current version) enumerates 118 rules and 182 recommendations with the aim of making c programs (more) secure. the large number of rules and recommendations makes automated tool support essential for certifying that a given system is in compliance with the standard. in this paper we report on ongoing work on integrating two state of the art analysis tools, clang and coccinelle, into a combined tool well suited for analysing and certifying c programs according to, e.g., the cert c secure coding standard or the misra (the motor industry software reliability assocation) c standard. we further argue that such a tool must be highly adaptable and customisable to each software project as well as to the certification rules required by a given standard. clang is the c frontend for the llvm compiler/virtual machine project which includes a comprehensive set of static analyses and code checkers. coccinelle is a program transformation tool and bug-finder developed originally for the linux kernel, but has been successfully used to find bugs in other open source projects such as wine and openssl. keywords: automated tool support, cert c secure coding, certification, clang, coccinelle 1 introduction writing correct c programs is well-known to be hard. this is, in large part, due to the many programming pitfalls inherent in the c language and compilers, such as low-level pointer semantics, a very forgiving type system and few, if any, run time checks. writing a secure c program is even more difficult, as witnessed by the proliferation of published security vulnerabilities in c programs: even seemingly insignificant or “small” bugs may lead to a complete compromise of security. in an effort to improve the quality of security critical c programs, the us cert1 organisation is maintaining and developing a set of rules and recommendations, called the cert c secure 1 formerly known as the us computer emergency response team (www.cert.org) 1 / 18 volume 33 (2010) mailto:rrh,mchro@cs.aau.dk http://www.cs.aau.dk mailto:julia,npalix@diku.dk http://www.diku.dk www.cert.org clang and coccinelle: the best of two worlds coding standard (ccscs), that programmers should observe and implement in c programs in order to ensure at least a minimal level of security. the current version of the ccscs enumerates 118 rules and 182 recommendations covering topics ranging from proper use of c preprocessor directives and array handling to memory management, error handling and concurrency. the sheer number of rules and recommendations makes it almost impossible for a human programmer to manually guarantee, or even check, compliance with the full standard. automated tool support for compliance checking is therefore essential. in this paper we describe work in progress on a prototype tool for automated ccscs compliance checking. the tool is based on the open source program analysis and program transformation tool coccinelle that has been successfully used to find bugs in the linux kernel, the openssl cryptographic library [lbp+09, llh+10, plm10], and other open source infrastructure software. coccinelle is scriptable using a combination of a domain specific language, called smpl for semantic patch language, as well as in o’caml and python. the scripts specify search patterns partly based on syntax and partly on the control flow of a program. this makes coccinelle easily adaptable to new classes of errors and new codebases with distinct api usage and code style requirements. coccinelle does not perform program analysis in the traditional sense, e.g., data flow analysis or range analysis. however, for the purposes of program certification and compliance checking such analyses are essential, both to ensure soundness of the certification and to improve precision of the tool. for this reason we integrate the clang static analyzer with coccinelle in order to enable coccinelle to use the analysis (and other) information found by clang. the clang static analyzer is part of the c frontend for the llvm project2. in addition to classic compiler support, it also provides general support for program analysis, using the monotone framework, and a framework for checking source code for (security) bugs. the emphasis in the source code checkers of the clang project is on minimising false positives (reporting “errors” that are not really errors) and thus is likely to miss some real error cases. to further enhance the program analysis capabilities of clang, in particular for inter-procedural program analyses, we have integrated a library, called wali 3 for program analysis using weighted push-down systems (wpds)[rsjm05] into clang. to enable rapid prototyping and development of new or specialised analyses, we have implemented python bindings for the wali library. the rest of the paper is organised as follows. in section 2 we give an overview of the cert c secure coding standard including a brief description of the rule categories. section 3 illustrates how a few of the coding rules can be automatically checked using the coccinelle tool. section 4 describes how the coccinelle rules can benefit from having access to program analysis information. section 5 discusses current work in progress, including experiments and the integration of clang and coccinelle. finally section 7 concludes. 2 the cert c secure coding standard the cert c secure coding standard (ccscs) is a collection of rules and recommendations for developing secure c programs. one version of the ccscs was published in 2008 as [sea08]. 2 web: http://clang.llvm.org 3 web: http://www.cs.wisc.edu/wpis/wpds/ proc. opencert 2010 2 / 18 http://clang.llvm.org http://www.cs.wisc.edu/wpis/wpds/ eceasst code short name long name # of rules # of recomm. 01 pre preprocessor 4 12 02 dcl declarations and initialization 9 22 03 exp expressions 11 21 04 int integers 7 18 05 flt floating point 8 6 06 arr arrays 8 3 07 str characters and strings 9 12 08 mem memory management 6 13 09 fio input output 15 20 10 env environment 3 5 11 sig signals 6 3 12 err error handling 4 8 13 api application programming interfaces n/a 10 14 con concurrency 6 2 49 msc miscellaneous 10 23 50 pos posix 12 4 figure 1: categories in the cert c secure coding standard however, in this paper we focus on the version currently being developed. the development process is collaborative through the ccscs’ web site4. the current version5 of the ccscs consists of 118 rules and 182 recommendations. the rules and recommendations are divided into 16 categories covering the core aspects of the c programming language. figure 1 shows an overview of these categories and a summary of the number of rules and recommendations in each category. 2.1 overview of the ccscs experience shows that when programming in c, certain programming practises and language features, e.g., language features with unspecified (or compiler dependent) behaviour result in insecure programs or, at the very least, in programs that are hard to understand and check for vulnerabilities. this experience is at the heart of the ccscs. many of the observed problems arise when programmers rely on a specific compiler’s interpretation of behaviour that is undefined in the ansi standard for the c programming language (ansi c99). other problems are caused, or at least facilitated, by the flexibility of the c language and the almost complete lack of run-time checks. based on the observed problems, the us cert has identified a number of key issues and developed a set of rules that specify both how to avoid problematic features and also constructively how to use potentially dangerous constructs in a secure way, e.g., programming patterns for securely handling dynamic allocation and de-allocation of memory. the rules in the ccscs are 4 web: https://www.securecoding.cert.org/confluence/display/seccode/cert+c+secure+coding+standard 5 last checked 6 july 2010 3 / 18 volume 33 (2010) https://www.securecoding.cert.org/confluence/display/seccode/cert+c+secure+coding+standard clang and coccinelle: the best of two worlds almost all unambiguous, universal and generally applicable in the sense that they do not depend on the specific application being developed. furthermore the rules are, for the most part, formulated at the level of individual source files or even parts of source files and thus require little or no knowledge of the surrounding application or the context in which it is used. this makes the rules potentially ideally suited for automated checking, although see section 3 for a more detailed discussion of this. in addition to the above mentioned rules, the ccscs also contains an even larger number of recommendations. the recommendations often represent the best practise for programming secure systems. in contrast to the rules, the recommendations are not limited to constructs that are local to a single file or function, but may also cover more global issues such as how to handle sensitive information, how to use and implement apis, how to declare and access arrays, and so forth. while most of the recommendations are still amenable to automated analysis, it may take more work and, in particular, it will require configuring and specialising the automated tool to the specific project being checked, e.g., by specifying which data in the program may contain sensitive information or which macros that are considered safe or how to canonicalize file names. a programmer is not required to follow the recommendations in order to be compliant with the ccscs. the ccscs is much too large to cover in detail here, instead we give a brief overview of the different categories and the kind of (potential) errors they are designed to catch. in section 3 we focus on a few specific rules and discuss them in more detail. 2.2 categories of the ccscs preprocessor (01-pre). the rules and recommendations in this category are concerned with proper use of the c preprocessor. most (large) c projects use preprocessor directives, especially macro definitions, extensively. since these can dramatically change the “look” of a program, it is very important at least to avoid the many common pitfalls enumerated in this category. many static analysis tools are not very good at checking these rules since they typically work on the expanded code and thus do not even see the macros. this is unfortunate since a lot semantic information can be gleaned from well-designed macros and their use. declarations and initialization (02-dcl). the rules and recommendations in this category mostly cover tricky semantics of the type system and variable declarations such as implicit types, scopes, and conflicting linkage classifications. the recommendations in this category codify good programming practises, e.g., using visually distinct identifiers (dcl02-c) and using typedefs to improve code readability (dcl05-c). while many of the recommendations can be automatically verified while others (like dcl05-c) require human interaction. expressions (03-exp). the rules and recommendations in this category are concerned with issues related to expressions, including (unspecified) evaluation orders, type conversions, sizes of data types, general use of pointers, and so forth. below we show how rule exp34-c (do not dereference null pointers) can be checked using the coccinelle tool. proc. opencert 2010 4 / 18 eceasst integers (04-int). the rules and recommendations in this category are concerned with issues related to proper handling of integers. the main emphasis for the rules is on avoiding overflows and wrap-around for very large or very small integer values. automated checking for these rules can be difficult since that may require sophisticated data flow or interval analysis. alternatively, a tool can instead check that a program includes sufficient checking in the program itself to avoid the dangerous situations. in some cases it is possible to use coccinelle to automatically insert the proper checks. however, inserting such checks automatically would seem to violate the point of a security certification. the recommendations are similarly concerned with conversions, limits and sizes of the integer types. like the rules in this category, automated checking of the recommendations can be difficult and require sophisticated analysis. floating point (05-flp). the rules and recommendations in this category are concerned with issues relating to proper handling of floating point types: loss of precision, proper use of mathematical functions, and type conversion. automated checking is at least as difficult as for the integer case. arrays (06-arr). the rules and recommendations in this category focus on avoiding out of bounds array indexing and pointer access to arrays. automated checking is likely to require pointer analysis in order to ensure correctness and to minimise false positives. characters and strings (07-str). the rules and recommendations in this category are concerned with: ensuring that strings are null terminated, proper size calculation of strings, and bounds checking for strings. memory management (08-mem). the rules and recommendations in this category cover some of the many pitfalls surrounding dynamic memory allocation, including not accessing freed memory, do not “double free” memory, only freeing dynamically allocated memory and so forth. implementing memory management correctly is notoriously difficult and even small bugs in this category are likely to result in a security vulnerability, e.g., a buffer overflow or a null pointer dereference. below we discuss rule mem30-c (do not access freed memory) in more detail and show how it can be checked using coccinelle. input output (09-fio). the rules and recommendations in this category are mainly concerned with the proper use of library functions for (file) input and output, including proper opening and closing of files, creation of temporary files, as well as secure creation of format strings. environment (10-env). the rules and recommendations in this category are concerned with proper handling of the execution environment, i.e., environment variables, and calls to external command processors are covered by the rules and recommendations in the env category. 5 / 18 volume 33 (2010) clang and coccinelle: the best of two worlds signals (11-sig). the rules and recommendations in this category are concerned with raising and handling signals in a secure manner, including ensuring that signal handlers do not call longjmp() and do not modify or access shared objects. error handling (12-err). the rules and recommendations in this category are concerned with detecting and handling errors and proper handling of the errno variable. examples include not modifying the errno variable and not relying on indeterminate values of errno. below we discuss the rule err33-c (detect and handle errors) in more detail and examine how coccinelle can be used to check this rule. note that this rule is different from most other rules in that it is actually application dependent since errors are detected and handled differently in different applications. consequently, in order for an automated tool to support checking of this rule, it must be possible to customise and adapt the tool to a specific project’s error handling strategy. application programming interface (13-api). in the version of ccscs currently under development, this category has no rules, only recommendations, since proper api design is highly application specific. similar to the error handling (err) category above, automated tool support requires a very adaptable tool. concurrency (14-con). the rules and recommendations in this category are general observations concerning concurrent programming such as avoiding race conditions and deadlocks (by locking in a predefined order). miscellaneous (49-msc). the rules and recommendations in this category are those that do not fit into any other category, e.g., it is recommended to compile cleanly at high warning levels (msc00-c) and it is a rule that a non-void function’s flow of control never reaches the end of the function (msc37-c). below we discuss rule msc37-c (ensure that control never reaches the end of a non-void function) in more detail and show how this rule can be checked using coccinelle. posix (50-pos). the rules and recommendations in this category cover compliance with and proper use of posix. in particular things to avoid doing with posix, such as calling vfork() and not using signals to terminate threads. 3 compliance checking with coccinelle in this section we discuss how four rules, from the ccscs categories presented in the previous section, can be checked using the coccinelle tool. before going into the details of the individual rules, we briefly introduce coccinelle; for lack of space we cannot give a thorough introduction to coccinelle and the languages used to script it, instead we refer to previous work [lbp+09, bdh+09, plhm08]. the coccinelle tool was originally developed to provide support for documenting and automating updates to linux device drivers necessitated by a change in the underlying api, the proc. opencert 2010 6 / 18 eceasst so-called collateral evolutions [plhm08]. finding the right place to perform collateral evolutions in a large code base requires a highly configurable and efficient engine for code searching. in coccinelle this engine is based on model checking of a specialised modal logic, called ctlvw, over program models [bdh+09] enabling search not only for specific syntactic patterns but also for control flow patterns. individual program searches (and transformations) are specified in a domain specific language, called smpl (for semantic patch language), designed to be similar to the unified patch format widely used by linux kernel developers and other open source developers. such program searches are called semantic patches or even coccinelle scripts. the combination of easy configurability and efficient search capabilities makes coccinelle an excellent tool for searching for code patterns that may lead to potential bugs or violations of coding standards. it has been successfully used to search for bugs in open source infrastructure software such as the linux kernel and the openssl cryptographic library [lbp+09, llh+10]. the coccinelle tool is released under the gnu gplv2 open source license. 3.1 dcl32-c: guarantee that mutually visible identifiers are unique the ansi c99 standard for the c programming language specifies that at least 63 initial characters are significant in an identifier. thus, identifiers that are share a 63 character long prefix may be considered identical by the compiler. the dcl32-c rule requires that all (in scope) identifiers are unique, i.e., must differ within the first 63 characters. below a coccinelle semantic patch is shown that simply searches for all variable declarations. this simple search forms the heart of the semantic patch used to search for potential violations of the dcl32-c rule: 1 @@ 2 type t; 3 identifier id; 4 @@ 5 t id; observe that this is very similar to what a variable declaration looks like in a c program. in figure 2 the full semantic patch is shown. it simply collects all identifiers of length 63 or more and warns if there are (potential) violations of the rule. the rule does not take the scope of the declared identifiers into account and thus may give rise to unnecessary warnings (false positives). however, since identifiers of length 63 or more are rarely used this is unlikely to be a problem in practise. if, for a specific project, it turns out to be a problem, the semantic patch can be extended to take more scope information into account. the semantic patch includes a simple o’caml script (lines 11 to 21) that collects all the found identifiers (of length 63 or more) and adds them to a hash table. before adding an identifer to the hash table, it is checked for collisions, and thus potential violations, and a warning is printed if there are (potential) collisions (line 18). the basic semantic patch searching for declarations has been augmented with a position metavariable denoted @pos (line 9). the position meta-variable is bound to the position (line and column number) of each match. 7 / 18 volume 33 (2010) clang and coccinelle: the best of two worlds 1 @ initialize:ocaml @ 2 let idhash = hashtbl.create 128 3 4 @ decl @ 5 type t; 6 identifier id; 7 position pos; 8 @@ 9 t id@pos; 10 11 @ script:ocaml @ 12 p << decl.pos; 13 x << decl.id; 14 @@ 15 if (string.length(x)) >= 63 then 16 let sid = string.sub x 0 63 in 17 let _ = if (hashtbl.mem idhash sid) then 18 print_endline (warn p "dcl32-c" "found long (%d) identifier ’%s’" 19 (string.length(x)) x) 20 else () in 21 hashtbl.add idhash sid (x,p) figure 2: coccinelle script to find “long” identifiers. 3.2 exp34-c: do not dereference null pointers in the ccscs, the rationale for this rule is that attempts to dereference null pointers result in undefined behaviour. in recent years, attackers and vulnerability researchers have had great success at leveraging null pointer dereferences into full blown security vulnerabilities, making this rule very important for application security. the current version of the ccscs contains an example involving the linux kernel and the tun virtual network driver. one potential source of null pointers, as noted in the ccscs examples, is when memory allocation functions, e.g., malloc(), calloc(), and realloc(), fail and return null. if the return value from allocation functions is not properly checked for failure, and handled accordingly, there is a high risk that a program will eventually, or can be made to, dereference a null pointer. using coccinelle to find such code patterns is straightforward. in figure 3 the corresponding semantic patch is shown: we first look for calls to the relevant allocation functions (lines 8 to 14). the possible allocation functions are specified using the disjunction pattern (denoted by ‘(’, ‘|’, and ‘)’) that succeeds if either of the alternatives (separated by ‘|’) match. following that, the script looks for a control flow path, represented by ‘...’, where the identifier (x) is not assigned to, i.e., a path where it is not modified (line 15), and where the identifier is not tested for “nullness” (line 16). the latter is in order to cut down on the number false positives. here the ‘... when != x = e’ and the ‘when != if(e == null) s1 else s2’ means along any control flow path where assignment to x does not occur, i.e., any control flow path where x is not modified and which contains no null test on x. finally, we look for a dereference of x (lines 17 to 23), again using the disjunction pattern to specify three common ways to dereference a pointer: as a pointer (line 18), as an array (line 20), or for field member access (line 22). proc. opencert 2010 8 / 18 eceasst 1 @@ 2 identifier x; 3 expression e,e1; 4 type t1; 5 identifier fld; 6 statement s1, s2; 7 @@ 8 ( 9 x = (t1) malloc(...) 10 | 11 x = (t1) calloc(...) 12 | 13 x = (t1) realloc(...) 14 ) 15 ... when != x = e 16 when != if(e == null) s1 else s2 17 ( 18 *x 19 | 20 x[e1] 21 | 22 x->fld 23 ) figure 3: coccinelle script to find dereferencing of null pointers. note that, even though the semantic patch specifies that there can be no conditionals with a condition on the form ‘e==null’ (in line 16), coccinelle will automatically also match variations of this condition such as ‘null==e’, and ‘!e’. this feature is called isomorphisms and is a general, customisable, and scriptable feature of coccinelle designed to handle syntactic variations of the same semantic concept, in this case, comparing a variable to the null pointer. isomorphisms, while not strictly necessary, represent a large reduction in the amount of work a programmer has to do when developing a semantic patch. isomorphisms are also useful in developing patches that are more complete (cover more cases) since corner and special cases need only be handled once. while the semantic patch in figure 3 will catch many common violations of rule exp34-c, it cannot catch all possible violations. first of all, null pointers may come from many other places than the memory allocation functions, e.g., user defined functions and library functions. in principle it is of course possible to manually extend the semantic patch with all the functions possibly returning a null pointer, however, this quickly becomes unwieldy. another drawback of the semantic patch, as shown, is that it currently overlooks violations occuring after a null test. it is possible to manually refine the semantic patch to take more tests into account in a proper way. in [lbp+09] a more comprehensive coccinelle approach to dereferencing of null pointers is described. this approach covers not only standard allocations functions, but basically any function returning null. in addition, care is taken to consider null tests and handle them properly. another alternative would be if the semantic patch could make use of information from a dataflow analysis. that way it would not be necessary to explicitly cover all syntactic possibilities for null testing or dereferencing. in section 4 we describe our current work on integrating analysis 9 / 18 volume 33 (2010) clang and coccinelle: the best of two worlds 1 @@ 2 identifier x; 3 expression e,e1; 4 function f; 5 identifier fld; 6 @@ 7 free(x); 8 ... when != x = e 9 ( 10 f(...,x,...) 11 | 12 *x 13 | 14 x[e1] 15 | 16 x->fld 17 ) figure 4: coccinelle script to find potential access to deallocated memory. information into coccinelle scripts. 3.3 mem30-c: do not access freed memory in the c programming language, as in most programming languages, using the value of a pointer to memory that has been deallocated, with the free() function, results in undefined behaviour. in practise, reading from deallocated memory may result in crashes, leaks of information, and exploitable security vulnerabilities. rule mem30-c ensures that deallocated memory will not be accessed. the problem underlying this rule is very similar to that described in rule exp34-c (do not dereference null pointers): instead of focusing on null pointers, this rule covers all pointers that have been freed. in figure 4 a coccinelle script covering some of the simple(r) cases of this rule is shown. the script first looks for any identifier (declared in line 2) that occurs as an argument to the free() function (line 7). following that, the script looks for a control flow path where the identifier (x) is not assigned to, i.e., a path where it is not modified (line 8). finally, using the disjunction search pattern (denoted by ‘(’, ‘|’, and ‘)’) that succeeds if either of the alternatives (separated by ‘|’) match, the script looks for a use of the identifier that results in the actual violation. here four common uses are covered: used as an argument to a function (line 10), dereferenced as a pointer (line 12) or an array (line 14), and dereferenced for member field access (line 16). 3.4 err33-c: detect and handle errors the lack of proper exceptions in the c programming language means that error conditions have to be explicitly encoded and communicated to other parts of the program. most often a run-time error in a given c function will be communicated by returning an error value, frequently -1 or null. ignoring an error condition is highly likely to lead to unexpected and/or undefined behaviour, it is therefore essential that the return value is always checked for all calls to a function proc. opencert 2010 10 / 18 eceasst 1 @ voidfunc @ 2 function fn; 3 position voidpos; 4 @@ 5 void fn@voidpos(...) { 6 ... 7 } 8 9 @ func disable ret exists @ 10 type t; 11 expression e; 12 function fn; 13 position pos != voidfunc.voidpos; 14 @@ 15 t fn@pos(...) { 16 ... when != return e; 17 } figure 5: coccinelle script to find non-void functions without a return statement. that may return an error value and that any error condition is handled properly. rule err33-c formalises this requirement. this rule differs from most of the other rules in the ccscs in that it is almost entirely application dependent, since it is up to each application or software project to decide how, specifically, error conditions are signalled, what error values are used, what they mean, and how they must be checked and handled. it is therefore impossible to come up with a single, or even a few, rules that will cover the entire spectrum of possibilities. thus, for a tool to be useful and effective it must be very customisable in order to adapt it to project specific code styles and policies. we believe that the specialised semantic patch language (smpl) used in coccinelle provides an excellent, and highly adaptable, platform for developing project specific rule checkers. as an example of how coccinelle can be customised for project specific error handling standards, we show in [llh+10] how coccinelle was used to find several bugs in some error handling code in the openssl cryptographic library. coccinelle has also been used to find flaws in the error handling of the linux kernel [lbp+09]. 3.5 msc37-c: ensure that control never reaches the end of a non-void function non-void functions are required to return a value, using the return statement. it results in undefined behaviour to use the return value of a non-void function where control flow reaches the end of the function, i.e., without having explicitly returned a value. for this reason the ccscs requires that all control flows in a non-void function must end in a (non-empty) return statement. figure 5 shows a semantic patch that finds non-void functions with a control flow path not ending in a non-empty return statement. the overall strategy for this search is to first find all void functions (line 1 to 7), i.e., functions that are not supposed to return a value, in order to rule them out in our search. next, we find all function declarations except for the functions we have earlier identified as void functions (line 13). once such a function is found, we start 11 / 18 volume 33 (2010) clang and coccinelle: the best of two worlds looking for a control flow path that does not contain a return statement (line 16). observe that the head of the latter search pattern (line 9) not only contains the name of the search pattern (func) but also a directive to coccinelle that it should disable the use of the ‘ret’-isomorphism (cf. the discussion of isomorphisms in section 3.2) in order to avoid unwanted, potential interference from the isomorphism system. the header also specifies that the current rule should look for the existence of a control flow path with the required property, rather than checking for the property along all control flow paths, since we have a potential violation if there is even a single control flow path without a return statement. the problem caught by the above semantic patch is inherently syntactic and control flow based, and thus very well suited for coccinelle searches. furthermore, checking for violations can be done in a universal and application independent way. 4 adding program analysis information from the discussion in the previous section of the categories and how specific rules can be checked using coccinelle, it should be clear that while coccinelle is useful for compliance checking it would beneift greatly from having access to proper program analysis information, e.g., for more precise and comprehensive tracking of potential null pointers. such information could also be used to make checkers more succinct and efficient because fewer syntactic cases need to be covered. in the following we will illustrate both uses as well as how we intend to make program analysis information available for use in semantic patches. in section 4.2 we show how such information can be obtained through the clang tool and we discuss the current status of our integration of clang into coccinelle. 4.1 pointer analysis: tracking null pointers and aliases consider the rule exp34-c (do not dereference null pointers). here the problem is to find all expressions that may potentially dereference a null pointer. with access to pointer analysis information, every expression that may result in a null pointer can be found and tagged. note that this is independent of how an expression may result in a null pointer, i.e., it is no longer necessary to explicitly track information only from allocation functions in the semantic patch, since this is handled by the analysis. below we show how such analysis information could be incorporated into a semantic patch. the following semantic patch is intended to illustrate one possible way to make analyis information available to semantic patches: 1 @@ 2 identifier x, fld; 3 expression e1; 4 analysis[null] ninf; 5 @@ 6 ( *x@ninf 7 | x@ninf[e1] 8 | x@ninf->fld 9 ) proc. opencert 2010 12 / 18 eceasst the main thing to note in the above semantic patch is the ‘analysis’ declaration (line 4) that declares a meta-variable, called ninf. this meta-variable is then used in much the same way as position meta-variables: by “tagging” an expression with the ‘ninf’ meta-variable, e.g., like ‘x’ in line 7, only expressions that match the syntax (in this case an array) and that may also result in a null pointer are matched by the semantic patch. taking this a step further, we can also use analysis information to find all (sub-)expressions that are potential dereferences and then simply search for all expressions that are both tagged as potentially dereferencing and also as potentially resulting in a null pointer. here a dereferencing expression is taken to mean an expression that may in any way do a pointer dereference: 1 @@ 2 expression e; 3 analysis[deref] deref; 4 analysis[null] ninf; 5 @@ 6 e@deref@ninf since pointers in c may be aliases for the same location in memory, it is important that the pointer analysis not only tracks potential null pointers but also tracks all potentially aliasing pointers. this is often called a alias analysis or a points-to analysis. such analysis information would be useful in many other situations, e.g., in the rule mem30-c (do not access freed memory) where access may occur through an alias. the following semantic patch (with alias analysis information available) would capture this situation (see below for an explanation): 1 @@ 2 identifier x, y; 3 expression e,e1; 4 function f; 5 identifier fld; 6 analysis[alias] xyalias; 7 @@ 8 free(x@xyalias); 9 ... when != y@xyalias = e 10 ( 11 f(...,y@xyalias,...) 12 | 13 *y@xyalias 14 | 15 y@xyalias[e1] 16 | 17 y@xyalias->fld 18 ) the idea in the above semantic patch is that we first declare an analysis meta-variable in line 6 (called ‘xyalias’). then, in line 8, we match a call to ‘free()’ on an identifier ‘x’ and bind the xyalias meta-variable to any available alias analysis information for x. following that we match any assignments to and use of any identifier y that is an alias for x (represented by y@xyalias in lines 9, 11, 13, 15, and 17). 4.2 integrating clang and coccinelle in the following we describe how program analysis information, such as described in the above section, can be computed using the clang tool and discuss the current status of our integration of 13 / 18 volume 33 (2010) clang and coccinelle: the best of two worlds clang and coccinelle. clang was chosen as the main program analysis engine for coccinelle for several reasons: it is open source, it is being (very) actively developed, it has good support for writing new analyses, it provides a robust and proven infrastructure for manipulating c programs, and so forth. the current version of our implementation of a coccinelle/clang integration is a “proof of concept” where the main emphasis has been on making the two tools work together and less on adding language features to the semantic patch language. as a result, it is not possible to use the ‘analysis’ declaration illustrated in the semantic patches in the last section. instead we use positions, as implemented by the ‘position’ meta-variables, to look up relevant analysis information. below we show how this works using python scripting in the semantic patch: 1 @ initialize:python @ 2 3 # read in analysis information generated by clang into 4 # python dictionaries: deref and ninf indexed by positions 5 6 @ expr @ 7 expression e; 8 position pos; 9 @@ 10 e@pos 11 12 @ script:python @ 13 p << expr.pos 14 @@ 15 16 # lookup deref and ninf status in clang data 17 if not (deref[p] and ninf[p]): 18 # remove the match 19 else: 20 # accept the match and continue currently we first run clang on the source files in order to compute program analysis information. this information is then stored in a file that may subsequently be read by a semantic patch. however, it would be possible to start clang from within the semantic patch, again using either o’caml or python scripting. 4.3 clang and wpdss while clang provides a good framework supporting the implementation of checkers and program analyses in various forms, e.g., using the monotone framework, they must be programmed directly in c++ and require recompiling the entire clang tool. in order to make analysis development more flexible and convenient we have added a library for program analysis using weighted push-down systems (wpds). this allows for program analyses to be specified at the more abstract level of wpdss. we have also implemented python bindings for the wpds library enabling rapid prototyping of analyses without recompilation of clang. we have extended clang with the analysis framework of wpdss, using the library wali. this enables us to model the control-flow from clang as a push-down system, and plug-in different weight domains. weight domains for different analyses have been presented [rlk07], such as affine-relations analysis, generalised gen-kill analysis and may-aliasing pointer analysis. we have used the gen-kill weight domain to implement a reaching definitions analysis within clang, proc. opencert 2010 14 / 18 eceasst and plan to implement a pointer analysis as well. the analysis result can then be pre-processed in coccinelle scripts, as illustrated above, e.g., to get maybe-null analysis information. the benefit of using clang is that the control-flow graph of the program is readily available, with some infeasible paths automatically pruned. the analysis is written as a special analysis pass that constructs the wpds, assigns weights, and perform a query for each function. the analysis results (annotated weighted finite automata) are output, and subsequently interpreted by the concrete coccinelle script when analysis information is needed. currently the python scripting interface is used with some additional support code for calling clang and interpreting the output. 4.4 current work the information that we have integrated at this point is the reaching definitions analysis. the output from clang is a textual representation of the solved wfa, an example of one line of this output is: ( p , ( uninit_use.c , ( 5 , 9 ) ) , accept ) <\s.(s {null}) u {(simple:a@uninit_use.c:3:9@uninit_use.c:4:9,1)}> all lines are split into their components: from state of the wpds, which will be the state p in most cases. symbol in this case “( uninit use.c , ( 5 , 9 ) )” indicating the program point. to state which will be the accepting state accept. the weight associated with this transition, which is the program analysis information associated with the program point. the weight again needs to be parsed, in this case into its gen and kill set. in the above example the kill set is empty, and the gen set adds a definition point of the variable simple:a@uninit use.c:3:9, namely that it can be defined at uninit use.c:4:9. variables are named from: the function they are defined in, their identifier and the position they are defined at. all positions are made up of: a file name, line number and column number. finally, a dictionary data structure is constructed such that the reaching definitions for a variable at a program point can be looked up. one use is to look for uninitialised variables being used, where the basic semantic patch is: 1 @ uninituse @ 2 type t; identifier i; 3 position defloc, useloc; 4 identifier fn; 5 @@ 6 // look for declarations with no assignment 7 t@defloc i; 8 ... when any 9 //which are then used 10 ( 11 fn@useloc(...,i,...); 12 | 13 i@useloc 14 ) 15 / 18 volume 33 (2010) clang and coccinelle: the best of two worlds before being able to use a location from coccinelle we have to account for small differences in how locations are presented in the cfg of clang and coccinelle, e.g. precisely where a variable is defined: 1 int a; 2 ˆ clang define location 3 ˆ coccinelle define location another example is that the use found might be part of a larger expression, so we will have to find the location of the entire expression. currently we simply map a coccinelle location to the closest clang location on the same line. we can then discard false positive matches, based on whether the data can actually flow from the found definition to the found use, in a somewhat cleaner way than specifying all possible ways the variable could have been modified. the approach of course becomes much more powerful when including analysis information from a pointer analysis. 5 work in progress in this section we discuss the current status and work-in-progress for using coccinelle to check for ccscs compliance. in particular we we discuss compliance checking of the full standard for real world software projects. 5.1 compliance checking real world software coccinelle has already been used successfully to find numerous bugs in the linux kernel, the openssl library, and other open source projects used in the “real world”. especially the experience with bug finding in the linux kernel shows that the approach scales well even to very large software projects. one of the biggest problems when checking such large projects, is the number of false positives, i.e., warnings of potential violations that turn out not to be violations. here the customisability of coccinelle has turned out to be a great tool for reducing the number of false positives, since it enables a programmer to refine the semantic patches to take the project specific code styles into account that give rise to the most false positives. the integration of program analysis information, e.g., obtained from clang, will enable a code search to take (more) semantic information into account and will thus reduce the number of false positives further. 5.2 implementing checkers for the full standard while we have only detailed the implementation of coccinelle checkers for four of the 118 rules in the ccscs, we have implemented checkers for approximately 25 rules and plan to implement coccinelle checkers for all the ccscs rules that are suitably application independent. for rules that are application dependent, such as rule err33-c (discussed in section 3.4), it may be possible to provide an “abstract” semantic patch that can be instantiated with project specific details similar to the approach taken in [llh+10]. we intend to make the complete set of checkers available for download as open source. proc. opencert 2010 16 / 18 eceasst 6 related work the past decade has seen the development and release of numerous compile time tools for program navigation, bug finding and code style checking for programs written in c, as well as many other languages. these tools include the mc tool [ecch00] (later used as basis for the commercial tool coverity prevent). similar to coccinelle, the mc tool is a bug finder that can be adapted to specific projects, however the source code for mc has never been released. splint [le01] and flawfinder [whe06] are two examples of open source bug finders. both are able to check for a relatively small set of bugs. both are somewhat adaptable but requires either (light-weight) annotation of the source code or python programming. while several commercial static analysis tools support compliance checking6 for a wide spectrum of coding standard, including the ccscs, we are not aware of any open source bug finder tools working towards this goal. 7 conclusion in this paper we have shown that the coccinelle tool is very well suited for checking some of the rules comprising the cert c secure coding standard. we have further argued that integrating program analysis information would facilitate even more comprehensive, more expressible, and even more flexible semantic patches to be written. bibliography [bdh+09] j. brunel, d. doligez, r. r. hansen, j. l. lawall, g. muller. a foundation for flowbased program matching: using temporal logic and model checking. in shao and pierce (eds.), proceedings of the 36th acm sigplan-sigact symposium on principles of programming languages, popl 2009. pp. 114–126. acm, savannah, ga, usa, jan. 2009. [ecch00] d. r. engler, b. chelf, a. chou, s. hallem. checking system rules using systemspecific, programmer-written compiler extensions. in fourth usenix symposium on operating systems design and implementation (osdi). pp. 1–16. san diego, ca, oct. 2000. [lbp+09] j. l. lawall, j. brunel, n. palix, r. r. hansen, h. stuart, g. muller. wysiwib: a declarative approach to finding api protocols and bugs in linux code. in proceedings of the 2009 ieee/ifip international conference on dependable systems and networks, dsn 2009. pp. 43–52. ieee, estoril, lisbon, portugal, june/july 2009. [le01] d. larochelle, d. evans. statically detecting likely buffer overflow vulnerabilities. in proc. of the 10th usenix security symposium. usenix, washington d.c., usa, aug. 2001. http://lclint.cs.virginia.edu/ 6 see the ccscs web page for details on tool support. 17 / 18 volume 33 (2010) http://lclint.cs.virginia.edu/ clang and coccinelle: the best of two worlds [llh+10] j. l. lawall, b. laurie, r. r. hansen, n. palix, g. muller. finding error handling bugs in openssl using coccinelle. in eighth european dependable computing conference, edcc-8. pp. 191–196. ieee computer society, valencia, spain, apr. 2010. [plhm08] y. padioleau, j. l. lawall, r. r. hansen, g. muller. documenting and automating collateral evolutions in linux device drivers. in sventek and hand (eds.), proceedings of the 2008 eurosys conference. pp. 247–260. acm, glasgow, scotland, uk, apr. 2008. [plm10] n. palix, j. l. lawall, g. muller. tracking code patterns over multiple software versions with herodotos. in jézéquel and südholt (eds.), proceedings of the 9th international conference on aspect-oriented software development, aosd 2010. pp. 169–180. acm, rennes and saint-malo, france, mar. 2010. [rlk07] t. reps, a. lal, n. kidd. program analysis using weighted pushdown systems. in proceedings of the 27th international conference on foundations of software technology and theoretical computer science, fsttcs’07. pp. 23–51. springer-verlag, 2007. [rsjm05] t. reps, s. schwoon, s. jha, d. melski. weighted pushdown systems and their application to interprocedural dataflow analysis. science of computer programming 58(1-2):206–263, 2005. [sea08] r. c. seacord. the cert c secure coding standard. addison-wesley, 2008. [whe06] d. wheeler. flawfinder home page. web page: http://www.dwheeler.com/ flawfinder/, oct. 2006. http://www.dwheeler.com/flawfinder/ proc. opencert 2010 18 / 18 http://www.dwheeler.com/flawfinder/ http://www.dwheeler.com/flawfinder/ http://www.dwheeler.com/flawfinder/ introduction the cert c secure coding standard overview of the ccscs categories of the ccscs compliance checking with coccinelle dcl32-c: guarantee that mutually visible identifiers are unique exp34-c: do not dereference null pointers mem30-c: do not access freed memory err33-c: detect and handle errors msc37-c: ensure that control never reaches the end of a non-void function adding program analysis information pointer analysis: tracking null pointers and aliases integrating clang and coccinelle clang and wpdss current work work in progress compliance checking real world software implementing checkers for the full standard related work conclusion formalization of petri nets with individual tokens as basis for dpo net transformations electronic communications of the easst volume 40 (2011) proceedings of the 4th international workshop on petri nets and graph transformation (pngt 2010) formalization of petri nets with individual tokens as basis for dpo net transformations tony modica, karsten gabriel, kathrin hoffmann 21 pages guest editors: claudia ermel, kathrin hoffmann managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst formalization of petri nets with individual tokens as basis for dpo net transformations tony modica1, karsten gabriel2, kathrin hoffmann3 ∗ 1 modica@cs.tu-berlin.de integrated graduate program human-centric communication (h-c3), technische universität berlin, germany 2 kgabriel@cs.tu-berlin.de fraunhofer institute for open communication systems (fokus), berlin, germany 3 kathrin.hoffmann@haw-hamburg.de hochschule für angewandte wissenschaften, hamburg, germany abstract: reconfigurable place/transition systems are petri nets with initial markings and a set of rules which allow the modification of the net structure during runtime. they have been successfully used in different areas like mobile ad-hoc networks. in most of these applications the modification of net markings during runtime is an important issue. this requires the analysis of the interaction between firing and rule-based modification. for place/transition systems this analysis has been started explicitly without using the general theory of m -adhesive transformation systems, because firing cannot be expressed by rule-based transformations for p/t systems in this framework. this problem is solved in this paper using the new approach of p/t nets with individual tokens. in our main results we show that on one hand this new approach allows to express firing by transformation via suitable transition rules. on the other hand transformations of p/t nets with individual tokens can be shown to be an instance of m -adhesive transformation systems, such that several well-known results, like the local church-rosser theorem, can be applied. this avoids a separate conflict analysis of token firing and transformations. moreover, we compare the behavior of p/t nets with individual tokens with that of classical p/t nets. our new approach is also motivated and demonstrated by a network scenario modeling a distributed communication system. keywords: petri net transformation, reconfigurable place/transition systems, petri nets with individual tokens, collective token approach, network scenario 1 introduction petri nets are one of the main formalisms to describe and analyze concurrent processes. they have been a promising candidate for formal extensions on the one hand, but on the other hand ∗ this work has been partly funded by the research project formalnet (see tfs.cs.tu-berlin.de/formalnet) of the german research council and by the integrated graduate program on human-centric communication at technische universität berlin 1 / 21 volume 40 (2011) mailto:modica@cs.tu-berlin.de mailto:kgabriel@cs.tu-berlin.de mailto:kathrin.hoffmann@haw-hamburg.de tfs.cs.tu-berlin.de/formalnet formalization of petri nets with individual tokens as basis for dpo net transformations also for integrations with different formal techniques to capture more complex aspects. a theory of rule-based transformation based on double pushout (dpo) graph transformation [eept06] is available for place/transition (p/t) systems, i. e. p/t nets with an initial marking. this transformation of p/t systems changing their net structure has been successfully used for modeling adaptive workflows and mobile ad-hoc networks in [hme05, bdhm06]. p/t systems have been shown to form a weak adhesive high-level replacement (hlr) category with the class of all marking-strict morphisms [pehp08]. this allows us to apply all the results for weak adhesive hlr transformation systems concerning the local church-rosser theorem, parallelism, and concurrency of transformations as shown in [eept06] also to transformation systems of p/t systems. in this paper, we use the notion of m -adhesive category [egh10] which is short for vertical weak adhesive hlr category. in m -adhesive categories van kampen (vk) squares only need to satisfy the vertical vk-property, i. e. the vk-property has to hold for cubes where the vertical morphisms are in m . in contrast, for a weak adhesive hlr categories it is required that the vk-property does also hold for cubes, where the horizontal morphisms are in m . however, as shown in [egh10] all the main results of [eept06] are still valid for m -adhesive categories. the concept of petri systems leads to a category ptsys with morphisms allowing to increase the number of tokens on corresponding places. unfortunately, (ptsys,min j) with the class min j of all injective morphisms is not m -adhesive in contrast to (ptsys,mstrict), where mstrict is the class of injective morphisms where the number of tokens on corresponding places is equal [pra08]. using marking-strict morphisms, we can not formulate adequate transformation rules for p/t systems that change markings. this is inconvenient because marking-changing rules are essential to express token firing by transformation via suitable transition rules and for modeling communication systems and platforms with petri nets, especially for realizing multicasting of data tokens in high-level nets [bee+09]. to overcome this restriction, we present a new petri net formalism, called “place/transition nets with individual tokens” or short pti nets, together with a rule-based transformation approach. the difference between pti nets and p/t systems concerns the representation of net markings: for the new individual approach, we propose a net’s marking as a set of individuals instead of a (collective) sum of a monoid. the formal definition of nets with individual tokens still follows the concept “petri nets are monoids” from [mm90]. the paper is structured as follows: section 2 introduces pti nets, their firing behavior, and rule-based transformation of pti nets based on graph transformation with double pushouts. we demonstrate that the new concept of p/t nets with individual tokens is compatible with the concept of p/t systems using a construction that maps pti nets to corresponding p/t systems. for this purpose we define an equivalence relation on the class of pti nets, such that the equivalence classes are in one-to-one correspondence to the p/t systems. moreover, we show that the construction preserves and reflects the firing behavior. as a running example, we demonstrate a simple network model that can be reconfigured by rule applications that add new clients to the network. as first main result we show in section 3 that the category of pti nets with the class of all injective morphisms forms an m -adhesive category which allows to formulate marking changing rules. this important result is the basis for further results concerning analysis. first, we formulate a necessary and sufficient gluing condition for the applicability of transformation rules in the proc. pngt 2010 2 / 21 eceasst given m -adhesive category of pti nets. then, we demonstrate the equivalence of firing steps with corresponding transition firing rules. the second main result shows that token firing can be expressed by rule-based transformation based on suitable transition rules, leading to a local church-rosser theorem for rule applications and firing steps. in the concluding section 4, we give an outlook on algebraic high-level nets with individual tokens for modeling especially highly dynamic structures and complex behavior in the area of communication platforms in an adequate way. 2 p/t nets with individual tokens in this section we introduce our new concept of p/t nets with individual tokens (pti nets) and compare it to the classical concept of p/t systems with initial markings. furthermore, we define a rule-based transformation of pti nets in the sense of rule-based graph transformation [eept06]. as an example, we demonstrate a simple model of a distributed reconfigurable network. 2.1 p/t nets with individual tokens and their relationship to p/t systems the notion of nets with individual tokens was mentioned first in [rei85] where it was used to describe “tokens that can be identified as individual objects”. the main contribution of that article was the definition of markings as multisets of distinguished elements rather than amounts of indistinguishable black tokens. in the end, individual tokens in that context is a synonym for what by now is known as data tokens in high-level nets. further, there is the notion of token individuality that has been coined in [gp95] as “individual token interpretation” of firing steps, which entitles the definition of processes from [gr83]. under the individual approach, firing sequences consider not only the number and value of tokens (as in the collective approach) but also their history of tokens. in [vg05], the author investigates the collective/individual dichotomy of firing steps and the expressive power of the different firing rules w. r. t. labeled transition step systems. [bmms99] formalizes the individual token interpretation of firing steps categorically with a functorial individual firing semantics. we try to combine aspects of both approaches dealing with individual tokens. on the one hand, we need a concept of individual tokens on the syntactical level of petri systems like in [rei85] in order to gain benefits for the transformation of marked petri nets. with such individual tokens, rules can match specific tokens which allows us to formulate rules for manipulating markings freely without necessarily changing the net’s structure as in the category ptsys of p/t systems, i. e. p/t nets with collective markings (cf. [ehp+07]). on the other hand, we need individual “black” tokens like in [gp95] without presuming different data values for the tokens, because we also want to have low-level petri nets with individual tokens. for this purpose, we introduce the new notion of place/transition nets with individual tokens (pti nets), their firing behavior, and application of pti transformation rules. definition 1 (place/transition nets with individual tokens (pti)) we define a marked p/t net with individual tokens, short pti net, as ni = (pn,i,m), where • pn = (p,t, pre, post : t → p⊕) is a classical p/t net, where p⊕ is the free commutative 3 / 21 volume 40 (2011) formalization of petri nets with individual tokens as basis for dpo net transformations monoid over p, • i is the finite set of individual tokens of ni, and • m : i → p is the marking function, assigning the individual tokens to the places. further, we denote the environment of a transition t ∈ t as env(t) ={p ∈ p | pre(t)(p) 6= 0∨ post(t)(p) 6= 0}⊆ p example 1 (place/transition nets with individual tokens) figure 1 shows an example of a pti net modeling a simple network which consists of several clients. these clients can communicate with each other only indirectly via switches by sending or receiving data packages represented by black tokens. if a client wants to send data to another client which is connected to a different switch then it first has to send the data to the switch to which it is connected. the switch can then forward the data to the respective other switch which sends the data to the addressee. each client clientx has a complement place cx which represents the free data capacity of this client. the net has a marking of individual tokens i ={i1,...,i7}. the individual tokens are mapped to the corresponding places by a marking function m with m(i1) = c2, m(i2) = m(i3) = m(i4) = client1, m(i5) = m(i6) = client2 and m(i7) = switch1. client1 client2 send1 rec1 send2 rec2 switch1 c1 c2 i1 i5 i6 i7 i2 i3 i4 forward1 forwardn figure 1: pti net (simplenetwork,i,m) every p/t net with individual tokens corresponds to a p/t system in the collective approach as defined in [ehp+07]. the following construction coll flattens a pti net to a p/t system with collective marking by forgetting the individuality of token elements. definition 2 (collective construction for pti nets) given a pti net ni = (pn,i,m), we define coll(ni) = (pn, µ) where µ = ∑i∈i m(i)∈ p ⊕ pn . note that we can denote the collective marking alternatively as the sum with explicit coefficients µ = ∑p∈ppn|m −1(p)|· p. next, we define an equivalence relation ≈ on pti nets and show that two pti nets are equivalent if and only if they correspond to the same p/t system with collective marking. moreover, proc. pngt 2010 4 / 21 eceasst we show that for every collective p/t system there is at least one corresponding pti net. this allows us to show that our individual approach and the collective approach are compatible with each other, in the sense that the class ptsys of all p/t systems corresponds bijectively to the quotient ptinets/≈ where all equivalent pti nets are identified. definition 3 (equivalence of pti nets) we call two pti nets ni = (pn,i,m) and ni′ = (pn′,i′,m′) equivalent and write ni ≈ ni′, if pn = pn′ and there exists a bijective function f : i → i′ with m′◦ f = m. note that because bijective functions are closed under composition and inversion, ≈ is an equivalence relation. lemma 1 (collective equality and equivalence) for any two pti nets ni = (pn,i,m) and ni′ = (pn′,i′,m′) hold the equivalence coll(ni) = coll(ni′)⇔ ni ≈ ni′ proof. we assume coll(ni) = (pn, µ), coll(ni′) = (pn′, µ′), and that p is the set of places of pn (and also of pn’). “⇒”: from coll(ni) = coll(ni′) we get pn = pn′ and ∑i∈i m(i) = µ = µ′ = ∑i∈i′ m′(i). we construct a bijection f : i → i′ compatible with m and m′. choose for each place p ∈ p an arbitrary bijection f p : m−1(p)→ m′−1(p) between the subsets of tokens of i and i′ that are mapped to p by m and m′, respectively. such bijections exist because from the µ = µ′ we get by the equality of their coefficients for all p ∈ p that |m−1(p)|= |m′−1(p)|. consider the function f : i → i′ with f (x) = f p(x) for x ∈ m−1(p), which is welldefined because i = ⋃ p∈p m −1(p), i′ = ⋃ p∈p m ′−1(p) and the preimage subsets of m and m′ are disjoint. moreover, f is bijective and for all p ∈ p and all x ∈ m−1(p) we have m′◦ f (x) = m′( f p(x)) = p = m(x) from which we conclude ni ≈ ni′. “⇐”: from ni ≈ ni′, we get pn = pn′ and bijective f : i → i′ with m′◦ f = m. we have to show that µ = µ′: µ = ∑ i∈i m(i) = ∑ i∈i m′◦ f (i) = ∑ p∈p |(m′◦ f )−1(p)|· p f bij. = ∑ p∈p |m′−1(p)|· p = ∑ i∈i′ m′(i) = µ′. lemma 2 (coll is surjective) for every p/t system (pn, µ), there is a pti net ni with coll(ni) = (pn, µ). proof. let p be the set of places of pn. for µ = ∑p∈p λp · p, consider for each p ∈ p a set ip of λp elements with all ip being mutually disjoint. we choose ni = (pn,i,m) with i = ⋃ p∈p ip and m : i → p with m(x) = p for x ∈ ip. hence, coll(ni) = (pn, µ̂) with µ̂ = ∑i∈i m(i) = ∑p∈p ∑i∈ip m(i) = ∑p∈p λp · p = µ . theorem 1 the quotient ptinets/≈ of the class of all pti nets by their equivalence relation corresponds bijectively to the class pt sys of all p/t systems. 5 / 21 volume 40 (2011) formalization of petri nets with individual tokens as basis for dpo net transformations ptinets n && coll // ptsys ptinets/≈ i 99 proof. consider the function i : ptinets/≈→ ptsys with i([ni]≈) = coll(ni). note that i◦n = coll, where n is the natural function mapping a pti net to its equivalence class. by lemma 1, we get that i is well-defined and injective because all pti nets in the same equivalence class have the same collective construction to which only elements of this particular equivalence class are mapped by coll and i, respectively. by lemma 2, i is also surjective and hence bijective. 2.2 firing of p/t nets with individual tokens now, we define firing steps of transitions in pti nets. due to the fact that the tokens have identities, we have to consider a possible firing step in the context of a specific selection of tokens because there may be several valid firing steps for a transition under a particular marking. definition 4 (firing of pti nets) a transition t ∈ t in a pti net ni = (p,t,pre,post,i,m) is enabled under a token selection (m,m,n,n), where • m ⊆ i, m is the token mapping of ni, • n is a set with (i \m)∩n = /0, n : n → p is a function, if it meets the token selection condition ∑ i∈m m(i) = pre(t)∧ ∑ i∈n n(i) = post(t) if an enabled transition t fires, the follower marking (i′,m′) is given by i′ = (i \m)∪n, m′ : i′ → p with m′(x) = { m(x), x ∈ i \m n(x), x ∈ n leading to ni′ = (p,t, pre, post,i′,m′) as the new pti net in the firing step ni 〉−t,s−→ ni′ via s = (m,m,n,n). remark 1 (token selection) the purpose of the token selection is to specify exactly which tokens should be consumed and produced in the firing step. thus, m ⊆ i selects the individual tokens to be consumed, and n contains the set of individual tokens to be produced. clearly, (i\m)∩n = /0 must hold because it is impossible to add an individual token to a net that already contains this token. m and n relate the tokens to their carrying places. it would be sufficient to consider just the restriction m|m here or to infer it from the net but as a compromise on symmetry and readability we denote m in the token selection. example 2 (firing of pti nets) consider again the pti net (simplenetwork,i,m) in figure 1. we want to fire the transition send2 to send one data package from client2 to the switch. even though we have only black tokens, we have to choose which of the tokens on the place client2 should be consumed by the transition, because the tokens have identities. we decide to take proc. pngt 2010 6 / 21 eceasst the token i6. so we have a token selection s = (m,m,n,n) with m = {i6}, m(i6) = client2, n ={i8,i9}, n(i8) = c2 and n(i9) = switch1. now, send2 is enabled under selection s because there is m(i6) = client2 = pre(send2) and n(i8)⊕n(i9) = c2⊕switch1 = post(send2) which means that it meets the token selection condition. hence, there is a firing step (simplenetwork,i,m) 〉−send2,s−−−−→ (simplenetwork,i′,m′) with i′ ={i1,i2,i3,i4,i5,i7,i8,i9} and a mapping m′ of the individuals to places as derived from m and n. we can show that the firing behavior of our individual approach is compatible with the wellknown firing behavior of the collective approach since a firing step in one representation implies a firing step in the respective other one. theorem 2 (coll preserves and reflects firing behavior) 1. given a pti net ni with transition t ∈ tni enabled under token selection s = (m,m,n,n) with firing step ni 〉−t,s−→ ni′, then t is enabled in coll(ni) with firing step coll(ni) 〉−t→ coll(ni′). 2. vice versa, given an enabled transition t in coll(ni) with coll(ni) 〉−t→ (pn′, µ′), there exists a token selection s = (m,m,n,n) such that t is enabled in ni under s with firing step ni 〉−t,s−→ ni′ and coll(ni′) = (pn′, µ′). proof. assume ni = (p,t, pre, post,i,m) and coll(ni) = (p,t, pre, post, µ). 1. transition t is enabled in coll(ni) under µ because pre(t) t enabled = ∑i∈m m(i) m⊆i ≤ ∑i∈i m(i) = µ . firing changes just the markings, so we have ni′ = (p,t, pre, post,i′,m′) and coll(ni′) = (p,t, pre, post, µ′). we show that µ′ is the marking resulting from firing t in coll(ni). µ pre(t)⊕ post(t) = ∑ i∈i m(i) ∑ i∈m m(i)⊕ ∑ i∈n n(i) (def. coll,t enabled in ni under s) = ∑ i∈i\m m(i)⊕ ∑ i∈n n(i) = ∑ i∈(i\m)]n m′(i) (def. m′ as in definition 4) = ∑ i∈i′ m′(i) = µ′ (defs. coll and i′ as in definition 4) 2. because transition t is enabled in coll(ni) and we have pre(t) ≤ µ = ∑i∈i m(i), we can choose for each p ∈ p a subset mp ⊆ m−1(p) such that |mp| = pre(t)(p). note that m(x) = p for x ∈ mp. similarly, we choose for each p ∈ p a set np such that |np| = post(t)(p) and all np being mutually disjoint and disjoint to i \ ⋃ p∈p mp. consider the selection s = (m,m,n,n) with m = ⋃ p∈p mp, n = ⋃ p∈p np, and function n : n → p with n(x) = p for x ∈ np. the transition t is enabled in ni under s because ∑i∈m m(i) = ∑p∈p ∑i∈mp m(i) = ∑p∈p|mp| · p = ∑p∈p pre(t)(p) · p = pre(t) and analogously for n, n, and 7 / 21 volume 40 (2011) formalization of petri nets with individual tokens as basis for dpo net transformations post. for the firing step ni 〉−t,s−→ ni′, we have ni′ = (p,t, pre, post,i′,m′) according to definition 4 and pn′ = (p,t, pre, post) because firing changes the marking, only. we show for coll(ni′) = (pn′, µ̂) that µ′ = µ̂ . the arguments are analogous to the ones for the equations for item 1. µ′ = µ pre(t)⊕ post(t) = ∑i∈i m(i) ∑i∈m m(i)⊕∑i∈n n(i) = ∑i∈i\m m(i)⊕ ∑i∈n n(i) = ∑i∈(i\m)]n m ′(i) = ∑i∈i′ m ′(i) = µ̂ . corollary 1 (equivalent firing behavior) given pti nets ni1 ≈ ni2 and a firing step ni1 〉− t,s−→ ni′1. then there is a corresponding firing step ni2 〉− t,s′−−→ ni′2 with ni ′ 1 ≈ ni ′ 2. proof. by lemma 1 we have coll(ni1) = (pn, µ) = coll(ni2) and by theorem 2 there is a firing step (pn, µ) 〉−t→ (pn, µ′) = coll(ni′1), implying a reflected step ni2 〉− t,s′−−→ ni′2 with coll(ni′2) = (pn, µ ′) = coll(ni′1). hence, by lemma 1 there is ni ′ 1 ≈ ni ′ 2. 2.3 transformation of p/t nets with individual tokens the structure of a p/t system can be changed by the application of transformation rules using the double pushout (dpo) approach (see [eept06]). for the definition of transformation rules for pti nets we need the following definition of pti net morphisms. definition 5 (pti net morphisms and category ptinets) given two pti nets nii = (pi,ti, prei, posti,ii,mi), i ∈{1,2}, a pti net morphism is a triple of functions f = ( fp : p1 → p2, ft : t1 → t2, fi : i1 → i2) : ni1 → ni2, such that the following diagrams commute (componentwise for pre and post domains): t1 ft �� pre1 // = post1 // p⊕1 f⊕p �� i1 fi �� m1 // = p1 fp �� t2 pre2 // post2 // p⊕2 i2 m2 // p2 or, explicitly, that f⊕p ◦ pre1 = pre2 ◦ ft , f ⊕ p ◦ post1 = post2 ◦ ft , and fp ◦m1 = m2 ◦ fi . the category ptinets consists of all pti nets as objects with all pti net morphisms. remark 2 (choice of pti morphisms) we are aware that there exist several different reasonable definitions of morphisms for p/t nets in the algebraic representation with monoids of [mm90]. although the p/t morphisms from [eept06], on which our pti morphisms are based, are restricted in contrast to more general definitions of p/t morphisms, e. g. consisting of arbitrary monoid homomorphisms for the component on place monoids and partial functions for the transition components, we chose the current definition. for our simple pti morphisms consisting of total functions, pushouts simply can be constructed componentwise, leading to m -adhesive categories with a class m of injective morphisms. this is no longer valid for more general morphisms as mentioned above. in [mge+10], we show that pti morphisms with injective token component preserve firing steps. for a token-injective morphism f : ni1 → ni2, and a firing step (t,s) in ni1 is is not possible to canonically construct a selection s′ such that ( ft (t),s′) is a firing step in ni2, but we show that such a step exists. the reason of this is that some newly created token in ns proc. pngt 2010 8 / 21 eceasst may also exist in i2 \ ft (ms) so that the subset of conflicting tokens in ns has to be replaced isomorphically such that ns becomes disjoint to i2 \ ft (ms). up to a suitable renaming of these conflicting individual tokens, token-injective pti morphisms are simulations of firing behavior. definition 6 (pti transformation rules) a pti transformation rule is a span of injective ptinets morphisms ρ = (l l← k r→ r). definition 7 (pti transformation) given a pti transformation rule ρ = (l l← k r→ r) and a pti net ni1 with a pti net morphism f : l → ni1, called the match, a direct pti net transformation ni1 = ρ, f =⇒ ni2 from ni1 to the pti net ni2 is given by the following double-pushout (dpo) diagram in the category ptinets: l f �� (po1) k (po2) loo �� r // r f∗ �� ni1 ni0oo // ni2 the application of a rule with a given match following the dpo approach means that we compute first a pushout complement to obtain pushout (po1) and then the pushout (po2) in ptinets. note that pushouts and therefore the result of a rule application are unique only up to isomorphism. intuitively, everything that is matched from the left-hand side l that does not have a preimage in the interface k is deleted leading to a context net ni0. then the right-hand side r is glued to the context ni0 along the interface k leading to the result ni2 of the transformation. remark 3 (construction of pushouts and pushout complements) pushouts in the category ptinets can be constructed componentwise in ptnets and sets, where the marking function of the pushout pti net is induced by the pushout of the token sets. since (ptnets,m1) and (sets,m2) with classes m1 of injective p/t net morphisms and m2 of injective functions are m -adhesive categories (see [eept06]) they have unique pushout complements along m morphisms. thus, also ptinets has unique pushout complements along injective morphisms. example 3 (transformation of pti nets) figure 2 shows the application of a pti rule newclient which connects a new client with a data capacity of three tokens to an existing switch. for simplicity reasons all morphisms in the dpo diagram are inclusions. the left-hand side l of the rule is matched to a pti net network1 which already contains one client. since the rule is non-deleting we obtain a context net network0 which equals the original network. the result of the transformation is a new pti net network2 where the new client has been connected to the switch. 3 main results for p/t nets with individual tokens in this section, we present main results for transformation systems of pti nets following from the properties and results of weak adhesive high-level replacement (hlr) systems [eept06]. the latter are based on the notion of adhesive categories introduced in [ls04]. the results for 9 / 21 volume 40 (2011) formalization of petri nets with individual tokens as basis for dpo net transformations switch1 client1 client2 send1 rec1 send2 rec2 switch1 c1 c2 i6i5 i2 l r k r network0 network2 i3 i4 i1 i7 client1 send1 rec1 switch1 c1 i2 i3 i4 client2 send2 rec2 switch1 c2 i6i5 i1 i7 switch1l network1 client2 send2 rec2 switch1 c2 i6i5 i1 i7 figure 2: pti transformation network1 newclient =⇒ network2 weak adhesive hlr systems are also valid for m -adhesive transformation systems [egh10], which are a generalization that has been triggered by [hei10]. 3.1 p/t nets with individual tokens as m -adhesive category in this paper, we use the notion of m -adhesive category [egh10] which is short for vertical weak adhesive hlr category. in m -adhesive categories van kampen (vk) squares only need to satisfy the vertical vk-property, i. e. the vk-property has to hold for cubes where the vertical morphisms are in m . in contrast, for a weak adhesive hlr categories it is required that the vk-property does also hold for cubes, where the horizontal morphisms are in m . however, as shown in [egh10] all the main results of [eept06] are still valid for m -adhesive categories. theorem 3 (ptinets is m -adhesive) the category (ptinets,min j) is an m -adhesive category where min j ={ f ∈ morptinets | fp, ft , fi injective}. proof (idea). we already know from [eept06] that the category of p/t nets (without markings) (ptnets,m ′) is weak adhesive hlr and hence also m -adhesive with m ′ being the class of all injective petri net morphisms. we construct a comma category over (ptnets,m ′) and an individual marking functor such that this comma category is isomorphic to the m -category of pti nets with possibly infinite tokens sets and the class min j of injective pti net morphisms. from a construction theorem in [pra08] follows that this comma category is m -adhesive. a more detailed proof can be found in [mge+10]. finally, the full subcategory ptinets of pti nets with finite token sets is m -adhesive as well for the class min j. this is guaranteed by another construction theorem from [pra08], as the inclusion functor from setsfin to sets preserves pushouts and pullbacks. using this theorem, we can apply the important results for analyzing transformations from proc. pngt 2010 10 / 21 eceasst [eept06] to transformations of pti nets, e. g. the theorems about independent rule applications (local church-rosser), concurrent rule applications, and local confluence of transformation systems. m -adhesive transformation systems guarantee unique results of rule applications (up to isomorphisms). note that morphisms of ptsys rules have to be marking-strict in order to obtain an m -adhesive ptsys transformation system [pehp08]. this requirement is not necessary for an m -adhesive ptinets transformation system, allowing us to simulate the firing behavior of pti nets with direct transformations as we show in subsection 3.3. 3.2 gluing condition for p/t nets with individual tokens in order to be able to decide whether a rule is applicable at a certain match, we formulate a gluing condition for pti nets, such that there exists a pushout complement of the left rule morphism and the match if (and only if) they fulfill the gluing condition. definition 8 (gluing condition in ptinets) given a pti rule ρ = (l l← k r→ r), a pti net ni and a pti morphism f : l → ni (see the left part of figure 3), we define the set of identification points (i. e. all elements in l that are mapped non-injectively by f ) ip = ipp ∪ipt ∪ipi with • ipp ={x ∈ pl | ∃x′ 6= x : fp(x) = fp(x′)}, • ipt ={x ∈ tl | ∃x′ 6= x : ft (x) = ft (x′)}, • ipi ={x ∈ il | ∃x′ 6= x : fi(x) = fi(x′)}, the set of dangling points (i. e. all places in l that would leave a dangling arc, if deleted) dp = dpt ∪dpi with • dpt ={p ∈ pl | ∃t ∈ tni \ ft (tl): fp(p)∈ env (t)}, • dpi ={p ∈ pl | ∃i ∈ ini \ fi(il): fp(p) = mni(i)}, and the set of gluing points (i. e. all elements in l that have a preimage in k) gp = lp(pk)∪ lt (tk)∪li(ik). we say that ρ and f satisfy the gluing condition if ip∪dp ⊆ gp for the following theorem, we consider the m -adhesive category (ptinets,m ) whose morphism class m contains all injective morphisms. theorem 4 (gluing condition for pti transformation) given a pti rule ρ = (l l← k r→ r) with l,r ∈ m and a match f : l → ni into a pti net ni = (n,i,m : i → pni). the rule ρ is applicable on match f , i. e. there exists a (unique up to isomorphisms) pushout complement ni0 in the diagram in figure 3, iff ρ and f satisfy the gluing condition in ptinets. proof (idea). in [mge+10], we show that the gluing condition from definition 8 is equivalent to the categorical gluing condition from [eept06] for m -adhesive transformation systems, which states that the boundary of an initial pushout construction over the match has to be preserved by the rule. 11 / 21 volume 40 (2011) formalization of petri nets with individual tokens as basis for dpo net transformations l f �� (po) kloo f ′ �� r // r ni ni0oo figure 3: diagram of a mached rule and the possible pushout complement example 4 (gluing condition) consider the transformation rule deleteclient for ptinets depicted in figure 4 and an inclusion match f into the pti net (simplenetwork,i,m) shown in figure 1. the rule deleteclient and match f do not satisfy the gluing condition because due to the fact that the individuals i2, i3 and i4 are not matched by the rule, the place client1 is a dangling point and therefore it should have a preimage in the interface k of the rule (i. e. it should be a gluing point) in order to satisfy the gluing condition. since this is not the case the rule is not applicable with the given match. switch1switch1 client1 send1 rec1 switch1 c1 l r l k r figure 4: transformation rule deleteclient for pti nets in contrast, the pti transformation rule newclient shown in figure 2 together with the match described in example 3 satisfies the gluing condition, because since the match is injective there are no identification points, and the only dangling point switch1 is a gluing point. therefore the rule newclient can be applied with the given match. 3.3 correspondence of transition firing and rule applications an interesting aspect of the possibility to formulate marking-changing rules in ptinets is that rules can simulate firing steps of transitions. we give a construction for transition rules that simulate a firing step of some transition under a specific token selection and show that firing of a transition corresponds to an application of a transition rule and vice versa. definition 9 (pti transition rules) we define the transition rule for a transition t ∈ t of a pti net ni = (p,t, pre, post,i,m), enabled under a token selection s = (m,m,n,n), as the rule ρ(t,s) = (lt l← kt r→ rt) with • the common fixed net structure pnt = (pt,{t}, pret, postt), where pt = env (t), pret(t) = pre(t) and postt(t) = post(t), • lt = (pnt,m,mt : m → pt), with mt(x) = m(x), proc. pngt 2010 12 / 21 eceasst • kt = (pnt, /0,id /0), • rt = (pnt,n,nt : n → pt), with nt(x) = n(x), • l,r being the obvious inclusions on the rule nets. example 5 (simulation of firing behavior by rule-based transformation) consider again the firing of the transition send2 in example 2. the firing step can be simulated by application of the transition rule ρ(send2,s) shown in figure 5 to the pti net (simplenetwork,i,m) in figure 1 leading to the same result. ! ! l r client2 send2 c2l switch1 i6 client2 send2 c2k switch1 client2 send2 c2r i8 switch1 i9 figure 5: transition rule ρ(send2,s) theorem 5 (correspondence between firing steps and direct dpo transformations of pti nets) 1. each firing step ni 〉−t,s−→ ni′ via token selection s = (m,m,n,n) corresponds to an induced direct transformation ni = ρ(t,s), f ====⇒ ni′ via the transition rule ρ(t,s), where the match f : lρ(t,s) → ni is an inclusion. 2. each direct transformation ni = ρ(t,s), f ====⇒ ni1 via some transition rule ρ(t,s) with t ∈ tni , token selection s = (m,m,n,n), and injective match f : lρ(t,s) → ni, implies that the transition ft (t) is enabled in ni under some token selection s̄ with firing step ni 〉−ft (t),s̄−−−−→ni∗ such that ni∗∼= ni1. proof. in the following let ni = (pn,i,m), ni′ = (pn′,i′,m′), and nii = (pni,ii,mi). part 1. consider the dpo diagram in figure 6 with inclusions d and d′, i. e. pn = pn0 = pn1. l = (pnt,m,mt) f �� (po) k = (pnt, /0, /0) (po) ? _loo �� r // r = (pnt,n,nt) f∗ �� ni = (pn,i,m) ni0 = (pn0,i0,m0)d oo d′ // ni1 = (pn1,i1,m1) figure 6: dpo transformation diagram in ptinets for ρ(t,s) applied to ni this diagram exists by theorem 4 because there are no identification points ( f is injective) and all dangling points are gluing points (lp = idpt , i. e. no places are deleted). because pushouts in ptinets can be constructed componentwise for the net and the token components, we have i0 = i \m and i1 = i0 ](n \ /0) as in the dpo diagram of the sets components in figure 7. by assumption t is enabled under s, so we have that (i \m)∩n = /0 and therefore i1 = (i \m)∪n. 13 / 21 volume 40 (2011) formalization of petri nets with individual tokens as basis for dpo net transformations for m1 as induced morphism for the pushout object i1 follows that m fi �� (po) /0 (po) ? _oo �� // n f∗i �� nt !! i m ** i0? _ di oo � � d′i // m0=m◦di !! i1 m1 pt f∗p= fp �� ppn id ppn figure 7: dpo diagram in sets for the token components in figure 6 m1(x) = { m0(x) = m(x) for x ∈ i \m nt(x) = n(x) for x ∈ n hence i1 = i′,m1 = m′ according to definition 4 and therefore ni1 = ni′. this proves the existence of the direct transformation ni = ρ(t,s), f ====⇒ ni′. part 2. given a direct transformation ni = ρ(t,s), f ====⇒ ni1 as in the dpo diagrams in figure 6 and figure 7, there is also a direct transformation ni = ρ(t,s), f ====⇒ ni with ni = (pn,(i \ fi(m)) + n) given by the componentwise dpos in figure 8a by standard category theory and figure 8b by construction of pushout complements and pushouts in sets (see [eept06]) where we choose the injection d̄′i to be an inclusion. then there is ni ∼= ni1 by uniqueness of pushouts and pushout complements in ptinets. pnt ( fp, ft ) �� pnt idoo id // �� pnt ( f̄p, f̄t ) �� pn (po) pn id oo id // pn (po) (a) dpo in ptnets m fi �� /0? _oo � � // �� n f̄i �� nt $$ i m (( (po) i \ fi(m) m̄0 ? _ d̄ioo � � d̄′1 // (i \ fi(m))+ n m̄1 $$ (po) pt f̄p= fp �� ppn id ppn (b) dpo in sets figure 8: componentwise dpo diagrams in ptnets and sets then ft (t)∈ tni is enabled under a token selection s̄ = (m̄,m̄,n̄,n̄) with m̄ = fi(m), m̄ = m, n̄ = f̄i(n) and n̄ = m̄1|n̄ if 1. m̄ ⊆ i, 2. n̄ : n̄ → ppn , 3. (i \m̄)∩n̄ = /0, and 4. ∑ i∈m̄ m̄(i) = preni( ft (t)) 5. ∑ i∈n̄ n̄(i) = postni( ft (t)) proc. pngt 2010 14 / 21 eceasst items 1 and 2 hold by construction via image and restriction. item 3 follows from the fact that the coproduct (i \m̄)+ n is a disjoint union in sets and n̄ = f̄i(n) is exactly the part of that set which is not in i \m̄. it remains to show items 4 and 5: ∑ i∈m̄ m̄(i) = ∑ i∈ fi(m) m̄(i) = ∑ i∈m m◦ fi(i) ( fi inj.,m̄ = m) = ∑ i∈m fp ◦mt(i) ( f ptinets-morphism) = f⊕p ∑ i∈m mt(i) = f ⊕ p ∑ i∈m m(i) (∀i ∈ m : mt(i) = m(i) by def. of ρ(t,s)) = f⊕p ◦ prepnt (t) (t enabled under s in lρ(t,s)) =preni ◦ ft (t) ( f ptinets-morphism) and analogously, ∑ i∈n̄ n̄(i) = ∑ i∈ f̄i(n) n̄(i) = ∑ i∈n m̄1 ◦ f̄i(i) ( f̄i inj.,n̄ = m̄1| f̄i(n)) = ∑ i∈n fp ◦nt(i) ( f̄ = ( f̄p, f̄t , f̄i) ptinets-morphism, f̄p = fp) = f⊕p ∑ i∈n nt(i) = f ⊕ p ∑ i∈n n(i) (∀i ∈ n : nt(i) = n(i) by def. of ρ(t,s)) = f⊕p ◦ postpnt (t) (t enabled under s in lρ(t,s)) =postni ◦ ft (t) ( f ptinets-morphism) so we have that ft (t) is enabled under s̄ and we obtain a firing step ni 〉− ft (t),s̄−−−−→ ni∗ where ni∗ has the same net part pn and the follower marking (i∗,m∗) with i∗ = (i \m̄)∪n̄ and m∗(x) = { m̄(x) = m(x) = m̄1(x)|i\m̄ , if x ∈ i \m̄; n̄(x) = m̄1(x)|n̄ , if x ∈ n̄. now, by the fact that d̄′i is an inclusion we have i∗ = (i \m̄)∪n̄ = (i \ fi(m))∪ f̄i(n) = (i \ fi(m))+ n and the marking function m∗ : i∗→ ppn maps the individuals exactly like m̄1 : (i\ fi(m))+ n → ppn . so we have ni∗ = ni and hence ni∗ ∼= ni1. the encoding of pti transition rules and the correspondence between the firing of pti nets and the application of transition rules stated in the theorem above are very close to those presented in [kre81]. a difference, however, of our encoding is the fact that the transition rules are encoded directly as pti transformation rules rather than as graph transformation rules like in [kre81]. 15 / 21 volume 40 (2011) formalization of petri nets with individual tokens as basis for dpo net transformations this allows us to use the transition rules for analysis in pti transformation systems as presented in the next subsection. a generalization of petri nets to graph grammars is presented in [cm95] such that transitions correspond to rules and firing steps to rule applications. this approach uses an encoding of transitions as graph rules similar to definition 9 and the transition productions of [kre81] with the difference that they contain only the individual tokens as typed graph nodes where the types represent the places marked by the tokens. the authors of [cm95] mention a subtle mismatch of the encoding as a conceptual problem, i. e. that the indistinguishable tokens of the multiset marking in the actual net are more abstract than the tokens with distinguishable individuals in the graph representation. because of several possible matches for the individuals, there are different transformations representing the same unique firing step of a transition and there are many grammars representing the same net. although both constructions have inspired the transition rules in this paper, it is not our ambition to formalize a strict simulation relation between a pti net’s behavior and an – in some sense – equivalent (net) grammar. we rather use the correspondence result of theorem 5 to relate arbitrary net transformation steps with firing steps as we show in the next section. 3.4 independence of token-firing and rule application for p/t systems, [ehp+07] defines parallel and sequential independence of a transformation step and a firing step and proves results that are similar to the local church-rosser theorem of [eept06], which relates sequential and parallel independence of rule applications. as we have shown in theorem 5 we are able to express the firing of pti nets by application of transition rules. this allows us to immediately use the results for m -adhesive transformation systems [eept06, egh10] for the analysis of the independence of firing steps and rule applications. we obtain a notion of parallel independence of a rule application and a firing step for pti nets by relying on the definition of these properties for the corresponding transition rule. definition 10 (parallel independence of rule applications and firing steps) a transformation step ni0 ρ1,o1 =⇒ ni1 and a firing step ni0 〉− t,s−→ ni0′ (see the top of figure 9a) are parallel independent iff the rule applications (ρ1,o1) and (ρ(t,s),o2) are parallel independent (see figure 9b), where (ρ(t,s),o2) is defined according to item 1 of theorem 5. ni0 ρ1,o1 s{ '' t,s '' ni1 && t′,s′ && ni0′ ρ1,o′1 s{ ni1′ (a) independence diagram for a rule application and a firing step ni0 ρ1,o1 s{ ρ(t,s),o2 #+ ni1 ρ(t,s),o′2 "* ni0′ ρ1,o′1 s{ ni1′ (b) corresponding local churchrosser diagram figure 9: independence of rule applications and firing steps proc. pngt 2010 16 / 21 eceasst remark 4 (sequential independence of rule applications and firing steps) analogously to the parallel independence it is possible to define the sequential independence of rule applications and firing steps by defining that ni0 = ρ1 =⇒ ni1 〉− t,s−→ ni2 respectively ni0 〉− t,s−→ ni1 = ρ1 =⇒ ni2 are sequentially independent iff ni0 = ρ1 =⇒ ni1 = ρ(t,s) ===⇒ ni2 respectively ni0 = ρ(t,s) ===⇒ ni1 = ρ1 =⇒ ni2 are sequentially independent. now, we can transfer the relations that the local church-rosser theorem states between parallel and sequentially independent rule applications to parallel and sequentially independent rule applications and firing steps. with this result, we have a criterion to decide for rule applications and firing steps whether they can occur independently in any order with the same result. theorem 6 (local church rosser for rule applications and firing steps) given a direct transformation ni0 ρ1,o1 =⇒ ni1 and a firing step ni0 〉− t,s−→ ni′0 that are parallel independent (see the top of figure 9a), then there exists a transition t′∈ t1 enabled under some token selection s′ leading to ni1 〉− t′,s′−−→ ni′1 and a direct transformation ni ′ 0 ρ1,o′1 =⇒ ni′1. proof. parallel independence of (ρ1,o1) and (t,s) by definition 10 means that (ρ1,o1) and (ρ(t,s),o2) are parallel independent rule applications. this implies by theorem 5.12 in [eept06] that there are sequentially independent transformations ni0 = ρ1,o1 ==⇒ni1 = ρ(t,s),o′2 ====⇒ni′1 and ni0 = ρ(t,s),o2 ====⇒ ni′0 = ρ1,o′1 ==⇒ ni′1 as depicted in figure 9b. the match o ′ 2 is given by the composition o ′ 2 = g1 ◦ i2 where i2 with o2 = f1 ◦i2 is given by the parallel independence of the rules (cf. theorem 5.12 in [eept06]). r1 n1 �� k1r1oo �� l1 // l1 o1 �� i1 '' lρ(t,s) o2 }} i2 xx kρ(t,s)l2oo �� r2 // rρ(t,s) n2 �� ni1 c1g1oo f1 // ni0 c2f2oo g2 // ni′0 now, injectivity of o2 implies injectivity of i2, and injectivity of r1 implies injectivity of g1 because m -morphisms are closed under pushouts. so we have that o′2 = g1 ◦ i2 is injective and thus by item 2 of theorem 5 we have that t′ = o′2,t (t) is enabled under some token selection s ′ with firing step ni1 〉− t′,s′−−→ ni∗1 such that ni ∗ 1 ∼= ni′1. remark 5 due to the fact that a rule sequence ni1 = ρ1 =⇒ ni2 = ρ2 =⇒ ni3 is sequentially independent iff ni1 ρ −1 1⇐ ni2 = ρ2 =⇒ ni3 are parallel independent, the theorem above can be easily extended to cover also the analogous statement for sequentially independent firing and rule application. this argumentation has similarly been used in [ehp+07]. example 6 (independence of rule application and firing step) consider the ptinet network0 in the top-left corner of figure 10. we can add a new client client1 by applying the rule newclient in the top of figure 2 with an inclusion match morphism o. moreover, we can fire the transition send2 under a selection s as described in example 2. the rule application and the firing step are parallel independent which means that the diagram can be completed with sequentially independt dent sequences of rule application and firing steps as shown in figure 10. 17 / 21 volume 40 (2011) formalization of petri nets with individual tokens as basis for dpo net transformations client1 client2 send1 rec1 send2 rec2 switch1 c1 c2 i1 i5 i6 i7 i2 i3 i4 client1 client2 send1 rec1 send2 rec2 switch1 c1 c2 i1 i5 i9i7 i8 client2 send2 rec2 switch1 c2 i1 i5 i6 i7 client2 send2 rec2 switch1 c2 i1 i5 i9i7 i8 network0 network1 network1 'network0 ' ) newclient, o ) newclient, o' ½ send2, s ½ send2, s' i2 i3 i4 figure 10: independent application of newclient and firing of send2 4 conclusion and future work in this paper, we have presented place/transition nets with individual tokens (pti nets) together with a rule-based transformation by instantiation of m -adhesive transformation systems. the individual token approach of pti nets overcomes some technical restrictions of reconfigurable p/t systems and provides an appropriate representation of marking-changing rules. as a main result, we have shown that the category of pti nets together with the class of all injective morphisms form an m -adhesive category, where the framework of m -adhesive categories is a slight generalization of weak adhesive high-level replacement (hlr) categories. this allows us to use the analysis results for weak adhesive hlr systems from [eept06] for pti transformation systems, and we obtain a necessary and sufficient gluing condition for the application of pti transformation rules. moreover, we have shown that firing steps in pti nets are equivalent to applications of special transformation rules, called transition rules, simulating a firing step by changing the marking of the places in the environment of the fired transition accordingly. with this correspondence of firing steps and rule applications, we are able to define the notions of parallel and sequential independence of a pti firing step and a rule application by using the definitions of independence for rule applications from [eept06]. this allows to show a local church-rosser result for rule application and token firing based on the corresponding results in m -adhesive categories and is the basis for further conflict analysis based on critical pairs. in our technical report [mge+10], we extend our approach of petri nets with individual tokens to transformation systems of algebraic high-level nets with individual tokens (ahli nets) based proc. pngt 2010 18 / 21 eceasst on rule-based transformations of algebraic high-level nets from [per95]. for ahli nets we obtain similar results as for pti nets. that is, (ahlinets,m ) with the class of all injective morphisms with isomorphic data part is an m -adhesive category. moreover, we have a sufficient and necessary gluing condition for the applicability of ahli rules, and it is also possible to express the firing of ahli nets by application of ahli transition rules. we employ ahli nets in our modeling case study for skype in [hm10] for realizing multicasting to transmit specific data between groups of skype clients by marking-changing rules according to [bee+09]. in that case study, we use the algebraic data type part in order to represent the clients’ identities and the communicated data. due to the categorical characterization of independence in this paper in contrast to [ehp+07], the results only rely on the correspondence as stated in theorem 5. therefore, the local churchrosser theorem for ahli rule applications and firing steps can be shown completely analogously because of the correspondence between the firing of ahli nets and the application of ahli transition rules [mge+10]. moreover, it is possible to transfer similar results for transformations like the theorems for concurrency and local confluence based on critical pairs [eept06] to transformations mixed with firing steps of p/t and ahl nets with individual tokens. in [ehl10], the results of [eept06] concerning parallel and concurrent rules have been lifted to transformation systems with nested application conditions (see also [hp09]). the additional property for m -adhesive categories that is needed for these results is a suitable e -m factorization (and binary coproducts which we already have by cocompleteness). one possibility to achieve this requirement is the restriction to finite pti and ahli nets, because as shown in [begg10], the restriction of an m -adhesive category to all its finite objects has extremal e -m factorizations. another powerful concept is the amalgamation of rules (with application conditions) over a bundle of matches [geh10] which can be used to realize multicasting of data tokens in highlevel nets [bee+09]. in order to instantiate the results in that article to our petri net categories we need to show that they have so-called effective pushouts. acknowledgements: we thank the reviewers and the members of the tfs research group at tu berlin for their thorough reviews and highly appreciate the comments and suggestions, which significantly contributed to improving the paper’s quality. references [bdhm06] p. bottoni, f. de rosa, k. hoffmann, m. mecella. applying algebraic approaches for modeling workflows and their transformations in mobile networks. journal of mobile information systems 2(1):51–76, 2006. [bee+09] e. biermann, h. ehrig, c. ermel, k. hoffmann, t. modica. modeling multicasting in dynamic communication-based systems by reconfigurable high-level petri nets. in ieee symposium on visual languages and human-centric computing, 19 / 21 volume 40 (2011) formalization of petri nets with individual tokens as basis for dpo net transformations vl/hcc 2009, corvallis, or, usa, 20-24 september 2009, proceedings. pp. 47– 50. ieee, 2009. [begg10] b. braatz, h. ehrig, k. gabriel, u. golas. finitary m-adhesive categories. in ehrig et al. (eds.), proceedings of intern. conf. on graph transformation ( icgt’ 10). lncs 6372, pp. 234–249. springer, 2010. [bmms99] r. bruni, j. meseguer, u. montanari, v. sassone. functorial semantics for petri nets under the individual token philosophy. in category theory and computer science, ctcs ’99. entcs 29. elsevier, 1999. [cm95] a. corradini, u. montanari. specification of concurrent systems: from petri nets to graph grammars. in hommel (ed.), proc. workshop on quality of communication-based systems, berlin, germany. kluwer academic publishers, 1995. [eept06] h. ehrig, k. ehrig, u. prange, g. taentzer. fundamentals of algebraic graph transformation. eatcs monographs in theoretical computer science. springer verlag, 2006. [egh10] h. ehrig, u. golas, f. hermann. categorical frameworks for graph transformations and hlr systems based on the dpo approach. bull. eatcs 102:111–121, 2010. [ehl10] h. ehrig, a. habel, l. lambers. parallelism and concurrency theorems for rules with nested application conditions. electr. communications of the easst 26, 2010. [ehp+07] h. ehrig, k. hoffmann, j. padberg, u. prange, c. ermel. independence of net transformations and token firing in reconfigurable place/transition systems. in kleijn and yakovlev (eds.), proc. of 28th international conference on application and theory of petri nets and other models of concurrency. lncs 4546, pp. 104– 123. springer, 2007. [geh10] u. golas, h. ehrig, a. habel. multi-amalgamation in adhesive categories. in ehrig et al. (eds.), proceedings of intern. conf. on graph transformation ( icgt’ 10). lncs 6372, pp. 346–361. springer, 2010. [vg05] r. j. van glabbeek. the individual and collective token interpretations of petri nets. in proceedings concur 2005, 16 th international conference on concurrency theory. pp. 323–337. springer-verlag, london, uk, 2005. [gp95] r. j. van glabbeek, g. d. plotkin. configuration structures. in lics ’95: proceedings of the 10th annual ieee symposium on logic in computer science. p. 199. ieee computer society, washington, dc, usa, 1995. [gr83] u. goltz, w. reisig. the non-sequential behavior of petri nets. information and control 57(2/3):125–147, 1983. proc. pngt 2010 20 / 21 eceasst [hei10] t. heindel. hereditary pushouts reconsidered. in proceedings of the 5th international conference on graph transformations. icgt’10, pp. 250–265. springerverlag, berlin, heidelberg, 2010. http://portal.acm.org/citation.cfm?id=1928162.1928184 [hm10] k. hoffmann, t. modica. formal modeling and analysis of flexible processes using reconfigurable systems. in ermel et al. (eds.), proc. int. coll. on graph and model transformation (gramot 2010). volume 30. european association of software science and technology, 2010. [hme05] k. hoffmann, t. mossakowski, h. ehrig. high-level nets with nets and rules as tokens. in proc. of 26th intern. conf. on application and theory of petri nets and other models of concurrency. lncs 3536, pp. 268–288. springer, 2005. [hp09] a. habel, k.-h. pennemann. correctness of high-level transformation systems relative to nested conditions. mathematical structures in computer science 19:1–52, 2009. [kre81] h.-j. kreowski. a comparison between petri nets and graph grammars. in 5th international workshop on graph-theoretic concepts in computer science. lncs 100, pp. 1–19. springer, 1981. [ls04] s. lack, p. sobociński. adhesive categories. in proc. fossacs 2004. lncs 2987, pp. 273–288. springer, 2004. [mge+10] t. modica, k. gabriel, h. ehrig, k. hoffmann, s. shareef, c. ermel, u. golas, f. hermann, e. biermann. lowand high-level petri nets with individual tokens. technical report 2009/13, fakultät iv elektrotechnik und informatik – technische universität berlin, 2010. [mm90] j. meseguer, u. montanari. petri nets are monoids. information and computation 88(2):105–155, 1990. [pehp08] u. prange, h. ehrig, k. hoffman, j. padberg. transformations in reconfigurable place/transition systems. in degano et al. (eds.), concurrency, graphs and models: essays dedicated to ugo montanari on the occasion of his 65th birthday. lncs 5065, pp. 96–113. springer, 2008. [per95] j. padberg, h. ehrig, l. ribeiro. algebraic high-level net transformation systems. mathematical structures in computer science 5:217–256, 1995. [pra08] u. prange. towards algebraic high-level systems as weak adhesive hlr categories. in ehrig et al. (eds.), proc. workshop of applied and computational category theory (accat) at etaps 2007. electronic notes in theoretical computer science 203 / 6, pp. 67–88. elsevier, amsterdam, 2008. [rei85] w. reisig. petri nets with individual tokens. theoretical computer science 41:185–213, 1985. 21 / 21 volume 40 (2011) http://portal.acm.org/citation.cfm?id=1928162.1928184 introduction p/t nets with individual tokens p/t nets with individual tokens and their relationship to p/t systems firing of p/t nets with individual tokens transformation of p/t nets with individual tokens main results for p/t nets with individual tokens p/t nets with individual tokens as m-adhesive category gluing condition for p/t nets with individual tokens correspondence of transition firing and rule applications independence of token-firing and rule application conclusion and future work electronic communications of the easst volume 39 (2011) graph computation models selected revised papers from the third international workshop on graph computation models (gcm 2010) preface 1 pages guest editors: rachid echahed, annegret habel, mohamed mosbah managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst preface graphs are common mathematical structures which are visual and intuitive. they constitute a natural and seamless way for system modeling in several areas of science including computer science, life sciences, business processes, etc. graph computation models (gcm) constitute a class of very high level models where graphs are first-class citizens. they, thus, generalize classical computation models based on strings (e.g., chomsky’s grammars) or on trees (e.g., term rewrite systems). their mathematical foundations, in addition to their visual feature, contribute to facilitate specification, validation and analysis of complex systems. a variety of computation models has been developed yet using graphs and rule-based graph transformations. these models include features for programming languages and systems, paradigms for software development, concurrent calculi, local computations and distributed algorithms, biological or chemical computations, etc. this issue of electronic communications of the easst includes seven extended articles which have been selected out from the proceedings of the third international workshop on graph computation models (gcm 2010). all submissions were subject to a careful and standard international journal peer-reviewing process. the topics of the different articles range over a wide spectrum, including theoretical aspects of graph transformations, proof methods, semantics as well as application issues of graph computation models. we would like to thank all the reviewers for their hard work which contributed substantially to ensure the high quality of this issue. we also thank the different authors as well as the easst staff for their contributions and help in preparing this issue. july, 2011 rachid echahed, annegret habel and mohamed mosbah guest editors 1 / 1 volume 39 (2011) a visual interpreter semantics for statecharts based on amalgamated graph transformation electronic communications of the easst volume 39 (2011) graph computation models selected revised papers from the third international workshop on graph computation models (gcm 2010) a visual interpreter semantics for statecharts based on amalgamated graph transformation ulrike golas, enrico biermann, hartmut ehrig and claudia ermel 24 pages guest editors: rachid echahed, annegret habel, mohamed mosbah managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst a visual interpreter semantics for statecharts based on amalgamated graph transformation ulrike golas1, enrico biermann2, hartmut ehrig2 and claudia ermel2 1 golas@zib.de konrad-zuse-zentrum für informationstechnik berlin, germany 2 enrico|ehrig|lieske@cs.tu-berlin.de technische universität berlin, germany abstract: several different approaches to define the formal operational semantics of statecharts have been proposed in the literature, including visual techniques based on graph transformation. these visual approaches either define a compiler semantics (translating a concrete statechart into a semantical domain) or they define an interpreter using complex control and helper structures. existing visual semantics definitions make it difficult to apply the classical theory of graph transformations to analyze behavioral statechart properties due to the complex control structures. in this paper, we define an interpreter semantics for statecharts based on amalgamated graph transformation where rule schemes are used to handle an arbitrary number of transitions in orthogonal states in parallel. we build on an extension of the existing theory of amalgamation from binary to multi-amalgamation including nested application conditions to control rule applications for automatic simulation. this is essential for the interpreter semantics of statecharts. the theory of amalgamation allows us to show termination of the interpreter semantics of well-behaved statecharts, and especially for our running example, a producer-consumer system. keywords: operational semantics, statecharts, graph transformation, amalgamation 1 introduction and related work in [har87], harel introduced statecharts by enhancing finite automata by hierarchies, concurrency, and some communication issues. over time, many versions with slightly differing features and semantics have evolved. in the uml specification [omg09], the semantics of uml state machines is given as a textual description accompanying the syntax, but it is ambiguous and explained essentially by examples. in [bee02], a structured operational semantics (sos) for uml statecharts is given based on the preceding definition of a textual syntax for statecharts. the semantics combines kripke structures and an auxiliary semantics using deduction such that a semantical step is a transition step in the kripke structure. this semantics is difficult to understand due to its non-visual nature. the same problem arises in [rach00], where labeled transition systems and algebraic specification techniques are used. there are also different approaches to define a visual rule-based semantics of statecharts. one of the first was [mp96], where for each transition t a transition production pt is derived describing the effects of the corresponding transition step. a similar approach is followed in [kus01], where first a state hierarchy is constructed explicitly, and then a semantical step is given by a complex transformation unit constructed from the transition rules of a maximum set of independently 1 / 24 volume 39 (2011) mailto:golas@zib.de mailto:enrico$|$ehrig$|$lieske@cs.tu-berlin.de a visual interpreter semantics for statecharts based on amalgamation enabled transitions. in [kgkk02], in addition, class and object diagrams are integrated. the approach highly depends on concrete statechart models and is not a general interpreter semantics for statecharts. moreover, problems arise for nesting hierarchies, because the resulting situation is not fixed but also depends on other current or inactive states. in [gp98], the hierarchies of statecharts are flattened to a low-level graph representing an automaton defining the intended semantics of the statechart model. this is an indirect definition of the semantics, and the resulting transformation rules are model-specific and not applicable to statecharts in general. in [var02], varró defines a general interpreter semantics for statecharts. his intention is to separate syntactical and static semantic concepts (like conflicts, priorities etc.) of statecharts from their dynamic operational semantics, which is specified by graph transformation rules. to this end, he uses so-called model transition systems to control the application of the operational rules, which highly depend on additional helper structures encoding activation or conflicts of transitions and states. amalgamation is important for graph transformations in order to model synchronized parallelism of rules with shared subrules and corresponding transformations. for example, it has been applied to applications of parallel graph transformations to communication-based systems [tb94] and to model transformations from bpmn to bpel [bee+10]. the concept of amalgamation was first developed for the synchronization of two rules [bfh87] and then extended to that of an arbitrary number of rules [tae96] and integrated in the well-known theory of m adhesive systems [geh10]. using amalgamation for the definition of an operational semantics, the main advantage of our solution is that we do not need helper structures or a complex external control structure to cover the complex statecharts semantics: we define a state transition mainly by one interaction scheme followed by some clean-up rules. therefore, our model-independent definition based on rule amalgamation is not only visual and intuitive but allows us to show termination and forms a solid basis for applying further graph transformation-based analysis techniques. the rest of the paper is structured as follows. section 2 gives a brief introduction to our model of statecharts as typed attributed graphs. in section 3, we review the basic ideas of algebraic graph transformation [eept06] and give a short introduction to amalgamated transformation based on [geh10], which is used for the operational semantics of statecharts in section 4. based on the given semantics, we discuss the formal analysis of termination of semantical steps in statecharts. the operational semantics is demonstrated along a sample statechart modeling a producer-consumer system in section 5. in section 6, the implementation in our tool henshin is presented. finally, section 7 concludes our paper and considers future work directions. 2 modeling of statecharts in this section, we model statecharts by typed attributed graphs. we restrict ourselves to the most interesting parts of the statechart diagrams: we allow orthogonal regions as well as state nesting. but we do not handle entry and exit actions on states, nor extended state variables, and we allow guards only to be conditions over active states. gcm 2010 2 / 24 eceasst error call repair prod produced prepare empty full wait consumed arrive finish repair finish exit next produce [empty] /incbuff fail incbuff decbuff next consume [full] /decbuff figure 1: sample statechart prodcons in figure 1, the sample statechart prodcons is depicted modeling a producerconsumer system. when initialized, the system is in the state prod, which has three regions. there, in parallel a producer, a buffer, and a consumer may act. parallel substates are modelled in orthogonal regions of a common superstate (separated by dashed lines), which means that while the superstate is active, also exactly one substate from each orthogonal region is active. the producer alternates between the states produced and prepare, where the transition produce models the actual production activity. it is guarded by a condition that the parallel state empty is also current, meaning that the buffer is empty and may receive a product, which is then modeled by the action incbuff denoted after the /-dash. similarly to the producer, the buffer alternates between the states empty and full, and the consumer between wait and consumed. the transition consume is again guarded by the state full and followed by a decbuff-action emptying the buffer. two possible events may happen causing a state transition to leave the state prod: the consumer may decide to finish the complete run; or there may be a failure detected after the production leading to the error-state. after repair, the error-state can be exited via the corresponding exit-transition and the standard behavior in the prod-state is executed again. for our statechart language, we use typed attributed graphs, which are an extension of typed graphs by attributes [eept06]. we do not give details here, but use an intuitive approach, where the attributes of a node are given in a class diagram-like style. for the values of attributes in the rules we can also use variables. sm name:string r p e name:string t s name:string isinitial:bool isfinal:bool te name:string a name:string g 0..1 0..1 0..11 1 1 1 0..1 1 0..1 1 1 1..n 1..n region behavior currentnew regions states trigger action guard begin end condition next sub figure 2: type graph t gsc for statecharts the type graph t gsc is given in figure 2. we use multiplicities to denote some constraints directly in the type graph. to obtain valid statechart models, additional constraints are defined in figure 3. we use nested conditions, which are defined explicitely in section 3 and can be intuitively understood as the requirement to find occurrences of the morphism’s domain and codomain in the target object leading to commuting diagrams. note that ia defines the unique morphism from an initial object i to some object a. each diagram consists of exactly one statemachine sm (constraint c1) containing one or more orthogonal regions r. a region contains states s, where state names are unique within one region. a state may again contain one or more regions. constraint c2 expresses in addition that each region is contained in either exactly one state or the statemachine. moreover, states may be initial (attribute value isinitial = true) or final (attribute value isfinal=true), each region has to contain exactly one initial and at most one final state, and 3 / 24 volume 39 (2011) a visual interpreter semantics for statecharts based on amalgamation final states cannot contain regions (constraint c3). note that the edge type sub is only necessary to compute all substates of a state, which we need for the definition of the semantics. this relation is computed in the beginning using the statesand regions-edges. a transition t begins and ends at a state, is triggered by an event e, and may be restricted by a guard g and followed by an action a. a guard has one or more states as conditions. there is a special event with attribute value name="exit" which is reserved for exiting a state after the completion of all its orthogonal regions, which cannot have a guard condition (constraint c4). moreover, final states cannot be the beginning of a transition and their name attribute has to be set to name="final" (constraint c5). in addition, transitions cannot link states in different c1 :=∃ia1 ∧¬∃ib1 sm name="sm"a1 sm smb1 c2 :=∀(ia2,(∃a2 ∨∃b2))∧¬∃id2 ∧¬∃ie2 ∧¬∃if2 sm r b2 r a2 s r c2 sm s re2 s s rf2 s name=x s name=x r d2 c3 :=∀(ia3,∃a3)∧¬∃ic3 ∧¬∃id3 ∧¬∃ie3 ∧¬∃if3 r a3 s isinitial=true r b3 s isinitial=true s isinitial=true r c3 s isfinal=true s isfinal=true r d3 s isfinal=true r e3 s isinitial=true isfinal=true f3 c4 :=¬∃ia4 g t e name="exit"a4 c5 :=¬∃ia5 ∧∀(ib5,∃a5) t s isfinal=truea5 s isfinal=true b5 s name="final" isfinal=true c5 c6 :=¬∃ia6 s r r s s t a6 c7 :=∃ia7 ∧¬∃ib7 ∧¬∃ic7 te name=null p a7 p p c7 te name=null te b7 begin end begin a2 b2 a3 a5 figure 3: constraints limiting the valid statecharts orthogonal regions (constraint c6), which means that both regions are directly contained in the same state. a pointer p describes the active states of the statemachine. note that newly inserted current states are marked by a new-edge, while for established current states the current-edge is used (which is assumed to be the standard type and thus not marked in our diagrams). this differentiation is necessary for the semantics, where we need to distinguish between states that were current before and states that just became current in the last state transition. trigger elements te describe the events which have to be handled by the statemachine. note that they do not necessarily form a queue because orthogonal states may lead to parallel triggers which are sequentialized by the semantics. for simplicity we still call it event queue. there are at least the empty trigger element with attribute value name = null and no outgoing next-edge, and exactly one pointer in each diagram (constraint c7). the pointer and trigger elements are used later for the description of the operational semantics, but they do not belong to the general syntactical description. gcm 2010 4 / 24 eceasst p te name=null sm name="sm" r s name="error" isinitial=false isfinal=false s name="prod" isinitial=true isfinal=false t e name="exit" s name="final" isinitial=false isfinal=true r s name="call" isinitial=true isfinal=false s name="repair" isinitial=false isfinal=false s name="final" isinitial=false isfinal=true t e name="arrive" t e name="finish" t e name="repair" t e name="fail" r s name="produced" isinitial=true isfinal=false t e name="next" t e name="produce" g a name="incbuff" s name="prepare" isinitial=false isfinal=false r s name="empty" isinitial=true isfinal=false s name="full" isinitial=false isfinal=false r s name="wait" isinitial=true isfinal=false s name="consumed" isinitial=false isfinal=false t e name="next" t e name="consume" g a name="decbuff" t e name="decbuff" t e name="incbuff" t e name="finish" end begin begin end begin end begin end begin end begin endbeginend beginendbegin end beginend begin end begin end figure 4: statechart prodcons in abstract syntax in figure 4, the sample statechart prodcons from figure 1 is depicted in abstract syntax. nodes p and te are added, which have to exist for a valid statechart model but are not visible in the concrete syntax. for simulating statechart runs, the event queue of the statechart (consisting of only one default element named null in figure 4) can be filled by events to be processed (see figure 12 in section 5 for a possible event queue for our sample statechart). 5 / 24 volume 39 (2011) a visual interpreter semantics for statecharts based on amalgamation since edges of types sub, behavior, current, and next only belong to the semantics but not to the syntax of statecharts, we leave them out for the definition of the language of statecharts. all attributed graphs typed over this reduced type graph t gsc,syn satisfying all the constraints are valid statecharts. definition 1 (language v lsc) define the syntax type graph t gsc,syn = t gsc\{sub, behavior,current,next} based on the type graph t gsc in figure 2. the language v lsc consists of all typed attributed graphs respecting the type graph t gsc,syn and the constraints in figure 3, i. e. v lsc ={(g,type) | type : g → t gsc,syn,g |= c1 ∧...∧c7}. 3 introduction to amalgamated graph transformation in this section, we review the basic ideas of algebraic graph transformation [eept06] and give a short introduction into amalgamated transformation based on [geh10], to be used for the interpreter semantics of statecharts in section 4. a graph grammar gg = (rs,sg) consists of a set of rules rs and a start graph sg. a rule p = (l l←− k r−→ r,ac) consists of a left-hand side l, an interface k, a right-hand side r, two injective graph morphisms l l←−k and k r−→r, and an application condition ac on l. applying a rule p to a graph g means to find a match m of l in g, given by a graph morphism m : l → g which satisfies the application condition ac, and to replace this matched part m(l) by the corresponding right-hand side r of the rule. by g p,m =⇒ h, we denote the direct graph transformation where rule p is applied to g with match m leading to the result h. the formal construction of a direct transformation is a double-pushout (dpo) as shown in the diagram with pushouts l k r g d h ac l r m (po1) (po2) (po1) and (po2) in the category of graphs. the graph d is the intermediate graph after removing m(l), and h is constructed as gluing of d and r along k. a graph transformation is a sequence of direct transformations, denoted by g ∗ =⇒ h, and the graph language l(gg) of graph grammar gg is the set l(gg) ={g | sg ∗=⇒ g} of all graphs derivable from sg. an important concept of algebraic graph transformation is parallel and sequential independence of graph transformation steps leading to the local church–rosser and parallelism theorem [roz97], where parallel independent steps g p1,m1 =⇒ g1 and g p2,m2 =⇒ g2 lead to a parallel transformation g p1+p2,m =⇒ h based on a parallel rule p1 + p2. if p1 and p2 share a common subrule p0, the amalgamation theorem in [bfh87] shows that a pair of “amalgamable” transformations g (pi,mi) =⇒ gi (i = 1,2) leads to an amalgamated transformation g p̃,m̃ =⇒ h via the amalgamated rule p̃ = p1 +p0 p2 constructed as gluing of p1 and p2 along p0. the concept of amalgamable transformations is a weak version of parallel independence, with independence outside the subrule match, and amalgamation can be considered as a kind of “synchronized parallelism”. for the interpreter semantics of statecharts we need an extension of amalgamation in [bfh87] w.r.t. three aspects: first, we need a family of rules p1,..., pn with a common subrule p0 for n ≥ 2; second, we need typed attributed graphs [eept06] instead of “plain graphs”, and third, we need rules with application conditions. gcm 2010 6 / 24 eceasst in the following, we formulate the extended amalgamation concept for a general notion of graphs and application conditions, where general graphs are objects in a weak adhesive hlr category [eept06] and general application conditions are nested application conditions [hp09], including positive and negative ones and their combinations by logic operators. for readers not familiar with weak adhesive hlr categories and nested application conditions, it is sufficient to think of rules based on graphs and (typed) attributed graphs with positive and/or negative application conditions (see [eept06] for more details). a match m : l → g satisfies a positive (negative) condition of the form ∃a (¬∃a) for a : l → n if there is a (no) injective q : n → g with q◦a = m. more general, m : l → g satisfies a nested condition of the form ∃(a,acn) on l with condition acn on n if there is an injective q : n → g with q◦a = m and q satisfies acn . note that ∀(a,acn) is denoted as ¬∃(a,¬acn) (see application conditions in figure 9 and figure 10). l l′ g ac shift(t,ac)t m m′= an important concept is the shift of ac on l along a morphism t : l → l′ s.t. for all m′◦ t : l → g, m′ satisfies shift(t,ac) if and only if m = m′◦ t : l → g satisfies ac [ehl10]. based on [geh10], we are now able to introduce amalgamated rules and transformations with a common subrule p0 of p1,..., pn. a kernel morphism describes how the subrule is embedded into the larger rules. l0 k0 r0 li ki ri l0 r0 si,l si,k si,r(1i) (2i) definition 2 (kernel morphism). given rules pi = (li li←− ki ri−→ ri,aci) for i = 0,...,n, a kernel morphism si : p0 → pi consists of morphisms si,l : l0 → li, si,k : k0 → ki, and si,r : r0 → ri such that in the diagram on the right (1i) and (2i) are pullbacks and (1i) has a pushout complement for si,l ◦ l0, i.e. si,l satisfies the gluing condition w.r.t. l0. the pullbacks (1i) and (2i) mean that k0 is the intersection of ki with l0 and also of ki with r0. p0 p̃ pi t0 si ti= definition 3 (amalgamated rule and transformation). given rules pi = (li li←− ki ri−→ ri,aci) for i = 0,..,n with kernel morphisms si : p0 → pi (i = 1,...,n), then the amalgamated rule p̃ = (l̃ ←− k̃ −→ r̃,ãc) of p1,..., pn via p0 is constructed as the componentwise gluing of p1,..., pn along p0, where ãc is the conjunction of shift(ti,l,aci). l̃ is the gluing of l1,...,ln with shared l0 leading to ti,l : li → l̃. similar gluing constructions lead to k̃ and r̃ and we obtain kernel morphisms ti : pi → p̃ and ti ◦si = t0 for i = 1,...,n. we call p0 kernel rule, and p1,..., pn multi rules. an amalgamated transformation g p̃ =⇒ h is a transformation via the amalgamated rule p̃. example 1 (amalgamated rule construction) we construct an amalgamated rule for the initialization of a statemachine with two orthogonal regions. a pointer has to be linked to the statemachine and to the initial states of both the statemachine’s regions. rules are depicted in a compact notation where we do not show the interface k. it can be inferred by the intersection l∩r. the mappings are given as numberings for nodes and can be inferred for edges. the kernel rule p0 in figure 5 models the linking of the pointer to the statemachine. we have two multi-rules p1 and p2 modelling the linking of the pointer to the initial states of two different 7 / 24 volume 39 (2011) a visual interpreter semantics for statecharts based on amalgamation p0 : 1:sm 2:p l0 1:sm 2:p r0 p1 : 1:sm 2:p 3:r 4:s isinitial=truel1 1:sm 2:p 3:r 4:s isinitial=truer1 p2 : 1:sm 2:p 5:r 6:s isinitial=truel2 1:sm 2:p 5:r 6:s isinitial=truer2 p̃ : 1:sm 2:p 3:r 4:s isinitial=true 5:r 6:s isinitial=truel̃ 1:sm 2:p 3:r 4:s isinitial=true 5:r 6:s isinitial=truer̃ s1,l s1,r s2,l s2,r t1,l t1,r t2,l t2,r new new new new figure 5: construction of amalgamated rule regions. in the amalgamated rule p̃, the common subaction (linking the pointer to the statemachine) is represented only once since the multi-rules p1 and p2 have been glued at the kernel rule p0. the kernel morphisms are ti : pi → p̃ for i = 1,2. given a bundle of direct transformations g pi,mi =⇒ gi (i = 1,..,n), where p0 is a subrule of pi, we want to analyze whether the amalgamated rule p̃ is applicable to g combining all direct transformations. this is possible if they are multi-amalgamable, i.e. the matches agree on p0 and are parallel independent outside. this concept of multi-amalgamability is a direct generalization of amalgamability in [bfh87] and leads to the following theorem [geh10]. theorem 1 (multi-amalgamation) given rules p0,..., pn, where p0 is a subrule of pi, and multi-amalgamable direct transformations g pi,mi =⇒ gi (i = 1,...,n), then there is an amalgamated transformation g p̃,m̃ =⇒ h. proof idea: using the properties of the multi-amalgamable bundle, we can show that m̃ with m̃◦ti,l = mi induced by the colimit is a valid match for the amalgamated rule p̃ leading to the amalgamated transformation because the componentwise gluing is a colimit construction. for an extended proof idea see thm. 2 in [geh10], the complete proof can be found in [gol11]. for many application areas, including the interpreter semantics of statecharts, we do not want to explicitly define the kernel morphisms between the kernel rule and the multi rules, but we want to obtain them dependent on the object to be transformed. in this case, only an interaction scheme is ={s1,...,sk} with kernel morphisms s j : p0 → p j ( j = 1,...,k) is given, which defines different bundles of kernel morphisms s′i : p0 → p ′ i (i = 1,...,n) where each p ′ i corresponds to some p j for j ≤ k. gcm 2010 8 / 24 eceasst definition 4 (interaction scheme) a kernel rule p0 and a set of multi rules {p1,..., pk} with kernel morphisms si : p0 → pi form an interaction scheme is ={s1,...,sk}. given an interaction scheme, we want to apply as many rules p j as often as possible over a certain match of the kernel rule p0. in the following, we consider maximal weakly disjoint matchings, where we require the matchings of the multi rules not only to be multi-amalgamable, but also disjoint up to the match of the kernel rule, and maximal in the sense that no more valid matches for any multi rule in the interaction scheme can be found. l0 l′i l′` g si,l s`,l mi m` (pi`) definition 5 (maximal weakly disjoint matching). given an interaction scheme is ={s1,...,sk} and a tuple of matchings m = (mi : l′i → g) with i = 1,...,n, where each p′i corresponds to some p j for j ≤ k, with transformations g p′i,mi =⇒gi, then m forms a maximal weakly disjoint matching if the bundle g p′i,mi =⇒gi is multi-amalgamable, the square (pi`) is a pullback for all i 6= `∈{1,...,n}, and for any rule p j no other match m′ : l j →g can be found such that ((mi),m′) fulfills this property. note that different matches may use the same rule p j. the pullback requirement already implies the existence of the morphisms to show that the matches are parallel independent outside the kernel match. only the property for the application conditions has to be checked in addition. proposition 1 given an object g, a bundle of kernel morphisms s = (s1,...,sn), and matches m1,...,mn leading to a bundle of direct transformations g = pi,mi ==⇒ gi such that mi ◦si,l = m0 and square (pi`) is a pullback for all i 6= ` then the bundle g = pi,mi ==⇒ gi is s-amalgamable for transformations without application conditions. proof. by construction, the matches mi agree on the match m0 of the kernel rule. it remains to be shown that they are parallel independent outside the kernel match. k0 l0 ki li p l j di g ki ri di gi li g l0 si,k p s j,l si,l li ki f̂ m̂ m j fi mi fi li mi ri ki gi ni(20i) (21i) given the transformations g = pi,mi ==⇒ gi with pushouts (20i) and (21i), consider the following cube, where the bottom face is pushout (20i), the back right face is a pullback by definition, and the front right face is pullback (pi j). now construct the pullback of fi and m j as the front left face, and from m j ◦s j,l◦l0 = mi◦si,l◦l0 = mi◦li◦si,k = fi◦ki◦si,k we obtain a morphism p with f̂ ◦ p = s j,l ◦l0 and m̂◦ p = ki ◦si,k . from pullback composition and decomposition it follows that also the back left face is a pullback. now the m -van kampen property leads to a pushout in the top face. since pushout complements are unique up to isomorphism, p is isomorphic to k j. thus the morphism p ji := m̂ leads to parallel independence outside the kernel match. this construction can be applied for all pairs i, j leading to weakly parallel independent matches without application conditions. 9 / 24 volume 39 (2011) a visual interpreter semantics for statecharts based on amalgamation with this characterization of maximal weakly independent matches we obtain the following algorithm for their computation. algorithm 1 (maximal weakly disjoint matching). given an object g and an interaction scheme is = {s1,...,sk}, a maximal weakly disjoint matching m = (m0,m1,...,mn) can be computed as follows: 1. set i = 0. choose a kernel matching m0 : l0 → g such that g = p0,m0 ===⇒ g0 is a valid transformation. 2. as long as possible: increase i, choose a multi rule p̂i = p j with j ∈{1,...,k}, and find a match mi : l j → g such that mi◦s j,l = m0, g = p j,mi ==⇒ gi is a valid transformation, mi 6= m`, the square (pi`) is a pullback, and p̂` is applicable to gi via the extension of m` to gi for all ` = 1,...,i−1, i.e. the application condition âc` is satisfied for this extended match. 3. if no more valid matches for any rule in the interaction scheme can be found, return m = (m0,m1,...,mn). note, that we may find different maximal weakly disjoint matchings for a given interaction scheme, which may even lead to the same bundle of kernel morphisms. for a fixed maximal weakly disjoint match we can apply theorem 1 leading to an amalgamated transformation g p̃′,m̃ =⇒ h, where p̃′ is the amalgamated rule of p′1,..., p ′ n via p0. given a set is of interaction schemes is and a start graph sg, we obtain an amalgamated graph grammar with amalgamated transformations via maximal matchings, defined by maximal weakly disjoint matchings of the corresponding multi rules. definition 6 (amalgamated graph grammar) an amalgamated graph grammar agg = (is,sg) consists of a set is of interaction schemes and a start graph sg. the language l(agg) of agg is defined by l(agg) ={g | ∃ amalgamated transformation sg =∗⇒ g via maximal matchings}. 4 an interpreter semantics for statecharts the semantics of statecharts is modeled by amalgamated transformations, where one step in the semantics is modeled by several applications of interaction schemes. the main part of a state transition can be modeled by a single interaction scheme, but some additional rules are necessary to remove and add the proper pointers from and to hierarchical states. for the application of an interaction scheme we use maximal weakly disjoint matchings. the termination of the interpreter semantics of a statechart in general depends on the structural properties of the simulated statechart. a simulation will terminate for the trivial cases that the event queue is empty, that no transition triggers an action, or that there is no transition from any active state triggered by the current head elements of the event queue. since transitions may trigger actions which are added as new events to the queue it is possible that the simulation of a statechart may not terminate even if all semantical steps do. hence, it is useful to define structural constraints that provide a sufficient condition guaranteeing termination of the simulation in gcm 2010 10 / 24 eceasst general for well-behaved statecharts, where we forbid cycles in the dependencies of actions and events. definition 7 (well-behaved statecharts) for a given statechart model, the action-event graph has as nodes all event names and an edge (n1,n2) if an event with name n1 triggers an action named n2. a statechart is called well-behaved if it is finite, has an acyclic state hierarchy, and its actionevent graph is acyclic. example 2 an example of a well-behaved statechart is our statechart model in figure 1. it is finite, has an acyclic state hierarchy, and its action-event graph is shown in figure 6. this graph is acyclic, since the only action-event dependencies in our statechart occur between produce triggering incbuff and consume triggering decbuff. arrive repair fail produce incbuff next finish exit consume decbuff figure 6: the action-event graph of our statechart example the semantics of our statecharts is modeled by amalgamated transformations, but we apply the rules in a more restricted way, meaning that one step in the semantics is modeled by several applications of interaction schemes. we assume to have a finite statechart with a finite event queue where all trigger elements are already given in the diagram as an initial event queue. for the initialization step, we compute all substates of all states by applying the rules setsub and transsub in figure 7 as long as possible. then, the interaction scheme init is applied followed by the interaction scheme enterregions applied as long as possible, which are depicted in figure 8. with init, the pointer is associated to the statemachine and all initial states of the statemachine’s regions. the interaction scheme enterregions handles the nesting and sets the current pointer also to the initial states contained in an active state. when applied as long as possible, this means that all substates are handled. note that not all initial substates become setsub 1:s 2:r 3:s l11 1:s 2:r 3:s r11 ac11 =¬∃a11 l11 r11 transsub 1:s 2:s 3:s l21 1:s 2:s 3:s r21 ac21 =¬∃a21 l21 r21 a11 sub a21 sub sub sub sub sub figure 7: the rules setsub and transsub 11 / 24 volume 39 (2011) a visual interpreter semantics for statecharts based on amalgamation init = (s3) 1:sm 2:p l30 1:sm 2:p r30 1:sm 2:p 3:r 4:s isinitial=truel31 1:sm 2:p 3:r 4:s isinitial=truer31 ac30 =¬∃a30 l30 r30 ac31 = shift(s3,l,ac30) enterregions = (idp40,s4,s ′ 4,s ′′ 4) 1:s 2:p l40 1:s 2:p r40 1:s 2:p 3:r 4:s isinitial=truel41 1:s 2:p 3:r 4:s isinitial=truer41 ac40 = true ac41 =¬∃a41 ∧¬∃b41 l41 1:s 2:p 3:r s l41 1:s 2:p 3:r s l40 r40 1:s 2:p 5:r 6:s l42 1:s 2:p 5:r 6:s r42 ac42 =¬∃a42 ∧¬∃b42 l42 1:s 2:p 5:r 6:s l42 1:s 2:p 5:r 6:s l40 r40 1:s 2:p l43 1:s 2:p r43 ac43 = true a42 b42 new new new new a41 b41 new new new new new a30 s3,l s3,r s4,l s4,r s′4,l s ′ 4,r s′′4,l s ′′ 4,r new new new new figure 8: the interaction schemes init and enterregions active, but only those which are contained in a hierarchy of nested initial states. the interaction scheme enterregions also contains the identical kernel morphism idp40 : p40 → p40. using maximal weakly disjoint matchings, an identical kernel morphism has the effect that the kernel rule can be applied without a valid match for any multi rule. this ensures that this kernel rule is also applied in the lowest hierarchy level changing the newto a current-edge. for later use, also double edges are deleted and if the direct superstate is not marked by the pointer a new-edge is added to it. gcm 2010 12 / 24 eceasst the application of the rules setsub and transsub terminates because there could be at most one sub-edge between each pair of states due to the application conditions. since no new states are created, these rules can only be applied finitely often. the initialization step (applying init once and enterregions as long as possible) terminates because the application of the interaction scheme enterregions terminates: each application of enterregions replaces one new-edge with a current-edge. the multi rules p41 and p42 create new new-edges on the next lower and upper levels of a hierarchical state, but if the state hierarchy is acyclic this interaction scheme is only applicable a finite number of times. the same holds for the multi rule p43 which deletes double edges, since the number of currentand new-edges is decreased. thus, the transformation terminates. proposition 2 (termination of initialization step) for well-behaved statecharts, the initialization step terminates. a state transition representing a semantical step, i. e. switching from one state to another, is done by the application of the interaction scheme transitionstep shown in figure 9 followed by the interaction schemes enterregions!, leavestate1!, leavestate2!, and leaveregions! given in figure 8, 10, and 11 in this order, where ! means that the corresponding interaction scheme is applied as long as possible. for such a semantical step, the first trigger element (or one of the first if more than one action of different orthogonal substates may occur next) is chosen and deleted, while the corresponding state transitions are executed. the application condition ac50 ensures that exit-trigger elements are handled with priority, because the rule is only applicable if for any existing exit-trigger element (∀a50) this is not a start element in the queue, i.e. it has a predecessor (∃b50). moreover, it ensures that the chosen trigger element is a starting one, i.e. has no predecessor (¬∃c50). note that a transition triggered by its trigger element is active if the state it begins at is active, its guard condition state is active, and it has no active substate where a transition triggered by the same event is active. these restrictions are handled by the application conditions ac51 and ac52. moreover, if an action is provoked, this has to be added as one of the first next trigger elements. the two multi rules of transitionstep handle the state transition with and without action, respectively. the application condition ac52 is not shown explicitly, but the morphisms a52,..., f52 are similar to a51,..., f51 except that all objects contain in addition the node 8:a. the interaction schemes leavestate1, leavestate2, and leaveregions handle the correct selection of the active states. when for a yet active state with regions, by state transitions all states in one of its regions are no longer active, also this superstate is no longer active, which is described by leavestate1. the interaction scheme leavestate2 handles the case that, when a state become inactive by a state transition, also all its substates become inactive. if for a state with orthogonal regions the final state in each region is reached then these final states become inactive, and if the superstate has an exit-transition it is added as the next trigger element. this is handled by leaveregions. for the termination of a semantical step it is sufficient to show that the four interaction schemes enterregions, leavestate1, leavestate2, and leaveregions are only applicable a finite number of times. for the interaction scheme enterregions we have already argued that above. the interaction schemes leavestate1, leavestate2 as well as the multi rule 13 / 24 volume 39 (2011) a visual interpreter semantics for statecharts based on amalgamation transitionstep = (s5,s′5) l50 1:p 2:te name=x te name="exit"3:te 1:p 3:te te te name="exit" 2:te name=x ac50 =∀(a50,∃b50)∧¬∃c50 l50 1:p te 2:te name=x 3:te 1:p 2:te name=x 3:te l50 1:p 3:te r50 1:p 2:te name=x 3:te 4:s 5:t 6:s 7:e name=x l51 1:p 3:te 4:s 5:t 6:s 7:e name=x r51 ac51 = shift(s5,l,ac50)∧¬∃g51 ∧¬∃a51 ∧∀(b51,∃c51)∧∀(d51,∃(e51,¬∃ f51)) l51 l52 l51 a5 l51 b5 c5 l51 d5 e5 f5 1:p 2:te name="exit" 3:te 4:s 5:t s 6:s 7:e name="exit"a5 1:p 2:te name=x 3:te 4:s 5:t 6:s 7:e name=x g sb5 1:p 2:te name=x 3:te 4:s 5:t 6:s 7:e name=x g sc5 1:p 2:te name=x 3:te 4:s 5:t 6:s t e name=x 7:e name=x s d5 1:p 2:te name=x 3:te 4:s 5:t 6:s t e name=x 7:e name=x s g s e5 1:p 2:te name=x 3:te 4:s 5:t 6:s t e name=x 7:e name=x s g s f5 l50 r50 1:p 2:te name=x 8:a name=y 3:te 4:s 5:t 6:s 7:e name=x l52 te name=y 1:p 3:te 4:s 5:t 6:s 7:e name=x 8:a name=y r52 ac52 = shift(s′5,l,ac50)∧¬∃a52 ∧∀(b52,∃c52)∧∀(d52,∃(e52,¬∃ f52)) s5,l s5,r a50 b50 c50 g51 b51 c51 d51 e51 f51a51 begin end new begin end begin end begin end begin end begin end begin begin end begin begin end begin s′5,l s ′ 5,r begin end new begin end figure 9: the interaction scheme transitionstep p81 of the interaction scheme leaveregions reduce the number of active states in the statechart by deleting at least one current-edge. the application of the second multi rule p82 of the interaction scheme leaveregions prevents another match for itself because it creates the situation forbidden by its application condition ac82. it follows that the application of each of these four interaction schemes as long as possible terminates. gcm 2010 14 / 24 eceasst leavestate1 = (idp60) ac60 =∃(a60,¬∃b60) l60 1:s 2:p r 1:s 2:p r s 1:s 2:p l60 1:s 2:p r60 leavestate2 = (s7) ac70 =¬∃a70 l70 1:s 2:p 1:s 2:p l70 1:s 2:p r70 1:s 2:p3:s l71 1:s 2:p3:s r71 ac71 = shift(s7,l,ac70) a70 s7,l s7,r a60 b60 figure 10: the interaction schemes leavestate1 and leavestate2 leaveregions = (s8,s′8) ac80 =∀(a80,∃b80)∧¬∃c80 ∧¬∃d80 l80 1:s 2:p te 3:te l80 1:s 2:p 3:te r s isfinal=true 1:s 2:p 3:te r s isfinal=true l80 1:s 2:p 3:te s isfinal=false 1:s 2:p 3:te l80 1:s 2:p 3:te r80 1:s 2:p 3:te 4:s l81 1:s 2:p 3:te 4:s r81 ac81 = shift(s8,l,ac80) l80 r80 1:s 2:p 3:te 4:t 5:e name="exit" l82 1:s 2:p 3:te 4:t 5:e name="exit" te name="exit" r82 ac82 = shift(s′8,l,ac80)∧¬∃a82 l82 1:s 2:p 3:te name="exit" 4:t 5:e name="exit" begina82 s8,l s8,r d80 c80b80a80 begin begin s′8,l s ′ 8,r figure 11: the interaction scheme leaveregions 15 / 24 volume 39 (2011) a visual interpreter semantics for statecharts based on amalgamation proposition 3 (termination of semantical steps) given a well-behaved statechart, each semantical step terminates. combining all the rules as explained above leads to the semantics of statecharts. definition 8 (statechart semantics) the operational semantics of statecharts consists of one initialization step followed by as many as possible semantical steps defined as follows: • initialization step. for a statechart model m ∈v lsc (see definition 1) we obtain a model minitial by applying the sequence setsub!, transsub!, init, enterregions! to m. • semantical step. consider a model m1 with m1 obtained by a finite number of semantical steps from a model minitial for some m ∈ v lsc, then a semantical step from m1 to m2 is computed by applying the sequence transitionstep, enterregions!, leavestate1!, leavestate2!, leaveregions! to m1. moreover, combining our termination results we can conclude the termination of the statecharts semantics for well-behaved statecharts. theorem 2 (termination of interpreter semantics) for well-behaved statecharts with finite event queue, the interpreter semantics terminates. proof. according to proposition 2 and proposition 3, each initialization step and each semantical step terminates. moreover, each semantical step consumes an event from the event queue. if it triggers an action, the acyclic action-event graph ensures that there are only chains of events triggering actions, but no cycles, such that after the execution of this chain the number of elements in the event queue actually decreases. thus, after finitely many semantical steps the event queue is empty and the operational semantics terminates. 5 application to the running example we now consider an initialization and a semantical step in our statechart example from figure 1. in the top of figure 12, we show the incoming event queue as needed for our system run to be processed. note that the actions that are triggered by state transitions do not occur here because they are started internally, while the other events have to be supplied from the outside. thus, the internal events are supplied by the semantical rules themselves, while the external ones have to be given. for simplicity, we assume that the complete external event queue is given in advance, but the events could also appear one after the other using some additional rule that appends an event at the end of the queue. in the bottom of figure 12, the current states and their corresponding state transitions are depicted. we want to simulate these semantical steps now using the rules for the semantics applied to the statechart in abstract syntax in figure 4, extended by the event queue from figure 12. first, the initialization has to be done. we compute all sub-edges by applying the rules setsub and transsub in figure 7 as long as possible. for the actual initialization, we apply gcm 2010 16 / 24 eceasst current: prod produced empty wait current: prod prepare empty wait current: prod produced empty wait current: prod produced full wait current: prod produced full consumed current: prod produced empty consumed current: prod prepare empty wait current: prod produced empty wait current: prod produced full wait current: prod produced full consumed current: prod produced empty consumed current: error call current: error repair current: error repair current: error current: prod produced empty wait event queue: te name="next" te name="produce" te name="consume" te name="next" te name="produce" te name="consume" te name="null" te name="finish" te name="repair" te name="arrive" te name="fail" next produce →incbuff incbuff consume →decbuff decbuff next produce →incbuff incbuffconsume →decbuff decbufffail arrive repair finish →exit exit figure 12: event queue and state transitions the interaction scheme init from figure 8 followed by the application of enterregions as long as possible. with init, we connect the state machine and the pointer node, and in addition set the pointer to the prod-state using a new-edge. now the only available kernel match for enterregions is the match mapping node 1 to the prod-state, and with maximal matchings we obtain the bundle of kernel morphisms (idp40,s4,s4,s4), where the node 4 in l41 is mapped to the states produced, empty, and wait, respectively. after the application of the corresponding amalgamated rule, the current pointer is now connected to the state machine and the state prod, and via new-edges to the states produced, empty, and wait. further applications of enterregions using these three states for the kernel matches, respectively, lead to the bundle (idp40) thus changing the new-edges to current-edges by its application. error call repair prod produced prepare empty full wait consumed arrive finish repair finish exit next produce [empty] /incbuff fail incbuff decbuff next consume [full] /decbuff figure 13: the statechart after the initialization step as a result, the states prod, produced, empty, and wait are current, which is the initial situation for the statemachine as shown in figure 13, where the current states are marked by thicker lines. we do not find additional matches for enterregions, as we only have one level of nesting in our diagram, which means that the initialization is completed. 17 / 24 volume 39 (2011) a visual interpreter semantics for statecharts based on amalgamation for a state transition, the interaction scheme transitionstep in figure 9 is applied, followed by the interaction schemes enterregions!, leavestate1!, leavestate2!, and leaveregions! given in figure 8, 10, and 11. for the initial situation, the kernel rule p50 in figure 9 has to be matched such that the node 2 is mapped to the first trigger element next and the node 3 to produce, otherwise the application condition of the rule p50 would be violated. for the multi rules, there are two events with the name next, but since the state consumed is not current, only one match for l51 is found mapping the nodes 4 to the current state produced and 6 to the state prepare. all application conditions are fulfilled, since this transition does not have a guard or action, and the state produced does not have any substates. thus, the application of the bundle (s5) deletes the first trigger element next, which is done by the kernel rule, and redirects the current pointer from produced to prepare via a new-edge. an application of the interaction scheme enterregions using the bundle (idp40) changes this new-edge to a current-edge. since we do not find further matches for l40, l60, l71, l81, and l82, the other interaction schemes cannot be applied. this means that the states prod, prepare, empty, and wait are now the current states, which is the situation after the state transition triggered by next as shown in figure 12. for the next match of the kernel rule p50, the node 2 is mapped to the new next trigger element produce and 3 is mapped to consume. since the transition produce has an action, we cannot apply the multi rule p51 but p52 has a valid match. in particular, the application condition is fulfilled because the guard condition state empty is current and the state prepare does not have any substates. thus, the bundle (s′5) leads to the deletion of the trigger element produce, the current pointer is redirected from prepare to produced, and a new trigger element incbuff is inserted with a next-edge to the trigger element consume. again, enterregions changes the newto a current-edge and we do not find further matches for l40, l60, l71, l81, and l82. this means that now the states prod, produced, empty, and wait are current. we can process our trigger element queue step by step retracing the state transitions by the application of the rules. we do not explain all steps explicitly, but skip until after the last decbuff-trigger element, which leads to the current states prod, produced, empty, and consumed. the next match of the kernel rule p50 maps the nodes 2 to the trigger element fail and 3 to arrive. the only match for the multi rules maps the nodes 4 and 6 in l51 to the states produced and error, respectively. since the application condition is fulfilled, the application of the bundle (s5) leads to the deletion of the trigger element fail, and the current pointer is redirected from produced to error. now we find a match for the interaction scheme enterregions mapping the node 1 to the state error and 4 to the state call. thus the application of the bundle (idp40,s4) adds a new pointer to the state call, which is then changed from new to current. afterwards, we find a match for leavestate1, where the kernel rule match maps the node 1 to the state prod. the application condition is fulfilled because there is a region the one for the producer where no state is current. thus, the currentedge to prod is deleted. no more matches for l60 can be found, but there are two different matches for the multi rule p71 of leavestate2 matching the node 3 to the states empty and consumed, respectively. the application of the bundle (s7,s7) then leads to the deletion of the gcm 2010 18 / 24 eceasst current pointer for the states empty and consumed. no more matches for l71, l81, and l82 can be found. altogether, the states error and call are current now. this is exactly the situation as described in figure 12 after the state transition triggered by the fail-event. now we skip again two more trigger elements leading to the remaining trigger element queue finish → null and the current states error and repair. the kernel rule p50 is now matched to these two trigger elements, and the application of the bundle (s5) deletes the trigger element finish and redirects the current pointer from repair to final, the final state within the error-state. with enterregions, the corresponding new-edge is set to current. no matches for l60 and l71 can be found, but we find a match for the interaction scheme leaveregions, where the kernel rule is matched such that the node 1 is mapped to the state error and 3 is mapped to the null-trigger element. the application condition is fulfilled because all current substates of error are final states actually, there is only the one and null is the first trigger element in the queue. now there is a match for l81 mapping the node 4 to the state final and a match for l82 mapping the nodes 4 and 5 to the transition and the event between the stated error and prod. after the application of the bundle (s8,s′8), the current pointer is deleted from the final-state, and a new exit-trigger element is inserted before the null-trigger element. no more matches for l81 and l82 can be found, thus only the state error is current. a last application of the interaction scheme transitionstep followed by enterregions leads back to the initial situation and completes our example, since the event queue is empty except for the default element null. according to thm. 2, the simulation of our example terminates because our statechart is wellbehaved and the event queue is finite. 6 implementation recently, we have extended our tool henshin1 by visual editors for amalgamated rules and application conditions [besw10]. henshin is an eclipse plug-in supporting visual modeling and execution of emf model transformations, i.e. transformations of models conforming to a metamodel given in the emf ecore format. the transformation approach we use in our tool is based on graph transformation concepts which are lifted to emf model transformation by also taking containment relations in meta-models into account [abj+10]. the recent extensions of henshin enable us to validate the model of the visual interpreter semantics presented in this paper. the startgraph of our statechart interpreter is modeled in henshin as an emf instance (see figure 14). for simulation, henshin supports the definition of control structures (called transformation units) for rules, such as “apply rule r1 once, and then the rules from the set {r1,r2} in arbitrary order and as long as possible”. transformation units may be nested, the atomic unit being a rule. the main transformation unit for the statechart simulation is shown in figure 15. here, the initialization step is executed by applying the subunit initstatechart (see right part of figure 15). this step is realized by a sequence of units inserting at first the auxiliary edges of the type sub in the statechart model by applying the countedunit initsubedges (containing a rule) as 1 http://www.eclipse.org/modeling/emft/henshin/ 19 / 24 volume 39 (2011) a visual interpreter semantics for statecharts based on amalgamation figure 14: the initial statechart modeled in henshin long as possible (denoted by the count number “-1”), then applying the amalgamationunit init which corresponds to the interaction scheme init in figure 8, followed by the interaction scheme enterallregions applied as long as possible. having performed the initialization step, the second step in the main unit execute consists of performing as many semantical steps as possible, triggered by the event queue. the unit executeallevents applies its subunit executeevent (shown in the left part of figure 16) as long as possible. in this step, the interaction scheme transitionstep is applied, followed by as many applications as possible of the interaction schemes for entering regions and states, and leaving them afterwards. interaction schemes like transitionstep are visualized in henshin as a rule set containing one kernel rule and one or more multi-rules (see right part of figure 16). a multi-rule view in henshin shows in an integrated way the corresponding kernel rule elements as simple rectangles and the additional multi-rule elements as rectangles with a shadow (see figure 17). application conditions for rules are visualized as logical connector blocks to the left of the rule’s left-hand side (see left side of figure 17), where the inherent morphisms can be expanded to a morphism view similar to the rule view, where mappings are indicated by colors and the numbers of the nodes. gcm 2010 20 / 24 eceasst figure 15: the main transformation unit execute (left) and its subunit initstatechart (right) figure 16: the transformation unit executeevent (left) and its subunit transitionstep (right) figure 17: the multi-rule transitionstep m52 21 / 24 volume 39 (2011) a visual interpreter semantics for statecharts based on amalgamation 7 conclusion and future work in this paper, we have defined a formal interpreter semantics for statecharts leading to a visual interpreter semantics. it is based on the theory of algebraic graph transformation and hence a solid basis for applying graph transformation-based analysis techniques. unfortunately, the classical theory of graph transformations [roz97] is not adequate to model the interpreter semantics of statecharts because we need rule schemes to handle an arbitrary number of transitions in orthogonal states in parallel. in this paper, we have solved this problem using amalgamated graph transformation [geh10] in order to handle the interpreter semantics. as a first step towards the analysis of this semantics we have shown the termination of initialization and semantical steps and, more general, the termination of the interpreter semantics for well-behaved statecharts. our formal approach is also a promising basis to analyze other properties like confluence and functional behavior in the future. since termination and local confluence implies confluence, it is sufficient to analyze local confluence. this has been done successfully for algebraic graph transformation based on standard rules and critical pairs [eept06]. it remains to extend this analysis from standard rules to amalgamated rules constructed by interaction schemes and to take into account maximal matchings as well as all essential amalgamated rules constructed from one interaction scheme. the formal definition of syntax and operational semantics of statecharts in this paper provides the basis for a model transformation from statecharts to petri nets [geh11], which is shown to be semantics-preserving in [gol11]. another interesting research area to be considered in future is the nesting of kernel morphisms, which may lead to a hierarchical interaction scheme such that a semantical step of the statechart is actually a direct amalgamated transformation over one interaction scheme, and we no longer need rules for redirecting the current pointer afterwards. bibliography [abj+10] t. arendt, e. biermann, s. jurack, c. krause, g. taentzer. henshin: advanced concepts and tools for in-place emf model transformations. in petriu et al. (eds.), proceedings of mocels 2010, part i. lncs 6394, pp. 121–135. springer, 2010. [bee02] m. beeck. a structured operational semantics for uml-statecharts. software and systems modeling 1:130–141, 2002. [bee+10] e. biermann, h. ehrig, c. ermel, u. golas, g. taentzer. parallel independence of amalgamated graph transformations applied to model transformation. in engels et al. (eds.), graph transformations and model-driven engineering. essays dedicated to m. nagl on the occasion of his 65th birthday. lncs 5765, pp. 121–140. springer, 2010. [besw10] e. biermann, c. ermel, j. schmidt, a. warning. visual modeling of controlled emf model transformation using henshin. eceasst 32:1–13, 2010. gcm 2010 22 / 24 eceasst [bfh87] p. böhm, h.-r. fonio, a. habel. amalgamation of graph transformations: a synchronization mechanism. jcsc 34(2-3):377–408, 1987. [eept06] h. ehrig, k. ehrig, u. prange, g. taentzer. fundamentals of algebraic graph transformation. eatcs monographs. springer, 2006. [ehl10] h. ehrig, a. habel, l. lambers. parallelism and concurrency theorems for rules with nested application conditions. eceasst 26:1–23, 2010. [geh10] u. golas, h. ehrig, a. habel. multi-amalgamation in adhesive categories. in proceedings of icgt 2010. lncs 6372, pp. 346–361. springer, 2010. [geh11] u. golas, h. ehrig, f. hermann. formal specification of model transformations by triple graph grammars with application conditions. eceasst 39:1–26, 2011. this volume. [gol11] u. golas. analysis and correctness of algebraic graph and model transformations. phd thesis, technische universität berlin, 2011. vieweg+teubner. [gp98] m. gogolla, f. parisi-presicce. state diagrams in uml: a formal semantics using graph transformations. in proceedings of icse 1998. pp. 55–72. ieee, 1998. [har87] d. harel. statecharts: a visual formalism for complex systems. science of computer programming 8:231–274, 1987. [hp09] a. habel, k.-h. pennemann. correctness of high-level transformation systems relative to nested conditions. mscs 19(2):245–296, 2009. [kgkk02] s. kuske, m. gogolla, r. kollmann, h.-j. kreowski. an integrated semantics for uml class, object and state diagrams based on graph transformation. in butler et al. (eds.), proceedings of ifm 2002. lncs 2335, pp. 11–28. springer, 2002. [kus01] s. kuske. a formal semantics of uml state machines based on structured graph transformation. in gogolla and kobryn (eds.), proceedings of uml 2001. lncs 2185, pp. 241–256. springer, 2001. [mp96] a. maggiolo-schettini, a. peron. a graph rewriting framework for statecharts semantics. in cuny et al. (eds.), graph grammars and their application to computer science. lncs 1073, pp. 107–121. springer, 1996. [omg09] omg. unified modeling language (omg uml), superstructure, version 2.2. 2009. [rach00] g. reggio, e. astesiano, c. choppy, h. hussmann. analysing uml active classes and associated state machines a lightweight formal approach. in maibaum (ed.), fundamental approaches to software engineering. proceedings of fase 2000. lncs 1783, pp. 127–146. springer, 2000. 23 / 24 volume 39 (2011) a visual interpreter semantics for statecharts based on amalgamation [roz97] g. rozenberg (ed.). handbook of graph grammars and computing by graph transformation, volume 1: foundations. world scientific, 1997. [tae96] g. taentzer. parallel and distributed graph transformation formal description and application to communication based systems. phd thesis, technische universität berlin, 1996. [tb94] g. taentzer, m. beyer. amalgamated graph transformations and their use for specifying agg an algebraic graph grammar system. in schneider and ehrig (eds.), graph transformations in computer science. lncs 776, pp. 380–394. springer, 1994. [var02] d. varró. a formal semantics of uml statecharts by model transition systems. in corradini et al. (eds.), proceedings of icgt 2002. lncs 2505, pp. 378–392. springer, 2002. gcm 2010 24 / 24 introduction and related work modeling of statecharts introduction to amalgamated graph transformation an interpreter semantics for statecharts application to the running example implementation conclusion and future work pvsio-web: a tool for rapid prototyping device user interfaces in pvs electronic communications of the easst volume 69 (2013) proceedings of the 5th international workshop on formal methods for interactive systems (fmis 2013) pvsio-web: a tool for rapid prototyping device user interfaces in pvs patrick oladimeji, paolo masci, paul curzon and harold thimbleby 8 pages guest editors: judy bowen, steve reeves managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst pvsio-web: a tool for rapid prototyping device user interfaces in pvs patrick oladimeji1, paolo masci2, paul curzon2 and harold thimbleby1 1 p.oladimeji, h.thimbleby@swansea.ac.uk, http://fitlab.eu/ future interaction technology lab, swansea university, wales 2 paolo.masci,paul.curzon@eecs.qmul.ac.uk queen mary university of london, united kingdom abstract: we present pvsio-web which extends the simulation component of the pvs proof system with functionalities for rapid prototyping device user interfaces. the tool presents itself as a classic image-editing environment with functionalities such as area selection and hyperlink creation, thus reducing the barriers that prevent non-experts in formal methods from using pvs. designers load a picture of the layout of the device user interface under development, specify interactive areas over the layout, and link them to a pvs specification. they can then explore the behaviour of the formal user interface specification through point-and-click interactions. the architecture of the tool is general, and can be used as the basis for extending other verification tools. a demonstration of the capabilities of pvsio-web is presented through an example based on a commercial medical device user interface. our ultimate aim is to promote and facilitate the use of formal verification tools when developing device user interfaces. keywords: prototyping tool; interactive devices; user interfaces; pvs. 1 introduction and motivation safety-critical systems must be verified against safety requirements before being marketed. this is required by law in many countries to reduce the risk of failures to be as low as reasonably practical. for interactive systems, the verification includes the analysis of user interface designs, with the aim of reducing software defects and use errors. the utility of formal methods to help in identifying issues in user interface designs has been demonstrated several times since the early 1980s, e.g., see the work of degani [deg04] and thimbleby [thi90, thi10] on state machines. to date, however, the use of formal methods for developing user interfaces has been largely neglected by manufacturers. this is mainly due to barriers (some perceived, some real) created by verification tools, which have front-ends that are inaccessible to engineers and domain experts. for instance, consider the state-of-the-art theorem proving system pvs [orr+96]. one component of pvs, pvsio [muñ03], provides a prototyping environment that allows one to explore the behaviour of a pvs specification. this is useful, e.g., for debugging purposes and for discussing the specification with engineers and 1 / 8 volume 69 (2013) mailto:p.oladimeji, h.thimbleby@swansea.ac.uk http://fitlab.eu/ mailto:paolo.masci,paul.curzon@eecs.qmul.ac.uk pvsio-web: a tool for rapid prototyping device user interfaces in pvs domain experts before verifying it in the pvs theorem prover. the core of pvsio is a translator that compiles pvs expressions into common lisp code. it presents itself as an interactive command prompt with a read-eval-print loop that allows developers to enter commands and execute pvs specifications on-demand. for instance, the behaviour of a function defined in a pvs specification can be executed within pvsio by writing the name of the function in the pvsio command prompt: pvsio evaluates the function and returns a result. however, pvsio is hard to use and apply when prototyping interactive systems: a list of nested commands must be provided for evaluating functions, and the results are displayed in textual format as a (possibly long) list of fields. a more natural way of exploring the behaviour of a user interface is by means of interactions with buttons and keys on a user interface layout that visually resembles the one under development. in this work, we develop a prototyping environment that enables this interaction style using pvsio. contribution. the main contribution of this paper is to present a novel graphical environment, pvsio-web [pvs], for rapid prototyping of device user interfaces in pvs [orr+96]. specifically, the tool extends the pvsio [muñ03] component of pvs with functionalities that allow designers to execute the formal specification of an interactive system by interacting with a picture that represents the layout of the system user interface. the designer creates interactive areas over the picture. interactions on the defined areas are translated into commands for pvsio, and the returned result is rendered on the same picture of the layout. the second contribution, in section 3, is that we demonstrate the capabilities of pvsio-web through an example where the layout of a commercial medical device user interface is prototyped with functionalities defined in a pvs specification. 2 pvsio-web pvsio-web extends the pvsio [muñ03] component of pvs [orr+96] with a graphical environment that allows rapid prototyping of device user interfaces based on formal pvs specifications. designers can load a picture of the layout of a user interface and define interactive areas over it: regions of the picture that should react to user clicks or presses, and visible text areas that should render information fed back to users such as displays. the behaviour of these interactive areas is defined in a pvs specification given by the designer. the designer can use point-and-click interactions on user interface buttons for exploring the user interface behaviour and visually observe the effect of the interactions in real-time. architecture. pvsio-web has a distributed architecture based on a lightweight client and a webserver (see figure 1). the client presents the graphical front-end of the tool as an interactive webpage within a web-browser. a web-server encapsulates the tool back-end. a process in the web-server is dedicated to pvsio for executing the pvs specification on-demand. other processes are executed on the web-server for additional functionalities, such as type-checking the pvs specification. the server and client may be run on the same computer or on separate computers. an illustration of the functionalities of the client front-end and server back-end of pvsio-web follows. the client front-end is shown in figure 3. it is entirely written in javascript, and provides a user interface (ui) builder and a simulator. the ui builder allows designers to load a picture proc. fmis 2013 2 / 8 eceasst figure 1: architecture of pvsio-web (e.g., sketch, rendered image, or photograph) of the user interface layout, and bind interactive areas of the layout to function calls in a pvs specification. two types of interactive areas can be defined: button areas, which are input elements whose behaviour is specified by functions in the pvs specification; display areas, which are output elements whose value is specified in the state of the user interface defined in the pvs specification. the pvs specification is visualised, edited and type-checked from the ui builder environment. the ui simulator allows designers to explore the behaviour of the user interface through point-and-click interactions with the defined interactive areas. user interactions with button areas are translated into commands specifying name and arguments of functions in the pvs specification. these functions will be executed on the web-server back-end through pvsio. replies returned from the web-server provide the result of the execution. they are parsed by the ui simulator using regular expressions. the value of state variables associated to display areas are extracted and rendered on the corresponding display areas defined on the user interface layout. more details about the capabilities of the client front-end are provided in section 3 while illustrating an example based on a commercial drug infusion pump. the server back-end is a web-server hosting processes executing pvs and pvsio on-demand: the former is used for type-checking the pvs specification of the device user interface; the latter is used for executing the same pvs specification according to the commands sent by the ui simulator of the client front-end. the server code is written entirely in javascript and runs in node.js1, which is an environment built on google’s v8 javascript engine shipped with the chrome web-browser. node.js allows developers to easily build fast and scalable network applications written in javascript. the execution model of the platform is event driven with asynchronous, non-blocking function calls. the platform provides a seamless interface to spawn processes and access their input, output and error streams through javascript programs. this mechanism is used in pvsio-web for creating a pvs and pvsio process for type-checking and executing the pvs specification on-demand. once initialised, the server back-end listens for connections from prospective clients. websockets2 are used for exchanging messages between the client front-end and the server back-end. websocket is a standardised protocol intended for use on the web to enable bidirectional low-latency communication between two endpoints over a tcp connection. the payload of exchanged messages is specified in the javascript object notation (json) format. the server side exposes a generic interface for communicating with a pvsio process using websockets. the client initiates a websocket connection with the server and can send messages to 1 http://nodejs.org 2 http://www.websocket.org 3 / 8 volume 69 (2013) http://nodejs.org http://www.websocket.org pvsio-web: a tool for rapid prototyping device user interfaces in pvs start or close a process on the server using the websocket connection. it can also send commands to be executed by a running process it started. the server sends responses from the process back to the client through the same websocket connection. 3 example: prototyping the data entry system of infusion pump user interfaces we now demonstrate the capabilities of pvsio-web through two examples based on medical infusion pumps. medical infusion pumps are used in healthcare to deliver drugs and nutrients to patients at controlled rates. clinicians enter infusion parameters in the infusion pump by interacting with buttons and keys on the device user interface. a broad class of data entry system typically used in the current generation of drug infusion pumps is the incremental [cce+11] data entry. this layout is gradually replacing number pads because it can help reduce the likelihood of undetected key slip errors — the attention of the user is mostly on the display rather than on the keys [uk 10]. a first validation of this hypothesis has been demonstrated recently within a lab experiment [otc11]. different variants exist of incremental number entry systems: they are currently not standardised, and different manufacturers can implement the data entry system in different ways. a layout used in several medical infusion pumps is based on chevron keys. that is users enter a number by incrementing or decrementing the displayed value with a minimum of two dedicated keys. pvsio-web is now used for prototyping the chevron keys of a commercial drug infusion pump. a picture of the layout of a commercial infusion pump [car12] with chevron keys is shown in figure 2. it is an exemplar of chevron keys user interface, where up and down arrows are used for incrementing and decrementing the value of numeric infusion parameters — typically, volume to be infused (vtbi), infusion rate and infusion duration. the device provides buttons for fast (double chevron keys) and slow (single chevron keys) value edit, and they support press & hold interaction styles. that is, when a chevron key is pressed and held down, the value being set is iteratively incremented (with the up keys) or decremented (with the down keys). the value of the infusion parameter being set is always shown on the left display section just above the chevron keys. for prototyping the device user interface described above, the designer performs the following steps in the ui builder of pvsio-web. a picture of the device user interface (e.g., a photograph of the infusion pump as shown in figure 3) is uploaded in the pvsio-web front-end, and the associated pvs specification defining the interactive behaviour of the user interface is typed in or loaded in the ui specification editor of pvsio-web (in this case, we use the pvs specification illustrated in [mro+11]). the designer then defines interactive areas over the loaded picture. for each interactive area: (1.) a rectangle that surrounds a desired area of the picture is selected by clicking and dragging the mouse pointer; (2.) the intended type of area (either button or display) is specified; (3a.) buttons areas are bound to functions defined in the pvs specification; interactions with these areas (e.g., button clicks) are translated into commands for the pvsio-web back-end; pvsio is thus used on the server back-end for executing those functions; (3b.) display areas are bound to terms in the pvs specification that model the state of visible elements on the user interface; regular expressions are used for extracting the value of these variables from proc. fmis 2013 4 / 8 eceasst figure 2: a picture of a commercial medical infusion pump with chevron keys. the messages returned by the pvsio-web back-end that encapsulate the result of expressions evaluated with pvsio. in the following, these steps are exemplified for the left display element and the fast up key of the user interface layout shown in figure 3. for the display element, the term in the pvs specification modelling this element is a field display of type real in a record type. in order to bind the display element to field display, the designer creates an area around the display element by clicking and dragging the mouse pointer. by doing so, a contextual menu for setting the binding options of the area is displayed by pvsio-web after the dragging ends: the area type is display in this case, the area identifier is display, and the value type is number (a pre-defined type template in pvsio-web). pvsioweb uses these parameters for generating a regular expression, which is shown at the bottom of the contextual menu (display left := [0-9.]+, in this case), for parsing messages returned by the pvsio-web back-end. in this case, pvsio-web will search for a field display in the message, extract the value (a real number in this case) of the field, and render the value in the display area. for the fast up key, an area is created around the button edges, and the following parameters are set through the contextual menu displayed by pvsio-web: the area type (button), the area identifier (up), and the interaction style (press & hold). given these parameters, pvsio-web binds press & hold interactions with this button to a function in the pvs specification. a naming convention and a pvs specification style is used to ease the automation of this binding procedure. for instance, for press & hold interactions, a pair of functions press x and release x (where x is the button identifier) are used in the pvs specification for modelling press & hold interactions — the press x function is iteratively executed while x is pressed, and the release x function is executed once only when the button is released. by default, the iterative execution of press x is performed every 250ms, as this reflects the typical response time of several device user interfaces. for the up button, therefore, the script will create a command for the pvsio-web back-end that triggers the iterative execution of function press up in pvsio while the button is pressed and held down, and of function release up when the button is released. the new state of 5 / 8 volume 69 (2013) pvsio-web: a tool for rapid prototyping device user interfaces in pvs figure 3: the graphical environment of pvsio-web. the user interface generated after any execution is returned to the pvsio-web front-end. the same procedure is used for associating the other keys to the corresponding functions in the pvs specification. the naming convention and the default values can be overridden by the designer. after defining interactive areas with the ui builder, the ui simulator of pvsio-web is used for exploring the behaviour of the device user interface. starting from an initial user interface state, which is set through a init function defined in the pvs specification, the designer can interact with button areas and observe changes in display areas. with the considered device user interface, the initial value shown in the display area is 0, and if the designer clicks once the up button then a new value is displayed in real time in the display area (in this case, it becomes 1). this new value is obtained by executing in sequence the press up and release up functions in the pvs specification. if the up button is pressed and held down, the value is iteratively incremented according to the pvs specification, and each new value is rendered on the display element in real time (every 250ms in this case). 4 related work and conclusion we have presented pvsio-web, a new graphical tool for rapid prototyping device user interfaces in pvs. pvsio-web extends pvsio with a graphical environment that allows designers to bind a picture of a device user interface to a pvs specification and explore the user interface behaviour through point-and-click interactions over the picture of the user interface. several verification tools include front-ends for animating specifications. for instance, uppaal [bll+96] and ivy [ch09] provides graphical user interfaces that render models specified in the respective specification languages as state machines. the user can interact with the state machine to explore the behaviours of the specification, e.g., by triggering state transitions. the functionalities provided by pvsio-web are significantly different from those provided by the above tools. pvsio-web renders the behaviour of a specification directly onto a realistic picture of the final product. this allows users to interact with the specification by pressing buttons on a realistic picture of the product, and view the effect of actions directly on the same picture of the proc. fmis 2013 6 / 8 eceasst product. this helps formal methods experts to illustrate verification results to domain experts, such as engineers and human factors experts, which may be not familiar with formal methods. other tools have been created to support users that are non-experts of formal methods. for instance, in [ss12], a tool is developed that can support programmers when writing software code for low-level data structure manipulation, such as insertion or deletion of elements in a list. in [bbc+12], a graphical front-end is developed to facilitate usage of formal tools for biologists that have no previous knowledge in programming or formal methods. pvsio-web has a similar aim, in that has the potential to open the functionalities of a complex verification such as pvs to non-experts of the system. differently from all the above works, pvsio-web is specifically designed to support prototyping of widget-based interactive device user interfaces. with pvsio-web, the pvs verification system can be used as-it-is, without any modification that might compromise its correctness. the client-server architecture of pvsio-web can be used as the basis to extend other verification tools that provide simulation functionalities through an interactive command prompt. we have demonstrated the capabilities of pvsio-web with an example based on a commercial medical infusion device. acknowledgements: funded as part of chi+med: multidisciplinary computerhuman interaction research for design and safe use of interactive medical devices project epsrc grant number ep/g059063/1. bibliography [bbc+12] d. benque, s. bourton, c. cockerton, b. cook, j. fisher, s. ishtiaq, n. piterman, a. taylor, v. m. bio model analyzer: visual tool for modeling and analysis of biological networks. in proceedings of the 24th international conference on computer aided verification. cav’12. springer-verlag, berlin, heidelberg, 2012. [bce+12] r. bloomfield, n. chozos, d. embrey, j. henderson, t. kelley, f. koornneef, a. pasquini, s. pozzi, m. sujan, g. cleland, i. habli, j. medhurst. using safety cases in industry and healthcare. 2012. [bll+96] j. bengtsson, k. larsen, f. larsson, p. pettersson, w. yi. uppaala tool suite for automatic verification of real-time systems. springer, 1996. [car12] carefusion. alaris gh syringe pump. 2012. http://www.carefusion.co.uk. [cce+11] a. cauchi, p. curzon, p. eslambolchilar, a. gimblett, h. huang, p. lee, y. li, p. masci, p. oladimeji, r. rukšėnas, h. thimbleby. towards dependable number entry for medical devices. in eics4med, the 1st international workshop on engineering interactive computing systems for medicine and health care. acm digital library, 2011. [ch09] j. c. campos, m. d. harrison. interaction engineering using the ivy tool. in proceedings of the acm sigchi symposium on engineering interactive computing systems. pp. 35–44. acm, 2009. 7 / 8 volume 69 (2013) http://www.carefusion.co.uk pvsio-web: a tool for rapid prototyping device user interfaces in pvs [deg04] a. degani. taming hal: designing interfaces beyond 2001. palgrave, 2004. [mro+11] p. masci, r. rukšėnas, p. oladimeji, a. cauchi, a. gimblett, y. li, p. curzon, h. thimbleby. on formalising interactive number entry on infusion pumps. eceasst 45, 2011. [mro+12] p. masci, r. rukšėnas, p. oladimeji, a. cauchi, a. gimblett, y. li, p. curzon, h. thimbleby. the benefits of formalising design guidelines: a case study on the predictability of drug infusion pumps. under review, 2012. draft available at http: //tinyurl.com/masci-qmpreprints. [muñ03] c. muñoz. rapid prototyping in pvs. technical report nia report no. 2003-03, nasa/cr-2003-212418, national institute of aerospace, 2003. [orr+96] s. owre, s. rajan, j. rushby, n. shankar, m. srivas. pvs: combining specification, proof checking, and model checking. in cav96. lncs 1102. springer berlin heidelberg, 1996. [otc11] p. oladimeji, h. thimbleby, a. cox. number entry interfaces and their effects on error detection. in interact’11. springer-verlag, berlin, heidelberg, 2011. http://dl.acm.org/citation.cfm?id=2042283.2042302 [pvs] pvsio-web. http://thehogfather.github.io/pvsio-web/. [ss12] r. singh, a. solar-lezama. spt: storyboard programming tool. in proceedings of the 24th international conference on computer aided verification. cav’12, pp. 738–743. springer-verlag, berlin, heidelberg, 2012. [thi90] h. thimbleby. user interface design. addison-wesley, 1990. [thi10] h. thimbleby. press on: principles of interaction programming. mit press, 2010. [uk 10] uk national patient safety agency. design for patient safety: a guide to the design of electronic infusion devices. 2010. proc. fmis 2013 8 / 8 http://tinyurl.com/masci-qmpreprints http://tinyurl.com/masci-qmpreprints http://dl.acm.org/citation.cfm?id=2042283.2042302 http://thehogfather.github.io/pvsio-web/ introduction and motivation pvsio-web example: prototyping the data entry system of infusion pump user interfaces related work and conclusion electronic communications of the easst volume 30 (2010) guest editors: claudia ermel, hartmut ehrig, fernando orejas, gabriele taentzer managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 international colloquium on graph and model transformation on the occasion of the 65th birthday of hartmut ehrig (gramot 2010) position statement: models in software and systems development bernd mahr 11 pages eceasst 2 / 11 volume 30 (2010) position statement: models in software and systems development1 bernd mahr mahr@cs.tu-berlin.de institut für telekommunikationssysteme technische universität berlin abstract: the development of software and systems is, by its very nature, highly depending on models. in the software and system’s design models play an important role, where they represent the constraining standards as well as the choices of ideas and perspectives applied in the systems modelling, implementation and technology. the general model of model-being, developed by the author, is briefly explained and is used to discuss model interconnections resulting from model compositions and metamodel applications. in this position statement it is claimed that the analysis of model interconnections, prerequisite to or underlying the software and systems design, should provide new insights into the designs architecture. keywords: software, design, model, model-being, model interconnections 1 introduction the choice of design in software and systems development is naturally constrained by mainly four factors: first, by the requirements and expectations on the properties and features of the intended systems future application and use, second, by the norms and standards to be met, third, by the quality and limitations of resources available for the intended systems modelling, implementation and technical realization, and fourth, by the reality of the social and technical environments, in which the intended system is embedded when being operated. however, the system’s future applications, its modelling, implementation, technical realization as well as its environments are at the time, before the system is being developed, not directly accessible. at that time these constraining factors can only be identified and addressed by means of prospective models. and it is not only a fact that these constraints in the development process are to be mediated by models, it is also the likeliness of change, which affects the execution of the development task: it is not unusual that expectations and requirements on a system’s 1 this paper builds on and repeats some of the content of bernd mahr: information science and the logic of models, journal of software and systems modelling (2009) 8, springer verlag 2009, p. 365383, (see also the german original: bernd mahr: die informatik und die logik der modelle, informatik spektrum, 32, 3, 2009, pp. 228 – 249). as a position statement it does not fully elaborate its concepts and assertions. though what is said here is largely based on year long experience in softwareand application development and on deep research on the question of modelling, the claims made do sometimes express expectations rather than experience. models in software and systems development proc. gramot 2010 3 / 11 application and use are being modified before the system is delivered; it is also common experience that resources for its modelling, implementation and technical realization do not stay stable while the system is being developed; and it is certain that the environments in which the system is being embedded, will not be in a constant state over time2 . all models involved in the task of development are therefore to some degree unpredictable in regard to their future adequacy and trustworthiness. and there is yet another difficulty in system’s development: when the system is being modelled and implemented, all matters of its functionality and design are to be expressed as features and properties of the system itself, which is to say that the models which capture requirements and expectations of the system’s application and use and of all the other constraining factors in the development task, have to be encoded as features and properties of the system. it would, however, be wrong to conclude from these observations, that the development of software and systems are impossible tasks. there are mainly two reasons why their development, despite of these difficulties, has a good chance of success: first, the fact that in practice systems behaviour is rarely judged on a predefined and completely rigorous basis. users usually accept to adapt their expectations, activities and patterns of use to what the system is able to do, at least to a certain degree. and second, more than 60 years of experience in theory and practice of software development have lead to techniques and tools, which enable architects and developers to cope with the consequences of mediation and change. in the widest sense, these techniques and tools concern means of coding, abstraction and coordination, all being based on models and modelling techniques. it is, however, surprising that we have little knowledge about the principal conditions for something to be a model and about the activities constituent for model use, namely the activities implied by modelling and model application. and we can hardly say what in general counts as a good model and what does not. these deficiencies may not be severe if the modelling takes place in a disciplined context with a high level of standardisation, but they are definitely present with the general notions of model and modelling, and are also found to affect modelling in the fields of information and conceptual modelling3 , and in the many endeavours of computer based modelling. having observed this, the question comes up of what benefit it might be to gain deeper knowledge about the notion of model in general, namely how the tasks of software and systems development can benefit from it. and one might also ask, if there is a chance at all to clear the general notion of model, which is widely assumed to be indefinable. to respond to the second question first, there is much more to know about models and modelling than there is known today. but to acquire this knowledge one has to give up some of the epistemological customs of explanation: when thinking about models one can no longer avoid to constructively treating their subject and context dependency; and in order to seek for an answer to the question of what is a model in ontology or in some formal theory, one has to rephrase this question as to what justifies the judgement that a given object is a model, and answer it in the 2 if application and use of a system makes a difference, which is what is intended by its provision, it will change its environment. 3 bernhard thalheim: entity relationship modeling – foundations of database technology, berlin und heidelberg: springer, 2000. eceasst 4 / 11 volume 30 (2010) realm of logic; and finally one has to focus on the structure of contextual relationships characteristic for models rather than to try to find the kind of similarity which relates an original with its model4. to respond to the first question, it has first of all to be observed that it is generally impossible to restrict the notion of model to only certain familiar types or to ask for computer science owned notions of model and modelling. software systems are applied in almost any field of science, engineering and daily life; the design of software, from an overall perspective, has therefore to deal with the modelling cultures and disciplines in all these fields. as a consequence, if software design is not wanted to be split into separate disciplines, we cannot avoid to either know about the different conceptions of model and modelling in these fields, or to develop a general conception of universal applicability. it is the authors position in this statement that a model of model-being can be conceptualized, which not only covers all known conceptions of models as particular fragments or specializations of the general conception, but which should at the same time be useful as a sensitive tool for analysis and design, not only in the case of modelling in general, but also in individual situations of model use.5 it is the expectation that such an analytical tool should also yield deeper insights into the structure of model interrelations on which software is being built. and from these insights, it is expected, it should be possible to derive new techniques and tools for the tasks of software and systems development. 2 the epistemic pattern of model-being the question of what justifies a judgement that a given object is a model, presupposes that the model-being of this object is the conclusion of a judgement for which there are grounds. if it is possible to phrase general conditions which are necessary and sufficient for such a judgement to be acceptable, one might take these conditions as an argument form, which in individual cases if properly instantiated justifies the judgement of model-being. the argument form of model-being is then seen to exhibit the logic of models in general, while its instantiations determine the logic of individual models. since judgements are actions undertaken by subjects, the model-being of an individual object is not a property of the object in itself but is relativised by the subject dependency of the judgement which asserts it. and since the argument form of model-being yields necessary and sufficient conditions for acceptability and not conditions for defined or objective truth, the notion of model, conceptualized in terms of this argument form, is relativised by the subject dependency of accepting. the conditions implied by the argument form for model-being cannot be based on inherent properties of the object judged to being a model. this is obvious from the fact that any object can be acceptably judged to being a model if it is only positioned into a proper context, for 4 herbert stachowiak: allgemeine modelltheorie, wien / new york: springer, 1973. 5 the model of model-being, for which this strong claim is made, has been developed in the last decade in interdisciplinary studies and projects by the author and his co-workers. see for example bernd mahr: modellieren. beobachtungen und gedanken zur geschichte des modellbegriffs, in: sybille krämer, horst bredekamp (ed.): bild-schrift-zahl, münchen: fink, 2004, p. 59-86; bernd mahr: ein modell des modellseins. ein beitrag zur aufklärung des modellbegriffs, in ulrich dirks, eberhard knobloch (ed.): modelle, frankfurt am main: peter lang, 2008, p. 187-218; reinhard wendler: die rolle der modelle in werkund erkenntnisprozessen, dissertation am kunstgeschichtlichen seminar der philosophischen fakultät iii der humboldt-universität zu berlin, juli 2008; and (mahr, 2009). models in software and systems development proc. gramot 2010 5 / 11 example into a context of production in which it takes the role of a prototype. and because there is no object which is a model by necessity, since it is always possible to position an object into a context in which there is no meaning of models at all, one has to conclude that the conditions implied by the argument form of model-being are context dependent. if an object is judged to being a model, it is necessarily conceived of as a model by the judging subject. assuming in general that to conceive of an object means nothing else but to identify the object’s involvement in context relationships6, it seems justified to defining the argument form for model-being as to being a complex of context relationship types. the pattern of these relationship types is then taken to characterise the situations, in which an object has the role of a model. this diagram depicts this pattern7 . χ μ g ba forof model is / as cargo transports the diagram defines the argument form of model-being and is composed of epistemic object and object relationship types. it is therefore also called the epistemic pattern of model-being. the term epistemic is used here to indicate that objects and relationships of an instantiated argument form have existence only as intentional objects, i.e. as being conceived of by the judging subject. objects of type a, g and b may be conceived of to be concrete or abstract, but the objects of type μ and χ as well as all relationships are necessarily abstract, i.e. their existence is independent from space and time. the intended meaning of the epistemic pattern of model-being, which guides the instantiation of its object and relationship types, is the following: 6 this assumption forms the basis of the model of conception developed by the author. the first thoughts on this model have been described in bernd mahr: gegenstand und kontext – eine theorie der auffassung, in: k. eyferth, b. mahr, r. posner, f. wysotzki (ed.): prinzipien der kontextualisierung, kit report 141, tu berlin, 1997, p. 101 119. a set-theoretical study of the model is given tina wieczorek: on foundational frames for formal modelling – sets, epsilon-sets and a model of conception, aachen: shaker, 2009. for a philosophical justification of the model see bernd mahr: intentionality and modelling of conception, 2009, in: sebastian bab, klaus robering (ed.): judgements and propositions – logical, linguistic and cognitive issues, berlin: logos, 2010, pp 61 – 87. 7 for justification of this pattern see (mahr, 2009) as well as (mahr, 2008) and (mahr, 2004). eceasst 6 / 11 volume 30 (2010) 1. in the context of this pattern an object of type g is called model object and an object of type μ is called model. an object of type g is not by its identity a model. it has to be distinguished from the model as which it is seen, because different model objects can represent the same model. the fact that an object is seen as a model assigns it the role of a model object and determines the relationship between itself and the model it represents. instance: a model, for example depicted as the above class diagram8 model object, can have different other diagrammatic representations as model , which is its objects. 2. a model is always a model of something, the type of which is here denoted by a. and the fact that a model is seen to be a model of something, determines the relationship between the model and that of which it is a model. instance is a model of the university’s library system. : the model which has the above mentioned class diagram as its model object, 3. composing the relationships as-a-model and model-of yields the fact that the model object is seen to be a model of a. this fact determines the relationship between a model object and that of which it is a model. instance system. : the above mentioned class diagram is a model of the university’s library 8 http://help.eclipse.org/galileo/topic/org.eclipse.ocl.doc/references/examples/extlibrarymode, october 26, 2010. http://help.eclipse.org/galileo/topic/org.eclipse.ocl.doc/references/examples/extlibrarymode� models in software and systems development proc. gramot 2010 7 / 11 4. a model is always a model for something, the type of which is here denoted by b. and the fact that a model is seen to be a model for something, determines the relationship between the model and that for which it is a model. instance is a model for the object architecture of the planned implementation of the : the model which has the above depicted class diagram as its model object, university’s e-library system. 5. composing the relationships as-a-model and model-for yields the fact that the model object is seen to be a model for something. instance of the university’s e-library system. : the above depicted class diagram is a model for the planned implementation 6. in the context of this pattern an object of type χ is called cargo. for a model to make sense there must be something, named its cargo, which carries over from that of which a model object is a model, to that, for which it is a model. the cargo of a model is seen to be transported by the model object from that of which it is a model to that for which it is a model. this fact determines the three relationships between objects of type g and χ, a and χ, and χ and b. instance component relationships and component owned operations, which are : the above depicted class diagram transports a structure of components, identified in the university’s library system, to the implementation of the university’s e-library system. χ μ g φ(g) ψ(y) yψ(g)φ(x)x indind dedded transtrans ba forof model is / as cargo transports χ χ looking more carefully at situations of model-being, it becomes apparent that the relationship types between a and g and between g and b show the same sequential structure. in combination they are derived from the following sequence of action types (also called action sequence of modelling): 1. an observation on an initial object of type x, resulting observed facts of type φ(x), 2. a transformation transforming the facts of type φ(x) to requirements of type ψ(g) imposed on a model object of type g, eceasst 8 / 11 volume 30 (2010) 3. a realization of the requirements of type ψ(g) by a model object of type g, 4. an observation on the model object, resulting observed facts of type φ(g), 5. a transformation transforming facts of type φ(g) to requirements of type ψ(y) on a terminal object of type y, 6. a realization of the requirements of type ψ(y) by the terminal object of type y. an object of type a may now be of type x, φ(x), or ψ(g), and an object of type b may now be of type φ(g), ψ(y), or y. we can then speak of a model of an object, of an observation, or of requirements, and accordingly of a model for an object, for requirements or for an observation. coming back to the example of a university library system, the relationship between the model object (depicted as the class diagram above) and the object of type a (the existing library system), of which the diagram represents the model, can be explained as follows: it is derived from some kind of systems analysis in which the existing library system (instantiating the object of type x) has been studied (observation) in respect to what matters in view of the model to be created. this analysis results in the identification of relevant types of entities, relationships, attributes and actions (observed facts). these facts are then read (transformation) as items to be referred to (requirements) in the model object to be created. the class diagram (model object) is then developed to show these items (realization). the relationship between the class diagram and the model object and the university’s e-library system is similarly structured, in the sense that it also results from a sequence of observation, transformation and realization. the only differences are that the object on which the observation is made, is the model object and that the terminal object of type y may, at the time when the judgement of model-being is made, be only a vision and not yet exist in reality. if the latter is the case, the sequence of observation, transformation and realization is only a thought. but if this thought was not justified to possibly be reality, it was difficult to argue that the class diagram was a model at all. it would then rather be an image. in any real circumstance in which a compliant judgement of model-being is made, the epistemic pattern of model-being is instantiated by the judging subject. no matter if the judging subject9 refers in his instantiation to existing things in reality or only to thoughts about a possible reality, it identifies objects which instantiate the types x, φ(x), ψ(g), φ(g), ψ(y), and y, and it identifies object relationships which result from the two observations, say α and β, the two transformations, say σ and τ, and the two realizations, say π and ρ10 9 the judging subject may be a human individual, but it may also be a group of individuals, a community or, even more abstract, a culture. on the other hand, a judging subject may also be a machine or a mathematical definition. generally speaking, the judging subject is something by the authority of which the judgement in question is affirmed. , thereby 10 these identifications need not necessarily be conscious. they constitute part of the context in which the model object takes its role as a model. the objects and object relationships identified also need not to have existence independent from the judging subject, as they may just be thought of or generated in the moment of judgement. their identification is assumed to be valid as long as the judgement is valid in the subject’s eye. examples show that in practice this may be a fragment of a second or, in the other extreme, if the subject is not an individual, last for centuries, or even longer. models in software and systems development proc. gramot 2010 9 / 11 producing a sequence of actions (which is to be distinguished from the presupposed sequence of action types): x – α – φ(x) – σ – ψ(g) – π – g – β – φ(g) – τ – ψ(y) – ρ – y the judgement of model-being is then acceptable, if this sequence of actions is an adequate view on a defined or an identified situation of model-being. assuming that all objects with object types in this sequence are being replaced by their logical theories11 , one observes that observations are deductions, and that realizations are inductions. a model object is therefore at the same time the result of an induction and the source of a deduction. this dual nature of model objects can be seen as one of the most typical characteristics of objects which are being conceived of as models. the epistemic pattern of model being is not a formal definition of what a model is. such a definition would make sense in certain modelling disciplines, like the disciplines of set formation or graphs, but due to the mathematical nature of its constituents it would hardly meet the needs of practical model use in most of the sciences, engineering and daily life in a direct way. if a formal definition was to be given it would have to follow the structure provided by the pattern, and would have to define object and object relationship types as well as their possible instantiations as mathematical entities in some foundational theory, like category theory or the theory of sets. a mathematical definition of models would replace the judging subject by written formal conditions and would have to explicitly determine the criteria for relationships to be observations, transformations and realizations. namely for transformations these criteria would either be restrictive, like the criteria for a function to be a homomorphism12 or the criteria for a relationship to encode similarity, or they would be very general and therefore be weak in their expressiveness and determination. but the question of what the epistemic pattern conceptually is, if it is not a definition, can nevertheless clearly be answered: it is a model itself, i.e. it is an object which is to be judged as something by using the same argument form that is used for other judgements of model-being.13 its epistemological foundation is therefore not different to that of a mathematical definition which, to be strict, is also to be based on a (mathematical) definition of what a definition is. 3 complexes of interconnected models anything constructed can be questioned for what it is, how it was constructed, and by what means. in the case of software, the question ‘what’ asks for the systems architecture, its functionality and its technical realization; the question ‘by what means’ asks for the techniques and tools applied in its modelling, implementation and installation; and the question ‘how’ 11 the theory of an object is the set of all sentences which are true of this object. a theory is therefore language dependent. for reasons of simplicity one might assume that the choice of this language is determined as part of the subject’s judgement and also that it is the same for all objects involved. 12 (stachowiak, 1973), p. 140 – 159. 13 justification for the epistemic pattern of model-being as to being a model itself can indeed be given by using the epistemic pattern of model-being as an argument form. evidence for this is provided in the articles (mahr, 2004), (mahr, 2008), (mahr, 2009) and in other texts cited there. eceasst 10 / 11 volume 30 (2010) asks for the concepts and models underlying its design. the distinction between the last two questions, however, is not exclusive, since also models are tools, and tools, like formalisms and languages, are representations of descriptive models. as a clarification it is therefore assumed that the question ‘how’ is here intended to ask for the conceptual basis on which the system was built as a solution and for the ideas and perspectives taken when this solution was found. choices of ideas and perspectives are choices of models. so to ask for ideas and perspectives is to ask for the models which have been applied in the systems modelling, implementation and use of technology. for example, access to a set of stored data can be implemented as an array, a list, a record, a stack, a tree, or the like; a system which integrates patient data distributed in a hospital and makes these data available in a hospital network to all having the right to their access, can be implemented as an information system, a communication system, an open distributed system, a service, an agent network, a peer to peer system or a cloud; and a component in a component based system can be realized as an object, a module, or a service. this is to say that prerequisite to or underlying any existing software and system is a complex of interconnected models which conceptualize the ideas and perspectives put together and combined to determine the software or systems design. in their relation to the design which itself is a model, these models are metamodels of the implemented software or system. generally, a judgement of model-being is never isolated. it is always embedded into a network of intentional relations which determine its meaning14 . examples show that the contextual environment of a model object is typically not only the complex of objects and object relationships, which the pattern of its model-being indicates, but that this environment also includes other models which are interconnected with the model at hand in specific ways. there are at least two elementary types of model interconnections, which can be distinguished: model compositions and metamodel applications. model compositions capture situations in which, for example, the initial object of a modelling action sequence is itself a model object, or in which a terminal object is the initial object of another sequence, or a model object is related to more than one initial object, observation or requirement, and the like. if the above depicted class diagram, for example, is not produced in a single step, but in a sequence of steps with intermediary results, like in model driven architecture (mda), the situation of modelling is better described as a model composition. and the idea of model composition also applies if one wants to capture a situation in which the class diagram is not only representing a model of the university’s existing library system alone but also includes concepts from other more innovative such systems. metamodel applications capture situations in which items in an action sequence, like an observation or the model object itself are constrained by other models in the sense that the constrained items result from an application of these other models. in the above sketched modelling of the library system this is the case with the use of uml as description formalism. uml constraints the model object of the library system by its concepts and expressiveness. 14 john r. searle: intentionality – an essay in the philosophy of mind, cambridge: cambridge university press, 2004, p. 20 – 21 and 26. models in software and systems development proc. gramot 2010 11 / 11 and if some automatic programming tool is applied, which takes the class diagram as its input, this tool plays the role of a metamodel for the sequence of observation, transformation and realization in the relationship between the class diagram and the implemented e-library system. referring to the action sequence of modelling, which was introduced above, i.e. to x – α – φ(x) – σ – ψ(g) – π – g – β – φ(g) – τ – ψ(y) – ρ – y and using some self explaining notational conventions, the following examples abstractly denote such situations of model compositions and metamodel applications: x–α–φ(x)–σ–ψ(g)–π–g–β–φ(g)–τ–ψ(y)–ρ–y–α’–φ(y)–σ’–ψ(z)–π’–z depicts the situation of a terminal object which is a model object itself, {(xi–αi–φ(xi)–σi–ψ(g)i–πi) | i є i }–g–β–φ(g)–τ–ψ(y)–ρ–y depicts the situation in which a model object g is a model having a set of initial objects x–α–φ(x)–σ–ψ(g)–π–g–[x’–α’–φ(x’)–σ’–ψ(g’)–π’–g’–β’–φ(g’)–τ’–ψ(β)–ρ’–β]–φ(g)–τ–ψ(y)–ρ–y depicts the situation in which the observation β on the model object g is obtained by applying a metamodel with model object g’. the complex of interconnected models, which conceptualizes the ideas and perspectives taken, namely by employing model compositions and metamodel applications, and which determines the design of a given software or system, may be seen as to being the software or system’s model architecture. frameworks, like security frameworks or specification frameworks, can then be identified as prescriptions of model architectures. they prescribe which metamodels are to be used in a modelling action sequence and how models are to be composed. by using the sequence of action types in the pattern of model-being it should not be difficult to build a formal setting for model compositions, which allows to specify particular model architectures and to define types of complexes of interconnected models in a systematic way. 1 introduction 2 the epistemic pattern of model-being 3 complexes of interconnected models analyzing gerrit code review parameters with bicho electronic communications of the easst volume 65 (2014) proceedings of the international workshop on software quality and maintainability (sqm 2014) analyzing gerrit code review parameters with bicho jesus m. gonzalez-barahona*, daniel izquierdo-cortazar†, gregorio robles*, alvaro del castillo† 12 pages guest editors: lodewijk bergmans, tom mens, steven raemaekers managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst analyzing gerrit code review parameters with bicho jesus m. gonzalez-barahona*, daniel izquierdo-cortazar†, gregorio robles*, alvaro del castillo† * gsyc/libresoft, escuela tecnica superior de ingenieria de telecomunicacion, universidad rey juan carlos (madrid, spain) † bitergia (madrid, spain) abstract: code review is becoming a common practice in large scale software development projects. in the case of free, open source software projects, many of them are selecting gerrit as the system to support the code review process. therefore, the analysis of the information produced by gerrit allows for the detailed tracking of the code review process in those projects. in this paper, we present an approach to retrieve and analyze that information based on extending bicho, a tool designed to retrieve information from issue tracking systems. the details of the retrieval process, the model used to map code review abstractions to issue tracking abstractions, and the structure of the retrieved information are described in detail. in addition, some results of using this approach in a real world scenario, the openstack gerrit code review system, are presented. keywords: code review; software maintenance; software development; 1 introduction code review is an accepted practice to improve the quality of software [bb01]. it contributes to the quality of the code, by detecting defects before they enter the production code base [ml09, mbr13], and checks the adherence of proposed changes to the specific policies and general architecture of the project. but it also introduces extra work for experienced developers [hky+13], and extra delays in time-to-deploy, which is an important metric for continuous deployment projects. tracking the performance, timing, people involved and other parameters of code review becomes fundamental to detect bottlenecks, need of resources, or just to detect troublesome trends. many large, free, open source software (floss) projects are quickly adopting peer code review as a part of their development policies [rgs08]. and many of them are using gerrit1 as the system to support the review process. in those projects, the gerrit repository hosts all the information needed to track code review. gerrit itself provides both a web interface and an api to select reviews according to different criteria, and interact with them. the data handled by gerrit can be massive. for example, for havana, the latest stable release of openstack, more than 21,000 code review processes were started over a period of 6 months, about 115 per day. for each of them, all the changes in state until the review were accepted or declined are recorded, usually after several iterations between several reviewers and the author. this wealth of information can be used to track in detail the parameters that characterize the review process, and to understand how it is performing. 1 http://code.google.com/p/gerrit/ 1 / 12 volume 65 (2014) http://code.google.com/p/gerrit/ analyzing gerrit code review parameters with bicho code review support systems such as gerrit can be understood as specialized issue tracking management systems. each code review process can be modeled as a ticket (issue), moving through different states as one or more code patchsets are proposed, reviewed, approved, rejected, resubmitted, etc. in the work described in this paper, we take advantage of this fact to extend a tool designed to retrieve information from issue tracking systems to also retrieve information from gerrit. the extended tool is bicho, a part of the metricsgrimoire toolset2. bicho has a modular architecture, with several backends to retrieve information from the issue tracking systems most popular in floss projects, and a common frontend that produces an sql database with the retrieved data, in a format which is partially common for all of those systems. a gerrit backend has been built, which produces the same format for code reviews, modeling them as tickets, thus reusing a large part of the code. to test the usefulness of the approach, we have used this extended version of bicho to analyze the gerrit system of the openstack project, designing queries on the produced sql data to obtain some of the the most relevant parameters of the openstack review process. the structure of the rest of this paper is as follows. the next section describes the common workflow with gerrit. section 3 presents the bicho tool and its database schema, which will be important to understand how information in code review systems can be mapped to it. after that, section 4 shows the details of how code review can be modeled as an issue tracking system. section 5 presents how this was done in the case of gerrit, so that bicho could be extended to support it. the paper ends with some examples of the use of the data retrieved from the openstack gerrit repository in section 6, and some conclusions and further work in section 7. 2 code review with gerrit code review typically involves a developer submitting a proposed change to the source code of the project, and one or more developers reviewing that change. in the case of gerrit, the change comes in the form of a “patchset”, a set of patches to files in the source code repository. reviewers may accept the patchset as such, or ask for a new, enhanced patchset addressing their comments, in an iterative process. if the patch is accepted, it is later automatically merged with the development branch, becoming a part of the code base. if it is not accepted as such, usually a new patchset is required. if no new patchset is provided during a certain period, usually the code review is removed from the active queue, and is no longer considered. when a new patchset is submitted in the context of an existing code review, it is again reviewed with the same possible outcomes, until it is finally approved or the period for submitting a new patchset ends without submission. in some projects, there is a special kind of reviewers, core reviewers, who have the exclusive right to accept changes to the code base. in this case, only when they signal their acceptance, the code review is finally accepted. there are several variations of how gerrit can be used for code review. in our case, we will focus on the practices of the openstack project, since it will be used in the examples provided later. in this case, the review process is divided into three steps: verification of the patchset, code 2 http://metricsgrimoire.github.io proc. sqm 2014 2 / 12 http://metricsgrimoire.github.io eceasst review and approval of the change. the verification of the patchset is intended for automatic tools to check that it compiles, complies with coding style, etc. if the verification step fails, the code review gets a -1, meaning that the developer should submit a new patchset fixing the detected errors. when the verification step is passed, the review step starts. during it, any developer can comment or propose improvements to the patchset. they can also vote on the patchset with +1 (should pass as such), 0 (some concerns, but not blocking acceptance), or -1 (a new patchset should be submitted). core reviewers vote in a similar way, but using -2 or +2 for expressing their status. in openstack, a patchset has to be accepted by a core reviewer, thus getting a +2, to be considered for approval. approval is the end of this step: a core developer marks the patchset as such, and it moves to the last step. at any moment, a new patchset can be submitted, effectively moving the process back to the verification step. the third step starts when a core reviewer marks the patchset as approved. this triggers another check by automatic tools, similar to the verification step, to ensure the code is ready for merging in the code base. if this step fails, again a new patchset has to be submitted, and the process comes back to the verification step. otherwise, it is finally merged in the main development branch, and the process ends. 3 the bicho database schema bicho is a tool to retrieve information from issue tracking systems, and store it in an sql database with a structure suitable for queries oriented to analyze its main parameters [rgih11]. it currently supports bugzilla, jira, and the issue tracking systems of some forges (launchpad, allura, github, and redmine). it uses the api provided by these systems, or html scrapping from the web pages they provide, or a combination of both, to obtain information about all changes to all tickets. the code in charge of dealing with each specific issue tracking system is the bicho backend, and in fact there is one backend per supported system. once bicho has completed its job, any analysis can be performed just by querying the database it produces. each of the supported issue tracking systems has a different model of what a ticket is, and how it is changed. however, all of them share a common model. to accommodate at the same time what is common to all of them, and what is different, bicho has a set of core tables, used by all the backends, and extended tables, particular to each of them. a simplified version of the database schema for the core tables shared by all the backends is shown in figure 1, with the three main tables: • issues: for each ticket, time when it was opened, opener, summary, description, current status, priority and assigned developer. • changes: all modifications to fields in tickets (priority, description, resolution status, etc). • people: list of persons that at some point participated in the ticketing process. in addition, there are two main extended tables, particular for each backend: • issues extension: modifications to fields that are not in the issues table, but are relevant for the specific backend. 3 / 12 volume 65 (2014) analyzing gerrit code review parameters with bicho figure 1: simplified database schema of the bicho tool • issues log: historic status of each ticket over time. it is obtained once the retrieval process is finished, based on the contents of the issues, changes and issues extension tables. this table facilitates the analysis of the history of the tickets, and the snapshots at points in time. 4 modeling code review as changes to tickets the information needed to follow a code review process can be modeled as changes to annotations in a ticket, similar to how tickets evolve in an issue tracking system. in fact, there are cases where projects use a real issue tracking system to assist the review process. one prominent example is the webkit project which uses annotations in tickets in bugzilla [gimr13], or github, where a code review can be implemented using the pull request functionality, which is supported by the issue tracking system with tickets tagged as pull requests. in the case of gerrit, modeling with tickets can be as follows: • each review code process (change) is modeled as a ticket, with its unique identifier being the change identifier. • all information needed to track what happens during the code review process is modeled as changes to fields in the ticket. • the relevant fields are: proc. sqm 2014 4 / 12 eceasst – submitted (subm). submission of a new patchset: patchset identifier. increments by one the patchset identifier (first patchset is 1). – verify (vrif). result of a verification step: +1 (passed) or -1 (not passed). – review (crvw). vote during the code review step: an integer between -2 and +2. – approve (aprv): +1 (approved for merging). – abandoned (abdn): +1 (marked as abandoned). • for each change to a field, some extra data will be collected: the current patchset, the time of the change to the field (time), and who issued the change (submitted by). these fields are very similar to those used by, for example, bugzilla. some exploration shows that they work the same way as in issue tracking systems: each time a change is produced to a ticket, the change is recorded along with information about who issued the change and when this was done. the only major difference is the existence of the patchset number, which can be considered as a property of a ticket. therefore, this information can be retrieved from a gerrit system, and be stored in a very similar way to how it would be stored in a database for an issue tracking system. by querying that database, the main parameters of the code review process could be calculated. some examples: • for any review and patchset pair, the period from a change from subm (first submission of a patchset) to the first change to crvw will be its time-to-attention (time until first review is obtained). • the number of unique people changing crvw during a certain period will be the number of code reviewers. • the number of tickets opened before a certain date, but with no change to aprv or abdn before that date, is the backlog of review processes still open at that moment. 5 extending bicho to support gerrit to show in practice how code review abstractions can be mapped to issue tracking system abstractions, a bicho backend for gerrit was designed and developed. using the gerrit api all the needed data is retrieved. following the model described in the previous section, that data is fed into the bicho database as follows: • for each change (code review process), a new entry in the issues table is opened, with the change as ticket identifier. • for each change, patchsets are identified, and recorded in the changes table using an identifier for each of them. • for each patchset, the review process history is modeled as entries in the changes table for the intended fields (subm, vrif, crvm, aprv, abdn), each of them tagged with the corresponding patchset identifier. 5 / 12 volume 65 (2014) analyzing gerrit code review parameters with bicho files lines of code bicho (included all backend) 27 6,621 bicho backends (9 backends) 12 4,104 gerrit backend (gerrit.py) 1 231 table 1: number of files and lines of code (as analyzed by the cloc tool) for bicho, bicho backends, and the gerrit backend for it. all code is in python. • an issues log table, built from the previous ones. • people and other tables are built with data obtained for each event in the review process. the abstraction which was more difficult to map to the bicho model was the patchset. unfortunately, we could not find an abstraction in an issue tracking system capable of capturing the idea of a patchset. fortunately, an unused field (for the case of gerrit) in the changes table could be used to store this patchset identifier. in the future, probably this should be implemented as an extension to the changes table, specific to the gerrit backend. the extension of bicho to support gerrit represented a relatively small quantity of work, as can be shown in table 1. thanks to the use of the bicho frontend, and the already available common facilities provided by the program, code to retrieve data from gerrit consists of a mere 231 lines of python code. once the backend was complete, we could test it by running queries similar to those for issue tracking systems (such as time to reach certain states, or people involved in tickets/changes). the experience has shown that the queries are similar, and a lot of the expertise in mining databases with issue tracking information can be used to mine code reviews. in addition, queries specific to code review systems (such as number of patchsets per change, or time waiting for review) were devised, and tested. the next section shows some examples of all these analyses. 6 examples of analyses of the information to illustrate how the bicho database with the gerrit backend can be used to analyze code review practices, this section shows the details of some analyses: number of people asking for reviews and reviewing, and oldest reviews still open. they have been performed on the gerrit data retrieved by bicho from the openstack project as of november 21st 2013. 6.1 number of people involved in reviews the size of the community involved in the code review process, and how many of them act as change proposers and as reviewers are important parameters to determine how large the development community is, and what roles developers are assuming in the review process. the number of people proposing code changes each month can be obtained from the issues table, in which the submitted_by field is the identifier for the person proposing the change mapped to the ticket. the (slightly simplified) sql code is: proc. sqm 2014 6 / 12 eceasst 0 2 0 0 5 0 0 2011−7 2012−2 2012−9 2013−4 2013−11 figure 2: number of change proposers (black), reviewers (red) and core reviewers (blue) per month in the openstack gerrit system. studied period: from july 2011 to november 2013. select year(changed_on), month(changed_on), count(distinct(submitted_by)) as submitters from issues group by year(submitted_on), month(submitted_on); a similar query (also slightly simplified) can be used to get the number of people reviewing patchsets each month, using information from the changes table. now, changes to the crvw field, which corresponds to votes during the review step, are tracked: select year(changed_on), month(changed_on), count(distinct(changed_by)) as reviewers from changes where field=’crvw’ group by year(changed_on), month(changed_on); figure 2 plots the evolution of those two parameters over time, showing how the number of people involved in the review process is increasing quickly, but still keeping balanced. this is typical of a true peer review process where everyone ends up as change proposer and reviewer. 7 / 12 volume 65 (2014) analyzing gerrit code review parameters with bicho we have also plotted core reviewers, which in openstack are those who can finally accept or reject a patchset. this is a smaller group of people, with a different evolution. it can be seen how their number grew proportionally to reviewers during a large part of the history of the project, but during the last months it is no longer growing that way. this could cause an increasing workload on those most experienced developers, signaling that probably the project should find a way of increasing the number of these type of developers. 6.2 top oldest reviews in gerrit still open to detect problems and bottlenecks, detecting which changes are staying longer in the review process is of interest. for getting this information, data in the issues and changes tables can be crossed to find the oldest changes among those still not approved or abandoned. we therefore can use the following query: select issues.issue as review, issues.summary as summary, timestampdiff (hour, times.min_time, times.max_time) as opened from (subquery) times, issues where times.issue_id = issues.id order by opened desc limit 10; with subquery being: select changes.issue_id as issue_id, min(changes.changed_on) as min_time, max(changes.changed_on) as max_time from changes, issues where changes.issue_id = issues.id and (issues.status=’new’ or issues.status=’workinprogress’) group by changes.issue_id for example, on november 21st 2013 the oldest change still open has the identifier 25,8823. table 2 shows the ten oldest change proposals that are still open, and for how long the have been open. 6.3 time to close a review the time to close a change is important from a management point of view. this time is defined as the period since a change is opened in gerrit, to the moment one of the patchsets proposed 3 https://review.openstack.org/#/c/25882/ proc. sqm 2014 8 / 12 https://review.openstack.org/#/c/25882/ eceasst change summary days open 25882 add listing tested apis 225 31068 sync common db and db.sqlalchemy code from oslo 173 33236 run db api tests on a given db backend 151 33473 add ssl certificate verification by default 148 30755 the use of the class variables 148 34291 api extension to list supported scheduler hints 146 34519 add api schema for v3 keypairs 145 36207 use common oslo database session 134 36291 added neutron incompatibility note for simple ip management 133 36197 added tab showing all servers assigned to a hypervisor 132 table 2: top 10 oldest changes still open on november 21st 2013 in the openstack gerrit system. change column shows the gerrit identifier for the change, time open is measured in complete days. in it is finally approved and merged in the development branch, and the change is considered to be done. the study of the evolution of this parameter helps to understand what can be expected when submitting a new change proposal, how reactive the project is to these proposals, and how long it is taking to review the code, once it has been written and proposed as a new change. in this case example, we have considered separately those changes that get merged into the code base, and those that are abandoned. the query for obtaining the times for merged changes is shown below. the one for abandoned changes is almost the same, with abandoned instead of merged in the subquery. select timestampdiff (hour, times.min_time, times.max_time) as opened from (subquery) times, issues where times.issue_id = issues.id with subquery being: select changes.issue_id as issue_id, min(changes.changed_on) as min_time, max(changes.changed_on) as max_time from changes, issues where changes.issue_id = issues.id and issues.status = ’merged’ group by changes.issue_id to understand the query, it is important to notice that the issues table keeps the status field, which is initialized as new, and can later be workinprogress (both stated imply that the 9 / 12 volume 65 (2014) analyzing gerrit code review parameters with bicho type min 1st qu. median mean 3rd qu. max merged 0 0 17 97.13 95 7,161 abandoned 0 0 11 135.7 116.2 7,322 table 3: basic statistics of the distribution of the time to close (merge or abandon) changes. time is in integer hours (but means or medians can be fractional because divisions are implied). mean is not very representative due to the skewness of the distribution. 0 2 4 6 8 0 .0 0 0 .0 5 0 .1 0 0 .1 5 figure 3: distribution of time to close for merged (black) and abandoned (red) changes. time, in x axis, is in natural logarithm scale (unit is integer hours). review process did not finish yet), merged (was merged into the code base) or abandoned (was marked as such). as shown in table 3, 25% of all the finally accepted changes were merged in less than 1 hour, 50% in less than 16 hours, and 75% in less than 95 hours (roughly 4 days). this also means, of course, that 25% of the changes that were approved took more than 4 days to merge. it is important to notice that in many of these cases several patchsets were submitted and reviewed before the change was finally approved (and the last of these patchsets was merged). and that this process takes place sequentially: for a given review if a new patchset is uploaded, the previous one is automatically deprecated. the numbers for abandoned changes are similar: a bit shorter for the quickest changes to be abandoned, a bit larger for those taking more time. figure 3 shows the distribution of time to close both types of changes. it can be graphically shown how most of the times are between e2 (approximately 7 hours) and e6 (about 400 hours, or 17 days). the difference between the distribution of abandoned and merged changes can also be better understood by viewing it. proc. sqm 2014 10 / 12 eceasst 7 conclusions and further work in this paper we have shown how systems supporting code review processes can be modeled as a specialized kind of issue tracking systems. this theoretical model has been used to extend the functionality of bicho, a tool to retrieve information about tickers from issue tracking systems, to retrieve information about code review processes from gerrit, one of the most popular tools to assist in code review in floss projects. extending an existing tool instead of writing a new one for retrieving information from gerrit has proved to be a very efficient approach, as it could be implemented with not much more than 200 lines of python code. the result is a completely functional gerrit data retriever, that offers information organized in an sql database ready to be queried to analyze any relevant parameter. the paper also shows how this database can in fact be mined to obtain such parameters in a real world scenario; in this paper we have shown it with the openstack project, with several tens of thousands of changes proposed and reviewed. this has allowed us to comment on the characteristics and the quality of several aspects of the review process. these aspects included both extensive properties, such as the time to close changes (review processes) or size of the communities involved in code review, and intensive properties, such as the oldest reviews at a certain point in time. in the future, authors intend to rearchitect bicho so that it becomes a tool for retrieving information both from issue tracking and code review systems. the work presented in this paper shows that its architecture is already close to that goal, but we intend to redesign it so that gerrit and other code review systems can be better integrated as first-class citizens in the context of bicho structure. reproduceability bicho can be retrieved from the metricsgrimoire project at github4. the exact version used for the work presented in this paper, along with the mysql dump of the database retrieved by bicho from the openstack gerrit repository and the r script used to produce the graphics and the data in this paper can be retrieved from the reproduceability package for this paper5. acknowledgments the work of jesus m. gonzalez-barahona and gregorio robles in the study presented in this paper has been funded in part the spanish government under project sobresale (tin2011-28110). the work of daniel izquierdo-cortazar has been funded in part by the spanish government under the torres quevedo program (ptq-12-05577). 4 http://metricsgrimoire.github.io 5 http://gsyc.es/∼jgb/repro/2014-sqm-bicho-gerrit 11 / 12 volume 65 (2014) http://metricsgrimoire.github.io http://gsyc.es/~jgb/repro/2014-sqm-bicho-gerrit analyzing gerrit code review parameters with bicho bibliography [bb01] b. boehm, v. r. basili. software defect reduction top 10 list. computer 34(1):135–137, jan. 2001. doi:10.1109/2.962984 http://dx.doi.org/10.1109/2.962984 [gimr13] j. m. gonzalez-barahona, d. izquierdo-cortazar, s. maffulli, g. robles. understanding how companies interact with free software communities. ieee software 30(5):38–45, 2013. [hky+13] k. hamasaki, r. g. kula, n. yoshida, a. e. c. cruz, k. fujiwara, h. iida. who does what during a code review? datasets of oss peer review repositories. in proceedings of the 10th working conference on mining software repositories. msr ’13, pp. 49–52. ieee press, piscataway, nj, usa, 2013. http://dl.acm.org/citation.cfm?id=2487085.2487096 [mbr13] m. mukadam, c. bird, p. c. rigby. gerrit software code review data from android. in proceedings of the 10th working conference on mining software repositories. msr ’13, pp. 45–48. ieee press, piscataway, nj, usa, 2013. http://dl.acm.org/citation.cfm?id=2487085.2487095 [ml09] m. mantyla, c. lassenius. what types of defects are really discovered in code reviews? software engineering, ieee transactions on 35(3):430–448, 2009. doi:10.1109/tse.2008.71 [rgih11] g. robles, j. m. gonzalez-barahona, d. izquierdo-cortazar, i. herraiz. tools and datasets for mining libre software repositories. volume 1, chapter 2, p. 24–42. igi global, hershey, pa, 2011. doi:10.4018/978-1-60960-513-1 http://www.igi-global.com/book/multi-disciplinary-advancement-open-source/ 46171 [rgs08] p. c. rigby, d. m. german, m.-a. storey. open source software peer review practices: a case study of the apache server. in proceedings of the 30th international conference on software engineering. pp. 541–550. 2008. proc. sqm 2014 12 / 12 http://dx.doi.org/10.1109/2.962984 http://dx.doi.org/10.1109/2.962984 http://dl.acm.org/citation.cfm?id=2487085.2487096 http://dl.acm.org/citation.cfm?id=2487085.2487095 http://dx.doi.org/10.1109/tse.2008.71 http://dx.doi.org/10.4018/978-1-60960-513-1 http://www.igi-global.com/book/multi-disciplinary-advancement-open-source/46171 http://www.igi-global.com/book/multi-disciplinary-advancement-open-source/46171 introduction code review with gerrit the bicho database schema modeling code review as changes to tickets extending bicho to support gerrit examples of analyses of the information number of people involved in reviews top oldest reviews in gerrit still open time to close a review conclusions and further work architectural constraints for pervasive adaptive applications electronic communications of the easst volume 28 (2010) proceedings of the third international discotec workshop on context-aware adaptation mechanisms for pervasive and ubiquitous services (campus 2010) architectural constraints for pervasive adaptive applications christian straube, andreas schroeder 12 pages guest editors: sonia ben mokhtar, romain rouvoy, michael wagner managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst architectural constraints for pervasive adaptive applications christian straube1, andreas schroeder1 institute for computer science, ludwig-maximilians-university munich1 abstract: to face the challenge in today’s mobile applications, that software entities and devices enter and leave the application scope very frequently, component-based architectures are used more and more. with the flexibility of this concept and the ability to handle a huge amount of situations come inpredictability and less reliability of the application. this article presents a “safety net” weaved by architectural constraints and an internal dsl to ensure the integrity of the whole application even after multiple reconfigurations. with this integrated, not graph-oriented approach, software-systems can be much more flexible in combination with less code complexity, and the responsibility of architectural integrity is moved from the developer to the application. keywords: component-based software-engineering, system architecture, reconfiguration, constraints, dsl 1 introduction system architectures of today’s mobile applications are inherently volatile. software entities and devices enter and leave the application scope as the users move through the physical environment, and new functionality is dynamically added or removed; as a consequence, connections among devices and relations among entities change frequently. in order to keep such applications manageable, a simple but powerful model of software and system structure is needed. one approach followed is using component-based architectures. essentially, these consist of two parts: the so-called components, which are responsible for implementing application behavior and encapsulate functionality [szy98] and the so-called connectors, which bind components together and can be seen as mediators between components. in the classical component-based approach, the advantages of reusability and minimized coupling of components are accompanied by an essential disadvantage: the model does not incorporate means to react to changes in the architecture, and as a consequence, the whole system cannot react to changes in its surroundings. the introduction of architectural reconfiguration [km90, omt98] dealt with this problem by introducing means and concepts for changing the structure of a system at run-time. still, today’s component systems lack the flexibility offered by these theories. one reason for this issue is that repeated reconfigurations may lead to systems with unclear structures, thereby losing the benefits of a clear system architecture. figure 1 gives an example of how the architecture of a software system may evolve over time without using any architectural constraints. in this example, the parameters in the surrounding change in an unpredictable order and combination, while at the same time, several rules must be satisfied to ensure intended operation of the software. it is easy to see that with hard-wired reconfiguration rules like nested if-then-else statements it is hardly possible to handle every pos1 / 12 volume 28 (2010) architectural constraints for pervasive adaptive applications surrounding parameters subset of possible combinations/changes system with different configurations accordant to changes invariants concerning the architecture c 1 c 2 c 3 c 4 p 1 p 2 p 3 p 4 a 1 a 2 a 3 a 4 figure 1: system evolution without architectural constraints. every c depicts a configuration sible combination. at this point, architectural constraints show their strength: with architectural constraints as safety net, it is easier to design reconfiguration rules which do not depend on a sequence of reconfigurations or changes in the surrounding. our contribution is to provide an architectural constraint framework at the level of code, allowing to check, introduce, and retract architectural constraints, and react to their violation at run-time. due to the complexity of solving constraint violations, our approach only triggers methods which repair the architecture but does not implement those methods. we provide this framework in a pervasive and adaptive way; it is pervasive because the approach underlays the whole software application as a safety net and not only at certain execution points. it is adaptive, as a hard-wired approach could not handle the extreme flexible environments of today’s applications. this article presents an approach to ensure application consistency through architectural constraints. we have implemented our approach to architectural constraints as an internal domainspecific language to java on top of an osgi-based component model [szh08]. a dsl, or special purpose language (spl) [spi01], is a programming language focused on a very specific domain and lacks advanced control structures like loops [mhs05, fow09b]. typically, a dsl assists a general purpose language (gpl) like java or c. an internal dsl uses its host language, encapsulates specific functionality and can be understand as a kind of library. the remainder of this paper is organized as follows. section 2 discusses the application area and background of our approach. in section 3 we present an overview of our approach and in section 4 we provide conceptual and implementation details. finally, we discuss related work in section 5 and conclude in section 6. 2 background as we are moving on from desktop computers to a pervasive computing intelligence interwoven in the “fabric of everyday life”, our interactions with computers are becoming more complex; new interaction schemes between humans and computers must be invented, as are interaction mechanisms between the devices making up our new ever-changing environment. proc. campus 2010 2 / 12 eceasst at the same time, these transformations also bring new opportunities for radically new ways of interactions between humans and computers. it-systems are not only becoming capable of discovering our physical context in terms of location and time; as computer systems are getting closer to us, the possibility arises to measure and influence our physical, emotional and cognitive context by measuring responses of our body through sensors and cameras, and reacting to them [szh08]. through this interaction, a biocybernetic loop [sf09] can be created for the benefit of the user. a biocybernetic loop is characterized by continuous interaction and mutual influence between the user and the it-system. by using wearable sensors and implicit channels, the it-system can adapt the environment to the user’s needs and create a more productive, more comfortable or more suitable environment for the user. 3 idea to create such a biocybernetic loop, a flexible software infrastructure is needed, as it has to handle virtually every condition of daily live. at the same time, the software has to be extremely stable and reliable, because of its deep and pervasive integration in everyone’s business. from the flexibility requirements, it can be deduced that it is much more harder to guarantee reliability and determinism. the software must react to an extremely wide range of constellations, some of which being even unknown at the point of design or implementation. we believe that for a clean separation of concerns the architecture of the software must be brought into focus: verifying the system’s integrity and repairing it should be done on the level of its architecture. as said before our approach does not cope with the repairing process, only with its invocation. thus, instead of making tools for verification of rules easier for the developer or optimizing existing case-related concepts, the aim of our approach is to find a new conceptual structure for the definition and verification of architectural rules. with this new concept, it should be possible to define generic rules with little code and to be independent from a special chain of events. therefore, our approach shifts from a case-related treatment to a more declarative level, namely to the architecture of the whole it-system, to the architectural surrounding of a component, and to its interactions with this surrounding. in order to reduce the necessary amount of code complexity for instance nested if-then-else blocks and to meet the mentioned goals, our approach creates a security net at the level of architecture. we use the phrase ”security net” because there are a lot of parallels to artists: the verification process happens outside of the main action (coding the application), the security net is the last instance before crashing and its effect does not depend on the concrete code. more details to the analogy can be found in section 4.1. 3.1 automotive example the aim of our approach is shown with a running example from the automotive domain. in this example, the noise (music, telephone call etc.) inside a car should be continuously adapted to the stress level of the driver, the endangerment of the situation, and sources of noise and distraction; incoming telephone calls and music should be managed by the pervasive adaptive system. this 3 / 12 volume 28 (2010) architectural constraints for pervasive adaptive applications system is an extension of the personalized affective music player as proposed in [jbw09]. the structure and architectural constraints of the example are shown in figure 2. there must be at least 1 source for action trigger actions only through coordinator perform actions only if telephone exists there must be at least 2 valid components source local media database source online streaming server music coordinator mood, source, volume action music volume controller adapt telephone phone controller adapt music all three sensors must serve valid data analysis component stresslevel heart rate skin temperature skin conductance level there must be at least 1 source for action analysis component endagerement rain vehicle speed outside temperature battery caller radio reception figure 2: adapt the noise to the stress level of the driver in this example, three different types of constraints can be identified: hasstate, connected and exists. the stress level of the driver is detected by an analysis component connected with physiological sensors like skin conductance and ecg producing physiological features like skin conductance level, skin conductance response and heart rate variability. the analysis component has the state active (hasstate) and the status property set to operational, indicating that all sensors work properly and serve valid data. the endangerment of the situation is detected by an analysis component as well. if one of these analysis components does not run properly – the state is not active or the status property has not the value operational – the noise level in the car is not managed by the pervasive adaptive system. in this situation, both analysis components can trigger callback methods which ”repair” the architecture and perform needed adaptations. the controller component adapt music is connected to both analysis components and receives data from them (connected). only with at least one music source connected, the controller performs actions. if there are no music sources, the music cannot be adapted. with the help of an architectural constraint, the controller determines whether the current source is a local proc. campus 2010 4 / 12 eceasst media database or an online streaming server. this is done by the combination of two architectural constraints: exists and connected . if it is a local media database, it gets the value canchangetotargetmusicmood for the mood relax from it. this value is true if there are songs in the database with a more relaxing influence than the current one, and the music mood has not been changed within the last five minutes. if so, the coordinator component requests the music coordinator to change the mood of the music. if the mood cannot be changed or the current source is an online streaming server, the music controller request the music coordinator to decrease the music volume. the action of adapting the music can only be achieved through the component music coordinator (exists, connected). the music coordinator guarantees that the most important request is served first and that the driver experiences a coherent behavior of the system. if for instance, the controller adapt telephone requests the coordinator to forward a call to the driver and at the same time decrease the music volume for this, it will only be carried out if the stress level of the driver is under a certain limit or if the calling person is member of a vip-group, e.g. family. the example shows only one of many different scenarios. another possible scenario would be a very tired or inattentive driver. in this case, the music should not relax the driver but keep him attentive. 4 details 4.1 system-wide security net with the help of architectural constraints, a system wide security net can be established that ensures the architectural integrity after every reconfiguration or when manually triggered. however, only detecting violations of the architectural integrity is often unsatisfactory. therefore, our architectural constraint system allows to specify arbitrary reactions to the violation of constraints – allowing in particular the developer to specify repairing actions to be undertaken in-place with the architectural constraint. using a security net has several benefits. first and most obviously the software is less errorprone. whenever a constraint is violated, the security net avoids (fatal) runtime errors as architectural constraints are checked. second, the code is easier to maintain because is not blown up by lines over lines of code to validate the architecture: instead of a procedural way, where multiple lines of code for every single case are needed, our concept has a more declarative approach. this declarative approach supports thinking about the it-system as an entity. as one constraint can handle several different cases, the code is more generic and errors are not concealed in a special case deep inside the code. third, even conditions which are not considered at design-time and during implementation can be handled due to our generic approach. the generic treatment at architectural level comes into play as well. instead of defining rules depending on a specific configuration, every component define its very own requirements on the architecture. therefore, the rule does not depend on a specific case but it defines the requirements of a component on the architecture for every case. of course, there can be conflicts between two or more constraints, for instance one constraint postulates component a to exist, another constraints postulates a not to exist. this issue is discussed as future work in section 6. altogether, allowing the developer to specify a system-wide security net increases the system’s 5 / 12 volume 28 (2010) architectural constraints for pervasive adaptive applications reliability and leads to a more deterministic behavior of the system. 4.2 support for reuse software components are intended to be reusable entities and help to reduce multiple and redundant code development. this can only be achieved if they can be re-used in multiple environments. our generic approach allows just this: instead of focussing on correctly assembling a single system, the use of architectural constraints guides developers towards thinking in terms of the structural requirements of components and of architectural constraints that the system must satisfy for the software component to operate correctly. hence, using architectural constraints – and in particular our approach – is a supporting factor for component reusability. 4.3 constraint types and structure figure 3 shows the main structure of the definable constraints. as visible in the uml diagram, there are four main constraint types and their corresponding negations plus a preparing constraint. magicdraw uml, 1-1 /users/cstraube/documents/studium/projektarbeit/veroeffentlichung_campus10/graphics/campus2010/campus2010.mdzip constraints may 21, 2010 4:23:00 pm #definedat : stacktraceelement -otherwises : set +callotherwise( f : dslmodelfailure ) +getdefinedat() : stacktraceelement +verifycomponents() constraint -fromport : port -viaport : port -withcomponents +verifycomponents() constraintconnectednot +verifycomponents() constraintexistsnot +verifycomponents() constraintexists -fromport : port -viaport : port -withcomponents +verifycomponents() constraintconnected -ownerid : string -ownerobject +verifycomponents() constraintonwedbynot -states : state[] +verifycomponents() constrainthasstatenot -states : state[] +verifycomponents() constrainthasstate +verifycomponents() constraintprepared -ownerid : string -ownerobject +verifycomponents() constraintownedby figure 3: constraint types by default, every constraint tracks the line of code defining the constraint and the line of code where it failed. in this way, the developer gets the information needed to start debugging and fixing constraint violations. due to the fact that every constraint has its own java-class and the encapsulation of the error information into a dslmodelerror-object (section 4.5.1), the collected information of a violation can be extended very easily if needed and the line number can be seen as starting point for debugging. in addition, it is very easy to extend our approach with own constraint types. other concepts, like automatic search and observe changing points, are less or even not flexible or extensible. proc. campus 2010 6 / 12 eceasst details on callback method invocation and prepared constraints are given in section 4.5.1 and section 4.5.2, respectively. 4.4 code example this section contains a code example with every construct incorporated by our approach. p u b l i c c l a s s m a n a g e r { p u b l i c v o i d s t r e s s l e v e l w r o n g s t a t u s ( d s l m o d e l f a i l u r e e r r o r ) { s y s t e m . o u t . p r i n t l n ( e r r o r . g e t m e s s a g e ( ) ) ; s y s t e m . o u t . p r i n t l n ( ” d e f i n e d ” + e r r o r . g e t d e f i n e d a t ( ) ) ; } p u b l i c v o i d e x c e p t i o n h a n d l e r ( d s l m o d e l e x c e p t i o n e ) { s y s t e m . o u t . p r i n t l n ( ” d e f i n e d ” + d s l e x c e p t i o n . g e t f a i l u r e d e t a i l s ( ) . g e t d e f i n e d a t ( ) ) ; } p u b l i c m a n a g e r ( ) { c h e c k ( ) . g e t ( i d ( ” s t r e s s l e v e l ” ) ) . e x i s t s ( ) . o t h e r w i s e ( f a i l ( ) ) . h a s s t a t e ( active ) ) . o t h e r w i s e ( c a l l ( t h i s , ” s t r e s s l e v e l w r o n g s t a t u s ” ) ) ; c h e c k ( ) . l e t ( ” c o n t r o l l e r e x i s t s ” ) . g e t ( i d ( ” m u s i c c o n t r o l l e r ” ) ) . e x i s t s ( ) . o t h e r w i s e ( f a i l ( ) ) ; c h e c k ( t h i s , ” e x c e p t i o n h a n d l e r ” ) . g e t ( i d ( ” m u s i c c o o r d i n a t o r ” ) ) . e x i s t s ( ) . o t h e r w i s e ( f a i l ( ) ) . c h e c k ( ” c o n t r o l l e r e x i s t s ” ) ; } p u b l i c v o i d v a l i d a t e c o n s t r a i n t s ( ) { c h e c k ( ) . v a l i d a t e ( ) ; } } the method stresslevelwrongstatus() is an individual callback method that is invoked whenever the stress level constraint validation fails. the dslmodelfailure-parameter encapsulates information about the failure, e.g. where the constraint was defined. as mentioned above, the dslmodelfailure-object can be extended if needed. in addition to callback methods, exception handlers can be defined, as seen in the definition of exceptionhandler(). this method handles exceptions thrown by the dsl, e.g. thrown on the usage of an undefined prepared constraint or when an unhandled constraint fails (fail() in the otherwise() call). the constraints are defined in the class constructor createconstraints(). the first constraint gets all components with the id stresslevel, checks their existence, and throws 7 / 12 volume 28 (2010) architectural constraints for pervasive adaptive applications an exception (indicated by fail()) if none exists. as there is no component to detect the stress level of the driver, the noise cannot be adapted. if at least one stress level component exists, the constraint checks its state (done by hasstate()). if one of the found components has a state different from active, the callback method stresslevelwrongstatus() is invoked. note that the state that is checked by a state constraint is abstract, i.e. it does not refer to the concrete data state, but instead to an abstract representation of state that can be inspected by external entities. the next constraint definition prepares a constraint that can be referred to through its id controllerexists. it is only prepared because the existence of a music controller is only important in a certain context, for instance whenever the stress level of the driver and the endangerment of the situation can be detected or if a music coordinator exists. hence, there’s no need to validate the constraint immediately. the last constraint states that the specified exception handler should be used instead of the default handler. it gets all components with the id musiccoordinator, fails if none exists and executes the prepared constraint controllerexists otherwise: the controller works as expected only if a coordinator exists. in a productive it-system, the callback methods and exception handlers would contain functionality to adapt the architecture instead of simple output invocations. aware of the scope of our approach, we forsweared such functionality in our example. 4.5 toolbox of our approach 4.5.1 validation, error handling and individual method calls whenever the validation of an architectural constraint fails, it should be as easy as possible to define custom reaction schemes. constraining the possibilities of reacting to violations would advance the use of workarounds, as there are many ways for reacting to violations. of course, repairing the system in case of a violation is the most desired reaction, and already this can be performed in several ways: sending a special message to a software component, changing a property of a single component or reconfiguring a part of the system is only a subset of possible reparation activities. in addition to this, reporting the error and deactivating or restarting affected parts of the system may also be an option for reacting to architectural constraint violation. in that respect, constraint violation handling is very similar to exception handling: it needs the power of a general purpose language. therefore, we allow the developer to specify a set of violation handling methods to be called, and have implemented a default behavior for reacting to violations. the built-in default handling can be called with the method failed(). in this case, an exception is thrown and the following error message is written down in the console: the c o m p o n e n t s t r e s s l e v e l d o e s n o t e x i s t d e f i n e d a t . . . m a n a g e r .< c o n s t r u c t o r >( m a n a g e r . j a v a : 6 6 ) v e r i f i e d a t . . . m a n a g e r . v a l i d a t e c o n s t r a i n t s ( m a n a g e r . j a v a : 8 2 ) in modern ides, manager.java:66 and manager.java:82 are linked to the respective lines of code, so the developer can easily jump with one click to the point of interest and is proc. campus 2010 8 / 12 eceasst assisted to fix the constraint validation failure. the second possibility is to define one or more callback methods which are called when a constraint cannot be validated. several callback methods can be specified for every single constraint as shown in the following example: c h e c k ( ) . g e t ( i d ( ” c o m p o n e n t i d ” ) ) . e x i s t s ( ) . o t h e r w i s e ( c a l l ( t h i s , ” f a i l u r e c a l l b a c k ” ) , c a l l ( d e m o i n s t a n c e , ” f o o ” , ” b a r ” ) ) ; the defined constraint fails if no component with the id componentid exists. in this case, all the methods referred in the otherwise() block are invoked. first, the method failurecallback() of the current object is invoked. next, the method foo("bar") owned by the object demoinstance is invoked, receiving "bar" as parameter. the advantage of this implementation is that there are no container methods needed to collect different callback invocations. instead, every method can be passed on its own, including all its parameters. the last possibility is to define an own handler for exceptions thrown during the validation process. this handler gets the thrown exception as parameter. this exception contains a dslmodelerror-object which contains all the important information about the error. 4.5.2 prepared constraints and context-dependent verification sometimes a constraint should not be validated directly but either later or bound to a special event or context. it could be later if all constraints are defined in one central place and the validation is triggered later in a specific method. it could be bound to a specific context if a constraint should only be validated if another constraint was positive (or negative) validated. for those situations, we added prepared constraint to our approach. a prepared constraint is defined like any other constraint with an additional id. the id is unique in the whole security net and can be referred from any place. prepared constraints can be called via the check(id) method by specifying the constraint id. 4.5.3 easy integration and usage the best concept is useless if it is not reasonable to handle in practice. to support the usage of a new concept, there are two critical points: first, it must be easy to install. our approach is implemented as internal dsl which means that it consists of a library without the need for additional parsers, compilers or runtime environments, since an internal dsl uses the host language itself. second, it should be easy to use. when new concepts are established, the main problem is that there is no time to learn how to use it and its new syntax, semantics and rules. to bring those demands to a minimum, our approach comes with a fluent interface, which means that all the architectural constraints can be defined as sentences, making them easy to read and understand. 4.5.4 fluent interface one advantage of our approach is the intuitive definition of architectural constraints through a fluent interface [fow09a]. instead of writing single lines of code, a whole sentence can be 9 / 12 volume 28 (2010) architectural constraints for pervasive adaptive applications created. / / common foo f = new foo ( ) ; l i s t l i s t = f . g e t o b j e c t s f o r p r e d i c a t e ( ” f o o ” ) ; f . w o r k w i t h l i s t ( l i s t ) ; / / f l u e n t i n t e r f a c e f . g e t l i s t ( ” f o o ” ) . a n d h a n d l e ( ) ; compared to the common way of coding (commandquery-api), where the meaning of a method must be inferred from its name without any context, in a fluent interface, the meaning of a method is defined by its position in the sentence. the meaning of a code block can be read as a sentence, which reduces the need to look up method documentation in a programming interface guide. 5 related work applying architectural constraints to evolving component-based systems is everything but new; approaches to architectural constraints range back to the mid nineties [mk96, bal96]. however, modern approaches to architectural constraints focus on more specific topics like model-driven development [krg08], which propose using architecture models and variation points specified in uml for designing adaptive applications. here, architectural constraints have the primary role to reduce the combinatorial explosion in the number of variants. other more recent component-based approaches similar to our approach are archjava [acn02] and rainbow [gsc09]. while archjava focuses on preventing architectural erosion on the implementation level, reconfigurations and the entailed need for run-time checking of system instances are not considered. the rainbow framework is very similar to ours in technical details, and its capabilities goes even those of our constraint framework, but has a different focus. rainbow provides means to realize adaptation logic, while we propose to use architectural constraints as safety net under such adaptive behavior; our methodological perspective is hence different. others, like [blmt08] focus on formal analysis of software architectural constraints and system reconfigurations. in the former work a graphical and textual notation is used which is inspired by hypergraphs and term rewriting. the approach of bruni et al. allows to statically verify that a component-based system under reconfiguration will always respect the architectural constraints imposed on the system. all approaches so far introduced formal notations [blmt08], uml profiles [krg08, fos09] or own programming languages [mk96, bjc05] for the specification of architectural constraints. our approach differs from the existing ones in that respect. by using the host language that also contains the full application logic, architectural constraints can be specified and verified within the standard development environment, leveraging the full power of the java programming language and java ides. hence, our approach takes a more pragmatic view on the use of architectural constraints, purposefully trading formal verification possibilities for usability. proc. campus 2010 10 / 12 eceasst 6 conclusion and future work this paper presented an architectural constraint framework that is intended to be used to improve reliability and reusability in pervasive adaptive systems [szh08]. in particular, it gives insights to the design rationale of our constraint framework based on a fluent-interface style internal dsl. the design of the domain specific language was driven by the idea of reducing code redundancy, promoting clear separation of concerns and allowing a concise specification of architectural constraints without the use of boilerplate code. the goal of our approach is twofold, namely a) to shift the focus from the development single systems to the development of single reusable components in multiple scenarios. this is achieved by allowing the developer specifying architectural requirements for the use of components. furthermore our goal is b) to increase the flexibility and adaptivity of component-based software systems by allowing to dynamically react to constraint violations. the architectural constraint framework presented lives at the level of code, allowing to check, introduce, and retract architectural constraints, and react to their violation at run-time. during the implementation and use of the constraint framework, future work on architectural constraints has been identified. firstly, allowing every component to specify architectural constraints may lead to an inconsistent constraint base; repair actions trying to re-establish a subset of constraints would immediately invalidate other constraints. the detection of inconsistent constraint sets is therefore one extension for our framework. additionally, it is worthwhile to investigate how autonomous self-repairing actions based on constraint-solving techniques can be of use in the domain of architectural constraints, and how to control their interference with developer-specified repairing actions. a solution to both inconsistent constraints and interactions between autonomous self-repair and explicit repair actions could be the use of soft constraints, in which a priority can be specified to architectural constraints. acknowledgements: this work has been partially sponsored by the ec project reflect, ist-2007-215893. bibliography [acn02] j. aldrich, c. chambers, d. notkin. archjava: connecting software architecture to implementation. in icse. pp. 187–197. acm, 2002. [bal96] r. balzer. enforcing architecture constraints. in 2nd int. soft. architecture wshp. and int. wshp. on multiple perspectives in soft. dev. pp. 80–82. acm, 1996. [bjc05] t. v. batista, a. joolia, g. coulson. managing dynamic reconfiguration in component-based systems. in ewsa. lncs 3527, pp. 1–17. springer, 2005. [blmt08] r. bruni, a. l. lafuente, u. montanari, e. tuosto. style-based architectural reconfigurations. bulletin of the eatcs 94, 2008. [fos09] h. foster. architecture and behaviour analysis for engineering service modes. in wshp. on principles of engineering service oriented systems. pp. 1–8. ieee, 2009. 11 / 12 volume 28 (2010) architectural constraints for pervasive adaptive applications [fow09a] m. fowler. domain specific languages expression builder. domain specific languages, 2009. http://www.martinfowler.com/dslwip/expressionbuilder.html [fow09b] m. fowler. domain specific languages intro. domain specific languages, 2009. http://martinfowler.com/dslwip/intro.html#programmingmissgrantscontroller [gsc09] d. garlan, b. schmerl, s.-w. cheng. software architecture-based self-adaptation. volume isbn 978-0-387-89827-8, pp. 31–55. springer, 2009. [jbw09] j. h. janssen, e. l. v. d. broek, j. h. westerink. personalized affective music player. in 2009 int. conf. on affective comp. and intelligent interaction. pp. 472–477. ieee, 2009. [km90] j. kramer, j. magee. the evolving philosophers problem: dynamic change management. ieee transactions on soft. eng. 16:1293–1306, 1990. [krg08] m. u. khan, r. reichle, k. geihs. architectural constraints in the model-driven development of self-adaptive applications. ieee distributed systems online 9(7):1, 2008. [mhs05] m. mernik, j. heering, m. sloane. when and how to develop domain-specific languages. acm comp. surveys 37:316–344, 2005. [mk96] j. magee, j. kramer. dynamic structure in software architectures. in sigsoft fse. pp. 3–14. acm, 1996. [omt98] p. oreizy, n. medvidovic, r. n. taylor. architecture-based runtime software evolution. in icse. pp. 177–186. ieee, 1998. [sf09] n. b. serbedzija, s. h. fairclough. biocybernetic loop: from awareness to evolution. in 11th congress on evolutionary comp. pp. 2063–2069. ieee press, 2009. [spi01] d. spinellis. notable design patterns for domain-specific languages. journal of systems and software 56(1):91–99, 2001. [szh08] a. schroeder, m. v. d. zwaag, m. hammer. a middleware architecture for humancentred pervasive adaptive applications. in 2008 2nd ieee int. conf. on selfadaptive and self-organizing systems wshp. pp. 138–143. ieee, 2008. [szy98] c. szyperski. component software: beyond object-oriented programming. addison-wesley, 1998. proc. campus 2010 12 / 12 http://www.martinfowler.com/dslwip/expressionbuilder.html http://martinfowler.com/dslwip/intro.html#programmingmissgrantscontroller introduction background idea automotive example details system-wide security net support for reuse constraint types and structure code example toolbox of our approach validation, error handling and individual method calls prepared constraints and context-dependent verification easy integration and usage fluent interface related work conclusion and future work requirements analysis foran integrated ocl development environment electronic communications of the easst volume 24 (2009) proceedings of the workshop the pragmatics of ocl and other textual specification languages at models 2009 requirements analysis for an integrated ocl development environment joanna chimiak–opoka, birgit demuth, darius silingas, nicolas f. rouquette 15 pages guest editors: j. cabot, j. chimiak-opoka, f. jouault, m. gogolla, a. knapp managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst requirements analysis for an integrated ocl development environment joanna chimiak–opoka1, birgit demuth2, darius silingas3, nicolas f. rouquette4 1 institute of computer science, university of innsbruck, austria joanna.opoka@uibk.ac.at 2 department of computer science, technische universität dresden, germany birgit.demuth@tu-dresden.de 3 no magic europe, savanoriu av. 363, 49425 kaunas, lithuania darius.silingas@nomagic.com 4 jet propulsion laboratory, caltech, m/s 301–270, 4800 oak grove drive pasadena, ca 91109, usa nicolas.f.rouquette@jpl.nasa.gov abstract: an integrated ocl development environment (ide4ocl) can significantly improve the pragmatics and praxis of ocl. we present the domain concepts, tool–level interactions with ocl and the use cases we identified in a systematic analysis of requirements for an ide4ocl. the domain concepts is an important contribution of our work as it attempts to clarify inconsistencies in the relevant specifications. because ocl is not a stand–alone language, the ocl landscape includes several interacting tools including an ide4ocl. the use cases describe our vision of the desired functionality unique to an ide4ocl. the results of our analysis and the long term vision of our work should be relevant to developers of ocl tools as well as to the omg request for information regarding the uml futures1. our work is relevant to the uml futures roadmap because providing ocl for the constraints in the uml specification has been a longstanding problem at the omg. keywords: ocl concepts, ocl development, ocl pragmatics, ocl tool support, requirement specification 1 introduction the specification and implementation of the object constraint language (ocl) involves three language definition aspects: syntax, semantics and pragmatics. for any language syntax must be specified prior to semantics since meaning can be given only to correctly formed expressions in a language; semantics needs to be formulated before considering the issues of pragmatics since interaction with human users can be considered only for expressions whose meaning is understood [sk95]. for ocl, the dependencies amongst these aspects are reflected in the chronological phasing of their maturity with pragmatics lagging behind semantics which is lagging behind syntax. for ocl, the broad support for the syntactic and semantic aspects stand in sharp contrast with the dearth of support for pragmatics. formalisations of ocl syntax and semantics are the basis for building tool support for automatic checking of syntactical correctness and formal reasoning 1 http://www.omg.org/news/releases/pr2009/06-18-09.htm 1 / 15 volume 24 (2009) mailto:joanna.opoka@uibk.ac.at mailto:birgit.demuth@tu-dresden.de mailto:darius.silingas@nomagic.com mailto:nicolas.f.rouquette@jpl.nasa.gov http://www.omg.org/news/releases/pr2009/06-18-09.htm requirements analysis for ide4ocl about properties of ocl specifications. in contrast to syntax and semantics, pragmatics cannot be formalised [bjo06]. however, pragmatics entices programmers to use a language. this implies the fact that pragmatics does not need theory, it needs practical solutions. despite recent advances in tool support for ocl [b+05], much remains to be done conceptually and technically to encourage practitioners to work with ocl tools [cpp08] as defining ocl expressions is still difficult, error–prone and a time–consuming task [ack01]. as a two–language hybrid artifact, a mof–based model with ocl constraints is inherently more difficult to understand and evolve than an equivalent single–language artifact. for hybrid models, there is ample empirical evidence that the organization of the mof–based model has a strong influence on the understandability of ocl constraints for that model [c+07]. this paper focuses on the pragmatics of ocl in the context of the life cycle of hybrid models. we consider here internal pragmatics, i.e. pragmatics within the ocl development process and one considering its impact on developers. in [cpp08], it was mentioned that tools’ constituents (editors, compilers, browsers) must implement the functionalities established by integrated development environments (ides). we want to go one step further with a systematic requirement analysis for an integrated ocl development environment, which we call ide4ocl. instead of targeting the ideal ocl tool, we focus on an ide supporting the development of ocl specifications as part of an overall ocl tools landscape. in terms of an abstracted typical life cycle of an ocl specification to be plan–do–check–act cycle (fig. 1), we focus on support of the second and the third steps where an ocl specification is the focus of the development and verification activities. in the life cycle we consider external pragmatics, i.e. how the ocl specifications are used outside an ide4ocl. act—use the ocl specification to increase the quality of systems built with the conceptual model. it is related to the (external) pragmatics, as we consider usage of the specification. check—assess if the ocl specification meets the objectives/requirements. it is related to the semantics, as semantical properties of the specification are tested or verified, and (internal) pragmatics focusing on ease of assessment. plan—determine objectives/requirements of an ocl specification for a conceptual model. do—define the ocl specification or a part of it to operationalize the specification objectives. it is related to the syntax, as the syntactically correct specification is defined using error prevention mechanisms, and (internal) pragmatics focusing on ease of development. figure 1: a life cycle of an ocl specification seen as the deming cycle [dem86]. to flesh out the requirements for an ide4ocl, we start with domain analysis and define the system context specifying what are the responsibilities of an ide4ocl. then we decompose proc. ocl 2009 2 / 15 eceasst the identified use cases into tool features that are similar to the features implemented in modern integrated development environments like eclipse platform. the applied requirements analysis approach is presented in more detail in [sb08, sb09]. on first approximation, we identified three classes of requirements: domain analysis, system context, and use case model. domain analysis is based on a refined ocl metamodel, which is re–categorized from the pragmatical view and extended with additional concepts from programming, such as the notions of project and library. for defining the system context, we focus on the information flow between tools that either make use of ocl expressions or can help a developer specify or evaluate them. the structure of the paper corresponds to the requirement analysis steps for an ide4ocl. at first we analyse the domain of an ide4ocl (section 2). next we describe the identified use cases and features (section 3). the last section provides conclusion, and discusses relevance of our work and future steps. 2 domain specification in the subsequent subsections we define domain concepts and give a context of an ide4ocl. 2.1 domain concepts our proposal is based on our academic teaching and tool development experience [dw09, c+08] and aims to clarify problems with understanding different concepts of ocl specification by students and developers. we also introduce axillary concepts [bd07, co09] as means to improve ocl application to different metamodels and ocl development process. for better understanding we introduce domain concepts in three stages. at first we review the latest ocl standard specification [omg06] (in the rest of the paper called the standard for short) and introduce our categorisation of related concepts (fig. 2). next we relate the ocl concepts with the modeling abstractions levels (fig. 3). finally, we introduce concepts necessary for the context and requirement specification for an ide4ocl (fig. 4). 2.1.1 ocl concepts we propose a 2–layer view of the domain concept for ocl [omg06]. it introduces a categorisation of these concepts considering a language definition [sk95] with syntax, semantics and pragmatics. within the domain description we preserve the original syntax and semantics given by the standard and we add the third perspective, namely (external) pragmatics, to express how the concepts are used at a level of abstraction that matters for the ide4ocl requirements. this model leaves out several aspects of pragmatics that are simply out of scope for the purposes of this paper. in fig. 2 we give an overview of concepts and show separation between syntactical and pragmatic view. the top row of the syntactic context layer (above the dashed line in fig. 2) presents the top level concepts with their meaning and relations corresponding to [omg06, clause 12.12]: package (12.12.1), context declaration (12.12.2) and expressions (9.3). the middle row introduces further categorisation of context declarations depending on the type of a contextual element (12.12), i.e. for classifier, operation and attribute or association. the bottom row corresponds to the 3 / 15 volume 24 (2009) requirements analysis for ide4ocl syntactical categories from [omg06, section 12] with their original meaning preserved: definition (12.5,12.12.6), invariant (12.6,12.12.6), precondition (12.7,12.12.9), postcondition (12.7.2,12.12.9), operation body expression (12.10,12.12.8), initial value expression (12.8,12.12.4), and derived value expression (12.9,12.12.4). statement constraint context declaration implicit constraintexplicit constraint operation contextclassifier context attribute or association context syntactical view ocl expression definition pragmatic view element definition derived value operation body invariant postconditionprecondition initial value package <> 0..* <> <><> <> <><> 1..* figure 2: ocl concepts from syntactic and pragmatic point of view. the leaf concepts of the syntactic context layer relate to the concepts of the pragmatic domain layer (below the dashed line in fig. 2). a description of these concepts from left–to–right in the figure follows. element definition is a new model element added by the ocl specification. it is a definition (12.5,12.12.7) which can introduce an attribute, an association or an operation. constraint is any construct used to impose restrictions on a model instance. it can be defined explicitly or implicitly. explicit constraint groups syntactical categories that are explicitly classified as a constraint in the standard and which consist of an ocl expression of boolean type, i.e. invariant, postand precondition. the standard explicitly introduces guards (12.11) as a semantic concept. we skipped guards in our domain concepts because a guard is a precondition from the syntactical view as well as from the pragmatic view. implicit constraint groups syntactical categories that are not classified as constraints in the standard and consist of ocl expressions of arbitrary types, i.e. operation body, initial and derived value. this concept groups elements that are used as constraints, i.e. to impose restrictions on a model instance. they provide an expected value (e), e.g. as a derived value for an attribute, which is compared with an actual value obtained from a proc. ocl 2009 4 / 15 eceasst model instance (a), e.g. of the attribute, and this comparison forms an equation, a boolean expression (e=a), which is an implicitly–defined constraint. statement is the most general term in the pragmatic view. it is introduced to denote a single chunk of an ocl specification that can be developed within an ide4ocl. 2.1.2 modeling abstraction levels as mentioned before, ocl is a language which always depends on another modeling language. without another language used for modeling, it does not make any sense to define constraints because ocl is used for constraint specification but not for modeling itself. thus, besides ocl, a modeling language is required to define a model on which ocl constraints shall be specified (fig. 3). we assume the omg mof four layer metadata architecture which is used to arrange and structure the metamodel, the model, and its model instances into a layered architecture. generally, four layers exist, the meta–metamodel layer (m3), the metamodel layer (m2), the model layer (m1), and the model instance layer (m0). mn mn+1 element definitionmodel metamodel pivotmodel model instance essentialocl element instance constraintelement mn-1 isdefinedfor isevaluatedforisevaluated <><><> adaptedto extends 0..* 0..* <> figure 3: generic three metadata layer architecture for ocl ocl statements can be defined on both, metamodels or models and be evaluated on models or model instances, respectively. thus, the four layer metadata architecture can be generalized to a generic three metadata layer architecture [dw09]. on the mn+1 layer lies the metamodel that is used to define the model that shall be constrained. the metamodel defines a modeling language. it is required that it is a mof (or emof/ecore)–based model, i.e. mof/emof/ecore itself or an instance of mof/emof/ecore, like uml or a dsl (domain specific language). the used metamodel has to be adapted to the so–called pivot model [bd07] . pivot model is an intermediate metamodel that allows the alignment of arbitrary metamodels with that of ocl. by directly supporting generics in this metamodel, modeling all of the template types and operations in the ocl standard library becomes possible. the pivot model is designed for any ocl tools and understood as a general concept or pattern. the pivot model based architecture provides therefore a flexible model repository adaptation mechanism and allows using ocl for any modeling languages which is an important feature 5 / 15 volume 24 (2009) requirements analysis for ide4ocl for an ide4ocl. the pivot model is designed on base of essential ocl [omg06]. essential ocl plays the role of the ocl metamodel. however, it should be noted that essential ocl is currently not very well–defined. in [rg99], a more founded metamodel was proposed for the first version of ocl. from a pragmatic point of view, essential ocl is adequate for the implementation of the pivot model, how it is proven in dresden ocl2 for eclipse. on the mn layer lies the model which is an instance of the metamodel that is enriched by the specification of ocl constraints. finally, on the mn-1 layer lies the model instance on which the ocl constraints shall be verified. please note, that in the context of such a generic layer architecture, a model instance can be both a model (like an uml class diagram) or an object (like a java object or relational data). 2.1.3 ocl development concepts in the last stage of the concepts definition we introduce concepts (fig. 4) related to the ocl development process within an ide4ocl and information exchange within the ocl tool landscape (fig. 5). test unit project library model model instance package packages 0..* userdata 0..* tests 0..* context 1 testdata 1 usedlibraries 0..* libraries0..* usedlibraries 0..* figure 4: ocl development concepts and their interrelations. project is a collection of packages and libraries that are developed within an ide4ocl. libraries can be imported (used). a project refers to a contextual model for which ocl statements are defined and to model instances on which ocl statements are evaluated. library is a kind of package with intent to be reusable [co09]. libraries as reusable artifacts can be imported into a library and form a hierarchy of libraries. additionally, a library contains test units. test unit is used to test an element definition before it is reused in another library or in an ocl statement. it is related to a model instance which provides test data and is an instance of the library contextual model [co09]. 2.2 context specification after a decade of several prototype implementations of ocl based tools and toolchains for multiple purposes, the ocl landscape is already manifold. this makes it difficult to classify these tools. we propose a simplified view on an ocl tool landscape (fig. 5) required to define the proc. ocl 2009 6 / 15 eceasst context of an ide4ocl which is based on possible usage scenarios of ocl [dw09]. based on our academic and industrial practice in ocl software development we identified tool–integration requirements for an ide4ocl, which is responsible for development of correct ocl statements (corresponding to do and check in fig. 1), whereas other tools consume ocl statements (corresponding to act in fig. 1). the character of the overall architecture can be considered as a toolchain or a collection of plug–ins. from a toolchain perspective, portability of ocl expressions across tools requires all tools to produce consistent ocl interpretations of the same ocl expressions. this approach requires a complete ocl specification to be respected by every tool vendor involved in the toolchain, including consideration of factors beyond the standard such as [cpp08, section 3]. from a plug–in architecture perspective, there must be only one component responsible for ocl interpretation. in this paper we assume possibility of exchanging ocl expressions with the full preservation of their semantics. this assumption enables us to incorporate a feedback from usage of an ocl specification and thus impact its further development to enable continuous improvement in an ocl specification life cycle. transform ocl into tests <> testing tool design models and model instances analyse model instance with ocl verify model instances with ocl <> modeling tool evaluate statement specify statement verify statement <> manage project ide4ocl reason on/ check project <> formal verification tool store and manage models/projects <> repository use ocl for model transformations transform ocl into code <> mde tool project evaluation results project project package, ocl expression model model, model instance, project project evaluation results package, model instance figure 5: the ocl tools landscape: relations between tools. below we will discuss particular tools in the ocl tool landscape and information exchange between them and an ide4ocl, which itself will be described in the next section. in the context of an ide4ocl, the most tightly related tools with bidirectional communication are a modeling tool, a repository and a formal verification tool. the remaining two tools, namely a mde tool and a testing tool, only consume ocl statements developed within an ide4ocl. however, all tools in the landscape exchange different artifacts, in the diagram we only focus on communication with an ide4ocl. a modeling tool is typically an uml tool that allows specification of constraints in any language, most frequently just as strings. in this case the integration should be tight (e.g. via plug–in mechanism) as both tools provide services for one another and constitute a symbiosis required by 7 / 15 volume 24 (2009) requirements analysis for ide4ocl the hybrid nature of the models. on one side ide4ocl provides ocl expressions/package for a given model designed in the modeling tool, next they can be evaluated within ide4ocl. the evaluation results can be returned to the modeling tool, where model verification or analysis is performed. on the other side, model and model instances are required to create ocl statements. then they can be designed within the modeling tool. another possibility to obtain models and model instances is to fetch them from a repository. in our architecture we consider a repository which plays a role similar to a version management system in software development or a data warehouse in a database system. the repository is a generic one, i.e. it is a kind of mof repository whose structure is not determined by an underlying metamodel, thus it can store any mof based metamodels, models, model instances, ocl expressions and projects. the artefacts from the repository can be loaded into an ide4ocl as working copies and subsequently modified and archived. specifying the complete functionality of a repository is a complex topic beyond the scope of this paper, thus we consider only it realizing storage and management of models/projects. other tools can access the repository to obtain desired ocl expressions together with related models, but as mentioned before we focus on communication with an ide4ocl only. the last tool which is tightly related to an ide4ocl is a formal verification tool. this tool has a producer and consumer role, as it can help to obtain semantically correct ocl specifications and use them to formally verify model instances. it is crucial to have any kind of formal reasoning supporting an ide4ocl to be able, e.g. to determine a specification satisfiability or to detect contradicting constraints. however, formal verification is a too complex problem to be considered as an integral part of an ide4ocl. instead we consider an integration of existing approaches, such as hol–ocl2 [bw08] an interactive proof environment based on a semantic framework described in [bru07], an interactive theorem prover [bhs07] (the transformation is a part of the key tool3) based on a translation of uml class diagrams with ocl constraints into first–order predicate logic described in [bks02], pvs4 a theorem prover together with a translation of uml class diagrams and a subset of ocl into its input language described in [kya06]. two approaches regarding the ocl evaluation can be considered, interpretation and code generation. the first one we consider to be in the scope of an ide4ocl functionality, but the second one not; we outsource it like the formal verification. we consider a code generation to several target languages, such as java and sql, to be in the scope of an mde tool (model driven engineering), which obtains ocl statements and related information from an ide4ocl. in case of a code generator, the execution of the target language code is done by a runtime system independently of an ide4ocl. the generative approach includes two steps: (1) the code for an ocl statement must be generated, most frequently by using templates or transformation rules defined on the metamodel elements for the model and its constraints (mn+1 and mn). (2) the generated code must be woven with the model or application code. another functionality of an mde tool, where input from an ide4ocl can be used, is a transformation of a model into another model defined on another metamodel. a model (mn = m1) is transformed using transformation rules defined on its metamodel (m2). the ocl constraints specified on the model 2 http://www.brucker.ch/projects/hol-ocl/ 3 http://www.key-project.org/ 4 http://pvs.csl.sri.com/ proc. ocl 2009 8 / 15 http://www.brucker.ch/projects/hol-ocl/ http://www.key-project.org/ http://pvs.csl.sri.com/ eceasst are transformed as well. examples for model transformations are uml/ocl to sql schema transformation 5, or uml/ocl to xml/xquery transformation. a similar approach is used for testing. a testing tool generates code based on ocl constraints to verify constraints for objects during software development. typically, ocl constraints are defined on a model (mn = m1) for which a code implementation shall be tested (m0). as already mentioned, our view of the ocl tool landscape is simplified, but it can be easily extended with other tools like model execution tools, e.g. [jzm07] or model simulation tools, e.g. [kdh07] which would communicate with an ide4ocl in monoor bidirectional manner to complete alternative ocl development or ocl usage scenarios. it is important to precisely define scope of responsibilities, information flow and later on required interfaces. 3 requirements based on the domain description provided in the previous section and our experience in tool development, we present the requirements for an ide4ocl: use cases (section 3.1) and features (section 3.2). we based our selection on passive observation of improvement in ocl tool and ide landscape as well as an active participation in ocl tool development. to increase the completeness of the selected features we discussed our selection with our developer teams. 3.1 use cases we distinguished four main use cases (to be realised by ide4ocl, compare fig. 5), namely specification, evaluation and verification of statements and project management. specify statement this is the basic use case of an ide4ocl, where an ocl developer specifies an ocl statement. we consider here the creation of a new statement from the scratch or modification of an existing one. since ocl has a well–defined textual concrete syntax, the requirements for editing ocl expressions are similar to those for editing source code in textual languages. in this use case we consider also such functionality as refactoring, reuse, and debugging, which are described in the feature subsection. evaluate statement a specified statement can be evaluated by an ocl interpreter, which parses and executes the statement defined on the model for the model instance, working on the model and its objects (mn and mn-1). this use case can be performed on request from an ocl developer or from another tool in the ocl tool landscape. as mentioned in section 2.2, we consider the evaluation in form of code generation as an outsourced functionality. verify statement we can consider formal and empirical attempts to verify an ocl specification. the former one, as mentioned in section 2.2, we consider to be outsourced, due to its complexity. the latter one in form of statement testing, should be supported by an ide4ocl. testing is a complementary means to a formal verification. it enables dynamic analysis as opposed to formal verification enabling a statical analysis of hybrid models. however, testing of a 5 http://dresden-ocl.sourceforge.net/ 9 / 15 volume 24 (2009) http://dresden-ocl.sourceforge.net/ requirements analysis for ide4ocl ocl statement is crucial [co09], it is not so well–accepted as testing of programs where it is used as an evaluation and prevention mechanism [gh88]. there are many reasons for testing. in the context of ocl the most important ones are the facts that testing reduces bugs in existing and new features, is good documentation, reduces the cost of change, enables refactoring, defends against other programmers and reduces fear [bc03]. an ide4ocl should at least support testing at the unit test level, i.e. testing of single ocl statements [co09]. manage project for an efficient support of ocl development, especially if one has to deal with big projects, management of all artifacts within a project is required. this use case covers management issues within an ide4ocl and related to communication with other tools. in respect of an ide4ocl, the current status and dependencies between all artefacts as well as navigation between them should be supported. concerning the communication with other tools, fetching and storing artifacts from and to other tools should be supported. 3.2 features elicitation in this subsection we list general and specific features of an ide4ocl focusing on the statement specification use case. to collect general features we use experience with existing successful tools covering different types of textual languages, namely programming and formal ones. the general features are applicable to an ide4ocl as ocl has a manifold character. on the one hand, regarding textual syntax ocl is similar to programming languages and the long term experience with tools supporting work of programmers can be inspiration for development of ocl tools. on the other hand, as it is more formal than programming languages, usually similar difficulties appear as in the formal specification domain, therefore this field can be a further inspiration. to collect specific features (in italics) we based on experience with ocl tool usage and development as well as our involvement in the standardisation process. as we do not want to prioritize features we list them in alphabetical order. the prioritizing of features and completion of the list should be a further discussion topic to become a reference list for development of new ocl tools or improvement of existing ones. association end navigability ocl implementations should support association end navigability independently of the navigability of the underlying association in the model. although navigability (as defined in uml) should not matter for ocl, the ocl specification is sufficiently vague on this point6 that it creates significant problems for ocl implementations that provide such support. proposed improvements for ocl2.17 are important for the pragmatics of ocl as long as the mof metamodels are sufficiently well–formed to avoid ambiguities even if support for navigating non–navigable association ends is available8. autocomplete enables predicting a word or phrase that the user wants to type in without the user actually typing it in completely. not only ocl grammar but also an underlying metamodel has to be included in the autocomplete mechanism. for example, selection or classifiers 6 http://www.omg.org/issues/ocl2-rtf.open.html#issue10825 7 see clause 7.5.3 in http://www.omg.org/cgi-bin/doc?ptc/09-05-02 8 e.g., see https://bugs.eclipse.org/bugs/show bug.cgi?id=194245 proc. ocl 2009 10 / 15 http://www.omg.org/issues/ocl2-rtf.open.html#issue10825 http://www.omg.org/cgi-bin/doc?ptc/09-05-02 https://bugs.eclipse.org/bugs/show_bug.cgi?id=194245 eceasst after typing the context keyword or suggestions for dot and arrow navigations. the point to address accessibility of elements, i.e. developing a well–formed ocl requires a careful check that the references in an ocl expression resolve to accessible elements from the context of that ocl expression. this feature can improve efficiency and ease of editing and additionally provide an error prevention mechanism. auto indentation helps to better convey the structure of code to human readers. in case of ocl, indentation can be used to show the relationship between nested structures. basic editing is a set of features related to editing any kind of text documents, which can be useful when editing ocl statements. in this category the following features can be considered: spell checking, regular expression based find & replace (single or multiple line), encoding and newline conversion, multiple undo/redo, rectangular block selection. these features can improve ease of editing. code folding enables user to selectively hide and display sections of an edited file, which is especially useful in case of editing large files. collaborative editing allows several people to edit a file using different computers. this feature could be also realized as a repository functionality. the advantage of its implementation within an ide4ocl is possibility of team/pair work to enable knowledge transfer (e.g. teacher–student) also in the case of geographically spread developers. debugging, especially a systematic debugging [zel05] is unavoidable and a major economical factor, especially if a language is perceived as difficult to understand so bugs are not obvious. it should support developers in understanding a nature and case of a bug offering functions such as running a statement step by step, breaking a statement to examine the current state, and tracking the values of some variables. additionally, it could enable to modify the state of variables while an ocl statement is interpreted and setting state guards. for traceability, automation and logging of all debugging activities is important. a support of test generation based on debugging activities is an optional functionality. document interface is a set of features supporting editing of multiple documents and it covers support of: multiple instances, single and multiple document window splitting, multiple document overlappable windows, tabbed document interface. it is especially a useful feature while working with hybrid models and enables following relationships between textual and graphical notations. hybrid ocl/mof view should provide an abstract syntax tree and additionally highlight the context of any ocl expression in the mof–based metamodel. the problem of hybrid ocl/mof metamodel view is new and the recent discussions amongst experts at the omg9 indicates that experts could also benefit from better tool support for this hybrid view. macro mechanism enables short sequences of keystrokes and mouse actions to be transformed into other, usually more time–consuming, sequences of keystrokes and mouse actions. 9 http://www.omg.org/issues/issue7364.txt 11 / 15 volume 24 (2009) http://www.omg.org/issues/issue7364.txt requirements analysis for ide4ocl name resolution the environment of an ocl expression defines what model elements are visible and can be referred to an expression [omg06, clause 8.3]. such references often take the form of simple or package–qualified names. however, adequate support for name resolution in ocl may require additional operations extending the metamodel of the domain for name resolution purposes as indicated in the ocl specification for the uml metamodel [omg06, clause 8.3.8]. in fact, the ocl specification is unnecessarily specific regarding the uml as the additional operations would be required of any mof metamodel which includes the metaclasses extended in clause 8.3.8. for example, adequate name resolution for foundational uml (fuml) models 10 would not require the additional operations for state or transition since fuml does not merge the behaviorstatemachines package of the uml superstructure. profiler enables performance analysis using information gathered when an ocl statement/specification is evaluated. in case of programs, it is typically used to determine for which sections of a program it is profitable to make optimization. similarly, it can be used to determine which ocl statements are most frequently evaluated and focus on their optimization. refactoring support for renaming and restructuring entities preserving the original semantics. for full support dependencies between statements must be analyzed to perform series of renaming activities. also, extracting a definition or a template from a statement should be supported to avoid code duplications. reuse support can be realized at different levels. at the same abstraction level ocl code can be reused by composition of statements, template and library import mechanisms. a specification from the upper abstraction level can be reused during development of a specification at a lower level to to ensure correctness of metamodel instantiation (compare [cpp08, feature 2 in section 5]). statement/element browser enables to browse, navigate, or visualize (e.g. as an outline) the structure of an ocl project, including ocl statements, elements and element instances (compare [cpp08, feature 5 in section 5]). statement coverage is used to measure the degree to which an ocl specification has been tested. to implement this feature coverage criteria have to be defined. static statement/specification analysis is the analysis conducted without evaluation of a statement/specification and provides highlighting possible coding errors and metrics in simple cases or proofs of program properties by applications of formal methods. the second option we will consider as to be outsourced. symbol database enables quick and easy location of statements, elements, element instances and so on based on indexing. 10 http://www.omg.org/spec/fuml/, omg document ptc/2008-11-03 proc. ocl 2009 12 / 15 http://www.omg.org/spec/fuml/ eceasst syntax highlighting enables displaying ocl code in different colors and fonts according to the category of terms. as ocl is not a stand alone language, additionally to the ocl grammar, an underlying metamodel should be considered. error highlighting can be considered as a special type of this features, where syntactical errors related to ocl or the metamodel (e.g. unknown classifiers used as a context) are stressed by special type of highlighting. brace matching is also a syntax highlighting feature, which show matching sets of braces to help to navigate through the code and spot any improper matching. those mechanisms can improve readability and is an error prevention mechanism. template support enables definition, usage and management of templates. it is related to refactoring and reuse features. visibility and lexical scoping mof metamodels have complex visibility rules due to the semantics of element/packageimport and packagemerge 11. these rules are particularly confusing because the same package can have two distinct interpretations depending on its role as a source or as a target of a package merge or import relationship. the context– sensitive interpretation of a package has subtle implications for the name resolution of ocl constraints in the context of a package with two distinct interpretations about its extent. 4 conclusions in this paper we presented systematic analysis of requirements for an ide4ocl, which in our opinion can significantly improve pragmatics of ocl. we identified domain concepts, interactions within ocl tools, use cases and features of an ide4ocl from the academic, standardisation and industrial point of view represented by authors and their collaborators experience. to improve results of our requirement analysis we want to discuss our proposal with members of the ocl community (questionnaires12 and interviews). based on their feedback we plan to realise future design steps of an ide4ocl and compare existing tools in respect to the final list of features. our work should also be considered as a first step to integrate the heterogeneous landscape of ocl tools. we hope it to be an inspiration for a cooperation between academic and industrial tool developers, which enables standardisation of exchange protocols between tools and in the long term will increase usage of ocl by practitioners. acknowledgement we would like to thank dan chiorean for his feedback on our work and inspiring discussions during his visits in innsbruck and dresden. furthermore, we thanks our colleagues from the dresden ocl developer team, especially michael thiele, for discussing features for an ide4ocl. 11 clause 7.3.15,39,40 of http://www.omg.org/spec/uml/2.2/superstructure/pdf, omg document formal/2009-0202 12 on–line surveys are accessible at http://squam.info/ide4ocl/ 13 / 15 volume 24 (2009) http://www.omg.org/spec/uml/2.2/superstructure/pdf http://squam.info/ide4ocl/ requirements analysis for ide4ocl bibliography [ack01] j. ackermann. fallstudie zur spezifikation von fachkomponenten. in 2. workshop modellierung und spezifikation von fachkomponenten. pp. 1–66. bamberg, deutschland, 2001. (in german). [b+05] t. baar et al. tool support for ocl and related formalisms needs and trends. in models satellite events. lncs 3844, pp. 1–9. springer, 2005. http://lgl.epfl.ch/members/baar/oclwsatmodels05/reportoclwsatmodels05.pdf [bc03] e. burke, b. coyner. top 12 reasons to write unit tests. 2 2003. http://www.onjava.com/pub/a/onjava/2003/04/02/javaxpckbk.html [bd07] m. bräuer, b. demuth. model-level integration of the ocl standard library using a pivot model with generics support. pp. 182–193 in [mod07]. [bhs07] b. beckert, r. hähnle, p. h. schmitt (eds.). verification of object-oriented software: the key approach. lncs 4334. springer-verlag, 2007. [bjo06] d. bjorner. software engineering 2: specification of systems and languages (texts in theoretical computer science. an eatcs series). springer-verlag new york, inc., secaucus, nj, usa, 2006. [bks02] b. beckert, u. keller, p. h. schmitt. translating the object constraint language into first–order predicate logic. in in proceedings, verify, workshop at federated logic conferences (floc). pp. 113–123. 2002. [bru07] a. d. brucker. an interactive proof environment for object-oriented specifications. phd thesis, eth zurich, mar. 2007. eth dissertation no. 17097. http://www.brucker.ch/bibliography/abstract/brucker-interactive-2007 [bw08] a. d. brucker, b. wolff. hol-ocl: a formal proof environment for uml/ocl. in fase. lncs 4961, pp. 97–100. springer, 2008. [c+07] a. l. correa et al. an empirical study of the impact of ocl smells and refactorings on the understandability of ocl specifications. pp. 76–90 in [mod07]. [c+08] j. chimiak-opoka et al. advanced ocl editor based on eclipse ocl. presentation in the ocl2008 workshop collocated with models’2008, 9 2008. [co09] j. chimiak-opoka. ocllib, oclunit, ocldoc: pragmatic extensions for the object constraint language. in model driven engineering languages and systems, models 2009, lncs 5795. pp. 665–669. springer verlag, 2009. [cpp08] d. chiorean, v. petrascu, d. petrascu. how my favorite tool supporting ocl must look like. ec-easst: ocl concepts and tools 2008 15, 2008. [dem86] w. deming. out of the crisis. mit, center for advanced engineering, cambridge, ma, usa, 1986. proc. ocl 2009 14 / 15 http://lgl.epfl.ch/members/baar/oclwsatmodels05/reportoclwsatmodels05.pdf http://www.onjava.com/pub/a/onjava/2003/04/02/javaxpckbk.html http://www.brucker.ch/bibliography/abstract/brucker-interactive-2007 http://squam.info/ocleditor/ http://squam.info/ocleditor/media/2008-09-30-oclworkshopdemo.html http://www.fots.ua.ac.be/events/ocl2008/?page=program http://www.irit.fr/models/index.html http://http://joanna.opoki.com/papers/opoka2009oclliboclunitocldoc http://www.springerlink.com/ http://eceasst.cs.tu-berlin.de/ http://eceasst.cs.tu-berlin.de/index.php/eceasst/issue/view/22 eceasst [dw09] b. demuth, c. wilke. model and object verification by using dresden ocl. in proceedings of the russian-german workshop innovation information technologies: theory and practice. ufa, russia, july 2009. [gh88] d. gelperin, b. hetzel. the growth of software testing. commun. acm 31(6):687– 695, 1988. doi:http://doi.acm.org/10.1145/62959.62965 [jzm07] k. jiang, l. zhang, s. miyake. ocl4x: an action semantics language for uml model execution. computer software and applications conference, annual international 1:633–636, 2007. doi:http://doi.ieeecomputersociety.org/10.1109/compsac.2007.158 [kdh07] a. kirshin, d. dotan, a. hartman. a uml simulator based on a generic model execution engine. pp. 324–326. 2007. http://dx.doi.org/10.1007/978-3-540-69489-2 40 [kya06] m. kyas. verifying ocl specifications of uml models : tool support and compositionality. phd thesis, lehmanns media; faculty of mathematics and natural sciences, leiden university, 4 2006. https://openaccess.leidenuniv.nl/dspace/handle/1887/4362 [mod07] model driven engineering languages and systems, 10th int. conf., models 2007, nashville, usa, proceedings. lncs 4735. springer, 2007. [omg06] omg. object constraint language. omg available specification. version 2.0. may 2006. http://www.omg.org/cgi-bin/doc?formal/2006-05-01 [rg99] m. richters, m. gogolla. a metamodel for ocl. in uml. lncs 1723, pp. 156–171. springer, 1999. [sb08] uml-intensive framework for modeling software requirements. 2008. [sb09] d. silingas, r. butleris. towards implementing a framework for modeling software requirements in magicdraw uml. information technology and control 38(2):153 – 164, 2009. [sk95] k. slonneger, b. kurtz. formal syntax and semantics of programming languages: a laboratory based approach. addison-wesley, 1995. [zel05] a. zeller. why programs fail: a guide to systematic debugging. morgan kaufmann, october 2005. 15 / 15 volume 24 (2009) http://dx.doi.org/http://doi.acm.org/10.1145/62959.62965 http://dx.doi.org/http://doi.ieeecomputersociety.org/10.1109/compsac.2007.158 http://dx.doi.org/10.1007/978-3-540-69489-2_40 https://openaccess.leidenuniv.nl/dspace/handle/1887/4362 http://www.omg.org/cgi-bin/doc?formal/2006-05-01 introduction domain specification domain concepts ocl concepts modeling abstraction levels ocl development concepts context specification requirements use cases features elicitation conclusions flexible modeling of emergency scenarios using reconfigurable systems electronic communications of the easst volume 12 (2008) formal modeling of adaptive and mobile processes flexible modeling of emergency scenarios using reconfigurable systems k. hoffmann, h. ehrig, j. padberg 20 pages guest editors: julia padberg, kathrin hoffmann managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst flexible modeling of emergency scenarios using reconfigurable systems k. hoffmann1, h. ehrig, j. padberg institute for software technology and theoretical computer science technical university of berlin, germany abstract: in emergency scenarios we can obtain a more effective coordination among team members constituting a mobile ad hoc network (manet) through the use of reconfigurable systems. this means that cooperative work can be adequately modeled by low level and high level petri nets with initial markings and the net structure can be adapted to new requirements of the environment during run time by a set of rules. in this paper we give main requirements for flexible processes in manets and show how to realize them using the formal notions of reconfigurable systems. the main part presents a case study in the area of emergency management and demonstrates the advantages of our approach which allows the dynamic adaption of processes in mobile environments. in this context we also discuss the main results achieved for reconfigurable systems and outline some interesting aspects of future work. keywords: mobile ad hoc network, reconfigurable system, petri net, rule based transformation, algebraic higher order net 1 introduction as the adaptation of systems to changing environments gets more and more important processes that can be modified at run time have become a significant topic in the recent years especially in the area of mobile ad hoc networks (manets). manets are networks of mobile devices that communicate with one another via wireless links without relying on an underlying infrastructure e.g. as in emergency/disaster scenarios where an effective coordination is crucial among teams and team members to stabilize the situation and reduce the probability of secondary damage as well as to provide emergency assistance for victims. as noticed in the context of the research project workpad2 the situation in such scenarios is complicated by the fact that the common goal is reached by different teams belonging to different organizations. moreover each team member should carry on specific activities while the different teams collaborate through the interleaving of all the different processes. normally processes in mobile environments are not fixed once and for all at build time but constantly adapted at run time e.g. to predict situations of disconnection or to restructure specific parts and activities. 1 this work has been partly funded by the research project formalnet (see tfs.cs.tu-berlin.de/formalnet/) of the german research council. 2 www.workpad-project.eu 1 / 20 volume 12 (2008) tfs.cs.tu-berlin.de/formalnet/ www.workpad-project.eu flexible modeling of emergency scenarios using reconfigurable systems for the effective coordination among teams and team members a suitable process definition language is desirable that supports an adequate modeling of processes and their modifications. but as recognized e.g. in the context of the graduate school metrik3 the workflow oriented view on processes in emergency/disaster scenarios is a novel line of research and up to now there exists only a few approaches especially designed for such an application area. in [hem05, phe+07, ehpp07, ekpe07, bhp07] the rule based approach of reconfigurable place/transition (p/t) systems is introduced, so that the modification of processes is realized at run time by a set of rules. the formalism of algebraic higher order systems follows the paradigm ”nets and rules as tokens” and represents a meta model for reconfigurable p/t systems where process execution and process modification is distinguished by the use of specific transitions. this paper is organized as follows: in section 2 we give a characterization of main requirements for flexible processes in emergency/disaster scenarios in order to review the formal notions and results of reconfigurable systems in section 3 and compare them with the listed requirements. to demonstrate the advantages of our approach we illustrate in section 4 reconfigurable systems by a case study in the area of pipeline emergencies. finally in section 5 we conclude with a discussion of some interesting aspects of future work. 2 flexible processes in manets this section presents a characterization of main requirements for flexible processes in emergency/disaster scenarios. based on the fundamental requirements for process definition languages called perspective in [aww03] these perspectives are improved to fit in our intended application area. summarizing a process definition language should cover the process perspective, informational perspective, organizational perspective, functional perspective, and operational perspective [aww03]. the process perspective concentrates on the control flow, i.e. the start conditions and the order of activities that have to be executed. the workflow management coalition4 identifies some basic types of relationship between activities: sequential, parallel, conditional, and iterative routing. following the approach in [kfp06] in a completely decentralized system as in manets each activity could be in addition in one of the following states : • received: a start conditions has arrived from the previous team member and is waiting until all conditions are true and the current team member is available to start running it. • initiated: a new process instance has just started, this is where the team member starts it because all start conditions are true. • running: the team member is running the activity. • aborted: the team member failed to complete the activity either because the team member is disconnected or for any other reason. • completed: the team member completed the activity. • on-hold: the activity is completed but the next team member is not available yet to receive his/her start conditions. 3 metrik.informatik.hu-berlin.de/grk-wiki 4 www.wfmc.org adaptive and mobile processes 2 / 20 metrik.informatik.hu-berlin.de/grk-wiki www.wfmc.org eceasst • rejected: the team member rejects to complete the given activity. moreover in a mobile environment movement activities concerning the network connectivity can be separated from activities concerning the intended process. the informational perspective concentrates on the data flow, so that data dependencies between activities are characterized by input and output parameters. on the one hand control data is used for process management purposes and on the other hand production data subsumes information objects like documents, questionnaires and forms. in manets information about the geographic area is especially important e.g. to localize positions of team members or to predict situations of disconnection. the organizational perspective is typically defined by roles, groups and other artifacts clarifying organizational issues. because in emergency/disaster scenarios different teams belong to different organizations, the inter-organizational aspect should be respected. in addition, in manets the network topology typically represented as topology graphs [az03] both influences and is influenced by the process. the functional perspective prescribes the decomposition of a process into smaller units often represented by a hierarchical structure. finally, the operational perspective depends on the technical environment, so that elementary operations are performed by resources and applications. based on the observation in [kfp06] in a mobile environment the team member can be on line, i.e. he/she can receive new work, or off line, where the team member is not available to receive new work. in this case new activities may be on hold until the team member returns on line or even allocated to alternative team members. team members before permanently leave may notify this otherwise the team leader may decide to treat any other team member failing to respond as permanent. for activities where the team member is temporarily off line, the execution of the process will continue, if possible. in this case when the team member returns some synchronization may be required or alternatively the execution will have to wait until the team member returns. from a practical point of view processes in manets often have to be restructured e.g. because of unforeseen events or to maintain the network connectivity resulting in a highly dynamical modification of processes. in [aww03] three issues to dynamic change of processes are addressed. by constrained flexibility certain properties should be preserved during process adaption while instance change refers to the modification of process instances at run time. finally instance migration are based on simultaneous changes of both process schemes and process instances. in addition dynamic changes are grouped into ad hoc changes, i.e. changes are responses to unforeseen exceptions, and pre-planned and evolutionary changes, i.e. changes are known at build time (see e.g [aww03, rrd04]). besides others in [smo00, ros07] a minimal set of change operations are characterized: • inserting a new activity where also bridging actions may be used to keep network connectivity, • removing an existing activity, • modifying the order of activities, and 3 / 20 volume 12 (2008) flexible modeling of emergency scenarios using reconfigurable systems • modifying activity properties like data requirements, underlying applications, temporal constraints, resource allocation, or reassignment of activities from one team or member to another. processes have to be analysed (see e.g. [aww03]) for verification purposes, so that some form of correctness criteria, i.e. different properties on a syntactical and/or semantical level, has to be satisfied and can be checked. in contrast validation verifies processes with respect to the intended and typically informally formalised process and performance analysis is realized by simulating processes to detect e.g. potential deadlocks or livelocks. . 3 reconfigurable systems in this section we compare reconfigurable systems with the requirements listed in the last section and present the results achieved for reconfigurable place/transition (p/t) systems in [hem05, phe+07, ehpp07, ekpe07, bhp07]. a p/t system is a p/t net with an initial marking. p/t nets, p/t systems and their variants are an established process definition language (see e.g. [ell79, vda03]) providing constructs of the process perspective. while p/t nets represent process schemes, p/t systems describe the behavior of process instances due to their initial markings. activities are modeled by transitions while the control flow is reflected by arcs between places and transitions. places can be seen as pre and post conditions for activities and source places with an empty pre domain can be used as start condition for the process. the workflow patterns initiative5 [ahkb00] presents a number of patterns for the relationship between activities following not only the basic types identified by the workflow management coalition but also more advanced constructs. the concept of reconfigurable p/t systems was introduced for modeling changes of the net structure by rule based transformations while the system is kept running. for rule based transformations of p/t systems we use the framework of net transformations [eept06, ehpp07] following the double pushout (dpo) approach of graph transformation systems [roz97]. the basic idea behind net transformation is the stepwise development of p/t systems by given rules. think of these rules as replacement systems where the left hand side is replaced by the right hand side while preserving a context. in reconfigurable p/t systems not only the follower marking can be computed but also the net structure can be changed by rule applications and we obtain new p/t systems that are more appropriate with respect to some requirements of the environment. in detail a reconfigurable p/t system ((pn1, m1), ru les) consists of a p/t system (pn1, m1), where pn1 is a p/t net with initial marking m1, and a set of rules ru les. rules and transformations in the dpo approach are based on morphisms preserving on the one hand firing steps and requiring on the other hand that the initial marking at corresponding places is increasing or even stronger. an application of a rule is called a transformation step and describes how an object is actually changed by the rule. in general a rule prod = ((l, ml) l← 5 www.workflowpatterns.com adaptive and mobile processes 4 / 20 www.workflowpatterns.com eceasst (k, mk ) r→ (r, mr)) is given by three p/t systems called left hand side, interface and right hand side, respectively, and a span of two p/t morphisms l and r. we additionally need a match morphism (l, ml) m→ (pn1, m1) that identifies the relevant parts of the left hand side (l, ml) in the p/t system (pn1, m1). now a direct transformation (pn1, m1) (prod,m) =⇒ (pn2, m2) via prod ∈ru les and m can be constructed in two steps. we delete in a first step those elements from (pn1, m1) which are identified by the match m but not preserved by the interface (k, mk ) leading to the intermediate p/t system (pn0, m0). in a second step we glue together the p/t systems (pn0, m0) and (r, mr) along the interface resulting in the new p/t system (pn2, m2). the dpo approach does not allow the treatment of unmatched transitions at places which should be deleted. in this case the so called gluing condition forbids the application of rules. furthermore items which are identified by a non injective match must be preserved by rule applications. note that a positive check of the gluing condition makes sure that the intermediate p/t system is well defined. the rule based approach of reconfigurable p/t systems supports dynamic changes in the sense that the concept of instance change is formalised by the application of appropriate rules realising the insertion of new activities, removing of existing activities or changing the order of activities. because rules are fixed at build time the concept of reconfigurable p/t system supports pre-planned and evolutionary changes. to support constraint flexibility the set of rules can be restricted to property preserving rules [pu03], so that safety and liveness properties are preserved by rule applications. the main result in [ehpp07] concerns the formal foundation for transformations of p/t systems based on the framework of adhesive high level replacement (hlr) systems [eept06, ehpp06]. adhesive hlr systems have been recently introduced as a new categorical framework for graph transformation in the dpo approach. they combine the well known framework of hlr systems with the framework of adhesive categories introduced in [ls05]. the main concept behind adhesive categories are the so called van kampen squares. these ensure that pushouts along monomorphisms are stable under pullbacks and, vice versa, that pullbacks are stable under combined pushouts and pullbacks. note that a pushout can be seen as a gluing construction of two objects over a specific interface, while a pullback is dual to a pushout in the sense that a pullback construction extracts the common part of two objects. in the case of adhesive hlr categories the class of all monomorphisms is replaced by a subclass of monomorphisms closed under composition and decomposition. within the framework of adhesive hlr systems there are many interesting results concerning the applicability of rules, the embedding and extension of transformations, parallel and sequential dependence and independence, and concurrency of rule applications. the concept of parallel independence states that two transformation steps are not in conflict while two consecutive transformation steps are sequentially independent if they are not causally dependent. provided that the relevant conditions are satisfied two alternative transformation steps may be swapped and each of them can still be applied after the other has been performed. since we have shown in [ehpp07] that p/t systems form a weak adhesive hlr category, we can apply these results to reconfigurable p/t systems. based on the observation of parallel and sequential independence of rule applications the main results in [ekpe07] deals with conflict situations between transformation and token firing. the 5 / 20 volume 12 (2008) flexible modeling of emergency scenarios using reconfigurable systems p2 : rules n transformation m : mor cod m = n applicable(r, m) = tt ntoken game enabled(n,t) =tt t : transitions (aho system-sig,a) r fire(n,t) transform(r, m) p1 : system figure 1: algebraic higher order system traditional concurrency situation in p/t systems without capacities is that two transitions with overlapping pre domain are both enabled and together require more tokens than available in the current marking. as p/t systems can evolve in two different ways the notions of conflict and concurrency become more complex. assume that a given p/t system represents a certain system state. the next evolution step can be obtained not only by token firing but also by the application of one of the rules available. hence the question arises whether each of these evolution steps can be postponed after the realization of the other, yielding the same result, and if they can be performed in a different order without changing the result. in [ekpe07] we have presented conditions for (co-)parallel and sequential independence and we have shown that in specific cases firing and transformation steps can be performed in any order, yielding the same result. we have correlated these conditions, i.e. that parallel independence implies sequential independence and, vice versa, sequential (coparallel) independence implies parallel and coparallel (parallel and sequential) independence. the advantage of the presented conditions is that they could be checked at a syntactical and local level instead of semantical and global one. thus they are also applicable in the case of complex reconfigurable p/t systems. in [hem05] we have introduced the paradigm ”nets and rules as tokens” by a high level model with suitable data type part. the model called algebraic higher order (aho) system exploits some form of control not only on rule application but also on token firing. in general an aho system is defined by an algebraic high level net [per95] with system places and rule places as for example shown in fig. 1 where a marking can be given by suitable p/t systems and rules, respectively, on these places. for a detailed description of the data type part, i.e. the aho system-signature and corresponding algebra a, we refer to [hem05]. in the following we review the behavior of aho systems according to [hem05]. with the symbol var(t) we indicate the set of variables of a transition t, i.e. the set of all variables occurring in preand post domain and in the firing condition of t. the marking m determines the distribution of p/t systems and rules in an aho system which are elements of a given higher order algebra a. intuitively p/t systems and rules can be moved along aho system arcs and can be modified during the firing of transitions. the follower marking is computed by the evaluation of net inscriptions in a variable assignment v : var(t) → a. the transition t is enabled in a marking m, if and only if (t, v) is consistent, that is if the evaluation of the firing condition is fulfilled. then the follower marking after firing of transition t is defined by removing tokens corresponding to the net inscription in the pre domain of t and adding tokens corresponding to the net inscription in the post domain of t. the transitions in the aho system in fig. 1 realize on the one hand firing steps and on the other hand transformation steps as indicated by the net inscriptions f ire(n,t) and trans f orm(r, m), adaptive and mobile processes 6 / 20 eceasst respectively. to compute the follower marking of p/t systems we use the transition token game of the aho system while the transition transformation is provided for changing the structure of p/t systems. in this way process execution and process modification is distinguished by these two transitions. the pair (or sequence) of firing and transformation steps discussed in [ekpe07] is reflected by firing of the transitions one after the other in our aho system. thus these results are most important for the analysis of aho systems. using p/t systems as tokens aho systems focus on the process perspective. to integrate the informational perspective we can use high level nets as tokens themselves, i.e. the data type part is extended by algebraic high level nets and corresponding rules. analogously the organizational and operational perspectives can be added following e.g. the approach in [aw01]. so activity properties like data requirements and the reassignment of activities from one team member to another can be modified by the applications of suitable rules. for the functional perspective the formalism of aho systems can be adapted using the hierarchy concept of coloured petri nets (see [jen96]). to consider ad hoc changes of processes the modification of rule tokens requires an extension not only of the data type part but also of the net structure as introduced in [hpm05], so that the definition of new rules by reusing existing rules is supported at run time by different operations like inheritance [pp01]. while the aho system in fig. 1 deals with one layer for reconfigurable p/t systems, in [phe+07] we follow the observation that processes in manets consists of different aspects. thus we separate movement activities from general activities and allow a local view of team members. this leads to an aho system with different layers each of them equipped with its own p/t system and set of rules. moreover the notion of layer consistent environment states that the views in each layer fit together realizing one form of instance migration. in [bhp07] we extend this approach to allow the introduction of new team members by more advanced changes at each layer. because reconfigurable p/t systems and aho systems are formalized on a rigorous mathematical foundation and have a clear formal semantics, several results as described above are provided to analyse systems in the sense of formal verification. these results present a line of research and there is a large amount of most interesting and relevant open questions directly related to the work presented here. we plan to develop a tool to support simulation and analysis aspects for our approach. for the application of net transformation rules this tool will provide an export to agg6, a graph transformation engine as well as a tool for the analysis of graph transformation properties like termination and rule independence. furthermore the token net properties could be analyzed using the petri net kernel [kw01], a tool infrastructure supporting different petri net classes. 4 emergency/disaster scenario in this section we illustrate the main idea of reconfigurable systems by a case study of a pipeline emergency scenario where an unknown source of a natural gas leak is detected in a residential 6 tfs.cs.tu-berlin.de/agg 7 / 20 volume 12 (2008) tfs.cs.tu-berlin.de/agg flexible modeling of emergency scenarios using reconfigurable systems area7: a postal worker delivering mail in a residential street smells a strong odor of gas. she immediately notifies the fire department. a single engine company is dispatched by the fire department with four firefighters leaded by one company officer. at the scene the postal worker meets the company officer and describes the problem. he calls the gas company and requests an additional law enforcement officers to control traffic into the area. while three firefighters evacuate the homes in the immediate area and afterwards deny entry to this area, another one reads the gas indicator and detects that the gas is highest in front of a home located on 114 maple street. after electricity and gas lines are shut off to each home the fire department stand by with fully charged hose lines and wait for the arrival of the gas company. the cooperative process enacted by the firefighter company is depicted as p/t system (pn1, m1) in fig. 2. to start the activities of the firefighter team the follower marking of the p/t system (pn1, m1) is computed by firing the and-split-transition and we obtain the new p/t system (pn1, m′1) in fig. 3. next we focus on dynamic changes while the process is running. the three firefighters responsible for the evacuation process need more detailed information how to proceed. so the company officer gives the instruction that first of all the residents are notified of the evacuation. afterwards the firefighters should assist handicapped persons and guide all of them to the extend possible. to introduce the refinement of the evacuate homes-transition into the p/t system (pn1, m′1) we provide the rule prodevacuate in fig. 4. the marking ml1 of the p/t system in the left hand side of prodevacuate demands that the evacuation process is not yet started because there is one token in the pre domain of the evacuate homes-transition. the application of the rule is given as follows: the match morphism m1 is given by the obvious inclusion and identifies the relevant parts of the left hand side (l1, ml1 ) of rule prodevacuate in (pn1, m ′ 1); next, the evacuate homes-transition is deleted and we obtain an intermediate p/t system (pn0, m0); then, the transitions notify residents, assist handicapped persons and guide persons together with their (new) environment are added leading to the p/t system (pn2, m2) in fig. 5. thus we obtain the transformation step (pn1, m′1) (prodevacuate,m1)=⇒ (pn2, m2). afterwards the firefighter company proceed with their activities and we obtain the p/t system (pn2, m′2) in fig. 6 by firing the corresponding transitions. after the problem identification the odor of gas grows stronger and the firefighter takes an additional reading of the gas indicator and informs the company officer about the result, so that the company officer is able to determine if the atmosphere in the area is safe, unsafe, or dangerous. to extend our process by these additional activities we use the rule prodanalyse in fig. 7 where the marking ml2 in the left hand side indicates that the problem location is identified. by the application of the rule we obtain the transformation step (pn2, m′2) (prodanalyse,m2) =⇒ (pn3, m3) where the new p/t system (pn3, m3) is depicted in fig. 8. based on the additional results of the gas indicator the company officer analyses that the atmosphere in this area is over the lower explosive limit and thereby more dangerous than expected. he determines that the best course of action is to call for additional resources to maintain the isolation perimeter and expand the area of evacuation as a precaution. so, in a next step the follower marking of the p/t system (pn3, m3) is computed by firing the additional readingand analyse7 www.pipelineemergencies.com adaptive and mobile processes 8 / 20 www.pipelineemergencies.com eceasst reading the gas indicator deny entry identify the location gas is highest shut off electricity and gas lines stand by with fully charged hose lines waiting for the arrival of the gas company call the gas company request to control traffic into the area evacuate homes in the immediate area (pn1, m1) figure 2: process (pn1, m1) 9 / 20 volume 12 (2008) flexible modeling of emergency scenarios using reconfigurable systems transitions leading to the p/t system (pn3, m′3) in fig. 9. afterwards the rule prodex pand depicted in fig. 10 is applied to the p/t system (pn3, m′3) resulting in the new p/t system (pn4, m4) in fig. 11. summarizing, at the beginning our reconfigurable p/t system consists of the p/t system (pn1, m1) in fig. 2 and the set of rules depicted in figs. 4, 7 and 10. let the reconfigurable p/t system be the initial marking of the aho system in fig. 1, i.e. the p/t system (pn1, m1) is on the place p1 while the marking of the place p2 is given by the set of rules. to compute the follower marking of the p/t system we use the transition token game of the aho system. first the variable n is assigned to the p/t system (pn1, m1) and the variable t to the and-split-transition that is enabled, so that the firing condition is fulfilled. due to the evaluation of the term f ire(n,t) we obtain the new p/t system (pn1, m′1) in fig. 2. for changing the structure of p/t systems the transition transformation is provided in fig. 1. again we have to give an assignment v for the variables of this transition, i.e. variables n, m and r, where v(n) = (pn1, m′1), v(m) = m1 is a suitable match morphism and v(r) = prodevacuate (see fig. 4). the firing condition cod m = n ensures that the codomain of the match morphism is equal to (pn1, m′1) while the second condition applicable(r, m) checks the gluing condition, i.e. if the rule prodevacuate is applicable with match m1. afterwards the transformation step is computed by the evaluation of the net inscription trans f orm(r, m) and the effect of firing the transition transformation is the removal of the p/t system (pn1, m′1) from place p1 and adding the p/t system (pn2, m2) in fig. 5 to it. analogously we proceed with the computation of the follower markings and dynamic adaption of our process as described above. after several firing steps of the transitions token game and transformation we obtain the reconfigurable p/t system consisting of the p/t system (pn4, m4) (see fig. 11) and the original set of rules. to analyse the reconfigurable p/t systems we apply the results presented in [ekpe07] and described in the previous section. for example the transformation step (pn1, m′1) (prodevacuate,m1)=⇒ (pn2, m2) is parallel independent of the firing step given by the reading gas indicator-transition because the transition is not deleted by the transformation step and the marking of the p/t system (pn1, m′1) is unchanged by the application of the rule prodevacuate. moreover the pair of transformation and firing steps is sequentially independent because the reading gas indicator-transition is not created by the transformation step. thus the pair of steps may be swapped and each of them can be applied after the other has been performed leading to the same result. in the context of our aho system in fig. 1 this observation is reflected by an independent firing of the transitions token game and transformation, i.e. the sequential firing of these transitions leading to the same result independent of the order these transitions are fired. the pair of consecutive steps given by firing the and-split-transition in (pn1, m1) and the transformation (pn1, m′1) (prodevacuate,m1)=⇒ (pn2, m2) is sequentially dependent because the marking of the left hand side of prodevacuate demands a token in the pre domain of the evacuate homestransition. further situations of independent and dependent firing and transformation steps are illustrated in fig. 12 where, however, the traditional concurrency situation of transitions and transformations, respectively, is not shown. note that e.g. the two consecutive transformations (pn1, m21 ) (prodevacuate,m1)=⇒ (pn2, m22 ) and (pn2, m 2 2 ) (prodanalyse,m2) =⇒ (pn3, m23 ) are sequentially indeadaptive and mobile processes 10 / 20 eceasst reading the gas indicator call the gas companyevacuate homes in the immediate area (pn1, m′1) figure 3: relevant part of process (pn1, m′1) persons notify residents of the evacuation guide persons to the extend possible the immediate area evacuate homes in assist handicapped (k1, mk1 )(l1, ml1 ) (r1, mr1 ) figure 4: rule prodevacuate pendent because the overlapping of the right hand side of prodevacuate and the left hand side of prodanalyse in (pn2, m22 ) is included in the intersection of the interfaces. 5 conclusion in this paper we have given main requirements for flexible processes in emergency/disaster scenarios in order to show that most of them are realized by reconfigurable systems, a rule based formalism based on the one hand on low level and high level petri nets with a suitable marking and on the other hand on the categorical framework of weak adhesive high level replacement systems. as future work, it would be important to investigate and verify additional requirements necessary for flexible processes in emergency/disaster scenarios and mobile environments. the main part of this paper presents the case study in the area of pipeline emergencies where 11 / 20 volume 12 (2008) flexible modeling of emergency scenarios using reconfigurable systems persons reading the gas indicator call the gas company identify the location gas is highest deny entry shut off electricity and gas lines stand by with fully charged hose lines waiting for the arrival of the gas company request to control traffic into the area notify residents of the evacuation guide persons to the extend possible assist handicapped (pn2, m2) figure 5: process (pn2, m2) adaptive and mobile processes 12 / 20 eceasst gas is highest deny entry request to control traffic into the area shut off electricity and gas lines identify the location (pn2, m′2) figure 6: relevant part of process (pn2, m′2) the gas indicator additional reading shut off electricity and gas lines analyse resultsshut off electricity and gas lines (k2 , mk2 ) (r2 , mr2 )(l2 , ml2 ) figure 7: rule prodanalyse 13 / 20 volume 12 (2008) flexible modeling of emergency scenarios using reconfigurable systems persons reading the gas indicator call the gas company deny entry identify the location gas is highest the gas indicator additional reading shut off electricity and gas lines request to control traffic into the area analyse results stand by with fully charged hose lines waiting for the arrival of the gas company notify residents of the evacuation guide persons to the extend possible assist handicapped (pn3, m3) figure 8: process (pn3, m3) adaptive and mobile processes 14 / 20 eceasst deny entry identify the location gas is highest the gas indicator additional reading shut off electricity and gas lines request to control traffic into the area analyse results (pn3, m′3) figure 9: relevant part of process (pn3, m′3) call for additional ressources expand the area of evacuation (l3 , ml3 ) (r3 , mr3 )(k3 , mk3 ) figure 10: rule prodex pand 15 / 20 volume 12 (2008) flexible modeling of emergency scenarios using reconfigurable systems persons reading the gas indicator call the gas companynotify residents of the evacuation guide persons to the extend possible deny entry expand the area of evacuation stand by with fully charged hose lines waiting for the arrival of the gas company identify the location gas is highest the gas indicator additional reading shut off electricity and gas lines request to control traffic into the area analyse results call for additional ressources assist handicapped (pn4, m4) figure 11: process (pn4, m4)adaptive and mobile processes 16 / 20 eceasst (pn1, m1) and-split �� dependent (pn1, m′1) (prodevacuate,m1)+3 reading gas indicator �� (pn2, m2) reading gas indicator �� (pn2, m11 ) (prodevacuate,m1)+3 identify the location �� (pn2, m12 ) dependent identify the location �� (pn1, m21 ) (prodevacuate,m1)+3 call the gas company �� (pn2, m22 ) call the gas company �� (prodanalyse,m2) +3 (pn3, m23 ) call the gas company �� (pn1, m31 ) (prodevacuate,m1)+3 request to control traffic �� (pn2, m32 ) request to control traffic �� (prodanalyse,m2) +3 (pn3, m33 ) request to control traffic �� (pn1, m41 ) dependent (prodevacuate,m1)+3 (pn2, m42 ) notify residents �� (prodanalyse,m2) +3 (pn3, m43 ) notify residents �� (pn2, m52 ) assist handicapped persons �� (prodanalyse,m2) +3 (pn3, m53 ) assist handicapped persons �� (pn2, m62 ) guide persons �� (prodanalyse,m2) +3 (pn3, m63 ) guide persons �� (pn2, m72 ) deny entry �� (prodanalyse,m2) +3 (pn3, m73 ) deny entry �� (pn2, m′2) dependent (prodanalyse,m2) +3 (pn3, m3) additional reading �� (pn3, m13 ) analyse results �� dependent (pn3, m′3) (prodex pand ,m3) +3 (pn4, m4) figure 12: independence and dependence of firing and transformation steps 17 / 20 volume 12 (2008) flexible modeling of emergency scenarios using reconfigurable systems dynamic changes of the process are realised at run time by rule applications to express the refinement and insertion of activities. note that our processes focus on the intended activities and exclude movement activities because the network connectivity is assured due to the limited perimeter of the affected area and the use of cell phones and radio devices. nevertheless, the scenario could be extended in such a way that the problem is located beyond the range of these equipment and several team members have to follow other ones to avoid a situation of disconnection. one aspect of future work is integration of the informational and organizational perspectives into our formalism because within our case study these aspects become most relevant. in fact process modifications in our case study depend on the exchange of messages and data concerning a detailed instruction of the evacuation process, the results of reading the gas indicator and the final analysis of these results by the company officer. in addition the processes enacted by the gas company and the law enforcement officer have to be taken into account, so that the different teams collaborate through the interleaving of all the different processes to achieve the common goal. bibliography [vda03] w. van der aalst. the application of petri nets to workflow management. journal of circuits, systems and computers 8(1):21–66, 2003. [ahkb00] w. van der aalst, a. ter hofstede, b. kiepuszewski, a. barros. workflow patterns. in proc. cooperative information systems (coopis). lncs 1901, pp. 18–29. springer, 2000. [aw01] w. m. p. van der aalst, m. weske. the p2p approach to interorganizational workflows. in proc. advanced information systems engineering (caise). lncs 2068, pp. 140–156. springer, 2001. [aww03] w. van der aalst, m. weske, g. wirtz. advanced topics in workflow management: issues, requirements, and solutions. journal of integrated design and process science 7(3), 2003. [az03] d. agrawal, q. zeng. introduction to wireless and mobile systems. thomson brooks/cole, 2003. [bhp07] e. biermann, k. hoffmann, j. padberg. layered architecture consistency for manets: introducing new team members. in proc. integrated design and process technology (idpt). 2007. [eept06] h. ehrig, k. ehrig, u. prange, g. taentzer. fundamentals of algebraic graph transformation. eatcs monographs in theoretical computer science. springer, 2006. [ehpp06] h. ehrig, a. habel, j. padberg, u. prange. adhesive high-level replacement systems: a new categorical framework for graph transformation. fundamenta informaticae 74(1):1–29, 2006. adaptive and mobile processes 18 / 20 eceasst [ehpp07] h. ehrig, k. hoffmann, u. prange, j. padberg. formal foundation for the reconfiguration of nets. technical report 2007-01, technical university berlin, fak. iv, 2007. [ekpe07] h. ehrig, j. p. k. hoffmann, u. prange, c. ermel. independence of net transformations and token firing in reconfigurable place/transition systems. in proc. application and theory of petri nets (atpn). lncs 4546, pp. 104–123. springer, 2007. [ell79] c. ellis. information control nets: a mathematical model of office information flow. in proc. simulation, measurement and modelling of computer systems. pp. 225–240. acm press, 1979. [hem05] k. hoffmann, h. ehrig, t. mossakowski. high-level nets with nets and rules as tokens. in proc. application and theory of petri nets (atpn). lncs 3536, pp. 268–288. springer, 2005. [hpm05] k. hoffmann, f. parisi-presicce, t. mossakowski. higher-order nets for mobile policies. in workshop on petri nets and graph transformation (pngt). electronic notes in theoretical computer science 127, pp. 87–105. elsvier, 2005. [jen96] k. jensen. coloured petri nets. basic concepts, analysis methods and practical use. eatcs monographs in theoretical computer science. springer, 1996. [kfp06] e. kyriacou, g. fakas, v. pavlaki. a completely decentralized workflow management system for the support of emergency telemedicine and patient monitoring. in proc. ieee embs annual international conference. 2006. [kw01] e. kindler, m. weber. the petri net kernel an infrastructure for building petri net tools. software tools for technology transfer 3(4):486–497, 2001. [ls05] s. lack, p. sobocinski. adhesive and quasiadhesive categories. theoretical informatics and applications 39(5):511–546, 2005. [pp01] f. parisi-presicce. on modifying high level replacement systems. electronic notes in theoretical computer science 44(2), 2001. [per95] j. padberg, h. ehrig, l. ribeiro. algebraic high-level net transformation systems. mathematical structures in computer science 5:217–256, 1995. [phe+07] j. padberg, k. hoffmann, h. ehrig, t. modica, e. biermann, c. ermel. maintaining consistency in layered architectures of mobile ad-hoc networks. in proc. fundamental approaches to software engineering (fase). lncs 4422, pp. 383–397. springer, 2007. [pu03] j. padberg, m. urbasek. rule-based refinement of petri nets: a survey. in advances in petri nets: petri net technologies for modeling communication based systems. lecture notes in computer science 2472, pp. 161–196. springer, 2003. 19 / 20 volume 12 (2008) flexible modeling of emergency scenarios using reconfigurable systems [ros07] f. d. rosa. adaptive process management in mobile and dynamic scenarios. phd thesis, sapienza universita di roma, department of computer science, 2007. [roz97] g. rozenberg. handbook of graph grammars and computing by graph transformations, volume 1: foundations. world scientific, 1997. [rrd04] s. rinderle, m. reichert, p. dadam. correctness criteria for dynamic changes in workflow systems a survey. data knowl. eng. 50(1):9–34, 2004. [smo00] s. sadiq, o. marjanovic, m. orlowska. managing change and time in dynamic workflow processes. journal of cooperative information systems 9(12), 2000. adaptive and mobile processes 20 / 20 introduction flexible processes in manets reconfigurable systems emergency/disaster scenario conclusion model checking c++ with exceptions electronic communications of the easst volume 70 (2014) proceedings of the 14th international workshop on automated verification of critical systems (avocs 2014) model checking c++ with exceptions p. ročkai, j. barnat and l. brim 15 pages guest editors: marieke huisman, jaco van de pol managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst model checking c++ with exceptions p. ročkai∗, j. barnat and l. brim faculty of informatics, masaryk university brno, czech republic {xrockai,barnat,brim}@fi.muni.cz abstract: we present an extension of the divine software model checker to support programs with exception handling. the extension consists of two parts, a language-neutral implementation of the llvm exception-handling instructions, and an adaptation of the c++ runtime for the divine/llvm exception model. this constitutes an important step towards support of both the full c++ specification and towards verification of real-world c++ programs using a software model checker. additionally, we show how these extensions can be used to elegantly implement other features with non-local control transfer, most importantly the longjmp function in c. keywords: model checking, c++, exception handling, llvm 1 introduction widespread and regular use of formal verification methods in the general software development is one of the major goals in computer science. as a matter of fact, recent formal method research trends put a strong emphasis on direct practical applicability of verification results. a current example of this trend is the activity in the program analysis community and the software verification competition [bey14]. the strong drive to make formal method applications approachable by the general software development and engineering community highlights the fact that the most important factor of using formal methods in practice is their ease of use. hence, formal methods must be applied at a level that software engineers and developers naturally work at – that is, in an overwhelming majority of cases, at the source code level. there are multiple reason for this: not only working with program source code is natural for a software developer, source code also constitutes very precise notation, which is a natural match for a formal system. while it is true that semantics of programming languages are usually not rigorously specified, they do often attain a very high level of precision in their specifications. the main inconvenience of specifications of languages like c++ lies in the large volume of text, and consequently, large amount of facts. nevertheless, the complex natural-language specs have a formal counterpart: compilers. while a c++ compiler is a very complex software system, the fact is that real-world compilers achieve an enviable level of agreement in their semantics, despite numerous optimisation passes they all implement. consequently, there is a natural tendency to build model checkers that can be applied to programs written in commonly-used languages: most importantly c, c++ and java. clearly, there ∗ petr ročkai has been partially supported by red hat, inc. 1 / 15 volume 70 (2014) model checking c++ with exceptions are limitations to what a model checker can do: the problem it is tackling is, in general, firmly undecidable. in theory, this is a huge red flag – we are trying to solve a problem that we know for a fact cannot be solved. nevertheless, a partial solution can still be immensely useful: after all, a software engineer often has to argue about properties of programs that are in general undecidable. in this case, all that matters is whether the instance at hand can be solved. there is however another limitation, which is usually more important in practice: conformance to programming language specifications. in order to derive substantial utility from a model checker, it should implement a full programming language specification: the programs that software developers write and that they can run should be also valid inputs to a model checker. this is especially critical if we expect a seamless integration of model checking tools into a development workflow. the brunt of the problem at hand is that programming languages as specified are already very constraining – engineers in pursuit of more elegant and more maintainable code already skirt the boundaries of what is allowed in a particular programming language. introducing substantial constraints to enable model checking is, in many cases, a non-starter.1. this is especially a concern with c++, which is a relatively high-level language, with a long development history and widespread use. some of the features the language offers are rather unpalatable (especially so in the model checking community), usually because they exhibit very complex semantics. while some of the problematic aspects can be conjured away by targeting a suitable intermediate language and hijacking a good existing compiler frontend – such as llvm [la04] (the ir) and its companion clang (the frontend) – this is not the case with all such the features. a particularly hairy example is exception handling, which necessarily finds its way into the intermediate representation. besides their complicated semantics, which are already a formidable problem, they bring an entirely new phenomenon to model checking: non-local transfer of control. while not unapproachable, it complicates everything – and a modern software model checker is already complicated enough. it is easy to see how tempting it is to constrain the input language of the model checker to disallow exceptions. however, for the reasons expounded earlier, we firmly believe that it is very important to provide full coverage of language features in a model checker. this paper primarily presents our experience in implementing exception handling in divine, an explicit-state model checker for c and c++ programs based on llvm. 2 preliminaries divine [bbh+13] is a general-purpose explicit-state model checker for safety and ltl properties. for ltl model checking, it uses an automata-based approach [vw86], reducing the decision procedure to a graph problem – namely detection of an accepting cycle in the state space graph of a program under verification. in order to tackle large graphs, it implements efficient parallel algorithms for both reachability (for safety verification) and accepting cycle detection (for ltl 1 clearly, there are specialised projects where programming language semantics need to be severely constrained, whether it is due to formal treatment – this is sometimes the case with mission-critical software – or due to limitations of the hardware platform, a situation most often encountered in the embedded systems space. nevertheless, in the latter category, increases in hardware capabilities of embedded systems is apt to reduce this gap between embedded and mainstream general-purpose programming. proc. avocs 2014 2 / 15 eceasst model checking). implementations tailored for both shared-memory and distributed-memory parallel computers are available, along with an assortment of memory-saving techniques. for more recent results in the field of parallel and distributed model checking, see e.g. [elpp12]. among other input languages, divine can handle programs written in llvm intermediate representaion (llvm ir). the main use-case for explicit-state model checking, and especially ltl model checking in this area is for unit testing of parallel programs. while explicit-state model checking per se (without the aid of some form of abstraction) cannot handle arbitrary io behaviour, this is something that software engineers deal with all the time – testing cannot do that either. of course, an ideal solution would overcome this problem as well – but we contend that this is not a serious obstacle in pragmatic use. however, there are two interesting things that an explicit-state model checker can do (and where testing struggles): asynchronous lock-based parallelism (which is an ubiquitous concern in contemporary c++ programming) and liveness (ltl) checking. moreover, since llvm is quickly becoming the lingua franca of software analysis tools [mfs12, cde08], it is not unconceivable that an explicit-state model checker would be integrated into a larger abstraction/cegar-based decision procedure, in order to tackle the open-world angle in program verification. now if we have a model checker that can handle llvm ir as its input, and a compiler frontend that can translate c++ into llvm ir (and there are at least two such compilers, clang and gcc) – we can compile c++ programs to ir (bitcode) and run a model checker on it. this appears to be very easy on the surface of it, but there are hidden complexities. first, in order to actually verify a program, it needs to be fully defined: in basically all cases, programs make use of the c and c++ standard libraries. especially the c++ standard library constitutes a very substantial amount of code, and we cannot reasonably argue about program correctness if we don’t include this code. the libraries in turn make use of system-level apis (in the cases we are interested in, this is mostly posix), which are fortunately fairly constrained and small, compared to the standard libraries themselves. as we have argued above in section 1, constraining the language that can be used with the model checker is an option of last resort, as it has substantial impact on its usefulness. a good way to approach this problem is to compile the libraries themselves into bitcode and bundle them with the program’s own bitcode, to form a nearly fully-defined llvm program. the missing system-level apis can be either provided as stubs (a practice commonly used in testing), or in some cases – where they constitute important part of program functionality – implemented in terms of a small number of model-checker provided primitives. to this end, divine provides an implementation of both the c and c++ standard libraries, including the small number of changes required for compatibility with the different system-level api implemented by divine. the overall structure of the libraries, with emphasis on exception handling (see also section 3 for more details on this) is illustrated in figure 1. 3 exception handling exception handling is an area where code generation needs to co-operate in order to implement correct language semantics. since code generators are part of llvm, but llvm itself is programming-language-agnostic, the llvm code generators need to provide a sufficiently generic 3 / 15 volume 70 (2014) model checking c++ with exceptions __divine_landingpad __divine_unwind memory managment common components unwind tables exception handlers landing pads threading, etc... user's c++ source code divine llvm verification the standard c library system (os, cpu, ...) exception handling divine c++ runtime llvm ir execution stack unwinder personality function c++ runtime support libunwind the standard c++ library verifiable bitcode source code dwarf unwind tables exception handlers cleanup handlers binary __cxa_throw_divine personality function __cxa_throw __cxa_begin_catch __cxa_end_catch figure 1: the various components involved in exception handling, and their interaction with execution and verification. the source code is first compiled using a suitable c++ frontend (clang or gcc) into llvm ir. when building a binary for execution, the ir code is fed to a code generator and combined with common components (the standard c and c++ libraries), and with execution-specific components: libunwind and execution-specific parts of the c++ runtime support library (the personality routine and the libunwind-based stack unwinder). for verification purposes, the llvm ir is instead combined with those same common components that have been converted into intermediate representation, and with verification-specific runtime functions from the divine c++ runtime. the resulting bitcode file is then fed to divine, using its llvm subsystem to generate the state space and execute a suitable verification algorithm on that state space. proc. avocs 2014 4 / 15 eceasst interface to allow implementation of efficient exception handling. in all modern c++ compilers, zero-cost exceptions are the norm: the exception handling machinery imposes no overhead at all unless an exception is actually thrown. this means that the code generator is not allowed to insert special instructions for calls or for saving context when entering try blocks. in order to allow this sort of behaviour, all exception handling logic needs to happen at an exception throw time, and for this to be possible, a stack unwinder is required. the unwinder is platform-specific, and needs to understand the particular abi and most importantly the layout of the program stack and individual stack frames. llvm itself does not provide an unwinder library: it is usually provided by the operating system. unfortunately, the interface of the unwinder library is not entirely specified, and as such, it is also somewhat platform-specific. there are two major surfaces of the unwinder, each exposed to different part of the compiler/standard library duo. on one hand, the unwinder needs unwind tables in order to correctly unwind the stack. these unwind tables are generated by llvm, since they reflect the high-level structure of individual stack frames, which is itself generated by llvm. these tables end up being a part of the program text, i.e. they are stored in the executable image, and are as such a static part of the program. on the other hand, there is the “dynamic”, or runtime, interface of the unwinder library, which is exposed to the language runtime instead: when an exception is raised, the language runtime uses the unwind library and the unwind tables generated by llvm to guide the exception handling process. while c++ is the primary target of the exception-handling mechanisms in llvm, care has been taken to make it sufficiently general to accommodate other language runtimes, as long as their exception handling works along the same general principles. the main requirement for an exception system to be compatible with llvm is that it can use the same unwinder interface, or at very least that it can process the unwind tables produced by llvm. on many platforms (all modern unix systems based on the elf executable format), these unwind tables are in a standardised format, mandated by the dwarf specification [dwa10]. other platforms use different unwind tables, though. besides information about the structure of a stack frame, unwind tables contain information about how exception handling should process this particular stack frame. in programming languages with lexical scoping, lexically scoped variables cease to exist when their scope terminates: normally, this happens when a function returns. however, exceptions create a new way in which a lexical scope can cease to exist, namely that an exception is propagated through this scope upwards. as long as lexically scoped (local) variables are sufficiently simple (plain old data in c++ terminology), this is not a major problem: the stack is unwound, so the storage associated with those variables is automatically reclaimed. however, c++ and a number of other languages allows scoped variables of complex types, with associated destructors: code that the runtime guarantees is executed just before the variable is deallocated. particularly in c++, this is widely used to implement reliable, automatic resource acquisition and release2. even though similar schemes have been proposed for c [tur], they are usually implemented using setjmp and longjmp primitives, do not use any compiler support and therefore do not map to the llvm 2 in the c++ community, this design pattern is known as raii: resource acquisition is instantiation. among other things, it is used to safely hold mutual exclusion locks, dynamically allocated memory and other non-composable resources inside functions that could experience non-local loss of control due to exceptions. 5 / 15 volume 70 (2014) model checking c++ with exceptions exception handling mechanism. nevertheless, llvm as such has no concept of destructors, nor does the unwinder library. the language compiler needs to generate cleanup handlers, i.e. blocks of code that take care of calling any appropriate destructors, or performing other language-specific cleanup when a stack frame is torn down because the stack is being unwound. moreover, the same mechanism is used for exception handlers: the main difference is that an exception handler stops the propagation of an exception, and its role is to deal with the exceptional situation: exception handlers correspond to the catch blocks attached to a try block. in order to improve efficiency (at the expense of simplicity) of the unwinder, it has a concept of exception type: different types of exceptions can happen, and a particular catch block can handle only a subset of those exception types. each call-site in each call frame possibly contains a cleanup handler, and a list of exception handlers. deciding whether a particular exception handler can handle a particular exception type is deferred to a personality function: a languagespecific callback provided to the unwinder. this personality function helps the unwinder decide, among other things, which handler to invoke for a particular exception type. 3.1 mapping exceptions to llvm now that we have established the basics of how exceptions are implemented in general, we will look at how those concepts map to llvm. the machinery provided by llvm to handle exceptions consists of 3 instructions: invoke, landingpad and resume. the invoke instruction is like a call instruction, but it provides extra provisions for exception propagation: unlike call, it is a terminator instruction, i.e. it is always last in a basic block. it is also a branching instruction: it takes two basic block addresses as parameters corresponding to two branches – the first is taken upon a normal return from the function, the other is taken if an exception has been raised in the callee. the invoke instruction co-operates tightly with the landingpad instruction: the basic block that the exception branch of invoke points to must begin (after any possible ϕ instructions) with a landingpad instruction, and the entire basic block is called a landing block3. the landingpad instruction then encodes the list of exception handlers and whether there is a cleanup handler present, and which personality function to invoke for the corresponding callsite (invoke instruction). the syntax of the landingpad instruction is following: = landingpad personality + = landingpad personality cleanup * := catch := filter if the landing block is a cleanup one, the stack unwinder always transfers control to the landing block during the unwinding process, regardless of any exception handlers. if the landing block is 3 in upstream llvm documentation, what we call a “landing block” here is referred to as a “landing pad”. the reason for this departure is that the original terminology makes it easy to confuse “landingpad” as an instruction and “landing pad” as a basic block. proc. avocs 2014 6 / 15 eceasst not a cleanup landing block, it is only executed if some catch clause in the landingpad instruction matches the exception type (as decided by the provided personality function).4 since each invoke instruction only has a single landing block associated, this landing block is responsible for handling any and all catch clauses of the higher-level programming language covering the particular callsite. the return value of the landingpad instruction is crucial in deciding what action to take when the landing block is entered, and corresponds to the return value of the personality function. in other words, when the unwinder executes the personality function (which is part of the language runtime), it stores its return value, and provides this return value in the result of the landingpad instruction. since the personality function has access to the part of the unwind tables generated from the landingpad instruction, it can communicate information encoded in the unwind table to the landing block itself. in the libc++ runtime, the personality function returns a tuple consisting of a pointer to the exception object itself, and a “handler switch value”, an integer which corresponds to the index of a relevant “catch” clause of the landingpad instruction, or a special value (-1) when no catch clauses match but a cleanup needs to be performed. the code generated for the landing block then checks the handler switch value computed by the personality function, and transfers control to a cleanup or handler block accordingly. finally, if the selected handler is a cleanup handler, the exception propagation (stack unwinding) needs to be resumed after the cleanup is done. this is achieved by the resume instruction, which expects as a parameter the same value that was returned by the corresponding landingpad instruction which interrupted the exception propagation. interestingly, there are no llvm instructions for raising (throwing) exceptions. this is left entirely in the management of the language runtime, which needs to closely co-operate with the stack unwinding library anyway (the interface of the personality function is mandated by the stack unwinder). 4 c and c++ runtime support in divine as we have argued in section 2, in order to verify real-world code, we need to provide an implementation of standard libraries: divine provides libc, in form of bitcode that can be linked to (incomplete) bitcode produced by the compiler from the c program itself. while the implementation of libc is mostly complete, in some respects, it behaves differently from traditional os-provided versions. since the program that is being verified is not allowed to actually interact with the world, such function calls are implemented either as “stubs” possibly using non-deterministic choice, or they interact with divine using a private divine-specific interface. the case of c++ is slightly more complicated. while many language features require no special runtime support (i.e. the same as c), there are some that do, most notably run-time type identification (rtti) and exception handling. besides those areas where library support code is required for language features, like in c, most c++ programs make use of the standard 4 additionally, the filter clauses restrict the types of exceptions that can be propagated through the invoke instruction corresponding to this landing block, akin to how exception specifiers work in c++. if an exception is thrown and it reaches a filter clause of the appropriate type, a language-specific action is invoked. in c++, this action is userspecified, and defaults to terminating the program. 7 / 15 volume 70 (2014) model checking c++ with exceptions c++ library. consequently, there are two libraries that are required by virtually all c++ programs: the runtime support library, and the standard library. multiple implementations of both exist5 – divine ships with libc++abi for the runtime portion and libc++ for the stdlib portion. as far as rtti goes, there are no special considerations with regards to model checking. the upstream libc++abi code can be used verbatim with divine. exceptions are more complicated, and are, coincidentally, a feature that is most often neglected in analysis tools and model checkers that work with c++ programs. exception handling in c++ consists of three major parts: unwind tables, landing pads and exception handlers which are all generated by the compiler based on the input code, using special (although language-neutral) llvm instructions: invoke and landingpad being the two most notable. additionally, the c++ runtime library uses a cpuand platform-specific stack unwinder and contains a language-specific personality routine. the personality routine makes use of the unwind tables generated by the compiler to guide the stack unwinder during an exception (see section 3 for details). an llvm interpreter hence needs to provide a stack unwinder and an api to access the unwind tables, for use by the personality routine. in divine, the unwinder interface is extremely simple, consisting of a single trap, divine unwind. the language runtime can use divine unwind to remove a number of topmost stack frames from the stack of the current thread, returning control to the topmost remaining frame. if the active instruction in the target frame is an invoke instruction, control is transferred to its alternate destination basic block (a landing block), and the value passed to divine unwind is passed on to the personality routine of the landing block. 5 implementation we have outlined the mechanisms used by llvm to implement language-agnostic exception handling in sections 3 and 3.1. there are multiple points where divine has to hook into those mechanisms in order to support exception handling in a particular programming language. while a substantial part of that support is language-agnostic, crucial pieces of infrastructure are part of the language’s standard library: in case of c++, this is libc++abi as explained in section 4. in a native code generator in llvm, the information from landingpad instructions generated in the frontend is used to construct unwind tables. the format of those tables is platformand architecturespecific. to read those tables, libc++abi uses the libunwind interface (originally specified as part of the ia64 c++ abi). this interface is semi-standard, but no actual standardising document exists. since the libunwind implementation is tied to the binary format of the executable, via the in-memory image of the unwind tables, it cannot be directly used in divine. likewise, it is tied to a specific architecture/platform via its knowledge of stack and register layout – another disqualifying feature. therefore, libunwind needed to be replaced with a new implementation for divine. 5 the gnu compilers ship with libstdc++, which contains, as a subproject a runtime support library libsupc++. clang ships with libc++. depending on platform, a choice of either libc++abi or libcxxrt is available for use with libc++. an independent implementation is available from apache software foundation under the name libcxx. multiple compilers ship yet different implementations. proc. avocs 2014 8 / 15 eceasst struct r1 { r1() { /* ... */ } ˜r1() { /* ... */ } }; struct rc { r1 r1; int *resource; rc() : r1() { resource = new int[32]; } ˜rc() { delete[] resource; } }; int main() { try { rc res; // work with the resource... } catch (...) { // handle exceptions } } figure 2: example source code, for illustrating exception handling mechanisms. see figures 3 and 4. 5.1 the libunwind interface there were two basic options: either replicate the portion of the libunwind interface used by libc++abi, making it possible to use unmodified source for libc++abi – which sits on a higher level than libunwind. conceptually, this is a tempting solution – the more of the library code is left intact, the more faithful the verification. there is a major downside though: the interface between libunwind and libc++abi is complex and intricate. this is especially true of the interface between the unwinder and the personality function: the unwinder uses the personality function as a callback, invoking it once for each active frame on the stack at the moment an exception is raised. the personality function uses a pair of platform-specific registers to pass the handler switch value and the exception pointer to the exception handler: it cannot invoke the handler itself, as the stack has not been unwound yet and the handler would end up running in the wrong context. for this reason, libunwind provides an interface to splice register values into the context of the exception handler to be invoked.6 it would be in principle possible to implement this interface in divine system space: each thread would need two special thread-local variables to hold these values, and the landingpad instruction would simply read those values and copy them into appropriate llvm registers. the downside is extra space overhead – 16 bytes per thread, allocated even if no exceptions are currently active.7 6 this is clearly implemented in a platform-specific fashion. if the registers are always saved on the stack, their stack images will be rewritten. if they are clobber-type registers, they can be written to directly and the unwinder will take care not to clobber them before transferring control to the selected exception handler. other options may be available depending on platform. 7 those 16 bytes could be compressed away in most cases to a single bit, at expense of code complexity. however, system-space complexity is very costly, and complexity involved in addressing the state vector even more so. 9 / 15 volume 70 (2014) model checking c++ with exceptions __divine_landingpad__divine_landingpad __gxx_personality__gxx_personality main()main() rc::rc()rc::rc() operator newoperator new __cxa_throw__cxa_throw __divine_unwind__divine_unwind main()main() rc::rc()rc::rc() operator newoperator new __cxa_throw__cxa_throw main()main() rc::rc() [cleanup]rc::rc() [cleanup] main()main() rc::rc()rc::rc() operator newoperator new __cxa_throw__cxa_throw __divine_landingpad__divine_landingpad main()main() rc::rc() [cleanup]rc::rc() [cleanup] r1::~r1()r1::~r1() main()main() main() [catch]main() [catch] rc::rc() [cleanup]rc::rc() [cleanup] figure 3: example of an exception-handling process as it happens in the divine runtime (see figure 2 for the source code). the situation at the top of the flowchart corresponds to an outof-memory condition in the program. constructor of class rc was trying to obtain dynamic memory (using operator new), but the allocation request has failed. as a result, operator new is throwing an exception – the throw statement in the c++ source code of the implementation is translated to a cxa throw call, which uses cxa throw divine to unwind the stack. the unwinder first uses divine landingpad to find an exception handler (which it finds in the call frame of the main() function, and any intervening cleanup handlers (there is one in the rc constructor itself). the unwinder proceeds to call the personality routine to obtain a handler switch value and passes the result to divine unwind, along with the address of the first cleanup handler. divine unwind removes stack frames up to the cleanup handler, which takes control and calls a destructor of the locally constructed r1 instance. finally, when done, the cleanup handler invokes the resume instruction which continues the propagation up the stack, to the exception handler (the catch block in main()). proc. avocs 2014 10 / 15 eceasst _unwind_raiseexception_unwind_raiseexception __unwind_raiseexc...__unwind_raiseexc... main()main() rc::rc()rc::rc() operator newoperator new __cxa_throw__cxa_throw main()main() rc::rc()rc::rc() operator newoperator new __cxa_throw__cxa_throw main()main() rc::rc() [cleanup]rc::rc() [cleanup] main()main() rc::rc() [cleanup]rc::rc() [cleanup] r1::~r1()r1::~r1() main() [catch]main() [catch] main()main() rc::rc() [cleanup]rc::rc() [cleanup] __gxx_personality__gxx_personality __gxx_personality__gxx_personality main()main() rc::rc() [cleanup]rc::rc() [cleanup] _unwind_resume_unwind_resume __gxx_personality__gxx_personality figure 4: example of an exception-handling process as it happens in the standard libc++abi process on 64-bit linux (see figure 2 for the source code and figure 3 for comparison with divine). the situation at the top of the flowchart corresponds to an out-of-memory condition in the program – as a result, operator new is throwing an exception – the throw statement in the c++ source code of the implementation is translated to a cxa throw call. the cxa throw implementation then calls into libunwind – the unwind raiseexception function in particular. at this point, libunwind takes over control, looping over active stack frames. each frame is examined by calling the personality routine with a ua search phase flag, in the context of the throw statement. in this phase, an exception handler is identified, but the stack is not yet unwound. in the next phase, the stack is actually unwound, and again, each frame is examined by a call to the personality routine. if a cleanup handler or the selected exception handler is found, it is invoked by returning urc install context to libunwind (otherwise, urc continue unwind indicates that unwinding should continue with the next frame). cleanup handlers return control to libunwind by invoking unwind resume. 11 / 15 volume 70 (2014) model checking c++ with exceptions another downside is that this limits flexibility: while the llvm exception mechanism is made to play nice with libunwind, it is flexible enough, at least in theory, to admit another approach to stack unwinding. using this approach would mean changing the divine system space to accommodate a different landingpad return type. while this api/abi issue has reasonable solutions, there is a more important issue at play. while libunwind understands the platform-specific portions of unwind tables, it provides no support for parsing the language-specific chunks. this means that libc++abi code itself has abi-specific knowledge of the unwind table layout, needed to extract the exception type info and switch values. all libunwind does here is provide a pointer to the lsda (languagespecific data area) portion of the unwind table for a given stack frame. in order to support this libc++abi code in its literal form, divine would have to synthesise dwarf-formatted8 lsda areas from landingpad instructions. this is unpleasant, because it is a complex format designed for space efficiency, and the encoded tables are completely c++ specific, even specific to c++ on a particular platform. the only reasonable way to provide such tables would be to leverage pieces of the existing x86 (or x86-64) code generator to synthesise the lsda tables. llvm, however, does not provide an interface to this functionality. 5.2 divine-specific unwinding api both these issues in mind, we have chosen a different approach, which requires modifications to libc++abi, but can be implemented with just 2 new system-space builtins – one for querying metadata encoded in landingpad instructions, based on a stack frame reference ( divine landingpad) and another for actually unwinding the stack ( divine unwind). this clearly requires some changes in libc++abi: one is the personality function, and the other is the actual cxa throw implementation: a call to this function is inserted by the c++ compiler at the site of a throw statement (along with some support code). while in the original libc++abi implementation, the personality function bears most of the burden (since libunwind does the stack search, calling out to the personality function as needed), this is reversed in the divine implementation. here, the personality function merely extracts the correct items from the exception header to pass on to the exception handler. the cxa throw implementation, on the other hand (and unlike in the libunwind version) unwinds the stack itself using divine landingpad. this builtin does not change anything, but provides the caller with landingpad metadata, using a simple integer indexing of stack frames. negative indices start at the top of the stack, non-negative at the bottom. this makes it easy for the unwinder to walk through the stack one frame at a time, looking for an appropriate handler. when the handler is found, it can call the personality function (pointer to which is part of the landingpad metadata) and pass it to divine unwind along with the frame address it obtained from calling divine landingpad. the job of divine unwind is then simple enough: destroy all the frames above the one addressed and transfer control to the landing block associated with the active invoke instruction in the now-topmost stack frame. divine unwind also takes care of copying the value it obtained from its caller (in this case the return value of the personality 8 dwarf is a companion format to encode debug and other metadata in elf executable images. a backronym “debugging with attributed record format” has been invented for it. proc. avocs 2014 12 / 15 eceasst function) into the result of the corresponding landingpad instruction. the implementation of divine landingpad takes advantage of the implicit garbage collection done by divine, as it allocates the metadata block on heap. since the block is neither flagged as a result of an alloca instruction, nor as a result of divine malloc, it is transparently retained as long as necessary without being flagged by the interpreter as a memory leak. 5.3 setjmp and longjmp the c functions setjmp and longjmp can be used for non-local transfer of control, in a way somewhat similar to c++ exceptions. in fact, some c programs use those two semi-standard functions to implement somewhat crude exception handling in c. the purpose of the setjmp function is to save enough of the machine state to allow non-local transfer of control to the point in program where setjmp was called. the longjmp partner then, using a context saved by the setjmp call, restores the corresponding machine state. the state is exactly the same as it was right after setjmp call returned for the first time, with one exception: the return value of the setjmp call is altered in its second return, to make it possible to detect whether the return was a “normal” return or a longjmp return. clearly, exception handling based on setjmp/longjmp cannot be “zero-cost” – state has to be explicitly saved at the start of every try block, and possibly before any resource acquisition. the latter problem can be side-stepped by maintaining a separate “resource” stack [tur], but even then, entering try blocks is fairly expensive. nevertheless, robust c programs may choose this style of exception handling, since the runtime overhead can be outweighed by the programming benefits – especially due to fewer and simpler error paths to write, maintain and test. finally, there are other uses for longjmp in programs, besides exceptional situations. while longjmp is not nearly as widely used as c++ exceptions are, the reasons for supporting this primitive are similar, even if somewhat weaker. fortunately, the primitives we have designed for c++ exception handling can be easily re-used in implementing setjmp and longjmp – since divine unwind can just as easily stop at a call instruction as it can on an invoke instruction, we only need minor extensions to the divine landingpad/ divine unwind mechanism. the main difference between exceptions and longjmp is how the control flow at the point of setjmp is handled. the divinespecific implementation of setjmp needs to be able to find out the program counter value of its enclosing frame, corresponding to the call instruction. this can be done by slightly extending divine landingpad, to provide the program counter value for call instructions in the stack (this does not alter the semantics of divine landingpad for invoke instructions in any way). finally, divine unwind needs to be extended as well, to allow the caller to specify where to restart the execution in the target frame – since longjmp is not above the corresponding setjmp in the call stack, a successful longjmp needs to change the program counter in the target frame, in addition to unwinding. luckily, this is fairly easy, since the divine unwind caller can specify the program counter corresponding to the callsite to unwind to. for normal c++ exceptions, the caller just puts in a 0, meaning no program counter adjustment (i.e. the semantics stay exactly the same) and longjmp passes in the program counter value obtained from a divine landingpad call done by the setjmp function. 13 / 15 volume 70 (2014) model checking c++ with exceptions 6 case studies besides the simple fact of making model checking possible on a substantially wider class of programs, exceptions themselves are an interesting subject for model checkers: error paths are notoriously hard to test. with a model checker, however, it is easy to insert non-deterministic failures and check that the program behaves sensibly under all sorts of error conditions. resource leaks are among the most common errors encountered in error paths, which makes the problem even harder to debug – resource leaks, especially memory leaks, require special tools to diagnose in a test, such as valgrind. since divine can already diagnose memory leaks in llvm inputs, checking error paths involving exceptions becomes a fairly easy task. however, error paths can contain more serious errors as well – especially in multi-threaded programs, where threads are not isolated from the effects of other threads failing to handle an exception, and the entire program may crash. among the first issues that we have found using our new exception support in divine is such a crash, in std::thread implementation in libc++, under out-of memory conditions.9 when a new thread is created using this standard c++ interface, most of its state is allocated in the newlycreated thread, before user code is executed. since this allocation can fail with an exception, and the libc++ implementation fails to install an exception handler in the context of this newlycreated thread, the exception cannot be caught. in such cases, the c++ standard document requires the runtime library to call an “unexpected exception handler”, which, unless overriden by the user, terminates the application. in order to fix this problem, we have moved the memory allocation code into the calling thread. to avoid synchronisation problems and possible resource leaks, this happens before the new thread is created – the calling thread allocates all the dynamic state for the new thread and passes it down as a parameter. this way, any exceptions related to resource exhaustion happen in the calling thread, in a context where users can control the scope and propagation of exceptions by wrapping the call to the thread constructor in a suitable catch block. 7 conclusions we have shown how to extend an explicit-state software model checker based on llvm with support for exception handling, with focus on c++ exceptions. to ensure the viability of the approach described in the paper, we have created an implementation as part of the divine model checker. additionally, we have used this implementation to verify properties of c++ programs that make use of exceptions (either directly or via the standard library) and in the process found an exception-related bug in the libc++ implementation of std::thread. to the best of our knowledge, this makes divine the first model checker to be able to verify c++ code with exceptions10. the main contributions of the paper are twofold: first, the description of c++ and llvm exception handling mechanisms in the context of model checking, and 9 the proposed patch that fixes the problem can be found in http://llvm.org/bugs/show bug.cgi?id=15638 and the relevant source code in the file libc++/std/thread. 10 according to [rfs+13], the esbmc++ tool also supports c++ exceptions. unfortunately, it appears that this support is so far largely theoretical: the current version (1.23) produces a spurious counterexample on a simple test case, taking a path through the code which disregards the fact that an exception has been raised. proc. avocs 2014 14 / 15 http://llvm.org/bugs/show_bug.cgi?id=15638 eceasst second the implementation derived from it: all relevant source code is freely available as part of the current divine distribution. bibliography [bbh+13] j. barnat, l. brim, v. havel, j. havlı́ček, j. kriho, m. lenčo, p. ročkai, v. štill, j. weiser. divine 3.0 – an explicit-state model checker for multithreaded c & c++ programs. in computer aided verification (cav 2013). lncs 8044, pp. 863– 868. springer, 2013. [bey14] d. beyer. status report on software verification (competition summary sv-comp 2014). in tools and algorithms for the construction and analysis of systems (tacas 2014). lncs 8413, pp. 373–388. springer, 2014. [cde08] c. cadar, d. dunbar, d. r. engler. klee: unassisted and automatic generation of high-coverage tests for complex systems programs. in 8th usenix symposium on operating systems design and implementation, (osdi 2008). pp. 209–224. usenix association, 2008. [dwa10] dwarf debugging information format committee. dwarf debugging information format version 4. 2010. http://dwarfstd.org/ [elpp12] s. evangelista, a. laarman, l. petrucci, j. van de pol. improved multi-core nested depth-first search. in automated technology for verification and analysis (atva 2012). lncs 7561, pp. 269–283. springer, 2012. [la04] c. lattner, v. adve. llvm: a compilation framework for lifelong program analysis & transformation. in international symposium on code generation and optimization (cgo). palo alto, california, mar 2004. [mfs12] f. merz, s. falke, c. sinz. llbmc: bounded model checking of c and c++ programs using a compiler ir. in proceedings of the 4th international conference on verified software: theories, tools, experiments. vstte’12, pp. 146–161. springerverlag, 2012. [rfs+13] m. ramalho, m. freitas, f. sousa, h. marques, l. cordeiro, b. fischer. smt-based bounded model checking of c++ programs. in proceedings of the 20th annual ieee international conference and workshops on the engineering of computer based systems. ecbs ’13, pp. 147–156. ieee computer society, washington, dc, usa, 2013. [tur] d. turner. robust design techniques for c programs. http://freetype.sourceforge.net/david/reliable-c.html [vw86] m. vardi, p. wolper. an automata-theoretic approach to automatic program verification. in ieee symposium on logic in computer science. pp. 322–331. computer society press, 1986. 15 / 15 volume 70 (2014) http://dwarfstd.org/ http://freetype.sourceforge.net/david/reliable-c.html introduction preliminaries exception handling mapping exceptions to llvm c and c++ runtime support in divine implementation the libunwind interface divine-specific unwinding api setjmp and longjmp case studies conclusions modelling and analysing the interactive behaviour of an infusion pump electronic communications of the easst volume 45 (2011) proceedings of the fourth international workshop on formal methods for interactive systems (fmis 2011) modelling and analysing the interactive behaviour of an infusion pump josé creissac campos, michael d. harrison 16 pages guest editors: judy bowen, steve reeves managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst modelling and analysing the interactive behaviour of an infusion pump josé creissac campos1, michael d. harrison2 1 jose.campos@di.uminho.pt departamento de informática/cctc, universidade do minho, braga, portugal 2 michael.harrison@ncl.ac.uk school of computing science, newcastle university, claremont tower newcastle upon tyne, ne1 7ru, uk abstract: this paper is concerned with the scaleable and systematic analysis of interactive systems. the motivating problem is the procurement of medical devices. in such situations several different manufacturers offer solutions that support a particular clinical activity. apart from cost, which is a dominating factor, the variations between devices are relatively subtle and the consequences of particular design features are not clear from manufacturers’ manuals, demonstrations or trial uses. despite their subtlety these differences can be important to the safety and usability of the device. the paper argues that formal analysis of the range of offered devices can provide a systematic means of comparison. the paper also explores barriers to the use of such techniques, demonstrating how layers of specification may be used to make it possible to reuse common specification. infusion pumps provide a motivating example. a specific model is described and analysed and comparison between competitive devices is discussed. keywords: mal, ivy, medical devices, procurement, interactive systems 1 introduction the systematic analysis of properties of interactive behaviour using modal action logic (mal) and the ivy tool has been reported in previous papers [ch08, ch09]. this paper focuses on the modelling and analysis of a more complex device than described previously, supporting a variety of display modes. it is part of the ongoing analysis of a range of medical infusion devices with the aim of reducing procurement costs. the situation that motivates this discussion is where comparable analyses are required for a range of devices to assess which design is most appropriate for purchase given a particular context. the focus of this comparison is to identify issues which might affect their use in the proposed work context. properties of the user interface provide the primary concern. a recently developed intravenous infusion pump (the alaris gp [car06]) is considered as a candidate for analysis. the relevance of the rigorous assessments proposed here prior to procurement are heightened by well documented concerns about safety of infusion devices in general (see for example [fa10]). the model that is used in the analysis is based on two sources: a manual [car06] and a simulation developed by patrick oladimeji at swansea university http://cs.swan.ac.uk/∼cspo/ simulations based on the actual device. in addition to discussing a proposed means of product 1 / 16 volume 45 (2011) mailto:jose.campos@di.uminho.pt mailto:michael.harrison@ncl.ac.uk http://cs.swan.ac.uk/~cspo/simulations http://cs.swan.ac.uk/~cspo/simulations modelling and analysing the interactive behaviour of an infusion pump comparison, the paper demonstrates that mal and ivy can be scaled appropriately to a suitable class of devices. the task of producing the model for the candidate device is illustrated by providing and explaining mal fragments. inevitably this means that, because the model is not presented completely, it can appear complex. however the benefit of this level of explanation is to indicate the scale of the task of producing a detailed model of a real device. the paper makes two distinct contributions. it proposes a layered approach to modelling systems with the aim of supporting reuse, thereby reducing modelling costs. it demonstrates the modelling and analysis of a more compex system than previously discussed using the ivy tools which includes the specification of both soft buttons and screen areas where information is mode dependent. it proposes an approach to dealing with this complexity. the paper briefly introduces the model’s specification and focuses on properties that can be used for the purposes of comparison. after a brief review of the background (section 2) and introduction to the device (section 3) the analysis is introduced and illustrated. section 4 introduces the three layers of model and section 5 provides examples of the verification. a final section (section 6) provides some discussion and conclusions. 2 background the procurement process is an important stage in the introduction of new technology within healthcare. techniques are required that will make it possible to explore candidates systematically (for discussion, see [gin05]). a prime motivation for this analysis has been a concern with the safety of medical devices, particularly from an ergonomic perspective [mnmc08]. a number of usability engineering methods have been explored in this regard, for example cognitive walkthrough [bo07] and heuristic evaluation [zjp+03]. these techniques have been adapted to be relevant to the requirements of the medical domain. they involve the imaginative application of guidelines or heuristics either to a description of the device, in the case of heuristic evaluation, or to how the device is to be used (in terms of a task or a scenario) in the case of cognitive walkthrough. these desk-based evaluation techniques are either applied by individuals or suitably qualified teams. human reliability analysis techniques [kir94] have also been applied in a medical domain, for example sherpa [lsh06], with the aim of providing realistic assessments of the safety of use of medical devices. a useful review of techniques can be found in [mnmc08]. all these techniques are systematic, they often involve teams of evaluators with a balance of skills, and require a representation of the activities that are being carried out in terms of a task or a scenario. the device model is often informal, for example the proposal in [bo07] is that the task model be annotated with screen shots to indicate how the device functions. formal analysis of software based systems provides the underpinning to the work described here. these techniques provide the opportunity to be both thorough and systematic by checking a battery of properties. relevant techniques include those of thimbleby and gow [tg08] who have applied formal approaches to medical devices based on graph models of the interface. thimbleby and oladimeji use similar techniques to explore the data entry characteristics of the infusion pump [to09]. their process involves the manual development of a state model reflecting the design. these models are analysed as graphs. animation and prototyping of models can also be a powerful method of visualising the consequences of a design. palanque and others have proc. fmis 2011 2 / 16 eceasst figure 1: the alaris gp volumetric pump developed petri net and object oriented models of interactive devices and use a tool (petshop) [npdb06] to animate and prototype. their work focuses at the widget level and has included a specification of the arinc 661 aircraft cockpit controls standard [bcnp07]. “visual event grammars” (veg) [brrp05] have also been used to describe interface widgets. these widgets are described as a set of production rules and are translated into promela and analysed using spin [hol03]. veg is used to explore reachability and deadlock properties but does not explore usability related properties explicitly. an important issue in the development of such models is to deal with issues of scale, particularly dealing with the number of states that must be explored. in this respect bolton and bass use sal to explore an architecture for a baxter ipump [bb10], another variant of the type of device explored here. their paper focuses on the architecture of their model and the measures that were taken to ensure the model was tractable. using ivy (which maps to smv) it was possible to explore substantially richer models of a similar device. 3 the infusion pump the candidate device for procurement is an infusion pump. the particular focus for this discussion is one variant of the alaris gp infusion pump [car06] (see figure 1). this device is safety critical, and is used in hospital settings to provide accurate and reliable intravenous infusions to patients. failure to set up infusion pumps correctly can have severe consequences. a number of documented incidents with a range of types of infusion pump indicate how the wrong material, or the wrong volume at the wrong rate, has had disastrous consequences for the patient to whom the infusion was being administered (see, for example [zjp+03]). the manual for the particular 3 / 16 volume 45 (2011) modelling and analysing the interactive behaviour of an infusion pump figure 2: alaris actions device described in this paper [car06] proposes that it is designed to be used in a variety of settings, from general hospital wards, critical and intensive care, operating rooms to accident and emergency rooms. the infusion pump allows input of data relating to the volume to be infused and rate of infusion prior to starting the infusion process. the pump has two basic states: infusing and holding. in the infusing state the volume to be infused (vtbi) is pumped into the patient intravenously according to the infusion rate. while in the infusing state the vtbi can be exhausted, in which case the pump continues in kvo (keep vein open) mode and sets off an alarm. the other basic state is holding. in this state values and settings can be changed via chevron buttons (for the device layout, see figure 2). these buttons are used to increase or decrease entered numbers incrementally. depending on mode the buttons can be used to change infusion rate and volume to be infused, or alternatively allow the user to move between options in a menu, for example in bag mode and in query mode. bag mode allows the user to select from a set of infusion bag options, thereby setting vtbi to a predetermined value. query mode, which is invoked by pressing the query button, generates a menu of options. these options include a number of possibilities according to how the device is configured by the manufacturer, including the possibility of locking the infusion rate, or disabling the possibility of locking it. the device also allows movement between display modes via three function keys (key1, key2 and key3). each function key has a display associated with it indicating its present function. the focus of the analysis presented here is to consider confusions that arise as a result of the mode structure exhibited by this device. the aim is to compare it with the structure of other similar devices. furthermore the analysis explores potential confusions that arise through the information that is being displayed. the focus of the paper is on the “software” aspects of the design. the relationship between the device and its environment, which is of course extremely important, will not be considered proc. fmis 2011 4 / 16 eceasst explicitly in this paper. hence, for example physical aspects of the “giving set” used to connect the device to the vein of the patient will not be considered nor will any issues associated with electromagnetic interference. these other aspects are of course also important in the procurement of these devices. there are a wide range of infusion pumps and syringe drivers in use in hospitals with a variety of interface styles that differ in terms of style of data entry and the ways in which modes are structured. this specific example will trigger discussion of broader issues. 4 the model the full specification of the model discussed in this paper can be seen at the minho hci specification repository (http://hcispecs.di.uminho.pt). three layers of the model are described to make it easier to reveal the differences between alternative candidate pump designs. the underlying pump model (the inner layer) is identical, or nearly identical, subject to minor controlled variations across the range of devices. the middle layer is specific to the device being modelled and describes its interface structure. the activity model (the outer layer) will assume the same activities in each device that is being considered. these activities will be derived from an understanding of the work that the clinician is to carry out. this outer layer is not dependent on characteristics of the device though it provides a mapping into the middle layer thereby grounding it in the specific details of the device. the paper introduces the mal notation in which the model is described through a number of fragments. there is no space to provide a full description of the notation. more details of mal can be found in [ch01, ch08, ch09]. 4.1 the inner layer the inner layer describes the temporal evolution of the infusion process. the process is captured in an invariant: infusionrate > 0 −> infusionrateaux = infusionrate infusionrate > 0 −> time = (vtbi/infusionrateaux) infusionrate = 0 −> time = 0 this invariant asserts relationship between vtbi, infusion rate and time to completion of the process. the invariant ensures that division by zero is not possible by using an additional state attribute infusionrateaux taking values in the range 1..maxrate. the tick action (which captures the evolution of the process) describes infusion and the alarms that occur when the device has been left in a hold state for too long. to illustrate the model’s specification in the simplest terms one element of the infusion process is described using a modal axiom in mal. (infusionstatus = infuse) & (infusionrate < vtbi) −> [tick] vtbi′ = vtbi−infusionrate & volumeinfused′ = volumeinfused + infusionrate & keep(infusionrate, . . . 5 / 16 volume 45 (2011) http://hcispecs.di.uminho.pt modelling and analysing the interactive behaviour of an infusion pump this axiom describes tick as the pump is infusing (infusionstatus = infuse) when the infusion rate (i.e. the volume infused per tick) does not lead to exhaustion of the volume to be infused. the axiom has three elements: the action that is being described (contained in square brackets); the conditions that must be satisfied for the action to have the stated effect (left side of the implication); the result of the action under these conditions. vtbi′ = vtbi−infusionrate specifies that the next state (indicated by the prime symbol) of vtbi must be equal to its old value minus the infusionrate. mal specifies that unless a state attribute is explicitly constrained in a modal axiom then it can change randomly in the next state. the keep function determines the list of state attributes that cannot change. 4.2 the middle layer the difference between the competing pumps is captured in the middle layer of the specification. the pumps use modes so that the devices’ limited display space can be used effectively to help the clinician see what the effects of actions will be. this layer describes the mode structure and the information that is displayed at each stage. the visibility of these variables is specified explicitly using the boolean array middisp. the following illustrative axiom describes the behaviour of the soft key 2 when the top line of the device shows “holding” (see figure 2) and the pump is processing normally (vtbi has not been exhausted i.e. the pump is not in kvo mode). (topline = holding) & !kvoflag −> [key2] topline′ = dispvtbi & oldvtbi′ = vtbi & middisp[dvtbi]′ & !middisp[dvol]′ & !middisp[dtime]′ & !middisp[dbags]′ & !middisp[dkvorate]′ & !middisp[dquery]′ & fndisp1′ = fok & fndisp2′ = fbags & fndisp3′ = fquit & vtmode′ & !rmode′ & !bagmode′ & !qmode′ & elapse′ = 0 & keep(infusionstatus, infusionrate, volumeinfused, vtbi, onlight, runlight, pauselight, rdisabled, rlock, kvoflag) the axiom asserts that the next top line shows “volume to be infused” (dispvtbi) and the value of vtbi is displayed (i.e. middisp[dvtbi]′ is true). the soft function keys (fndisp1′ etc.) in this next step show “ok”, “bags” and “quit” respectively. the mode in this step is determined to be vtmode while other modes are false. 4.3 the outer layer the third layer of the model describes the activities that are assumed to be typical of the clinician’s use of the device. these activities are assumed to be determined through negotiation with domain and human factors experts. the examples here are intended to be indicative only. one of the activities that may have been determined as being important in the infusion process is that another clinician should confirm that the correct value of vtbi has been entered into the device based on the original prescription. this layer of the model describes activities, capturing what needs to be done in relation to the pump. the process of eliciting and understanding these activity actions and meta-state attributes is a process akin to task modelling [ka92] where the human proc. fmis 2011 6 / 16 eceasst factors or domain expert observes the infusion activity in context. these meta-state attributes do not capture any feature of the device or its interface, rather they indicate a state in the activity as assumed to be understood by the clinician who is using the device. they can be used to constrain the device actions described in the middle layer. hence confirming that the vtbi has been entered involves completing the entervtbi activity (by requiring that the meta-state attribute enteringvtbi is set to false) and asserting that vtbi has been confirmed (using the vtbiconfirmed meta-state attribute). [confirmvtbi] !enteringvtbi′ & vtbiconfirmed′ & keep(enteringrate, readyforrate, mrate, mvolume, rateconfirmed, readyforvtbi) the confirmvtbi activity is only permitted if enteringvtbi is true and and the value of vtbi is equal to the required volume contained in the prescription. note that the attribute vtbi defined within the alarispump interactor is referred to by prefixing the attribute name with the interactor name alarispump.vtbi. hence per(confirmvtbi) −> (mvolume = alarispump.vtbi) & enteringvtbi mal makes it possible to describe deontic assertions using operators for permission and obligation. in this model permission axioms are used widely to restrict the possible behaviours of actions. hence the use of a chevron key is permitted only if entering the vtbi or entering the infusion rate as part of an activity defined at the outer layer. these actions are now assumed to bear a specific relation to the prescribed value that the clinician has taken from the prescription. hence the “fast up” chevron is only used if the current value is less than the required value by more than “big step” in the appropriate activity. this is specified using the following permission axiom. per(alarispump.fup) −> (enteringvtbi & alarispump.vtmode & ((bigstep + alarispump.vtbi) < mvolume)) | (enteringrate & alarispump.rmode & ((alarispump.infusionrate + bigstep) < mrate)) this outer level has some similarity with the cognitive models described by [rbcb09]. it is however simpler, making no assumptions about the cognitive process itself, simply concerning itself with observed activities. 5 verifying the model the aim of the verification process is that similar properties relating to user interface characteristics can be checked of each candidate device. these formal properties provide a benchmark against which each candidate can be explored. as a result, potentially unforeseen design consequences can be discovered that could not be found simply by reading the manual or through brief experiment with the device. the circumstances in which properties fail are assessed with 7 / 16 volume 45 (2011) modelling and analysing the interactive behaviour of an infusion pump aid of human factors or domain expertise. thus failure acts as a trigger for the consideration of a human interface characteristic that would otherwise lie hidden. properties checked of each candidate are of the following types. • checking that the process represented in the inner layer is sufficiently visible through the device interface (mirroring the process in the interface). • ensuring consistency of use of the display, or of action (consistency of the interface). • ensuring that activities described in the outer layer are supported (supporting activities). the specific details of the properties in these three categories will differ depending on the device that is described in the middle layer of the model. in the case of the device modelled here, the properties that were checked of the inner and middle layers were checked first (reducing the time for checking) before adding a further interactor describing the activity layer. properties are presented for analysis using ctl (see [cgp99] for an introduction to model checking). ctl provides two kinds of temporal operator, operators over paths and operators over states. paths represent the possible future behaviours of the system. when p is a property expressed over paths, a(p) expresses that p holds for all paths and e(p) that p holds for at least one path. operators are also provided over states. when q and s are properties over states, g(q) expresses that q holds for all the states of the examined path; f(q) that q holds for some states over the examined path; x(q) expresses that q holds for the next state of the examined path; while [qus] means that q holds until s holds in the path. ctl allows a subset of the possible formulae that might arise from the combination of these operators. ag(q) means that q holds for all the states of all the paths; af(q) means that q holds for some states in all the paths; ef(q) means that q holds for some states in some paths; eg(q) means that q holds for all states in some paths; ax(q) means that q holds in the next state of all paths; ex(q) means that q might hold in the next state; a[qus] means that q holds until some other property s holds in all paths; e[qus] means there exists a path in which q holds until some property s. the properties are analysed in the ivy tool by translating the mal model into smv and using the symbolic model checker nusmv [ccg+02] to check the ctl properties. it was necessary to restrict the state space by reducing the ranges of vtbi, infusion rate and menu lengths. checking the combination of inner layer and middle layer of the model using the whole battery of properties took less than twenty minutes on a standard laptop. adding the outer layer increased the checking time to about 20 minutes per property. checking the three layer model involved 1.2963e + 09(230.2718) reachable states. 5.1 mirroring the device in the interface relevant properties first concern the extent to which the infusion pump process is visible in the device. this visibility is concerned with the basic variables: infusion rate, vtbi, time to infuse. it is also concerned with whether it is clear that the pump is infusing or not, including whether it is in kvo mode. the middle layer model simply records whether the attribute is displayed or not. by this means visibility is made explicit in the model. the status of the pumping process is slightly more complex. this status is captured at the inner level using the state attribute proc. fmis 2011 8 / 16 eceasst infusionstatus. in the alaris pump there is no specific display attribute that indicates unequivocally whether the device is pumping or not. the top line of the display provides information that helps the clinician understand (see figure 2) what mode the device is in. appropriate properties associated with checking the interface are: ag(topline in {infusing, dispkvo, vtbidone} ↔ infusionstatus = infuse) ag(topline in {holding, dispvtbi, setvtbi, attention, volume, options, dispinfo, locked, blank} ↔ infusionstatus = hold) the first property fails. examining the trace indicates that in kvo mode a display appears that allows function key 1 to take the device to a state where the top line display shows “volume”. this means that “volume” can appear as the top line when both infusing and holding, potentially a cause for concern, particularly if there is no audible alarm associated with the device infusing in kvo mode. on the other hand it could be argued by domain experts that this potential confusion is unlikely to be a real confusion in the context of clinical activities. in the second property there is a substantial list of displays in the top line that indicate that the device is holding. a further top line display indicates when the infusion rate is locked and appears for one tick if the user attempts to change the infusion rate. the final value in the top line is “blank” used to indicate that the device is switched off regardless of the value of the other state attributes of the model. the second property also fails because “volume” can also appear as the top line when infusing. 5.2 consistency of the interface a number of properties are concerned with the consistency of the interface. these include: (1) the role and visibility of modes; (2) consistency of naming and purpose of functions; (3) consistency of behaviour of the data entry keys. the role and visibility of modes the device supports modes that govern whether the chevron keys (see figure 2) can be used to enter vtbi, infusion rate or to move between menu selections in bags mode or options mode. additional modes include whether the device is in kvo mode and whether infusion rate modification is locked. it is important to assess how the interface alerts the user to these modes. in the alaris two modes allow entry of vtbi: direct entry (vtmode) and via bag mode (bagmode). both modes are indicated by a display of vtbi in the top line as can be checked using: ag((vtmode | bagmode) ↔ topline = dispvtbi) furthermore it is possible to enter the infusion rate, when the device is in rmode and the top line shows holding. ag(topline = holding ↔ rmode) 9 / 16 volume 45 (2011) modelling and analysing the interactive behaviour of an infusion pump there are other state attributes that act as mode discriminators. infusion rate and vtbi are displayed in a number of situations, hence the first two properties below are false. however the options menu is visible if and only if in query mode, and likewise the bags menu is only visible in the case of bags mode. ag(rmode ↔ middisp[drate]) ag((bagmode | vtmode) ↔ middisp[dvtbi]) ag(qmode ↔ middisp[dquery]) ag(bagmode ↔ middisp[dbags]) the weaker implications, that the variables to be changed are visible in the respective modes is true except in the case of bag mode (hence the second property below is false). whether this is an issue is a matter for the domain expert. ag(vtmode → middisp[dvtbi]) ag(bagmode → middisp[dvtbi]) checking these properties indicates that display of infusion rate or vtbi does not act as a mode discriminator. consistency of naming and purpose of functions a second class of properties is concerned with the consistent appearance of function keys. typical relevant properties include: a particular type of function is always mapped to the same function key; soft functions “ok” and “quit” always return the device to a display mode in which the top line shows “holding”; any display mode (as defined by the top line) will always show the same annotations to function keys. an illustration of the first property is to check that function key 3 is always mapped to “quit” if it is used. ag(fndisp3 ! = fnull → fndisp3 = fquit) this property is false. there are a number of other uses of function key 3. for example in bags mode function key 3 shows “back” rather than “quit”, a case that should be discussed with a domain or human factors expert. if this possibility is excluded then the property continues to fail. ag(((fndisp3! = fnull)&!bagmode&!(topline in {attention, vtbidone, setvtbi})) → fndisp3 = fquit) when the top line shows “attention” or “vtbi done” the device is in an alarm state. when the top line shows “set vtbi” an attempt is being made to start an infusion when no vtbi has been entered. these special cases can be presented to domain or human factors experts so that they can assess whether these exceptions are a cause for concern. to check that if “quit” is a function attached to a key it is associated with key 3, the following property can be used. proc. fmis 2011 10 / 16 eceasst ag((fndisp1 = fquit | fndisp2 = fquit | fndisp3 = fquit) → fndisp3 = fquit) furthermore, consistency of effect of function keys (returning to a top line showing holding) can be checked using: ag((fndisp1 = fok & topline! = options) → ax(key1 → topline = holding)) ag(fndisp3 = fquit → ax(key3 → topline = holding)) the first property demonstrates that the ok function always returns the device to a state in which the top line is holding unless the display is showing options. in the options case, ok will show information relevant to the option. in the case of quit the device always returns to the top line of holding. the final property aims to demonstrate that there is always the same function key configuration: ag(topline = volume → (fndisp1 = fnull & fndisp2 = fclear & fndisp3 = fquit)) although this is true in the case of volume it is not true for all top lines, for example the following property is false: ag(topline = dispvtbi → (fndisp1 = fok & fndisp2 = fbags & fndisp3 = fquit)) because in bags mode the top line displays vtbi but the function keys show ok, null and back respectively. a further property demonstrates consistent effect of the clear function when the top line displays volume. ag((topline = volume & infusionstatus = hold) → ax(key2 → volumeinfused = 0)) in this case if top line is “volume” and key2 is the action then the effect is always to change volumeinfused to 0. consistent behaviour of the data entry keys these properties check that (1) keys will have a similar effect regardless of the value being changed or the mode in which the change is taking place and that (2) keys will have similar properties, for example reversibility, irrespective of the value changed or the mode. these properties can be illustrated in the case of (1) by the template: ag((mode & (modeattribute)) → ax(chevron → effect(modeattribute))) the following illustrative property ranges over all the possible values of infusionrate (in the ivy tool meta-variables ival1 for example can be defined that range over the values of a type or some subset thereof). 11 / 16 volume 45 (2011) modelling and analysing the interactive behaviour of an infusion pump ag((rmode & (infusionrate = ival1)) → ax(sup → infusionrate = ival1 + 1)) the mode of concern here is rmode. the attribute of concern is infusionrate and the effect that is to be consistent is that the action will increment the value of infusionrate. in this particular example the properties are false because the infusion rate lock can be switched on via the options menu. the following alternative properties: ag((!rlock & rmode & (infusionrate = ival1)) → ax(sup → infusionrate = ival1 + 1)) are true except for the extreme case when infusion rate is maximum. the final property template is concerned with reversability. ag(attribute = value → ax(action → ex(attribute = value))) ag(attribute = value→ ax(action1→ ex(action2) & ax(action2→ (attribute = value))))) as an illustration of this class of properties, the following property is true. ag((infusionrate = ival1 & rmode & !rlock) → ax(sup → (ex(sdown)& ax(sdown → infusionrate = ival1)))) here sdown provides the reverse for sup. 5.3 supporting activities the support of activities is explored by proving that specific goals related to the infusion pump can be achieved. hence given an initial infusion rate and vtbi, the pump eventually stops with a volume infused equivalent to the original vtbi. to prove otherwise (which would provide useful counter-examples) amounts to checking: ag((alarispump.infusionrate = ival1&alarispump.vtbi = ival2) → ag(alarispump.volumeinfused ! = ival2)) the traces generated by the model checker as counter-examples can then be explored, consider for example ival1 = 2 and ival2 = 9 (see trace figure 3). the activities involved include: (1) entervtbi (which starts at step 4); (2) confirmvtbi (which starts at step 7); (3) enterrate (which starts at step 8); and (5) confirmrate (which starts at step 11). the infusion starts at step 13 and completes at step 19. a number of device actions are subsumed within these activities. step 2 involves switching the device on, then moving to a top line of vtbi (step 3) then moving to bag mode, then going up one step in the bags menu using the chevron button (step 5, note that step 4 shows the beginning of the entervtbi activity) then exiting from vtbi and returning to a state where the top line is holding (step 7). at this point proc. fmis 2011 12 / 16 eceasst figure 3: the activity counter-example the vtbi is 9 and this permits confirmvtbi to be activated. at step 8 where enterrate is begun there is initially a tick (a random action that is not relevant to the intended process). the top line is holding — the device returns to this display mode after completing the entervtbi activity in step 7. the infusion rate is entered as 3 by first using the double chevron up button and then the single chevron up button. the confirm rate action is permitted in step 11. at this same step the options menu is selected and the rate lock option selected (because it is the first entry encountered). the next step (11) is to confirm it. this returns the device to the holding state, whereupon it is set to “infuse” using the run key. the infusion is completed after 3 ticks at which point the condition of the property is satisfied and the top line shows “vtbi done”. it can be seen that the model checker has generated a plausible sequence of actions in finding a counter-example to the property. this sequence could be further analysed in a more qualitative way using a clinician or human factors specialist to explore the implications of this sequence. 6 discussion and conclusions analysing the infusion pump has produced promising results. the properties used in the analysis are largely based on standardisable patterns either generated by the ivy tool or easily generated from the requirements of the device and situation. analogous properties can be systematically applied to other candidate pumps. indeed this analysis has also been performed on the bbraun infusomat pump [bbr05]. the checking of the properties raises a number of issues associated 13 / 16 volume 45 (2011) modelling and analysing the interactive behaviour of an infusion pump with the relation of the display to the underlying pump process and the mode structure of the particular device. for example, the analysis indicates that there are: • possible confusions relating to the use of the display of vtbi in the top line; • ambiguities about whether the pump is infusing or not using the top line of the display as a guide; • inconsistent use of function keys. the analysis says nothing about the significance of these issues. the method is to be used as part of a process including the active participation of human factors and domain specialists. in the context of use these discrepancies in the device may not be issues at all. an important aspect of the method is that it is systematic and that it has the potential to be reused for every candidate infusion pump. the inner level of the specification can be reused for every candidate pump. the outer activity layer can also be partially reused, guiding the analyst to create the appropriate constraints on the device model. the middle layer will be created afresh for each new device. in practice this part of the model continues to be substantial (perhaps a week’s work for the second author). further work is required to develop methods of reusing models that have similar structure or drive particular mode structures. there is still some distance to go before procurers will find the techniques described here costeffective, however the cost of using an infusion device extends beyond making a good deal on price and ongoing maintenance. it is also important to develop systematic techniques that will make it possible to explore the issues associated with the use of the device. the work described here is part of the ongoing analysis of a range of infusion devices with the aim of reducing these costs. part of this process should include a comparison with empirical techniques and with usability evaluation methods in terms of the range problems that can be uncovered by these different methods. acknowledgements: we acknowledge enthusiastically the help of patrick oladimeji of swansea in particular and meetings with members of the epsrc funded chi+med project (ep/g059063/1) in queen mary university, ucl interaction centre and swansea. ann blandford, andy gimblett and paolo masci provided helpful comments. trips to the sites were funded by the project. bibliography [bb10] m. l. bolton, e. j. bass. formally verifying human-automation interaction as part of a system model: limitations and tradeoffs. innovations in system and software engineering 6(3):219–231, 2010. [bbr05] bbraun. bbraun infusomat space: instructions for use. technical report, b. braun melsungen ag, 2005. www.bbraun.com proc. fmis 2011 14 / 16 www.bbraun.com eceasst [bcnp07] e. barboni, s. conversy, d. navarre, p. palanque. model-based engineering of widgets, user applications and servers compliant with arinc 661 specification. in doherty and blandford (eds.), interactive systems: design, specification and verification (dsvis 2006). springer lecture notes in computer science 4323, pp. 25–38. springerverlag, 2007. [bo07] l.-a. bligard, a.-l. osvalder. an analytical approach for predicting and identifying use error and usability problem. in holzinger (ed.), proceedings of the 3rd human-computer interaction and usability engineering of the austrian computer society conference on hci and usability for medicine and health care. springer lecture notes in computer science 4799, pp. 427–440. springer-verlag, 2007. [brrp05] j. berstel, s. reghizzi, g. rouseel, p. pietro. a scalable formal method for the design and automatic checking of user interfaces. acm transactions on software engineering and methodology 14(2):124–167, 2005. [car06] cardinal health inc. alaris gp volumetric pump: directions for use. technical report, cardinal health, 1180 rolle, switzerland, 2006. [ccg+02] a. cimatti, e. clarke, e. giunchiglia, f. giunchiglia, m. pistore, m. roveri, r. sebastiani, a. tacchella. nusmv 2: an open source tool for symbolic model checking. in larsen and brinksma (eds.), computer-aided verification (cav ’02). lecture notes in computer science 2404. springer-verlag, 2002. [cgp99] e. clarke, o. grumberg, d. peled. model checking. mit press, 1999. [ch01] j. campos, m. harrison. model checking interactor specifications. automated software engineering 8:275–310, 2001. [ch08] j. campos, m. harrison. systematic analysis of control panel interfaces using formal tools. in graham and palanque (eds.), interactive systems: design, specification and verification, dsvis’08. springer lecture notes in computer science 5136, pp. 72–85. springer-verlag, 2008. [ch09] j. campos, m. harrison. interaction engineering using the ivy tool. in calvary et al. (eds.), proceedings of the acm sigchi symposium on engineering interactive computing systems. pp. 35–44. acm press, 2009. [fa10] u. food, drug administration. infusion pump improvement initiative. technical report, center for devices and radiological health, april 2010. http://www.fda.gov/medicaldevices/productsandmedicalprocedures/ generalhospitaldevicesandsupplies/infusionpumps/ucm205424.htm [gin05] g. ginsburg. human factors engineering: a tool for medical device evaluation in hospital procurement decision-making. journal of biomedical informatics 38:213219, 2005. [hol03] g. holzmann. the spin model checker, primer and reference manual. addison wesley, 2003. 15 / 16 volume 45 (2011) http://www.fda.gov/medicaldevices/productsandmedicalprocedures/generalhospitaldevicesandsupplies/infusionpumps/ucm205424.htm http://www.fda.gov/medicaldevices/productsandmedicalprocedures/generalhospitaldevicesandsupplies/infusionpumps/ucm205424.htm modelling and analysing the interactive behaviour of an infusion pump [ka92] b. kirwan, l. ainsworth. a guide to task analysis. taylor and francis, 1992. [kir94] b. kirwan. a guide to practical human reliability assessment. taylor and francis, 1994. [lsh06] r. lane, n. a. stanton, d. harrison. applying hierarchical task analysis to medication administration errors. applied ergonomics 37:669679, 2006. [mnmc08] j. l. martin, b. j. norris, e. murphy, j. a. crowe. medical device development: the challenge for ergonomics. applied ergonomics 39:271283, 2008. [npdb06] d. navarre, p. palanque, p. dragicevic, r. bastide. an approach integrating two complementary model-based environments for the construction of multimodal interactive applications. interact. comput. 18(5):910–941, 2006. [rbcb09] r. ruksenas, j. back, p. curzon, a. blandford. verification-guided modelling of salience and cognitive load. formal aspects of computing, 2009. doi: 10.1007/s00165-008-0102-7. [tg08] h. thimbleby, j. gow. applying graph theory to interaction design. in engineering interactive systems. springer lecture notes in computer science 4940, pp. 501–519. springer-verlag, 2008. [to09] h. thimbleby, p. oladimeji. social network analysis and interactive device design analysis. in calvary et al. (eds.), proceedings of the acm sigchi symposium on engineering interactive computing systems. pp. 91–100. acm press, 2009. [zjp+03] j. zhang, t. r. johnson, v. l. patel, d. l. paige, t. kuboseb. using usability heuristics to evaluate patient safety of medical devices. journal of biomedical informatics 36:2330, 2003. proc. fmis 2011 16 / 16 introduction background the infusion pump the model the inner layer the middle layer the outer layer verifying the model mirroring the device in the interface consistency of the interface supporting activities discussion and conclusions microsoft word 99-279-1-sm.doc electronic communications of the easst volume 9 (2008) guest editors: david h. akehurst, martin gogolla, steffen zschaler managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 proceedings of the workshop ocl4all: modeling systems with ocl at models 2007 sharing ocl constraints by using web rules milan milanović, dragan gašević, adrian giurca, gerd wagner and vladan devedžić 18 pages eceasst 2 / 18 volume 9 (2008) sharing ocl constraints by using web rules milan milanović1, dragan gašević2, adrian giurca3, gerd wagner3, and vladan devedžić1 1milan@milanovic.org, devedzic@etf.bg.ac.yu fon-school of business administration, university of belgrade, serbia 2dgasevic@acm.org school of computing and information systems, athabasca university, canada 3giurca@tu-cottbus.de, g.wagner@tu-cottbus.de institute of informatics, brandenburg technical university at cottbus, germany abstract: this paper presents an mde-based approach to interchanging rules between the object constraint language (ocl) and rewerse i1 rule markup language (r2ml). the r2ml tends to be a standard rule markup language by following up the w3c initiative for rule interchange format (rif). the main benefit of this approach is that the transformations between languages are completely based on the languages’ abstract syntax (i.e., metamodels) and in this way we keep the focus on the language concepts rather than on technical issues caused by different concrete syntax. in the current implementation, we have supported translation of the ocl invariants into the r2ml integrity rules. while most of the ocl expression could be represented in the r2ml and other rule languages, we have also identified that collection operators could only be partially supported in other rule languages (e.g., swrl). keywords: mde, ocl, uml, mof, xml, ebnf, rif, r2ml, model transformations, atl, swrl 1 introduction the unified modeling language (uml) [uml06] presents a de-facto standard for modeling object-oriented systems. in the uml, various model elements like classes or state machines can be annotated by logical constraints defined by using the object constraint language (ocl). in this way, uml models constrained by ocl expressions are more accurate and complete. the ocl is today used in a number of tools, and it is accepted as a standard by the omg (object management group); it can be also used to define constraints on mof (meta object facility)-based metamodels [mof06]. the ocl 2.0 specification [ocl06] explicitly defines a concrete and an abstract syntax of the language, i.e., a mof-based metamodel and a textual concrete syntax. in the research community, there have been a lot of efforts to enable sharing uml models with other languages. one such effort is to share uml models and ontologies, and thus enable the reconciliation of the semantic web and software engineering communities [bkk02], [cra01], [gdd06]. however, none of the present efforts have so far considered the problem of sharing ocl constraints with other types of constraint or rule languages such as semantic web rule language [hpb*04], f-logic, or jess. this has a consequence that one can not sharing ocl constraints by using web rules proc. ocl4all 2007 3 / 18 translate ocl constraints defined on uml models into, for example, corresponding constraints defined over owl ontologies. nevertheless, the w3c consortium started an initiative called rule interchange format (rif) [gin06], which tries to define a standard for sharing rules. that is, rif should be expressive enough, so that it can represent concepts of various rule languages. besides rif, one should also develop a (two-way) transformation between rif and any rule language that should be shared by using rif. currently, there is no official submission to rif, but the ruleml [hbg*06] and the rewerse i1 rule markup language (r2ml) [wgl05] are two well-known rif proposals. in this paper, we propose transformations between the r2ml and ocl to enable interchanging ocl rules with other rule languages via r2ml. however, we want our solution to be completely based on the abstract syntax of both languages, unlike other similar approaches proposed in the context of rule interchange [rtj06] that mainly focus on a concrete syntax without efficient mechanisms to check whether the implemented transformations are valid w.r.t. the abstract syntax. in this paper, we propose using modeldriven engineering (mde) principles and model transformations to address this issue. this means that we have to provide a two way mapping between the ocl and r2ml. the main benefit of such an approach is that we can actually map ocl constraints into all other rule languages (e.g., swrl, jess, f-logic, and prolog) that have mappings defined with r2ml. in our previous work [mgg*06], we defined technical requirements for fully implementation of this approach, while in this paper we focus on the details of the mappings between ocl and r2ml constructs. the mappings between the ocl and r2ml include those ocl constructs which are interchangeable with other rule languages, i.e., we have defined mappings of such ocl expressions that could be represented in rule languages for which we have already defined mappings. 2 motivation in order to motivate sharing rules expressed in the ocl and r2ml, let us consider the following uml model from figure 1 that represents an excerpt from the eu-rent vocabulary business context. eu-rent is a car rental company owned by eu-corporation and it is used as an example in the semantics of business vocabulary and business rules (sbvr) standard [sbvr05]. at the uml class person, there is a following ocl invariant defined: a barred driver is a person known to eu-rent as a driver who has at least 3 bad experiences. this invariant is in a uml note attached to the person class and shown on the uml diagram from figure 1. given the great diversity of rule concepts and existing rule languages, the r2ml metamodel consists of overlapping metamodels for the following types of rules: integrity, derivation, reaction, and production rules. this means, we first have to decide to what type of r2ml rules we should transform the above ocl constraint. having in mind the nature of the ocl invariant above, which defines that something must be true for all instances of that type at any time, we actually should transform the above rule into an r2ml integrity rule, or more specifically an alethic integrity rule (see more details about notion of r2ml integrity rules in section 4.1) [wgl05]. in general, we can say that an ocl invariant, which is universally quantified formula over a set of objects corresponding to the context in a form of an alethic integrity rule (necessity), can be translated to an r2ml rule. due to the nature of the ocl eceasst 4 / 18 volume 9 (2008) invariants, it has to be translated onto the r2ml integrity rule. in figure 2, we show the ocl invariant from figure 1 in the r2ml xml-based concrete syntax. this r2ml alethic rule has a universally quantified formula as its constraint, while this universally quantified formula is an implication which is obtained from the ocl implies element. mappings between the ocl invariant shown in figure 1 and the r2ml rule shown in figure 2, will be explained in detail in section 4.3. figure 1. ocl invariant and its corresponding uml class person in the uml class diagram once we transform the ocl invariant into an r2ml alethic integrity rule, we can further transform it onto all other rule languages supporting integrity rules by exploiting the existing transformations for r2ml [r2ml07] (e.g., swrl [mgg*06]). however, we should mention here that we have supported only those ocl constructs which can be translated into other rule languages (see section 4.3 for details). from the above facts, it is obvious that in both examples we use the concrete syntax of the languages (i.e., ocl and r2ml). however, a language is usually defined by its abstract syntax (i.e., metamodel), while concrete (visual or textual) syntax is employed to represent physically rules. thus, defining and implementing mappings between languages should be done on the level of their abstract syntax, as this actually allows us to focus on mappings between language constructs, rather than on the implementation details of their concrete syntax. being driven by this approach, in the rest of the paper, we describe mappings between r2ml and ocl on the level of their abstract syntax, and yet bridge the gap between r2ml and ocl’s abstract and concrete syntax by using mde principles. sharing ocl constraints by using web rules proc. ocl4all 2007 5 / 18 figure 2. an r2ml (alethic) integrity rule equivalent to the ocl invariant from figure 1 3 model transformations for rules in this section, we summarize transformation chain used to implement mappings between two languages, while the detailed discussion on the technical requirements is given in [mgg*06]. the first step (see figure 3) is between ocl rules (invariants) represented in the ocl concrete syntax (i.e., in the ebnf technical space [kba02]) and models compliant with the ocl metamodel (in the mof technical space) [ocl06]. in the second step, the mof-based ocl rules obtained (i.e., ocl models) are transformed to r2ml models compliant with the r2ml metamodel. in the third step, r2ml models are transformed into the xml models (i.e., instances of the xml metamodel) by using transformations that we created in our previous work for bridging between the r2ml abstract and concrete syntax [mgg*07]. finally, in the fourth step, such xml models (from the mof technical space) are serialized into the r2ml xml format (compliant with the r2ml xml schema) by using the atl xml extractor tool [atl07a]. having in mind all the above transformations, we have the core of the solution that is based on abstract syntax, but we actually can transform between ocl invariants and r2ml xmlbased rules. eceasst 6 / 18 volume 9 (2008) figure 3. the transformation scenario between ocl and r2ml 4 mappings between r2ml and ocl in this section, we first describe the parts of the r2ml abstract syntax relevant for representing ocl rules. we then describe the ocl abstract syntax, and finally, mappings between r2ml and ocl in detail. 4.1 r2ml abstract syntax the r2ml metamodel is defined by using the mof metamodeling language. r2ml supports four kinds of rules, namely, integrity rules, derivation rules, production rules, and reaction rules. r2ml covers almost all of the use case requirements of rif [gin06]. although ocl can represent both integrity constraints and derivation rules, we only describe r2ml integrity rules here. an integrity rule, also known as (integrity) constraint, consists of a constraint assertion, which is a sentence in a logical language such as first-order predicate logic or ocl (see figure 4error! reference source not found.). the r2ml framework supports two kinds of integrity rules: the alethic and deontic ones. an alethic integrity rule can be expressed by a phrase, such as “it is necessarily the case that” and a deontic one can be expressed by phrases, such as “it is obligatory that” or “it should be the case that.”. figure 4. the metamodel of integrity rules sharing ocl constraints by using web rules proc. ocl4all 2007 7 / 18 the corresponding logicalformula must have no free variables, that is, all the variables from this formula must be quantified. r2ml defines the general concept of logicalformula (see figure 5) that can be conjunction, disjunction, negationasfailure, strongnegation, and implication. the concept of a quantifiedformula is essential for r2ml integrity rules, and it subsumes existentially quantified formulas and universally quantified formulas. figure 5 also contains elements such as atleastquantifiedformula, atmostquantifiedformula, and atleastandatmostquantifiedformula for defining cardinality constraints with r2ml rules. atoms are basic constituents of formulas in r2ml, and they together with formulas correspond to the boolean ocl expressions. atoms are compatible with all important concepts of uml and ocl. r2ml distinguishes object atoms, data atoms, and generic atoms. figure 5. the concept of a logical formula in r2ml terms are the basic constituents of atoms, which can be viewed as a first-order predicatelogic-based version of the ocl metamodel fragment of non-boolean ocl expressions. similarly to atoms, the r2ml language distinguishes between object terms, data terms and generic terms. we here describe only data terms due to the size limit, while object and generic atoms are defined in a similar way. a dataterm is a dataliteral, datavariable, or datafunctionterm that can be dataoperationterm, attributefunctionterm, and datatypefunctionterm (see figure 6). eceasst 8 / 18 volume 9 (2008) figure 6. r2ml data terms a dataoperationterm is formed with the help of a contextargument, a user-defined operation, and an ordered collection of arguments. the attributefunctionterm corresponds to a datatype attribute in a uml class model. datatypefunctionterm is represented with datatypefunction and dataarguments. datavariable stands for plain data types, while dataliteral can be plainliteral and typedliteral with some datatype. 4.2 ocl abstract syntax the ocl metamodel (i.e., abstract syntax for ocl version 2.0) is also defined by using mof [ocl06]. in this abstract syntax, a number of meta-classes from the uml 2.0 metamodel are imported [uml06]. the ocl metamodel is divided into several packages: the types package describes the concepts that define the type system of ocl. it shows the types predefined in ocl as well as the types that are deduced from the uml models; the expressions package describes the structure of ocl expressions; and the enhancedocl1 package that we have added to the standard ocl metamodel to represent invariant constructs that are not supported in the standard ocl. the expressions package defines kinds of ocl expressions. an overview of the inheritance relationships between all classes defined in the package is shown in figure 7. the basic structure of the package consists of the ocl metamodel classes such as oclexpression that is an abstract superclass for all ocl expressions; and feature–callexp that is superclass for the operationcallexp and propertycallexp classes. operationcallexp represents an operation defined on a classifier, while propertycallexp models a reference to an attribute of a classifier defined in a uml model. 1 we are very grateful to mr. mariano belaunde for his generous help in defining the enhancedocl package. sharing ocl constraints by using web rules proc. ocl4all 2007 9 / 18 figure 7. the basic structure of expressions in the ocl metamodel since the standard specification of the ocl metamodel [ocl06] does not contain support for ocl invariants, we introduced the enhancedocl package. this package contains the invariant class, as a subclass of the oclmoduleelement class (see figure 8), white classes are from the uml metamodel, white gray colored ones are from the standard ocl metamodel and dark gray are classes that we have defined). figure 8. elements of the enhancedocl package in the ocl metamodel oclmoduleelement represents a superclass for following elements: ocl invariant elements (represented with the invariant class); ocl operations and properties, i.e., “def” elements (represented with the abstract class oclfeature) that are represented with classes ocloperation and oclproperty, respectively; and ocl derivation rules, i.e., "derive" elements (represented with class deriveoclmoduleelement). eceasst 10 / 18 volume 9 (2008) oclmoduleelement contains a definition of an invariant context that is represented with the oclcontextdefinition class. in addition, the oclmodule class is introduced to represent a basic class in an ocl model, and it contains other oclmoduleelements. we also added the operatorcallexp class into the standard expression package of the ocl metamodel to represent operation call expressions that use operators, and it inherits operationcallexp class. we had to do this in order to be able to develop the ocl parser that fully covers all ocl constructs. due the limited size for this paper, we do not show these classes and their relations. 4.3 conceptual mappings between ocl and r2ml in order to share rules between ocl and r2ml, we have defined isomorphic mappings between certain constructs of ocl and r2ml on the level of their abstract syntax. every ocl invariant which is in the form of an ocl implies is mapped to an r2ml alethicintegrityrule whose constraint is a universallyquantifiedformula, while its formula is an implication mapped from an ocl implies element. besides ocl implies expression, we have supported all other ocl expression that can be written in invariants. we further expand the mappings between ocl and r2ml to specify mappings between elements that are part of ocl and r2ml expressions. in table 1, we give an excerpt of the mappings that we defined between both languages metamodels. the complete mappings between the r2ml and ocl metamodels contain 37 rules. in the rest of this subsection, we describe the mappings of the main ocl expressions, which could be used in invariants, into the r2ml. as an illustration, we refer to the eu-rent case study shown in figure 1. (n.b. every ocl invariant expression is defined in the context of a uml class such as context rentalcar). • ocl attribute (e.g., self.age), which is represented in the ocl metamodel as propertycallexp, is mapped into an r2ml attributionatom, which consists of an object term as “subject” and a data term as “value“. for example, startdate(r1, sd), where startdate is an attribute, r1 is an object term (subject), and sd is a data term (data value). note that the attributionatom, as well as all other r2ml atoms, inherit the atom class shown in figure 5. • ocl operation call, which is represented in the ocl metamodel as operationcallexp, is mapped: o to r2ml dataoperationterm, if the operation call returns a primitive ocl datatype. the dataoperationterm refers to a non-state-changing user-defined operation and consists of a list of data or object arguments and an object term as a context argument. the result of an operation is a data term (value). an example of a dataoperationterm is x.getage(), which returns the age of a car x. the dataoperationterm corresponds to a java path expression calling an operation which returns a datatype as result (e.g., int). o to r2ml objectoperationterm, if the operation call returns an object. the objectoperationterm refer to a non-state-changing operation. the objectoperationterm may have data terms and object terms as operation arguments and is evaluated to an object. for example, the expression x.getlastrental(), which returns the last rental of a rental car, is an object operation term, where getlastrental() denotes an operation and x is the context argument (see figure 1). the objectoperationterm corresponds to a java path expression calling an operation which returns an object as result. sharing ocl constraints by using web rules proc. ocl4all 2007 11 / 18 • a uml association is navigated in the ocl by using its opposite association end (in the ocl metamodel, this is represented with propertycallexp). if the maximal multiplicity of the association end is 1 (i.e., cases “0..1” or “1”), then the value of this expression is an object, and such an expression is mapped into an r2ml referencepropertyfunctionterm. the r2ml referencepropertyfunctionterm is a function, which returns the value of an association end for a given object. for example, the expression x.pickupbranch, where pickupbranch is an association end name of a branch in the association between classes rental and branch (see figure 1) is a reference property function term, where x is an object term and pickupbranch is a reference property. however, if the multiplicity of the association end is more than one (“*”), then the navigation will result in a set, and such an expression is mapped into an r2ml attributefunctionterm (with “set“ as the type category). the attributefunctionterm refers to an attribute and an object term as a context argument. for example, the expression x.reservationdate is an attribute function term, where x is an object term and reservationdate is an attribute of class rental. when the association is adorned with {ordered}, the navigation results in an orderedset and in this case the attributefunctionterms type category is “orderedset.” for two other kinds of collections (bag and sequence), the attributefunctionterm has corresponding type categories. • ocl collections may have a large number of predefined collections operations on them (e.g., the size operation, which returns the number of elements in a collection, or the isempty operation, which returns true if the collection is empty or false otherwise). these operation calls (represented in the ocl metamodel with operationcallexp) are mapped into the r2ml datatypepredicateatoms, in the case when on the left side of the equality operator is collection operation call and on the right side is any other ocl expression (e.g., badexpirience->size()=1). the operation calls are also mapped into the r2ml datatypepredicateatoms, in the case when a collection operation call on an association end (with multiplicity more than one) is evaluated to a boolean value (e.g., badexpirience->isempty). the datatypepredicateatom describes a relation between several data terms, using a data predicate which represents a swrl built-in function [hpb*04] that is translated from the operation on a collection. for example, self.badexpirience->isempty() is translated into an r2ml datatypepredicateatom where „swrlb:empty“ is data predicate and self is an attributefunctionterm (with the person class as an object term) with “bag“ as the type category. in the case of the notempty operation, the datatypepredicateatom is negated (with the property isnegated, which is set to true). however, in case when the collection operation call is used in an expression with comparison operators to some other evaluated expression (e.g., self.badexperience->size()>3), the collection operation call is mapped into an r2ml datatypefunctionterm, where the collection operation call is translated into the (xpath) datatype function. we have made this decision because comparison operators (other than equality) are mapped into datatypepredicateatoms whose arguments must be terms. for example, the ocl size operation is translated into the xpath count operation. besides this, we have also a special case when the collection operation call returns just one element, but not the entire collection (e.g., the first operation), in which case the operation call is mapped into an r2ml objectoperationterm. eceasst 12 / 18 volume 9 (2008) • ocl equality operation between two association ends, which is represented in the ocl metamodel with operationcallexp, is mapped into an r2ml referencepropertyatom. the referencepropertyatom associates object terms as “subjects” with other object terms as “objects.” for example, returnbranch(r1, rb), where returnbranch is a reference property and r1 (subject) and rb (object) are object terms. in the case of the inequality operator, the property isnegated of the referencepropertyatom is set to true. note that translation of any negated ocl expression (denoted with “not” operator) into an r2ml atom is done by setting property isnegated of such atom to true. • ocl ocliskindof(t) operator, which is a property that determines whether t is either the direct type or one of the supertypes of an called object, is mapped into an r2ml objectclassificationatom. the objectclassificationatom consists of a class type (as “base type”) and an object term, variable, constant or function term. objectclassificationatom accommodates the concept of an operationcallexp in the ocl metamodel with a typeexp argument (e.g., rental(r1)). • ocl implies operation, which is represented in the ocl metamodel as operationcallexp, is mapped into an r2ml implication. the r2ml implication consists of an antecedent (body) and a consequent (head), each of which consists of a set of atoms. • in r2ml, functions range over individuals, like in standard first-order predicate logic. since ocl allows function terms (such as navigation call expressions) to range over sets (more precisely, collections) and because the current r2ml metamodel does not support collections, the r2ml only captures a fragment of the ocl collection expressions. this will be subject for the future work to allow set-valued functions in the r2ml metamodel and then to provide a full support for such ocl expressions. • in the current implementation, we have partially supported following ocl collection operations: select, reject, includesall, and forall. due to size of this paper we do not describe mapping of every operation in detail. as an example, we may say that the select operation (represented in the ocl metamodel as iteratorexp), which specifies a subset of a collection, is mapped into an r2ml conjunction of an attributionatom and existentiallyquantifiedformula. the attributionatom represents a mapping of an association end which is a collection, and the existentiallyquantifiedformula is mapped from the select’s boolean expression (also, iterator variables are mapped into the r2ml genericatoms). note that there a constraint here, that is, we have only supported the translation of the following select construct: collection->select( v | boolean-expression-with-v), where v is called iterator variable. when the select construct is evaluated, v iterates over the collection and the boolean-expression-with-v is evaluated for each v. the v variable is a reference to the object from the collection and can be used to refer to the objects themselves from the collection (e.g., self.employee->select(age>10)->notempty()). in a similar way, we have mapped other collection operations. • ocl tuple type, which is used to compose several values and consists of named parts and which is represented in the ocl metamodel with tupleliteralexp, is mapped into the r2ml objectdescriptionatom. the objectdescriptionatom refers to a class as a base type and to zero or more classes as categories, and consists of a number of property/term pairs (i.e., r2ml attribute data term pairs and reference property object sharing ocl constraints by using web rules proc. ocl4all 2007 13 / 18 term pairs). any instance of such atom refers to one particular object, that is referenced by an objectid, if it is not anonymous. using the mappings between ocl and r2ml presented in above and shown in table 1, we now illustrate the transformation process by using the example of the ocl rule from figure 1 and its corresponding r2ml rule from figure 2. as we have already mentioned, the ocl invariants (invariant elements from figure 8) are transformed into r2ml integrity rules (alethicintegrityrule elements from figure 2). an ocl implies element (i.e., operationcallexp class with name “implies”) is transformed to an r2ml alethicintegrityrule (shown in figure 4) with universallyquantifiedformula element as its constraint, where universallyquantifiedformula has an implication for its formula. the r2ml objectvariable in the r2ml universallyquantifiedformula element is obtained by transforming the contextual class (class element) from the ocl invariant element (shown in figure 8). as it is shown in table 1, an ocl operator call expression (operatorcallexp element) which with name “=”, is transformed into an r2ml attributionatom element, where the ocl operatorcallexp’s source element is transformed into the attributionatom’s attribute element (i.e., attribute class). the r2ml attributionatom’s datavalue element is obtained from the ocl operatorcallexp’s argument element. the ocl operatorcallexp “>” is transformed into an r2ml datatypepredicateatom, and an ocl operationcallexp, represents an operation call, is transformed into an r2ml dataoperationterm, if such an operation returns a data value, otherwise, it is transformed to an r2ml objectoperationterm. table 1. an excerpt of mappings between the r2ml metamodel elements and the ocl metamodel elements r2ml metamodel ocl metamodel rulebase oclmodule alethicintegrityrule invariant conjunction operatorcallexp (name = 'and') implication operationcallexp (name = 'implies') attributionatom operatorcallexp (name = '=') source = propertycallexp (subject) objectvariable variableexp referencepropertyfunctionterm propertycallexp referredproperty (name = 'property') source = variableexp objectoperationterm collectionoperationcallexp datatypepredicateatom operatorcallexp (name = ">") source = operationcallexp dataoperationterm operationcallexp 5 implementation expirience in this section, we explain the transformation steps undertaken to transform between ocl invariants and r2ml integrity rules. here we refer to figure 3 from section 3.3 in order to eceasst 14 / 18 volume 9 (2008) position each specific transformation/step in this process of transformation. as we have already mentioned in section 3.3, the transformation process between r2ml and ocl is split into four major steps. step 1. in this step, we bridge between the ocl (ebnf-based) concrete syntax and the ocl abstract syntax (i.e., ocl metamodel). because the ocl textual concrete syntax is located in the ebnf technical space, we need to create an instance of the ocl metamodel (abstract syntax) in the mof technical space. to do this, we first use the ebnf injector, (see figure 3, step 1: ebnf injection), a part of the atl toolkit, and the ocl lexer and parser. we generated the ocl parser and lexer by using the tcs (textual concrete syntax) tools which are also part of the atl toolkit [jbk06]. tcs represents domain specific language (dsl) for defining textual concrete syntax in mde. the ocl parser automatically transforms ocl invariants like the one given in figure 1 into the models conforming to the mof-based ocl metamodel. once we created the ocl tcs and generated ocl parser and lexer based on it, the ebnf injector takes for input the ocl metamodel, ocl code that we want to parse (as .ocl textual file), generated ocl lexer and parser, and it returns a mof-based ocl model as output. once we inject ocl invariants into a mof-based representation (ocl rule in figure 3), we can manipulate with them like with any other mof-based model. step 2. this step is the core of our transformation between the ocl abstract syntax (i.e., ocl metamodel) and the r2ml abstract syntax (figure 3, step 2). this transformation step is fully based on the conceptual mappings between the elements of the ocl and r2ml metamodel described in section 4.2. the transformations between the ocl metamodel and the r2ml metamodel are defined as a sequence of rules in the atl language (see figure 3, ocl2r2ml.atl and r2ml2ocl.atl). step 3. in order to serialize the r2ml model (from the mof technical space) that is obtained in the previous step into the r2ml xml concrete syntax (i.e., to the xml technical space), we first need to use the r2ml2xml.atl transformation (figure 3, step 3) to get an xml model from r2ml model. after applying this transformation to the input r2ml model xml models are stored in the model repository (r2ml rule xml model from figure 3). the output xml model conforms to the xml metamodel. such xml model is serialized into the r2ml xml format in the next step. [mgg*07] gives details about bridging the r2ml concrete and abstract syntax. step 4. the step is the xml extraction from the mof technical space to the xml technical space (step 4 in figure 3). we transform the xml model (shown in figure 3) which conforms to the mof-based xml metamodel and is generated in step 3 to an r2ml rule represented the r2ml xml concrete syntax, which is shown in figure 2. an r2ml rule in the r2ml xml concrete syntax can be transformed into some other language for which there is a translator defined with the r2ml language [rtr07], [wk03]. we have also defined the opposite transformations, from the xml metamodel into the r2ml metamodel (xml2r2ml.atl in figure 3), and from the r2ml metamodel into the ocl metamodel (r2ml2ocl.atl in figure 3). as the atl toolkit has the xml injector tool, that can transform an r2ml rule from the r2ml xml concrete syntax into the xml metamodel (i.e., the mof technical space), such an xml model can then be transformed into an r2ml model by using the xml2r2ml.atl transformation. as well, by using the r2ml2ocl.atl transformation, we can transform that r2ml model into the ocl model. the atl toolkit has also the ebnf extractor tool that can extract an ocl model (i.e., from the mof technical space) into the ocl concrete textual syntax by using the ocl tcs that we defined. in this sharing ocl constraints by using web rules proc. ocl4all 2007 15 / 18 way, we have enabled a round-trip engineering between the r2ml general rule interchange language and the ocl language). 6 discussion the transformations implemented between the ocl and r2ml abstract syntax comprise translation of the ocl invariants. however, we have yet not finalized the implementation of all ocl iterator construct variations (e.g., select, forall, and collect), because those constructs do not exists in other rule languages, and thus r2ml. our current transformations do not support the full transformation of all uml class related elements (e.g., associations) to r2ml. in the future, we plan to support fully the translation of all uml (core) model elements into the r2ml vocabulary. this will enable us to recognize property types in the ocl textual concrete syntax (e.g., when a property is referenced via another property). with the currently implemented solution, we can translate an ocl invariant from figure 1 into r2ml rule (see figure 2) and then into some other language for which there is a transformation with r2ml already defined. for example, we can translate that ocl invariant into a swrl rule [hpb*04], as we have defined transformations between swrl and r2ml [mgg*06]. as we have shown in this paper, our transformations can translate ocl invariants into the r2ml integrity rules. however, our ocl parser also supports ocl derivation rules (i.e., "derive" expressions), and we plan to extend our transformations between ocl and r2ml to enable for the translation between ocl derive rules and r2ml derivation rules. generally, this will only require adding rules for translating head of ocl derive rules, since their body expression is the same as in invariants (and that is represented with the oclexpression element in the ocl metamodel). once we support derivation rules, it will be possible to translate ocl rules into f-logic, jess, ruleml, which are supported by the present r2ml translators for derivation rules [rtr07]. we have tested our transformations between ocl and r2ml on 25 ocl invariant examples which included all of the ocl expressions described in section 4.3. those ocl invariants are collected from different sources such as eu rent case study [euc05], warmer and kleppe’ book [wk03], and dresden ocl toolkit (i.e., ocl test and demonstration constraints) [dot07]. all these ocl invariants are also translated to swrl [hpb*04] via r2ml. note also that the complete source code of the transformations presented can be found in the atl transformations zoo [atl07b] [atl07c]. 7 conclusion in this paper, we have shown how to transform rules between r2ml and ocl by employing model transformation principles. we have mapped ocl invariants into the r2ml integrity rules, and thus we enabled sharing ocl invariants with other rule languages. in the current implementation, we support only ocl invariants, but in the next versions of our transformation, we plan to support other kinds of the ocl constraints (i.e., derive, init, pre and postconditions), which we have already supported in the tcs-based parser and lexer for ocl. the mappings between r2ml and ocl do not cover ocl collection operators completely, but just a basic ones (as it has been shown in section 4.3). we have made this decision since all of the ocl collection operations could not be represented in the r2ml, because the r2ml does not support collection operators as ocl does. note that the desing of the r2ml is based on a hypothesis that most of web rule languages (e.g., f-logic, jess, jenarules, ilog jrules, and jboss rules) do not have collection operators supported in ocl. eceasst 16 / 18 volume 9 (2008) the transformation implementation is done by using the atl (between ocl and r2ml, and the r2ml mof-based abstract syntax and r2ml xml schema) and the tcs (between the ocl mof-based abstract syntax and the ocl textual concrete syntax). the solution presented in this paper represents the first practical example of approaching web and software engineering rule and constraints standards, after the activities done in the odm standardization [gdd06]. to the best of our knowledge, there is no available solution of mapping between web rule languages and ocl, and thus our solution represents an important contribution to the further reconciliation of the software engineering and web communities. we hope that our results will stimulate collaborative research of the two communities, so that the designs of rule languages (e.g., rif) will integrate needs and best practices of both communities. for example, in this paper, we demonstrated that the current web rule languages (r2ml and rif) do not have support for advance ocl collection operators, and this could be an important input of the ocl community to the rif standardization efforts. this could allow developers to leverage ocl when model semantic web applications. a similar approach to ours is applied in the odm specification [odm06] where the (model) transformations between owl and the languages such as uml, topic maps, and er models are defined on the level of their abstract syntax (i.e., metamodels). our solution goes one step further and demonstrates how to bridge between concrete and abstract syntax of rule languages. besides the obvious benefit of developing transformations between rule languages on the level of abstract syntax, the use of model transformations and languages such as atl is more suitable than xslt. although, in principle, we could use xslt to map between abstract syntax thanks to xmi in which all mof-based metamodels can be stored, the available analysis of the use of xslt for sharing knowledge indicates that xslt is hard to maintain where modifications of input and output formats can completely invalidate previous versions of xslts [jg05]. we are now in the phase of the evaluation of the results of the translation between the ocl and r2ml languages, and potentials for sharing rules between ocl and other rule languages via r2ml. in this paper, we just reflected on an exchange with the swrl language, while our subsequent analysis will fully explore this exchange and exchange of ocl constraints with other relevant rule languages such as jess, jena, and f-logic. in our future publications, we are going to report on transformation implementation in more detail and evaluation results. we also plan to use this approach to provide mappings between r2ml, web services, and policy rule-based languages (e.g., kaos and rei). this will enable modeling web services and policies by using mde principles and will be a further reconciliation of web research efforts with mde principles. 8 references [atl07a] atlas transformation language (atl), http://www.sciences.univnantes.fr/lina/atl, 2007. [atl07b] atl scenario ocl to r2ml, http://www.eclipse.org/m2m/atl/atltransformations/#ocl2r2ml. [atl07c] atl scenario: r2ml to ocl: http://www.eclipse.org/m2m/atl/atltransformations/#r2ml2ocl. sharing ocl constraints by using web rules proc. ocl4all 2007 17 / 18 [bkk02] k. baclawski, m. m. kokar, p. a. kogut, l. hart, j. e. smith, j. letkowski, p. emery, software and systems modeling, vol. 1, no. 2, pp. 142-156, 2002. [cra01] s. cranefield. uml and the semantic web, in proceedomgs of the int’l semantic web workshop symposium, stanford university, ca, usa, 2001. [dot07] dresden ocl toolkit, technische unversität dresden, software engineering group, http://dresden-ocl.sourceforge.net, 2007. [euc05] eu rent case study, http://www.eurobizrules.org/ebrc2005/eurentcs. [gdd06] d. gašević, d. djurić, v. devedžić. model driven architecture and ontology development, springer, berlin, 2006. [gin06] a. ginsberg. rif use cases and requirements, w3c working draft, http://www.w3.org/tr/rif-ucr/, 2006. [hbg*06] d. hirtle, h. boley, b. grosof, m. kifer, m. sintek, s. tabet, g. wagner. schema specification of ruleml 0.91, 2006. [hpb*04] i. horrocks, p. f. patel-scheider, h. boley, s. tabet, b. grosof, m. dean. swrl: a semantic web rule language combining owl and ruleml, w3c member submission, http://www.w3.org/submission/swrl/, 2004. [jg05] j. jovanović, d. gašević. xml/xslt-based knowledge sharing, expert systems with applications, vol. 29, no. 3, pp. 535-553, 2005. [jbk06] f. jouault, j. bézivin, i. kurtev. tcs: textual concrete syntax, in proceedings of the 2nd amma/atl workshop atlas group (inria & lina), nantes, france, 2006. [kba02] i. kurtev, j. bézivin, m. aksit. technological spaces: an initial appraisal, in proceedings of the coopis, doa'2002 federated confs., industrial track, irvine, usa, 2002. [mgg*06] m. milanović, d. gašević, a. giurca, g. wagner, v. devedžić. on interchanging between owl/swrl and uml/ocl, in proceedings of the 6th workshop on ocl for (meta-)models in multiple application domains, pp. 81-95, 2006. [mgg*07] m. milanović, d. gašević, a. giurca, g. wagner, s. lukichev, v. devedžić. bridging concrete and abstract syntax of web rule languages, in proceedings of the 1st int’l conference on web reasoning and rule systems, innsbruck, austria, 2007. eceasst 18 / 18 volume 9 (2008) [mof06] omg meta object facility (mof) core, v2.0. omg document formal/06-0101, http://www.omg.org/cgi-bin/doc?formal/2006-01-01, 2006. [odm06] omg odm. ontology definition metamodel, 6th revised submission, 2006. [ocl06] omg ocl. object constraint language, omg specification, version 2.0, formal/06-05-01, http://www.omg.org/docs/formal/06-05-01.pdf, 2006. [r2ml07] r2ml. the rewerse i1 rule language, http://oxygen.informatik.tucottbus.de/rewerse-i1/?q=node/6, 2007. [rtr07] r2ml translators. http://oxygen.informatik.tu-cottbus.de/rewersei1/?q=node/15, 2007. [sbvr05] omg semantics of business vocabulary and business rules (sbvr), revised submission to bei rfp br/2003-06-03, http://www.omg.org/docs/bei/05-08-01.pdf, 2005. [rtj06] translator from ruleml to jess. http://www.ruleml.org/jess/, 2006. [qvt05] omg mof qvt final adopted specification. omg document 05-11-01, http://www.omg.org/docs/ptc/05-11-01.pdf, 2005. [uml06] omg, unified modeling language (uml) 2.0, docs. formal/05-07-04 & formal/05-07-05, 2006. [wgl05] g. wagner, a. giurca, s. lukichev. r2ml: a usable interchange format for rich syntax rules integrating ocl, ruleml and swrl, in proceedings of reasoning on the web 2006, row2006, edinburgh, scotland, 2006. [wk03] j. warmer, a. kleppe. the object constraint language: getting your models ready for mda, second edition, addison wesley, 2003. << /ascii85encodepages false /allowtransparency false /autopositionepsfiles true /autorotatepages /all /binding /left /calgrayprofile (dot gain 20%) /calrgbprofile (srgb iec61966-2.1) /calcmykprofile (u.s. web coated \050swop\051 v2) /srgbprofile (srgb iec61966-2.1) /cannotembedfontpolicy /warning /compatibilitylevel 1.4 /compressobjects /tags /compresspages true /convertimagestoindexed true /passthroughjpegimages true /createjdffile false /createjobticket false /defaultrenderingintent /default /detectblends true /colorconversionstrategy /leavecolorunchanged /dothumbnails false /embedallfonts true /embedjoboptions true /dscreportinglevel 0 /emitdscwarnings false /endpage -1 /imagememory 1048576 /lockdistillerparams false /maxsubsetpct 100 /optimize true /opm 1 /parsedsccomments true /parsedsccommentsfordocinfo true /preservecopypage true /preserveepsinfo true /preservehalftoneinfo false /preserveopicomments false /preserveoverprintsettings true /startpage 1 /subsetfonts true /transferfunctioninfo /apply /ucrandbginfo /preserve /useprologue false /colorsettingsfile () /alwaysembed [ true ] /neverembed [ true ] /antialiascolorimages false /downsamplecolorimages true /colorimagedownsampletype /bicubic /colorimageresolution 300 /colorimagedepth -1 /colorimagedownsamplethreshold 1.50000 /encodecolorimages true /colorimagefilter /dctencode /autofiltercolorimages true /colorimageautofilterstrategy /jpeg /coloracsimagedict << /qfactor 0.15 /hsamples [1 1 1 1] /vsamples [1 1 1 1] >> /colorimagedict << /qfactor 0.15 /hsamples [1 1 1 1] /vsamples [1 1 1 1] >> /jpeg2000coloracsimagedict << /tilewidth 256 /tileheight 256 /quality 30 >> /jpeg2000colorimagedict << /tilewidth 256 /tileheight 256 /quality 30 >> /antialiasgrayimages false /downsamplegrayimages true /grayimagedownsampletype /bicubic /grayimageresolution 300 /grayimagedepth -1 /grayimagedownsamplethreshold 1.50000 /encodegrayimages true /grayimagefilter /dctencode /autofiltergrayimages true /grayimageautofilterstrategy /jpeg /grayacsimagedict << /qfactor 0.15 /hsamples [1 1 1 1] /vsamples [1 1 1 1] >> /grayimagedict << /qfactor 0.15 /hsamples [1 1 1 1] /vsamples [1 1 1 1] >> /jpeg2000grayacsimagedict << /tilewidth 256 /tileheight 256 /quality 30 >> /jpeg2000grayimagedict << /tilewidth 256 /tileheight 256 /quality 30 >> /antialiasmonoimages false /downsamplemonoimages true /monoimagedownsampletype /bicubic /monoimageresolution 1200 /monoimagedepth -1 /monoimagedownsamplethreshold 1.50000 /encodemonoimages true /monoimagefilter /ccittfaxencode /monoimagedict << /k -1 >> /allowpsxobjects false /pdfx1acheck false /pdfx3check false /pdfxcompliantpdfonly false /pdfxnotrimboxerror true /pdfxtrimboxtomediaboxoffset [ 0.00000 0.00000 0.00000 0.00000 ] /pdfxsetbleedboxtomediabox true /pdfxbleedboxtotrimboxoffset [ 0.00000 0.00000 0.00000 0.00000 ] /pdfxoutputintentprofile () /pdfxoutputcondition () /pdfxregistryname (http://www.color.org) /pdfxtrapped /unknown /description << /fra /enu (use these settings to create pdf documents with higher image resolution for improved printing quality. the pdf documents can be opened with acrobat and reader 5.0 and later.) /jpn /deu /ptb /dan /nld /esp /suo /ita /nor /sve >> >> setdistillerparams << /hwresolution [2400 2400] /pagesize [612.000 792.000] >> setpagedevice the implementation of the cha-q meta-model: a comprehensive, change-centric software representation electronic communications of the easst volume 65 (2014) proceedings of the international workshop on software quality and maintainability (sqm 2014) the implementation of the cha-q meta-model: a comprehensive, change-centric software representation coen de roover, christophe scholliers, viviane jonckers javier pérez, alessandro murgia, serge demeyer 15 pages guest editors: lodewijk bergmans, tom mens, steven raemaekers managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst the implementation of the cha-q meta-model: a comprehensive, change-centric software representation coen de roover, christophe scholliers, viviane jonckers javier pérez, alessandro murgia, serge demeyer software languages lab, vrije universiteit brussel ansymo group, universiteit antwerpen abstract: although contemporary software development processes have embraced the need for continuous change, most development tools still assume that they act upon a single complete release of the system. the cha-q project (change-centric quality assurance) aims to strike a balance between agility and reliability through change-centric quality assurance tools. these tools are to share a first-class representation of changes to software artefacts. in this paper we present the cha-q meta-model that defines this representation and highlight important characteristics of its implementation: an object-oriented api, persistency through a graph database, and a strategy for tracking the history of artefacts in a memory-efficient manner. keywords: change-centric, meta model, quality assurance 1 introduction in this paper, we introduce the cha-q meta-model that owes its name to the cha-q project (change-centric quality assurance)1. this project aims to strike a balance between agility and reliability through change-centric quality assurance tools. these tools are to share a first-class representation of the artefacts that comprise a software system (source code, files, bugs, bug comments, mailing lists, . . . ), as well as the complete history of all individual changes to these artefacts —a representation defined by the cha-q meta-model. the main contributions of this new meta-model are: • a first-class representation for changes to various software artefacts. • a uniform and extensible object-oriented api. • an implementation that uses a graph database for persistency, while tracking the history of software artefacts in a memory-efficient manner. the latter relieves developers from secondary concerns such as memory usage and storage requirements. in the remainder of this paper we present the related work that serves as background for our proposal in section 2. we give an overview of our meta-mode in section 3, introduce potential quality-related application scenarios for this metamodel in section 4, highlight important properties of its implementation in section 5 and the underlying persistence strategy in section 6. subsequently we demonstrate the meta-model in section 7 by creating models for a use case, and present the results of a preliminary performance evaluation in section 8. 1 http://soft.vub.ac.be/chaq/ 1 / 15 volume 65 (2014) http://soft.vub.ac.be/chaq/ the implementation of the cha-q meta-model 2 related work within the software engineering community, the use of meta-models to provide common representation frameworks that can be leveraged by various software engineering tools is not new. one example of such a generic meta-model to represent object-oriented systems is the famix meta-model [tddn00]. famix offers a language-independent, first-class representation of object-oriented, class-based languages that has been used by a wide range of software engineering tools such as the moose reverse engineering tool suite. famix3 [dab+11] represents the most recent incarnation of this meta-model. next to such representations of object-oriented programs, a body of work exists with regard to modeling multiple versions of a system. a good overview of the early research in this area can be found in the book chapter by d’ambros et al. [dglp08]. hismo [gd06] extends the famix meta-model such that multiple versions of a software system can be represented. for each version in the history, a complete model of that version — along with information that relates source-code entities over various versions — is stored. the more recent orion [lddf11] meta-model also represents multiple versions of famix entities, but does this in a manner that avoids copying entities that have not changed between versions. its strategy has not only been observed to result in memory-efficient models, but these models can also be constructed faster as fewer allocations have to be performed. another body of work relies on meta-models that represent change operations to a system as first-class objects. the spyware tool suite by robbes et al. [rl06, rl08], in contrast, records all changes that are made to a system using the integrated development environment (ide). internally, spyware provides a fine-grained model where each individual change to the system is stored. the cheops [ebr09] system by ebraert et al. offers a similar meta-model for representing and storing changes. both approaches target smalltalk. another similar approach for the reification of changes is the one taken by hattori [hat12] in syde, a tool that logs the changes made by several developers in parallel. syde targets java. the unicase [khs09, hk10] tool represents changes to emf models as first-class entities to facilitate conflict detection and resolution. the tool suite around operationrecorder [mkoh12] employs an extremely fine-grained representation of edit operations to text. so far, we have only discussed meta-models that represent the state, history or individual changes to the source code of a system. the most influential meta-model for representing issue tracking information is the one used by the evolizer [gfp09] tool suite. an earlier version is detailed along with a representative meta-model for versioning meta-data (e.g., commit messages) in [mar06]. to conclude, while existing meta-models define a representation of source code or changes, we can observe that none provides a complete representation of both —let alone of the other artefacts of a software system (versions, issues, mailing lists, . . . ) and their changes. 3 overview of the cha-q meta-model the cha-q meta-model defines a representation of the various artefacts that comprise a software system, as well as the complete history of all individual changes to these artefacts. based on proc. sqm 2014 2 / 15 eceasst our experiences with the famix [tddn00], cheops [ebr09] and ring [ug12] meta-models, we have opted for an object-oriented representation. figure 1 depicts its high-level uml class diagram. changes are modeled as first-class objects that can be analyzed, repeated and reverted (cf. change). to this end, we provide a representation of the dependencies between two changes (cf. change-dependency). these imply a partial ordering within a given set of changes (cf. changeset). the corresponding elements are depicted in blue. similar metamodels have already proven themselves for representing changes to code (e.g., spyware [rl08], cheops [ebr09] and syde [hat12]) and to emf models (e.g., unicase [khs09]). our metamodel goes beyond the state of the art by representing changes to the properties of any system artefact (i.e., source code, files, commits, bugs, e-mails, . . . ) in a uniform manner. this uniform treatment of an artefact’s properties is inspired by the reflective api of the eclipse jdt. the corresponding elements (cf. propertydescriptor) are depicted in brown. applying a change results in a new state for its subject (cf. entitystate). figure 1 depicts the corresponding elements in yellow. examples include abstract syntax trees (cf. astnode) and issues managed by an issue tracker (cf. issue). the meta-model elements related to issue tracking and e-mail communication are inspired by the meta-model used by the evolizer [gfp09] and stnacockpit [pg10] tools respectively. figure 1 depicts them in green. snapshots correspond to the state of all of a system’s artefacts at a particular point in time as seen by a particular developer (cf. snapshot). the delta between two snapshots is a set of changes (cf. changeset). snapshots of the entire system can be inspected and compared. this connection is similar to the one between ring’s history and change meta-model [ug12]. revisions (cf. revision) are snapshots placed under control of a version control system. figure 1 depicts the corresponding elements, such as a modification reports and branches, in pink. these are inspired by the revision meta-model used by evolizer [gfp09]. 4 potential applications of the cha-q metamodel the cha-q metamodel offers a series of opportunities to develop new techniques and tools in the context of software quality evaluation and improvement. the fine-grained combined record of source code changes and issue report evolution could help improving the bug triaging tasks. the change information can be used to identify misclassified bug reports more easily and to verify whether anomalies occur in the bug database (e.g. wrong severity, assigned to the wrong component). a fine-grained change information can also be useful for estimation and recommendation purposes, e.g. once bugs get reported, determine who is the best person in the team to handle the request and make a reliable estimation for the time to fix the bug. testing activities can also be improved by using the cha-q metamodel, for example in determining the impact of changes on both the test and production code, to persuade team members to increase test activities. the metamodel can also support test optimisation. instead of running all tests for a given release, the developers could run only those tests that are potentially affected by a given change. this allows for instant feedback on the changes that cause failing tests, saving valuable time in identifying the precise location of a defect. 3 / 15 volume 65 (2014) the implementation of the cha-q meta-model f igure 1: o verview of key c h a -q m eta-m odelelem ents. proc. sqm 2014 4 / 15 eceasst the change information stored in our metamodel can also be used to support a variety of maintenance activities such us releasing a new version of an api together with an executable list of patches, that could be seamless applied in order to update all client code, or re-playing bug fixes, that were successful on a given release, on a variant release, thus avoiding tedious manual synchronisation of branches. 5 implementation highlights the cha-q meta-model associates a unique identifier (cf. entityidentifier) with each change subject (cf. entitystate). this enables tracking the evolution of a single subject throughout the history of a system. for each subject, a history of previous states is kept in a memory-efficient manner; successive states share the values of properties that do not change. we deem this necessary as copying of entity states has been observed to consume 3gb of memory for the syde change-centric representation of a version repository of 78mb [hat12]. however, a selective cloning approach would be impractical to implement as all entities are interconnected transitively. we therefore follow the approach advocated by the orion [lddf11] and ring [ug12] history meta-models. property values are identifiers (cf. entityidentifier) that are looked up with respect to a particular snapshot. to ensure that this additional level of indirection does not endanger type safety, our implementation relies on java generics and property annotations. the property initializer of a variabledeclaration, for instance, can only have expression identifiers as its value. as shown in section 7, the programmer can easily enforce such constraints in the cha-q metamodel. despite this memory-efficient representation, the working memory of a typical development terminal is unlikely to suffice for the entire history of the industry-sized projects that we aim to support. our implementation therefore persists instances of meta-model elements to a neo4j2 graph database and retrieves them on a strict as-needed basis. use of weak references ensures that instances that are no longer needed can be reclaimed by the garbage collector. our two-way mapping is driven by run-time reflection about the aforementioned property annotations. this renders our implementation extensible. extensive caching ensures that reflection does not come at the cost of a performance penalty. 5.1 property annotations the cha-q meta-model ensures type safety of the fields of the entitystate by means of annotations. as shown in figure 2, there are three annotations defined in the be.ac.chaq.model.entity package. • simpleproperty: this annotation can adorn the fields of any class that extends entitystate. all fields annotated with the simpleproperty annotation must be serializable. when a field is annotated with a simpleproperty access to this field is provided through the getproperty method provided by the entitystate 2 http://www.neo4j.org 5 / 15 volume 65 (2014) http://www.neo4j.org the implementation of the cha-q meta-model figure 2: cha-q annotations class. note that adding the annotation to his class is the only thing the programmer has to do. • entityproperty: this annotation is used to flag that the annotated field is used in order to store another entitystate object. again this property can be read by making use of the getproperty method defined in the entitystate class. • entitylistproperty: this annotation is very similar to the entityproperty annotation but instead of indicating a single field that refers to an entitystate this annotation must be used to indicate a list of entity states. in section 7 we give an overview of how the meta-programmer uses these annotations in order to create a custom entitystate. 5.2 memory-efficient state tracking as mentioned before, copying an entity each time its state changes (the approach taken by syde [hat12]) would be prohibitively expensive for large projects. to minimize memory consumption, successive entitystate instances have to share the values of properties that do not change. as all entities are interconnected transitively and these connections can be navigated in multiple directions (e.g., from a method to its declaring class and from a class to its declared methods), consistency would be difficult to maintain using a selective shallow and deep cloning approach. following orion [lddf11] and ring [ug12], we store the values of properties as entityidentifier instances that have to be looked up starting in a particular snapshot. instances of class snapshot correspond to the state of all of a system’s artefacts at a particular point in time as seen by a particular developer. to this end, each snapshot maintains identifiertostate mappings from the unique identifier of an entity to its current state within the snapshot. performing a propertychange therefore amounts to making a shallow clone of the current entitystate of the change subject, updating the snapshot’s current mapping from the subject’s entityidentifier to the new entitystate of the change subject, and updating the property’s value in the newly created entitystate. deleting an entity amounts to removing its identifiertostate mapping, rendering the corresponding entity inaccessible in the current snapshot. each snapshot does keep track of all changed, created and deleted entity identifiers for inspection purposes. increased access cost is the price to pay for this sharing of property values that do not change between successive states of an entity. implementation-wise, indirect lookups can by hidden by having accessor methods return proxies that wrap an entity identifier with a snapshot and proc. sqm 2014 6 / 15 eceasst forward all requests to the corresponding entity state. orion [lddf11] and ring [ug12] rely on a similar proxy to provide snapshot-unaware tools a view on a particular snapshot. note that our meta-model’s snapshots comprise a middle ground between a complete versionbased and a complete change-based representation of a system’s evolution. depending on their timespan, snapshots can accumulate the effect of a single or of several changes. as such, they can be used to represent eras of a system’s lifetime about which fine-grained change information is unavailable or not desired. 5.3 reflection cache the annotations defined by the programmer are evaluated at runtime by making use of reflection. these reflection operations are relatively slow and therefore, the implementation of the metamodel makes use of a cache to avoid having to repeat the reflective operations over and over again. in the implementation of the entitystate class getting and setting properties is done by making use of a propertydescriptorsmap. for every class this map contains a property descriptor for each of the fields of the entity state. the programmer does not need to built this map himself. instead, whenever a property of a class is requested the property descriptor map is consulted to retrieve the map for this particular class. if there is no entry in the property descriptor map a new entry is built by using reflection. the constructed property descriptor map is then stored in the property descriptors map for later retrieval. because this map is cashed in the entity state class the reflective operations are kept to a minimum. 5.4 persistence considerations while the cha-q meta-model already provides a lot of beneficial measurements in order to make efficient use of memory, loading all revision of a large software artefact in memory is currently not possible. therefore, the cha-q meta-model makes use of weak references to ensure that instances that are no longer needed can be reclaimed by the garbage collector. this does not mean that the garbage collected references are simply thrown away. the meta-model automatically persists the snapshots of the project that can not be fit into the memory and restores these snapshots when they are needed in order to perform an analysis. however, the programmer who makes use of the cha-q meta-model is not confronted with the way the meta-model is serialised or deserialised. form the programmers point of view all the versions of the project can be consulted. in the next section we give a more in depth overview of the persistence model of the cha-q meta-model. 6 persistence the persistency model of the cha-q meta-model is a direct translation of the object oriented classes to a graph database. the advantage of using a graph database instead of more conventional databases is that there is a better mapping of the object-oriented representation of the cha-q meta-model onto a graph than onto tables. for example, a node in the database that represents a method declaration simply has an outgoing edge to the body of that method just 7 / 15 volume 65 (2014) the implementation of the cha-q meta-model s i ii es c s i i es ssnapshot identifier i esenitity state reference property predecessor figure 3: cha-q graph database model like in the object-oriented representation. moreover, once a node in the graph database has been identified, retrieval of semantically close nodes can be done very fast as this is just a matter of following the outgoing edges. 6.1 graph representation the size of the projects that we aim to support is much bigger than the memory size of a normal desktop computer. therefore, the persistence of the meta-model is not only important for storage and retrieval, it is an essential part of the meta-model to deal with large projects. there is a one-to-one mapping between how the graph database stores nodes and relationships and the cha-q meta-model classes. figure 3 shows a possible serialisation of the graph database. there are four types of nodes in the model, snapshot nodes, identifier nodes, entity state nodes and constant nodes. each snapshot node has a set of edges pointing to the identifier nodes which are contain in the snapshots. all snapshots besides the root snapshot also have an outgoing edge to the predecessor snapshot. identifier snapshots have a reference to their entity state nodes. for each propriety of the entity state, the entity state node has an outgoing property edge. these edges point either to identifier node or to a constant node. entity state nodes keep state in order to identify from which class they were serialized in the database. as can be seen, the graph database model follows the memory model closely. by reusing the nodes in the graph the storage requirements are significantly reduced. 6.2 example serialization: method declaration in this section, we give a graphical overview of the graph serialization process. as all the entity states of the software project are translated into nodes, showing even a medium sized project would be overwhelming. therefore, we only show a very small fraction of a method declaration. the serialization graph can be seen in figure 4. besides the actual method declaration we also show the node that represent the snapshot. as shown before a snapshot does not have direct references to the corresponding entity states. instead a snapshot has a number of outgoing relationships which point to entity identifiers. in the example the snapshot node has number 1. from all the outgoing edges only three are shown. in practice the snapshot has much more than three outgoing edges but in order to keep the overview they are not shown here. the rightmost edge points proc. sqm 2014 8 / 15 eceasst figure 4: graph view of a stored method declaration to a node with number 1106, this node represents the method declaration. as expected this node has a number of fields that are represented again with outgoing edges. in the case of a method declaration a node has a returntype2, a body, a parent and a name. just as in the object model, the body declaration is not an entitystate but a entitystateidentifier that can be use in order to retrieve the entitystate from the snapshot. 7 modeling entities in the cha-q meta-model in this section, we given an overview of how to use the meta-model by showing the modeling process for the definition of a custom entitystate. the entity state of our concrete use case is part of the java ast-node meta-model. we have implemented entity states for all java ast-nodes but here we limit ourselves to the implementation of a single ast-node: variabledeclaration. the implementation of the other java ast-nodes follows the same recipe. 7.1 java ast nodes figure 5 shows a part of the java classes that are involved with the definition of the variabledeclaration class. as can be seen the ast node is an extension of the entitystate, this is a necessary prerequisite in order to make use of the annotations offered by the meta-model. the variabledeclaration class has three fields, astidentifier, extradimensions and initializer. the concrete implementation of the variabledeclaration is shown in figure 6. as can be seen the fields of this class all carry annotations. the extra dimensions field is annotated with a simpleproperty annotation. the value of the annotation specifies of which class the object stored in the field should be an instance. in the case of the extradimensions field this is the 9 / 15 volume 65 (2014) the implementation of the cha-q meta-model figure 5: variable declaration astnode class integer. similarly, the name field is annotated with an entityproperty annotation. this annotation also requires that the class of the field is specified as a value which must be serializable. in the case of the name field this is a simplename class. public class variabledeclaration extends astnode { @entityproperty(value = simplename.class) protected astidentifier name; @simpleproperty(value = integer.class) protected integer extradimensions; @entityproperty(value = expression.class) protected astidentifier initializer; //... } figure 6: annotations in the variabledeclaration class. proc. sqm 2014 10 / 15 eceasst 7.2 applying changes in the previous section, we have shown how to implement a custom entitystate. in this section, we show how the programmer benefits from using these annotations when applying changes in the model. the cha-q meta-model defines a number of ways in which entity states can be changed. the implementation of these changes is completely defined in terms of entity states and property descriptors. because changes are defined as a high-level abstraction all the predefined and future change classes can be applied over the custom made entity states as well. in this section we show how the variabledeclaration defined in the previous section can be created with a creationchange and then modified with simplepropertychange. note that these changes are predefined and offered to the programmer as part of the meta-model. figure 7 shows the creation of the variable declaration. note that the creation change c is instantiated at first but the variable declaration is only added to the snapshot when the method perform is executed on the change. 1 testentitystate es = new testentitystate(); 2 creationchange c = new variabledeclaration(rootsnapshot, es); 3 c.perform(); figure 7: creating and adding entity states to a snapshot. figure 8 shows how the extradimensions of the method declaration can be changed to the value 12 . again the change is only executed after the perform method of the change has been invoked. 1 propertydescriptor pd = 2 es.getpropertydescriptornamed("extradimensions"); 3 simplepropertychange spc = 4 new simplepropertychange(rootsnapshot, es, pd, 12); 5 entitystate newes = spc.perform(); figure 8: applying changes over the entity states. as already discussed before the programmer does not need to be concerned with persistence while modelling custom entity states. 8 evaluation in this section, we report on an early evaluation of the cha-q meta-model. while the metamodel is still in development we can already successfully create a model for java projects and deduce coarse grained changes. these coarse grained changes are currently limited to the file level. whenever a change to a file is detected between two successive revisions of the software 11 / 15 volume 65 (2014) the implementation of the cha-q meta-model artefact a modified change is deduced between the two compilation units. as these changes are very coarse grained the potential reuse is much higher. when the cha-q meta-model is instrumented with a good change distiller it will become possible to record changes at the level of individual statements instead of on the file level. therefore, the potential reuse will become much higher and consequently the memory and storage consumption will be reduced even farther. from experiments with such coarse changes it already became clear that the cha-q meta-model memory significantly reduces the memory footprint needed for storing the meta-model. 8.1 test data we have evaluated the performance of the cha-q meta-model by applying our meta-model over a small web-application called exapus 3. exapus is a web application for exploring the usage of apis within a single project (i.e., project-centric exploration) and across a corpus of projects (i.e., api-centric exploration) along the dimensions of where, how much and in what manner [dlp13]. the project consists of 127 compilation units, 132 class declarations and 1173 method declarations. a quick measurement showed that the memory consumption a single revision with java jdt nodes is about 122mb. the changes in this project are very coarse grained and on average 22,5 files are modified which constitutes about one sixth of the total files in each revision. this means that the potential reuse between every iteration consists of 5/6 of the total number of files. 8.2 storage and memory performance in order to prove our claims that the cha-q meta-model can drastically reduce the memory and storage requirements we have done a number of micro benchmarks. the serialisation of a single revision consists of about 194149 nodes, 223979 properties, and 194147 relationships divided over 32 distinct relationship types. by only storing the changes between each revision the storage requirements of the cha-q meta-model can be significantly reduced. we have implemented the importation and serialisation of the meta-model in two different ways. the naive implementation creates the meta-model as described but instead of reusing the different versions of a snapshot it creates a completely new snapshot for each revision. this implementation represent current practices which are readily available but do not optimise for storage and memory. because of the one-to-one mapping of the object-oriented representation to the graph database the figures for the memory requirements are very similar. the graph representation requires almost exactly the same amount of space when serialised as it requires memory in the java vm. the performance evaluation with respect to the database storage overhead can be seen in figure 9. a first observation is that our measurements are confirming the observations of prior work [hat12]. the naive implementation requires already over 3.4 gb of storage space. in contrast after revision 33 the cha-q meta-model requires 2.5 times less storage space. while this seems far away from the 5/6 potential reuse we found that the larger files in the system were adjust more than the smaller files therefore the measurement based on file number do not give a complete image of the potential reuse. while 2.5 times less space is already a good number we are working to also feed the model with fine grained changes which should drastically increase the potential reuse and consequently decrease the storage footprint. 3 available online: https://github.com/cderoove/exapus proc. sqm 2014 12 / 15 https://github.com/cderoove/exapus eceasst 0" 500" 1000" 1500" 2000" 2500" 3000" 3500" 4000" 1" 2" 3" 4" 5" 6" 7" 8" 9" 10" 11" 12" 13" 14" 15" 16" 17" 18" 19" 20" 21" 22" 23" 24" 25" 26" 27" 28" 29" 30" 31" 32" 33" d at ab as e' si ze '(m b) ' ' revision' naive" cha3q" figure 9: storage overhead of the cha-q meta-model versus a naive implementation. 9 conclusion and future work we presented the cha-q meta-model, a novel meta-model that provides a detailed representation of the artefacts that comprise a software system, as well as the complete history of all individual changes to these artefacts. these changes are modeled as first-class objects that can be analyzed, repeated and reverted. the cha-q meta-model is the first to do so for changes to artefacts other than a system’s source code (e.g., bugs, bug comments, project e-mails, . . . ). the meta-model supports tracking the evolution of a single entity from its creation onwards, such as the traceability link between a test case and its corresponding requirement. as such an entity is subject to changes, a means is required to uniquely identify each entity. to this end, the meta-model provides a hierarchy of identifier classes. applying a change results in a new state for its subject. for efficiency reasons, successive states share the values of properties that do not change. the suggested implementation strategy addresses the problem of maintaining consistency in meta-models of which all entities are interconnected transitively. snapshots are our meta-model’s means to represent the collective state of all of a system’s artefacts as seen by a particular developer at a particular point in time. snapshots can accumulate the effect of a single or of several changes as desired —thus providing a configurable compromise between the extremes of completely version-based and completely change-based representations of a system’s evolution. revisions are modeled as snapshots that are placed under control of a version control system. the entities they are related to represent versioning information. the meta-model currently defines classes for representing the state, evolution and changes to versioning information, bugs and source code. for the latter, the meta-model defines classes representing abstract syntax trees (modeled after the abstract grammar of the eclipse jdt dom 13 / 15 volume 65 (2014) the implementation of the cha-q meta-model for java and the visualworks refactoring browser for smalltalk) as well as classes representing object-oriented entities and their relations (modeled after the generic, language-independent famix3 meta-model). classes representing information about a system’s requirements, test cases and traceability links will be defined and added to the model in the near future. in future work we will use the model over a wide range of application ranging from bug triaging to re-playing bug fixes as shown in section section 4. in order to do that, some additional features need to be added to the infrastructure, such as a change distiller that can infer and extract the list of occurred changes between two versions of a system and a change logger that can record the changes while the developer interacts with the ide. the benefits of this approach will be demonstrated in the future by performing several experiments with our industrial partners. bibliography [dab+11] s. ducasse, n. anquetil, u. bhatti, a. c. hora, j. laval, t. girba. mse and famix 3.0: an interexchange format and source code model family. technical report, inria lne-lirmm, 2011. [dglp08] m. d’ambros, h. gall, m. lanza, m. pinzger. analysing software repositories to understand software evolution. in mens and demeyer (eds.), software evolution. springer-verlag, 2008. [dlp13] c. de roover, r. lammel, e. pek. multi-dimensional exploration of api usage. in 21st international conference on program comprehension (icpc). pp. 152–161. 2013. [ebr09] p. ebraert. a bottom-up approach to program variation. phd thesis, vrije universiteit brussel, march 2009. [gd06] t. gı̂rba, s. ducasse. modeling history to analyze software evolution. journal of software maintenance: research and practice (jsme) 18:207–236, 2006. [gfp09] h. gall, b. fluri, m. pinzger. change analysis with evolizer and changedistiller. ieee softw. 26(1):26–33, 2009. [hat12] l. p. hattori. change-centric improvement of team collaboration. phd thesis, università della svizzera italiana, 2012. [hk10] m. herrmannsdoerfer, m. koegel. towards a generic operation recorder for model evolution. in proceedings of the 1st international workshop on model comparison in practice (iwmcp10). pp. 76–81. 2010. [khs09] m. koegel, j. helming, s. seyboth. operation-based conflict detection and resolution. in proceedings of the 2009 icse workshop on comparison and versioning of software models (cvsm09). 2009. proc. sqm 2014 14 / 15 eceasst [lddf11] j. laval, s. denier, s. ducasse, j.-r. falleri. supporting simultaneous versions for software evolution assessment. science of computer programming 76(12):1177– 1193, dec. 2011. [mar06] d. marjanovic. developing a meta model for release history systems. master’s thesis, university of zurich, 2006. [mkoh12] k. maruyama, e. kitsu, t. omori, s. hayashi. slicing and replaying code change history. in proceedings of the 27th nternational conference on automated software engineering (ase12). pp. 246–249. 2012. [pg10] m. pinzger, h. c. gall. dynamic analysis of communication and collaboration in oss projects. in collaborative software engineering. pp. 265–284. springer berlin heidelberg, 2010. [rl06] r. robbes, m. lanza. change-based software evolution. in evol ’06: proceedings of the 1st international ercim workshop on challenges in software evolution. pp. 159–164. 2006. [rl08] r. robbes, m. lanza. spyware: a change-aware development toolset. in proceedings of the 30th international conference on software engineering (icse ’08). pp. 847–850. acm, 2008. [tddn00] s. tichelaar, s. ducasse, s. demeyer, o. nierstrasz. a meta-model for languageindependent refactoring. in proceedings of international symposium on principles of software evolution (ispse00). 2000. [ug12] v. uquillas gómez. supporting integration activities in object-oriented applications. phd thesis, vrije universiteit brussel université des sciences et technologies de lille, october 2012. 15 / 15 volume 65 (2014) introduction related work overview of the cha-q meta-model potential applications of the cha-q metamodel implementation highlights property annotations memory-efficient state tracking reflection cache persistence considerations persistence graph representation example serialization: method declaration modeling entities in the cha-q meta-model java ast nodes applying changes evaluation test data storage and memory performance conclusion and future work high-level proofs about low-level programs electronic communications of the easst volume 23 (2009) proceedings of the ninth international workshop on automated verification of critical systems (avocs 2009) high-level proofs about low-level programs holger gast and julia trieflinger 15 pages guest editor: markus roggenbach managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst high-level proofs about low-level programs holger gast and julia trieflinger wilhelm-schickard-institut für informatik eberhard karls universität tübingen, tübingen, germany gast@informatik.uni-tuebingen.de trieflin@informatik.uni-tuebingen.de http://www-pu.informatik.uni-tuebingen.de/users/gast/ http://www-pu.informatik.uni-tuebingen.de/users/trieflin/ abstract: functional verification of low-level code requires abstractions over the memory model to be effective, since the number of side-conditions induced by byteaddressed memory is prohibitive even with modern automated reasoners. we propose a flexible solution to this challenge: assertions contain explicit memory layouts which carry the necessary side-conditions as invariants. the memory-related proof obligations arising during verification can then be solved using specialized automatic proof procedures. the remaining verification conditions about the content of data structures directly reflect a developer’s understanding. the development is formalized in isabelle/hol. keywords: verification of c code, pointer programs, precise memory models 1 introduction the functional verification of low-level c code has recently attracted much attention (e.g. [tuc08b, tkn07b, cmst09, rh09]). the central challenge in these applications consists in proving the disjointness of memory objects in the c memory model. unlike in strongly typed languages like java or c#, the inequality of pointers in c does not imply the disjointness of the memory regions occupied by the referenced objects: pointer arithmetic, pointer casts, and internal pointers to struct fields allow almost arbitrary overlaps. the strategy proposed in the literature is to maintain a typed view on the untyped memory: tuch et al. [tuc08b, tkn07b] employ a variant of separation logic; cohen et al. [cmst09] maintain a set of disjoint objects in a ghost variable; rakamarić et al. [rh09] use a static analysis to identify parts of c programs that obey the split-heap model [bur72]. the actual verification is then performed on the typed view. the disjointness of regions is, however, only one aspect of reasoning about low-level programs. another aspect concerns the invariants and side-conditions associated with data structures. for instance, allocated blocks in c are always contiguous in memory, i.e. overflow in the pointer arithmetic inside them is excluded. this property, in turn, enables pointers into an array to be compared by the less than operator. while it is always possible to augment assertions with suitable side-conditions, these need to be handled explicitly although they are, in fact, invariants that continue to hold through all operations. reasoning about less precise memory models is more efficient partly because the invariants are implicit. we show that it is possible to associate the invariants with descriptions of low-level memory layouts instead. 1 / 15 volume 23 (2009) mailto:gast@informatik.uni-tuebingen.de mailto:trieflin@informatik.uni-tuebingen.de http://www-pu.informatik.uni-tuebingen.de/users/gast/ http://www-pu.informatik.uni-tuebingen.de/users/trieflin/ high-level proofs about low-level programs the following function, which initializes raw memory, demonstrates the point. void init(char *p, char *q) { char *r = p; while (r != q) *r++ = 0; } for functional verification, the user would like to give the following natural loop invariant. it asserts that r runs between p and q and that the bytes from p to r have already been initialized (*a denotes reading from address a): p ≤ r ∧ r ≤ q ∧ (∀a. p ≤ a ∧ a < r −→ (*a) = 0) the crucial point to observe is that this invariant requires reasoning about pointer inequalities. to establish the invariant, p ≤ q has to be given as a precondition of the init function. however, a programmer would never initialize a memory region without this property, so that the precondition appears as a merely technical necessity. building on the lightweight separation method [gas08], we propose, instead, to make memory layouts explicit in assertions and to associate side-conditions with them. in the example, the layout will contain a ptr-block p q. it describes the memory region between addresses p and q and also includes the side-condition p ≤ q. furthermore, the proposed approach simplifies proofs about layouts [gas09] since fewer side-conditions arise (see section 3). the purpose of this paper is to show how side-conditions and invariants can be maintained implicitly with the memory layout, and that handling them implicitly leads to natural proof obligations. in low-level programs it then becomes straightforward to switch between typed and untyped views. furthermore, we show that the reasoning also covers composite objects such as structs, arrays, and linked lists. the current paper thus extends the earlier work [gas08, gas09] to byte-addressed memory and machine-level representations of values. the work presented is carried out in isabelle/hol to ensure soundness. the proofs are therefore partly interactive. however, we structure them to enable a direct comparison with automated approaches: for each algorithm, we first prove auxiliary theorems, which would become axioms in other methods. the verification itself is then essentially automatic (cf. section 2). organization section 2 gives an overview over lightweight separation. section 3 describes the maintenance of invariants associated with memory layouts. section 4 applies the resulting framework to two examples. section 5 discusses related work. section 6 concludes. isabelle notation the notation of isabelle/hol mostly uses standard mathematical conventions. a few exceptions need to be mentioned. functions, as usual in higher-order logic, are curried. the function type is denoted by ⇒. application of function f to argument a is written by juxtaposition f a. definitions of constants are written by ≡. an interval [a, b) over an ordered domain is denoted by {a..x and src->y in the typed view. this is shown automatically by proving the respective memory regions disjoint as follows. proc. avocs 2009 8 / 15 eceasst pre: m i �src : struct point� ‖ �dst : struct point� ∧ point-known γ ∧ src = src ∧ dst = dst ∧ src → x = x ∧ src → y = y post: m i �src : struct point� ‖ �dst : struct point� ∧ src → x = x ∧ src → y = y ∧ dst → x = x ∧ dst → y = y void copy point(struct point *src, struct point *dst) { int i; i = 0; [inv m i �src : struct point� ‖ �dst : struct point� ‖ src ‖ dst ‖ i ∧ point-known γ ∧ 0 ≤s i ∧ i ≤s sz-of-ty γ (struct point) ∧ src = src ∧ dst = dst ∧ �src → x� = x ∧ �src → y� = y ∧ ( ∀ j. 0 ≤s j ∧ j calls stl_project ob1.stl [ ] transformfc [ ] transformcall 1. 2. 3. :ob :title value = val :comment value = val ++ ++++++ ++ ++ ++ ++ ++ ++ ++ transformfc [name != `ob1.stl ]: :fc address = val 1. ++ ++ ++ ++ transformcall [call == val ]: calls ob1.stl :ob :fc ++ ++uses figure 4: pair grammar for our case study proc. ocl 2010 10 / 15 eceasst to be created by the rule and do not need to be present for the rule to match. elements without a “++” form the context of the rule and must be present for the rule to match5. the right part of the first rule transformob describes the overall structure of an stl project. a folder (stl project) contains a single ob file (ob1.stl) and multiple fc files. the ob file, as a file node in the ast, contains three ordered children: (1.) a node representing the title, (2.) a node ’calls’ containing all function calls as children, and (3.) a node representing a comment. nodes in the ast are either folders or files with names, or generic nodes with a single value. the value can be explicitly specified (e.g. calls) or left variable (e.g. ). the parts of the rule in square brackets are not part of the grammar and just indicate that the subtrees, if present, would match the subrules transformfc and transformcall. the links between elements on different sides of the rules are so called traceability links and constitute a correspondence model that can be used to transfer attribute values, and specify further rules. this first rule transformob consists only of elements marked with a “++” and, therefore, has no prerequisites or context and can always be matched and executed. the rule decides what model elements and nodes should be created by interpreting the corresponding structure and order of children of nodes in the ast. the second rule in fig. 4 requires that a folder already exists (folder on the far right doesn’t have a “++” and thus belongs to the context of the rule). if an existing folder is found (e.g. after executing transformob), every file whose name is not “ob1.stl” is linked to an fc element with the appropriate address. the additional constraint is specified as a condition to the rule and must be fulfilled for the pattern to match (transformfc[name != ‘ob1.stl’]). the distinction between context and non-context elements in a rule allows for a declarative and high-level specification of what and not how – and can be implemented with a pattern matching engine [gsr05]. the last rule transformcall, is a very interesting rule with a relatively complex context. this rule enriches the model by searching for certain patterns in the ast. in this case, organisational blocks (obs) use or call up functional blocks (fcs) if a corresponding call statement that matches the address of the fc is found in the ob. this is expressed by the pattern on the right part of the rule: a folder containing the ob and an arbitrary file are required. both elements should already be linked to model elements on the left part of the rule (already translated). non-context elements with a “++” specify that a “uses” association between an ob and an fc exists when a “call” node is found in the ob file, which matches the name of an existing fc file with the appropriate address (constraint is expressed again by the condition transformcall[call == val]). 4.3 application of our pair grammar using an example: in this section, we consider an instance of the stl inspired metamodel (fig. 1) as our input model and go through the steps of transforming it to stl code (model-to-text)6. the different rules from fig. 4 have to be applied to the input model. to this end, a so-called forward graph transformator is derived from all rules, that expects all elements on the left of a rule to exist already (i.e. context objects) and creates the appropriate elements on the right and the links 5 to increase readability, links in fig. 4 are not annotated with “++” but of course, also have to be created. 6 text-to-model is analogous and will not be discussed in detail. 11 / 15 volume 36 (2010) support for bidirectional model-to-text transformations in between7. figure 5 depicts the graph triple after applying the transformob rule on the :fc address = 13 :ob :title value = ob1 :comment value = acomment ob1 calls acomment stl_project ob1.stl 1. 2. 3. uses figure 5: model-to-text transformation after application of rule transformob model on the left. the result is the creation of a correspondence graph with its traceability links (centre of fig. 5) as well as an ast with a folder stl project and a file ob1.stl (right part of fig. 5). this file has child nodes (1.) ob1, that represents its title, and (3.) acomment, representing a comment in the file. the child node (2.) calls is a structural node in the ast that indicates that all child nodes thereof are “calls” in the ob file. the next rule that can match is transformfc. applying it to the input model creates an fc file with a child node (1.) 13 and a link between the newly created fc file and its corresponding fc object (fig. 6). :ob :title value = ob1 :comment value = acomment ob1 acomment stl_project ob1.stl 1. 3. uses 13 1. :fc address = 13 fc calls 2. figure 6: model-to-text transformation after application of rule transformfc the “uses” connection between the fc object and the ob object now has to be established in the ast. this is achieved by applying the transformcall rule to the graph triple of fig. 6. the result is depicted in fig. 7. a new child node (1.) 13 is added to the node calls, and represents the corresponding call command in the ob file. to complete the model-to-text transformation, moca serialises the ast by traversing it depth first: • folder and file nodes are created in the file system. 7 left → right, hence “forward”. proc. ocl 2010 12 / 15 eceasst calls fc :fc address = 13 13 1. :ob :title value = ob1 :comment value = acomment ob1 acomment stl_project ob1.stl 1. 3. 2. 13 1. uses figure 7: model-to-text transformation after application of rule transformcalls • for every other node, a search is made in the template archive for a corresponding template for the node. if a template with the right name is found, it is instantiated and all child nodes are passed as template parameters. • if no appropriate template was found, moca simply uses the value of the node as the default textual representation. to complete the round-trip (fig. 1) the user may now edit the generated code. for the text-tomodel transformation, this modified code is passed to the parser to produce the corresponding ast (fig. 3). with this ast now as the input model, the backward graph tranformator of the specified pair grammar (fig. 4) would create the new stl inspired model analogously to the model-to-text transformation. with this declarative and relatively simple grammar, our case study can be completed using tggs as a model-to-model transformation language to integrate our stl inspired metamodel (fig. 2) with the los metamodel and achieve our goal of integrating los models with corresponding stl code artifacts (fig. 1). furthermore, a central goal is to achieve – from a user perspective – a homogeneous and conceptually seamless change from model-to-text to modelto-model transformations as required for the complete tool integration (los ↔ stl). 5 summary and outlook in this paper, we identified a series of important open problems that we introduced with a realworld case study. as there is currently little or no support from existing approaches to address these challenges, we presented an informal description of a new bidirectional model-to-text transformation language, inspired by triple graph grammars [sch94] and the original concept of a pair grammar [pra71], and argued benefits using our case study as a concrete example. in future work, we will present a formal specification of our bidirectional model-to-text transformation language and underline similarities and differences to existing tgg theory. we will continue work on our prototype and strive to share a common core with our existing tgg implementation in moflon. as the current pattern matching engine [gsr05] in use relies heavily on types, we will implement pattern matching on the ast (generic and poorly typed) using different algorithms that do not require types and instead exploit the tree structure. 13 / 15 volume 36 (2010) support for bidirectional model-to-text transformations numerous applications are planned including a matlab tool adapter [alss08], our current research cooperation with siemens ag (los ↔ stl), our internal code generator in moflon to further bootstrap moflon with our own technology, and textual syntaxes for our modelling and transformation languages (mof, tgg, sdm) that currently only have a graphical concrete syntax. with the experience obtained from all of these diverse use cases, we hope to be able to distill a set of common requirements and features (scopes, declaration and definition, primitive types, etc.) that can be supported directly as special edges and nodes in the ast fragments of our pair grammars. last but not least, we regard a suitable, intuitive, graphical and textual syntax for our transformation language as very critical for its acceptance and success. bibliography [akk+08] c. amelunxen, f. klar, a. königs, t. rötschke, a. schürr. metamodel-based tool integration with moflon. in proc. of the 30th icse. pp. 807–810. acm press, may 2008. formal research demonstration. [akrs06] c. amelunxen, a. königs, t. rötschke, a. schürr. moflon: a standardcompliant metamodeling framework with graph transformations. in rensink and warmer (eds.), proc. of the 2nd ecmda-fa. lncs 4066, pp. 361–375. springer, 2006. [alss08] c. amelunxen, e. legros, a. schürr, i. stürmer. checking and enforcement of modeling guidelines with graph transformations. in agtive 2008. lncs 5088, pp. 313–328. springer, 2008. [bgsz10] m. bork, l. geiger, c. schneider, a. zündorf. towards roundtrip engineering a template-based reverse engineering approach. in proc. of the 4th ecmda-fa. lncs 5095, pp. 33–47. springer, 2010. [egl+05] model transformation by graph transformation: a comparative study. 2005. [ek06] s. efftinge, c. kadura. oaw 4.1 xpand. language reference. august 2006. http://www.eclipse.org/gmt/oaw/doc/ [ev06] oaw xtext: a framework for textual dsls. 2006. [gbu09] t. goldschmidt, s. becker, a. uhl. textual views in model driven engineering. in proc. of the 35th seaa. pp. 133–140. ieee computer society, 2009. [gbu10] t. goldschmidt, s. becker, a. uhl. classification of concrete textual syntax mapping approaches. in model driven architecture – foundations and applications. lncs 5095, pp. 169–184. springer, 2010. [gsr05] template-and modelbased code generation for mda-tools. 2005. [klks10] f. klar, m. lauder, a. königs, a. schürr. extended triple graph grammars with efficient and compatible graph translators. springer, 2010. accepted for publication. proc. ocl 2010 14 / 15 http://www.eclipse.org/gmt/oaw/doc/ eceasst [krs09] f. klar, s. rose, a. schürr. tie a tool integration environment. in proc. of the 5th ecmda traceability workshop. ctit workshop proceedings wp09-09, pp. 39–48. 2009. [krv08] h. krahn, b. rumpe, s. völkel. monticore: modular development of textual domain specific languages. objects, components, models and patterns, 2008. [lsrs10] m. lauder, m. schlereth, s. rose, a. schürr. model-driven systems engineering: state-of-the-art and research challenges. bulletin of the polish academy of sciences, technical sciences, 2010. accepted for publication. [nag96] m. nagl (ed.). building tightly integrated software development environments: the ipsen approach. springer, 1996. [par04] t. j. parr. enforcing strict model-view separation in template engines. in proc. of www ’04. pp. 224–233. acm, 2004. [par07] t. parr. the definitive antlr reference: building domain-specific languages. pragmatic programmers. pragmatic bookshelf, first edition, may 2007. [pra71] t. w. pratt. pair grammars, graph languages and string-to-graph translations. j. comput. syst. sci. 5(6):560–595, 1971. [sch94] a. schürr. specification of graph translators with triple graph grammars. in tinhofer (ed.), 20th international workshop on graph-theoretic concepts in computer science. lncs 903, pp. 151–163. springer, 1994. [sk08] a. schürr, f. klar. 15 years of triple graph grammars research challenges, new contributions, open problems. in proc. of the 4th icgt. lncs 5214, pp. 411–425. springer, nov. 2008. [srs09] m. schlereth, s. rose, a. schürr. model driven automation engineering characteristics and challenges. in 5th workshop on mbees. 2009. [sv05] t. stahl, m. voelter. model-driven software development. wiley, 2005. [wag09] r. wagner. inkrementelle modellsynchronisation: univ., diss.–paderborn, 2009. logos-verlag, 2009. 15 / 15 volume 36 (2010) introduction and motivation case study related work support for defining a new concrete textual syntax support for arbitrary pre-existing textual languages identified challenges and open problems enabling an iterative process: working with arbitrary parsers: not enforcing a certain editor: ensuring replaceable templates: providing explicit support for bidirectionality: providing an intuitive, high-level transformation language: preparatory work and results code adapters with pair grammars moca (moflon code adapter framework) pair grammar for our case study application of our pair grammar using an example: summary and outlook co-tabulations, bicolimits and van-kampen squares in collagories electronic communications of the easst volume 29 (2010) proceedings of the ninth international workshop on graph transformation and visual modeling techniques (gt-vmt 2010) co-tabulations, bicolimits and van-kampen squares in collagories wolfram kahl 15 pages guest editors: jochen küster, emilio tuosto managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst co-tabulations, bicolimits and van-kampen squares in collagories wolfram kahl∗ kahl@cas.mcmaster.ca, http://sqrl.mcmaster.ca/∼kahl/ department of computing and software, mcmaster university, hamilton, ontario, canada abstract: we previously defined collagories essentially as “distributive allegories without zero morphisms”. collagories are sufficient for accommodating the relation-algebraic approach to graph transformation, and closely correspond to the adhesive categories important for the categorical dpo approach to graph transformation. heindel and sobociński have recently characterised the van-kampen colimits used in adhesive categories as bicolimits in span categories. in this paper, we study both bicolimits and lax colimits in collagories. we show that the relation-algebraic co-tabulation concept is equivalent to lax colimits of difunctional morphisms and to bipushouts, but much more concise and accessible. from this, we also obtain an interesting characterisation of van-kampen squares in collagories. keywords: relation-algebraic graph transformation, collagories, allegories, pushout, adhesive categories 1 introduction one of the hallmarks of the relation-algebraic approach to graph transformation [kaw90, kah01, kah04] is that it allows an abstract characterisation of the gluing condition for the double pushout approach. nevertheless, the categorical approach to graph transformation has continued to use the node-and-edge-based formulation of the gluing condition even in the handbook chapter [cmr+97]. recently, the literature of the categorical approach, starting essentially with [epph06] has adopted the “adhesive categories” of lack and sobociński [ls04], where however the details of the gluing condition are completely sidestepped. in [kah09a], we introduced collagories essentially as “distributive allegories without zero morphisms”. we redeveloped in collagories the fundamentals of the relation-algebraic approach to graph transformation, and showed that adhesive categories arise, and also that bitabular collagories share the most important construction principles, such as slice and co-slice category constructions, with adhesive categories. inspired by heindel and sobociński’s characterisation of van kampen squares as bicolimits in the bicategory of spans [hs09], we establish in this paper (sect. 6) the connections between our co-tabulations and bicolimits in collagories, succeding to show that the co-tabulation characterisation of pushouts, which essentially goes back to kawahara [kaw90], has a precise categorical counterpart in bipushouts, and, even more closely, in lax colimits of difunctional morphisms in a collagory context. we also succeed in providing, in sect. 7, an original collagory-theoretic characterisation of van kampen squares, significantly advancing over the results of [kah09a, kah09b]. ∗ this research is supported by the national science and engineering research council of canada (nserc). 1 / 15 volume 29 (2010) mailto:kahl@cas.mcmaster.ca http://sqrl.mcmaster.ca/~kahl/ co-tabulations, bicolimits and van-kampen squares in collagories 2 categories, allegories this section only serves to fix notation and terminology for standard concepts, see [fs90, ss93, kah04]. like freyd and scedrov and a slowly increasing number of categorists, we denote composition in “diagram order” not only in relation-algebraic contexts, where this is customary, but also in the context of categories. we will always use the infix operator “.,” to make composition explicit: r ., s = a r-b s-c . definition 2.1. a category c is a tuple (objc, morc, src, trg, i, .,) where • objc is a collection of objects. • morc is a collection of arrows or morphisms. • src (resp. trg) maps each morphism to its source (resp. target) object. instead of src(f ) = a ∧ trg(f ) = b we write f : a → b. the collection of all morphisms f with f : a → b is denoted as morc[a , b] and also called a homset. • “.,” is the binary composition operator, and composition of two morphisms f : a → b and g : b′ → c is defined iff b = b′, and then (f ., g) : a → c ; composition is associative. • i associates with every object a a morphism ia which is both a right and left unit for composition. definition 2.2. an ordered category is a category c such that • for each two objects a and b, the relation va ,b is a partial order on morc[a , b] (the indices will usually be omitted), and • composition is monotonic with respect to v in both arguments. for homsets that have least or greatest elements, we introduce corresponding notation: definition 2.3. in an ordered category, for each two objects a and b we introduce the following notions: • if the homset morc[a , b] contains a greatest element, this is denoted >>a ,b . • if the homset morc[a , b] contains a least element, this is denoted ⊥⊥a ,b . for these extremal morphisms and for identities we frequently omit indices where these can be induced from the context. definition 2.4. an ordered category with converse, or occ, is an ordered category such that • each morphism r : a → b has a converse r` : b → a , • the involution equations hold for all r : a → b and s : b → c : (r`)` = r i`a = ia (r ., s)` = s`., r` • conversion is monotonic with respect to v. many standard properties of relations can be characterised in the context of occs [kah04]: definition 2.5. a morphism r : a → b in an occ is called: • univalent iff r`., r v ib , • total iff ia v r ., r `, • injective iff r ., r`v ia , • surjective iff ib v r `., r, • a mapping iff it is univalent and total, proc. gt-vmt 2010 2 / 15 eceasst • bijective iff it is injective and surjective, • difunctional iff r ., r`., r v r. for an occ c, we write map c for the sub-category of c that contains only the mappings as arrows. difunctionality will play an important rôle in this paper; a concrete relation, understood as a boolean matrix, is difunctional iff it can be rearranged into “loose block-diagonal form”, with full rectangular blocks such that there is no overlap between different blocks in either direction. (see [ss93, 4.4] for more about difunctionality). for endomorphisms, there are a few additional properties of interest: definition 2.6. a morphism r : a → a in an occ is called: • reflexive iff i v r, • transitive iff r ., r v r, and idempotent iff r ., r = r, • co-reflexive or a sub-identity iff r v ia , • symmetric iff r`v r, • an equivalence iff it is symmetric, reflexive and transitive. lemma 2.7. if b p� a q-c is a span and p` ., q is difunctional, then p ., p` ., q ., q` is idempotent. if p and q are moreover total, then p ., p`., q ., q` is an equivalence. proof: the first claim is immediate: p ., p`., q ., q`., p ., p`., q ., q` = p ., p`., q ., q`. for the second claim, reflexivity is obvious from totality, and the first claim implies transitivity, and, together with totality, also symmetry: q ., q `., p ., p ` = ia ., q ., q `., p ., p `., ia v p ., p `., q ., q `., p ., p `., q ., q ` = p ., p`., q ., q` while freyd and scedrov [fs90] derive the homset ordering in their allegories from the meet operation, we define allegories on top of ordered categories — the composition operator has higher precedence than all other binary operators. definition 2.8. an allegory is an occ such that • each homset is a lower semilattice with binary meet u. • for all q : a → b, r : b → c , and s : a → c , the modal rule holds: q ., rus v (qus ., r`) ., r . the most well-known allegory is the category rel of sets with relations and standard relational operations. logical theories give rise to allegories of derived predicates [fs90, app. b]. a simpler case of that are the allegories arising from σ-algebras (over some signature σ) as objects, and with “relational σ-homomorphisms”, i.e. bisimulations in the sense of [kah04], as morphisms. in allegories, one can define domain and range operators: definition 2.9. for every morphism r : a ↔ b in an allegory, we define dom r : a ↔ a and ran r : b ↔ b as: dom r := ia ur ., r ` ran r := ib ur `., r 3 / 15 volume 29 (2010) co-tabulations, bicolimits and van-kampen squares in collagories 3 collagories κ óλ λ α : glue in freyd and scedrov’s treatment, although allegories are not required to have zero-ary meets, distributive allegories are required to have zero-ary joins (least elements) together with distributivity of composition over them, that is, the zero law ⊥⊥ ., r = ⊥⊥. in [kah09a], we introduced an intermediate concept that does not assume anything about zero-ary joins: definition 3.1. a collagory is an allegory where each homset is a distributive lattice with binary join t, and composition distributes over binary joins from both sides. we directly axiomatise difunctional closure, without introducing kleene star: definition 3.2. a difunctionally closed collagory is a collagory where, there is an additional unary operation ∗� which satisfies the following axioms for all r : a → b, q : c → a , and s : b → c : q′ : c → b, and s′ : a → c : r∗� = rtr∗� ., (r∗�)`., r∗� recursive definition q ., r v q′ ∧ q′ ., r`., r v q′ ⇒ q ., r∗� v q′ right induction r ., s v s′ ∧ r ., r`., s′ v s′ ⇒ r∗� ., s v s′ left induction we further define r∗b : a → a and r ∗c : b → b as: r∗b := itr∗� ., (r∗�)` and r ∗c := it(r∗�)`., r∗� . in a difunctionally closed collagory, the operation ∗� produces difunctional closures [kah09a]. requiring least morphisms satisfying zero laws turns collagories into distributive allegories, which still heave a much weaker theory than relations in a topos, so graph structures (unary algebras) with relational graph homomorphism in particular also form collagories. in [kah09a], we showed that the absence of the zero laws enables the presence of constant symbols (allowing for example pointed sets), and also that restrictions to sub-collagories in signature reducts (for example fixing label sets) and nested algebra constructions (interpreting signatures in the mapping categories of arbitrary collagories instead of just in map rel) both construct new collagories. these constructions are directly useful for concrete modelling tasks, and for implementation of the resulting models as data structures; they also subsume the construction methods presented by lack and sobociński [ls04] for adhesive categories, in particular comprising clice and co-slice category construction. 4 tabulations and co-tabulations central to the connection between pullbacks and pushouts in categories of mappings on the one hand and constructions in relational theories on the other hand is the fact that a square of mappings commutes iff the “relation” induced by the source span is contained in that induced by the target co-span. the proof of this does not need the modal rule. a � � p @ @r q b c @ @rr � � s d proc. gt-vmt 2010 4 / 15 eceasst lemma 4.1. [fs90, 2.146] given a square of mappings in an allegory as drawn above, we have p ., r = q ., s iff p`., q v r ., s`. this provides a first hint that in the relational setting, the identity of the two mappings p and q does not matter when looking for a pushout of the span b p� a q-c — we only need to consider the diagonal p` ., q. dually, when looking for a pullback of the co-span b r-d s� c , only r ., s` needs to be considered. the gap between the two ways of calculating the horizontal diagonal can be significant since r ., s` is always difunctional. in fact, lemma 4.1 can be strenghtened: lemma 4.2. given a square of mappings in an allegory as drawn above, and existence of the difunctional closure of p`., q, we have p ., r = q ., s iff (p`., q)∗� v r ., s`. proof: the “if” direction follows immediately from p`., q v (p`., q)∗� and the “if” direction of lemma 4.1. for “only if”, assume p ., r = q ., s. then p`., q v r ., s` by lemma 4.1, and r ., s`., q`., p ., p`., q = r ., r`., p`., p ., p`., q commutativity = r ., r`., p`., q p unival. = r ., s`., q`., q commutativity v r ., s` q unival. by left-induction for difunctional closure we therefore have (p`., q)∗� v r ., s` . producing the result span of a pullback (respectively the result co-span of a pushout) from the horizontal diagonal alone is, in some sense, a generalisation of freyd and scedrov’s splitting of idempotents; [kah04] contains more discussion of this aspect. definition 4.3. [fs90, 2.14] in an allegory, let a morphism v : b → c be given. the span b p� a q-c of mappings p and q is called a tabulation of v iff the following equations hold: p `., q = v p ., p`uq ., q` = ia . a � �� p @ @@r q b v c b w c @ @@rr � �� s d definition 4.4. [kah04] in a collagory, let a morphism w : b → c be given. the co-span b r-d s� c of mappings r and s is called a co-tabulation of w iff the following equations hold: r ., s ` = w r`., rts`., s = id . the first equation implies w ., w`., w = r ., s`., s ., r`., r ., s`v r ., s` = w (using univalence of r and s), so if w has a co-tabulation, it has to be difunctional. furthermore, from univalence of r and s we also obtain the lax cocone conditions r` ., w = r`., r ., s`v s` and w ., s = r ., s`., s v r. the following equivalent characterisations provided by [kah04] have the advantage that they are fully equational, without the implicit inclusions in the mapping conditions. this frequently 5 / 15 volume 29 (2010) co-tabulations, bicolimits and van-kampen squares in collagories facilitates calculations. note that iuv ., v` = dom v ; we use the expanded form to emphasise the duality. proposition 4.5. in an allegory, the span b p� a q-c is a tabulation of v : b → c if and only if the following equations hold: p `., q = v p`., p = iuv ., v` q`., q = iuv`., v p ., p `uq ., q` = ia . proposition 4.6. in a collagory, the co-span b r-d s� c is a co-tabulation of w : b → c iff the following equations hold: r ., s ` = w r ., r` = itw ., w` s ., s` = itw`., w r `., rts`., s = id . definition 4.7. if an allegory has a tabulation for each morphism, we call it tabular. if a collagory has a co-tabulation for each morphism, we call it co-tabular, and if it is furthermore tabular, we call it bi-tabular. tabulations in an allegory are unique up to isomorphism (this uses the modal rule), and include the following special cases: • in a tabulation of a sub-identity, both tabulation morphisms are the induced sub-object injection [fs90, 2.145]. • we can define a direct product of a and b to be a tabulation of a >>a ,b , provided that greatest morphism exists. the resulting direct product definition differs from that of [ss93] in extending naturally to “empty” objects (e.g., empty sets) by not demanding surjectivity of the projections, but only π`., π = dom>>a ,b and ρ `., ρ = ran>>a ,b . • if a co-span b r-d s� c of mappings is given, then each tabulation of r ., s` (there might be none) is a pullback in map a [fs90, 2.147]. for a tabular allegory a, this implies that each pullback in map a is isomorphic to a tabulation, and therefore is itself a tabulation. however, if a is not tabular, then a co-span b r-d s� c of mappings for which no tabulation of r ., s` exists may still have a pullback in map a, which then cannot be a tabulation. if an allegory is known to have all direct products and subobjects, then these can be used to construct a tabulation for each morphism. in a collagory, we have the following special cases of co-tabulations, dual to the special tabulations above: • in a co-tabulation of an equivalence relation, both r and s are the induced quotient projections. • we can define a direct sum of a and b to be a co-tabulation of ⊥⊥a ,b , if that least morphism exists. • if a span b p� a q-c of mappings is given, and the difunctional closure w := (p` ., q)∗� exists then each co-tabulation of w (there might be none) is a pushout in map a [kah09a]. the situation is, except for the addition of the difunctional closure, perfectly dual to the situation for pullbacks described above: for a co-tabular collagory c, each pushout in map c is isomorphic to a co-tabulation, and therefore is itself a co-tabulation. however, if c is not proc. gt-vmt 2010 6 / 15 eceasst co-tabular, then a span b p� a q-c of mappings for which no co-tabulation of (p` ., q)∗� exists may still have a pushout in map c, which then cannot be a co-tabulation. if direct sums and quotients are available, then a co-tabulation can be constructed for each difunctional morphism. a co-tabulation for a difunctional closure z∗� satisfies the following equations: r ., s ` = z∗� r ., r` = z∗b s ., s` = z ∗c r`., rts`., s = id . this was introduced as a gluing for the morphism z in [kah01]. kawahara is the first to have characterised pushouts relation-algebraically in essentially this way [kaw90]; he used relationalgebraic operations on relations arising in toposes. convention 4.8. for a square of morphisms as drawn at the beginning of this section, we say that • it is a tabulation iff b p� a q-c is a tabulation for r ., s`, • it is a (direct) co-tabulation iff b r-d s� c is a co-tabulation for p`., q, • it is a gluing iff b r-d s� c is a gluing for p` ., q, that is, if it is a co-tabulation for (p`., q)∗�. 5 the gluing condition in collagories we can now state a relational variant of the gluing condition, first introduced by kawahara [kaw90]: definition 5.1. let two morphisms1 φ : g → l and x : l → a in a collagory with pseudocomplements on subidentities be given.2 • we say that the identification condition holds iff x ., x`v it(ran φ) ., x ., x`., ran φ . • we say that the dangling condition holds iff ran xt(ran x → ran (φ ., x)) = i . the proofs that the gluing condition is sufficient for the existence of a pushout complement [kaw90], and that injectivity of φ is sufficient for unambiguity of the pushout complement [kah01] carry over to the collagory setting, but are outside the scope of this paper. another related condition is important in the context of the single-pushout approach [löw90, le91]: l φ� g x ? ξ pppppppppp? a ψ pppppppppp� h definition 5.2. in an allegory, we call x conflict-free for φ iff ran (φ ., x ., x`) v ran φ. 1 note that “x” is a capital “χ ”. 2 pseudo-complements are residuation of meet in lower semilattice categories; where pseudo-complements exist, we denote the pseudo-complement or r with respect to s as r → s, and we have: xur v s ⇔ x v (r → s) for example, the pseudo-complement of a subgraph r of a graph g with respect to another subgraph s consists of all nodes of g that are in s or not in r, and all edges in s or not in r that are also nor incident with nodes in r. intuitively, r → s therefore is g with the parts of r outside s removed, and then also all dangling edges removed. 7 / 15 volume 29 (2010) co-tabulations, bicolimits and van-kampen squares in collagories for a node-and-edges-level formulation of conflict-freeness it is well-known that the induced single-pushout squares have a total embedding of the right-hand side into the application graph [löw90, cor. 3.18.5]. the component-free formulation above was first given in [kah01], where it is also shown (thm. 5.4.11) that a restricting derivation step for a conflict-free redex produces a pushout of partial functions. 6 co-tabulations as bicolimits and lax colimits ordered categories are a simple example of 2-categories and bicategories: for two morphisms r, s : a → b of an ordered category, there is at most one two-cell from r to s, and there is a two-cell from r to s iff r v s. therefore, there is an invertible two-cell between r and s if and only if r = s. 6.1 oc-colimits: bicolimits in ordered categories the general notion of bicolimits takes as its point of departure a diagram defined via a functor from a category. we introduce a specialised variant of the definition used in [hs09] by restricting our attention to ordered categories. definition 6.1. given a category c, an (index) category j, a functor d : j → c defining a diagram, and an object d , a cocone η from d to d consists of a morphism ηa : d a → d in c for each object a of j, satisfying the following cocone commutativity condition: d f ., ηb = ηa for each morphism f : a → b in j. definition 6.2. given an ordered category c, an (index) category j, and a functor d : j → c, an oc-colimit of d is given by an object d of c, and a cocone η from d to d , satisfying the following conditions: 1. factorisation: for any other object d′ of c with cocone κ from d to d′, there is a morphism h : d → d′ in c with ηa ., h = κa for each object a in j. 2. isotony: for any other object d′ of c and any two morphisms h, h′ : d →d′, if ηa ., h v ηa ., h′ for all objects a in j, then h v h′. oc-colimits are unique up to isomorphism. 6.2 lax colimits in occs for lax cocones, we only need the concept of lax functor, which differs from the functor concept in that a lax functor d only needs to satisfy id a v d ia and (d f ) ., (d g) v d(f ., g), see, e.g., [stu05, sect. 8, p. 37ff]. again, we provide specialised definition of lax cocones and lax colimits for the ordered category case: definition 6.3. given an ordered category c, an (index) category j, a lax functor d : j → c defining a diagram, and an object d , a lax cocone η from d to d consists of a morphism proc. gt-vmt 2010 8 / 15 eceasst ηa : d a → d in c for each object a of j, satisfying the following cocone subcommutativity condition: d f ., ηb v ηa for each morphism f : a → b in j. definition 6.4. given an ordered category c, an (index) category j, and a lax functor d : j → c, a lax colimit of d is given by an object d of c, and a lax cocone η from d to d satisfying the following conditions 1. factorisation: for any object d′ of c with lax cocone κ from d to d′, there is a morphism u : d → d′ in c with ηa ., u = κa for each object a in j, 2. isotony: for any object d′ of c and any two morphisms u, u′ : d → d′, if ηa ., u v ηa ., u′ for each object a in j, then u v u′. lax colimits are unique up to isomorphism, too. we now add the converse operator to our consideration of lax colimits, and when we use “•→•” to denote an occ, that occ has the homset from the first object a to the second, different object b contain exactly one morphism, say f, from a to b. as an occ, it needs to also have f`, which will be the only morphism from b to a . since in this occ, also f ., f` ., f needs to exist as a morphism from a to b, it has to be equal to f, which therefore is difunctional. if a lax functor d maps f : a → b to w : a ′ → b′, then w ., w `., w = d f ., (d f)`., d f v d (f ., f`., f) = d f = w , so it can map f only to difunctional morphisms. furthermore, if, for a lax cocone, its source j is considered as an occ, this implies that for each morphism f : a →b in j, also the converse morphism f`: b →a needs to be considered. such a lax cocone therefore automatically has to satisfy both the following conditions: d f ., ηb v ηa (d f)`., ηa v ηb } for each morphism f : a → b in j. convention 6.5. given a morphism w : b → c in the occ c, we will frequently identify w with the functor d mapping the single morphism explicitly mentioned in the occ •→• to w. (since we are dealing with an occ, that morphism also has a converse, which then must be mapped to w`.) a lax cocone from w to d therefore is a cospan b r-d s� c satisfying w ., s v r and w`., r v s. c @ @ @r s w 6 d � � �� r b c @ @ @r s h h h h h hhj s′ w 6 d up p p p p p p p-d′ � � �� r � � � � � ��* r′ b we explicitly state the definition of resulting special case of lax colimits: 9 / 15 volume 29 (2010) co-tabulations, bicolimits and van-kampen squares in collagories definition 6.6. an occ-colimit of w : b → c in the occ c is a lax cocone b r-d s� c from w to d (with w ., s v r and w`., r v s) satisfying the following conditions: 1. factorisation: for any object d′ of c with lax cocone b r ′ -d′ s ′ � c from w to d′, there is a morphism u : d → d′ in c with r ., u = r′ and s ., u = s′ ; 2. isotony: for any object d′ of c and any two morphisms u, u′ : d → d′, if r ., u v r ., u′ and s ., u v s ., u′, then u v u′. the crucial aspect of the following theorem (proof in [kah10]) is that it connects the respecive o*-limits for spans b p� a q-c of mappings with those for the single difunctional morphisms (p`., q)∗� (which do not need to be mappings). theorem 6.7. if a span b p� a q-c of mappings in a collagory is given, then a cospan b r-d s� c is an occ-colimit for (p`., q)∗� iff it is an oc-pushout (i.e., oc-colimit for a span) for b p� a q-c . 6.3 occ-colimits are co-tabulations in a collagory c that is not co-tabular, categorical pushouts in map c are not necessarily gluings — the pushout conditions establish no connection between mappings and other morphisms, and pathological cases cannot be excluded. however, oc-colimits and occ-colimits do establish the necessary connections; one direction is easy to see (details in [kah10]): theorem 6.8. if a cospan b r-d s� c in a collagory is a co-tabulation of w : b →c , then it is also an occ-colimit for w. we now show that all occ-colimits (of necessarily difunctional morphisms) are in fact cotabulations. the proof needs to rely on the lax colimit properties, and therefore needs to use appropriate lax cocones constructed from the morphisms known to exist for a given occ-colimit. the following lemma already follows this pattern: lemma 6.9. if, in an allegory, b r-d s� c is an occ-colimit for w, then w`., r = s ., ran r w`., r ., r` = s ., r` w ., s = r ., ran s w ., s ., s` = r ., s` proof: let r0 = w ., s and s0 = s. this defines a lax cocone b r0-d s0� c from w to d , since: w`., r0 = w `., w ., s v w`., r v s = s0 ; w ., s0 = w ., s = r0 . then factorisation gives us a u0 : d →d such that r0 = w ., s = r ., u0 and s0 = s = s ., u0. since r ., u0 = w ., s v r = r ., id and s ., u0 = s v s ., id , isotony gives us u0 v id . so u0 is a sub-identity, and s = s ., u0 implies ran s v u0. since composition of sub-identities is meet, we obtain the following (which implies u0 = ran s): w ., s = w ., s ., ran s = r ., u0 ., ran s = r ., ran s proc. gt-vmt 2010 10 / 15 eceasst analogously, w`., r = s ., ran r also holds, and these further imply w `., r ., r ` = s ., r` and w ., s ., s` = r ., s` . lemma 6.9 does not use difunctionality of w, and implies: w`., w ., w`., r = w`., w ., s ., ran r = w`., r ., ran s ., ran r = w`., r ., ran s = s ., ran r ., ran s = s ., ran r = w`., r and, analogously, w ., w`., w ., s = w ., s. therefore, even with a weaker concept of occ-colimit, we would still have, in some sense, “almost-difunctionality” of w. lemma 6.9 did use allegory properties (for sub-identities); to show the opposite inclusion to theorem 6.8 we need full collagories (detailed proof in [kah10]): theorem 6.10. if, in a collagory, w : b → c is a difunctional morphism and b r-d s� c is an occ-colimit for w, then it is also a co-tabulation for w. in summary, we have shown in theorem 6.7 that oc-pushouts (i.e., oc-colimits) of a span are the same as occ-colimits of the difunctional closure of the composition across that span. furthermore, occ-colimits of difunctional morphisms are the same as co-tabulations, as shown in theorems 6.8 and 6.10. 7 van kampen squares in collagories adhesive categories as a more specific setting for double-pushout graph rewriting have been introduced by lack and sobociński [ls04, ls05]; the following two definitions are taken from there: definition 7.1. a van kampen square (i) is a pushout which satisfies the following condition: given a commutative cube (ii) of which (i) forms the bottom face and the back faces are pullbacks (where c is considered to be in the back), the front faces are pullbacks if and only if the top face is a pushout. c � � � m @ @ @r f a b @ @ @r g � � � n d (i) c ′ f -b′ � � m � � n a ′ gc ? d′ ? b a ? c -f ? d b � �� m � �� n a -g d (ii) definition 7.2. a category c is said to be adhesive if 1. c has pushouts along monomorphisms; 2. c has pullbacks; 3. pushouts along monomorphisms are van kampen squares. 11 / 15 volume 29 (2010) co-tabulations, bicolimits and van-kampen squares in collagories for more concise formulations, we define: definition 7.3. a van kampen setup in a collagory c for a square as in def. 7.1(i) is a commuting cube in map c as in def. 7.1(ii) where the bottom square is a gluing and the two back squares are tabulations. in [kah09b], the following two lemmas were only shown for co-tabulations (i.e., assuming that m` ., f is difunctional, and also of m` ., f where it is assumed to be a gluing), not for general gluings. in [kah10], we show the following significantly strengthened versions. lemma 7.4. in a collagory, if the front squares of a van kampen setup are tabulations, then the top square is a gluing. if furthermore m`., f is difunctional, then m`., f is difunctional, too. lemma 7.5. in a van kampen setup where the top square is a gluing, the front squares are tabulations iff the following holds: m ., (m`., f )∗� ., f`uc ., c`v ic ′ the condition here is equivalent to the following inclusion in the lattice of equivalences on c ′: (m ., m`∨ f ., f`) ∧ c ., c` = ic ′ since equivalence lattices are not necessarily distributive, we cannot derive this from the tabulation equations m ., m`∧ c ., c` = ic ′ and f ., f `∧ c ., c` = ic ′. from lemmas 7.4 and 7.5, we also directly obtain a characterisation of van kampen squares in bitabular collagories: theorem 7.6. a gluing square (as in def. 7.1(i)) in a bitabular collagory is van kampen iff all its van kampen setups (as in def. 7.3) where the top square is a gluing satisfy the following: m ., (m`., f )∗� ., f`uc ., c`v ic ′ the bitabularity condition could be weakened, but even then, this characterisation theorem is still very different from the appropriate diagram instance of heindel and sobociński’s characterisation theorem [hs09, theorem 22], due to the fact that, by assuming a gluing, we already restricted ourselves to “well-behaved” pushouts. our theorem also stays more in the typical relation-algebraic spirit: instead of heindel and sobociński’s condition “a colimit exists”, we have a local inclusion to check. the universal quantification this is embedded in is essentially the same as in [hs09, theorem 22]. an interesting question is whether there is a useful characterisation that employs a local condition only on the candidate square, beyond injectivity of one m and f, as used in the definition of adhesive categories. first we observe (proof in [kah10]): lemma 7.7. in a van kampen setup where m ., m`uf ., f`v ic , the following hold: 1. f ., f`um ., m`., c ., c`v ic ′ 2. c ., c`um ., m`., f ., f`v ic ′ injectivity of m makes m` ., f difunctional and also enforces injectivity of m and therewith difunctionality of m`., f . in the general case, however, we have seen above that difunctionality of m`., f requires not only difunctionality of m`., f, but also the front tabulation conditions. proc. gt-vmt 2010 12 / 15 eceasst this failure of difunctionality propagation can be understood as coming from the fact that in the difunctionality inclusion m` ., f ., f` ., m ., m` ., f v m` ., f, the right-hand side passes through a “c element” that may be distinct from the three “c elements” of the left-hand side. this distinct “c element” gives rise to a “c ′ element” that is, in the absence of the front tabulation conditions, determined only up to c ., c`. one way to avoid this unwanted factor is to specify that in any chain diagram documenting m ., m` ., f ., f` ., m ., m`, the fourth (i.e., last) c element needs to be one of the previous three c elements. referring to so many elements simultaneously in a relation-algebraic way requires direct products — we use π and ρ as the projections. the following is one formulation of this condition: m ., m `., (π`uf ., f`., m ., m`., ρ`) v m ., m`., (π`u(f ., f`tm ., m`) ., ρ`) however, it is not hard to see that this is equivalent to the following, much simpler condition: f ., f `., m ., m `v f ., f`tm ., m` this is obviously satisfied if one of m and f is injective. it can also be strengthened to an equality, since m and f are both total. this implies symmetry: f ., f `., m ., m ` = f ., f`tm ., m` = m ., m`., f ., f` and, furthermore, difunctionality of m`., f: m `., f ., f `., m ., m `., f = m`., m ., m`., f ., f`., f = m`., f . assuming also m ., m`uf ., f`v ic , we obtain f ., f `., m ., m` = f ., f`tm ., m`: f ., f`., m ., m` = f ., f`., m ., m`uc ., f ., f`., m ., m`., c` v f ., f`., m ., m`uc ., (f ., f`tm ., m`) ., c` assumption = f ., f`., m ., m`u(c ., c`., f ., f`tc ., c`., m ., m`) = (f ., f`., m ., m`uc ., c`., f ., f`)t(f ., f`., m ., m`uc ., c`., m ., m`) v f ., f`tm ., m` lemma 7.7 therefore, m`., f is difunctional, too, and together with lemma 7.7 we obtain m ., (m`., f )∗� ., f`uc ., c` = m ., m`., f ., f`uc ., c`v ic ′ . altogether we have shown the following: theorem 7.8. in the category map c of maps over a bi-tabular collagory c, pushouts for spans a m� c f-b that satisfy also f ., f `um ., m`v ic and f ., f `., m ., m `v f ., f`tm ., m` are van kampen squares. both inclusions can be strengthened to equalities, and since the second condition implies difunctionality, both together imply that such pushouts are also pullbacks. 13 / 15 volume 29 (2010) co-tabulations, bicolimits and van-kampen squares in collagories 8 conclusion we have shown that, in collagories, lax colimits of single morphisms are the same as co-tabulations, and bicolimits of spans (bipushouts) are the same as gluings. furthermore, the move from a span b p� a q-c to the difunctional closure of p` ., q preserves both kinds of colimits. (the opposite move could be achieved via a tabulation, and may still deserve to be spelt out.) we also strengthened our previous results about the two implications involved in van kampen squares from difunctional spans to arbitrary spans, extracted a precise relation-algebraic condition for van kampen squares in collagories, and gave a new, purely local sufficient condition for van kampen squares that is more general than the “pushouts along monomorphisms” used in adhesive categories. these two results together with the fact that the equational characterisation of co-tabulations enables a nice, calculational proof style make a strong case to employ collagories as a convenient basis for theoretical investigations of graph structure transformations. in addition, relationalgebraic formulations and reasoning are accessible to a wide audience due to the fact that in the intuitive special case of rel, they can be understood as boolean matrix operations. future investigations will explore how these new conditions for van kampen squares can be combined with the different variations of adhesive categories in a collagory setting, including the quasiadhesive categories of [ls05], and their applications. bibliography [cmr+97] a. corradini, u. montanari, f. rossi, h. ehrig, r. heckel, m. löwe. algebraic approaches to graph transformation, part i: basic concepts and double pushout approach. in rozenberg (ed.), handbook of graph grammars and computing by graph transformation, vol. 1: foundations. chapter 3, pp. 163–245. world scientific, singapore, 1997. [epph06] h. ehrig, j. padberg, u. prange, a. habel. adhesive high-level replacement systems: a new categorical framework for graph transformation. fund. inform. 74(1):1–29, 2006. http://iospress.metapress.com/content/f89c8ba4nbeq1xc4/ [fs90] p. j. freyd, a. scedrov. categories, allegories. north-holland mathematical library 39. north-holland, amsterdam, 1990. [hs09] t. heindel, p. sobociński. van kampen colimits as bicolimits in span. in kurz et al. (eds.), algebra and coalgebra in computer science, calco 2009. lncs 5728, pp. 335–349. springer, 2009. (to appear). doi:10.1007/978-3-642-03741-2 23 [kah01] w. kahl. a relation-algebraic approach to graph structure transformation. 2001. habil. thesis, fakultät für informatik, univ. der bundeswehr münchen, techn. report 2002-03, http://sqrl.mcmaster.ca/∼kahl/publications/relrew/. [kah04] w. kahl. refactoring heterogeneous relation algebras around ordered categories and converse. j. relational methods in comp. sci. 1:277–313, 2004. http://www.jormics.org/ proc. gt-vmt 2010 14 / 15 http://iospress.metapress.com/content/f89c8ba4nbeq1xc4/ http://dx.doi.org/10.1007/978-3-642-03741-2_23 http://sqrl.mcmaster.ca/~kahl/publications/relrew/ http://www.jormics.org/ eceasst [kah09a] w. kahl. collagories for relational adhesive rewriting. in berghammer et al. (eds.), relations and kleene algebra in computer science, relmics/aka 2009. lncs 5827, pp. 211–226. springer, 2009. doi:10.1007/978-3-642-04639-1 [kah09b] w. kahl. collagories for relational adhesive rewriting. sqrl report 56, software quality research laboratory, department of computing and software, mcmaster university, july 2009. 24 pages. in: http://sqrl.mcmaster.ca/sqrl reports.html. (superseded by [kah10]). [kah10] w. kahl. collagory notes, version 1. sqrl report 57, software quality research laboratory, department of computing and software, mcmaster university, mar. 2010. 53 pages. in: http://sqrl.mcmaster.ca/sqrl reports.html. [kaw90] y. kawahara. pushout-complements and basic concepts of grammars in toposes. theoretical computer science 77:267–289, 1990. doi:10.1016/0304-3975(90)90171-d [le91] m. löwe, h. ehrig. algebraic approach to graph transformation based on single pushout derivations. in möhring (ed.), graph-theoretic concepts in computer science, wg ’90. lncs 484, pp. 338–353. springer, 1991. doi:10.1007/3-540-53832-1 52 [löw90] m. löwe. algebraic approach to graph transformation based on single pushout derivations. technical report 90/05, tu berlin, 1990. [ls04] s. lack, p. sobociński. adhesive categories. in walukiewicz (ed.), fossacs 2004. lncs 2987, pp. 273–288. 2004. doi:10.1007/b95995 [ls05] s. lack, p. sobociński. adhesive and quasiadhesive categories. rairo inform. théor. appl. 39(3):511–545, 2005. doi:10.1051/ita:2005028 [ss93] g. schmidt, t. ströhlein. relations and graphs, discrete mathematics for computer scientists. eatcs-monographs on theoretical computer science. springer, 1993. [stu05] i. stubbe. categorical structures enriched in a quantaloid: categories, distributors and fuctors. theory and appl. of categories 14(1):1–45, 2005. http://tac.mta.ca/tac/volumes/14/1/14-01abs.html 15 / 15 volume 29 (2010) http://dx.doi.org/10.1007/978-3-642-04639-1 http://sqrl.mcmaster.ca/sqrl_reports.html http://sqrl.mcmaster.ca/sqrl_reports.html http://dx.doi.org/10.1016/0304-3975(90)90171-d http://dx.doi.org/10.1007/3-540-53832-1_52 http://dx.doi.org/10.1007/b95995 http://dx.doi.org/10.1051/ita:2005028 http://tac.mta.ca/tac/volumes/14/1/14-01abs.html introduction categories, allegories collagories tabulations and co-tabulations the gluing condition in collagories co-tabulations as bicolimits and lax colimits oc-colimits: bicolimits in ordered categories lax colimits in occs occ-colimits are co-tabulations van kampen squares in collagories conclusion formal modeling and analysis for interactive hybrid systems electronic communications of the easst volume 45 (2011) proceedings of the fourth international workshop on formal methods for interactive systems (fmis 2011) formal modeling and analysis for interactive hybrid systems ellen j. bass, karen m. feigh, elsa gunter, and john rushby 16 pages guest editors: judy bowen, steve reeves managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst formal modeling and analysis for interactive hybrid systems ellen j. bass1, karen m. feigh2, elsa gunter3, and john rushby4∗ 1systems and information engineering, university of virginia 2school of aerospace engineering, georgia institute of technology 3department of computer science, university of illinois, urbana-champaign 4computer science laboratory, sri international, menlo park, california abstract: an effective strategy for discovering certain kinds of automation surprise and other problems in interactive systems is to build models of the participating (automated and human) agents and then explore all reachable states of the composed system looking for divergences between mental states and those of the automation. various kinds of model checking provide ways to automate this approach when the agents can be modeled as discrete automata. but when some of the agents are continuous dynamical systems (e.g., airplanes), the composed model is a hybrid (i.e., mixed continuous and discrete) system and these are notoriously hard to analyze. we describe an approach for very abstract modeling of hybrid systems using relational approximations and their automated analysis using infinite bounded model checking supported by an smt solver. when counterexamples are found, we describe how additional constraints can be supplied to direct counterexamples toward plausible scenarios that can be confirmed in high-fidelity simulation. the approach is illustrated though application to a known (and now corrected) human-automation interaction problem in airbus aircraft. keywords: hybrid systems, infinite bounded model checking, smt solvers, mental models, automation surprise 1 introduction new air traffic control procedures (collectively known as nextgen) involve automated exchange of information, intentions, and instructions among aircraft and between aircraft and the ground. these procedures raise new issues in situational awareness, autonomy, authority, and control among pilots, ground controllers, and automated systems in the cockpit and on the ground. we participate in a project called “nextgen authority and autonomy” (nextgenaa) to explore human-automation interaction issues in these procedures using formal methods and simulation [bbf+11]. the ultimate goal is to provide assurance that a given procedure harbors no potential for an “automation surprise” [swb97] or other anomaly, but along the way we will be interested to discover scenarios that may indicate such potential and to subject them to particular scrutiny. ∗ supported by nsf grant cns-0720908 and by nasa contract nna10de79c. the content is solely the responsibility of the authors and does not necessarily represent the official views of nsf or nasa. 1 / 16 volume 45 (2011) formal modeling and analysis for interactive hybrid systems our approach to assurance is to develop models of the human and automated actors in these procedures, together with the aircraft they control or the air traffic automation they are using, and to search for anomalous scenarios, such as those that exhibit an automation surprise—which will be manifested as a divergence between the state of the mental model of one of the human actors and the real state of the physical system (or the mental state of another actor) [rus02]. if such anomalies are found, then our models should enable us to find the root cause and to revise the associated procedure—or its supporting automation or training, as appropriate. if no anomalies are discovered, and we can show that our search is exhaustive, then we have delivered assurance for absence of anomalies in the procedures examined, subject to caveats about the soundness of our models and methods of analysis. many of our models will be state machines, for which several effective methods of automated analysis (i.e., search) are available: these methods use various techniques from automated deduction, such as model checking and theorem proving. state machines are suitable models for automated systems, and for some aspects of human behavior. however, we must also model the behavior of physical “plant,” such as aircraft in flight. high fidelity aircraft models use differential equations that accurately represent the flight dynamics of a given aircraft. an aircraft may operate in different “modes” (e.g., flaps retracted or extended), and there will be different sets of differential equations for each mode: aircraft models are therefore hybrid systems (i.e., they combine discrete and continuous elements) and these pose challenges for analysis, especially when composed with models for the other actors. a straightforward method for analyzing hybrid systems is simulation (e.g., using matlab simulink/stateflow). simulations can be very accurate, but they are computationally expensive and therefore of limited utility in a search for anomalous scenarios: the computational cost will restrict the search to a small number of scenarios and some anomalous ones may be overlooked. there are formal methods for exploring the reachable states of hybrid systems, and for verifying invariants, but these also are computationally challenging and can seldom handle models with more than five continuous variables. the properties of some hybrid systems do depend crucially on the differential equations involved; control systems are like this, because the controller is highly tuned to the behavior (modeled by differential equations) of the controlled plant. but properties of other kinds of hybrid system are less dependent on the differential equations: human-automation interaction must surely be of this latter kind, because the human can employ only a fairly crude mental simulation of the dynamics involved. what we seek is a method of modeling and analysis for hybrid systems that is commensurate with this second kind of system. our approach is to use a range of models: we start with very abstract (i.e., highly approximate) models for aircraft dynamics that can be analyzed efficiently using a method known as “infinite bounded model checking.” if anomalies are discovered, then we must decide whether these are due to the approximations employed, or are real. we attempt to do this by refining and manipulating the approximate model so that it delivers an anomalous scenario that appears credible; we then use this scenario to guide a limited search in a simulator to see if a similar anomalous scenario can be created in high fidelity. the purpose of this paper is to describe and explain the models and the analysis techniques that we employ at the most abstracted end of our range of methods. we illustrate our techniques using a known automation surprise found in certain airbus aircraft. although this example does proc. fmis 2011 2 / 16 eceasst not concern air traffic operations, it does employ similar components: human mental models, automated systems, and aircraft dynamics. we use this example because we have analyzed it previously [cjr00] and can illustrate the difference between earlier methods and those developed here. the automation surprise that is the basis for our example is described in the following section; our method for abstract modeling and analysis is described in section 3 and its application to the example is described in detail in section 4; we present our conclusions in section 5. 2 an example scenario: a320 speed protection our example focuses on a form of “speed protection” built in to various airbus aircraft, and the potential it provides for an automation surprise. the specific protection that we model is an older form that was installed by default in a320, a330, and a340 aircraft and, in a somewhat similar form, in a310s. due to automation surprise incidents, this protection is modified in the “global speed protection package” offered today. to see why, we recommend viewing the following video of an incident that occurred on 24 september 1994 to an airbus a310, registration yrlcc, operating as tarom flight 381 from bucharest to paris orly: http://www.youtube.com/ watch?v=vqmrrfeyzbi. the first part of the video is a reconstruction of the incident, based on information from the flight data recorder; the second part is actual video taken from the ground. the sound track from the voice data recorder is synchronized to both parts. the official incident report is available from the french authorities [bea94]. in the following paragraphs, we adumbrate relevant parts of the automation employed in the a320 and describe a scenario that could provoke an automation surprise and an incident such as that on tarom flight 381. our automation model is based on the implementation used in a320 aircraft, as described in [cjr00]. the a320 autopilot has several vertical modes and submodes, of which we are interested in v/s fpa (the flight path angle submode of vertical speed mode), op des (the descent submode of open mode), and op clb (the climb submode of open mode). v/s fpa flies at a specific flight path angle whose value is set in the flight control unit (fcu). the autothrottle also has several modes, of which we focus on the behavior in spd (speed mode), which tries to maintain a specific airspeed whose value also is set in the fcu. if the aircraft is descending steeply, it is possible that its airspeed will exceed that requested, even when the autothrottle has selected idle thrust. in this case, fpa is prioritized over airspeed and the latter is allowed to exceed the speed set in the fcu. however, the airspeed may become sufficiently large that it exceeds the maximum safe speed, which depends on the aircraft configuration (specifically, whether the flaps are extended or not). in this case, automated speed protection changes the vertical mode from v/s fpa to op des or op clb, which prioritize airspeed over vertical speed. the selected mode depends on whether the “target altitude” set in the fcu is above or below the aircraft’s current altitude. during descent, the target altitude is generally set by the crew to the missed-approach altitude, in case a go-around is needed. if speed protection causes mode reversion when the plane is below this altitude, the new mode will be op clb (open climb), which will cause the plane to climb towards the altitude set in the fcu. the climb is performed at maximum thrust, using a flight path angle that will maintain the set airspeed. 3 / 16 volume 45 (2011) http://www.youtube.com/watch?v=vqmrrfeyzbi http://www.youtube.com/watch?v=vqmrrfeyzbi formal modeling and analysis for interactive hybrid systems this mode change is likely to occasion an automation surprise, as the mental state of the pilots will be “descent and landing” and they will not be expecting the aircraft suddenly to reverse direction from gradual descent to a strong climb. the response to such a surprise will depend on the training and performance of the crew. in the case of flight 381, the pilots disconnected the autopilot but left the autothrottle engaged, which continued to command high thrust; they then (apparently inadvertently) commanded maximum upward pitch trim, which they countered with down elevator. when they relaxed the down elevator, the aircraft was massively out of trim and pitched violently upwards and stalled. due to this and several similar incidents, airbus modified speed protection so that the aircraft stays in v/s fpa mode, but adjusts its flight path angle to remain below the maximum permitted speed. 3 formal modeling issues one approach to formal analysis of human-automation interaction issues builds on the proposition that human interaction with machines is guided by a mental model of the device concerned [jl83]. the nature of the model is subject to debate: some authors posit stimulusresponse rules, while others argue for a state machine or a similar representation that supports mental simulation of the device. our view is that a device or system will not be useable unless interaction with it can be guided by some simple representation. we use state machines as our representation and study the interaction of such a “mental model” with a state machine model of the actual system; the hypothesis of [rus02] is that significant divergences between the models indicate potential automation surprises, and a model checker can be used to detect such divergences and to construct scenarios that manifest them. now, how can we develop the state machine for a mental model? we are not seeking to develop or validate psychological insight, so we do not attempt to discover the models employed by individual human operators; rather, we suppose that the system developer explicitly or implicitly designs the system so that it can be operated with the aid of a relatively simple model, and part of the purpose of the system training manuals is to communicate that model. javaux [jav98] suggests that training induces fairly detailed and precise state machine models, which are then simplified through experience and forgetfulness. he proposes (and has validated) two specific processes: frequential simplification causes rarely taken transitions, or rarely encountered guards on transitions, to be forgotten, while inferential simplification causes transition rules that are “similar” to one another to be merged into a single prototypical rule that blurs their differences. plausible mental models could conceivably be constructed mechanically using javaux’ insights: extract the state machine implied by the training manuals, then iteratively apply the two simplification rules until a fixed point is obtained. however, our previous examples, [rus02] (md-88), [cjr00] (a320), and [rus00] (737) use very crude mental models that represent little more than plausible expectations about vertical direction (i.e., whether the pilot expects the aircraft to climb or to descend), and the representation of the aircraft automation is also highly abstracted. a divergence is considered to occur when the vertical direction of the mental model is opposite to that commanded by the automation. a valid objection to the modeling used in these examples is that no aircraft is present! an automation surprise is modeled as a divergence between the state of the mental model and that of proc. fmis 2011 4 / 16 eceasst the automation but, in reality, the state of the automation is not always known to the pilot (that is often the root cause of the automation surprise); a true automation surprise is surely a divergence between the state of the mental model and the actual behavior of the aircraft—as observed via its instruments or through the seat of the pants. to model and analyze this more realistic interpretation, we need to introduce the dynamics of the aircraft, and the ways in which these are controlled by the automation. as noted earlier, this takes us into the realm of hybrid systems where, despite much impressive research, the problems of model checking and verification remain computationally formidable. our approach is to remain very abstract (i.e., approximate) but to introduce “just enough” modeling of the dynamics that we are able to detect anomalies very efficiently and can generate scenarios that may be used to guide high-fidelity simulations. for the a320 speed protection example, we need to model how the thrust and pitch values computed by the control laws of the autothrottle and autopilot, and the flap setting commanded by the pilots, determine the trajectory of the airplane. we are interested only in the vertical dimension, so we focus on altitude and airspeed and the derivatives of these. now it might seem that we need differential equations to model these attributes—and indeed, we do for full fidelity. but for our purposes, something much cruder suffices: we can ignore the metric element of time and simply assert relationships among the continuous state variables “now” and those in any future state, provided the airplane stays in the same discrete mode. for example, if the pitch angle is positive, we can assert that the altitude any time in the future will be greater than it is now, provided there is no change in discrete parameters (such as the flaps setting, or the pitch angle itself). there is, in fact, a very strong and sound new method for analysis of hybrid systems based on relational abstractions of this type [st11]. the difference between that approach and ours is that sound relational abstractions are calculated from a hybrid system model by specialized invariant generation, whereas we simply assert a relation as our model. we claim that this is sufficient for our purposes: provided our relations are conservative (i.e., admit more behaviors than would an accurate model), we are certain to discover anomalies if they exist. of course, we may discover spurious anomalies if our modeling is too approximate. what we will do is construct very approximate models to begin with, then, if we discover an interestingly anomalous scenario (e.g., one in which the pilot’s mental mode is “descend” but airplane is climbing), we can refine the model until the scenario becomes realistic or is found to dissolve as an artifact of excessive approximation. once we have developed a realistic scenario with the model checker, we will attempt to reproduce it in a high-fidelity simulation. relational approximations allow us to eliminate derivatives and differential equations but we must still consider how to represent the relations in a form that a model checker can accept and analyze. model checkers differ greatly in the ways models may be specified, and in the kinds of analysis they support. some model checkers employ a modeling language similar, or even identical, to a programming language, while others provide a more abstract notation. among the latter, “guarded commands” are a popular choice. these consist of a series of commands of the following form guard --> var = expression where the guard is some predicate over the state variables, var is one of the state variables, 5 / 16 volume 45 (2011) formal modeling and analysis for interactive hybrid systems and expression is some expression over the state variables. the interpretation is that in a state where the guard evaluates to true, the state variable var can be updated to the result of evaluating expression in that state. it usually is possible to have multiple assignments, so that several state variables can be updated atomically. if more than one guard evaluates to true, then one is chosen nondeterministically. most model checkers also allow nondeterministic assignment so that a set of expressions may appear on the right, and one is chosen nondeterministically. it is sometimes useful if the value newly assigned to one state variable can be used in the expression assigned to a second. primes are often used for this purpose, so that the example above would become guard --> var’ = expression and primed variables may then appear in the expression (some analysis may be necessary to eliminate circular dependencies). some model checkers further allow primed variables to appear in the guard. with this background, we now describe three methods for specifying relational models. to make it concrete, we suppose we are trying to specify a model in which altitude must increase when pitch angle is positive, and we will use the concrete syntax of the sal suite of model checkers from sri [sal]. our first method is the following. 1pitch > 0 --> altitude’ in {x | x > altitude} here pitch and altitude are state variables of some numeric type; the in construct is sal’s notation for nondeterministic assignment, and the relation appears directly within this construct: it says that the new value of altitude is chosen nondeterministically from those values greater than its current value. a second method is the following. 2pitch > 0 and (altitude’ > altitude) --> altitude’ in {x | true} here, the assignment is totally nondeterministic and the relation appears in the guard. many model checkers do not allow primed variables in the guards and so they cannot support this method. the third method employs a synchronous observer. this is a separate model, synchronously composed with the first, that observes the state of the system and sets a new boolean state variable ok to false when it observes a violation of the relational constraint. for our simple example, the basic model will use a totally nondeterministic assignment 3pitch > 0 --> altitude’ in {x | true} and the observer will enforce the relation as follows. 4not (altitude’ > altitude) --> ok’ = false when we run the model checker, we will instruct it to consider only those runs where ok is true. for example, when model checking for some invariant property prop, we will use a specification of the following form, where g (sometimes written �) is the always modality of linear temporal logic (ltl).1 1 a model checker using computation tree logic (ctl) would use ag in place of g. proc. fmis 2011 6 / 16 eceasst g(ok implies prop) while the first method seems the most attractive in this simple example, it does not extend to the case where assignments are made to several state variables and the new values must satisfy some joint relation (e.g., assign to x and y such that x*x + y*y < 1). the second method can deal with this case but, as already noted, many model checkers do not allow primed variables in the guards. hence, for widest applicability, we will employ the third method; we will see later that use of a synchronous observer also makes it easy to refine the relation (by simply adding more constraints). primed variables in the guards of a synchronous observer can be eliminated, if necessary, by introducing additional variables to store the previous values of the state variables concerned (so the model operates on values delayed by one time unit: “previous” and “now,” rather than “now” and “next.”) we now turn to the representation of numerical values for quantities such as altitude and pitch. a crude approximation simply uses a discrete enumeration to represent ranges of numeric values (e.g., low, medium, and high for altitude). however, most modern model checkers directly support the use of bounded integers (e.g., in the range -32,786 to 32,767) by encoding them as bitvectors. model checking is accomplished by translating the model to a purely boolean representation that is analyzed by a bdd or sat engine, so operations such as addition are performed by compiling the representation for a binary adder into the translation sent to the backend engine.2 the bitvector representation is adequate for many examples, but it is computationally expensive so that models with many numerical state variables can become difficult to analyze. furthermore, the “natural” representation for quantities such as pitch and altitude is surely as real numbers, by which we mean the mathematical notion of real numbers, not approximations such as floating point.3 fortunately, there is a technology that supports this representation, and also mathematical (i.e., unbounded) integers; this is the technology of “infinite bounded model checking” [mrs02]. in its basic form, bounded model checking (bmc) takes a finite state model of a system, a putative invariant for the system (i.e., a property that should be true in all its reachable states), and a natural number k, and determines whether there is a counterexample to the property of length k steps or less. the finite state model is translated to a boolean representation and “unrolled” k times, the property is likewise represented in boolean form, and these two boolean representations are combined to pose a problem that can be solved by a propositional satisfiability (sat) solver: bmc can be extended from refutation (i.e., bug-finding) to verification by slightly reformulating the underlying sat problem so that it performs k-induction [mrs03]. sat solving can be generalized from the purely propositional case to satisfiability modulo theories (smt), which supports several useful theories, including the real numbers, mathematical (i.e., unbounded) integers, and uninterpreted functions [rus06]. bmc and k-induction can then be reformulated to target the capabilities of smt solvers; this is referred to as infinite bmc, because it operates over potentially infinite state spaces, such as those involving real numbers. in additional to supporting more realistic models, infinite bmc over reals and integers is often 2 the different traditions and technologies that contribute to model checking use different terms for the same notions—bitvectors, and binary, boolean or propositional representations—they are all equivalent for our purposes. 3 cockpit instruments may display altitude in terms of integer feet, or flight level, but the underlying physical parameter—the actual height of the airplane above the ground—is a real-valued quantity. 7 / 16 volume 45 (2011) formal modeling and analysis for interactive hybrid systems faster than ordinary bmc using bitvector representations for bounded integers. smt solvers, and hence infinite bmc, allow the use of uninterpreted functions: these are functions about which nothing is known, save what is supplied via axioms. the attraction here is that the totally nondeterministic assignment in 3 can be replaced by one that indicates the state variables on which this assignment should depend. this does not change the reachable states of the model (those are determined by the relational constraint enforced by the synchronous observer of 4 ) but it conveys more of the intuition behind the model, and this can help in communicating with those who develop the more detailed simulation models. specifically, we can introduce an uninterpreted relation (which can be thought of as an uninterpreted higher-order function that returns a set of values) ad (standing for altitude dynamics) that takes an altitude and a pitch angle and returns the set of possible new altitudes. this relation would be defined in sal like this ad(alt: real, pitch: real): [real -> boolean] (so that ad(x, y)(z) is true if z is among the possible new altitudes when the current altitude and pitch are x and y, respectively) and the guarded command of 3 can then be written as follows. pitch > 0 --> altitude’ in ad(altitude, pitch) now that we have introduced our approach to relational modeling of interactive hybrid systems, and methods for representing and analyzing these with a model checker, we are ready to illustrate the approach using the a320 speed protection example introduced previously; this is the topic of the following section. 4 example: formal analysis for a320 speed protection the behavior of the a320 and its speed protection system, as described in section 2, emerges from the interaction of several separate components: the pilots and the devices they manipulate (fcu, sidestick etc.), the autopilot and autothrottle, the engines, and the dynamics of the aircraft. since the purpose of this example is illustration, we will omit many details and lump some of the components together: in particular, we will combine the autopilot and autothrottle into one component called automation, we will combine all aspects of human-automation interaction into a component called pilots, and we will combine the dynamics of the aircraft with its engines into another component called airplane. as we are interested only in the behavior of the aircraft in the vertical direction, we model just its altitude and airspeed, and ignore its heading and horizontal position. we first outline each of the three lumped component models, then present their actual specification. we begin with the automation. this is a fairly conventional state machine: it takes as inputs various controls and values set by the pilots (desired vertical mode, fcu altitude and flight path angle, flap setting) and the current state of the airplane (its airspeed and altitude), determines the actual vertical mode to be used (which may be different than that desired by the pilots if a protection is being applied), and applies control laws to determine the thrust and proc. fmis 2011 8 / 16 eceasst pitch settings to be used by the airplane. notice that thrust and pitch are modeled as parameters to internal communications from automation to airplane; they are not observed by the pilots directly. the pilots take the state of the airplane (airspeed and altitude) as inputs (given by instruments and, presumably, their own kinesthetics), and perform various actions such as dialing values for altitude and flight path angle into the fcu, setting the desired vertical mode, and extending or retracting the flaps. they perform these actions in the context of a “mental mode” (descending, climbing, level flight) that provides coherence: for example, they will not extend the flaps when the mental mode is “climbing.” this behavior can be modeled by a conventional state machine. the airplane takes as input the thrust and pitch values computed by the control laws of the automation, and the flap setting commanded by the pilots, and simulates the aircraft dynamics to calculate its trajectory through space, of which we model only altitude and airspeed. having described the general approach, we now present the example concretely using the notation of sal. a320sp: context = begin flap_config: type = {retracted, extended}; vertical_mode: type = {vs_fpa, op_clb, op_des, other}; mental_modes: type = {climb, descend, level}; speedvals: type = {x: real | x >= 0 and x < 700}; altvals: type = {x: real | x >= 0 and x < 43000}; thrustvals: type = {x: real | x >= 0 and x <= 100}; pitchvals: type = {x: real | x >= -9 and x <= 30}; vmax: speedvals = 400; vfe: speedvals = 180; the specification begins with its name a320sp (“sp” for speed protection) and is kept in a file named a320sp.sal. next, we introduce types for some of the state variables. first, flap config is an enumerated type used to specify flap configurations (we abstract all degrees of extension into the single value extended), then vertical mode enumerates the various modes of the automation: we focus on vs fpa (v/s fpa), op clb (op clb) and op des (op des), and abstract all others into other. the mental modes of the pilots are also enumerated here. next, we introduce the types that will represent airspeeds, altitudes, thrust settings, and pitch: these are modeled as suitable subranges of the real numbers. we also specify constants for the maximum speeds permitted for the airplane: vfe is the maximum when the flaps are extended, and vmax when they are retracted. these and other numeric constants appearing in the specification were chosen somewhat arbitrarily: we do not know the true values. then we introduce the uninterpreted functions (they are actually relations but, as noted before, sal models these as higher-order functions whose range type is a predicate) that describe the dynamics of the airplane: there are two pairs of functions, one giving the airspeed dynamics, the other the altitude, each in two variants, depending on whether the flaps are extended or retracted (i.e., the wing is “clean”). these functions take the current airplane airspeed, altitude, engine thrust, and pitch angle and deliver sets (modeled as predicates—i.e., functions with 9 / 16 volume 45 (2011) formal modeling and analysis for interactive hybrid systems range type boolean) of airspeed or altitude as appropriate. to avoid cluttering the page, we replace function arguments with ... after the first. speed_dynamics_clean(airspeed: speedvals, altitude: altvals, thrust: thrustvals, pitch: pitchvals): [speedvals -> boolean]; alt_dynamics_clean(...): [altvals -> boolean]; speed_dynamics_flaps(...): [speedvals -> boolean]; alt_dynamics_flaps(...): [altvals -> boolean]; next, we introduce uninterpreted functions that represent the control laws applied by the automation. these also are specified in pairs: one member of each pair computes the engine thrust to be applied, the other the pitch angle to be flown. the functions take as arguments the current airspeed, the flight path angle set in the fcu (fcu fpa), the current altitude, the target altitude set in the fcu (fcu alt), the current pitch angle and the flaps setting. there is a separate pair of control law functions for each mode of the automation: vs fpa, op clb, and op des. to save space, we omit the thrust control law functions. vs_fpa_pitch_law(airspeed: speedvals, fcu_fpa: pitchvals, altitude: altvals, fcu_alt: altvals, pitch: pitchvals, flaps: flap_config): [pitchvals -> boolean]; op_clb_pitch_law(...): [pitchvals -> boolean]; op_des_pitch_law(...): [pitchvals -> boolean]; now we can specify the automation as a state machine. this takes the current flaps setting, fcu alt, fcu fpa, and fcu mode (all set by the pilots), and the current airspeed and altitude (set by the airplane), and outputs the thrust and pitch angle settings, and also the actual mode whose control laws it is applying. automation: module = begin input flaps: flap_config, fcu_alt: altvals, fcu_fpa: pitchvals, fcu_mode: vertical_mode, airspeed: speedvals, altitude: altvals output thrust: thrustvals, pitch: pitchvals, actual_mode: vertical_mode, max_speed: speedvals initialization actual_mode = fcu_mode definition max_speed = if flaps = retracted then vmax else vfe endif; transition [ track-fcu-mode: fcu_mode’ /= fcu_mode --> actual_mode’ = fcu_mode’ [] mode_reversion: actual_mode = vs_fpa and airspeed > max_speed --> actual_mode’ = if fcu_alt > altitude then op_clb else op_des endif; [] vs_fpa_mode: actual_mode = vs_fpa and airspeed <= max_speed --> pitch’ in vs_fpa_pitch_law(...) [] op_clb_mode: actual_mode = op_clb --> pitch’ in op_clb_pitch_law(...) [] op_des_mode: actual_mode = op_des --> pitch’ in op_des_pitch_law(...) [] automation_idles: else --> ] end; proc. fmis 2011 10 / 16 eceasst the guarded commands appearing in the transition section and separated by [] symbols specify the behavior of the state machine: each command has a label (whose only purpose is to provide identifying information in counterexamples) followed by a colon, then the guard (a boolean expression), then an arrow (-->) followed by a series of assignments. at each step, some true guard is selected (the else guard will be true if none of the others are) and the corresponding assignments are executed atomically. recall that primed names represent the value of the state variable in the “new” state while unprimed values represent the “old” value, and notice that primed names can appear in guards and on the right side of assignments. thus, the guard of the command track fcu mode is true when the pilots have changed the setting of fcu mode, and the result of the assignment is to set the actual mode equal to the new value of the fcu mode. the guard of the command mode reversion is true when the actual mode is vs fpa and the airspeed exceeds the current maximum. the result of the corresponding assignment is to set the actual mode to op clb or op des as appropriate. the remaining guarded commands simply apply the control laws of the current actual mode. to save space, we omit all assignments to the thrust variable (these would be modeled as application of the thrust control laws of the autothrottle). next, we specify the behavior of the pilots. essentially, this is a nondeterministic choice among extending or retracting the flaps (only when the mental mode is descend or climb, respectively), dialing a (nondeterministic) value into fcu alt, switching the mental mode to descend or climb, or doing nothing. when the mental mode switches to descend or climb, the fcu mode is set to vs fpa and a nondeterministic negative or positive flight path angle, respectively, is dialed into fcu fpa. pilots: module = begin output flaps: flap_config, fcu_alt: altvals, fcu_fpa: pitchvals, fcu_mode: vertical_mode, mental_mode: mental_modes input airspeed: speedvals, altitude: altvals initialization mental_mode = level; fcu_mode = other; fcu_alt = 0; flaps = retracted; transition [ extend_flaps: mental_mode = descend and flaps = retracted --> flaps’ = extended [] retract_flaps: mental_mode = climb and flaps = extended --> flaps’ = retracted [] dial_fcu_alt: fcu_mode = other --> fcu_alt’ in {x: altvals | true} [] dial_descend: mental_mode /= descend --> mental_mode’ = descend; fcu_mode’ = vs_fpa; fcu_fpa’ in {x: pitchvals | x < 0}; [] dial_climb: mental_mode /= climb --> mental_mode’ = climb; fcu_mode’ = vs_fpa; fcu_fpa’ in {x: pitchvals | x > 0}; [] pilots_idle: true --> ] end; next, we present the model of the airplane. this has two modes, depending on whether 11 / 16 volume 45 (2011) formal modeling and analysis for interactive hybrid systems or not the flaps are extended, and simply applies the appropriate speed and altitude dynamics to yield (nondeterministic) new values for its output variables airspeed and altitude. we initialize these variables to values representative of the later stages of a descent. airplane: module = begin input thrust: thrustvals, pitch: pitchvals, flaps: flap_config output airspeed: speedvals, altitude: altvals initialization airspeed = 200; altitude = 3000; transition [ flying_clean: flaps = retracted --> airspeed’ in speed_dynamics_clean(airspeed, altitude, thrust, pitch); altitude’ in alt_dynamics_clean(...); [] flying_flaps: flaps = extended --> airspeed’ in speed_dynamics_flaps(...); altitude’ in alt_dynamics_flaps(...); ] end; we now need to specify a constraints module that enforces suitable relations on altitude and airspeed (thereby giving more interpretation to the airplane model) and on thrust and pitch (thereby giving more interpretation to the automation). this module will be a synchronous observer that takes many of the state variables of the system as inputs, and sets a variable ok to false whenever they violate the desired constraints. when we use model checking to examine properties of interest, we will restrict attention to those scenarios in which ok is true. constraints: module = begin output ok: boolean input airspeed: speedvals, altitude: altvals, thrust: thrustvals, pitch: pitchvals, actual_mode: vertical_mode, flaps: flap_config, fcu_alt: altvals, fcu_fpa: pitchvals, fcu_mode: vertical_mode, mental_mode: mental_modes initialization ok = true; transition [ actual_mode = op_des and pitch > 0 --> ok’ = false; [] actual_mode = op_clb and pitch < 0 --> ok’ = false; [] actual_mode = vs_fpa and fcu_fpa <= 0 and pitch > 0 --> ok’ = false; [] actual_mode = vs_fpa and fcu_fpa >= 0 and pitch < 0 --> ok’ = false; [] pitch > 0 and altitude’ < altitude --> ok’ = false; [] pitch < 0 and altitude’ > altitude --> ok’ = false; [] pitch=0 and altitude’ /= altitude --> ok’ = false; [] else --> ] end; proc. fmis 2011 12 / 16 eceasst the first guarded command ensures that when the actual mode is op des, then the pitch angle is not positive (the guarded commands specify what is not allowed, so the constraints are the negation of these); it is a constraint on the otherwise uninterpreted op des pitch law of the automation. the next three guarded commands similarly add constraints to the other control laws. the fourth guarded command ensures that the altitude increases when the pitch angle is positive and the remaining commands deal with the cases of negative or zero pitch angle; these three commands are constraints on the airplane model. finally, we can specify the property we wish to examine: that is, an automation surprise where the mental mode of the pilots is descend but the airplane is (strongly) climbing. we specify this in another synchronous observer that raises (and latches) an alarm variable when it sees a violation of the desired property: altitude’ altitude > 0 indicates a climb and we (somewhat arbitrarily) substitute 90 for 0 as the indication of a strong climb. observer: module = begin output alarm: boolean input mental_mode: mental_modes, altitude: altvals initialization alarm = false transition alarm’ = alarm or (mental_mode = descend and altitude’ altitude > 90) end; we specify the system as the synchronous composition of the five modules introduced above (in this kind of composition, a step of the system comprises a step by each of its components). system: module = airplane || automation || pilots || constraints || observer; then we specify (as the theorem surprise) the invariant that the alarm is never raised, provided the constraints are satisfied (i.e., ok is true); any counterexample to this invariant will be an anomalous scenario that manifests an automation surprise. surprise: theorem system |g(ok implies not alarm); we use infinite bmc to examine this claim. sal-inf-bmc a320sp.sal surprise -v 3 -it -d 20 this command names the claim surprise to be examined in the file a320sp.sal, sets the verbosity level to 3, and instructs the model checker to iteratively increase the number of steps in the examination from 1, 2, . . . to a maximum depth of 20 (the default is 10). the model checker discovers a violation of the property in five steps in a fraction of a second. the scenario is summarized below (we use simple unix scripts to format these tables from the raw sal output). the numbered rows give the values of the state variables (we abbreviate names and omit several variables to save space) and the intervening unnumbered rows name the commands of the airplane, automation, and pilots modules, respectively, that produced the transition from the state above to the one below. 13 / 16 volume 45 (2011) formal modeling and analysis for interactive hybrid systems (to conserve space, we omit the first step, in which fcu alt is set by dial fcu alt.) step act mde airspd alt fcu alt fcu fpa fcu md flaps mx spd mntl md pitch 1 other 200 3000 3001 -1 other rtrctd 400 level 0 commands: flying clean, track fcu md, dial descend 2 vs fpa 401 3000 3001 -2 vs fpa rtrctd 400 descend 0 commands: flying clean, mode reversion, extend flaps 3 op clb 180 3000 3001 -2 vs fpa extnd 180 descend 0 commands: flying flaps, op clb mode, pilots idle 4 op clb 0 3000 3001 -2 vs fpa extnd 180 descend 1 commands: flying flaps, op clb mode, pilots idle 5 op clb 0 3091 3001 -2 vs fpa extnd 180 descend 0 we see that a mode reversion has occurred, causing a climb while the mental mode is descend, but it is caused by the airspeed abruptly increasing from 200 to 401 (thereby exceeding vmax). we observe some other unfortunate attributes in this counterexample: for example, in steps 4 and 5 the airspeed decays to 0. these abrupt changes in airspeed are contrary to our intuition, but consistent with our specification because we have no constraints on the uninterpreted functions speed dynamics clean and speed dynamics flaps that represent the dynamics of this variable. sal and its backend smt solver yices [sal] find “simple” satisfying instantiations for uninterpreted functions: there is nothing that requires these functions to be “continuous,” so the solver just finds values for the points needed to construct the counterexample. we need to add further constraints to our model and to refine some of those already present so that they more accurately represent the dynamics. [] airspeed’> airspeed+10 or airspeed’< airspeed-10 --> ok’ = false; [] pitch > 0 and altitude’ < altitude+10*pitch --> ok’ = false; [] pitch < 0 and altitude’ > altitude+10*pitch --> ok’ = false; [] pitch=0 and (altitude’> altitude+10 or altitude’< altitude-10) --> ok’ = false; the first of these guarded commands is a new rule that requires airspeed to change by no more than 10 between steps. the next three commands are refinements of those already present: they couple altitude more tightly to pitch. with these adjustments to the constraints module, we invoke the model checker again, and receive the following counterexample. step act mde airspd alt fcu alt fcu fpa fcu md flaps mx spd mntl md pitch 1 other 200 3000 3291 -1/50 other rtrctd 400 level -1/100 commands: flying clean, track fcu md, dial descend 2 vs fpa 201 2989 3291 -1/100 vs fpa rtrctd 400 descend -1/100 commands: flying clean, vs fpa mode, extend flaps 3 vs fpa 200 2988 3291 -1/100 vs fpa extnd 180 descend 0 commands: flying flaps, mode reversion, pilots idle 4 op clb 201 2989 3291 -1/100 vs fpa extnd 180 descend 0 commands: flying flaps, op clb mode, pilots idle 5 op clb 200 2990 3291 -1/100 vs fpa extnd 180 descend 1/50 commands: flying flaps, op clb mode, pilots idle 6 op clb 190 3291 3291 -1/100 vs fpa extnd 180 descend 3/100 proc. fmis 2011 14 / 16 eceasst this counterexample manifests the automation surprise from section 2, and does so with a plausible scenario: the fcu alt is set to 3291 while the aircraft is flying at 3000; the pilots decide to descend and enter a negative fcu fpa; they then extend the flaps, which causes overspeed and a mode reversion to op clb mode, which in turn causes a strong climb. some infelicities remain in the scenario: for example, the values for pitch and fcu fpa are implausible. these can be adjusted by adding additional commands to the constraints module. although formally equivalent, there is a conceptual distinction between constraints that truly refine the model and those that serve merely to nudge the counterexample in a preferred direction; if desired, the latter can be placed in a separate synchronous observer module. although we have not developed this example beyond what is described here, we are confident (because of the strength of abstraction available) that the approach can be applied to more detailed and realistic specifications of aircraft automation and human mental models. 5 conclusions we have described and illustrated a method for modeling and analyzing interactive hybrid systems at a very abstract level. this enables us to model human-machine interactions in the presence of physical plant, such as airplanes, whose dynamics are described by differential equations. the method uses relational abstractions for the hybrid components: these are approximations that specify relations between the continuous state variables “now” and any future state, provided the discrete variables remain the same. we described how relations may be specified to a conventional model checker using synchronous observers. automated analysis of our approximations builds on the ability smt solvers to reason over the theories of uninterpreted functions and arithmetic, and the exploitation of this ability by infinite bounded model checkers. of course, any discrete approximation for the hybrid components enables model checking of interactive hybrid systems; the arguments in favor of our method are that we can be reasonably confident of soundness, it is easy to refine the models, and it is easy to analyze them. for soundness (with respect to safety properties) it is necessary that the behaviors of our relational approximations are a superset of those of a fully accurate model (i.e., with differential equations). it is possible to derive such sound approximations by analysis of the accurate model [st11] but this is computationally challenging. what we do instead is assert simple relations in whose soundness we are confident (e.g., when pitch angle is positive, altitude increases).4 if model checking reveals a potential automation surprise, then it is easy to refine the approximation by adding additional relational constraints to the synchronous observer so that a realistic scenario is developed, or the anomaly is found to be due to excessive approximation. this approximation method is suitable for examining new air traffic procedures for humancomputer interaction issues; when a possible problem is identified, additional constraints can be used to push the counterexample toward a plausible scenario that can be examined in a higher fidelity modeling environment, such as a simulator. the nextgenaa project plans to evaluate this method on new procedures such as continuous descent approach (cda) and oceanic airspace in-trail procedure (atsa itp) [bbf+11]. verifying safety, or finding anomalies, in complex interactions such as these, involving humans, automation, and hybrid/dynamic systems, requires very strong, but appropriate use of abstraction in modeling. the method introduced in this paper 4 this might not be true in certain conditions, such as downdrafts; that is outside our model, but could be added. 15 / 16 volume 45 (2011) formal modeling and analysis for interactive hybrid systems adds a new approach to the collection of highly abstract modeling and analysis methods available for this and similar domains. acknowledgements: ashish tiwari introduced us to relational abstractions, and to some of the ways to represent them in sal. bibliography [bbf+11] e. j. bass, m. l. bolton, k. m. feigh, d. griffith, e. gunter, w. mansky, j. rushby. toward a multi-method approach to formalizing human-automation interaction and human-human communications. in ieee international conference on systems, man, and cybernetics. anchorage, ak, oct. 2011. to appear. [bea94] bureau d’enquêtes et d’analyses pour la sécurité de l’aviation civile. report on the incident on 24 september 1994 during approach to orly (94) to the airbus a 310 registered yr-lca operated by tarom. 1994. report yr-a940924a. [cjr00] j. crow, d. javaux, j. rushby. models and mechanized methods that integrate human factors into automation design. in abbott et al. (eds.), international conference on human-computer interaction in aeronautics: hci-aero 2000, pp. 163–168. toulouse, france, sept. 2000. [jav98] d. javaux. explaining sarter and woods’ classical results. in leveson and johnson (eds.), 2nd w’kshop on human error, safety, and s/w design. seattle, wa, apr. 1998. [jl83] p. n. johnson-laird. mental models. cognitive science series 6. harvard university press, cambridge, ma, 1983. [mrs02] l. de moura, h. rueß, m. sorea. lazy theorem proving for bounded model checking over infinite domains. in voronkov (ed.), 18th international conference on automated deduction. lncs 2392, pp. 438–455. copenhagen, denmark, july 2002. [mrs03] l. de moura, h. rueß, m. sorea. bounded model checking and induction: from refutation to verification. in hunt, jr. and somenzi (eds.), computer-aided verification. lncs 2725, pp. 14–26. boulder, co, july 2003. [rus00] j. rushby. analyzing cockpit interfaces using formal methods. in bowman (ed.), proceedings of fm-elsewhere. electronic notes in theoretical computer science 43. elsevier, pisa, italy, oct. 2000. [rus02] j. rushby. using model checking to help discover mode confusions and other automation surprises. reliability eng. and system safety 75(2):167–177, feb. 2002. [rus06] j. rushby. harnessing disruptive innovation in formal verification. in hung and pandya (eds.), fourth international conference on software engineering and formal methods, pp. 21–28. pune, india, sept. 2006. [sal] sal and yices home pages. http://sal.csl.sri.com/ and http://yices.csl.sri.com/. [st11] s. sankaranarayanan, a. tiwari. relational abstractions for continuous and hybrid systems. in computer-aided verification. lncs. snowbird, ut, 2011. to appear. [swb97] n. b. sarter, d. d. woods, c. e. billings. automation surprises. in salvendy (ed.), handbook of human factors and ergonomics. wiley and sons, 2nd edition, 1997. proc. fmis 2011 16 / 16 http://sal.csl.sri.com/ http://yices.csl.sri.com/ introduction an example scenario: a320 speed protection formal modeling issues example: formal analysis for a320 speed protection conclusions model-driven constraint engineering electronic communications of the easst volume 5 (2006) proceedings of the sixth ocl workshop ocl for (meta-)models in multiple application domains (oclapps 2006) model-driven constraint engineering michael wahler, jana koehler and achim d. brucker 20 pages guest editors: dan chiorean, birgit demuth, martin gogolla, jos warmer managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.zurich.ibm.com/~wah/ http://www.zurich.ibm.com/~koe/ http://www.brucker.ch/ http://www.easst.org/eceasst/ eceasst model-driven constraint engineering michael wahler1, jana koehler2 and achim d. brucker3 1 wah@zurich.ibm.com, 2 koe@zurich.ibm.com ibm zurich research laboratory saeumerstrasse 4, 8803 rueschlikon, switzerland 3 brucker@inf.ethz.ch information security, eth zurich 8092 zurich, switzerland abstract: precise specification of meta-models is an important prerequisite for the successful application of a model-driven engineering (mde) process. one means of precise specification are textual constraints. however, the task of constraint development is time-consuming and error-prone if done manually. in this paper, we present both a methodology and a tool for developing constraints in a systematic way that can be integrated into a case tool. thus, we provide a semi-automated means for integrating constraints into the mde process. our approach is based on an extensible library of generic constraint patterns. constraint patterns can be combined to create complex constraints and easily parameterized in a case tool. moreover, we show how these parameterized patterns are transformed into platform-independent or platform-specific constraints by a model transformation. keywords: constraint, pattern, model-driven engineering, uml, ocl 1 introduction in model-driven engineering (mde), a model defines the building blocks from which instances can be constructed. the main building blocks in the meta-object facility (mof, [obj02]) are classes, their structural features and associations between the classes. models are usually specified with a concrete graphical syntax, which allows for rough specification only. the set of possible instances grows with the number of building blocks that are defined in the model. in general, not all possible instances are valid with respect to the semantics of the model. therefore, textual constraints are used on the model to express details that are either difficult or even impossible to express in a diagrammatic way. adding constraints to a model usually decreases the number of possible instances unless contradictory constraints are introduced. constraints stem from different sources: there may be legal restrictions that a system needs to obey; there may be company policies that grant privileges to certain kinds of customers; there may be technical restrictions on a system [clw+06]; there may be security restrictions [lbd02]; and there may be facts that are implied by common sense that cannot be expressed diagrammatically. for instance, hundreds of constraints are used in the specification of the unified modeling language (uml) meta-model [obj05]. 1 / 20 volume 5 (2006) http://www.zurich.ibm.com/~wah/ http://www.zurich.ibm.com/~koe/ http://www.brucker.ch/ mailto:wah@zurich.ibm.com mailto:koe@zurich.ibm.com mailto:brucker@inf.ethz.ch model-driven constraint engineering whereas models were solely used for documentation and communication purposes in the past, recent model-centric development approaches use models as first-class artifacts in the development process. for instance, business process models can be transformed to executable code that is run on process execution engines [hk04] or models in a domain-specific security language are transformed to uml [bdw06]. to guarantee correctness of the execution of the generated code, it is crucial that every model instance conforms to its defining model and satisfies its constraints. these validity checks can be performed automatically if the constraints are formalized. for instance, tools exist that type-check a set of ocl (object constraint language [obj03]) constraints and validate a model against them [árf03]. alternatively, validity checks can be implemented in a programming language, e. g., java, using a model–access api. creation and maintenance of constraints are tedious tasks. in a case study we performed in a business modeling environment, about 80 constraints were necessary to guarantee the executability of a behavioral model for business process monitoring. all constraints are invariants on the model elements and restrict the set of allowed model instances to a set that is executable on a process execution engine. whereas some of these constraints were rather simple, many complex constraints needed to be formalized, which turned out to be a time-consuming and error-prone task. the formalization resulted in approximately 500 lines of ocl code, which by nature are unlikely to be bug-free. furthermore, the meaning of formal constraints is often misunderstood by novice users [cab06]. even if the constraint expressions and the validation code do not contain any errors, they need to be adapted once the model changes. this usually results in additional time-consuming coding and debugging phases, especially in refactorings [cw04, mb05] where models undergo frequent changes and the attached constraints need to be kept consistent with new versions of the model. our contribution to solving the problem of constraint development consists of four parts. firstly, we introduce the notion of computation-independent constraint patterns and show how to transform them into platform-independent or platform-specific constraints. secondly, we introduce a library of constraint patterns, separate the patterns into atomic and composite patterns, and add a structure to them to enhance their expressiveness and usability. thirdly, we provide metaconstraints that restrict the parameter values of the constraint patterns, thus excluding invalid pattern instances. fourthly, we discuss the requirements for integrating model-driven constraint engineering in a case tool and illustrate our prototype for eclipse/uml2 [ecl]. we believe that a flexible pattern-based approach that is supported by a tool offers an important improvement for constraint engineering. most syntactic and semantic errors can be avoided because the developer can generate ocl code instead of writing it by hand. furthermore, our solution promises to decrease development time substantially. the paper is organized as follows: after presenting some examples motivating the use of patterns in section 2, we show how patterns can be derived by generalizing a concrete specification in section 3. in section 4, we present our library of patterns together with a taxonomy for them. to integrate patterns into an mde process, we first present the transformation of parameterized patterns to concrete constraints in section 5. then, we present how to add support for this approach to a case tool in section 6. we discuss related work in section 7 and conclude this paper with a summary of our contributions and pointer to future work in section 8. proc. oclapps 2006 2 / 20 eceasst 2 example model and constraints in figure 1 we illustrate a simple model of a company that serves as example throughout the remainder of this paper. the uml class diagram contains five classes, in which manager and employee are related by a many-to-many relation. each instance of employee is associated with exactly one office, whereas there are no restrictions on the number of inhabitants in one office. employee name : string salary : integer manager budget : integer office desks : integer normaloffice luxuryoffice * + inhabitant1 + office 1..* + worksfor * + employs figure 1: manager and employee class diagram besides the defined classes and associations, instances of this model are not restricted in any way: there may be managers without employees, and employees may have a salary of zero while working for multiple managers. however, there are additional requirements that each company has to comply with. we assume fictitious labor union and company it requirements that every work environment has to satisfy. the requirements are captured in the following constraints, informally in english and formally as ocl expressions. constraint 1. a manager with a budget of more than 100,000 must employ at least one employee with a salary of at least 3000. this constraint requires that for each instance m of manager whose budget is greater than 100,000, there exists an instance e of employee that is related to m by the relation employs. furthermore, the value of the salary attribute of e must be at least 3000. context manager inv: self . budget > 100000 implies self.employs−>exists( e | e.salary >= 3000) constraint 2. a manager may not occur twice within the management hierarchy. this constraint prevents that a manager m is responsible for him-/herself by being related to him-/herself directly by the worksfor relation or indirectly by other managers {mi, . . . , m j} who work for m. formally, a manager may not be an element of the transitive closure of the worksfor relation. however, ocl does not provide an operator to compute the transitive closure of a relation. thus, we need to define an operation closureworksfor(s) that computes the transitive closure [baa03] of the worksfor relation. we use the parameter s to ensure the termination of the computation. this parameter stores the elements for which the transitive closure has been computed; it is initially empty. in each step, the set s is deducted from the set of elements in the worksfor relation. eventually, s contains all elements in the transitive closure, and the computation terminates. 3 / 20 volume 5 (2006) model-driven constraint engineering context manager def: closureworksfor(s:set(manager)) : set(manager) = worksfor−>union((worksfor − s)−> collect (m : manager | m.closureworksfor(s−>including(self)))−>asset()) inv: not self . closureworksfor(set{})−>includes(self) constraint 3. the company may not have more than five organizational layers. this constraint restricts the depth of the worksfor navigation path. because a manager can employ another manager, arbitrary hierarchy levels can be instantiated. however, constraint 3 forbids more than five hierarchy levels. therefore, we define the recursive query pathdepthworksfor(max,counter) that evaluates if the worksfor relation adheres to the maximum path depth. this query has two parameters, max and counter, where max is set to the desired maximum path depth minus 1 and counter is initialized with 0. the query terminates with false if the value of counter is greater than the value of max, i.e., the maximum path depth has been exceeded. otherwise, the counter is increased and the query recursively evaluated on all elements that are related by worksfor. context manager def: pathdepthworksfor(max:integer, counter:integer): boolean = if (counter > max or counter < 0 or max < 0) then false else if ( self . worksfor−>isempty()) then true else self . worksfor−>forall(m:manager|m.pathdepthworksfor(max, counter+1)) endif endif inv: self . pathdepthworksfor(4,0) 3 deriving constraint patterns constraint patterns can be identified by analyzing existing constraints for recurring expressions and abstracting from them. in the following, we use the constraints from section 2 to illustrate how patterns are derived from concrete constraints. constraint 1 is an implication and thus consists of two parts, a premise and a conclusion. from an abstract point of view, the premise restricts the value of an attribute to a constant. in the conclusion, the existence of a certain instance related to the context object is required, and there is another value restriction on the attribute salary of the related instance. thus, we can identify the patterns exists and attributevaluerestriction, corresponding to existential quantification and value restriction respectively. from constraint 2, we can derive a pattern cyclicdependency that identifies cyclic navigation paths in model instances. finally, constraint 3 can generally be seen as a constraint that restricts the maximum length of a navigation path from which we derive the pathdepthrestriction pattern. in general, a constraint pattern is a higher-order function that maps a set of parameters to a constraint. the semantics of a constraint pattern can be provided in any language, e. g., parameterized ocl templates such as in [at06]. this has the advantage that an ocl constraint can simply be instantiated from such a pattern by providing values for the pattern parameters. in our solution, which we call model-driven constraint engineering, we follow the model driven architecture (mda) approach [kwb03], which comprises models at different levels proc. oclapps 2006 4 / 20 eceasst of abstraction. mda is an mde variant defined by the object management group, and we use mda and mde as synonyms in the remainder of this paper. we consider a constraint pattern a computation-independent model (cim) of a constraint, because no knowledge of a formal constraint language is required to apply a pattern as long as the informal semantics of the pattern is understood. such a cim constraint can be transformed into a platform-independent or platform-specific model (pim/psm) by a model transformation. following mda, the (formal) semantics of a pattern is defined within the transformations. therefore, we define two transformations for the cyclicdependency pattern that generate an ocl expression and java code. first, we need to define a signature for the pattern to specify the parameters and their types. the only parameter for this pattern is an ocl navigation expression, which is a sequence of properties. thus, the signature is cyclicdependency(navigation:sequence (property)). the transformations for this pattern are simple template–processing functions that replace the placeholders for the parameters with concrete values. the ocl template for the cyclicdependency pattern is self . closure(set{})−>includes(self), in which we assume the existence of a template function closure(). as mentioned, different target platforms can be used instead of generating ocl code. for instance, a template for the transformation to java validation code can be defined as follows. boolean validatecyclicdependency(list navigation) { set s = this . closure(navigation, new set()); if (s.includes( self )) return true ; else return false ; } a pattern can be instantiated by providing values for its parameters. however, not all pattern instantiations are meaningful. for instance, the navigation path that is used to parameterize the cyclicdependency pattern needs to be reflexive. to exclude meaningless parameter values such as negative values for multiplicity bounds, we define meta-constraints for each constraint pattern. these meta-constraints are usually very simple ocl expressions. for instance, the following meta-constraint ensures that the navigation path that is used to parameterize the cyclicdependency pattern is reflexive. self . class..class = self . class 4 a taxonomy of structured constraint patterns although the constraint pattern approach as it has previously been introduced [at06, cgq+06, mn05] reduces both the development time and error rate for model constraints, it has one important restriction: as each pattern represents a subset of all possible constraint expressions, there will be many constraints that are not expressible in terms of existing constraint patterns. this holds even if an extensive pattern library is used. therefore, we introduce the notion of structured constraint patterns, which adds a high degree of expressiveness to the constraint pattern approach by two measures. firstly, we introduce the 5 / 20 volume 5 (2006) model-driven constraint engineering logical concepts of implication and negation into the pattern model, which allows a user to create complex constraints from existing patterns. secondly, we divide constraint patterns into atomic and composite patterns. the set of atomic patterns represents recurring restrictions that we have identified, and it is extensible by the user. the composite patterns are recursively constructed from atomic patterns and represent higher-order concepts such as quantification. 4.1 adding logical structure to constraint patterns the core of our approach is the class structuredconstraint, which is a specialization of the uml meta-class constraint. this class contains the concepts of negation and implication, allowing instances of each pattern to be inverted and logically combined. structuredconstraint negated : boolean atomicconstraint compositeconstraint properties : constraint [*] constraint constrainedelement : element [*] * assumption figure 2: uml class diagram of structured constraint concept the concept of logical implication is implemented as shown in figure 2. each structured constraint c can have a finite set a of assumptions that can be any kind of constraint, which is illustrated by the association assumption from structuredconstraint to constraint. this allows us to use either arbitrary constraints (e. g., in ocl) or structured pattern instances as assumptions for constraints. the semantics of the assumption relation is defined as follows: let c be an instance of a structured constraint and a be a finite set of constraints that is related to c with the assumption relation. then the conjunction of all constraints in a implies c. the concept of logical negation is represented by the attribute negated of the class structuredconstraint. figure 2 also introduces the concepts of atomicconstraint and compositeconstraint, which are abstract subclasses of structuredconstraint. an example for this concept of structured constraints is constraint 1 from section 2. this constraint consists of three parts. the first part is the assumption self . budget > 100000, the second part the existential quantification self . employs−>exists( e | . . .), and the third part the properties of the quantification, e.salary > 3000. we consider the expressions in the assumption and the quantification property as atomic constraints, whereas we consider the quantification itself as a composite constraint. in the following, we elaborate on the concepts of atomic and composite constraint patterns. 4.2 atomic constraint patterns in this section, we present an extensible library of atomic constraint patterns. the idea of atomic constraint patterns is to identify a relevant set of atomic constraints that covers frequently occurring fundamental restrictions on a model, e. g., restrictions on attribute values or on relations proc. oclapps 2006 6 / 20 eceasst between objects. the patterns presented in this section originate from a case study in which we formalized constraints for a business process monitoring model [clw+06]. furthermore, we relate the patterns using generalization associations. this creates a taxonomy of patterns. this taxonomy gives a structure to the set of patterns and helps one to find the right pattern for a specific purpose. figure 3 illustrates the taxonomy of atomic constraint patterns we have identified. in this figure, the patterns are represented as classes that are related with generalization associations. the parameters of the patterns are specified as attributes, which refer to simple types such as integer, to uml meta-classes such as class, and to the ocl metaclass oclexpression. atomicconstraint associationtyperestriction allowedtypes : class [1..*] cyclicdependency pathdepthrestriction maxdepth : integer uniquepath pathrestriction navigation : property [1..*] injectiverelation surjectiverelation relationproperties relation : association attributevaluerestriction operator : oclexpression operand : oclexpression targetattribute : property multiplicityrestriction navigation : property operator : oclexpression operand : oclexpression objectincollection collection : oclexpression finiteinstanceset uniqueattributevalue targetattribute : property figure 3: uml class diagram of atomic constraint patterns in the following, we further specify the patterns in figure 3 with informal and formal semantics. whereas we use english for the informal semantics, we define the formal semantics in the form of ocl templates. these templates will later be the basis for the model transformation that generates ocl constraints from pattern instances. for each constraint pattern, we also define meta-constraints that ensure the well-formedness of pattern instances, as described in section 3. 4.2.1 attribute value restriction. the attributevaluerestriction pattern can be used to restrict the value of an attribute of a class for all instances of the class. it is a very simple pattern and thus well-suited for introducing our syntax for ocl templates to the reader. attributevaluerestriction ( targetattribute : property,operator,term:oclexpression): boolean = self .< targetattribute > there is one meta-constraint that instances of this pattern need to satisfy: the parameters targetattribute and term need to be of the same type. a) targetattribute . type = term.type example: the premise of constraint 1 from section 2—the fact that the budget of a manager must be greater than 100,000—can be expressed using an instance of this pattern. 7 / 20 volume 5 (2006) model-driven constraint engineering context manager inv: attributevaluerestriction (budget, >, 100000) 4.2.2 multiplicity restriction. the multiplicityrestriction pattern restricts the multiplicity of an association. whereas uml class diagrams allow for constraining multiplicities to a fixed interval, this pattern allows a user to define multiplicity restrictions that depend on properties of the model instance, e. g., an attribute value. multiplicityrestriction (navigation:sequence(property),operator,operand:oclexpression): boolean = self .−>size() we identified two meta-constraints for this pattern. firstly, the property navigation needs to evaluate to a collection. secondly, the operand must be a positive number. a) self ..ocliskindof(collection ) b) >= 0 example: a typical example of this pattern is the association between office and employee: the number of employees in an office may not exceed the number of desks in an office. context office inv: multiplicityrestriction ( inhabitant , <=, desks) 4.2.3 object in collection the objectincollection pattern can be used to express that the context element is in a collection of related objects. objectincollection(navigation:sequence(property)): boolean = self .−>includes(self) the parameter collection for this pattern needs to evaluate to a collection. a) self .< collection >.ocliskindof(collection ) example: this constraint pattern can be used to express that a manager needs to work in the same office with at least one employee, using the following pattern instance. context manager inv: objectincollection(employs.office. inhabitant ) 4.2.4 unique attribute value the uniqueattributevalue pattern requires that all instances of the constrained class have distinct values for the target attribute specified. this pattern is also known as “semantic key” [at06], “primary identifier” [mn05] or “identifier” [cgq+06] pattern in the literature. uniqueattributevalue( targetattribute : property): boolean = self . allinstances()−>isunique() proc. oclapps 2006 8 / 20 eceasst the only meta-constraint that needs to be satisfied is that the specified targetattribute belongs to the context class. a) targetattribute . class = self . class example: instances of the employee class are uniquely identifiable by their name attribute. context employee inv: uniqueattributevalue(name) 4.2.5 association type restriction the associationtyperestriction pattern can be used to restrict an association a that is defined between the context class and a superclass c0. using this pattern, it can be enforced that only instances of certain subclasses c1, . . . ,cn of c0, the allowedtypes, may participate in the relation. associationtyperestriction(navigation:sequence(property), allowedtypes:set(class)) = self .−>forall( x | −>exists( c | x.oclistypeof(c))) again, the property navigation needs to evaluate to a collection. a) self ..ocliskindof(collection ) example: our company model in figure 1 allows employees to work in any kind of office. this pattern can be used to enforce that managers must work in luxury offices. context manager inv associationtyperestriction( office ,{ luxuryoffice}) 4.2.6 cyclic dependency the cyclicdependency pattern can be used to identify cycles in the instance graph of a model. such a cycle requires a reflexive association or navigation path in the model. cyclicdependency(navigation:sequence(property)) = self . closure(set{})−>includes(self) for this pattern, we assume the existence of an operation that computes the transitive closure for each reflexive navigation. we further require that the parameter navigation denote a reflexive association, which we capture in the following meta-constraint. a) self .−>forall( x | x.class = self . class) example: an example instance of this pattern is constraint 2. as this constraints forbids the existence of a cycle, we need to use the negation feature that each pattern inherits from structuredconstraint, which can be textually represented as follows. context manager inv: not cyclicdependency(worksfor) 9 / 20 volume 5 (2006) model-driven constraint engineering 4.2.7 path depth restriction the pathdepthrestriction pattern can be used to restrict the maximum path length for instances of reflexive associations. pathdepthrestriction(navigation:sequence(property), maxdepth:integer) = self . pathdepth(maxdepth−1, 0) again, we assume the existence of a function that computes the path depth for each reflexive association. two meta-constraints need to be satisfied by instances of this pattern. firstly, navigation needs to be reflexive. secondly, the value maxdepth needs to be at least one, because of the definition of the path depth function (cf. section 2). a) self .−>forall( x | x.class = self . class) b) maxdepth >= 1 example: constraint 3 is an example instance of this pattern, where the maximum length of the employs association is restricted to 5. using the pattern, this constraint can be defined as follows. context manager inv: pathdepthrestriction(worksfor,5) 4.2.8 unique path the uniquepath pattern ensures that there is not more than one path from the context element to a related element. uniquepath(navigation:sequence(property)) = self .−>forall( x | self .−>count(x) = 1) again, the property navigation needs to evaluate to a collection. a) self ..ocliskindof(collection ) example: an infamous example configuration that can be excluded with this pattern was identified in [rc81] and became famous as the “nixon diamond” in nonmonotonic reasoning and as the “diamond of death” in object-oriented programming languages. in this configuration, four classes a, b, c and d are in the generalization relation ≺= {(a, b), (a,c), (b, d), (c, d)}. if b and c inherit a structural feature x from a, it is unclear whether d inherits b :: x or c :: x. thus, the path from a class to each superclass of its superclasses should be unique. context class inv: uniquepath(superclass.superclass) 4.2.9 injective relation the injectiverelation pattern can be used to establish the mathematical concept of an injective relation r : x ×y , i.e., r(x1, y)∧r(x2, y) → x1 = x2. injectiverelation (navigation:sequence(property)) = self .−>size() = 1 and self . allinstances()−>forall (x,y | x. = y. implies x=y) again, the property navigation needs to evaluate to a collection. proc. oclapps 2006 10 / 20 eceasst a) self ..ocliskindof(collection ) example: an intuitive example is the constraint that no two employees may work in the same office. this can be expressed through the following pattern instance. context employee inv: injectiverelation ( office ) 4.2.10 surjective relation the surjectiverelation pattern can be used to establish the mathematical concept of a surjective relation r : x ×y , i.e., (∀y ∈ y ).(∃x ∈ x ).r(x, y). surjectiverelation (navigation:sequence(property)) = self ..allinstances()−>forall ( y | self . allinstances()−>exists( x | x.−>includes(y))) again, the property navigation needs to evaluate to a collection. a) self ..ocliskindof(collection ) having defined patterns for injective and surjective relations, we can deduce a pattern for bijective relations, i.e., one-to-one relations. bijectiverelation (navigation:sequence(property)) = injectiverelation (navigation) and surjectiverelation(navigation) surjectivity and bijectivity can also be expressed using multiplicities in the class diagram. however, these patterns become important if an association is restricted under certain assumptions only (cf. subsection 4.1) and not globally for all instances of a model. 4.2.11 finite instance set the finiteinstanceset pattern can be used to disallow an infinitely large number of instances of a class. this is usually guaranteed because of memory bounds in real systems, but can lead to problems when reasoning about models. finiteinstanceset() = not self . allinstances()−>size().oclisundefined() example: in our company model, we model only real–world entities such as offices or employees. therefore, each class should be required to have a finite number of instances only. context employee, office inv: finiteinstanceset() 4.3 composite constraint patterns apart from atomic constraint patterns, each of which restricts a basic property of a model, composite constraints can be used to express complex properties by integrating an arbitrary number of other constraints (either atomic or composite). using such a divide-and-conquer approach, complex constraints can be developed in a structured way by combining several simple constraints. 11 / 20 volume 5 (2006) model-driven constraint engineering compositeconstraint properties : constraint [*] exists objects : oclexpression forall objects : oclexpression ifthenelse then : constraint [1..*] else : constraint [*] figure 4: class diagram of composite constraint patterns so far, we have identified three composite constraint patterns, exists, forall and ifthenelse, which we illustrate in figure 4. constraint 1 from section 2 contains an example instance of the exists pattern: for the context element m of class manager, there has to exist an element e that is related to m with the navigation employs. this element e must satisfy a set of constraints, the properties of the composite constraint. in the following, we provide a template for the exists pattern. this pattern cannot be expressed in ocl because it quantifies over a set of predicates, which is a concept of higher-order logic. therefore, we use the operator ∧ to define the pattern in pseudo-ocl. when an instance of a pattern is transformed to an ocl expression, this operator is unfolded to a sequence of conjunctions. exists(properties : set(constraint ), objects:oclexpression) = objects−>exists( o | ∧ p∈properties p(o)) the forall constraint pattern is defined analogously. the ifthenelse pattern denotes an ifthen-else expression. if the context element of the constraint satisfies all properties, it also needs to satisfy all then constraints, otherwise, it needs to satisfy all else constraints. ifthenelse(properties, then, else:set(constraint)) = if ( ∧ p∈properties p(self)) then ( ∧ p∈then p(self)) else ( ∧ p∈else p(self)) endif 5 transforming cim to pim having defined a library of cim constraint patterns, we need to provide model transformations to generate pim or psm constraints from the parameterized patterns. as mentioned before, multiple transformations for different target languages can be defined. in this section, we illustrate a transformation that generates ocl constraints from parameterized cim constraint patterns. this transformation, transform_ocl(c), uses ocl templates to generate output for a pattern c. we use pseudo code that has the same expressiveness as common programming languages for the definition of the operations. three steps are necessary to transform an atomic constraint pattern. first, the code for the assumptions is generated if there are any. then, the ocl keyword not is inserted into the constraint expression if the pattern attribute negated is true. finally, the variables in the templates for the constraint patterns are replaced by concrete values from the pattern specification proc. oclapps 2006 12 / 20 eceasst by replace_parameters(t), which is a simple string replacement and thus not further specified in this paper. listing 1 shows the complete transformation from cim to pim for an atomic pattern. 1 sub transform_ocl ( c : a t o m i c c o n s t r a i n t ) { 2 # p r i n t t h e assumptions o f t h e c o n s t r a i n t 3 transform_assumptions_ocl ( c ) ; 4 5 # p r i n t t h e ocl keyword ‘ not ’ i f t h e c o n s t r a i n t i s negated 6 i f ( c . negated ) p r i n t " n o t " ; 7 8 # r e p l a c e t h e v a r i a b l e s i n t h e t e m p l a t e and p r i n t c o n s t r a i n t 9 p r i n t r e p l a c e _ p a r a m e t e r s ( t e m p l a t e ( c ) ) ; 10 } listing 1: ocl transformation function for atomic patterns two operations are invoked from within transform_ocl(c). whereas replace_parameters(t) performs simple string replacement, transform_assumptions_ocl(c) is slightly more complicated. in this operation, the set of assumptions is transformed into a conjunction of predicates, followed by the ocl operator implies. listing 2 shows the definition of this operation. 1 sub transform_assumptions_ocl ( c : s t r u c t u r e d c o n s t r a i n t ) { 2 # p r i n t t h e c o n j u n c t i o n o f assumptions 3 foreach p i n c . assumption 4 p r i n t transform_ocl ( p ) ; 5 i f ( c . assumption . hasnext ( ) ) p r i n t " and " ; 6 7 # p r i n t t h e i m p l i c a t i o n o p e r a t o r i f n e c e s s a r y 8 i f ( c . assumption . notempty ( ) ) p r i n t " i m p l i e s " ; 9 } listing 2: transformation function for assumptions our composite constraints use other constraints as properties for the elements in their object collections. this higher-order use of constraints renders the code generation slightly more complicated than for atomic constraints. in particular, the operator ∧ , representing a conjunction of predicates in a set, needs to be transformed. 1 sub transform_ocl ( c : c o m p o s i t e c o n s t r a i n t ) { 2 transform_assumptions_ocl ( c ) ; 3 i f ( c . negated ) p r i n t " n o t " ; 4 5 # copy t h e t e m p l a t e i n t o a v a r i a b l e ‘ body ’ 6 body : = t e m p l a t e ( c ) ; 7 8 # g e n e r a t e e x p r e s s i o n s f o r t h e p r o p e r t i e s and add them t o c o n j u n c t s 9 foreach p i n c . p r o p e r t i e s { 10 c o n j u n c t s . add ( transform_ocl ( p ) . r e p l a c e ( " s e l f " , " e " ) ) ; 11 } 12 13 # r e p l a c e " ∧ " by t h e g e n e r a t e d c o n j u n c t s 14 foreach p i n c o n j u n c t s { 15 i f ( c o n j u n c t s . hasnext ( ) ) 16 body . r e p l a c e ( " ∧ " , p+ " and " + " ∧ " ) ; 17 e l s e 18 body . r e p l a c e ( " ∧ " , p ) ; 19 } listing 3: transformation function for composite constraints 13 / 20 volume 5 (2006) model-driven constraint engineering the transformation of a composite constraint pattern c is shown in listing 3 and works as follows. lines 2 and 3 generate the assumptions and the negation flag as usual. in line 6, the template text is copied into a variable body. in lines 9–11, the properties associated with the composite constraint are recursively generated and stored in a vector conjuncts. in lines 14–19, the operator ∧ is replaced by an explicit conjunction. if c is an instance of the ifthenelse pattern, its then and else parts need to be transformed as well. this transformation is analogous to the transformation shown in lines 9–19 of listing 3. 6 tool support for model-driven constraint engineering tool support is essential for the acceptance and success of model-driven engineering approaches. in this section, we discuss how to integrate our idea of structured constraint patterns in a modeldriven development tool and apply the tool to the example from section 2. 6.1 technical solution as depicted in figure 2, our concept of a structured constraint is a specialization of the uml meta-class constraint. there are mainly two commonly accepted approaches for creating variations of the uml meta-model, namely, extending the meta-model itself or adapting the metamodel with a uml profile [coo00]. we suggest an implementation of our approach as a uml profile because we consider it a light-weight approach that simplifies the interoperability between tools. in our profile, each constraint pattern is represented by a uml stereotype. the taxonomy of constraint patterns is established using generalization associations between the stereotypes. the attributes of the constraint patterns become attributes of the stereotypes in the implementation. in this solution, one limitation of uml 2.0 becomes critical. in uml 2.0, stereotypes may not have associations with meta-classes [obj05]. thus, a uniqueattributevalue constraint cannot refer to the uml meta-class property. even worse, a composite constraint cannot refer to other constraints as we introduced it in subsection 4.3. however, this deficiency has been remedied in the uml 2.1 standard [obj06], in which associations between a stereotype and a meta-class can be defined. the eclipse uml2 project [ecl] provides an implementation of the uml 2.1 meta-model based on the eclipse modeling framework [emf]. this makes eclipse/uml2 an ideal platform for implementing tool support for structured constraint patterns. in figure 6(a) we show a screenshot of the uml profile editor in eclipse. as can be seen, the taxonomy of structured constraint patterns can be implemented in a straightforward manner as a uml 2.1 profile. we prototyped a graphical user interface that guides a user during constraint creation and maintenance. in figure 6(b) we show a screenshot of our “wizard” that we integrated into the graphical modeling tool ibm rational software architect (rsa), based on the uml profile defined in eclipse/uml2. in the upper left part of the window, the user can choose a constraint pattern. when a pattern is selected, a description of the pattern and its parameters are shown in the upper right part of the window. in the lower half of the window, the attributes of the pattern selected are shown proc. oclapps 2006 14 / 20 eceasst (a) profile editor (b) constraint wizard figure 5: screen shots of eclipse prototype and attribute values can be entered. in its current state, the wizard implements one cim-to-pim transformation that generates ocl expressions and one cim-to-psm transformation that creates java code for run-time model validation. furthermore, the wizard can also be used to modify previously created structured constraints by invoking it from the context menu of a structured constraint. the user can then adapt the parameter values and regenerate the constraint in question. 6.2 applying the tool to the example we have argued in this paper that our approach helps to decrease development time and to reduce the rate of syntactic errors. to indicate the practicability of our approach, we revisit the example from section 2 and apply our method to it. in particular, we use the constraint wizard prototype to implement constraint 1 by choosing appropriate patterns specifying their parameters. constraint 1 is split into three parts, a quantification part, a predicate part and an assumption. this enables a divide-and-conquer approach for formalizing this constraint because each part can be defined separately. the parts can then be linked to form a complex constraint. when implementing constraint 1 using our approach, the class manager is constrained by an instance of the exists pattern. this instance has two parameters: the set of all employees ( self . employs) and the quantification predicate, namely, the ocl constraint self . salary >= 3000, which is the only predicate in the properties of the exists pattern instance. furthermore, this constraint has an assumption that is an attributevaluerestriction on the budget of the manager. figure 6 shows a visualization of constraint 1 in rsa. we have already shown in subsection 4.2 how constraint 2 and constraint 3 can be repre15 / 20 volume 5 (2006) model-driven constraint engineering manager budget : integer must have an employee with special properties. «exists» {objects = self.employs} budget is greater than 100k. «attributevaluerestriction» {targetattribute=budget, operator = '>', term =100000} assumption salary must be at least 3k. {self.salary >= 3000} properties figure 6: structured model of constraint 1 sented using the cyclicdependency and the pathdepthrestriction pattern respectively. these two complicated constraints can thus be specified by simply providing a few parameter values each. if requirements change, these constraints can be quickly adapted without reading, adapting, and testing verbose expressions. we believe that this small example already shows the practicability of our approach. complicated recursive expressions are replaced by structured, concise, and easy-to-read constraint definitions. in addition, our model-driven approach enables the automatic generation of platformindependent or platform-specific constraints in various languages or modeling frameworks. 7 related work the difficulty of developing concise and correct ocl constraints has been addressed in numerous publications. ocl is considered to be a very important formalism in today’s modeling technologies, yet it is difficult to write correct, clear, and efficient ocl expressions [cbc05]. this paper supports the need of using textual constraints in model-driven development, and points out that tool support is critical for the success of ocl. in [ccbc04], a list of recommendations is presented to improve correctness, clarity and efficiency of ocl expressions, two of which we consider especially important. firstly, the authors advise to couple an ocl constraint with an informal specification for clarity. our approach of model-driven constraint engineering, in which a concrete constraint is derived from a cim constraint pattern, follows this idea. secondly, it is advised to test constraints for syntactic errors. our approach avoids syntactic errors by having predefined, syntactically correct templates and a set of meta-constraints for each pattern. the concrete syntax of ocl has been made responsible for its low acceptance so far. thus, several publications try to improve the syntax. for instance, a visual concrete syntax for ocl is proposed in [bkpt00], and a mathematical syntax is presented in [süß06] and [bw06]. the structured constraint patterns we have presented can be regarded as another concrete constraint syntax. however, we elevate the syntax to a more abstract level, which we believe improves conciseness and correctness. wrong intuitions about the formal semantics of uml/ocl seem to be a common problem for users unfamiliar with formal specifications [cab06]. we believe that our approach can help to replace wrong intuitions by precisely defined constraint expressions. proc. oclapps 2006 16 / 20 eceasst several publications use the idea of constraint patterns, thus following the general idea of capturing domain knowledge and making it reusable, as for example introduced in [ghjv95] for object orientation. patterns for constraints in model-driven development were first mentioned in [bhss00], where one pattern—singleton—is introduced. the idea of constraint patterns is further elaborated in [at06, abb+05], where a small number of constraint patterns is introduced along with ocl templates. two publications present a larger library of constraint patterns [mn05, cgq+06]. the patterns presented there originate from the data–modeling domain, and partly overlap with the patterns introduced in this paper, even though they are named differently. some patterns defined in this paper cannot be found in these two papers and vice versa. our contribution adds to these approaches in two ways. firstly, our approach offers composite patterns and, moreover, allows a user to negate patterns and to combine existing patterns using implication. thus, the user has a higher flexibility in using the patterns. secondly, our approach is supported by a tool that integrates into existing case tools. 8 conclusion and future work in this paper, we have introduced the notion of model-driven constraint engineering. our approach provides three main contributions for the efficient development and maintenance of concise uml/ocl specifications. firstly, we have introduced the notion of computation-independent patterns and transformations to concrete constraint expressions. this allows constraints to be represented in an abstract way, generating platform-independent expressions for precise documentation and platformspecific code for model validation. secondly, we have introduced an extensible library of patterns. our patterns originate from a case study in which we formalized about 80 constraints, and first discussions with modeling experts confirmed the relevance of our patterns. we have added a high degree of expressiveness to a pattern-based approach by adding logical structure and by classifying patterns into atomic and composite patterns. thirdly, we have provided tool support for integrating the concepts of model-driven constraint engineering into a case tool. we have presented a wizard that integrates into ibm rational software architect and supports a user in choosing and parameterizing a constraint pattern. furthermore, the wizard contains transformations to platform-independent and platform-specific code. we argue that our approach helps to decrease both the time and the error rate for constraint development. for instance, the ocl expression needed for constraint 3 in section 2 uses a recursive definition that is not easy to understand. in contrast to the lengthy and complicated ocl statement, the same constraint can be defined as an instance of the pathdepthrestriction pattern. tool support as presented in section 6 by an initial prototype further reduces the problem of defining a constraint by pointing-and-clicking to relevant model elements. we would like to emphasize that although we have introduced a wizard, we cannot spirit away the complexity inherent in many constraints. however, we believe that our approach offers a powerful tool for dealing with this inherent complexity. future work includes the definition of new atomic and composite constraint patterns. we believe that more interesting constraint patterns can be identified in other application domains, such 17 / 20 volume 5 (2006) model-driven constraint engineering as model transformations [hksw05], ontology modeling [cp99] or model refactorings [gr02]. furthermore, existing and future constraint patterns need to be validated with respect to their relevance in as many case studies as possible. we are currently working on formalizing the constraint patterns in hol-ocl [bw06], an interactive proof environment for uml/ocl. having support for interactive reasoning has two advantages. firstly, we can formally carry out proofs about the constraint patterns, e. g., redundancy between patterns or parameter values that result in unsatisfiable pattern instances. secondly, these proofs help to increase the level of automation for consistency proofs of a uml/ocl specification, provided that constraint patterns are used in the specification. acknowledgements: we thank david basin, jochen küster, alexander pretschner, and ksenia ryndina for their valuable feedback on earlier versions of this paper. bibliography [abb+05] w. ahrendt, t. baar, b. beckert, r. bubel, m. giese, r. hähnle, w. menzel, w. mostowski, a. roth, s. schlager, p. h. schmitt. the key tool. software and system modeling 4(1):32–54, 2005. [árf03] j. a. t. álvarez, v. requena, j. l. fernández. emerging ocl tools. software and system modeling 2(4):248–261, 2003. [at06] j. ackermann, k. turowski. a library of ocl specification patterns to simplify behavioral specification of software components. in proceedings of conference on advanced information systems engineering. lncs 4001, pp. 255–269. 2006. [baa03] t. baar. the definition of transitive closure with ocl – limitations and applications. in proceedings, fifth andrei ershov international conference, perspectives of system informatics, novosibirsk, russia. lncs 2890, pp. 358–365. springer, july 2003. [bdw06] a. d. brucker, j. doser, b. wolff. a model transformation semantics and analysis methodology for secureuml. in nierstrasz et al. (eds.), models 2006: model driven engineering languages and systems. lncs, pp. 306–320. springer-verlag, 2006. [bhss00] t. baar, r. hähnle, t. sattler, p. h. schmitt. entwurfgesteuerte erzeugung von oclconstraints. softwaretechnik-trends 20(3), 2000. [bkpt00] p. bottoni, m. koch, f. parisi-presicce, g. taentzer. consistency checking and visualization of ocl constraints. pp. 294–308 in [eks00]. [bw06] a. d. brucker, b. wolff. the hol-ocl book. technical report 525, eth zürich, switzerland, 2006. proc. oclapps 2006 18 / 20 eceasst [cab06] j. cabot. ambiguity issues in ocl postconditions. in proceedings of the 6th ocl workshop at the uml/models conference 2006. pp. 194–204. 2006. [cbc05] d. chiorean, m. bortes, d. corutiu. proposals for a widespread use of ocl. in baar (ed.), proceedings of the models’05 conference workshop on tool support for ocl and related formalisms needs and trends, montego bay, jamaica, october 4, 2005. technical report lgl-report-2005-001, pp. 68–82. epfl, lausanne, switzerland, 2005. [ccbc04] d. chiorean, d. corutiu, m. bortes, i. chiorean. good practices for creating correct, clear and efficient ocl specifications. in proceedings of nwuml’2004 – 2nd nordic workshop on the unified modeling language. pp. 127–142. 2004. [cgq+06] d. costal, c. gómez, a. queralt, r. raventós, e. teniente. facilitating the definition of general constraints in uml. in nierstrasz et al. (eds.), models 2006. lncs 4199, pp. 260–274. springer-verlag, 2006. [clw+06] s.-k. chen, h. lei, m. wahler, h. chang, k. bhaskaran, j. frank. a model driven xml transformation framework for business performance management model creation. in international journal of electronic business. volume 4(3/4), pp. 281– 301. inderscience, 2006. [coo00] s. cook. the uml family: profiles, prefaces and packages. pp. 255–264 in [eks00]. [cp99] s. cranefield, m. purvis. uml as an ontology modelling language. in proceedings of the workshop on intelligent information integration, 16th international joint conference on artificial intelligence. 1999. [cw04] a. l. correa, c. m. l. werner. applying refactoring techniques to uml/ocl models. in baar et al. (eds.), uml. lncs 3273, pp. 173–187. springer, 2004. [ecl] the eclipse uml2 project. http://www.eclipse.org/uml2/. [eks00] a. evans, s. kent, b. selic (eds.). uml 2000. lncs 1939. springer, 2000. [emf] the eclipse modeling framework. http://www.eclipse.org/emf. [ghjv95] e. gamma, r. helm, r. johnson, j. vlissides. design patterns: elements of reusable object-oriented software. addison-wesley, boston, ma, usa, 1995. [gr02] m. gogolla, m. richters. expressing uml class diagrams properties with ocl. in object modeling with the ocl, the rationale behind the object constraint language. pp. 85–114. springer-verlag, london, uk, 2002. [hk04] r. hauser, j. koehler. compiling process graphs into executable code. in third international conference on generative programming and component engineering. lncs 3286, pp. 317–336. springer, 2004. 19 / 20 volume 5 (2006) http://www.eclipse.org/uml2/ http://www.eclipse.org/emf model-driven constraint engineering [hksw05] r. hauser, j. koehler, s. sendall, m. wahler. declarative techniques for modeldriven business process integration. ibm systems journal 44(1):47–65, 2005. [kwb03] a. kleppe, j. warmer, w. bast. mda explained. the model driven architecture: practice and promise. addison-wesley, 2003. [lbd02] t. lodderstedt, d. a. basin, j. doser. secureuml: a uml-based modeling language for model-driven security. in jézéquel et al. (eds.), uml 2002. lncs 2460, pp. 426–441. springer, 2002. [mb05] s. markovic, t. baar. refactoring ocl annotated uml class diagrams. in models 2005. lncs 3713, pp. 280–294. 2005. [mn05] e. miliauskaitė, l. nemuraitė. representation of integrity constraints in conceptual models. information technology and control 34(4):355–365, 2005. [obj02] object management group (omg). meta object facility (mof) specification version 1.4. april 2002. available as omg document formal/2002-04-03. [obj03] object management group (omg). uml 2.0 ocl final adopted specification. 2003. available as omg document ptc/03-10-14. [obj05] object management group (omg). unified modeling language: superstructure. version 2.0. july 2005. available as omg document formal/05-07-04. [obj06] object management group (omg). unified modeling language: superstructure. version 2.1. april 2006. available as omg document ptc/2006-04-02. [rc81] r. reiter, g. criscuolo. on interacting defaults. proceedings of the seventh international joint conference on artificial intelligence (ijcai’81), pp. 94–100, 1981. [süß06] j. g. süß. sugar for ocl. in proceedings of the 6th ocl workshop at the uml/models conference 2006. pp. 240–251. 2006. proc. oclapps 2006 20 / 20 http://www.omg.org/cgi-bin/doc?formal/2002-04-03 http://www.omg.org/cgi-bin/doc?ptc/03-10-14 http://www.omg.org/cgi-bin/doc?formal/05-07-04 http://www.omg.org/cgi-bin/doc?ptc/2006-04-02 introduction example model and constraints deriving constraint patterns a taxonomy of structured constraint patterns adding logical structure to constraint patterns atomic constraint patterns attribute value restriction. multiplicity restriction. object in collection unique attribute value association type restriction cyclic dependency path depth restriction unique path injective relation surjective relation finite instance set composite constraint patterns transforming cim to pim tool support for model-driven constraint engineering technical solution applying the tool to the example related work conclusion and future work a pattern-based layout algorithm for diagram editors electronic communications of the easst volume 7 (2007) proceedings of the workshop on the layout of (software) engineering diagrams (led 2007) a pattern-based layout algorithm for diagram editors sonja maier and mark minas 16 pages guest editors: andrew fish, alexander knapp, harald störrle managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst a pattern-based layout algorithm for diagram editors sonja maier 1 and mark minas 2 1 sonja.maier@unibw.de 2 mark.minas@unibw.de institut für softwaretechnologie universität der bundeswehr münchen, germany abstract: the diagram editor generator framework diameta utilizes meta-modelbased language specifications and supports free-hand as well as structured editing. we presented a generic layout algorithm that meets the demands of this kind of editors. the algorithm combines two concepts, constraint satisfaction and attribute evaluation, to a powerful methodology for specifying the layout for a particular visual language. as the layout specification for this algorithm is rather complex, we encapsulated basic functionality into reusable patterns. this paper describes this pattern concept of the generic layout algorithm, and shows how they simplify the layout specification of a specific language. keywords: pattern, constraint satisfaction, attribute evaluation, visual language, free-hand editing, structured editing 1 introduction several approaches and tools have been proposed to specify visual languages and to generate editors from such specifications. these attempts can be characterized by the way the diagram language is specified and by the way the user interacts with the editor and creates respectively edits diagrams. most visual languages have a meta-model as (abstract) syntax specification. a model is essentially a class diagram of the data structure that is visualized by a diagram. when considering user interaction and the way how the user can create and edit diagrams, structured editing is usually distinguished from free-hand editing. structured editors offer the user some operations that transform correct diagrams into (other) correct diagrams. free-hand editors, on the other hand, allow to arrange diagram components from a language-specific set on the screen without any restrictions. the editor has to check whether the drawing is correct and what its meaning is. in both cases, a layouter may be used to beautify the diagram. in free-hand mode, the editor user has more freedom, which implies that the layouter is more complex. in [mm07] we designed a generic layout algorithm that works for model-based visual languages. it meets the demands of structured as well as free-hand editing. our algorithm was designed for the framework diameta, that follows the model-driven approach to specify diagram languages. from such a specification an editor, offering structured as well as free-hand editing, can be generated. in fig. 1 we can see an editor that was generated with diameta. for structured editors, layout algorithms were studied in the past [cmp99]. for free-hand editors, these layout algorithms cannot be applied in a straightforward way the layouter has to deal with the increase of flexibility and should restrict the user only in a moderate way. in 1 / 16 volume 7 (2007) mailto:sonja.maier@unibw.de mailto:mark.minas@unibw.de pattern-based layout the world of grammar-based editors, some layout algorithms have been established in the past [min04]. our layout algorithm operates on a meta model instead. it allows for defining a layout that is specialized for a certain model, i.e. a certain visual language. one frequently used concept is attribute evaluation. an attribute evaluator is fast and best suited if the layout is unambiguous. this concept cannot deal with the situation that the same diagram may be represented in different ways. especially in free-hand mode, a conventional attribute evaluator is not sufficient. another concept that is frequently used for layout [min04, cmp99] is constraint satisfaction. the disadvantages of this concept are that constraint satisfaction is slow in some cases and its behavior is unpredictable in some situations. figure 1: petri net editor in [mm07] we presented an algorithm that combines the two concepts, constraint satisfaction and attribute evaluation, to a powerful algorithm that is fast, flexible and behaves exactly the way we desire: declarative constraints ensure the characteristics of the layout. if they are not fulfilled, a set of certain attribute evaluation rules is switched on. these rules are evaluated, and the associated attributes are updated. we realized that writing such a specification is rather complicated and complex. therefore we encapsulated basic functionality as packages, as it is done in [sk03, sch06], and give the user the opportunity to use (and reuse) these packages. they contain a set of constraints and corresponding attribute evaluation rules that are tailored to a specific problem, e.g. to the problem of arranging arrows in a graph-based visual language. these packages are called patterns in the following, the terminology used in [sk03, sch06]. these patterns introduce another level proc. led 2007 2 / 16 eceasst of abstraction on top of the specification, as design patterns [ghjv95] do for object-oriented software design. in order to use such a predefined pattern, the model must contain some special components, e.g. for the graphpattern, the model must contain a class representing edges and a class representing nodes. for most visual languages, standard layout algorithms may be specified, using predefined patterns. using them simplifies the layout specification. if the predefined patterns are not sufficient, e.g. for unusual visual languages or a fancy layout, the patterns may be adjusted to the special needs or new patterns may be created. and of course it is also possible to use the algorithm in the traditional way and benefit from the complete functionality the generic layout algorithm offers. in sect. 2 we introduce the model of petri nets, the visual language that is used as a running example. in sect. 3 we explain the generic layout algorithm that we have proposed for meta model based editors. in sect. 4 we introduce the pattern concept for the generic layout algorithm. in sect. 5 we show how to use this concept to create the layout for petri net editors. sect. 6 summarizes some implementation details and gives an overview of diameta, the environment in which the pattern concept was tested. sect. 7 concludes the paper. 2 running example in this section we introduce an editor for petri nets as running example. first we describe the underlying meta model of the petri net language. then we explain how the diagram is visualized. finally we give a short overview of the layout that we are going to define throughout the paper. each diagram consists of a finite set of visual components. in petri nets, these are places, transitions, tokens, and arrows between places and transitions. each component is determined by its attributes. figure 2: meta model of petri nets 3 / 16 volume 7 (2007) pattern-based layout fig. 2 shows the meta model for petri nets. it contains the class node as an abstract base class of a petri net’s place or transition. the classes place and transition have a member attribute label. edge is the abstract base class of a connection between places and transitions. concrete classes of the abstract model are place, transition, ptarrow, tparrow, and token respectively. transition-place relations are represented by the associations between transition, tparrow and place, place-transition relations by the associations between place, ptarrow and token. placetoken relations are represented by the association between the classes place and transition. in the meta model, the abstract syntax is described. besides that, some aspects of the concrete syntax are included. this additional information is needed to perform layout computations. the classes cplace, ctransition, carrow and ctoken represent aspects of the concrete syntax. a place is visualized by a circle whose center position is determined by its attributes (xpos, ypos) and its radius by the attribute radius. a transition is visualized by a square whose center position is defined by the coordinate point (xpos, ypos) and its size by the attributes width and height. a token is visualized by a circle whose center position is again defined by (xpos, ypos). its radius is a fixed value that cannot be modified by the user. ptarrow and tparrow are visualized by arrows whose position is defined by its two end points, i.e. by two coordinate pairs (xstart, ystart) and (xend, yend).1 in fig. 1 we can see a sample petri net, visualized as described above, and layouted (incrementally) as described in the following. we are going to specify a layout for the petri net editor that is based on the model presented above. during user interaction, we want to support the user with some special behavior. after user interaction, we want to get a beautified diagram as result. • after user interaction: arrows start and end exactly at the border of a component, i.e. exactly at the border of a transition or place. arrows must have a minimal length, i.e. the components must have a minimal distance. tokens are completely inside a place. they may not intersect the border line of the place. if possible, tokens are arranged as a list, as long as the list fits into the place.2 • during user interaction: when we move a place (or change the size of a place), arrows and tokens have to follow the place. when we move a transition (or change the size of a transition), arrows also have to follow the transition. this gives the user an easy and intuitive way of changing the visual appearance of the petri net. he may for example rearrange tokens and places without changing the semantics of the diagram. when we move an arrow or token, nothing else is changed. with this functionality, the user may change the dynamic behavior of the petri net. he may for example move a token from one place to another. in our specification we make use of three patterns. the graphpattern being responsible for layouting the arrows, the listpattern that is responsible for arranging the tokens inside a place and the containmentpattern that ensures that tokens are completely inside the place. to demonstrate the possibilities offered by the concept, we will adjust a pattern and we will add some additional functionality that is not supported by the patterns. 1 they can be substituted by a list of bends. the editor that was created via diameta actually supports bends. 2 this is not the most intuitive layout. this behavior was introduced for explanatory reasons, as we will see later. proc. led 2007 4 / 16 eceasst 3 generic layout algorithm in fig. 3 we can see a birds-eye view of the layout algorithm that has been presented in [mm07]. the algorithm is based on the idea that we have a set of declarative constraints (and a set of all attributes), that assure the characteristics of the layout. if all constraints are satisfied, the layouter terminates. if one or more constraints are not satisfied, the layouter needs to change some attributes to satisfy the constraints. therefore it switches on one or more attribute evaluation rules. these rules in turn are responsible for updating the attributes, i.e. to satisfy the constraints. in this section we describe this layout algorithm in more detail. first we describe the input parameters of the layouter. then we summarize what components the layout specification consists of. as a last step we describe the layout algorithm itself. in the next section we will introduce the pattern concept for this layout algorithm. 3.1 input the algorithm gets as input one or two sets of attribute values the old values (values before user interaction), the user-desired values (values after user interaction) or both. furthermore, the layouter is aware of the current state. it knows whether the user is in the process of modifying a component, e.g. is currently moving a place, or has finished a modification already. it also knows, which component(s) the user has changed. in addition, the layouter has access to the model of the visual language. we have to distinguish three types of user interaction: adding, modifying and removing. the selection of old values and user-desired values depends on the type of user interaction. when the user adds a component at a desired position, the layouter gets one set of values as input the user-desired values. when the user modifies a component, e.g. moves a place from the position characterized by xposold and yposold to a new position xposuser and yposuser, the layouter has two sets of values as input the old values and the user-desired values. in case of deletion, the layouter gets only the old values as input. 10 diagram [updated] diagram [modified] layout algorithm calculate new values switch on rules check constraints update diagram [otherwise] [all satisfied] check semantics [otherwise] [semantics maintained] undo changes user interaction update attribute values figure 3: birds-eye view of the generic layout algorithm 5 / 16 volume 7 (2007) pattern-based layout after user interaction during user interaction before user interaction figure 4: moving a place we distinguish between two states, during modification and after modification that we treat in different ways. during modification only the layouter is called, after modification first the model is updated and then the layouter is called, using the updated model. during modification, some layouting constraints should be satisfied immediately. the satisfaction of other constraints may be postponed to the end of the user interaction. suppose we change the position of a place, as we can see in fig 4. while we move the component (during modification), we want arrows to follow the place. as the layouter is responsible for updating the attributes, he needs to be called several times during modification of the diagram via user input in order to update the arrows. after we finished moving the place, for example, we want to satisfy the constraint that arrows have a minimal length. if an arrow does not satisfy this constraint, it is extended automatically. minimizing the number of computations during user interaction not only speeds up the computation of the new visualization, it also gives the user more freedom. another aspect we take care of is the information, what component, i.e. what attributes, the user changed. in our example we distinguish between moving arrows and moving places or transitions. when we move an arrow, we just want the arrow to be moved. the places and transitions remain unchanged. if we move a place or transition, we want the arrows to remain connected to these components, and hence the arrows are changed. 3.2 layout specification the layouter uses the attributes, the state and the model of the visual language to calculate new values that represent the updated diagram. to do that, it needs a layout specification, as introduced in [mm07]. this specification consists of a set of constraints, each of them associated with a concrete class like place or ptarrow. for every constraint there exists a list of attribute evaluation rules. if a constraint is violated, it is its evaluation rules’ task to update attributes such that the constraint is satisfied (again). the constraints and attribute evaluation rules use the standard ocl syntax, as specified in [omg06]. only current values are changed during execution of the layout algorithm. all other attributes remain unchanged. intermediate results are created each layout iteration. constraints are responsible for switching on and off attribute evaluation rules. attribute evaluation rules are responsible for calculating the set of new values. for example, constraint (1) switches on rule (2) if xpos ≤ in.xpos. if this is not the case, xpos remains unchanged. [after modification]xpos > in.xpos (1) xpos ← in.xpos + 5 (2) proc. led 2007 6 / 16 eceasst we may restrict constraints and attribute evaluation rules to be checked and executed only if we are in a special state (indicated by [state] in front of the constraint or rule). for example, if we add [after modification] in front of the constraint, this constraint is checked after modification. otherwise, this constraint is checked each time the layouter is called. we may also add [o1 changed] in front of the constraint. this means that the constraint is only executed if one of the attributes of the object o1 has changed.3 3.3 layout algorithm in fig. 3 we can see a birds-eye view of the generic layout algorithm. the layouter is called each time the diagram was changed via user interaction. the set of current values consists of user-desired values for the attributes changed via user interaction, and old values for attributes the user did not change. all potentially violated layout constraints (that need to be checked for the current state) are checked, and the rules that were switched on are collected. thereafter the new values of the attributes are calculated via attribute evaluation. the current values are substituted by the new values and the constraints are checked again, since new constraints may have become unsatisfied due to changes performed by the layouter. if all constraints are satisfied, the layouter succeeds and reports all new values. otherwise, the layouter has to evaluate the rules again. if the layouter does not succeed after a certain number of iterations (may be user defined), the layouter stops and returns the user values as result. 4 pattern concept for the layout algorithm creating an editor with diameta is tool supported. the only part the editor developer had to write by hand had been the layouter. with the layout algorithm presented above, the editor developer is no longer burdened with this task. he now only has to provide a layout specification. we are aware that writing such a specification is still rather complicated and complex. therefore we encapsulated basic functionality, as it is done in [sk03, sch06], and give the user the opportunity to use these patterns. in fig. 5 we can see some patterns that were already defined. graphpattern, containmentpattern and listpattern will be explained in the next section, as they form the basis of the layout specification for the petri net editor. graph pattern containment pattern list pattern matrix pattern list pattern & cont. pattern figure 5: graphpattern, containmentpattern, listpattern, matrixpattern 3 note that not only the editor user may change an object, but also the layouter may be responsible for changes. 7 / 16 volume 7 (2007) pattern-based layout in order to use these patterns, the user simply has to specify which pattern he wants to apply on what part of the model. for example, for the graphpattern, he has to specify which component plays the role node, and which component the role edge. for our petri net editor, places and transitions will play the role node and arrows will play the role edge. in our meta model, places are represented by the two classes cplace and place and transitions by the two classes ctransition and transition. arrows are represented by the two classes carrow and ptarrow or by the two classes carrow and tparrow, as shown in fig. 6. the editor developer has the opportunity to adjust these patterns to his own needs. he may also combine different patterns, or refine a pattern. of course he may also add additional functionality or create new patterns from scratch. 4.1 pattern requirements a pattern contains a set of constraints and corresponding attribute evaluation rules. these constraints and attribute evaluation rules need some associations and attributes for their calculations. consequently, a pattern may only be used if some requirements are fulfilled. in fig. 6 (in the middle) we see the requirements that need to be met in order to use the graphpattern. there need to be two associations between node and edge with the roles from and to respectively. node must have the attributes xpos, ypos, width and height. edge must have the attributes xstart, ystart, xend and yend. figure 6: requirements for the graphpattern in our example place does not offer the attributes width and height. all other requirements are already met. we could add these attributes, but we do not want to change the meta model. in this case, the editor developer may introduce a mapping between a required component and another available component. we introduce a bidirectional mapping between height and radius and a bidirectional mapping between width and radius:4 height ← 2∗radius width ← 2∗radius radius ← height/2 radius ← width/2 4 both directions are required to implement the methods getwidth(), setwidth(), getheight() and setheight(). proc. led 2007 8 / 16 eceasst 4.2 pattern usage and pattern adjustment if all requirements are met, the pattern may be used (pattern usage). a pattern consists of a set of constraints and attribute evaluation rules. e.g. the graphpattern consists of the following constraints and attribute evaluation rules. the following four constraints (left side) associated with the classes ptarrow and tparrow assure that arrows start and end exactly at the top or bottom of a component, as we can see in fig. 4. (xpos, ypos) is located in the top left corner of a component. the first (last) two constraints are checked if the component, at which the arrow starts (ends) has changed. the associated attribute evaluation rules (right side) update arrows, if they are not at the right position. [from changed] xstart = f rom.xpos + f rom.width2 xstart ← f rom.xpos + f rom.width 2 [from changed] ystart = f rom.ypos + f rom.height ystart ← f rom.ypos + f rom.height [to changed] xend = to.xpos + to.width2 xend ← to.xpos + to.width 2 [to changed] yend = to.ypos yend ← to.ypos to assure that arrows have a minimal length, we introduce a constraint associated with the classes ptarrow and tparrow. this constraint is checked after user interaction has finished: [after modification] (xend −xstart)2 + (yend −ystart)2 > 1000 the associated rules extend an arrow, if it is shorter than the minimal length required. if the component, at which the arrow starts (ends) has changed, the component, at which the arrow ends (starts) is moved. as the arrow stays connected to this component, it is automatically extended to the required length. [from changed] to.xpos ← to.xpost(i−1) + to.xpost(i−1)− f rom.xpos |to.xpost(i−1)− f rom.xpos| [from changed] to.ypos ← to.ypost(i−1) + to.ypost(i−1)− f rom.ypos |to.ypost(i−1)− f rom.ypos| [to changed] f rom.xpos ← f rom.xpost(i−1) + f rom.xpost(i−1)−to.xpos | f rom.xpost(i−1)−to.xpos| [to changed] f rom.ypos ← f rom.ypost(i−1) + f rom.ypost(i−1)−to.ypos | f rom.ypost(i−1)−to.ypos| in each pattern we introduced some constants. these constants have an initial value and may be overridden by the user (pattern adjustment). they are used in the constraints and attribute evaluation rules. e.g. for the graphpattern, the attribute minlength (the 1000 in the constraint) may be overridden. this changes the minimal length of an arrow. this mechanism made pattern more flexible. experiments showed that they were now applicable in more situations. 4.3 pattern combination and pattern refinement it is possible to use more than one pattern for layout specification (pattern combination). in our example, we will combine the two patterns containmentpattern and listpattern. the containmentpattern will be responsible to keep tokens inside a place. the listpattern is responsible for arranging tokens as a list, if the constraints of the containmentpattern still can be satisfied. right now, pattern combination is done by applying the patterns one after another. 9 / 16 volume 7 (2007) pattern-based layout pattern pattern refinement figure 7: pattern refinement in our example, first the listpattern is applied, and then the containmentpattern. this mechanism will be substituted by an enhanced priority concept in future implementations. we may also add additional constraints and attribute evaluation rules to a pattern (pattern refinement). in our example we add a constraint that assures that transitions have a minimal width and height (fig. 7). up to now, all constraints and attribute evaluation rules are collected. no simplification or error check is utilized. the editor creator has to ensure that constraints and attribute evaluation rules are reasonable. 5 pattern-based layout for the petri net editor we now explore a concrete example the layout declaration for the petri net editor. we present the patterns that are used in more detail, and show how they are adjusted, combined and refined to the language specific layout desired. 5.1 containmentpattern the containmentpattern assures that components are completely inside a surrounding component. they may not intersect the border line of the surrounding component. in order to apply the containmentpattern, the model must contain the following components. between container and element, there must be a 1-to-many association. container must have the attributes width, height, xpos and ypos. element must have the same attributes (fig. 8). (a) requirements user input cont. pattern applied (b) application figure 8: containentpattern we apply the containmentpattern to places as container, and tokens as element. in order to use the pattern we need to add the attributes width and height to places and tokens. for places we introduce a bidirectional mapping between height and radius and between width and radius, as described in sect. 4.1. for tokens, these are fixed values: 20 for both, an unidirectional mapping (height ← 20, width ← 20).5 in fig. 8 we see an excerpt of a petri net. on the left side we see the user input, on the right side the result after applying the containmentpattern. 5 note that all tokens are moved inside the square width*height, not into a circle. to change this, we would need to define a specialized pattern. proc. led 2007 10 / 16 eceasst 5.2 listpattern the listpattern is responsible for arranging a set of components as a list. the listpattern requires that the meta model contains a 1-to-many association between list and element. furthermore, the list must have the attributes listposx and listposy. these are the coordinates where the list starts. element must have the attributes width, height, xpos and ypos. we can see the requirements in fig. 9. (a) requirements user input list pattern applied (b) application figure 9: listpattern we apply the listpattern to places as list and tokens as element. in order to use the pattern, user input lp & cp applied figure 10: cont. and listpattern we must add the attributes listposx and listposy to place. for listposx and listposy we define a bidirectional mapping. (listposx ← xpos + width/2, xpos ← listposx − width/2 and listposy ← ypos, ypos ← listposy ). transition already has all attributes required. the listpattern provides several customization options. for example we may choose whether to align elements vertically or horizontally. by default they are aligned vertically, as used for our petri net editor. in fig. 9 we see an excerpt of a petri net. on the left side we see the user input, and on the right side the result after applying the listpattern. in fig. 10 we can see what happens if we apply both the containmentpattern as well as the listpattern. 5.3 graphpattern as the third and last pattern we use the graphpattern, the pattern that was already described in the last section. it demands that arrows start and end at the border of transitions and places. user input graph pattern applied figure 11: graphpattern in addition, arrows must have a minimal length. the graphpattern may be applied if the requirements shown in fig. 6 are met. we apply the graphpattern to places and transitions as node and arrows as edge. the graphpattern also provides several customization options. for example, we may change the minimal length of arrows. this opportunity is used in order to specify our layout. or we may arrange components from leftto-right, instead of top-to-bottom. in fig. 11 we can see the user input on the left side. on the right side we see the result after applying the graphpattern. 11 / 16 volume 7 (2007) pattern-based layout 5.4 complete layout to demonstrate the simplicity and flexibility of the pattern concept, we include all concepts described in sect. 4 in the complete layout. we use the patterns described above (pattern usage and pattern combination). we change the minimal length of arrows required (pattern adjustment) and we require that transitions must have a minimal size (pattern refinement). we override the attribute minlength of the graphpattern to change the minimal length of arrows, and we add an additional constraint and its corresponding attribute evaluation rules to assure the minimal size of transitions. the interesting part of the layout specification is the following: gp = new graphpattern(carrow,cplace,ctransition); lp = new listpattern(cplace,ctoken)); cp = new containmentpattern(cplace,ctoken); gp.adjust("minlength := 100"); constraint constr = new constraint("width > 100",ctransition); constr.addrule("width := width + 10"); gp.refine(constr); 6 implementation in this section, we will give an overview of diameta, the environment in which the algorithm was tested and explain how the algorithm was integrated in the framework. we will then examine the layout algorithm and the pattern concept in terms of usability and performance. 6.1 integration of the layout algorithm in diameta diameta provides an environment for rapidly developing diagram editors based on metamodeling. each diameta editor is based on the same editor architecture which is adjusted to the specific diagram language. 6.1.1 architecture fig 12. shows the structure which is common to all diameta editors [min06a, min06b]. the editor supports free-hand editing by means of the included drawing tool which is part of the editor framework, and can be adjusted by the diameta designer. with this drawing tool, the user is able to create, arrange and modify the diagram components of the particular diagram language. editor specific program code, which has been specified by the editor developer and generated by the diameta designer, is responsible for the visual representation of these language specific components. the drawing tool creates the data structure of the diagram as a set of diagram components together with their attributes (position, size, etc.). the sequence of processing steps necessary for free-hand editing starts with the modeler and ends with the model checker; the modeler first transforms the diagram into an internal model, the graph model. the reducer then creates the diagrams instance graph that is analyzed by the model analyzer. this last processing step identifies the maximal sub diagram which is (syntactically) proc. led 2007 12 / 16 eceasst diagram drawing tool editor user selects operation 5 graph model modeler instance graph reducer model checker java objects selects operation graph transformer (optional) reads reads adds/rem oves modifies reads layouter (optional) highlights syntactically correct sub-diagrams figure 12: architecture of a diagram editor based on diameta correct and provides visual feedback to the user by drawing those diagram components in a certain color; errors are indicated by another color. however, the model analyzer not only checks the diagrams abstract syntax, but also creates the object structure of the diagram’s syntactically correct sub diagram. then the layouter is (optionally) called. it modifies attributes of diagram components and thus the diagram layout is based on the (syntactically correct sub diagrams) object structure that was created in the last processing step. 6.1.2 framework this section completes the description of diameta and outlines its environment supporting specification and code generation of diagram editors that are tailored to specific diagram languages. the diameta environment shown in fig. 13 consists of an editor framework, the diameta designer and the diameta layout generator.6 the framework that is basically a collection of java classes, provides the generic editor functionality, which is necessary for editing and analyzing diagrams. in order to create an editor for a specific diagram language, the editor developer has to provide two specifications: first, the abstract syntax of the diagram language in terms of its model, and second, the visual appearance of diagram components, the concrete syntax of the diagram language, the reducer rules and the interaction specification. besides that, he may provide a layout specification, if he wants to define a specific layout. we may use the pattern concept in this specification. diameta can either use the eclipse modeling framework (emf version) [akrs06, min06a] or moflon (mof version) [bbm03, min06b] for specifying language models and generating their implementations. our algorithm implementation is based on the emf version. but with minor changes, the algorithm and the pattern concept may also work with the mof version instead. a languages class diagram is specified as an emf model that the editor developer creates 6 the layout generator is the implementation of the generic layout algorithm presented in this paper. 13 / 16 volume 7 (2007) pattern-based layout editor developer diagram editor diameta editor framework diameta designerdiameta generated program code emf compiler operates ecore modeller ecore specification operates diameta layout generator generated program code editor specification layout specification figure 13: generating diagram editors with diameta by using the emf modeler. the emf compiler, being part of the emf plugin for eclipse, is used to create java code that represents the model. the emf compiler creates java classes (respectively interfaces) for the specified classes. the editor developer uses the diameta designer for specifying the concrete syntax and the visual appearance of diagram components, e.g. places are drawn as circles, transitions as rectangles, and edges as arrows. the diameta designer generates java code from this specification. in addition, we can provide a layout specification, e.g. we may iapply the graphpattern to arrows, places and transitions. the diameta layout generator generates java code from this specification. this java code, together with the java code generated by the diameta designer, the java code created by the emf compiler and the editor framework, implement an editor for the specified diagram language. 6.2 usability and performance in the last subsection we described how the layout algorithm (and thus the pattern concept) was integrated in diameta. we examine the algorithm in terms of usability and performance, as it is done in [dfab98]. schmidt demonstrated in [sk03, sch06] that a small number of patterns is sufficient to implement a great variety of visual languages. after investigation of several visual languages, we specified via diameta in the past, we came to the same result. for these languages, the editor developer can use the predefined patterns. this simplifies the layout specification. for a visual languages’ layout that needs more flexibility, these patterns may be adjusted or refined. the editor developer may create new ones or use the generic layout algorithm in the traditional way. consequently, the specification of the layout becomes rather complex and complicated, but on the other hand we have the whole functionality available. the language used is ocl, a standard language. this has the advantage that only a short training phase is needed, if ocl is known. the week point of the specification is that you have to write a correct specification with no tool support, e.g. you have no error reporting or error correction. besides that, no constraint or rule simplification is performed.this will be the focus of further research. all in all the generic layout algorithm in combination with the pattern concept is a powerful tool for specifying a layout for proc. led 2007 14 / 16 eceasst a specific visual language. the editor developer himself may decide how much effort he wants to put onto the layout specification. the weak point of most algorithms solely based on constraint satisfaction is performance [cmp99]. in our algorithm we provide the constraints as well as the solution to these constraints (attribute evaluation rules). this has the consequence that layout computation is no longer time consuming. thus performance is (up to now) no issue. e.g. for the presented example, layouting a diagram that contains 200 components (50 places, 50 transitions, 50 tokens and 50 arrows) takes less than 0.5 seconds. for further details, please refer to [mm07]. 7 conclusions and prospects the diagram editor generator framework diameta makes use of meta-model-based language specifications and supports free-hand as well as structured editing. the algorithm described in [mm07] is a modular and generic layout algorithm that meets the demands of this kind of editors. the fundamental concept of the algorithm is constraint satisfaction combined with attribute evaluation in the sense that constraints are used to activate particular attribute evaluation rules. this combination gives the layouter the flexibility it needs to support free-hand as well as structured editing. by means of the example we saw that it is possible to define a layout algorithm for diagrams that supports the user during user interaction (incrementally), and meanwhile grants the user plenty of freedom. furthermore, a layouted diagram is displayed at any time. we realized that writing such a specification is rather complicated. therefore we encapsulated basic functionality, and give the user the opportunity to use (and reuse) these patterns. patterns introduce another level of abstraction on top of the specification, as design patterns do in object oriented software design. a pattern is basically a set of constraints and attribute evaluation rules that is tailored to a specific problem, e.g. to the problem of arranging arrows in a graph-based visual language. patterns may be used if some requirements are satisfied. it may be adjusted to a visual language as required. the editor developer has the opportunity to combine different patterns or refine a pattern. of course he may also add additional functionality or create new patterns from scratch. using the pattern concept made writing a specification easier, without loosing the flexibility of the original, sufficiently efficient generic layout algorithm. up to now creating a specification or defining a pattern has to be done by hand. the next step will be to introduce gui support for creating patterns and also for creating a whole specification. extensive case studies are planned, and may lead to an enhanced pattern concept. the extension will include a priority concept for constraints and will offer a possibility to integrate existing layouter and constraint solver. we will apply the concept to graph-based as well as other visual languages. we will examine the applicability to diagrams of different sizes. we will define different views for the same visual language. till now we focused on an incremental layout, in future case studies we will also examine a complete automatic layout. we will investigate free-hand as well as structured editing. identifying patterns in the model automatically is also imaginable. then the program could suggest patterns applicable, and the only thing the user has to do is selecting the pattern desired. the program could even change the model such that a specific pattern is applicable. this idea will be the focus of further research. 15 / 16 volume 7 (2007) pattern-based layout bibliography [akrs06] c. amelunxen, a. königs, t. rötschke, a. schürr. moflon: a standardcompliant metamodeling framework with graph transformations. in rensink and warmer (eds.), model driven architecture foundations and applications: second european conference. lecture notes in computer science (lncs) 4066, pp. 361– 375. springer verlag, heidelberg, 2006. [bbm03] f. budinsky, s. a. brodsky, e. merks. eclipse modeling framework. pearson education, 2003. [cmp99] s. s. chok, k. marriott, t. paton. constraint-based diagram beautification. in vl ’99: proceedings of the ieee symposium on visual languages. p. 12. ieee computer society, washington, dc, usa, 1999. [dfab98] a. dix, j. finley, g. abowd, r. beale. human-computer interaction (2nd ed.). prentice-hall, inc., upper saddle river, nj, usa, 1998. [ghjv95] e. gamma, r. helm, r. johnson, j. vlissides. design patterns. addison-wesley professional, january 1995. [min04] m. minas. visualdiagen – a tool for visually specifying and generating visual editors. in applications of graph transformation with industrial relevance, proc. 2nd intl. workshop agtive’03, charlottesville, usa, 2003, revised and invited papers. lecture notes in computer science 3062. springer-verlag, 2004. [min06a] m. minas. generating meta-model-based freehand editors. appears in electronic communications of the easst, proc. of 3rd international workshop on graph based tools (grabats’06), natal (brazil), september 21-22, 2006, satellite event of the 3rd international conference on graph transformation, 2006. [min06b] m. minas. generating visual editors based on fujaba/moflon and diameta. in giese and westfechtel (eds.), proc. fujaba days 2006, bayreuth, germany, september 28-30, 2006. pp. 35–42. 2006. technical report tr-ri-06-275 universität paderborn, fakultät für elektrotechnik, informatik und mathematik, institut für informatik. [mm07] s. maier, m. minas. a generic layout algorithm for meta-model based editors. in applications of graph transformation with industrial relevance, proc. 3rd intl. workshop agtive’07, kassel, germany. 2007. [omg06] omg. object constraint language (ocl) specification, version 2.0. 2006. [sch06] c. schmidt. generierung von struktureditioren für anspruchsvolle visuelle sprachen. phd thesis, universität paderborn, d-33098 paderborn, germany, 2006. [sk03] c. schmidt, u. kastens. implementation of visual languages using pattern-based specifications. softw. pract. exper. 33(15):1471–1505, 2003. proc. led 2007 16 / 16 introduction running example generic layout algorithm input layout specification layout algorithm pattern concept for the layout algorithm pattern requirements pattern usage and pattern adjustment pattern combination and pattern refinement pattern-based layout for the petri net editor containmentpattern listpattern graphpattern complete layout implementation integration of the layout algorithm in diameta architecture framework usability and performance conclusions and prospects a survey of triple graph grammar tools electronic communications of the easst volume 57 (2013) proceedings of the second international workshop on bidirectional transformations (bx 2013) a survey of triple graph grammar tools stephan hildebrandt1, leen lambers1, holger giese1 jan rieke2, joel greenyer3, wilhelm schäfer2 marius lauder4, anthony anjorin4 and andy schürr4 17 pages guest editors: perdita stevens, james f. terwilliger managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst a survey of triple graph grammar tools stephan hildebrandt1, leen lambers1, holger giese1 jan rieke2, joel greenyer3, wilhelm schäfer2 marius lauder4, anthony anjorin4 and andy schürr4 1 hasso-plattner-institut 2 universität paderborn, heinz nixdorf institut prof.-dr.-helmert-str. 2-3 zukunftsmeile 1 14482 potsdam, germany 33102 paderborn, germany firstname.surname@hpi.uni-potsdam.de firstname.surname@uni-paderborn.de 3 politecnico di milano 4 technische universität darmstadt dipartimento di elettronica e informazione real-time systems lab via golgi, 42 merckstr. 25 20133 milano, italy 64283 darmstadt, germany surname@elet.polimi.it firstname.surname@es.tu-darmstadt.de abstract: model transformation plays a central role in model-driven engineering (mde) and supporting bidirectionality is a current challenge with important applications. triple graph grammars (tggs) are a formally founded, bidirectional model transformation language shown by numerous case studies to be promising and useful in practice. tggs have been researched for more than 15 years and multiple tgg tools are under active development. although a common theoretical foundation is shared, tgg tools differ considerably concerning expressiveness, applicability, efficiency, and the underlying translation algorithm. there currently exists neither a quantitative nor a qualitative overview and comparison of tgg tools and it is quite difficult to understand the different foci and corresponding strengths and weaknesses. our contribution in this paper is to develop a set of criteria for comparing tgg tools and to provide a concrete quantitative and qualitative comparison of three tgg tools. keywords: bidirectionality, triple graph grammars, mote, tgg interpreter, emoflon 1 motivation triple graph grammars (tggs) [klks10] are a formally founded, rule-based and declarative bidirectional model transformation language, shown by numerous case studies [gnh10, gr12, lsrs10] to be promising and useful in practice. tggs have been researched for more than 15 years and there are currently multiple implementations, all being actively developed. although a common theoretical foundation is shared, these implementations differ in expressiveness (what features are supported), applicability (what limitations are imposed), efficiency (strategies to ensure polynomial runtime), and the underlying translation algorithm (choice and sequence of rule applications). as neither a quantitative nor a qualitative overview and comparison of tgg tools exists, it is quite difficult to understand their different strengths and weaknesses. 1 / 17 volume 57 (2013) a survey of triple graph grammar tools our contribution in this paper is to provide (1) a set of criteria for comparing tgg tools, and (2), based on these criteria, a concrete quantitative and qualitative comparison of three tgg tools with fundamentally different approaches: mote,1 the tgg interpreter,2 and emoflon.3 we also provide (3) a discussion of formal guarantees and restrictions, and (4) virtual machines via share [vm11] with a complete installation of each implementation to complement this paper. our work is a first step towards a benchmark for tgg tools that can be extended to test and evaluate other existing tools or new ones. our results can be used as a guideline for choosing the appropriate tgg tool for a specific task. section 2 compares our contribution to existing surveys, while sect. 3 introduces tgg fundamentals and gives an overview of a schematic tgg control algorithm. our criteria for the comparison are discussed in sect. 4 and used in sects. 5–7 to present each implementation with a qualitative comparison. this comparison is summarized in sect. 8. section 9 complements this with runtime measurements, while areas of future work are discussed briefly in sect. 10. 2 related work the feature-based survey of model transformation approaches by czarnecki and helsen [ch06] regards directionality, incrementality, and the way transformation rules are specified. with a similar goal, mens and van gorp [mv06] propose a taxonomy of model transformations, but focus more on the transformation scenario than on the model transformation approach. their classification includes not only the number of source/target models and different kinds of transformations, but also quality aspects of the language/tool, like usability or performance. another survey by stevens [ste08] focuses on bidirectional transformations and investigates more formal aspects of different approaches. in contrast to these broad surveys, we identify relevant criteria and conduct a quantitative and qualitative comparison of three concrete tgg tools. the model transformations in practice workshop (mtip 2005) [brst06] sought to establish a benchmark for (bidirectional) model transformations with the class diagram to database (cdds) transformation as an example. the solutions submitted, however, often modified the example to fit the respective tool, leading to multiple variants and simplifications that do not allow an objective comparison of the tools. in particular, no quantitative, i.e., performance comparison was provided by the different solutions. other papers [gh09, hego10] do present a performance evaluation, but only of a single tool in each case. in this paper, we formalize the cdds example for tgg tools by providing not only metamodels but also a tgg to test and compare the tgg tools. although the example had to be simplified so that all three tools could be used, we are able to provide, for the first time, a runtime comparison of three tgg tools. we provide virtual machines via share [vm11] with a complete installation for each tool: [onl12]. the interested reader is welcome to try out the tools. our single example is by no means a complete benchmark, but it is a first step in the right direction and must be extended in the future to cover further tools and, more importantly, a series of examples and different transformation scenarios such as in varró et al. [vsv05] for graph pattern matching. 1 www.mdelab.de/mote/ 2 www.cs.upb.de/index.php?id=tgg-interpreter 3 www.emoflon.org proc. bx 2013 2 / 17 www.mdelab.de/mote/ www.cs.upb.de/index.php?id=tgg-interpreter www.emoflon.org eceasst 3 foundations and running example our running example is inspired by bézivin et al. [brst06] and is a variant of the well-known bidirectional transformation from class diagrams to database schemata. figure 1 depicts a concrete class diagram on the left, and the corresponding database schema on the right. a class diagram consists of classes such as bank, client and account, and of associations between these classes such as clients between bank and client. furthermore, each element in the class diagram has a unique id: 01 for bank, 02 for clients, etc. in the domain of database schemata, tables such as bank 01, client 03 and account 05 have columns. in each table, exactly one column is designated as the primary key of the table (named “pk”), while all other columns (e.g., the column “clients::02” in bank 01) are foreign keys that reference other tables (indicated with arrows). a class obviously corresponds to a table with a primary key, while associations correspond to foreign keys. please note the correspondences between the names and ids of classes and the ids of tables (e.g., bank, 01 and bank 01), and the names and ids of associations and the names of columns (e.g., clients, 02 and clients::02). bank client account clients accounts accounts 01 02 04 03 05 06 bank_01 pkpk clients::02fk accounts::06fk account_05 pkpk client_03 pkpk accounts::04fk class diagram database schema figure 1: a class diagram and corresponding database schemata triple graph grammars (tggs) provide a declarative, rule-based means for specifying bidirectional transformations. a tgg consists of a set of rules that describe how related models from a source domain (class diagrams) and from a target domain (database schemata) can be produced simultaneously. a third model (hence triple graph grammars) is created in the process and can be viewed as a set of traceability links between corresponding model elements from the source and target domains. a tgg can be used to generate a set or language of triples of source, correspondence and target models and can be viewed as a consistency relation; a source (ms) and target (mt ) model are consistent with respect to a given tgg, if a triple of models ms, mc, mt , denoted as ms ← mc → mt , can be generated with the tgg, where mc is the correspondence model. our goal in this paper is to impart a clear intuition for the core concepts of tggs and we refer to [eee+07, kw07, ghl10, klks10] for further details. fig. 2 depicts a tgg rule for our running example. a rule r = (l,r) consists of a precondition l and a postcondition r, both typed graphs (structures consisting of nodes and links with types) representing model fragments that conform to the specified triple of metamodels. the rule can be interpreted as follows: if an occurrence or match can be found for the precondition l in a given 3 / 17 volume 57 (2013) a survey of triple graph grammar tools model m, then the rule r can be applied to the model m to yield a new model m′ by replacing the determined match of l with r. the rule r, depicted in fig. 2, requires an already related triple of class diagram, correspondence, and database schema (created using a different rule) and extends this triple by adding a new class to the class diagram and a corresponding new table with its primary key column. elements in l and r\l are referred to as context and created elements, respectively. tgg rules have been extended formally to handle attributes in the related models [avs12]. in fig. 2, the attribute formula specifies that the table’s uid must correspond to the concatenation of the name, an underscore, and the id of the corresponding class. classdiagram: classdiagram schema: schema cd2s: classdiagramtoschema clazz: clazz table: tablec2t: clazztotable primarykey: column +columns +elements +tables +target+source +target+source classdiagram: classdiagram schema: schema cd2s: classdiagramtoschema +target+source :l r clazz.name + ‘_’ + clazz.id = table.uid figure 2: tgg rule classtotable in formal syntax although tgg rules can be used to produce source and target models simultaneously, the real potential of tggs lies in the automatic derivation of operational forward and backward transformation rules. from the tgg rule r (fig. 2), an operational forward rule r f can be derived, which differs from r in that it translates all create elements in the source domain and only creates new elements in the correspondence and target domains. deriving operational rules is straightforward: the precondition of a rule is extended to include all elements created in the source domain. to create valid triple models with these rules, however, it must be ensured for the existing source model that (i) context nodes in rules are only matched to translated host graph nodes, and (ii) created nodes in rules are only matched to host graph nodes that have not yet been translated. a backward rule is derived analogously. attribute values are assigned based on attribute formulae, which are either automatically computed from the attribute formula or provided explicitly by the user. although attributes can be regarded formally as separate nodes, most implementations treat attributes as primitives and only allow assignment of attributes for created nodes in rules, i.e., attributes of context nodes cannot be created or deleted. given a source model ms, a forward transformation can be executed by applying forward rules derived from the tgg to translate ms and yield a triple ms ← mc → mt , which could have been generated by using tgg rules. an important question is under which conditions this is always possible, and formal results from [eee+07] prove existence and uniqueness provided that tgg rules are non-deleting, namely, l ⊆ r, which is the case for the three considered tools. the proof in [eee+07] is however not constructive and the task of determining the correct sequence of forward rule applications remains a challenge and a point where the different tgg tools diverge. the derived operational rules can be used in various scenarios, e.g., to create a consistent triple of models ms ← mc → mt from a given input model ms (a batch transformation), or to proc. bx 2013 4 / 17 eceasst incrementally update a triple ms ← mc → mt to result in a consistent triple m′s ← m ′ c → m ′ t (an incremental transformation) given the changes that produced m′s from ms. a tgg tool, therefore, requires a control algorithm to (i) determine a traversal order through the input model and (ii) choose the right rule to process each model element. to commence the transformation, a starting node in the input model and an operational rule to translate this node must be determined. such a valid starting rule without any context elements, i.e., no precondition, is referred to as an axiom. after the first node is translated, a strategy is required to systematically cover all elements in the input model in an appropriate order. in general, more than one rule can be applicable for the current node to be translated and making the right choice requires backtracking to undo wrong decisions. this is, however, inefficient (exponential runtime) and most tgg tools restrict the class of supported tggs to avoid backtracking. 4 criteria for comparison figure 3 depicts a schematic architecture of a tgg implementation. the transformation designer (fig. 3::1, i.e., label 1 in fig.3) specifies the bidirectional transformation as a tgg. the end user (fig. 3::2) is mainly interested in the implemented transformation and uses this as a black box. in many scenarios, both users are actually the same person; the transformation designer, for instance, needs to test and refine the tgg, thus temporarily taking on the role of the end user. transformation designer end user specification environment integration environment frontend backend tgg rules operational rules control algorithm 1 2 3 4 5 6 7 8 figure 3: schematic architecture of a tgg implementation there is normally a clear separation between a front end and a back end. the front end can be divided into two parts: a specification environment (fig. 3::3) used by the transformation designer to specify the involved metamodels and rules, and an integration environment (fig. 3::4), with which the end user can run the transformation, view the results, and understand the transformation process. depending on the concrete tgg tool, these might be clearly separated or form a single front end component. the front end and back end must be connected (fig. 3::5) either via an import/export persistence format or an api. this again depends on whether the front end and back end are realized in completely separate tools or not. the back end consists of data structures for the metamodels and the tgg rules (fig. 3::6). 5 / 17 volume 57 (2013) a survey of triple graph grammar tools depending on the concrete tgg tool, there might also be explicit data structures for the operational rules (fig. 3::7) used by a control algorithm (fig. 3::8). operational rules are, however, optional as an interpreter might use the tgg rules directly. we consider the following groups of criteria to be most important when comparing tgg implementations from a practical point of view: usability (u): the first hurdle when using a new tool is getting it installed and properly configured (u1). this task should be supported with an installer, a sensible default configuration, tutorials, interactive help in the tool, and examples. the transformation designer requires a suitable concrete syntax (u2) (visual or textual) with which tgg rules can be specified. equally important is a thorough static analysis (u3) and numerous sanity checks to identify modeling errors early in the process and offer possible fixes. tool support should also be provided to increase productivity (u4), such as refactorings, or automatic rule derivation from other rules. at this point, a clear workflow (u5), stating which steps have to be taken in what sequence, becomes crucial, especially if there is an explicit switch between specification and integration environments. furthermore, the end user requires support to configure and invoke the transformation (u6) for an input model, and a means of visualizing the resulting triple (u7) in such a way that the translation process can be understood. expressiveness (e): a central question is if a chosen tgg tool is expressive enough to describe a required transformation. here, we limit ourselves to important features of the considered tools, meaning that this list is to be extended when comparing other tools. (negative) application conditions (e1) restrict the applicability of a rule to certain cases. to translate attributes, the tools use different types of attribute constraints (e2). attribute constraints may be unidirectional, i.e., there must be two constraints (forward and backward). with bidirectional attribute constraints, there is only a single constraint that is used for both forward and backward transformations. some tools allow the transformation of single edges (e3), i.e., rules where only edges are created in a triple rule. this requires explicit bookkeeping of the transformed edges. tools may impose restrictions on the connectivity of the rules (e4), e.g., require them to be strongly connected or to be just weakly connected. without any restrictions, rules may even consist of disjunct components. tgg tools usually have to find a compromise between expressiveness on the one hand and efficiency and formal properties on the other. therefore, each tool appropriately restricts the class of supported tggs (cf. properties f1 and f2). formal properties (f): every tgg tool is expected to be correct (f1), complete with respect to the class of supported tggs (f2) and efficient for batch (f3) and incremental (f4) transformations. according to [klks10], these properties are defined as follows: correctness: given an input model mi, the resulting triple mi ← mc → mo created by a forward/backward transformation must be a member of the language generated by the tgg. completeness: every input model that can (in theory) be extended to a consistent triple must be extended to a consistent triple by the forward/backward transformation. efficiency: for a batch transformation, the transformation must have polynomial runtime complexity (nk) w.r.t. the number of model elements (n) and the maximal number of elements (k) in a single rule of the tgg. in the incremental case, the runtime must scale w.r.t. the number of changes to be propagated incrementally and not with the size of the involved models. proc. bx 2013 6 / 17 eceasst besides correctness, which ensures that results of a forward/backward transformation never contradict the given tgg, it is also useful to guarantee completeness at least for a certain class of tggs. if a transformation fails with a complete tool, the user knows for sure that either (i) the input model is invalid, i.e., cannot be completed to a valid triple, or (ii) the given tgg is not in the class of tggs supported by the tool, which must be clearly defined when proving completeness. in practice, to ensure efficiency, most tgg tools are correct and complete only for a certain subset of all possible tggs, i.e., each implementation poses a different set of limitations on valid tgg rules. this is one of the factors that make it difficult to use different tgg tools and is to be addressed in this paper. nevertheless, these properties can be guaranteed by formalizing the core algorithm of an approach and arguing that they hold at least at this level of abstraction. tests and actual measurements are of course necessary to support such claims, and a series of benchmarks in a controlled testing framework are some of the steps taken in this paper to achieve this goal. in the following, we present three tgg tools and enable a qualitative and quantitative comparison using the criteria defined in this section. 5 mote (hasso-plattner-institute) mote (model transformation engine) is an emf-based model transformation tool that supports bidirectional model transformation and synchronization (or incremental updates). usability: mote can be installed via the eclipse update manager from the mdelab update site. an example transformation can be installed and user documentation is available via the eclipse help system (u1). a gmf-based editor is provided to specify tgg rules using the common tgg visual concrete syntax, where lhs and rhs are presented in a combined notation using colors to differentiate context (black) from created (green and marked with the <> stereotype) elements (fig. 4) (u2). in mote, tgg rules can have rule parameters, which specify values to be assigned to created elements when the tgg rules are applied directly to create both models as used in the automatic conformance testing framework [hlg+12]. the derived operational rules calculate the values of rule parameters using the provided forward and backward expressions (denoted with f and b). the editor also provides a comprehensive validation of tgg rules (u3). a wizard is provided to create a new tgg rule project with an initial tgg axiom and a first incomplete tgg rule (u4). after completing the specification, the transformation developer can derive operational rules by executing a designated workflow4 file, which additionally creates configuration files and java code to invoke the operational rules (u5). finally, the tgg rule project has to be deployed as an eclipse plugin, which is discovered by mote via the extension mechanism in eclipse. a model transformation or synchronization can be invoked either via its java api, with the appropriate wizard from the model transformations menu, or as part of a workflow (u6). in addition, a testing framework is provided [hlg+12], which can be used to generate random test models and test the tgg. this allows the transformation developer to validate whether his tgg behaves as expected. 4 mdelab workflows (http://www.mdelab.de/workflow/) can be used to automate certain modeling tasks by plugging together workflow components, e.g., a component to read a model, a component to transform this model to a target model, and another component to save the target model to disk. 7 / 17 volume 57 (2013) http://www.mdelab.de/workflow/ a survey of triple graph grammar tools figure 4: the clazz2table rule in mote’s tgg editor expressiveness: mote has been used successfully in an industrial case study [gnh10] to integrate a sysml and an autosar modeling tool. tgg rules are compiled to story diagrams,5 which are interpreted by a story diagram interpreter [ghs09]. mote is emf-based and supports constraints and attribute assignments in ocl or java. attribute assignments, however, have to be specified for each direction separately (e2). currently, mote does not support (negative) application conditions (e1) and rules that create edges between context nodes (e3). furthermore, some restrictions are imposed on the structure of valid tgg rules to be able to formalize the transformation algorithm and ensure comparably high transformation efficiency (e4). formal properties: the batch transformation algorithm in mote is formalized in [ghl10], defining the exact restrictions imposed on valid tgg rules and proving correctness (f1), and completeness (f2) for tggs that exhibit functional behavior [hego10]. functional behavior means that the result of a transformation is unique up to isomorphism and can be viewed, depending on the application scenario, either as a limitation, or as a useful property. a tgg has functional behavior if it is terminating, which is ensured by checking the structure of tgg rules, and if its rules do not conflict, which can be checked via a critical pair analysis. however, this is not yet supported in the current mote release. mote supports batch (f3) and incremental (f4) transformations, which have been shown to be efficient (see sect. 9 and [gh09]). regarding the underlying control algorithm; mote requires a designated starting node (typically the root node of an emf model) and only allows exactly one axiom in the tgg. to drive the transformation process, mote takes the following approach: each rule creates exactly one 5 programmed graph transformations for specifying unidirectional model transformation. proc. bx 2013 8 / 17 eceasst correspondence node and requires a set of correspondence nodes as context. the derived operational rules create a link between context and the created correspondence node. this results in a directed acyclic correspondence graph, which also represents dependencies between applied rules. after the axiom is applied to create a single correspondence node c, all rules that require c as context are applied with c as the entry point for pattern matching to translate and create further elements in the input and output models respectively. each rule that transforms an element also creates a new correspondence node and the process is repeated until it terminates (a correspondence node is created which is not required by any other rule). this allows for efficient pattern matching and also reduces the number of rules that must be checked for applicability in each step. mote does not support backtracking, which is one reason why a tgg must have functional behavior. current and future focus: due to the widespread use of model transformations in mde, the quality of model transformations has to be ensured. conformance testing of model transformations is, therefore, still an important and open issue. current development focusses on improving and extending the automatic conformance testing framework presented in [hlg+12], and generalizing it to support and test transformations specified with other transformation languages, not only tggs. 6 the tgg interpreter (university of paderborn) the tgg interpreter is a tgg model transformation and incremental update tool that was developed as a result of comparing tggs and the omg standard for (bidirectional) model transformations, query/view/transformation qvt [gk07, gk10]. usability: the tgg interpreter is eclipse-based and can be installed via the eclipse update manager (u1). figure 5 depicts a screenshot of the tgg rule editor showing a visual concrete syntax similar to all other tools (u2). several sanity checks (e.g., node/edge type conformance, rule inheritance validity, ocl syntax checks, etc.) are performed statically to prevent modeling errors (u3). however, there is no support for critical-pair analysis in order to identify possibly conflicting rules. a gmf editor is provided for editing tgg rules along with convenience functionality, e.g., creating new rules based on patterns in other rules, and creating correspondence types on-the-fly for correspondence nodes (u4). the tgg interpreter directly executes tgg specifications without further processing (u5). it integrates itself into the eclipse gui, allowing performing transformations by right-clicking on a model file or via an eclipse run configuration (u6). transformations can also be executed programmatically via an api call. an additional plugin, the correspondence view, can be used to visualize the results of a transformation. it shows the concrete syntax of both models side-by-side, allowing the user to visualize corresponding elements in the models. a transformation designer can use the debug mode (fig. 5) to inspect the transformation and pattern matching process (u7). expressiveness: application conditions (e1) and attribute constraints (e2) can be formulated in ocl, but bidirectional relations on attribute values have to be expressed as assignments in the forward and backward direction. no strong restrictions are imposed on the structure of tgg rules, i.e., patterns need only be weakly connected (e4), edges can be created between context 9 / 17 volume 57 (2013) a survey of triple graph grammar tools figure 5: tgg rule editor of the tgg interpreter during debugging nodes (e3), and correspondence nodes can be connected to source and target elements as the user wishes. the tgg interpreter supports advanced tgg concepts such as a form of rule inheritance, stereotypes in uml domains, and reusable nodes and patterns to retain information in the incremental case [gr12]. formal properties: the tgg interpreter is correct (validated but not formally verified) (f1), but not complete (f2) in general, due to a lack of backtracking/look-ahead functionality. thus, similar to mote, it may fail to find a correct sequence of rule applications to match a given source model when more than one rule is applicable. a static analysis to check these conditions is currently not provided. as the tgg interpreter directly interprets the tgg and, moreover, supports advanced features such as explicit edge bindings, it is outperformed by both other tools (cf. sect. 9), but is still efficient enough for most practical cases (f3). furthermore, as the tgg is interpreted to perform the transformation, it can be updated on-the-fly during a transformation without needing to recompile or compute anything. like mote, the tgg interpreter also supports incremental updates (f4). regarding the control algorithm; the tgg interpreter requires a designated starting node, only allows exactly one axiom in the tgg, and requires functional behavior to avoid backtracking. the input model is traversed by driving a front consisting of the current set of translated nodes, which is extended by examining all elements that can be reached from the front via a single edge. only these front-extension elements are considered in the next step limiting the search for applicable rules to only those that require a front element and translate a front-extension element. the process terminates when the front can no longer be extended. proc. bx 2013 10 / 17 eceasst current and future focus: current development on the tgg interpreter is in the direction of (i) support for improved algorithms for incremental updates [gpr11] and conflict resolution, (ii) a static analysis to identify conflicting rules (f2), and (iii) support for non-functional transformations [rs12]. furthermore, performance optimization is planned as future work. 7 emoflon (technische universität darmstadt) emoflon [alps11] is a tool suite for metamodeling and model transformation. hence, not only bidirectional model transformation with tggs is supported, but also unidirectional model transformation with story diagrams, and metamodeling with ecore/emf. emoflon aspires to provide a complete environment for all required activities (cf. the online demo via share [onl12]). usability: a detailed tutorial (available at www.emoflon.org) describes the few steps required to get emoflon up and running. the specification and integration environment are provided as plugins of separate tools: an extension for enterprise architect (ea) and an eclipse plugin. ea is a professional uml tool and has proven to be advantageous for visual modeling as opposed to, e.g., gmf [alps11]. installing emoflon (u1) only requires clicking through a windows installer for the ea extension, and installing an eclipse plugin. figure 6(a) depicts the clazz2table tgg rule in ea. the emoflon concrete syntax (u2) is visual and uses a compact (merged) representation. currently, the emoflon frontend only runs on windows, but an alternative specification environment in eclipse with a textual concrete syntax is under development. (a) emoflon specification environment (b) emoflon integration environment figure 6: tgg rule specification in ea (left) and runtime integration environment (right) 11 / 17 volume 57 (2013) www.emoflon.org a survey of triple graph grammar tools specifying tggs in ea (fig. 6(a)) is supported by a substantial static analysis (u3). editor features support productivity (u4), e.g., via the automatic derivation of tgg rules from other rules or from a choice of metamodel elements. the workflow (u5) is completed by exporting the specification from ea (simple context menu) and switching to the corresponding eclipse workspace. the generated transformation code can be invoked (u6) by executing an automatically generated java main method. the resulting triple created by the transformation can be visualized (u7) and stepped through using an integrator (fig. 6(b)). this gui component visualizes a triple of models in a matrix, i.e., the correspondence graph is visualized as links between two trees. a protocol containing a trace of the whole transformation process can be used to step through the transformation and understand which rules were applied when and why to which elements (colors indicate different states of elements during the transformation). as regions can be collapsed in the integrator (fig. 6(b)) and programmable breakpoints can be provided to navigate directly to interesting situations, models with up to about 800 1000 nodes can be analyzed successfully, depending of course on how interconnected the nodes are. expressiveness: emoflon uses codegen2 from the fujaba tool suite as its underlying graph pattern matcher. tggs are compiled to story diagrams6 with story diagrams, which are then compiled with codegen2 to plain emf code. in addition to basic graph patterns, negative application conditions [ast12] (e1) and flexible, bidirectional attribute manipulation [avs12] (e2) are supported in tgg rules. the latter is achieved via in node attribute assignments, such as for pk:column (cf. fig. 6(a)), and via a bidirectional and extensible constraint language, such as for concatenating class names and table ids. additionally, tgg rules are allowed to only transform edges (e3). regarding the connectivity of the rules (e4), the underlying graph pattern matcher requires to have weakly connected patterns in the source and target domain of a rule. formal properties: the emoflon tgg tool is based on the algorithm of [klks10], which has been shown to be correct (f1), complete for a certain class of tggs (f2), and efficient (f3). emoflon is not yet incremental (f4) but the incremental tgg control algorithm presented in [lavs12] is currently being implemented. the control algorithm of emoflon can start with any node in the input model and handle arbitrary many axioms. tggs are not required to be functional and a look-ahead is used to resolve local rule choices by inspecting edges that can no longer be translated if a wrong choice is made (dangling edge check (dec)). for efficiency, emoflon only supports a look-ahead of one edge (dec 1) from the current node to be translated, i.e., the class of supported tggs is limited to local complete tggs where dec 1 is sufficient to resolve conflicts. in cases where multiple choices are correct, i.e., there is a true degree of freedom in the translation, emoflon asks a component (the user, a configuration file, algorithm, etc.) to decide. note that the set of local complete tggs subsumes the set of functional tggs, which only require “dec 0”. regarding the traversal order; this order is determined on-the-fly in a context-driven manner. all context nodes required by each potential rule are recursively translated, which automatically induces a feasible order in which all elements of the input model can be translated successfully. please note that this recursive, eager and context-driven transformation strategy works for the supported class of tggs, which is precisely defined in [klks10] with a description of all runtime exceptions that are thrown when a required restriction is violated. 6 story diagrams are a combination of uml activity diagrams and graph transformations. proc. bx 2013 12 / 17 eceasst current and future focus: current and future development on emoflon is in the direction of (i) implementing the incremental algorithm presented in [lavs12] and investigating/evaluating other strategies for supporting incremental transformations with tggs, (ii) providing a rich static analysis based on first ideas presented in [ast12], (iii) investigating and implementing advanced modularity concepts for tggs, (iv) providing a textual concrete syntax for tggs (and emoflon in general), and (v) extending the general framework for bidirectional model-to-text transformations with tggs presented in [asrs12]. 8 summary of qualitative comparison table 1 summarizes the comparison based on criteria from sect. 4 ( denotes “sufficient/good”, g# “can be improved”, and # “missing/inadequate”). in general, there is no “single best” tool; all three tools have their own strengths and weaknesses. u1 u2 u3 u4 u5 u6 u7 e1 e2 e3 e4 f1 f2 f3 f4 mote g# g# g# # g# g# # g# g# interp. g# g# g# g# g# g# g# emoflon g# g# g# g# g# g# g# # table 1: summary of the qualitative comparison of the three tgg implementations some observations are: emoflon’s installation process is a bit complex as two separate tools are used (u1), an alternative textual concrete syntax for tggs is currently missing in all tools (u2), all tools should be improved regarding static analyses (u3), and mote can be improved regarding the visualization of results and the transformation process (u7). mote has the strongest restrictions on tgg rules (e1 to e4), the tgg interpreter allows the most flexible patterns (e4), and only emoflon supports true bidirectional attribute constraints (e2). although bidirectional constraints guarantee that a tgg works bidirectionally, note that unidirectional constraints are more expressive in some cases. all tools are correct (f1), but a formal proof for completeness (f2) only exists for mote’s and emoflon’s transformation algorithm. emoflon supports a larger class of tggs than both mote and the tgg interpreter, is fastest (f3) on the example scenario (cf. sect. 9), but does not yet support incremental transformations (f4). 9 quantitative comparison (runtime measurements) to allow a first estimation of the batch transformation performance of the tools, we conducted a benchmark, in which each tool was used to translate the same set of models using the transformation presented in sect. 3. this quantitative assessment was not conducted for incremental transformations, as this is not yet fully supported by all tools (cf. sect. 8). using the model generator of the tgg test framework [hlg+12] (part of mote), random test models were created. in total, 19 random class diagram test models were generated with 100, 200, ..., 1000 elements and 2000, 3000, ..., 10000 elements. the average execution times were calculated after each 13 / 17 volume 57 (2013) a survey of triple graph grammar tools 100 1000 10000 100000 1000000 ti m e in m se c 10 100 200 300 400 500 600 700 800 900 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 model size mote forward emoflon forward tgg interpreter forward figure 7: runtime measurement results for forward transformation tgg tool transformed each class diagram 20 times. the measurements were conducted on a windows 7 x64 pc with an intel i5 750 (2.66 ghz) processor, oracle jdk 1.7, and eclipse 4.2. the class diagram and database schema metamodels and all test models are available for download.7 the average execution times for all tools and model sizes for the forward and the backward transformation are depicted in fig. 7 and 8. note that a logarithmic scale is used for the y-axis. a vertical line indicates where the x-axis scaling changes. for the forward transformation, the results show that emoflon (green solid curve), the only tool that generates java code from tgg rules, is faster than the tgg interpreter (red dotted curve), which interprets tgg rules directly, and mote (blue dashed curve), which interprets operational rules as story diagrams. the difference between emoflon and mote (8s/20s for 10000 elements) is, however, considerably smaller than that between emoflon and the tgg interpreter (8s/367s for 10000 elements). this is probably due to the dynamic pattern matching strategy of the story diagram interpreter [ghs09], and mote’s algorithm (see sect. 5), in which the application of the next tgg rule is guided by dependencies in the correspondence model; both perform well in this scenario. the tgg interpreter is faster when transforming backwards than when transforming forward in this scenario. mote is also faster for models with more than 700 elements. interestingly, emoflon is slower in the backward direction than in the forward direction for models with more than 300 elements, infact, mote outperforms emoflon when transforming backwards for model with more than 2000 elements. the different results for forward and backward transformations indicate that the matching and transformation strategies implemented in the tools are quite different and have a significant impact on the overall performance. to make any general conclusions, however, other transformation scenarios have to be considered. this is planned as future work. 7 http://emoflon.org/fileadmin/download/emoflon/bx13 tgg survey.zip proc. bx 2013 14 / 17 http://emoflon.org/fileadmin/download/emoflon/bx13_tgg_survey.zip eceasst 100 1000 10000 100000 1000000 ti m e in m se c 10 100 200 300 400 500 600 700 800 900 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 model size mote backward emoflon backward tgg interpreter backward figure 8: runtime measurement results for backward transformation a polynomial runtime (in the size of the input model) is formally proven for emoflon [klks10], but not for mote and the tgg interpreter. nonetheless, from our experience, the runtime of the two latter tools is also polynomial in the size of the input model. 10 conclusion and future work in this paper, we provide a set of criteria to be used for comparing tgg tools. based on these criteria and the well-known class diagrams to database schemata transformation, we presented a quantitative and qualitative comparison of three actively developed tools: mote, the tgg interpreter, and emoflon. our results show that the tools vary considerably and have different strengths and weaknesses, depending on the application scenario and corresponding requirements: a purely interpretative approach (the tgg interpreter) is probably the best choice if metamodels are to be used without demanding generated code, emoflon is a viable choice if user interaction is to be integrated in the transformation (i.e., the tgg is non-functional), and mote/emoflon can be used for large models and in cases where efficiency is paramount. mote/the tgg interpreter are currently the best choice for incremental updates, and, finally, the tgg interpreter and emoflon support an interesting set of advanced tgg features that might be necessary if high expressiveness is required. as future work, we plan to extend the comparison to include further tgg tools and cover a whole suite of transformations that test different aspects including various kinds of incremental updates. the vision is to establish a benchmark for tgg tools, which can be used to drive and measure improvements in the future. 15 / 17 volume 57 (2013) a survey of triple graph grammar tools bibliography [alps11] a. anjorin, m. lauder, s. patzina, a. schürr. emoflon : leveraging emf and professional case tools. in memwe ’11. lni 192, p. 281. gi, 2011. [asrs12] a. anjorin, k. saller, s. rose, a. schürr. a framework for bidirectional model-toplatform transformations. in proc. of sle 2012. lncs. springer berlin / heidelberg, 2012. [ast12] a. anjorin, a. schürr, g. taentzer. construction of integrity preserving triple graph grammars. in ehrig et al. (eds.), proc. of icgt ’12. lncs 7562, pp. 356– 370. springer, 2012. [avs12] a. anjorin, g. varró, a. schürr. complex attribute manipulation in tggs with constraint-based programming techniques. in hermann and voigtländer (eds.), proc. of bx ’12. ec-easst 49, pp. 1–16. easst, 2012. [brst06] j. bézivin, b. rumpe, a. schürr, l. tratt. model transformation in practice. in bruel (ed.), models 2005 workshops. lncs 3844, pp. 120–127. springer, 2006. [ch06] k. czarnecki, s. helsen. feature-based survey of model transformation approaches. ibm systems journal 45(3):621–645, 2006. [eee+07] h. ehrig, k. ehrig, c. ermel, f. hermann, g. taentzer. information preserving bidirectional model transformations. in dwyer and lopes (eds.), proc. of fase ’07. lncs 4422, pp. 72–86. springer, 2007. [gh09] h. giese, s. hildebrandt. efficient model synchronization of large-scale models. technical report 28, universitätsverlag potsdam, 2009. [ghl10] h. giese, s. hildebrandt, l. lambers. toward bridging the gap between formal semantics and implementation of triple graph grammars. in proc. of modevva ’10. pp. 19–24. ieee, 2010. [ghs09] h. giese, s. hildebrandt, a. seibel. improved flexibility and scalability by interpreting story diagrams. in margaria et al. (eds.), proc. of gt-vmt ’09. eceasst 18. easst, 2009. [gk07] j. greenyer, e. kindler. reconciling tggs with qvt. in engels et al. (eds.), proc. of models ’07. lncs 4735, pp. 16–30. springer, 2007. [gk10] j. greenyer, e. kindler. comparing relational model transformation technologies: implementing query/view/transformation with triple graph grammars. sosym 9(1):21–46, 2010. [gnh10] h. giese, s. neumann, s. hildebrandt. model synchronization at work: keeping sysml and autosar models consistent. in engels et al. (eds.), festschrift nagl. lncs 5765, pp. 555–579. springer, 2010. proc. bx 2013 16 / 17 eceasst [gpr11] j. greenyer, s. pook, j. rieke. preventing information loss in incremental model synchronization by reusing elements. in france et al. (eds.), proc. of ecmfa ’11. lncs 6698, pp. 144–159. springer, 2011. [gr12] j. greenyer, j. rieke. applying advanced tgg concepts for a complex transformation of sequence diagram specifications to timed game automata. in schürr et al. (eds.), proc. of agtive 2011. lncs 7233, pp. 222–237. springer, 2012. [hego10] f. hermann, h. ehrig, u. golas, f. orejas. efficient analysis and execution of correct and complete model transformations based on triple graph grammars. in bézivin et al. (eds.), proc. of mdi ’10. pp. 22–31. acm, 2010. [hlg+12] s. hildebrandt, l. lambers, h. giese, d. petrick, i. richter. automatic conformance testing of optimized triple graph grammar implementations. in schürr et al. (eds.), proc. of agtive ’11. volume 7233, pp. 238–253. springer, 2012. [klks10] f. klar, m. lauder, a. königs, a. schürr. extended triple graph grammars with efficient and compatible graph translators. in engels et al. (eds.), festschrift nagl. lncs 5765, pp. 141–174. springer, 2010. [kw07] e. kindler, r. wagner. triple graph grammars: concepts, extensions, implementations, and application scenarios. technical report tr-ri-07-284, department of computer science, university of paderborn, 2007. [lavs12] m. lauder, a. anjorin, g. varró, a. schürr. efficient model synchronization with precedence triple graph grammars. in ehrig et al. (eds.), proc. of icgt ’12. lncs 7562, pp. 401–415. springer, 2012. [lsrs10] m. lauder, m. schlereth, s. rose, a. schürr. model-driven systems engineering: state-of-the-art and research challenges. bulletin of the polish academy of sciences, technical sciences 58(3):409–422, 2010. [mv06] t. mens, p. van gorp. a taxonomy of model transformation. entcs 152:125–142, 2006. [onl12] online demos for all tools as share images. http://www.moflon.org/emoflon/ a-survey-of-tgg-tools/. 2012. [rs12] j. rieke, o. sudmann. specifying refinement relations in vertical model transformations. in proc. of ecmfa 2012. pp. 210–225. springer berlin/heidelberg, 2012. [ste08] p. stevens. a landscape of bidirectional model transformations. in lämmel et al. (eds.), proc. of gttse ’07. lncs 5235, pp. 408–424. springer, 2008. [vm11] p. van gorp, s. mazanek. share: a web portal for creating and sharing executable research papers. proc. of iccs ’11 4:589–597, 2011. [vsv05] g. varró, a. schürr, d. varró. benchmarking for graph transformation. in proc. of vlhcc ’05. pp. 79–88. ieee, 2005. 17 / 17 volume 57 (2013) http://www.moflon.org/emoflon/a-survey-of-tgg-tools/ http://www.moflon.org/emoflon/a-survey-of-tgg-tools/ motivation related work foundations and running example criteria for comparison mote (hasso-plattner-institute) the tgg interpreter (university of paderborn) emoflon (technische universität darmstadt) summary of qualitative comparison quantitative comparison (runtime measurements) conclusion and future work automatically verifying railway interlockings using sat-based model checking electronic communications of the easst volume 35 (2010) proceedings of the 10th international workshop on automated verification of critical systems (avocs 2010) automatically verifying railway interlockings using sat-based model checking phillip james and markus roggenbach 17 pages guest editors: jens bendisposto, michael leuschel, markus roggenbach managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst automatically verifying railway interlockings using sat-based model checking phillip james1∗ and markus roggenbach1 swansea university1, wales, uk abstract: in this paper, we demonstrate the successful application of various satbased model checking techniques to verify train control systems. starting with a propositional model for a control system, we show how execution of the system can be modelled via a finite automaton. we give algorithms to perform sat-based model checking over such an automaton. in order to tackle state-space explosion we propose slicing. finally we comment on results obtained by applying these methods to verify two real-world railway interlocking systems. keywords: model checking, interlocking, ladder logic, railway, sat, slicing. 1 introduction formal verification of railway control software has been identified to be one of the “grand challenges” [jac04] of computer science. various formal methods have been applied to this area, including algebraic specification, e.g., [bjø09], process-algebraic modelling and verification, e.g., [win02], and also model-oriented specification, where e.g., the b method has been used in order to verify part of the paris metro railway [bg00]. in partnership with invensys, an internationally established company specialising in railway control systems, we explore various verification approaches based on sat solving [bhmw09]. the aim is to explore and develop technologies that, at a later date, might be integrated into invensys’ design process. continuing work by kanso et al. [kms08] we verify interlockings of real-world train stations with respect to safety conditions. our modelling language is propositional logic, see figure 1: the physical layout of the train station together with an abstract safety condition, e.g., ‘trains are separated by at least one empty track segment’, yields a concrete safety condition ϕ . the initial configuration of a train station is characterised by some initialisation formula i. the control program (in ladder logic, an iec standard [iec03]) of the interlocking system is translated into a transition formula t . all the above translations have been automated in [kms08]. using an inductive approach, namely i(z) ⇒ ϕ(z) and t (z,z′)∧ϕ(z) ⇒ ϕ(z′), kanso et al. [kms08] successfully verify a medium sized real-world interlocking. some of the required safety properties are automatically proven using a sat solver [kul08], however in some cases the sat solver produces counter examples. these take the from of a pair of states, namely interpretations of z and z′, which violate the safety property. in the context of the interlocking under discussion, these counter examples were excluded via manual analysis: it was claimed that they concern unreachable states. for inclusion into the standard development process of interlockings, invensys requires further automation of the verification, namely the exclusion of the supposed to be ∗ acknowledging the support of invensys rail. 1 / 17 volume 35 (2010) automatically verifying railway interlockings using sat-based model checking for all track points... safety condition 𝜑 𝑍 railway topology informal safety condition automated verification interlocking ladder logic |a| |c| |e| |d| (b) initial condition 𝐼(𝑍) and transition formula 𝑇 𝑍, 𝑍′ 𝑍, 𝑍′ : 𝑅𝑒𝑝𝑟𝑒𝑠𝑒𝑛𝑡 𝑠𝑦𝑠𝑡𝑒𝑚 𝑠𝑡𝑎𝑡𝑒𝑠. t104 t101 t102 t103 figure 1: the basic verification setting. unreachable states and the production of error traces if a safety property does not hold. in order to accommodate these requirements, we develop and experiment with verification approaches based on ideas used in bounded model checking. here, we deliberately stay within boolean modelling: first, it is natural in the given context – the ladder logic program contains only boolean variables; second, it allows the direct use of sat solvers for verification. in order to deal with real-world interlockings, we develop a slicing technique. to this end we re-use an algorithm first stated by [gkv95, fh98] and prove that it is correct w.r.t. our specific setting. in practice, slicing reduces the problem size by approximately a factor of five. this reduction has proven to be enough to automatically verify, using various techniques, two interlockings of medium complexity: either the safety condition could be proven, or an error trace was produced. in [zrk03, fh98] alternative approaches for the verification of ladder logic programs are provided. in [zrk03] a translation from ladder logic into timed automata is defined, before using the uppaal model checker [upp10] for verification. due to state-space explosion their approach is limited to “small” programs. secondly, in [fh98] an inductive verification approach is taken to verify ladder logic interlockings. this paper is organised as follows: in section 2, we introduce the basics of railway interlockings. section 3 introduces a pelican crossing as a small example system. in sections 4 and 5 we give a modelling of interlockings through propositional logic and automata. section 6 introduces the model checking approaches we apply, with section 7 giving a method to tackle state-space explosion. finally, section 8 shows the results gained from verifying two real-world interlockings. the results given in this paper are based on [jam10] and have already been presented at calco-jnr [jr10], a workshop for young researchers which encourages re-submission of papers to proper scientific events. proc. avocs 2010 2 / 17 eceasst 2 interlockings an interlocking provides a safety layer for a railway. it interfaces with both the physical track layout and the human (or computerised) controller. the controller issues requests, such as to move a point. on such a request the interlocking will determine whether it is safe for the operation to be permitted. if it is safe then the interlocking will issue requests to change the physical track layout, informing the controller of the change. whereas if it is unsafe to perform the operation the interlocking will not allow the physical track layout to be changed, and will report back to the controller that the operation has not taken place as it would yield an unsafe situation. here, we consider westrace [wes10] interlockings. a westrace interlocking has the following typical control flow: initialise while true do read (input) %% read (*) state’ 2 configurations of the interlocking: instead of paired valuations one has to define k-tuples of valuations; a safety property ϕ can speak about k different copies of each variable in i ∪c; and ψ is safe if all reachable k-tuples of consecutive states satisfy the safety condition ϕ. 6 applying model checking to ladder logic in this section we discuss two verification techniques based on sat solving: bounded model checking [bccz99] and temporal induction [sss00]. to allow us to apply these techniques, we firstly have to give a representation of the state sequences of the automaton under consideration. 6.1 representing state sequences given a set i of input variables and a set c of state variables, we define variable sets wi = c(i)∪i(i) with c(i) = {c(i) |c ∈ c} and i(i) = {x(i) |x ∈ i} for i ∈ z. here we use the superscript (i) to produce fresh variables. we write [wi/(i ∪c)] to denote the substitution where all superscripts are removed, and [wi+1/(i′∪c′)] for the substitution where all superscripts are replaced by primes. a sequence w0,w1,w2,... of these variable sets is capable to “store” a state sequence of an automaton a(ψ): definition 5 (series of transitions) let ψ be a ladder logic formula. we define the propositional formulae init ≡ ( ∧ i∈i(−1) ¬i)∧t (w−1,w0) tn ≡ ∧ 0≤i≤n−1 t (wi,wi+1) where n ≥ 0 and t (wi,wi+1)≡ ψ [wi/(i ∪c)][wi+1/(i′∪c′)]. given a ladder logic formula ψ , then the formula init∧tn is “satisfied” exactly by all state sequences s0,s1,...,sn of a(ψ). more formally: given a state sequence s0,s1,...,sn we construct an valuation µ : w−1 ∪w0 ∪···∪wn → {1,0}, where state s j gives the interpretation of wj for 0 ≤ j ≤ n, i.e. µ(i( j)) = s j(i), i ∈ i, and µ(c( j)) = s j(c), c ∈ c; µ(i(−1)) = 0, i ∈ i, and µ(c(−1)) such that we reach s0 via ψ. for this µ holds: µ |= init∧tn. conversely, given a µ with µ |= init∧tn one can decompose it to a state sequences s0,s1,...,sn of a(ψ). with these notations in place, we can define safety at a specific point in a sequence w0,w1,w2,.... proc. avocs 2010 8 / 17 eceasst definition 6 (safety at step n) let ϕ be a safety condition for a ladder logic formula ψ. we define the propositional formula ϕn ≡ ϕ [wn−1/(i ∪c)][wn/(i′∪c′)], where n > 0. 6.2 bounded model checking widely used within industrial applications [cess08, adk+05], bounded model checking restricts the search space by a bound which states how many transitions of the automaton should maximally be considered for the verification process. using the formulae initial ≡ init∧t1 ⇒ ϕ1 transitionn ≡ tn ⇒ ϕn, for n > 0 the algorithm shown in figure 4 performs a forwards iteration of the state-space. given an automaton a(ψ) and safety condition ϕ , the algorithm will check: (1) that ϕ holds on all transitions leaving the initial states of the automaton, and that (2) ϕ holds for up to k transitions from an initial state of the automaton. if ¬initial is satisfiable return error trace j ← 2 while j ≤ k do if ¬transition j is satisfiable return error trace j ← j + 1 return ”k-safe” figure 4: k-step forwards iteration algorithm. the algorithm in figure 4 calls a sat solver once in every iteration. in practice, the algorithm performs better when multiple calls to the sat solver are combined into one call, namely for l > 1, “¬transition j satisfiable”, . . . , “transition j+l satisfiable”, are combined to one call, namely “¬(transition j ∧···∧transition j+l) satisfiable”. practical results from the pelican crossing example, show that verification times are less than one second2. with inductive verification, see [kan08], verification of the safety condition given in section 5.1 fails for the induction step. with the proposed bounded model checking approach, we were able to show that this was in fact due to unreachable states. that is, a bound size of k = 6 is required when using the given algorithm. then via inspecting the state space given in figure 3 we see that a bound of 6 covers all states. 6.3 unbounded model checking temporal induction [sss00] is a method that is based on strengthening the inductive approach as e.g., given by kanso [kan08]. as the name suggests, the verification method still consists of 2 all results presented in this paper are based on tests carried out using a 64-bit computer, with a 3ghz quad-core processor and 8 gbytes of memory. 9 / 17 volume 35 (2010) automatically verifying railway interlockings using sat-based model checking two proof steps, namely a base case and an inductive step. these proof steps are however used differently: the (negation of the) base case is checked for satisfiability, and the (negation of the) inductive step is checked for unsatisfiability. our presentation follows [es03]. we define properties of a state sequence encoded by w0,w1,...,wn: lfn ≡ ( ∧ 0≤k> <> <> <> <> literalsensorid literalsignalid literalpointid literalrouteid literalduration literaltimeinstant <> <> <>0..1 0..1 literalinteger <> value:integer prefix:string figure 3: literals part of the rcsd profile several new datatypes are needed: identifiers for all controllable elements, identifiers for routes (e.g. to specify conflicting ones), time instants, and durations. all of them have in com5 / 18 volume 5 (2006) ocl-based validation of a railway domain profile mon that the value domain is n. defining different datatypes facilitates constraints like: all signal identifiers are unique, all point identifiers are unique, and so on. in addition, each new datatype has a dedicated stereotype to model literals of this type (see figure 3). for the identification types, the corresponding literal consists of an integer value and a prefix character. literals for time instants and durations are integer values. inv literalpointid1: value >= 0 inv literalpointid2: prefix = ’p’ ocl constraints for these stereotypes are simple as only values of properties are restricted. integers values have to be from n; prefixes for different identification types have specific values: ’s’ for sensors, ’sig’ for signals, ’p’ for points, ’a’ for automatic runnings, and ’r’ for routes. as an example, the two constraints needed for literalpointid are given above. for the sake of brevity, the name of invariants and the invariants context, where it is unmistakable, are omitted in the following. 4.2 network elements <> segment <> crossing <> sensor 0..1 automaticrunning <>0..1 <> class <> point 0..1 <> trackelement <> <> singlepoint slippoint 0..1 <> signal <> low high failure sensorstatekind <> go stop <> straight left right failure pointstatekind <> go stop failure signalstatekind <> off failure on autorunkind left right straight <> routekind permissionkind figure 4: network elements part of the rcsd profile the next part of the profile defines track network elements, i.e. segments, crossings, points, signals, sensors, and automatic train runnings (see figure 4). segment, crossing, and point have in common that they form the track network itself, therefore they are all subclasses of the abstract proc. oclapps 2006 6 / 18 eceasst trackelement. similarly, singlepoint and slippoint are specializations of point. enumerations are defined to specify values of properties. all elements are equipped with a set of constraints that define which properties must be supported by each element and how it is related to other elements. an instance of trackelement on the model layer must provide several properties: maximalnumberoftrains to restrict the number of trains on a track element at one point in time (mandatory) and limit to give a speed limit (optional). both properties have to be integers. the first one has a fixed multiplicity 1, the second one may have multiplicities 0..1 or 1. such requirements for trackelement are defined in the following way: ownedattribute->one(a | a.name->includes(’maxnumberoftrains’) and a.type.name->includes(’integer’) and a.upperbound() = 1 and a.lowerbound() = 1 and a.isreadonly = true) to understand the structure of this constraint, a look at the uml metamodel is helpful. in figure 5, a part of it is shown, namely the classes diagram of the uml 2.0 kernel package. as all network elements are stereotypes of class, we can refer to all properties of class in our constraints. properties on the model level are instances of class property on the metamodel level, which are associated to class by ownedattribute. as a structuralfeature, property is also a namedelement, a typedelement, and a multiplicityelement, which allows to restrain name, type, and multiplicity as shown in the constraints above. operation valuespecification <> aggregationkind none composite shared classifier /default:string aggregation:aggregationkind = none /iscomposite:boolean +ownedattribute {subsets redefinedelement} +class {subsets namespace, {ordered, subsets redefinitioncontext} subsets ownedmember} 0..1 subsets namespace, subsets featuringclassifier} {subsets classifier, subsets ownedmember} +/superclass +subsettedproperty {redefines general} +nestedclassifier+class +class 0..1 0..1 +ownedoperation {subsets redefinitioncontext, {ordered, subsets ownedmember} subsets namespace, subsets feature, subsets featuringclassifier} +/opposite0..1 {ordered, subsets attribute, {ordered, subsets member} subsets ownedend, subsets feature, subsets ownedmember} +redefinedproperty +navigableownedend {subsets ownedend} {ordered, isderived:boolean = false isreadonly:boolean = false isderivedunion:boolean = false property 0..1 2..* +defaultvalue+owningproperty 0..1 {subsets owner} {subsets ownedelement} class {subsets association, subsets namespace, subsets featuringclassifier} 0..1 0..1 isderived:boolean = false association +ownedend +owningassociation +memberend +association structuralfeature relationshipclassifier {ordered} +/endtype 1..* classifier * * * * * * * * type figure 5: classes diagram of the uml 2.0 kernel package specifying that some class on model level is the end of an association works in the same way on the metamodel level. as we can see in figure 5, the ends of each association are properties of classes, i.e. we have to define another property that has to be an association end. trackelement is again used as an example: at each end of a trackelement, entry or exit sensors can be associated. 7 / 18 volume 5 (2006) ocl-based validation of a railway domain profile e1entry, e1exit, e2entry, and e2exit are used to model these ends of associations to sensors (optional). all outgoing associations must be sensorassociations: ownedattribute->one(a | a.name->includes(’e1entry’) and a.upperbound() = 1 and a.lowerbound() >= 0 and a.isreadonly = true and a.outgoingassociation. oclistypeof(sensorassociation)) or (not ownedattribute->exists(a2 | a2.name->includes(’e1entry’))) ... ownedattribute->collect(outgoingassociation)-> forall(a | a.oclistypeof(sensorassociation) or a.isundefined) similar constraints are defined for all network elements. they belong obviously to the category (a) as described in section 2. they restrict properties on the metamodel level for the usage on the model level. 4.3 associations three types of associations are defined: sensorassociations that connect track elements and sensors, signalassociations that connect signals and sensors, and autorunassociations that connect automatic train runnings and sensors (see figure 7(a)). constraints are needed e.g. to determine the kind of stereotype at the ends of each association and their number. as an example, each signalassociation is connected to one sensor and one signal: inv signalassociation1: memberend->size() = 2 inv signalassociation2: endtype->size() = 2 inv signalassociation3: endtype->one(t | t.ocliskindof(sensor)) inv signalassociation4: endtype->one(t | t.ocliskindof(signal)) similar constraints are defined for the other kinds of association. 4.4 instances of network elements and associations for each non-abstract modeling element and each association, there exists a corresponding instance stereotype (see figure 7(b)). here, the domain-specific notation is defined. in figure 6(a), two unidirectional segments connected by a sensor s1 are shown. for comparison, the same constellation in object notation is given in figure 6(b). s1 (a) exit e2exit s1:<>sens entrye1entry :<>seg:<>seg (b) figure 6: sensors in rcsd notation (a) and classical uml notation (b) the instances are heavily restricted by ocl constraints as the instance level serves as the basis for automated code generation. again, we find several constraints of category (a), where the values of properties are specified explicitly. to give an example, the maximal number of trains on a crossing or point is always defined and the value is 1: proc. oclapps 2006 8 / 18 eceasst slot->one(s1 | s1.definingfeature.name->includes(’maxnumberoftrains’) and s1.value->size()= 1 and s1.value->first().oclistypeof(literalinteger) and s1.value->first()->oclastype(literalinteger).value = 1) similar constraints appear for all kinds of track elements, e.g. the limit on track elements must have a value from n if present. more interesting are the constraints from category (b) that describe the dependencies between properties of one stereotype. as an example, each point has a plus and minus position. one of these has to be straight and the other one left or right : slot->select(s1 | s1.definingfeature.name->includes(’minus’) or s1.definingfeature.name->includes(’plus’))-> one(s2 | s2.value->size()= 1 and s2.value->first().oclistypeof(instancevalue) and s2.value->first().oclastype(instancevalue).instance.name-> includes(’straight’)) and slot->select(s1 | s1.definingfeature.name->includes(’minus’) or s1.definingfeature.name->includes(’plus’))-> one(s2 | s2.value->size()= 1 and s2.value->first().oclistypeof(instancevalue) and (s2.value->first().oclastype(instancevalue).instance. name->includes(’left’) or s2.value->first()->oclastype(instancevalue).instance. name->includes(’right’))) 0..1 sensorassociation <> 0..1 <> autorunassociation <> 0..1 signalassociation <> association (a) <> automaticrunninginstance 0..1 <> signalinstance <> autorunlink <> signallink <> sensorlink <> sensorinstance <> instancespecification 0..1 0..1 segmentinstance <> crossinginstance <> <> <> 0..1 0..1 0..1 singlepointinstance slippointinstance 0..1 0..1 0..1 0..1 (b) figure 7: associations (a) and instances of network elements and associations (b) parts of the rcsd profile 9 / 18 volume 5 (2006) ocl-based validation of a railway domain profile an example from category (c) are identification numbers of sensors that have to be unique. each sensor must have a property sensorid that is unique with respect to all instances of sensor: sensorinstance.allinstances->collect(slot)->asset->flatten-> select(s | s.definingfeature.name->includes(’sensorid’))-> iterate( s:slot; result:set(literalsensorid) = oclempty(set(literalsensorid)) | result->including(s.value->first.oclastype(literalsensorid)))-> isunique(value) 4.5 route definitions <> <> route <> 0..1 0..1 <> class signalsetting <> routeconflict pointposition 0..1 0..1 <> routeconflictkind <><> instancespecification routeinstance 0..1 noallocation stopsignal figure 8: route definition part of the rcsd profile moreover, the profile defines routes and their instances as shown in figure 8. each route is defined by an ordered sequence of sensors. the signal setting for entering the route and sets of required point positions and of conflicts with other routes are further necessary information. again, constraints are used for unambiguous and strict definitions of properties. constraints from category (d) are typical as sensors, signals, and points are referenced by their id in route definitions. this implies that these ids belong to some existing instances, e.g. the sensor ids given in the definition of a route. hence, the following constraint must hold for each routeinstance: let i:set(integer) = slot->select(s | s.definingfeature.name-> includes(’routedefinition’))->assequence->first().value-> iterate(v:valuespecification; result:set(integer)=oclempty(set(integer)) | result->including(v.oclastype(literalsensorid).value)) in i->forall(id | sensorinstance.allinstances->exists(sens | sens.slot->select(s | s.definingfeature.name-> includes(’sensorid’))->assequence->first().value->first(). oclastype(literalsensorid).value = id)) proc. oclapps 2006 10 / 18 eceasst 5 validation of wellformedness rules with use the next step is adapting the profile and its various invariants to use for the validation process. use expects a model in textual notation as input. for syntax details, we refer to [gz04]. in our case, this is the metamodel consisting of (a part of) the uml metamodel and the profile. on this basis, instance models can be checked with respect to the invariants in the metamodel. in our case, the instance model consists of both class layer and object layer, i.e. models using the rcsd profile. a similar application of use with respect to the four metamodeling layers of uml is shown in [gfb05]. this metamodel file includes both the necessary part of the uml 2.0 metamodel and the rcsd profile for two reasons: first, the profile cannot exist without its reference metamodel and second, one goal is to check the compliance of the profile to the metamodel. this task must be performed implicitly as use does not check if the given constraints contradict. instead, we assume the profile compliant to the metamodel as long as both the constraints in the metamodel and the constraints in the profile are all valid. contradicting constraints can be identified if all constraints in the profile evaluate to true but some constraint(s) in the metamodel evaluate(s) to false. 5.1 modeling the uml metamodel and the rcsd profile for use in the metamodel file, a description of classes with attributes and operations, associations, and ocl constraints is expected. ocl constraints are either invariants as shown in section 4, definitions of operations, or pre-and postconditions of operations. only operations whose return value is directly specified in ocl and not dependent on preconditions are considered side-effect free and may be used in invariants. for the validation of the profile, all invariants must be fulfilled by the instance model(s). from the uml metamodel, the kernel package has been modeled with some modifications: (a) packages are not needed by the rcsd profile and therefore skipped in all diagrams, diagram packages has been omitted completely. (b) lower and upper bounds of multiplicities have been changed to literalinteger instead of valuespecification for easier handling. one reason is that the invariants in the context of multiplicityelement are not specific enough to guarantee that the valuespecification really evaluates to literalinteger as necessary. therefore, expressions cannot be used to specify multiplicities. the invariants of multiplicityelement have been adapted to this. (c) several invariants and operations had to be rewritten or omitted completely as they are erroneous in the uml specification. more information about this problem can be found in [bgg04]. (d) some names in the uml specification had to be changed due to conflicts with use keywords or multiple usage in the specification which also leads to conflicts. this problem is also described in [bgg04]. (e) use does not support unlimitednatural as type. this problem has been overcome by using integer and additional constraints that restrict corresponding values to n. all in all, 34 invariants have been modeled here. further packages from the uml metamodel are not needed. profiles are not directly supported by use. this problem has been overcome by modeling each stereotype as a subclass from its metaclass, i.e. a metamodel extension. modeling profiles as restricted extensions to metamodels is feasible with respect to [jsz+04]. here, modifications 11 / 18 volume 5 (2006) ocl-based validation of a railway domain profile limit:integer[0..1] {readonly} maxnumberoftrains:integer=1 {readonly} tramcrossing <> <> tramsensor tramsegment <> limit:integer[0..1] {readonly} maxnumberoftrains:integer=1 {readonly} <> conflicts routeid:routeid {readonly} kind:routeconflictkind {readonly} signals <> sigstate:signalstatekind {readonly} signalid:signalid {readonly} dirstate:routekind[0..1] {readonly} points <> pointid:pointid {readonly} pointstate:pointstatekind {readonly} tramroute <> routeid:routeid {readonly} routedefinition:sensorid[0..*] {readonly, ordered} actualstate:signalstatekind requestedstate:signalstatekind delta_s:duration {readonly} signalid:signalid {readonly} requesttime:timeinstant direction:routekind <> tramsignal trampoint <> pointid:pointid {readonly} plus:pointstatekind {readonly} minus:pointstatekind {readonly} actualstate:pointstatekind requestedstate:pointstatekind requesttime:timeinstant limit:integer[0..1] {readonly} maxnumberoftrains:integer=1 {readonly} delta_p:duration {readonly} e4exit e3exit e2exit 0..1 1 11 actualstate:sensorstatekind senttime:timeinstant counter:integer delta_l:duration {readonly} delta_tram:duration {readonly} sensorid:sensorid {readonly} e2exit e2exit e1exit sensor e3entry e2entry e3entry e1entry e1entry e1entry 1 0..1 0..1 0..1 0..1 1 1 1 pointposrouteconflict signalsetting{readonly} 1 signal 0..1 0..* 0..* entryseg exitseg exitpointentrypoint {readonly} {readonly} entrycross exitcross 1 1 0..1 0..1 0..1 0..1 0..1 figure 9: tram network definitions class level to metamodels are classified in level one (all extensions to the reference metamodel allowed), level two (new constructs can be added to the referenced metamodel, but existing ones cannot be changed), level three (each new construct must have a parent in the reference metamodel), and level four (new relationships are only allowed as far as existing ones are specialized. the lower levels include all restrictions of the levels above. therefore, profiles can be considered a level four metamodel extension and modeled as such in use. 1 all in all, the following invariants of types (a) (d) have been specified: profile part (a) (b) (c) (d) types and literals 12 0 0 0 network elements 95 0 0 0 associations 27 0 0 0 instances 104 37 4 7 route definitions 36 1 3 22 total 274 38 7 29 1 [jsz+04] considers profiles as level three which is incorrect as the relationship restriction has to be respected by profiles. proc. oclapps 2006 12 / 18 eceasst 5.2 compliance of rcsd model to profile on class level evaluating constraints is possible for instances of the given (meta)model. as an example, a tram network description is used on class level. tram networks consist of segments, crossings, and single points that are all used unidirectionally. furthermore, there are signals, sensors, and routes, but no automatic runnings. this constellation is shown in figure 9. in use, an instance model can be constructed step by step by adding instances of classes and associations of the metamodel to an instance diagram. more convenient is the usage of a *.cmd command file where instance creation and setting of property values are specified in textual notation. again, we refer to [gz04] for syntax details. w100 s22−g21.1 g25.1 g24.1 tram maintenance site route 3: s21−g25.1 route 5: g25.0 route 0: s20−g21.1 s21−g23.1 route 2 g23.0 g23.1g20.0 g20.1 g21.0 g21.1 g22.1 route4: s22−g23.1 g22.9 g24.3g20.3g20.2 w102 w119 g22.3g22.2 w118 g22.0 g20.9 g20.8 w103 w101 g24.2 g22.9 g24.0 g30.1 g29.9 g30.0 s20−g25.1 route 1: s21 s20 s22 figure 10: concrete track network instance level 5.3 compliance of rcsd model to profile on instance level a concrete network of a tram maintenance site with six routes is shown in figure 10. note that this diagram is given in rcsd notation and can also be shown in uml object notation as discussed in section 4. the explicit route definitions have been omitted for the sake of brevity, but can be easily extracted from figure 10. this diagram has been used for the validation on the instance level. it consists of 12 segments, 3 crossings, 6 points, 25 sensors, 3 signals, and 6 routes, specified in a second *.cmd file. the two *.cmd files form a complete instance model of the metamodel consisting of classes and their instances. 5.4 results in this example, all invariants have been fulfilled. the correctness of the ocl constraints could be easily checked by adding intentional errors like incorrect association ends or signals with the 13 / 18 volume 5 (2006) ocl-based validation of a railway domain profile same id. use facilitates tracing of such errors by (a) showing which instance of the metamodel has violated an invariant and by (b) decomposing the invariant in all sub-clauses and giving the respective evaluation. in figure 11, we can see that sensor2 and sensor3 have duplicate identification numbers. figure 11: evaluation example two identical sensor ids for the validation process, some effort has to be made for the modeling part. fortunately, the metamodel and profile have to be modeled only once for each profile. the part of the uml metamodel that has to be included varies from profile to profile depending on the metaclasses references by stereotypes. the current version of the use model file consists of approximately 4000 lines. as this task is performed once per profile, the effort seems reasonable. with respect of the rcsd profile, the instance model on class level has to be modeled once per specific railway system, e.g. once for trams. with this part of the instance model, all kinds of concrete track layouts can be checked. the tram example consists of approximately 1500 lines of input data to use. these can be generated from class diagrams by parsing the output of case tools and adapting them to use. concrete track layout can also be generated, this time from object diagrams. in this way, all kinds of track layouts for one system can be checked. the example track layout needs about 5000 lines. as writing them for each layout would be an obnoxious task, automation is highly required. 6 related and future work at the moment, the rcsd profiles defines large parts of a domain-specific language for the railway control systems domain. on the one hand, there is the abstract and concrete syntax defined by uml diagrams as shown in the figures in section 4. on the other hand, there are static semantics defined by ocl constraints (see section 4) that allow us to validate rcsd models and use them as foundation for further tasks. proc. oclapps 2006 14 / 18 eceasst obviously, also behavioral semantics have to be defined. these are captured by a timed state transition system (tsts) that is based on a rcsd model and also incorporates the behavior of a controller which has to guarantee safety conditions for the running system. the behavior of the controller can be deduced from generic patterns that are derived from domain knowledge. the composition of the controller and the individual rcsd model should then allow only sequences of transitions which never violate a safety condition. a good example here is that a railway controller may never release two conflicting routes at the same time. more details about the tsts and the generic controller patterns can be found in [bh06, pghd04, pbd+05]. a tsts can be encoded in systemc [glms02] and used for verification purposes [gd03]. as described in [pghd04] and [pbd+05], the verification of the railway domain model can be performed by bounded-model checking as this technique overcomes the problem of state explosion usually occurring with other model checking techniques for railway control systems of realistic sizes. systemc models also serve as foundation for automated code generation of railway controller code. automated code generation and the verification of the generated code are ongoing work that is further described in [pbd+05]. an interesting point to investigate is automated test case generation. even if the correctness of model and generated code can be verified, tests have to be performed at least on hardwaresoftware integration level. this is unavoidable as the hardware integration may expose new kinds of errors that are caused by hardware configurations, memory handling, interface latencies, and similar problems that not present on model level. we expect that the selection of meaningful test cases will be improved significantly due to the domain-specific knowledge provided by rcsd models. currently, there are several approaches to model-based automated test case generation that could be adapted to the tsts. one example is presented in [dgg04]. test cases are chosen by traversing a graphical representation of the software under test. paths in the graph are chosen by statistical methods. another approach – based on timed automata – is presented in [co02]. here, heuristics have been developed to chose test cases from the infinitely many ones deduced from paths through the timed automata. both approaches – and also similar ones – share the same problem: it is not possible to ensure that all relevant test cases for the system under test have been found. for the railway domain, the domain knowledge can be taken into account with respect to test case generation algorithms. the object model in combination with safety conditions gives important information about the expected behavior of the controller under test. to give an example, we expect that all points assigned to a route have been switched to the requested position before the entry signal of the route is set to go. other examples are that conflicting routes may not be released at the same time or that only one train is allowed at most on a point at each point in time. the test case generation algorithm has to be aware of this information. at the moment two possibilities seem feasible. (a) test case generation is performed at object level based on route information and safety conditions specified in ocl. the needed test cases are then transfered to the systemc level where we can check if the model is sufficiently covered – dependent on some coverage criterion – and eventually more test cases have to be generated. (b) another possibility is to incorporate the domain-specific knowledge about relevant test cases into the systemc model as additional information. in this case, test case generation can be completely 15 / 18 volume 5 (2006) ocl-based validation of a railway domain profile performed on systemc level. at the moment, we examine the power of these two approaches. another advantage of using domain-specific knowledge in automated test case generation is that not only test cases but also meaningful documentation can be generated. this facilitates backtracking of occurring errors as we are able to follow the inputs to the controller under test and its outputs more easily. it is obviously more convenient to be aware that contradicting routes route 2 and route 4 have been requested and both released due to some error than reconstructing the meaning of the generated test case manually. moreover, the generation of use snapshots of rcsd object diagrams by each test, e.g. in a different log file, seems promising to facilitate error backtracking. as the behavior of the controller is derived from static semantics and safety conditions defined by ocl expressions, it is likely that errors occurring in tests are reflected in invariant violations. hence, we need a snapshot of an object diagram coinciding with the current system state. in this case, the violated invariant will give information about the cause of the error. the possibilities for using ocl constraints and use in error backtracking are also currently under investigation. 7 conclusion the validation of models of the rcsd profile and the profile itself based on ocl constraints with use has been proven useful in several ways. it has been shown that the profile complies to uml as it is required and that an example model for tramways is valid in the rcsd context. this makes object diagrams for such tramways applicable for transformation and verification purposes. another effect of the validation with use was the improvement of the ocl constraints themselves. as most case tools have no ocl support, it is hard to detect if constraints exhibit syntax errors or if complicated constraints really have the intended meaning. an adaption of the validation process to other profiles can be performed straightforward as the same kinds of constraints should appear. it is possible that the uml metamodel part has to be enhanced for other profiles as this depends on the metaclasses referenced by stereotypes. validation is reasonable for each profile whose application relies on a solid and unambiguous model. with respect to the rcsd profile, future work has to investigate the behavioral aspects of track layouts as described in section 6. at the moment, only statical aspects have been examined, but use can also be applied to the validation and test of controllers that have been generated for a concrete track network. at any rate, verification, automated code generation, and automated test case generation based on rcsd models seem to be promising approaches to improve the development process of railway control systems and their verification. first results also show the impact of domain-specific languages as the domain-specific knowledge covered in such models influences further usage of models as e.g. in automated test case generation significantly. acknowledgements: special thanks go to fabian büttner and arne lindow for their help with use and to ulrich hannemann and jan peleska for their valuable feedback to the first versions of this paper and the related work. proc. oclapps 2006 16 / 18 eceasst bibliography [bcc+05] t. baar, d. chiorean, a. correa, m. gogolla, h. hußmann, o. patrascoiu, p. h. schmitt, j. warmer. tool support for ocl and related formalisms needs and trends. in bruel (ed.), satellite events at the models‘2005 conference. lncs 3844, pp. 1–9. springer-verlag, 2005. doi:10.1007/11663430 1 [bgg04] h. bauerdick, m. gogolla, f. gutsche. detecting ocl traps in the uml 2.0 superstructure. in baar et al. (eds.), proceedings 7th international conference unified modeling language (uml’2004). lncs 3273, pp. 188–197. springer, 2004. doi:10.1007/b101232 [bh06] k. berkenkötter, u. hannemann. modeling the railway control domain rigorously with a uml 2.0 profile. in górski (ed.), computer safety, reliability, and security, safecomp 2006. lncs 4166, pp. 398–411. springer, 2006. doi:10.1007/11875567 [bhp] k. berkenkötter, u. hannemann, j. peleska. the railway control system domain. draft. http://www.informatik.uni-bremen.de/agbs/research/rcsd/ [co02] r. cardell-oliver. conformance test experiments for distributed real-time systems. in olderog and steffen (eds.), international symposium on software testing and analysis (issta’02). acm press 1710, pp. 159–163. july 2002. doi:10.1145/566172.566196 [dgg04] a. denise, m.-c. gaudel, s.-d. gouraud. a generic method for statistical testing. issre 15th international symposium on software reliability engineering, pp. 25– 34, 2004. doi:http://doi.ieeecomputersociety.org/10.1109/issre.2004.2 [eva06] a. evans. domain specific languages and mda. 2006. http://albini.xactium.com/web/downloads/b1a35960appliedmetamodelling.pdf [gd03] d. große, r. drechsler. formal verification of ltl formulas for systemc designs. in ieee international symposium on circuits and systems. pp. v:245–v:248. 2003. http://ieeexplore.ieee.org/search/wrapper.jsp?arnumber=1206243 [gfb05] m. gogolla, j.-m. favre, f. büttner. on squeezing m0, m1, m2, and m3 into a single object diagram. technical report lgl-report-2005-001, ecole polytechnique fédérale de lausanne, 2005. http://www.db.informatik.uni-bremen.de/publications/gogolla 2005 oclws.ps [glms02] t. grötker, s. liao, g. martin, s. swan. system design with systemc. kluwer academic publishers, 2002. 17 / 18 volume 5 (2006) http://dx.doi.org/10.1007/11663430_1 http://dx.doi.org/10.1007/b101232 http://dx.doi.org/10.1007/11875567 http://www.informatik.uni-bremen.de/agbs/research/rcsd/ http://dx.doi.org/10.1145/566172.566196 http://dx.doi.org/http://doi.ieeecomputersociety.org/10.1109/issre.2004.2 http://albini.xactium.com/web/downloads/b1a35960appliedmetamodelling.pdf http://ieeexplore.ieee.org/search/wrapper.jsp?arnumber=1206243 http://www.db.informatik.uni-bremen.de/publications/gogolla_2005_oclws.ps ocl-based validation of a railway domain profile [omg03] object management group. mda guide version 1.0.1. june 2003. http://www.omg.org/docs/omg/03-06-01.pdf [omg05a] object management group. ocl 2.0 specification, version 2.0. june 2005. http://www.omg.org/docs/ptc/05-06-06.pdf [omg05b] object management group. unified modeling language: superstructure, version 2.0. july 2005. http://www.omg.org/docs/formal/05-07-04.pdf [omg05c] object management group. unified modeling language (uml) specification: infrastructure, version 2.0. july 2005. http://www.omg.org/docs/ptc/04-10-14.pdf [omg06] object management group. meta object facility (mof) 2.0 core specification. jan. 2006. http://www.omg.org/docs/formal/06-01-01.pdf [gz04] m. gogolla, p. ziemann. checking bart test scenarios with uml’s object constraint language. pp. 133–170. kluwer, boston, 2004. http://www.db.informatik.uni-bremen.de/publications/gogolla 2004 kluwer.ps [jsz+04] y. jiang, w. shao, l. zhang, z. ma, x. meng, h. ma. on the classification of uml’s meta model extension mechanism. in baar et al. (eds.), the unified modelling language: modelling languages and applications. lncs 3273, pp. 54–68. springer, 2004. doi:10.1007/b101232 [pac02] j. pachl. railway operation and control. vtd rail publishing, mountlake terrace (usa), 2002. isbn 0-9719915-1-0. [pbd+05] j. peleska, k. berkenkötter, r. drechsler, d. große, u. hannemann, a. e. haxthausen, s. kinder. domain-specific formalisms and model-driven development for railway control systems. in train workshop at sefm2005. september 2005. http://www.informatik.uni-bremen.de/agbs/jp/papers/peleska et al train2005 slides.pdf [pghd04] j. peleska, d. große, a. e. haxthausen, j. r. drechsler. automated verification for train control systems. in schnieder and tarnai (eds.), forms/format 2004 formal methods for automation and safety in railway and automotive systems. pp. 252–265. technical university of braunschweig, 2004. http://www.informatik.uni-bremen.de/agbs/jp/papers/peleska et al forms2004.ps [ric02] m. richters. a precise approach to validating uml models and ocl constraints. biss monographs 14. logos verlag, berlin, 2002. ph.d. thesis, universität bremen. [wk04] j. warmer, a. kleppe. object constraint language 2.0. mitp-verlag, bonn, 2004. proc. oclapps 2006 18 / 18 http://www.omg.org/docs/omg/03-06-01.pdf http://www.omg.org/docs/ptc/05-06-06.pdf http://www.omg.org/docs/formal/05-07-04.pdf http://www.omg.org/docs/ptc/04-10-14.pdf http://www.omg.org/docs/formal/06-01-01.pdf http://www.db.informatik.uni-bremen.de/publications/gogolla_2004_kluwer.ps http://dx.doi.org/10.1007/b101232 http://www.informatik.uni-bremen.de/agbs/jp/papers/peleska_et_al_train2005_slides.pdf http://www.informatik.uni-bremen.de/agbs/jp/papers/peleska_et_al_train2005_slides.pdf http://www.informatik.uni-bremen.de/agbs/jp/papers/peleska_et_al_forms2004.ps introduction uml profiles and ocl short introduction to the railway domain rcsd profile types and literals network elements associations instances of network elements and associations route definitions validation of wellformedness rules with use modeling the uml metamodel and the rcsd profile for use compliance of rcsd model to profile on class level compliance of rcsd model to profile on instance level results related and future work conclusion improving the search capabilities of a cflp(fd) systemthis work has been partially supported by the spanish projects tin2013-44742-c4-3-r, tin2008-06622-c03-01, ucm-bsch-gr58/08-910502, and s2009tic-1465 electronic communications of the easst volume 64 (2013) proceedings of the xiii spanish conference on programming and computer languages (prole 2013) improving the search capabilities of a cflp(fd) system ignacio castiñeiras, fernando sáenz-pérez 18 pages guest editors: clara benac earle, laura castro, lars-åke fredlund managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst improving the search capabilities of a cflp(fd) system∗ ignacio castiñeiras1, fernando sáenz-pérez2 1 ncasti@fdi.ucm.es dept. sistemas informáticos y computación universidad complutense de madrid, spain 2 fernan@sip.ucm.es, http://www.fdi.ucm.es/profesor/fernan dept. ingenierı́a del software e inteligencia artificial universidad complutense de madrid, spain abstract: the cflp system t oy (f d) is implemented in sicstus prolog, and supports f d constraints by interfacing the cp(f d ) solvers of gecode and ilog solver. in this paper, t oy (f d) is extended with new search primitives in a setting easily adaptable to other prolog clp or cflp systems. the primitives are described from a solver-independent point of view, pointing out some novel concepts not directly available in the gecode and ilog solver libraries. also, we describe how to specify some search criteria at t oy (f d) level and how easily these strategies can be combined to set different search scenarios. the implementation of the primitives is described, presenting an abstract view of the requirements and how they are targeted to the gecode and ilog libraries. finally, some benchmarks show that the new search strategies actually improve the solving performance of t oy (f d). keywords: cflp, fd search strategies, solver integration 1 introduction the use of ad hoc search strategies has been identified as a key point for solving constraint satisfaction problems (csp’s) [tsa93], allowing the user to interact with the solver in the search of solutions (exploiting its knowledge about the structure of the csp and its solutions). different paradigms provide different expressivity for specifying search strategies: constraint logic programming clp(f d ) [jm94] and constraint functional logic programming cflp(f d ) [han07] provide a declarative view of this specification, in contrast to the procedural one offered by constraint programming cp(f d ) [ms98] systems (which make the programming of a strategy to depend on low-level details associated to the constraint solver, and even on the concrete machine the search is being performed). also, due to their model reasoning capabilities, clp(f d ) and cflp(f d ) treat search primitives as simple expressions, making possible to place a search primitive at any point of the program, combine several primitives to develop complex search heuristics, intermix search primitives with constraint posting, and use non-determinism to apply different search scenarios for solving a csp. ∗ this work has been partially supported by the spanish projects tin2013-44742-c4-3-r, tin2008-06622-c03-01, ucm-bsch-gr58/08-910502, and s2009tic-1465 1 / 18 volume 64 (2013) mailto:ncasti@fdi.ucm.es mailto:fernan@sip.ucm.es http://www.fdi.ucm.es/profesor/fernan improving the search capabilities of a cflp(fd) system1 the main contribution of this paper is to present a set of search primitives for clp(f d ) and cflp(f d ) systems implemented in prolog, and interfacing external cp(f d ) solvers with a c++ api. the motivation of this approach is to take advantage of the high expressivity of clp(f d ) and cflp(f d ) for specifying search strategies, and of the high efficiency of cp(f d ) solvers. the paper focuses on the cflp(f d ) system t oy (f d) [fhsv07], more precisely in the system versions t oy (f d g) and t oy (f d i) [cs12] which interface the external cp(f d ) solvers (with c++ api) of gecode 3.7.3 [gec] and ibm ilog solver 6.8 [ilo10], respectively. regarding search, t oy (f d) offers two possibilities up to now. first, defining a new search from scratch at t oy (f d) level (using reflection functions to represent the search procedure). second, use the search primitive labeling, which simply relies on predefined search strategies already existing in gecode and ilog, respectively. the use of external cp(f d ) solvers (with c++ api) opens a third possibility, which is exploited in this work: enhancing the search language of t oy (f d g) and t oy (f d i) with new parametric search primitives, which are implemented in gecode and ilog by extending their underlying search libraries. the paper is organized as follows: section 2 presents a brief introduction to t oy (f d). section 3 presents an abstract description of the new t oy (f d) search primitives. it points out some novel concepts not directly available in gecode and ilog solver libraries. it also describes how to specify some search criteria at t oy (f d) level, and how easily these strategies can be combined to set different search scenarios. section 4 describes the implementation of the primitives in t oy (f d), presenting an abstract view of the requirements, and how they are targeted to the gecode and ilog libraries. section 5 presents some benchmarks, showing that the use of the search strategies improve the solving performance of both t oy (f d g) and t oy (f d i). section 6 presents some related work. finally, section 7 presents some conclusions and future work. 2 the t oy (f d) system t oy (f d) (available at http://gpd.sip.ucm.es/ncasti/toy(fd).zip) is implemented in sicstus prolog [sic]. it supports the solving of syntactic equalities and disequalities (via a host herbrand solver: h ), and of f d constraints (via a connected cp(f d ) solver). the t oy compiler uses sicstus prolog as an object language [llr93]. its declarative semantics is based on a conditional term-rewriting logic: crwl [ghlr99], and its operational semantics on a constraint lazy narrowing calculus: clnc(f d ) [lrv04]. a t oy (f d) program consists of a set of data constructors and a set of functions, that can be higher-order and non-deterministic (with possibly several reductions for given, even ground, arguments). the syntax is mostly borrowed from haskell [pj02], with the remarkable exception that program and type variables begin with upper-case letters whereas data constructors, types and functions begin with lower-case. the repertoire of f d constraints and operators is presented in table 1, also including == and /=, as they are truly polymorphic (with the same operators for h and f d ). the two syntactic domains patterns and expressions must be distinguished. whereas an expression is susceptible of being reduced by the rules of the functions defined in the program, a proc. prole 2013 2 / 18 http://gpd.sip.ucm.es/ncasti/toy(fd).zip eceasst type constraints and operators relational constraints ==, /=, #>, #>=, #<, #<= arithmetic operators #+, #-, #*, #/ propositional constraints post implication domain constraint domain, domain valarray global constraints all different, count, sum, scalar product table 1: repertoire of f d constraints and operators pattern denotes a data value not subject of further evaluation (this includes variables, constants, data constructors and partial application of functions). a (user-)defined function is characterized by an optional principal type, which is checked/inferred by the system, and by a set of constrained rewriting rules f t1 ...tn =e ⇐= l1 ==r1,...,lk ==rk where t1,...,tn form a tuple of linear patterns (i.e., with no repeated variables), and e,li,ri are expressions. rules have a conditional reading: f t1 ...tn can be reduced to e if all the constraints l1 == r1, ..., lk == rk are satisfied. for the case of non-deterministic functions, rules are applied following their textual order, and both failure and user request for a new solution trigger backtracking to the next unexplored rule. a t oy (f d) goal consists of a set of constraints. goal solving follows lazy narrowing: if a constraint is either an equality/disequality herbrand constraint between patterns or a primitive finite domain constraint, then it is directly posted to its corresponding solver. otherwise, the arguments of the constraint being expressions are lazily evaluated, applying matching function rules. this transforms the initial constraint into a primitive one, possibly producing more primitive or composed constraints to be processed. once all the constraints of the goal have been processed, a t oy (f d) solution consists of the simplified h and f d constraint stores. 3 search primitives this section presents eight new t oy (f d) primitives for specifying search strategies, allowing the user to interact with the solver in the search for solutions. each primitive is presented from an abstract (solver independent) point of view, emphasizing some novel search concepts they provide. the specification of some search criteria at t oy (f d) level and the combination of primitives (to specify complex search strategies) are also presented. 3.1 labeling primitives in this section, four search primitives are described: lab, labb, labw and labo. primitive lab lab :: varord -> valord -> int -> [int] -> bool this primitive collects (one by one) all possible combinations of values satisfying the set of constraints posted to the solver. it is parameterized by four basic components. the first and second ones represent the variable and value order criteria to be used in the search strategy, respectively. 3 / 18 volume 64 (2013) improving the search capabilities of a cflp(fd) system2 myvarorder:: [int] -> int myvarorder v = fst (foldl cmp (0,0) (zip (take (length v) (from 0)) (map (length . get_dom) v))) % myvalorder:: [[int]] -> int | from:: int -> [int] myvalorder d = head (last d) | from n = [n | from (n+1)] % cmp:: (int,int) -> (int,int) -> (int,int) cmp (i1,v1) (i2,v2) = if (v1 >= v2) then (i1,v1) else (i2,v2) ---------------------------------------------------------------toy(fd)> domain [x,y,z] 0 4, y /= 1, y /= 3, z /= 2, lab uservar userval 2 [x,y,z], ... (rest of goal) figure 1: variable and value user-defined criteria to express them we have defined in t oy the enumerated datatypes varord and valord, covering all the predefined criteria available in the gecode documentation [stl13]. they also include a last case (uservar and userval, respectively) in which the user implements its own variable/value selection criteria at t oy (f d) level. the third element n represents how many variables of the variable set are to be labeled. this represents a novel concept which is not available in the predefined search strategies of gecode and ilog solver. the fourth argument represents the variable set s. thus, the search heuristic uses varord to label just n variables of s. figure 1 presents a t oy (f d) program (top) and goal (bottom) showing how expressive, easy and flexible is to specify a search criteria in t oy (f d). in the example, the search strategy of the goal uses the uservar and userval selection criteria (specified by the user in the functions myvarorder and myvalorder, respectively). the lab search strategy is applicable to the constraint network posted by the t oy (f d) goal domain [x,y,z] 0 4, y /= 1, y /= 3, z /= 2. then, the computation continues by processing the “rest of goal” for each feasible solutions found by the lab strategy. it acts over the set of variables [x,y,z], but it is only expected to label two of them. the function myvarorder selects first the variable with more intervals in its domain. it receives the list of variables involved in the search strategy, returning the index of the selected one. to this end, it uses the auxiliary functions from and cmp; the predefined functions fst, foldl, zip, take, length, map, head, last and (.) (all of them with an equivalent semantics to those of haskell); and the reflection function get dom, which accesses the internal state of the solver to obtain the domain of a variable (this domain is presented as a list of lists, where each sublist represents an interval of values). the function myvalorder receives as its unique argument the domain of the variable, returning the lower bound of its upper interval. so, in conclusion, the first two solutions obtained by the lab strategy are: {x in 0..4, y -> 4, z -> 3} and {x in 0..4, y -> 4, z -> 4}. primitive labb labb :: varord -> valord -> int -> [int] -> bool proc. prole 2013 4 / 18 eceasst this primitive uses the same four basic elements as lab. however, its behavior is different, as it follows the varord and valord criteria to explore just one branch of the search tree, with no backtracking allowed. the 4-queens problem is used to explain this behavior. using lab unassignedleftvar smallestval 0 [x1,x2,x3,x4] (where 0 in the third argument stands for labeling all the variables) two solutions are obtained: {x1 -> 1, x2 -> 3, x3 -> 2, x4 -> 4} and {x1 -> 2, x2 -> 4, x3 -> 1, x4 -> 3}. however, if labb unassignedleftvar smallestval 0 [x1,x2,x3,x4] is used, then the strategy fails, getting no solutions. figure 2 (4×4 square board and tree) shows the computation process. first, the selected criteria assigns x1 -> 1 at root node (1), leading to node 2. propagation reduces the search space to {x2 in 3..4, x3 in 2 ∨ 4, x4 in 2..3}, pruning nodes 3 and 4. then, computation assigns x2 -> 3 (leading to node 5), and propagation leads to an empty domain for x3. so, the explored tree path leads to no solutions as well as, therefore, its computation. as it is seen, propagation during search modifies the intended branch to be explored (in the goal example, it explores the branch 1-2-5 instead of 1-2-3). primitive labw labw :: varord -> bound -> int -> [int] -> bool this primitive performs an exhaustive breadth exploration of the search tree, storing the satisfiable leaf nodes achieved to further sort them by a specified criteria. a first example is considered to understand the behavior of labw. figure 3 presents a t oy (f d) goal with four variables, where two implication constraints relate x and y with v1 and v2, respectively. if lab unassignedleftvar smallestval 2 [x,y,v1,v2] strategy had been used (instead of the labw one) to label the first two unbound vars of [x,y,v1,v2], then the search would have explored the search tree obtaining (one by one) the next four feasible solutions: {x -> 0, y -> 0}, {x -> 0, y -> 1}, {x -> 1, y -> 0} and {x -> 1, y -> 1}. figure 4 represents the exploration for obtaining those solutions, where each black node represents a solution, and the triangle it has below represents the remaining size of the search space (product of cardinalities of v1 and v2). as it is seen, whereas the first solution computed by lab leads to compute the “rest of goal” from a 12 candidates search space, the third solution leads to a 6 candidates one. the primitive labw explores exhaustively the search tree in breadth, storing in a data structure ds each feasible node leading to a solution. once the tree has been completely explored, the solutions are obtained (one by one) by using a criteria to select and remove the best node from ds. in the example, the selected criteria smallestsearchtree selects first the node with smaller product of cardinalities of v1 and v2 (returning first the solution of the 6 candidates). the order in which the labw strategy of the goal delivers the solutions 2 3 5 6 1 4 board figure 2: applying labb to the queens problem 5 / 18 volume 64 (2013) improving the search capabilities of a cflp(fd) system3 toy(fd)> domain [x,y] 0 1, post_implication x (#=) 1 v1 (#>) 1, domain [v1,v2] 0 3, post_implication y (#=) 0 v2 (#>) 0, labw unassignedleftvar smallestsearchtree 2 [x,y,v1,v2], ... (rest of goal) figure 3: labw example is presented in figure 4. coming back to the definition of labw, the first parameter represents the variable selection criteria (no value selection is necessary, as the search would be exhaustive for all the values of the selected variables). the second parameter represents the best node selection criteria. to express it in t oy (f d), the enumerated datatype ord has been defined, ranging from the smallest/largest remaining search space of the product cardinalities of the labeling/solver-scope variables. again, a last case (userbound) allows to specify the bound criteria at t oy (f d) level. the third parameter sets the breadth level of exhaustive exploration of the tree (represented as a horizontal black line in figure 4). finally, as usual, the last parameter is the set of variables to be labeled. figure 5 presents a t oy (f d) program (top) and goal (bottom) with a bound criteria specified in the user function mybound. the best node procedure selection traverses all the obtained nodes in ds, selecting first the one with minimal bound value. in this context, the user criteria specified in mybound assigns to each node (minus) the number of its singleton value search variables. once again, the function mybound also relies on auxiliary, predefined and reflection functions. the first two obtained solutions are {x -> 1, y -> 1, a -> 0, b -> 0, c -> 0} and {x -> 2, y -> 1, a in 0..1, b -> 0, c -> 0}, respectively. in summary, labw represents a novel concept which is not available in the predefined search strategies of gecode and ilog solver. however, it must be used carefully, as exploring the tree very deeply can lead to a explosion of feasible nodes, producing memory problems for ds and becoming very inefficient (due to the time spent on exploring the tree and selecting the best node). primitive labo labo :: opttype -> varord -> valord -> int -> [int] -> bool this primitive performs a standard optimization labeling. the first parameter opttype contains the optimization type (minimization/maximization) and the variable to be optimized. the other four parameters are the same as in the lab primitive. 1st 2nd3rd 4th x = 0 x = 1 y = 0 y = 0 y = 1 y = 1 6 8 12 16 figure 4: labw search tree exploration proc. prole 2013 6 / 18 eceasst 3.2 fragmentize primitives frag :: domfrag -> varord -> intervalord -> int -> [int] -> bool fragb:: domfrag -> varord -> intervalord -> int -> [int] -> bool fragw:: domfrag -> varord -> bound -> int -> [int] -> bool frago:: domfrag -> opttype->varord->intervalord->int->[int]-> bool these four new primitives are mate to the labeling ones, but each variable is not labeled (bound) to a value, but fragmented (pruned) to a subset of the values of their domain. an introductory example is used to motivate the usefulness of these new primitives: a goal contains v variables and c constraints, with v’≡{v1, v2, v3} a subset of v. the constraint domain v’ 1 9 belongs to c. and no constraint of c relates the variables of v’ by themselves, but some constraints relate v’ with the rest of variables of v. figure 6 presents the search tree exploration achieved by frag* and lab* search primitives, respectively, where search nodes have been numbered. in the case of frag*, the three variables of v’ have been fragmented into the intervals (1,...,3), (4,...,6) and (7,...,9), leading to exponentially less leaf nodes (27) than the lab* exploration (729). on the one hand, if it is known that there is only one solution to the problem, the probabilities of finding the right combination of v’ values is thus bigger in frag* than in lab*. on the other hand, the remaining search space of the leaf nodes of lab* are expected to be exponentially smaller than the ones of frag*, due to the more propagation in v’ (also expecting to lead to more pruning in the rest of variables v). thus, the frag* search strategies can be seen as a more conservative technique, where there are less expectations of highly reducing the search space, as variables are not bound, but there is more probability of choosing a subset containing values leading to solutions (in what can be seen as a sort of generalization of first-fail). coming back to the definition of each frag* primitive, two main differences arise w.r.t. its mate lab* primitive: first, it contains as an extra basic component (first argument) the datatype domfrag, which specifies the way the selected variable is fragmented. the user can choose between partition n and intervals. the former fragments the domain values of the variable into n subsets of the same cardinality. the latter looks for already existing intervals on the domain of the variables, splitting the domain on them. for example, in the goal domain [x] 0 16, x /= 9, x /= 12 whereas applying partition 3 to x fragments the domain in the subsets s1≡{0...4}, s2≡{5...8}∪{10} and s3 ≡{11}∪{13...16}, applying intervals fragments the domain in the subsets s1’ ≡ isbound:: [[int]] -> bool isbound [[a,a]] = true isbound [[a,b]] = false <== b /= a isbound [[a,b] | rl] = false <== length rl > 0 % mybound:: [int] -> int mybound v = (length (filter isbound (map get_dom v))) --------------------------------------------------------toy(fd)> domain [x,y] 1 2, domain [a,b,c] 0 5, a #< x, b #< y, c #< y, labw unassignedleftvar userbound 2 [x,y,a,b,c] figure 5: bound user-defined criteria 7 / 18 volume 64 (2013) improving the search capabilities of a cflp(fd) system4 … … v3 1 1 2 3 5 9 6 1 4 16 18 27 17 … … 1 81 1 9 v3 v2 v1 729 1 450 v1 v2 figure 6: frag vs. lab search tree {0...8}, s2’ ≡ {10...11} and s3’ ≡ {13...16}. as a second difference, it contains an enumerated datatype intervalord (replacing the lab* argument valord), to specify the order in which the different intervals should be tried: first left, right, middle or random interval. in summary, it is claimed that frag* primitives are an remarkable tool, to be taken into account in the context of search strategies as an alternative or a complement to the use of exhaustive labelings. also, its use in t oy (f d) represents a novel concept which is not available in the predefined search strategies of gecode and ilog solver. 3.3 applying different search scenarios the use of t oy (f d) non-deterministic functions allows to sequentially apply different search strategies for solving a problem. for example, after posting v and c to the solver, the t oy (f d) program (top) and goal (bottom) presented in figure 7 uses the non-deterministic function f to specify three different scenarios for the solving of the goal described in section 3.2. each scenario ends with an exhaustive labeling of the set of variables v. however, the search space s this exhaustive labeling has to explore can be highly reduced by the previous evaluation of f. scenario 1: the first rule of f performs the search heuristic h1 over v’ ≡{v1,v2,v3}. h1 fragments the domain of v1 into 4 subsets, selecting one randomly. if propagation succeeds, then h1 bounds v2 and v3 to their smallest value. if propagation succeeds (with a remaining search space s1), then h1 succeeds, and the exhaustive labeling explores s1. if propagation fails in one of those points, or the exhaustive labeling does not find any solution in s1, then h1 completely fails f:: [int] -> bool f [v1,v2,v3] = true <== fragb (partition 4) unassignedleftvar random 0 [v1], labb unassignedleftvar smallestval 0 [v2,v3] f [v1,v2,v3] = true <== fragw (partition 4) unassignedleftvar smallesttree 0 [v1], labb unassignedleftvar smallesttotalvars 0 [v2,v3] f [v1,v2,v3] = true -------------------------------------------toy(fd)> post of (v,c), f v’, lab uservar userval 0 v figure 7: applying different search strategies proc. prole 2013 8 / 18 eceasst (as well as the first rule of f), as both the labb and fragb primitives just explore one branch. scenario 2: the second rule of f is tried, performing the heuristic h2 over v’. here a fragw primitive is first applied. so, if further either labb of h2 or the exhaustive lab (acting over s2) fails, backtracking is performed over fragw, providing the next best interval of v1 (according to the smallest search tree criteria, as in figure 4). if, after trying all the intervals a solution is not found, then h2 completely fails (as well as the second rule of f). scenario 3: if both h1 and h2 fail, the third rule of f trivially succeeds, and the exhaustive labeling is performed over the original search space obtained after posting v and c to the solver. 4 implementing the search primitives the implementation of the eight new search primitives is based on the gecode and ilog solver underlying search mechanisms. first, an abstract specification of the requirements the new t oy (f d) search strategies must fulfill is presented. then, it is described how to adapt those requirements to gecode and ilog solver. 4.1 abstract specification of the search strategy a single entry point (c++ function) for the different primitives is specified. its proposed algorithm is parameterizable by the primitive type and its basic components. it is described as follows: 1. the algorithm explores the tree by iteratively selecting a variable var and a value v, creating two options: (a) post var == v. (b) post var /= v to continue the exploration taking advantage of the previously explored branch, recursively selecting another value to perform again (a) and (b). 2. for frag* strategies it selects an interval i instead of a value, posting in (a) both var #>= i.min and var #<= i.max. however, the (b) branch can not take advantage by posting var #< i.min and var #> i.max, as the constraint store would become inconsistent. thus, (b) just removes i from the set of intervals, and continue the search by selecting a new interval. 3. for labb and fragb strategies, only the (a) option is tried. 4. for labo and frago strategies, branch and bound techniques are used to optimize the search. 5. specific functions are devoted to variable and value/interval selection strategies, as well as to the bound associated to a particular solution found by labw and fragw. those functions include the possibility of accessing prolog, to follow the criteria the user has specified at t oy (f d) level (using t oy (f d) functions which are compiled to mate prolog predicates). 6. the primitives labw and fragw perform the breadth exploration of the upper levels of the search tree, storing all the satisfiable leaf nodes to further provide them (one by one) 9 / 18 volume 64 (2013) improving the search capabilities of a cflp(fd) system5 on demand. thus, ss contains an entity performing the search and a vector ds (cf. section 3.2) containing the solutions. the notion of solution is abstracted as the necessary information to perform the synchronization from ss to the main constraint solver. also, a status indicates whether the exploration has finished or not. 7. the algorithm finishes (successfully) as it founds a solution, except for labw and fragw strategies, where it stores the solution node and triggers an explicit failure, continuing the breadth exploration of the tree. 8. a counter is used to control that only the specified amount of variables of the variable set is labeled/pruned. next two sections adapt this specification to gecode and ilog solver, respectively. table 2 summarizes the different notions provided by both libraries. 4.2 gecode search strategies in gecode are specified via branchers, which are applied to the constraint solver (space) to define the shape of the search tree to be explored. the space is then passed to a search engine, whose execution method looks for a solution by performing a depthfirst search exploration of the tree. this exploration is based on cloning spaces (two spaces are said to be equivalent if they contain equivalent stores) and hybrid recomputation techniques to optimize the backtracking. as spaces constitute the nodes of the search tree, a solution found by the search engine is a new space. the library allows to create a new class of brancher by defining three class methods: status, which specifies if the current node is a solution, or their children must be generated to continue with their exploration; choice, which generates an object o containing the number of children the node has, as well as all the necessary information to perform their exploration; commit, which receives o and the concrete children identifier to perform its exploration (generating a new space to be placed at that node). adaptation to the specification. the search strategies are implemented via two layers. first, a new class of brancher mygenerate, which carries out the tree exploration by the combination of the status, choice and commit methods. as each node of the tree is a space, the methods are applied to it. second, a search engine, controlling the search by receiving the search concept gecode ilog solver search trigger search engine ilogoal stack tree node space ilogoal attributes node exploration brancher commit ilogoal execution child generation brancher choice ilogoal constructor solution check brancher status stack with no iloand solution abstraction space tree path (var,value) vector table 2: different search concept abstractions in gecode and ilog solver proc. prole 2013 10 / 18 eceasst initial space and making the necessary clones to traverse the tree. in this setting, the abstract description presented before is instantiated to gecode as follows: 1. the choice method deals with the selection of the variable var and the value v, creating an object o with them as parameters, as well as the notion of having two children. the variable selection must rely on an external register r, being controlled by the search engine and thus independent on the concrete node (space) the choice method is working with. the register is necessary to ensure that, whether a father generates its right hand child by posting var /= v, this child will reuse r to select again var (as a difference to the left hand child, which removes the r content to select a new variable). 2. for frag* strategies, instead of passing val to o, the choice method generates a vector with all the different intervals to be tried, and the size of this vector is passed as its number of children. 3. for labb and fragb, only one child is considered. 4. for labo and frago, a specialized branch and bound search engine provided by gecode is used. 6 the search entity is the search engine and the solution is a space. 7 for labw and fragw, the search engine uses a loop, requesting solutions one by one until no more are found (the breadth exploration of the search tree has finished). 8 only the left hand child of lab* strategies increments the counter value, and the status method checks the counter to stop the search at the precise moment. 4.3 ilog solver search strategies in ilog solver are performed via the execution of ilogoals. an ilogoal is a daemon characterized by its constructor and its execution method. the constructor creates the goal, initializing its attributes. the execution method triggers the algorithm to be processed by the constraint solver (ilosolver), and can include more calls to goal constructors, making the algorithm processed by ilosolver to be the consequence of executing several ilogoals. an ilogoal fails if ilosolver becomes inconsistent by running its execution method; otherwise the goal succeeds. the library allows to create a new class of ilogoal by defining its constructor and execution method. four basic goal classes are provided for developing new goals with complex functionality. goals ilcgoaltrue and ilcgoalfalse make the current goal succeed and fail, respectively. goals ilcand and ilcor, both taking two subgoals as arguments, make the current goal succeed depending on the behavior of its subgoals. while ilcand succeeds only if its two subgoals succeed, ilcor creates a restorable choice point which executes its first subgoal, restores the solver state at the choice point on demand, and executes its second subgoal. adaptation to the specification. the search strategies are implemented via the new ilogoal classes mygenerate and myinstantiate. whereas the former deals with the selection of a 11 / 18 volume 64 (2013) improving the search capabilities of a cflp(fd) system6 variable, the latter deals with its binding/prunning to a value/interval. in this setting, the abstract description presented before is instantiated to ilog solver as follows: 1. the control of the tree exploration is carried out by mygenerate, which selects a variable and uses the recursive call ilcand(myinstantiate, mygenerate) to bind it and further continue processing a new variable. in myinstantiate, the alternatives (a) and (b) are implemented with ilcor(var == val, ilcand( var /= var, myinstantiate)). 2. it dynamically generates a vector with the available intervals on each different mygenerate call. 3. only the goal var == val is tried. 4. the branch and bound is explicitly implemented. thus, before selecting each new variable, it is checked if the current optimization variable can improve the bound previously obtained; otherwise an ilogoalfail is used to trigger backtracking (as well as if, after labeling the required variables, the obtained solution does not bind the optimization variable). 6 the entity performing the search is an ilosolver. also, a solution is represented by a vector of integers (representing the indexes of the labeled/pruned variables) and a vector of pairs, representing the assigned value or bounds of these variables. this explicit solution entity is built towards the recursive calls of mygenerate, which adds on each call the index of the variable being labeled. once found the solution, it stores it in ds. 7 after storing a solution in labw or fragw, an ilogoalfalse is used, triggering backtracking to continue the breadth exploration. 8 each call to mygenerate increments the counter value. 5 performance this section analyzes the new performance achieved by t oy (f d g) and t oy (f d i). the benchmark includes four of the cp(f d ) problems available at csplib [hmgw]: magic sequence, n-queens, langford’s number and golomb rulers. the set of problems is claimed to be representative enough because: first, all are parametric, and thus they allow to test the performance of the t oy (f d) versions as the instances of each problem scale. and, second, they include the whole set of f d constraints of the t oy (f d) repertoire. the structure of the solutions of each problem is discussed, pointing out how the new search strategies reduce the search exploration to find them. thus, for each problem, two t oy (f d) models are created: problem bs.toy, which applies a single labeling primitive as its search strategy; problem is.toy, which applies some of the new proposed search primitives before applying the ending labeling (to still guarantee completeness of the search process). benchmarks are run in a machine with an intel dual core 2.4ghz processor and 4gb ram memory. the os used is windows 7 sp1. the sicstus prolog version used is 3.12.8. microsoft visual studio 2008 tools are used for compiling and linking the t oy (f d i) and proc. prole 2013 12 / 18 eceasst t oy (f d g) c++ code. all the t oy (f d) models are available at: http://gpd.sip. ucm.es/ncasti/models.zip. for the sake of simplicity, from now on the different versions of the models will be simply referred to as bs and is. 5.1 analyzing the applied search strategies magic sequence. the bs model uses a single labeling [ff] l as its search strategy. analyzing the solutions of the problem it is observed that, if the parameter n ≥ 9 then the sequence follows the pattern: l ≡ [(n−4),2,1,0, 0,...,1,0,0,0]. in this context, the new search strategy of the is model first applies labb unassignedrightvar smallestval 3 l, labb unassignedrightvar largestval 1 l, which matches the last four variable 1,0,0,0 pattern. at that point, propagation leads to l ≡ [(n−4),a,b,c,0,...,1,0,0,0] (with a in 1..3, b in 0..1 and c in 0..1), highly reducing the search space the further labeling has to deal with. queens. the bs model uses a single labeling [ff] l as its search strategy. analyzing the solutions of the problem, an intuitive way for reducing the initial search space of the problem consists of: first, splitting the n variables into k variable sets (vs1,vs2,..., vsk) (where consecutive variables are placed in different variable sets). second, splitting the initial domain 1...n into k different intervals (1..(n/k),...,(n/k)∗(i−1) + 1..(n/k)∗ i,...,(n/k)∗(k−1) + 1..n). and, finally, assigning the variables of vsi to the ith interval. in this context, the new search strategy of the is model first applies split into 3 l ([], [], []) == (k1,k2,k3), fragb (partition 3) unassignedleftvar firstright 0 k1, fragb (partition 3) unassignedleftvar firstmiddle 0 k2, fragb (partition 3) unassignedleftvar firstleft 0 k3. this splits the variables and their domains into three sets, highly reducing the search space the further labeling has to deal with. langford’s number. the bs model uses a single labeling [ff] l as its search strategy. analyzing the solutions of the instances proposed, it is observed that they follow the pattern: l ≡ [x 1,x 2,...,a,b,c,d,e,f], with an inductive mapping between the set of variables {a,b,e,f} and the set of values {1,2,3,4}. in this context, the new search strategy of the is model first applies fragb (partition ((round ((m*n)/4)) 1)) unassignedrightvar firstleft 0 [a,b,e,f], labw unassignedrightvar smallesttotaldomain 0 [a,b,e,f]. the fragb fragments the domain of [a,b,e,f] in the (m*n)/4 intervals of values 1..4, 5..8, ..., m*n-3..m*n. it selects the first interval starting from the left (i.e., the smallest one), and it precludes any further backtracking to explore the remaining intervals. then, with the domain of [a,b,e,f] pruned to be in 1..4, labw labels them, exploring all their feasible combinations before selecting the one leading to the smallest search space for l. thus, it is clear that the use of the previous fragb is crucial for the success of the labw strategy. a deep breath exploration with labw implies a tradeoff between obtaining an ordered hierarchy of relevant intermediate tree-level nodes and the computational effort to obtain this hierarchy. with an initial domain of 1..m*n, the feasible combinations of values for [a,b,e,f] is unaffordable in terms of time and memory. however, with a domain of 1..4 (and knowing that they are constrained with an all di f f erent) the amount of feasible combinations is reduced to, at most, 24 (which is clearly affordable). 13 / 18 volume 64 (2013) http://gpd.sip.ucm.es/ncasti/models.zip http://gpd.sip.ucm.es/ncasti/models.zip improving the search capabilities of a cflp(fd) system7 golomb rulers. the bs model uses a single labeling [tominimize mn] m as its search strategy. analyzing the solutions of the instances proposed, it is observed that the initial domain of their variables is huge, and that the value they take in the optimal solution is not far away from their initial lower bound. for example, in g-11 (an instance benchmark for 11 rulers, for which m ≡ [0,a,b,...,h,i,j]), the initial domains of the last three variables are h in 36..1020, i in 45..1021 and j in 55..1023 (with known optimal solution 64, 70 and 72, respectively) and the initial domain of the first three variables is 0, a in 1..977 and b in 3..987 (with known optimal solution 0, 1 and 4, respectively). in this context, an intuitive way of reducing the initial search space is by reducing as much as possible the upper bound of these variables. the new search strategy of the is model first applies fragw (partition 3) unassignedrightvar smallestsearchtree 2 l, fragw (partition 12) unassignedleftvar largestsearchtree 2 l, fragmenting first the last two variables and then the first two. note that, whereas the former selects as best intermediate node the one minimizing the remaining search space, the latter selects the one maximizing it (which intuitively makes sense, as the smaller interval is the one pruning the least the upper bound of the first two variables, thus pruning less the search space). 5.2 running the experiments table 3 compares the performance of mate bs and is instances. columns 2 and 4 represent the cpu solving time in seconds of bs and is (respectively), both of them using incremental propagation mode. columns 3 and 5 represent the speed-up of t oy (f d g) w.r.t. t oy (f d i) for bs and is, respectively. finally, column 6 focuses on each concrete t oy (f d) version, representing the speed-up of is w.r.t. bs. some conclusions are obtained: first, the use of the new search strategies is encouraging, as the performance of t oy (f d g) and t oy (f d i) for solving is instances is better than the achieved for solving bs ones (excepting q-90 and l-119, where t oy (f d i) spends about 0.4 seconds more in solving is). in any case, the differences range from a 5% to nearly the 100%, so a more detailed analysis by problems and instances is required. for queens and langford’s is instances, the better performance achieved by t oy (f d g) and t oy (f d i) clearly scales as the sizes of the instances scale. more specifically, for q-90 and l-119 (solved in tenths of seconds) t oy (f d g) achieves an improvement of 22% and 5%, respectively. this improvement grows an order of magnitude for q-105 and l-127 (with an improvement of 92%) and two orders of magnitude for q-120 and l-131 (with an improvement of nearly the 100%). in t oy (f d i), it is observed the same growing pattern, but it is less noticeable. for q-90 and l-119 the is performance is even worse than the bs one. then, for q-105 and l-127 the is performance improves a 38% and a 63%, respectively, but still in the same order of magnitude as bs. finally, for q-120 and l-131 the is performance reaches the two orders of magnitude improvement w.r.t. bs, reaching nearly a 100%. for magic is instances, the better performance achieved by t oy (f d g) and t oy (f d i) remains stable as the size of the instances scale (with around a 33%-34% for t oy (f d g) and a 23%-24% for t oy (f d i)). last, for golomb is instances the better performance decreases a 20% per instance (as they scale), with a 75%, 60% and 41% improvement of t oy (f d g) for g-9, g-10 and g-11, respectively, and a 74%, 59% and 39% of t oy (f d i). proc. prole 2013 14 / 18 eceasst instance bs sp-up is sp-up on/off m-400 fdi 0.530 1.00 0.402 1.00 0.76 m-400 fdg 0.422 0.80 0.280 0.70 0.66 m-900 fdi 2.53 1.00 1.95 1.00 0.77 m-900 fdg 2.00 0.79 1.34 0.69 0.67 q-90 fdi 0.110 1.00 0.514 1.00 4.67 q-90 fdg 0.078 0.71 0.061 0.12 0.78 q-105 fdi 1.25 1.00 0.78 1.00 0.62 q-105 fdg 1.05 0.84 0.08 0.10 0.08 q-120 fdi 154.00 1.00 1.11 1.00 0.01 q-120 fdg 129.88 0.84 0.09 0.08 0.00 l-119 fdi 0.530 1.00 0.984 1.00 1.86 l-119 fdg 0.296 0.56 0.282 0.29 0.95 l-127 fdi 4.35 1.00 1.17 1.00 0.27 l-127 fdg 4.62 1.06 0.39 0.33 0.08 l-131 fdi 87.00 1.00 1.19 1.00 0.01 l-131 fdg 98.53 1.13 0.33 0.28 0.00 g-9 fdi 0.421 1.00 0.109 1.00 0.26 g-9 fdg 0.250 0.59 0.062 0.57 0.25 g-10 fdi 3.56 1.00 1.47 1.00 0.41 g-10 fdg 2.11 0.59 0.84 0.57 0.40 g-11 fdi 72.65 1.00 43.98 1.00 0.61 g-11 fdg 42.01 0.58 24.85 0.57 0.59 table 3: performance of t oy (f d) using the search strategies second, it is clearly observed that the improvement achieved by t oy (f d g) for is instances is bigger than the one achieved by t oy (f d i), revealing that the approach gecode offers to extend the library with new search strategies is more efficient than the one of ilog solver. that is, for any is instance, the speed-up of t oy (f d g) w.r.t. t oy (f d i) is bigger than the achieved for its mate bs instance. in this context, two different behaviors are observed. first, for queens and langford’s is instances the speed-up improvement achieved w.r.t. bs instances increases as the instances scale: a 59%, 74% and 76% for q-90, q-105 and q-120, respectively. a 27%, 73% and 85% for l-119, l-127 and l-131, respectively. second, for magic and golomb is instances the speed-up improvement achieved w.r.t. bs instances remains stable as the instances scale: a 10% for m-400 and m-900. a 2%, 2% and 1% for g-9, g-10 and g-11, respectively. 6 related work the approach of taking advantage of both the high expressivity of t oy (f d) and of the high efficiency of gecode and ilog solver can be related to the one followed in search combinators 15 / 18 volume 64 (2013) improving the search capabilities of a cflp(fd) system8 [stw+13]. it provides a lightweight and solver-independent method bridging the gap between a conceptually simple search language (high level, functional and naturally compositional) and an efficient implementation (low-level, imperative and highly non-modular). t oy (f d) is more rigid than [stw+13], but some of the features provided by the search combinators can be matched with the new set of primitives presented in section 3: the basic primitive heuristics base search and prune can be obtained with the primitive lab, controlling the exact number of variables to be labeled (which allows t oy (f d) to support composite search strategies). regarding the set of combinators proposed, t oy (f d) matches {let, assign, post} via intermixing search procedures with constraint posting, and {and, or} via the composed search strategies presented in section 3.3. finally, the t oy (f d) primitives are also extensible, as users can program their own criteria at t oy (f d) level with no extra effort at the sicstus and c++ core implementation of the system. similar approaches to search combinators are proposed for constraint funcional programming (cfp(f d )), with monadic constraint programming [ssw09], and for clp(f d ), with the library tor [std12] (available in swi-prolog). they decouple the definition of the search tree and the search method. in t oy (f d), it is not possible to specify the way to explore the search tree (as, for example, by limited discrepancy search). however, the primitives labw and fragw perform a breadth search exploration. also, whereas these primitives include a depth bound, it can be implicitly imposed as well for the rest of primitives (by using the parameter setting the amount of variables to be labeled). moreover, at least in t oy (f d g) it would not be difficult to support new ways of exploring the search tree, as the gecode library provide the mechanisms to implement them. 7 conclusions and future work this paper has presented eight new t oy (f d) search primitives, describing their behavior from a solver independent point of view, and using examples to show their application. it has emphasized the novel concepts those primitives include, as performing an exhaustive breadth exploration of the search tree further sorting the satisfiable solutions by a specified criteria, fragmenting the domains of the variables by pruning each one to a subset of its domain values instead of binding it to a single value, and applying the labeling or fragment strategy only to a subset of the variables involved. it has also pointed out how expressive, easy and flexible it is to specify some search criteria at t oy (f d) level, and also to apply different search strategies (setting different search scenarios) to the solving of a cp(f d ) problem. a new version of t oy (f d g) and t oy (f d i) including these search primitives has been presented. it has been described their implementation in gecode and ilog solver, by extending their libraries relying on their underlying search mechanisms. it has been observed that these search mechanisms are quite different in gecode (search engine, brancher methods, hybrid recomputation) and ilog solver (ilogoal, goal constructor, goal stack). thus, an abstract view of the requirements needed to integrate the search strategies in t oy (f d) has been first presented (with the scheme further instantiated to gecode and ilog solver). finally, standard benchmarks have been used to point out how the use of the proposed search strategies allow to reduce the search exploration to find them. mate t oy (f d) models, eiproc. prole 2013 16 / 18 eceasst ther with a classical labeling and with an improved ad hoc search strategy have been developed. it has been proven that the use of the new search strategies improve the performance of both t oy (f d g) and t oy (f d i), but the improvement achieved (ranging in 5%-100%) is dependent on the concrete problem and instance solved: whereas for queens and langford’s instances the better performance achieved clearly scales as the sizes of the instances scale, for magic ones it remains stable, and for golomb ones it decreases. moreover, the speed-up of t oy (f d g) w.r.t. t oy (f d i) is bigger for the new improved t oy (f d) models, revealing that the approach gecode offers to extend the library with new search strategies is more efficient than the one of ilog solver. as future work, we will analyze the applicability of the search strategies presented in this paper to other cp(f d ) paradigms. in particular, we will implement the search primitives in the cfp(f d ) system monadic constraint programming, the clp(f d ) system tor and the c++ cp(f d ) system gecode (using the search combinators [stw+13] to implement the strategies). we will discuss if there are aspects of t oy (f d) that are not easily implemented in the other systems, such as the use of non-deterministic functions (to apply different search scenarios to tackle a problem), and the specification of some search criteria in the proper native language (and the impact it may have in the system architecture). we will also reuse the benchmark used in this paper to compare the solving efficiency achieved by each system when applying the ad hoc strategies, analyzing any possible overhead arisen due to their use. besides that, focusing again in t oy (f d), scripting techniques can be applied, to solve the benchmarks under multiple and very precisely controlled scenarios. in them, an exhaustive combination of applying one or different search strategies (as well as the variable subset used on each of them) will be studied. the results will be analyzed, in order to find out which strategies had lead to a solution or, at least, to a minimum search space containing a solution. moreover, this analysis will help to find out new patterns about the relation between the structure of a concrete problem and the concrete search strategy (or combination of search strategies) to be applied to successfully solve it. bibliography [cs12] i. castiñeiras, f. sáenz-pérez. improving the performance of fd constraint solving in a cflp system. in flops’12, 88–103. lncs 7294. springer, 2012. [fhsv07] a. j. fernández, t. hortalá-gonzález, f. sáenz-pérez, r. del vado-vı́rseda. constraint functional logic programming over finite domains. tplp 7(5):537 – 582, 2007. [gec] gecode: generic constraint development environment. version 3.7.3. http://www. gecode.org/. [ghlr99] j. gonzález-moreno, m. hortalá-gonzález, f. lópez-fraguas, m. rodrı́guezartalejo. an approach to declarative programming based on a rewriting logic. journal of logic programming 40:47–87, 1999. 17 / 18 volume 64 (2013) http://www.gecode.org/ http://www.gecode.org/ improving the search capabilities of a cflp(fd) system9 [han07] m. hanus. multi-paradigm declarative languages. in iclp’07, 45–75. lncs 4670. springer, 2007. [hmgw] b. hnich, i. miguel, i. p. gent, t. walsh. csplib: a problem library for constraints. http://www.csplib.org/. [ilo10] ibm ilog cp 1.6. 2010. http://www-947.ibm.com/support/entry/portal/overview/ software/websphere/ibm ilog cp. [jm94] j. jaffar, m. maher. constraint logic programming: a survey. in the journal of logic programming, 19–20. 503–581. elsevier, 1994. [llr93] r. loogen, f. lópez-fraguas, m. rodrı́guez-artalejo. a demand driven computation strategy for lazy narrowing. in plilp’93, 184–200. lncs 714, 1993. [lrv04] f. lópez-fraguas, m. rodrı́guez-artalejo, r. vado-vı́rseda. a lazy narrowing calculus for declarative constraint programming. in ppdp’04, 43–54. acm, 2004. [ms98] k. marriot, p. j. stuckey. programming with constraints. mit press, 1998. [pj02] s. peyton-jones. haskell 98 language and libraries: the revised report. technical report, 2002. http://www.haskell.org/onlinereport/. [sic] sicstus prolog. http://www.sics.se/. [ssw09] t. schrijvers, p. stuckey, p. wadler. monadic constraint programming. journal of functional programming 19(6):663–697, 2009. [std12] t. schrijvers, m. triska, b. demoen. tor: extensible search with hookable disjunction. in ppdp’12, 103–114. acm, 2012. [stl13] c. schulte, g. tack, m. z. lagerkvist. modeling and programming with gecode. 2013. http://www.gecode.org/doc-latest/mpg.pdf. [stw+13] t. schrijvers, g. tack, p. wuille, h. samulowitz, p. stuckey. search combinators. constraints 18(2):269–305, 2013. [tsa93] e. tsang. foundations of constraint satisfaction. academic press, 1993. proc. prole 2013 18 / 18 http://www.csplib.org/ http://www-947.ibm.com/support/entry/portal/overview/software/websphere/ibm_ilog_cp http://www-947.ibm.com/support/entry/portal/overview/software/websphere/ibm_ilog_cp http://www.haskell.org/onlinereport/ http://www.sics.se/ http://www.gecode.org/doc-latest/mpg.pdf introduction the toy(fd) system search primitives labeling primitives fragmentize primitives applying different search scenarios implementing the search primitives abstract specification of the search strategy gecode ilog solver performance analyzing the applied search strategies running the experiments related work conclusions and future work electronic communications of the easst volume 28 (2010) proceedings of the third international discotec workshop on context-aware adaptation mechanisms for pervasive and ubiquitous services (campus 2010) preface sonia ben mokhtar, romain rouvoy and michael wagner guest editors: sonia ben mokhtar, romain rouvoy, michael wagner managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 eceasst preface there is a huge market potential for mobile applications in europe today. most people already carry a mobile device of some sort wherever they go, and an increasingly diverse set of devices (pdas, smart phones, gps, etc.) are becoming widely available. recently, serviceorientations (e.g., osgi, sca) have evolved to address these highly dynamic environments. however, it is still technically difficult, using existing method and tool supports, to create such services-oriented applications. for example, the very large range of devices, types of infrastructure, ways in which it can change, situations in which users can find themselves, and the functions they want, introduce great complexity and pose considerable technical challenges. to overcome these difficulties, and promote the development and widespread deployment of innovative mobile applications, more and more projects are addressing the development of context-aware adaptation mechanisms for leveraging the development of mobile applications. these projects aim at providing simple but powerful integrated approaches to support the development of applications interacting in pervasive and ubiquitous environments. thus, the campus workshop will focus on the promising approaches in the domain of context aware adaptation mechanisms supporting the dynamic evolution of the execution context (e.g., network/device/service failures). this volume contains the proceedings of the third workshop on context-aware adaptation mechanisms for pervasive and ubiquitous services, held in amsterdam, netherlands, june 10, 2010. the campus workshop is jointly organized by the music, connect, and diva ist projects. it provides a forum for scientists and engineers in academia and industry to present and discuss their latest research. the focus of the conference is the design, implementation, deployment, and evaluation of adaptive platforms and architectures for context-aware environments. this year, the workshop encouraged submissions related adaptation issues addressed by two emerging themes in the service computing community: sensor as a service and ambient social services. we had 14 submissions from 10 different countries, among which the top 8 technical papers were selected for inclusion in the technical program of the workshop. all papers were evaluated by at least four reviewers with respect to their originality, technical merit, presentation quality, and relevance to the workshop themes. the selected papers present the latest results and breakthroughs on middleware research in areas of automotive systems, ubiquitous environments, pervasive environments, ambient computing and multimedia computing. we would like to express our deepest appreciation to the authors of the submitted papers, to all program committee members for their diligence in the paper review and selection process, and to all external reviewers for their help in evaluating submissions. june, 2010 sonia ben mokhtar romain rouvoy michael wagner 2 / 5 volume 28 (2010) preface organization steering committee frank eliassen university of oslo, norway kurt geihs university of kassel, germany svein hallsteinsen sintef ict, norway geir horn sintef ict, norway valérie issarny inria, france organizing committee program co-chair sonia ben mokhtar cnrs, france program co-chair romain rouvoy university of lille 1, france & university of oslo, norway publication chair michael wagner university of kassel, germany program committee olivier barais university de rennes 1, france benoit baudry inria, france sonia ben mokhtar cnrs, france yolande berbers k.u.leuven, belgium gordon blair lancaster university, uk licia capra university college of london, uk franck chauvel peking university, china ruzanna chitchyan lancaster university, uk denis conan institut telecom, telecom sudparis, france geoff coulson lancaster university, uk wolfgang de meuter vrije universiteit brussel, belgium schahram dustdar vienna university of technology, austria frank eliassen university of oslo, norway kurt geihs university of kassel, germany geir horn sintef ict, norway joseph loyall bbn technologies, massachusetts ilaria matteucci istituto di informatica e telematica, italy rené meier trinty college dublin, ireland nearchos paspallis university of cyprus, cyprus pascal poizat university of evry, france hongyang qu oxford university, uk romain rouvoy university of lille 1, france & university of oslo, norway rachid saadi inria, france antonino sabetta isty-cnr, italy ulrich scholz european media laboratory gmbh, germany lionel seinturier university of lille 1, france sotirios terzis university of strathclyde, uk massimo tivoli university of l'aquila, italy roman vitenberg university of oslo, norway michael wagner university of kassel, germany proc. campus 2010 3 / 5 eceasst external referees gabriele costa istituto di informatica e telematica, italy andoni lombide carreton vrije universiteit brussel, belgium atif manzoor vienna university of technology, austria freddy munoz inria, france russel nzekwa university of lille 1, france roland reichle university of kassel, germany daniel romero university of lille 1, france 4 / 5 volume 28 (2010) preface proc. campus 2010 5 / 5 contents middleware for the internet of things, design goals and challenges koosha paridel, engineer bainomugisha, yves vanrompay, yolande berbers and wolfgang de meuter testing self-adaptive applications with simulation of context events konstantinos kakousis, nearchos paspallis, george a. papadopoulos and pedro antonio ruiz modelling feedback control loops for self-adaptive systems russel nzekwa, romain rouvoy and lionel seinturier supporting pervasive and social communications with frascati rémi mélisson, daniel romero, romain rouvoy and lionel seinturier architectural constraints for pervasive adaptive applications christian straube and andreas schroeder mlcontext: a context-modeling language for context-aware systems jose ramon hoyos, jesus j. garcia-molina and juan a. botia ambient contracts dries harnie, christophe scholliers and wolfgang de meuter training the behaviour preferences on context changes kuderna-iulian benta, marcel cremene and amalia hoszu preface organization contents assemblies as graph processes electronic communications of the easst volume 26 (2010) manipulation of graphs, algebras and pictures essays dedicated to hans-jörg kreowski on the occasion of his 60th birthday assemblies as graph processes dirk janssens 18 pages guest editors: frank drewes, annegret habel, berthold hoffmann, detlef plump managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst assemblies as graph processes dirk janssens department of mathematics and computer science university of antwerp, belgium abstract: this paper explores the potential of graph rewriting and graph processes as a tool for understanding natural computing, and in particular self-assembly. the basic point of view is that aggregation steps in self-assembly can be adequately described by graph rewriting steps in a graph transformation system: the building blocks of an assembly correspond to occurrences of rewriting rules, and hence assemblies correspond to graph processes. however, meaningful algorithms do not consist only of aggregation steps, but also of global steps in which assemblies are modified or partially destroyed. thus a number of further operations acting on processes are proposed and it is shown that both kinds of operations (assembly and partial destruction) can be combined to yield meaningful algorithms. keywords: natural computing, self-assembly, processes, graph rewriting 1 introduction the study of self-assembly has been an interesting and promising part of the fascinating area of natural computing for several years [wlws98, kr08, cas06]. the phenomenon is an important aspect of biological systems [etp+04] and has potential applications in nanotechnology, chemistry and material sciences [wms91]. the basic idea is that components such as molecules or proteins aggregate to form assemblies that have interesting emerging properties which are not present in the original components. it is obviously important to control this aggregation process, i.e. we want to be able to design the building blocks in such a way that certain a priori known structures emerge as a result of spontaneous aggregation. these structures may in their turn interact in a meaningful way with other components. components will be called assemblies whenever we want to stress that they are built by self-assembly. the basic step in an assembly process is sketched in figure 1: two components (left) aggregate to form an assembly (right). it is assumed that this happens because there is a particular relationship between their surface structures: these contain active parts (bold segments) that spontaneously stick together; one may think of atoms or molecules that form bonds between them, like in the case of watson-crick complementarity. however it is worth noting that “sticking together” is only a metaphor: often the components are subject to both attracting and repulsive forces, and only if certain complementary structures are present on their surfaces the attracting forces are sufficiently strong to overcome the repulsive ones. thus if only a part of the active structures is present, then there may be no sticking at all, not even over that part. the use of graph rewriting [ekmr97, eept97] as a tool for studying natural computing and self-assembly has been explored before [hlp08, kgl04]. however there are a lot of possible directions to follow because of the variety of processes that need to be described as well as the 1 / 18 volume 26 (2010) assemblies as graph processes figure 1: aggregation variety of graph rewriting mechanisms. the aim of this paper is to explore, in a preliminary and perhaps somewhat naive way, how the work on graph rewriting with embedding and the corresponding theory of graph processes from, e.g., [vj02] can be used in this context. it turns out that components, surface structure and assemblies correspond to rules, graphs and graph processes, respectively. the fact that both the surface structure and the assemblies are described within the same formal framework enables one to switch between the graph/surface structure and the process/assembly view: the former allows one to describe the aggregation steps (combination of various assemblies based on their surface structure) whereas the latter allows one to describe operations that act in a uniform way on the assemblies as a whole (e.g. with the purpose of removing certain parts of them). the first kind of step occurs when a large amount of simple building blocks (molecules) is put into a solution and allowed to form assemblies; the latter kind happens in response to external manipulations such as heating a solution, or selectively extracting assemblies that have a certain property. it is to be expected that the implementation of meaningful algorithms will often require a combination of both kinds of steps: although the self-assembly of cleverly designed building blocks is a powerful tool, its use leads inevitably to ever larger assemblies, and one may expect that at some point a model based on self-assembly alone becomes unrealistic. thus in addition to self-assembly we propose three operations acting directly on processes; two of these are very simple (combine and extract) but the third one (retain) allows one to partially destroy assemblies, keeping only a part of each of them. we present two language recognition algorithms in which the various kinds of steps are combined: the first one marks components that encode a certain language, the second one marks those components in a solution x that also occur in another solution y . here the “marking” of components consists in attaching a special element to them, making it possible to extract them. in the case of the second algorithm, one may think of y as a contamination that has to be removed from x ; the contamination is not given by specifying its structure explicitly, but by presenting a sample solution. in section 2 the basic assumptions underlying this work are given, and the relationship is discussed between components, surface structure and assemblies on the one hand and rules, graphs and graph processes on the other hand. section 3 provides the basic definitions concerning graph rewriting and processes. in section 4 the operations dealing with partial destruction and removal of assemblies are defined and illustrated by examples, and the paper ends by a brief discussion section. festschrift h.-j. kreowski 2 / 18 eceasst 2 graph rewriting and self-assembly 2.1 basic assumptions a graph transformation system consists essentially of a set of rules that describe local changes applied to graphs. traditionally, a rule has a left-hand side and a right-hand side, which are both graphs. a rule is applied to a graph g by matching its left-hand side with a subgraph of g. that subgraph is then removed and replaced by the right-hand side. in the approach used in this paper the rules are equipped with additional information, called “embedding mechanism”, which is used to determine the edges of the resulting graph. more details can be found in subsections 2.2 and 3.1. the way graph rewriting is related to aggregation is the following. consider an assembly step, like the one depicted in the upper part of figure 2: an existing assembly (top) gets larger by aggregating with a building block (bottom). the surface structure of the former is represented by a graph g1 with nodes a, b, c, d, e. the aggregation leads to a larger assembly with a modified surface structure, represented by a graph g2 with nodes c, d, e, f , g, h. thus the effect of adding the new building block on the surface structures is that g1 is changed into g2, in a way that can be captured by graph rewriting: the building block is viewed as a graph rewriting rule and the aggregation step corresponds to its application, removing the nodes a, b and replacing them by f , g, h. evidently one also has to deal with the edges, which represent relationships between surface elements, we come back to this in subsection 2.2. the approach entails the following three assumptions concerning aggregation. a b c d e a b̄ f h g c d e f hg a b c d e c d e f hg ˉ g 2g 1 figure 2: aggregation and graph transformation the first working hypothesis is that the surface structure of components, which governs the way in which they aggregate, can be adequately described by a labeled graph. the nodes represent atoms, molecules, ... that are present at specific locations on the surface, the node labels distinguish between various kinds of such surface elements, and the edges describe relationships between these elements that are important for determining whether a group of nodes is active in the sense that it causes aggregation. one may think of spatial relationships or vicinity, but there 3 / 18 volume 26 (2010) assemblies as graph processes may be others. in general, both nodes and edges may be abstractions of physical entities. in this paper we consider graphs that have labels on their nodes but not on their edges. however the approach can be generalized to edge-labeled graphs or even hypergraphs if desired. in figure 2 the symbols a and b are used to indicate the fact that binding or aggregation between physical components is caused by elements that are “complementary” in some sense (e.g. having opposite polarities, watson-crick complements, ...). in our approach this information is implicitly represented by the fact that building blocks are described by graph rewriting rules which have a designated left-hand side. this is why we will not explicitly need complementary labels such as a and a in the next section: it is simply assumed that the label a stands for a if it occurs in the left-hand side of a rule. the second hypothesis is that the relevant relationships between the elements of the new surface (i.e., the new edges) can be determined from (1) the surface of the existing component and (2) the new component. thus the components, such as the ones depicted in the left part of figure 1 will not be treated equally: one of them (the upper one in the figures) may be thought of as a large assembly that grows by aggregating with the other one, which is small and simple. the more symmetric case where two arbitrarily large components aggregate is not considered in this paper: there is a “large” assembly that “grows” by adding a new building block. as a result of this, the building blocks of an assembly are partially ordered, making them similar to graph processes. the surface of the assembly after the aggregation step consists of most of the “old” surface combined with a small, new part that belongs to the building block. it is assumed that in determining the new surface structure, one does not need the internal structure of the large assembly. the upper half of figure 2 depicts an aggregation step where the surface structures are graphs. technically the letters a, b, . . . are node labels, but throughout this section we need not to distinguish between nodes and their label. the lower half of figure 2 depicts the transformation of the surface structure, which is now a graph transformation. a last assumption is that the effect of an aggregation step is local: a surface element that is irrelevant for a location does not suddenly become relevant when an aggregation takes place involving that location: e.g. in figure 2, e is not relevant to the locations a and b involved in the aggregation – and thus e is not connected to either of them. in terms of graph rewriting, the assumption means that the newly introduced nodes can only be connected to those nodes that were neighbors of the nodes removed by the rewriting. thus the neighbors of the new nodes f , g, h are either also new or chosen among the “old” neighbors c, d of a and b. 2.2 the embedding mechanism the lower half of figure 2 depicts the change in surface structure that corresponds to the aggregation step in the upper half of the figure. this change will be described by the application of a graph rewriting rule to the graph g1 on the left: the rule removes nodes a, b and creates f , g, h. the edges of the new surface are either edges of the old surface, such as (d, e), or edges of the surface of the newly added building block, such as ( f , g), or edges that connect the new nodes with the old ones, such as (c, f ) or (h, d). the mechanism for establishing the latter kind of edges is known as an embedding mechanism. the embedding mechanism used in this paper is very simple: each of the new nodes may take over the incoming and/or outgoing edges of one or festschrift h.-j. kreowski 4 / 18 eceasst more of the nodes that have been removed. in figure 2, f takes over the incoming edges from a and h takes over the outgoing edges of b. the rule applied is depicted in figure 3: it consists of two graphs (the left-hand side and the right-hand side) and two binary relations in and out that express the way edges are established. in figure 3 both relations contain only one pair; in general in, out ⊆ lnd ×rnd where lnd and rnd are the sets of nodes of the left-hand side and the right-hand side, respectively. b f hg in out a left-hand side right-hand side figure 3: a rule 3 graph rewriting and processes the purpose of this section is to provide the basic notions and notation concerning graph rewriting and graph processes. in the first subsection we consider graphs, rules and the way they are applied to rewrite graphs. the graphs are finite, directed, simple, node labeled graphs; the introduction of edge labels should not lead to major difficulties and is left out for simplicity. as pointed out before, the graph rewriting considered uses a very simple embedding mechanism, needed to specify the edges of the graph that results from a rewriting step. in the second subsection graph processes are defined and it is briefly discussed how the process approach is related to the more traditional view of graph rewriting where the emphasis is on sequences of derivation steps. 3.1 graphs, rules and rewriting for the remainder of the paper, let lab be a finite set; its elements are called node labels. definition 1 (graph) a graph is a 3-tuple g = (nd, ed, lab) where nd is a finite set, e ⊆ nd ×nd and lab : nd → lab is a function. nd is the set of nodes of g, ed is the set of edges of g and lab is the node labeling function of g. for a graph g, its components are denoted by nd(g), ed(g) and labg. a graph g is a subgraph of a graph g′ if nd(g) ⊆ nd(g′), ed(g) ⊆ ed(g′) and labg is the restriction of labg′ to nd(g), hence the notion of subgraph coincides with pointwise inclusion. for a graph g and a subset x of nd(g), the induced subgraph of g on x is the graph (x , ed(g)∩(x ×x ), labx ) where labx is the restriction of labg to x . definition 2 (rule) a rule is a 4-tuple r = (lhs, rhs, in, out) where lhs and rhs are graphs such that nd(lhs)∩nd(rhs) = /0 and in, out ⊆ nd(lhs)×nd(rhs). the graphs lhs and rhs are called 5 / 18 volume 26 (2010) assemblies as graph processes the left-hand side and the right-hand side of r. for a rule r, its components are denoted by lhs(r), rhs(r), in(r) and out(r). the notion of a rule will be extended in subsection 3.2 to allow edges connecting the left-hand side to the righthand side. obviously, rules can be used to rewrite graphs: in order to apply a rule r to a graph g, one carries out the following steps. 1. match the left-hand side of r with a subgraph lhs′ of g. this means that one chooses an occurrence (an isomorphic copy) lhs′ of lhs(r) that is a subgraph of g. if no such occurrence can be found, then the rule r cannot be applied to g. 2. remove lhs′ from g. this includes the removal of edges between nodes of lhs′ and the remaining part of g. 3. replace lhs′ by an isomorphic copy rhs′ of rhs(r). the set of nodes of rhs′ should be disjoint from the set of nodes of g. 4. establish edges between nodes of rhs′ and the remaining part of g according to the embedding mechanism: for each (x, y) ∈ ed(g) and each x′, y′ ∈ (nd(g)\nd(lhs′))∪nd(rhs′), add the edge (x′, y′) to the set of edges of the result graph if both of the following conditions hold: (1) either x = x′ or (x, x′) corresponds to an element of out(r), and (2) either y = y′ or (y, y′) corresponds to an element of in(r). in out r g x' lhs' rhs' y y' x isomorphism figure 4: application of a rule the situation is illustrated in figure 4, and it is clear that the graph on the right lower corner of figure 2 is obtained in this way from the graph in the left lower corner, applying the rule of figure 3. the embedding mechanism transforms the dashed edges in figure 2 into the dotted ones. note also that an edge (x, y) of lhs′ such that (x, x′) corresponds to an element of out(r) and (y, y′) corresponds to an element of in(r) gives rise to an edge (x′, y′). in the example algorithms of section 4, however, this situation does not occur. in the rather informal description of a rewriting step given above, matching the left-hand side of the rule r with a subgraph lhs′ of the graph g amounts to choosing an isomorphism from lhs(r) to lhs′. such isomorphism is often called matching morphism; in many approaches to graph rewriting one allows more general matching morphisms than is the case in this paper. in the formal definition of a derivation step however, matching will be handled in a slightly different festschrift h.-j. kreowski 6 / 18 eceasst way: it is assumed that an isomorphic copy of the rule r is available such that its left-hand side is equal, and not just isomorphic, to lhs′. whenever a system is specified by a set of rules p, we assume that all isomorphic copies of the rules of p are available for the construction of derivation steps. in this way the only matching morphisms needed are identical mappings, and they can be left implicit. throughout the paper the term rule occurrence is used to emphasize the fact that a certain rule is an isomorphic copy of a rule in a system p. the notion of a derivation step is defined as follows. for a set x , let idx denote the identity relation on x . definition 3 (derivation step) a derivation step is a 3-tuple (g, r, g′) where g, g′ are graphs, r is a rule and the following holds. 1. lhs(r) is a subgraph of g and nd(rhs(r))∩nd(g) = /0. 2. nd(g′) = (nd(g)\nd(lhs(r)))∪nd(rhs(r)). 3. let in = in(r)∪idnd(g′) and out = out(r)∪idnd(g′). then ed(g′) = {(x′, y′) ∈ nd(g′)×nd(g′) | there exists (x, y) ∈ ed(g)∪ed(rhs(r)) such that (x, x′) ∈ out and (y, y′) ∈ in}. 4. for each x ∈ nd(g′), labg′(x) = { labg(x) if x ∈ nd(g) labrhs(r)(x) if x ∈ nd(rhs(r)). 3.2 processes in [cmr96, vj02] graph processes are proposed as a way to describe “runs” of a graph rewriting system. informally, a graph process is a structure obtained by gluing together the rule occurrences of a run, where the gluing is consistent with the way the rules are applied. for each rule occurrence, its left-hand side is glued over the set of nodes that is removed by that occurrence. thus a graph process is essentially a directed acyclic graph where the nodes are those that occur in the run and where the edges represent the direct causal dependency relation: whenever a rule occurrence removes a node a and introduces a new node b, then b is directly causally dependent on a. this dag is further decorated with extra information: the initial graph of the run is given as well as the rule occurrences. however there is no information on the order in which the rules are applied other than the causality relation. figure 5 depicts a process: the initial graph is the linear structure at the top and there are three occurrences of the rule depicted at the left. there is no information about the relative order of rule occurrences 1 and 2, and so the process describes in fact three possible runs: the three rule occurrences may happen either in the order 1,2,3, or 2,1,3, or 1 and 2 may happen simultaneously, followed by 3. the dotted edges are established according to the embedding mechanism. when reasoning about processes it is often useful to consider a rule as a graph, rather than a pair of graphs equipped with embedding information. in this way a rule can be viewed as a very simple process, describing a run consisting of just one rule application. however this also enables one to extend the notion of a rule by allowing edges connecting its left-hand side and its 7 / 18 volume 26 (2010) assemblies as graph processes 1 2 3 in out figure 5: a process right-hand side. while such edges have no obvious interpretation in the traditional view of graph rewriting, they fit well into the process view developed here and, more importantly, they turn out to be quite useful in the operations and algorithms of section 4. definition 4 (rule,extended) a rule is a 5-tuple r = (gr, lnd, rnd, in, out) where gr is a graph, (lnd, rnd) is a partition of nd(gr) and in, out ⊆ lnd×rnd. the induced subgraphs of gr on lnd and rnd are called the left-hand side an the right-hand side of r, respectively. the set nd(gr) is the set of nodes of r. the set of edges created by r is the set ed(gr)\(lnd(r)×lnd(r)). for a rule r, its components are denoted by gr(r), lnd(r), rnd(r), in(r) and out(r) respectively. its set of nodes, its set of edges created, its left-hand side and its right-hand side are denoted by nd(r), ed(r), lhs(r) and rhs(r). slightly abusing notation, labr denotes labgr(r). note that an extended rule r such that ed(gr(r)) ⊆ (lnd(r)×lnd(r))∪(rnd(r)×rnd(r)) can be described as a rule according to definition 2, replacing it by (lhs(r), rhs(r), in(r), out(r)). formally, the notion of a process is defined as follows. definition 5 (process) a process is a pair p = (init, occ) where init is a graph and occ is a set of rule occurrences such that the following holds. 1. let <1= ⋃ oc∈occ(lnd(oc)×rnd(oc)) and let nd = nd(init)∪ ⋃ oc∈occ nd(oc). then (nd, <1) is a directed acyclic graph. the relation <1 is called the direct causality relation of p. its transitive and reflexive closure is called the causality relation of p. 2. nd(init) is the set of minimal nodes of (nd, <1). 3. there exists a function lab : nd → lab such that, for each g ∈{init}∪occ, labg is a restriction of lab. the function lab is called the labeling function of p. 4. for each oc, oc′ ∈ occ such that oc 6= oc′, the sets lnd(oc) and lnd(oc′) are disjoint, and the sets rnd(oc) and rnd(oc′) are disjoint. for a process p, its components are denoted by init(p) and occ(p), respectively. its set of nodes, direct causality relation, causality relation and labeling function are denoted by nd(p), festschrift h.-j. kreowski 8 / 18 eceasst <1p , ≤p and labp. the relations in(p) and out(p) are defined by in(p) = idnd(p)∪ ⋃ oc∈occ in(oc) and out(p) = idnd(p)∪ ⋃ oc∈occ out(oc). the set of edges created in p, denoted by ed(p) is defined by ed(init(p))∪ ⋃ oc∈occ ed(oc). note that a graph g can be identified with a process(g, /0), and that a process imposes a partial order on its rule occurrences: oc directly precedes oc′ if rnd(oc)∩lnd(oc′) 6= /0. given a set of rules p, one has to associate with p a set of processes that is “valid” in the sense that they describe a possible run or rewriting process of p. informally, there are two obvious conditions to be satisfied by such a process: 1. the process should be built from an initial graph and occurrences of rules from p, and 2. for each rule occurrence oc of the process, its left-hand side should be a subgraph of the graph obtained by applying the occurrences that precede oc, starting from the initial graph. in order to formalize the second condition one needs to associate a set of graphs with a process: the graphs that occur as intermediate configurations in the course of the rewriting process. it is well known in the theory of processes that these configurations correspond to slices, i.e. maximal sets of causally unrelated nodes. thus what remains to be done is to equip each slice with a suitable set of edges (the node labels are determined by the node labeling functions of the initial graph and the rule occurrences). this leads to the following definitions. definition 6 (slice) let p be a process. a slice of p is a maximal subset s of nd(p) such that, for each x, y ∈ s, x ≤p y implies that x = y. definition 7 (configuration) let p be a process and let s be a subset of nd(p). the configuration of p on s, denoted conf (p, s), is the graph (s, e, labs) where e ={(x′, y′)∈ s×s | there exists (x, y)∈ ed(p) such that (x, x′)∈ out(p) and (y, y′)∈ in(p)} and labs is the restriction of lab(p) to s. intuitively, this means that the graph conf (p, s) contains all the edges that can be derived by the embedding mechanism from the edges of the initial graph and the edges created in the rule occurrences. the graph conf (p, s) is defined for arbitrary subsets s of nd(g), not only for slices. since the nodes of init(p) are minimal w.r.t. the causality relation, one easily verifies that conf (nd(init(p)), p) = init(p). the second condition mentioned above (a rule can only be applied if there is a match for its left-hand side) is captured by the notion of validity, defined as follows. definition 8 (validity) let p be a process. 9 / 18 volume 26 (2010) assemblies as graph processes 1. p is valid if, for each oc ∈ occ(p) and each slice s of p such that lnd(oc) ⊆ s, the graph lhs(oc) is a subgraph of conf (p, s). 2. let p be a set of rules. then p is valid for p if p is valid and each oc ∈ occ(p) is a rule occurrence of p. if p is a valid process and s is a slice, then conf (p, s) is an intermediate configuration of the rewriting process represented by p; i.e. it is the graph obtained by applying the rule occurrences that precede s, in the way specified by p, to the graph init(p). in the case where one uses only restricted rules, i.e. rules according to definition 2, then this view is consistent with the way derivation steps are defined in definition 3. this follows from the fact that conf (nd(init(p)), p) = init(p) and the following lemma. lemma 1 let p be a valid process, let s, s′ be slices of p, let oc ∈ occ(p) be such that ed(gr(oc))⊆(lnd(oc)×lnd(oc))∪(rnd(oc)×rnd(oc)), lnd(oc)⊆s and s′ = (s\lnd(oc))∪ rnd(oc). let roc be the rule (according to definition 2) (lhs(oc), rhs(oc), in(oc), out(oc)). then (conf (p, s), roc, conf (p, s′)) is a derivation step. thus the process view extends the traditional way of looking at graph rewriting: if p is a valid process such that all rule occurrences can be viewed as rules according to definition 2, s is a slice of p and oc is a rule occurrence such that the nodes of lhs(oc) belong to s, then oc transforms the graph conf (p, s) in the way described by definition 3. it is also worth noting that this implies that the graph rewriting considered in this paper is confluent: in general the causality relation does not impose a total order on the rule occurrences of a process, and applying them in any order consistent with the causality leads to the same result conf (p, max), where max is the set of maximal nodes of the causality relation. using the notions introduced above one has three ways to view the components that act as building blocks in aggregation steps such as the one considered in figure 2: a component with a surface structure, a graph rewriting rule, and a process. since such components are not composed of smaller ones they are called “atomic”. similarly, the processes that represent a single rule are called atomic processes. figure 6 depicts the three views; the arrows/lines labeled in and out represent the embedding mechanism. b̄ f h g b f hg b f hg in out outin ā a a figure 6: atomic component, rule and atomic process the relationship between processes and assemblies is illustrated in figure 7 (in the process, on the right, only the direct causality relation is represented). the confluency property is illustrated by figure 7: one may e.g. consider the situation of the assembly after building blocks 1 and 2 festschrift h.-j. kreowski 10 / 18 eceasst are added. the corresponding slice consists of the square nodes. the confluency property then implies that the surface structure at this point of the aggregation process does not depend on the order in which blocks 1 and 2 were added; a posteriori inspection of an assembly (which blocks are present and how are they glued together) suffices to determine its surface structure. since the order in which the aggregation takes place would probably be very hard to control, this property is of crucial importance. processassembly 1 2 3 4 figure 7: assembly and process 4 operations on assemblies we wish to study algorithms that manipulate solutions containing potentially large amounts of assemblies: the input is a set of solutions (test tubes) and the output is another set of solutions, one or more of which should have a certain, desired property. in order to realize this we need a set of operations to be used as instructions or steps in the algorithms. self-assembly provides a first powerful operation of this kind: one may add a number of cleverly designed atomic components to the solution, let them aggregate, and obtain in this way a modified solution. the design of aggregation steps is thus viewed as the design of a suitable set of graph transformation rules. it is implicitly assumed that for each of those rules a component can be constructed which has the right surface structure, and that this component interacts in the right way with the other components. it has to be noted that the latter assumption is not obvious, but there is evidence that unintended interactions can be made improbable by a clever design of the components; the problem is somewhat similar to the dna code word problem, which is an interesting research topic on its own. it is to be expected that self-assembly alone is insufficient to describe most meaningful algorithms or processes taking place in living organisms, because its repeated use leads to ever larger assemblies. in many forms of natural computing operations occur that partially break down or disassemble larger components, e.g. cutting strands of dna in a controlled way. thus there is a need for modeling operations that have a similar effect on assemblies. in this way one also introduces the possibility to reactivate elements that have become inactive: in the building of 11 / 18 volume 26 (2010) assemblies as graph processes assemblies, we assumed so far that a surface element that is glued to a new building block ceases to be on the surface of the resulting assembly and therefore becomes unavailable for further interactions. however, partially breaking down an assembly may bring such elements back to the surface and hence reactivate them. since we describe assemblies by (valid) processes, we need one or more operations that acts on processes. these have to be implemented by manipulations such as heating, applying an electromagnetic field, irradiation, etc., where all components in a solution are modified in a uniform way. such “global steps” are not necessarily local changes based on the surface structure of components, and thus the rewriting of graphs describing their surface structure is not a natural way to formalize them. however the more complete description of an assembly by a graph process provides information that is sufficient to express the global steps: the atomic components it is built from and their surface elements. 4.1 operations on processes apart from self-assembly, we propose three operations. two of them, combine and extract, are very simple, but the third one, retain, requires some more explanation. it enables one to partially break down assemblies. 1. combine. this operation allows to combine a number of graphs as one: the resulting graph simply consists of disjoint copies of the original graph. the combined graph can then serve as the initial graph of a self-assembly process. thus combine does not correspond to a physical manipulation of test tubes, it is merely a technical convenience. 2. extract(m), where m is a node label. the symbol m represents a marker, i.e. a part of a component that can easily be detected by its physical properties. the operation removes all components in which the marker occurs from a test tube. 3. retain(r), where r is a subset of the set of node labels. the operation removes, from each component in a test tube, the part that does not correspond to r. the remaining part is again considered as a component; its surface structure is derived from the internal structure of the original component. such effect can be achieved by designing these components in such a way that the elements in r are they are more stable or more resistant to heat or radiation than the other elements. since the surface of the remaining part of an assembly may contain elements that have been added at various stages of the assembly process, it may contain elements that are causally related in the process description of the assembly. in this first approach it is therefore assumed that the causality relation of the resulting assembly is trivial: thus all its elements are maximal, and belong to the surface. formally, the effect of retain(r) on a set of processes is that each process p is replaced by the graph conf (p, ret) where ret is the set {x ∈ nd(p) | labp(x) ∈ r} . evidently, the operation retain(r) is rather limited in that it completely destroys the internal structure of an assembly. it is easy to conceive more sophisticated variants of the operation, e.g. a version where the substructure of the process p induced by the nodes with labels in r is preserved. the structures obtained in that way would not be valid according to definition 8, since they are not obtained by composing elements of a designated set of basic components, but nevertheless one may decide to introduce them if desired. festschrift h.-j. kreowski 12 / 18 eceasst example 1 as a first example of the use of retain, consider the situation of figure 8. one wishes to let the string-like component grow by adding a building block. the assembly step would lead to a disconnected graph, but the desired result (bottom) appears if that step is followed by the operation retain({a, b, c}). note that the rule corresponding to the building block contains an edge connecting its left-hand side to its right-hand side. baa c a baa c a baa c c a assembly retain{a,b,c} baa a baa c a baa c graph rewriting c a (lhs) (rhs) rule building block surface structure surface structure surface structure figure 8: growing a string 4.2 example algorithms the aim of this section is to sketch how aggregation steps (building assemblies) and global steps (acting in a uniform way on all components) may be combined into a meaningful algorithm. an algorithm describes a sequence of steps in which test tubes containing a solution are manipulated in order to obtain a solution with certain desired properties. we present two language recognition algorithms: in both cases the input is a test tube containing string-like components such as the one depicted in figure 9, which is used as the encoding of the word x1x2 . . . xn. in both cases the output is a test tube from which the components encoding words of a certain language l are removed. this is achieved by using self-assembly to attach a “marker” to them, which allows their extraction. in both cases the retain operation can be used to return to a situation where the process of self-assembly and extraction can be iterated. in the first algorithm the language l is given by a context-free grammar, and the assembly process essentially builds a parse tree. in the second algorithm the language l is given in the form of a test tube that contains its encoding by components, so the structure of the words in l is not known explicitly. in this case one may think of l as a contamination that is to be removed from the input solution. 13 / 18 volume 26 (2010) assemblies as graph processes x1 x2 xnl r ... figure 9: component encoding a string 4.2.1 recognizing the language of a context-free grammar the method demonstrated works for any context-free grammar, but for the example consider the following one. s → ab a → aab b → ab the set of node labels is {l, r, a, b, s, a, b, m}. the algorithm consists of repeating the following steps for as long as step 3 yields a significant amount of extracted components: 1. mark the components encoding words in l, by adding the encodings of the rules of figure 10 to the test tube and letting them aggregate. note that the rightmost rule contains an edge from the only node of its right-hand side to a node of its left-hand side. 2. execute retain({l, r, a, b, m}) to partially destroy the assemblies formed, so that components which have not been correctly parsed return to their original form. 3. execute extract(m) to remove the correctly parsed components from the test tube. in out ba a in out ba s in out ba b l rs m a figure 10: rules for first algorithm figure 11 depicts a process that represents the correct parsing of a component encoding a word from l. the dotted edges are the edges added by the embedding mechanism, these are the edges of the graphs conf (p, s). an application of the rightmost rule of figure 10 leads to the process sketched in figure 12, where the shaded triangle represents the parse tree. a subsequent execution of retain({l, r, a, b, m}) leads to the graph of figure 13. the edge from m to l in the rightmost rule of figure 10 is not really necessary; it was only added to avoid an isolated node in figure 13. in general step 1 yields also processes corresponding to failed attempts at parsing, e.g. reducing ab in the word aab to b. one can only expect to remove all components encoding a word of l if the procedure can be iterated, and thus one needs to break down the unmarked assemblies so that step 1 can be repeated; this happens in step 2. festschrift h.-j. kreowski 14 / 18 eceasst l ab r a ba b s a figure 11: parsing l r m s figure 12: attaching the marker 4.2.2 recognizing the components of a test tube in the second algorithm we start from two test tubes t and tl: the first one contains a solution that has to be modified, whereas the second one only serves as an additional input: it contains the encodings of the language l. the aim is to remove from the first test tube the components that encode words of l. m rl a b a ba figure 13: marked component 15 / 18 volume 26 (2010) assemblies as graph processes let the set of node labels be {l, r, a, b, q, c, m}. the algorithm consists of the following steps: 1. mark the components encoding words in l, by first adding the rule depicted at the left of figure 14 to test tube tl and letting it aggregate, and then executing retain({l, r, a, b, c}) to obtain components such as the one on the right of figure 14: hence a node with label c is attached. c rl a b aa l c figure 14: step 1 2. repeat the following steps for as long as step (c) effectively yields a significant change: (a) add part of the contents of tl to t , and allow pairs of components to be considered as one; formally, apply a combine operation. (b) add the rules depicted in figure 15 and let them assemble. the aggregation process traverses both words from left to right, as illustrated in figure 16. the rightmost rule, which attaches the marker m, can be applied only to an assembly that has been built on a pair of components that both encode the same word. x ∈ {a,b} out out x xq q out out l l q r rq m c figure 15: step 1 l l q q ...qc figure 16: step 1 festschrift h.-j. kreowski 16 / 18 eceasst (c) execute extract(m) to remove the marked components from the test tube. (d) execute retain({l, r, a, b, c, m}). this has the effect of partially destroying the assemblies formed, so that components representing unsuccessful comparisons (starting from pairs of components that encode different words) return to their original form: a string starting with c ad a string starting with l. as a result, step 2 can be repeated. 5 discussion the aim of the paper is to explore the use of graph rewriting based on embedding for the understanding of self-assembly and natural computing. the basic idea is that graphs capture the active surface structure that controls the way components in a solution aggregate, and that the way in which such aggregation changes the surface structure can be captured by graph rewriting. however one may expect that most meaningful algorithms in this context do not only require the building of ever larger assemblies, but also operations that break down or modify such assemblies. thus what seems to be needed is an interplay between aggregation operations, which are described by graph transformation rules, and which act on the graphs that describe the active surface of components, and global operations in which all assemblies of a given kind in a solution are modified. since assemblies correspond to processes of the graph rewriting systems that describe their formation, the theory of graph rewriting and graph processes may provide a way to obtain a formal framework in which both kinds of operations can be combined in an elegant way. obviously, the material presented here is of a very speculative nature, since the implicit assumptions concerning the possible realization of the approach in the physical world may turn out to be naive or unrealistic. to mention just a few: when reducing the problem of controlling self-assemby to the problem of writing a suitable graph transformation system, it is assumed that each rule written down can be realized by a component that behaves exactly in the right way: not only does it aggregate with another component when the structure corresponding to its lefthand side matches part of the structure of the other component, but this is also the only way it interacts with other components. another thorny issue is the assumption about the information to be encoded into the edges, information that is handled by the embedding mechanism: what are exactly the relationships between locations on a component that are relevant? how to encode spatial information into those edges? also for the the global operations many questions remain: on the one hand they may seem rather ad-hoc, but on the other hand they are quite simple and one can easily define more sophisticated variants. it seems also rather straightforward to generalize the approach to edge labeled graphs or hypergraphs, providing a more expressive language to describe the surface structures. finally, in this paper only assembly steps are considered where a component combines with a basic component. however it may be more realistic to also include the possibility that large assemblies, perhaps each already composed of a number of basic components, combine. it is probably not too hard to adapt the approach to this: on the one hand, one may introduce operations that enable one to treat an assembly as a rule; hiding or encapsulating part of its internal structure, and on the other hand one may define suitable composition operations on processes, gluing them together over parts representing the surface of the components they represent. similar operations have been investigated for processes in the context of 17 / 18 volume 26 (2010) assemblies as graph processes concurrency theory, and it seems likely that a number of ideas studied there can be useful. it seems fair to conclude that, in spite of a number of reservations, the correspondence between graph rewriting and graph processes on the one hand and aggregation and assemblies on the other hand is simple and natural enough to deserve further attention. bibliography [cas06] l. d. castro. fundamentals of natural computing: basic concepts, algorithms, and applications. chapman and hall/crc press, 2006. [cmr96] a. corradini, u. montanari, f. rossi. graph processes. fundam. inf. 26(3-4):241– 265, 1996. [eept97] h. ehrig, k. ehrig, u. prange, g. taenzer. fundamentals of algebraic graph transformation. eatcs monographs in theoretical computer science. springer verlag, 1997. [ekmr97] h. ehrig, h.-j. kreowski, u. montanari, g. rozenberg. handbook of graph grammars and computing by graph transformation. world scientific, 1997. [etp+04] a. ehrenfeucht, t.harju, i. petre, d. prescott, g. rozenberg. computation in living cells gene assembly in ciliates. natural computing series. springer verlag, 2004. [hlp08] t. harju, c. li, i. petre. graph theoretic approach to parallel gene assembly. discrete applied mathematics 156(18):3416–3429, 2008. [kgl04] e. klavins, r. ghrist, d. lipsky. graph grammars for self assembling robotic systems. in proceedings of the 2004 ieee international conference on robotics and automation. pp. 5293–5300. 2004. [kr08] l. kari, g. rozenberg. the many facets of natural computing. commun. acm 51(10):72–83, 2008. [vj02] n. verlinden, d. janssens. algebraic properties of processes for local action systems. mathematical. structures in comp. sci. 12(4):423–448, 2002. [wlws98] e. winfree, f. liu, l. wenzler, n. seeman. design and self-assembly of twodimensional dna crystals. nature 394:539–544, 1998. [wms91] g. whitesides, j. mathias, c. seto. molecular self-assembly and nanochemistry a chemical strategy for the synthesis of nanostructures. science 254:1312–1319, 1991. festschrift h.-j. kreowski 18 / 18 introduction graph rewriting and self-assembly basic assumptions the embedding mechanism graph rewriting and processes graphs, rules and rewriting processes operations on assemblies operations on processes example algorithms recognizing the language of a context-free grammar recognizing the components of a test tube discussion fully symbolic tctl model checking for incomplete timed systems [1] [1]this work was partly supported by the german research council (dfg) as part of the transregional collaborative research center ``automatic verification and analysis of complex systems'' (sfb/tr 14 avacs, http://www.avacs.org/). electronic communications of the easst volume 66 (2013) proceedings of the automated verification of critical systems (avocs 2013) fully symbolic tctl model checking for incomplete timed systems 1 georges morbé and christoph scholl 15 pages guest editors: steve schneider, helen treharne managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 1 this work was partly supported by the german research council (dfg) as part of the transregional collaborative research center “automatic verification and analysis of complex systems” (sfb/tr 14 avacs, http://www.avacs.org/). http://www.easst.org/eceasst/ eceasst fully symbolic tctl model checking for incomplete timed systems ∗ georges morbé and christoph scholl department of computer science, university of freiburg, (morbe, scholl)@informatik.uni-freiburg.de abstract: in this paper we present a fully symbolic tctl model checking algorithm for incomplete timed systems. our algorithm is able to prove that a tctl property is violated or satisfied regardless of the implementation of unknown timed components in the system. for that purpose the algorithm computes overapproximations of sets of states fulfilling a tctl property φ for at least one implementation of the unknown components and under-approximations of sets of states fulfilling φ for all possible implementations of the unknown components. the algorithm works on a symbolic model for timed systems, called a finite state machine with time (fsmt), and makes use of fully symbolic state set representations containing both the clock values and the state variables. in order to handle incomplete timed systems our model checking algorithm deals with different communication methods between the system and its unknown components, e.g. shared integer variables and urgent and non-urgent synchronization. our experimental results demonstrate that it is possible to prove interesting properties at early stages of the design when parts of the overall system may not yet be finished. additionally, fading out components of a large system may dramatically reduce the complexity of the system and thus the effort for verification. keywords: timed automata, tctl model checking, black box model checking 1 introduction both the application areas and the complexity of real-time systems have grown with an enormous speed during the last decades. moreover, in many applications the correct operation of realtime systems is safety-critical. these reasons make verification of such systems crucial. timed automata (tas) [ad94, alu99] have become a standard for modeling real-time systems. they extend finite automata to the real-time domain by adding real-valued clock variables. all clock variables evolve over time with the same rate. during a discrete step that happens in zero-time a clock variable may be reset. model checking approaches for tas based on reachability analysis can be classified into semi symbolic and fully symbolic approaches. semi-symbolic approaches represent discrete locations of tas explicitly whereas sets of clock valuations are represented symbolically e.g. by unions of clock zones. clock zones are convex regions that result from an intersection of clock constraints of the form xi −x j ∼ d where d ∈q, ∼∈{<,≤,=,≥,>} and xi, x j are clock variables. uppaal [lpy97, bdl04], the probably most prominent semi-symbolic approach, represents clock zones by so-called difference bound matrices (dbms) and provides efficient methods for manipulating dbms. in [mps11] a fully symbolic model checking algorithm for reachability analysis based on finite state machines with time (fsmts) and linaigs (‘and-inverter-graphs ∗ this work was partly supported by the german research council (dfg) as part of the transregional collaborative research center “automatic verification and analysis of complex systems” (sfb/tr 14 avacs, http://www.avacs.org/). 1 / 15 volume 66 (2013) mailto:(morbe, scholl)@informatik.uni-freiburg.de fully symbolic tctl model checking for incomplete timed systems 1 with linear constraints’) [ddh+07, sdpk09, ddd+12] was presented. an fsmt is a formal model to represent real-time systems using transition functions and reset functions, which is especially suited for symbolic verification algorithms. tas may be translated into fsmts. linaigs provide a fully symbolic representation both for the continuous part (i.e. the clock values) and the discrete part (i.e. the state variables). a review of a number of alternative data structures for a fully symbolic representation of timed systems as well as their comparison to linaig representations can be found in [mps11] as well. in this paper we consider verification approaches for incomplete timed systems, i.e., timed systems that contain unknown components. unknown components are called ‘black boxes’ (bbs), whereas all known components are combined into the so-called ‘white box’ (wb). our verification algorithm deals with different communication methods between the wb and the bb, namely shared integer variables and urgent and non-urgent synchronization. we address two interesting questions: the question whether there exists a replacement of the bb such that a given property is satisfied (‘realizability’) and the question whether the property is satisfied for any possible replacement (‘validity’). the verification of incomplete timed systems can provide three major benefits: first of all, certain verification steps can be performed at early stages of the design of a timed system, when parts of the overall system may not yet be finished, so that errors can be detected as early as possible. second, complex parts of a complete timed system can be abstracted away and just the relevant components for verifying a certain property are considered. finally, the location of design errors in timed systems not satisfying some property can be narrowed down by iteratively masking potentially erroneous components. we use fully symbolic methods to do full tctl model checking for incomplete timed systems. we use over-approximations of the set of states satisfying the given tctl property φ for at least one implementation of the bb and we use under-approximations of set of states satisfying φ for all bb implementations. using these sets, we provide sound proofs of validity and nonrealizability. the paper is organized as follows. in sect. 2 we give a brief review of timed automata (tas), tctl model checking, and finite state machines with time (fsmts) as a fully symbolic representation for real-time systems. in sect. 3 we compare our approach to related work. our model checking algorithm for incomplete systems is given in sect. 4. we conclude the paper in sect. 6 after presenting experimental results in sect. 5. 2 preliminaries 2.1 timed automata real-time systems are often represented as timed automata (tas) [alu99, ad94]. tas use real-valued clock variables x := {x1,...,xn} to represent time. the set of clock constraints c (x) contains atomic constraints of the form (xi ∼ d) and (xi −x j ∼ d) with d ∈ q and ∼∈ {<,≤,=,≥,>}. we consider tas extended with integer variables. let int := {int1,...,intm} be a set of bounded integer variables with fixed lower and upper bounds for each integer. a ta has a finite number of discrete locations. a state of a ta is a combination of a location and a valuation of the clock variables and integer variables. when a ta stays in a location, a continuous transition may take place, i.e., all clock variables evolve over time with the same rate without changing the location or the values of the integers. in addition to continuous transitions, tas may take discrete transitions from one location to another (which happen in zero time). assignments to clocks and integers on a discrete transition take effect after taking the transition. proc. avocs 2013 2 / 15 eceasst r0 i = 2 a i := 2 a x1 ≤ 5 x0 ≥ 6 au x0 := 0 r1 r2 l0 l1 l2 au x1 := 0 a aui p0 p1 figure 1: timed system in general, transitions in tas are labeled with guards, (synchronization) actions, assignments to integers and resets of clocks. guards are restricted to conjunctions of clock constraints and constraints on integers. a transition can only be taken, if its guard is satisfied, i.e., if it is ‘enabled’. actions from act :={a1,...,ak} are used for synchronization between different tas. for our purposes they do not have a special meaning when considering one timed automaton in isolation. transitions in different automata labeled with the same actions have to be taken simultaneously. if a transition in a ta is not labeled with an action, then this transition can only be taken if all other tas stay in their current location. if several transitions without action are enabled at the same time it is chosen non-deterministically which one to take. resets are assignments to clock variables of the form xi := 0. if a transition is taken, then all resets and integer assignments on the transition are executed. a transition in a ta may be declared as urgent. whenever an urgent transition in the system is enabled, the current location must be left without any delay. just like transitions, actions may be declared as urgent. let au be an urgent action. if several ta components are composed in parallel and in all components containing au-transitions a transition labeled with au is enabled, then there must not be any time delay before taking a transition. example 1 the timed system shown in fig. 1 consists of two tas p0 and p1. each ta has three locations, p0 has clock variable x0, p1 has clock variable x1. the bounded integer i is used to pass numerical information from one ta to the other. initially, the timed system is in locations l0 and r0 with clock values x0 = 0 and x1 = 0 and integer value i = 0. when – starting from the initial state – time passes for 4.6 time units, e.g., the state s = (l0,r0,x0 = 4.6,x1 = 4.6,i = 0) is reached. the guards are used to enable transitions, for example the transition (r0,r1) is enabled in s whereas the transition (l0,l1) is only enabled when x0 has a value higher than or equal to 6. with the assignment i := 2 on the transition (l0,l1) integer i is set to 2. in p1 i is read in the guard i = 2 on the transition (r1,r2). clock variable x0 is reset on (l2,l0) in p0, x1 is reset on (r2,r0) in p1. both tas synchronize over the non-urgent action a and the urgent action au. because of a the two transitions (l2,l0) and (r2,r0) can only be taken in parallel. similarly, (l1,l2) and (r1,r2) synchronize over the action au. since au is an urgent action, when p0 is in l1, p1 is in r1, and i has a value of 2, time is not allowed to pass until the transitions (l1,l2) and (r1,r2) have been taken (in parallel). if there is a continuous or a discrete transition leading the ta from state s to state s′, we write s → s′. a trajectory of a t a is a finite or infinite sequence of states (s j) j≥0 with initial state s0 and s j−1 → s j for each j > 0. a state is reachable if there is a trajectory ending in that state. in many definitions for tas found in the literature (e.g. [lpy97]) locations are connected with so-called invariants as an alternative to urgent transitions and urgent actions. invariants in tas are conjunctions of clock constraints of the form xi ∼ d with ∼∈{<,≤}, d ∈ q+. a ta is only allowed to stay in a location as long as the location invariant is not violated. in some sense invariants are a means to define urgency implicitly: if a location l0 has the invariant x <= 5 and for instance one outgoing transition (synchronizing or non-synchronizing), then the outgoing transition becomes urgent as soon as the clock value of x equals 5. especially for synchronizations between different components we prefer to make it explicit whether they are urgent (i.e. require a transition without letting time pass) or not. for that reason we do not allow invariants in this paper. this is not a real restriction, because it is easy to see that for each ta with closed location invariants there is a ta without invariants which is semantically equivalent 3 / 15 volume 66 (2013) fully symbolic tctl model checking for incomplete timed systems 1 x ≤ 5 x ≤ 5 x = 5 ta ta′x := 0 x := 0 (a) urgent transitions x ≤ 5 x ≤ 5 x := 0 x = 5 ta ta′ a au a x := 0 (b) urgent synchroniztation figure 2: urgency caused by invariants (i.e. allows the same trajectories) and uses urgency only explicitly: lemma 1 for each ta without urgency and with closed location invariants of the form ∧ki=1(xi ≤ di) with clock variables xi, di ∈ q+ for i ∈ {1,...,k}, there exists a semantically equivalent ta with urgency and without invariants. consider a location l in timed automaton t a with the closed invariant x ≤ n. when transforming t a into a semantically equivalent ta t a′, l is copied into an equivalent location l′ without invariant. for each incoming transition of l′ without reset on x in the copy an additional guard of the form x ≤ n is added to guarantee that l′ cannot be entered with a clock value x > n. for each outgoing non-synchronizing (and non-urgent) transition e of l with a guard g, g∧(x = n) 6= 0, there are two edges in the copy: one non-urgent transition with all original labels and one urgent transition with the additional guard x = n corresponding to the boundary of the invariant. this has the effect that whenever in l′ the value of x is n a discrete transition must be taken to leave the location. for a transition with a guard g′, g′∧(x = n) 6= 0, leaving l labeled with a synchronizing (and non-urgent) action a, there are two transitions in t a′ as well: the original transition and an additional transition with identical labels, apart from the additional guard (x = n) and an urgent action au replacing the original action a. (in other components composed in parallel, transitions which were originally labeled by a are also duplicated into two edges, one with the non-urgent action a and one with the urgent action au.) figs. 2(a) and 2(b) illustrate these transformations. new urgent transitions (resp. transitions with urgent synchronization) are represented by dashed arrows. the connection of urgency and invariants has already been studied by bornot et al. in [bst97], introducing tas with deadlines that provide a general model for enforcing time progress conditions. in this model, transitions may be associated with deadlines and time progress is stopped whenever the deadline of such a transition is reached. urgent transitions are called eager transitions in [bst97], non-urgent transitions are called lazy transitions. according to [bst97] any ta with deadlines may be transformed into a ta using only eager and lazy transitions. a timed system is a system of p timed automata {t a1,...,t ap}. a timed system has an interleaving semantics, i.e., transitions in different tas may not be taken simultaneously unless they synchronize over non-urgent or urgent actions. for simplicity, we assume that only two timed automata are able to synchronize over a (binary) synchronization action. as usual, the composition of p timed automata is again a timed automaton. the interface of a ta t ai is formed by the synchronization actions that it has in common with other tas t a j (i 6= j) and by integers on its transitions that are written / read by other tas. in this paper we consider the urgency of a synchronization action in a ta t ai as a property of its interface. an urgent action au enforces an immediate synchronization without letting time pass, whereas time is allowed to pass before the synchronization if tas synchronize over a non-urgent action a. remark 1 a timed system t a1,...,t ap is called well-formed, if for each integer i and each synchronizing action a there is a unique ta t a j that is allowed to have transitions which are labeled by a and perform assignments to i. in well-formed systems write-conflicts on integers cannot occur. we only consider well-formed timed systems. proc. avocs 2013 4 / 15 eceasst in this paper we deal with incomplete networks of tas. in such a system not all components are known in detail. some components are modelled by a black box (bb) whose behavior is unknown. the remaining system is called white box (wb). a bb is a part of the system and like all other components it interacts with the rest of the system. there are several types of communication between a bb and the wb, namely (1) shared bounded integer variables, (2) non-urgent and (3) urgent synchronization actions. (1) with shared bounded integer variables numerical values within the integer bounds can be passed from one ta to another. in an incomplete system the bb is allowed to update certain shared integer variables. the exact value after the update is then unknown to the wb. (2) two enabled transitions synchronizing over a common non-urgent action have to be taken in parallel. if only one of the transitions is enabled, synchronization cannot take place and none of the two transitions can be taken. the problem of a synchronization between the wb and the bb consists in the fact that it is unclear when the bb sends a synchronization action. (3) as for non-urgent actions, transitions synchronizing over urgent actions have to be taken in parallel, but additionally a discrete transition must be taken without any delay, when an urgent synchronizing transition may take place. thus, a bb can cause two effects via urgent actions: it may enable a transition in the wb ‘waiting for synchronization’ (just as for non-urgent actions) and it can disable time evolution (continuous transitions) until a discrete transition is taken. with these three types of communication in a timed system the bb is not only able to affect the discrete behavior of the wb but, because of urgency, the timing behavior of the wb may also be influenced. remark 2 note that we do not allow communication via shared clock variables in this paper. this means that we assume local clocks of the wb and the bb components. in particular, clocks that are written (i.e., reset) in the bb are not allowed to be used in guards of wb components. we make the (realistic) assumption that only discrete information can be communicated from one component to the other. remark 3 furthermore, we restrict our consideration to bbs that cannot enable infinitely many non-synchronizing urgent transitions during a finite amount of time. we call those bbs ‘nonzeno’ bbs. other bbs are not interesting for us, because they can stop time evolution without any interaction with the wb components. 2.2 timed computation tree logic timed ctl [acd93, hnsy92, bk08] is an extension of the temporal logic ctl [ce82] used to express properties for real-time systems. as usual, eϕ holds in a state s when there exists a path starting in s that satisfies the path formula ϕ . aϕ holds in a state s when ϕ is satisfied on all paths starting in s. a path formula is defined by ϕ ::= φ uj ψ where j ⊆ r≥0 is an interval of real numbers. intuitively, a path satisfies φ uj ψ whenever at some point in j, a state satisfying ψ is reached and at all previous time instants φ∨ψ holds [bk08]. timed variants of the modal operators f (eventually) and g (always) can be derived as follows: f j φ = true uj φ, agj φ = ¬ef j¬φ, and egj φ = ¬af j¬φ. tctl formulas with j = [0,∞) may be considered as a ctl formula and can be verified using normal ctl model checking algorithms. any other 5 / 15 volume 66 (2013) fully symbolic tctl model checking for incomplete timed systems 1 intervals j 6= [0,∞) in a tctl formula can be handled as follows: for j 6= [0,∞) a new clock variable xnew is introduced that is neither used in the ta nor in the formula φ. the variable xnew is used to measure the elapsed time until a certain property holds. a tctl formula ef j φ holds in a state s, e.g., iff the formula ef(φ∧xnew ∈ j) holds in (s,xnew = 0). model checking of a tctl formula φ uses a recursive method to compute for all subformulas ψ the sets of states sat(ψ) for which ψ is satisfied (similar to ctl model checking). if ψ = ef j ψ1, j 6= [0,∞), e.g., then sat(ef j ψ1) is computed by a fixed point iteration starting from sat(ψ1 ∧xnew ∈ j) using the predecessor operation pre which computes for a state set s the set of all states s′ with s′ → s, s ∈ s. pre is repeatedly applied until the fixed point is reached. sat(ef j ψ1) simply results by fixing xnew to 0 in resulting fixed point. as usual, we say that a ta fulfills a property φ, if all initial states are included in sat(φ) (similar to ctl model checking). a complete exposition of tctl model checking can be found in [bk08],e.g.. 2.3 finite state machine with time (fsmt) in tas locations are represented explicitly. by parallel composition of several tas the number of locations may explode. for that reason fsmts have been considered for symbolic representations in [mps11]. fsmts do not define explicit representations of locations and thus, they are better suited for fully symbolic algorithms. an fsmt is basically an extension of finite state machines by real-valued clock variables. let x := {x1,...,xn} be the set of real-valued clock variables, y := {y1,..., yl} a set of (binary) state variables, i := {i1,...,ih} a set of (binary) input variables. let cb(x) be the set of arbitrary boolean combinations of clock constraints and cb(x,y ) be the set of arbitrary boolean combinations of clock constraints and state variables (similarly for cb(x,y,i)). as usual, c ∈ cb(x,y ) describes a subset of rn ×{0,1}l , namely the set of all valuations of variables in x and y that evaluate c to true. an fsmt is defined as follows: definition 1 (fsmt) a finite state machine with time, called fsmt, is a tuple 〈x,y,i,init, (δ1,...,δl),(resetx1,...,resetxn),urgent〉 where x :={x1,..., xn} is a set of clock variables, y := {y1,...,yl} is a set of state variables, i := {i1,...,ih} is a set of input variables, init : (r+0 )n × {0,1}l →{0,1} is a predicate describing the set of initial states, δi : (r+0 )n×{0,1}l ×{0,1}h → {0,1} (1 ≤ i ≤ l) are transition functions, resetx j : (r+0 )n×{0,1}l ×{0,1}h →{0,1} (1 ≤ j ≤ n) are reset functions, urgent : (r+0 ) n×{0,1}l ×{0,1}h →{0,1} is a predicate indicating when an urgent transition is enabled. the functions δi, resetx j and urgent can be represented by boolean combinations from cb(x,y,i), init can be represented by a boolean combination from cb(x,y ). a state of an fsmt is a valuation s = (xv1,...,x v n,y v 1,...,y v l ) ∈ (r + 0 ) n ×{0,1}l of the clock variables and the state variables. a valuation (yv1,...,y v l ) is also called a location of the fsmt. trajectories of an fsmt always start in states fulfilling init. an fsmt may perform discrete steps that are defined by transition functions δi based on the valuations of clocks, state variables, and inputs. when performing a discrete step, the state variable yi is set to 0 (1) iff δi evaluates to 0 (1) and a clock xi is reset to 0 iff resetxi evaluates to 1. moreover an fsmt may perform continuous steps (or time steps) where it stays in the same location, but lets time pass. this means that all clocks are increased by the same constant as long as the predicate urgent does not evaluate to 1. we consider systems of fsmts {f1,...,fp}, where the components are running in parallel. communication in such a system is realized just as for communicating fsms. fsmts communicate by reading each other’s state variables, clocks, and shared input variables. a system of proc. avocs 2013 6 / 15 eceasst fsmts therefore is again an fsmt. in [mps11] timed systems of several tas are translated into fsmts. the state bits y1,...,yl result from logarithmic encodings of locations and integer variables of the tas. the transition functions δi represent transitions in the tas and the reset functions are computed based on clock resets on these transitions. in order to obtain deterministic transition functions, self loops have to be added before the transformation and the decision between non-deterministic transitions is resolved by additional (pseudo-)inputs. additional input variables are used for the selection between different interleaved tas (in case of the so-called “pure interleaving behavior”) and for resolving read-/write-conflicts on integers and clocks (in case of the so-called “parallelized interleaving behavior”). altogether we arrive at a set of inputs {i1,...,ih}. in the following we abbreviate x1,...,xn by ~x, y1,...,yl by ~y, i1,...,ih by~i etc.. for ease of exposition we assume that there is a one-to-one relation between the integer values in the allowed range and the assignments to the state bits corresponding to these integers. we omit easy but slightly tedious technical details due to invalid codes. 3 related work our approach shares ideas with modal transition systems (mtss) [lt88, lx90] (and their successors like partial kripke structures (pkss) [bg99] and kripke modal transition systems (kmtss) [hjs01]) which exhibit mustand may-transitions between states. in our context musttransitions are transitions between states that exist for all possible bb implementations. maytransitions are transitions that may exist for at least one possible bb implementation. in that sense our method is strongly related to 3-valued model checking [hjs01] and its extensions using symbolic representations [cdeg03, ns04, ns13]. the approaches mentioned above were given for discrete systems, whereas we extend and adapt these ideas to timed systems and properties in tctl (timed computation tree logic) [acd93, hnsy92, bk08]. the module checking problem [kv96] may be seen as a validity problem (‘is a given property satisfied for all possible replacements of the bbs’) confined to a single bb (which models the environment behavior). kupferman and vardi use tree automata techniques to solve the module checking problem for discrete systems specified by branching time properties (ctl, ctl*) [kv96]. the realizability problem (‘does a replacement of the bbs exist, so that a given property is satisfied?’) is strongly connected to the controller synthesis problem [mps95, amps98], where a system interacts with an unknown controller. in the real-time domain the controller synthesis problem is modeled as a timed two-player game [bcd+, emp10, pem], where the controller (bb) tries to satisfy a safety property and plays against the wb (who tries to violate it). unsafe a bb a wb x := 0 x ≥ 6 l0 l1 l2 figure 3: bb example by fig. 3 we illustrate that these approaches with their ‘classical notion’ of controller synthesis are not able to decide the realizability question for safety properties as defined in our context. the figure shows a small wb with an initial location l0, two additional locations and two transitions labeled with the non-urgent action a and the guard x ≥ 6, respectively. the location l2 is considered to be unsafe and the task is to implement the bb in such a way that the unsafe location cannot be reached. the interface between the wb and the bb is given by a non-urgent synchronization action a. since the synchronization action a is non-urgent, it is not possible to define such an implementation for the bb, since time is allowed to pass until x = 6 and the transition to the unsafe location can be taken even if the bb is always in a location with an enabled outgoing transition labeled by a. however, the mentioned controller synthesis approaches lead to the result that the property is realizable, i.e., it is possible 7 / 15 volume 66 (2013) fully symbolic tctl model checking for incomplete timed systems 1 to replace the bb by a controller such that the unsafe location cannot be reached. this is due to the fact that these approaches assume that the controller is able to make transitions urgent (either explicitly or implicitly by invariants in the controller). this clearly gives the controller more power than allowed in our model where the bb and the wb are components with equal rights, that have to respect urgency or non-urgency of synchronization actions in the interface. if parts of an existing timed system that do not include invariants and communicate with their environment by non-urgent synchronization actions are abstracted away into a bb, then our approach may prove unrealizability (which means that the safety property is not valid for the original design) in cases when controller synthesis classifies the problem as realizable, since it gives the bb too much power. an example for such a case is given by the benchmark ‘arbiter error’ considered in sect. 5, where ‘classical’ controller synthesis cannot identify the error, which is found with our tctl model checking algorithm. additionally, whereas existing controller synthesis tools like uppaal-tiga [bcd+] consider only reachability of safety properties, our algorithm goes beyond and is able to handle full tctl properties. 4 model checking of incomplete timed systems tctl model checking for complete timed systems is based on the computation of a set sat(φ) of all states satisfying a tctl formula φ, followed by checking whether all initial states are included in this set (see also sect. 2.2). the situation becomes more complex, if we consider incomplete timed systems, since for each implementation of the bb we may have different state sets satisfying φ. for that reason we do not compute the set sat(φ), but two sets sat∃(φ) and sat∀(φ): sat∃(φ) contains all states, for which there is at least one bb implementation so that φ is satisfied. in a similar manner, sat∀(φ) contains all states, for which φ is satisfied for all possible bb implementations. it is easy to see that the following holds: • a property φ is valid for an incomplete timed system (i.e. for all bb implementations the property is satisfied), if all initial states are included in sat∀(φ). • a property φ is not realizable for an incomplete timed system (i.e. there is no bb implementation that satisfies φ), if there is an initial state that does not belong to sat∃(φ). in order to obtain sound results for validity resp. non-realizability, it is enough to compute approximations for sat∃(φ) and sat∀(φ). if we replace sat∀(φ) by an under-approximation sat appr∀ (φ) ⊆ sat∀(φ) and sat∃(φ) by an over-approximation sat appr ∃ (φ) ⊇ sat∃(φ), then the statements made above certainly remain correct. (an initial state that is in sat appr∀ (φ) is certainly in sat∀(φ) as well; an initial state that is not in sat appr ∃ (φ) is not in sat∃(φ) either.) in the following we show how to compute such sets. in order to simplify notations we usually write sat∃(φ) and sat∀(φ), even if the computed sets are approximations. in the next section we start with transformations needed to compute fully symbolic representations of sets sat∃(φ) and sat∀(φ). 4.1 modeling incomplete systems more precisely, we begin with a sketch of how to extend the translation of tas into fsmts for incomplete systems. for our model checking algorithm the communication between the bb and the wb is of particular importance. we distinguish between four different types of transitions in the wb: proc. avocs 2013 8 / 15 eceasst (1) non-urgent transitions without synchronization with the bb, called nu-transitions in the following (2) urgent transitions without synchronization with the bb, called u-transitions (3) transitions with a non-urgent synchronization with the bb, called nu-sync-transitions (4) transitions with an urgent synchronization with the bb, called u-sync-transitions in our algorithm we do not work with one transition (reset) function for the incomplete system at hand, but with different transition (reset) functions for different types of transitions. first, we consider only the transitions in the tas that do not synchronize with the bb at all (i.e. only nu-transitions and u-transitions) and apply the transformation from [mps11] (including addition of self loops etc.) resulting in transition functions δ no−synci (~x,~y,~i). secondly, we consider only u-sync-transitions, leading to transition functions δ u−synci (~x,~y,~i). these transition functions are computed by the transformation from [mps11] restricted to u-sync-transitions. the transition functions δ no−synci and δ u−sync i are used in the computation of sat∀(φ). to compute sat∃(φ) a third transition function is needed. here, actions used for communication with the bb on nu-sync-transitions and u-sync-transitions can be omitted, because there can always be a bb implementation sending the requested action such that synchronizing transitions are always enabled. the functions δ alli (~x,~y,~i) for the state bits yi are then computed by the transformation from [mps11] considering all transitions in the wb. similarly we compute three reset functions for each clock variable xi ∈ x . two reset functions are used for the computation of sat∀(φ), one for the resets on the nu-transitions and u-transitions (reset no−syncxi (~x,~y,~i)) and a second for u-sync-transitions (reset u−sync xi (~x,~y,~i)). a third reset function (reset allxi (~x,~y, ~i)) for all transitions in the wb (with neglected synchronization actions with the bb) is needed for the computation of sat∃(φ). finally, we need two additional urgency predicates in our algorithm (sect. 4.2): uno−sync(~x,~y) is a predicate evaluating to 1, if a u-transition is enabled in state (~x,~y) and uu−sync(~x,~y) is a predicate evaluating to 1, if a u-sync-transition is enabled in state (~x,~y). 4.2 model checking algorithm now we show how to do fully symbolic tctl model checking for incomplete real-time systems modeled as incomplete fsmts by computing fully symbolic representations of the sets sat∃(φ) and sat∀(φ) as defined above.1 the most important ingredient of tctl model checking is the predecessor operation pre (see also sect. 2.2); thus the essential contribution is how to define two variants of pre for computing sat∃ and sat∀. definition 2 (pre∃(s), pre∀(s)) s′ is included into pre∃(s) iff for at least one bb implementation there is a transition s′ → s with s ∈ s. (this transition can be regarded as a may transition following the notion from [lt88]). a state s′ is included in pre∀(s) iff for all bb implementations there is a transition s′ → s with s ∈ s. (the transition is a must transition.) for formulas like φ = ef ψ whose evaluation needs a fixed point iteration we make use of pre∃ to compute sat∃(φ) (instead of pre which is used for complete systems). in the special case φ = ef ψ we start with the set sat∃(ψ) ( that at least includes the set of states that may satisfy ψ 1 if clear from the context, we do not always differentiate between sets like sat∃(φ) and predicates describing these sets. 9 / 15 volume 66 (2013) fully symbolic tctl model checking for incomplete timed systems 1 depending on the concrete bb implementation) and we use pre∃ to compute the set of states that can reach sat∃(ψ) via one ‘may transition’. by iteratively applying pre∃ we obtain sat∃(ef ψ) that includes all states from which there is a computation path to a state from sat∃(ψ) for at least one bb implementation. likewise for sat∀(φ) we replace pre by pre∀. in the special case φ = ef ψ we start with the set sat∀(ψ) ( that at most includes the set of states that definitely satisfy ψ independently from the bb implementation) and we use pre∀ to compute the set of states which can reach sat∀(ψ) via one ‘must transition’, i.e. independently from the bb implementation. again, we obtain sat∀(ef ψ) by iteratively applying pre∀. the remaining operations are more or less straightforward. it is easy to see that sat∀(¬φ) = ¬sat∃(φ), sat∃(¬φ) = ¬sat∀(φ), i.e., negation plays a special role here, since it turns ‘existential quantification of bbs into universal quantification’ and over-approximation into underapproximation (and vice-versa). moreover, it holds sat∀(φ1 ∧φ2) = sat∀(φ1)∧sat∀(φ2) and sat∃(φ1∧φ2)⊆ sat∃(φ1)∧sat∃(φ2). in the second case we only have ‘⊆’ instead of ‘=’, since a certain state may fulfill φ1∧¬φ2 for certain bb implementations and ¬φ1∧φ2 for all others, thus it belongs to sat∃(φ1)∧sat∃(φ2), but not to sat∃(φ1 ∧φ2). for approximations we overapproximate by identifying sat appr∃ (φ1 ∧φ2) with sat appr ∃ (φ1)∧sat appr ∃ (φ2). a second source of approximation stems from the fact that we assume that the bb can make different decisions based on the current state of the wb, i.e., the bb ‘can read the state bits of the wb’. (note that the same assumption is implicitly made in classical controller synthesis approaches for safety properties as well [bcd+, emp10, pem].) the evaluation of general tctl formulas needs both pre∀ and pre∃. in the following we describe the computation of pre∀(φ) and pre∃(φ) separately for discrete steps and time steps. we start with pre∀(φ). 4.3 pred∀(φ) – the discrete step for pre∀(φ) starting with a state set φ(~x,~y) the discrete (backward) step needed for pre∀(φ) computes all predecessors from which φ can be reached over a discrete transition in the wb, independently from the implementation of the bb. since it is possible that the bb does not synchronize with the wb at all, we consider only u-transitions and nu-transitions which are described by the functions δ no−synci . the discrete step can then be computed similarly as in [mps11] using the transition functions δ no−synci and the reset functions reset no−syncxi . lemma 2 the resulting state set pred∀(φ)(~x,~y) contains only states from which φ(~x,~y) is reachable by a discrete transition in the wb independently from any bb behavior. the proof of the lemma is straightforward, since due to the interleaving semantics of tas, the u-transitions and nu-transitions of the wb can always be taken independently from the implementation of the bb. on the other hand, discrete steps that reach φ independently from the bb use only u-transitions and nu-transitions. this is easy to see by considering a special bb implementation bbno−sync that never synchronizes with the wb and thus disables all nu-sync-transitions and u-sync-transitions. 4.4 prec∀(φ) – the time step for pre∀(φ) proc. avocs 2013 10 / 15 eceasst l0 i = 1 au i = 0 au x = 5 x = 6 x = 7 au ibb l1 l2 figure 4: time step starting with a state set φ(~x,~y) the time step for pre∀(φ) computes all predecessors from which φ(~x,~y) can be reached through time passing, independently from the bb implementation. because of urgent synchronization, the bb can affect the timing behaviour in the wb by enabling a u-sync-transition and thus stopping time evolution. example 2 we illustrate the time step by a small example shown in fig. 4. here, the bb communicates with the wb over an urgent synchronization action au and a shared integer i with i ∈{0,1}. let φ be the state set already computed by our backward model checking algorithm. we assume that (l0,x = 7,i = 0) ∈ φ, (l0,x = 7,i = 1) ∈ φ and ask whether we can include (l0,x = 0,i = 0) into the states reaching φ independently from the bb implementation. if the bb never sends the action au, then no u-sync-transitions (dashed lines) would be enabled and time would be allowed to pass starting from (l0,x = 0,i = 0). (the time evolution could be interrupted by discrete urgent and non-synchronizing transitions inside the bb possibly writing on i, but only by finitely many of those, since we consider only non-zeno bbs, see remark 3.) finally we would arrive at (l0,x = 7,i = 0) or (l0,x = 7,i = 1). however, the situation is more complicated, since we have to consider all possible bb implementations including bbs which send au and thus disable time evolution. we consider two cases. case 1: the bb is not allowed to write i on synchronizing transitions with au, because i is written on such transitions in the wb (see remark 1). then the bb cannot change i on the u-sync-transitions in fig. 4. (all the same, the bb can always interrupt time evolutions by discrete urgent and non-synchronizing transitions inside the bb and switch between i = 0 and i = 1.) only if both (l1,x = 5,i = 0) ∈ φ and (l2,x = 6,i = 1) ∈ φ, we can conclude that we can definitely reach φ from (l0,x = 0,i = 0). time evolution may lead from (l0,x = 0,i = 0) to (l0,x = 5,i = 0). if the bb then enables the transition from l0 to l1 in fig. 4, then φ is reached via this u-sync-transition. if not, time evolution may continue until x = 6. again, if the bb then enables the transition from l0 to l2 (this presumes that the bb has set i := 1 before), then φ is reached via this u-sync-transition. otherwise the time evolution continues until (l0,x = 7,i = 0) or (l0,x = 7,i = 1) that are both in φ. case 2: the bb is allowed to write i on synchronizing transitions. then the bb may switch the integer i from 0 to 1 while taking the u-sync-transitions in fig. 4. compared to case 1, we have thus to demand (l1,x = 5,i = 1) ∈ φ and (l2,x = 6,i = 0) ∈ φ as well, if we want to guarantee that we can definitely reach φ from (l0,x = 0,i = 0). based on the ideas given in ex. 2 we arrive at the following formula prec∀(φ) for the time step: prec∀(φ)(~x,~y) = [ ∧nj=1 (x j ≥ 0) ] ∧( ¬uno−sync(~x,~y)∧ [ uu−sync(~x,~y) =⇒ ∀~yu−syncbb ∀~i pre u−sync d (φ)(~x,~y,~i) ]) ∧ ∃λ [ (λ > 0)∧∀~yallbb ( φ(~x +~λ ,~y)∧ { ∀λ ′(0 < λ ′ < λ ) =⇒ ( ¬uno−sync(~x + ~λ ′,~y)∧[ uu−sync(~x + ~λ ′,~y) =⇒ ∀~yu−syncbb ∀~i pre u−sync d (φ)(~x + ~λ ′,~y,~i) ])})] (1) with~x+~λ abbreviated for (x1 +λ ,...,xn +λ ) for a scalar λ , pre u−sync d (φ)(~x,~y,~i) being obtained from φ(~x,~y) by computing a discrete step using δ u−synci (~x,~y,~i) and reset u−sync x j (~x,~y,~i). the subset ~yallbb ⊆~y represents the state variables corresponding to the integer variables that are allowed to be written by the bb (see case 1 of ex. 2) and ~yu−syncbb ⊆~yallbb represents the state variables that are allowed to be written by the bb on u-sync-transitions (see case 2 of ex. 2). 11 / 15 volume 66 (2013) fully symbolic tctl model checking for incomplete timed systems 1 lemma 3 the resulting state set prec∀(φ)(~x,~y) contains only states from which states of φ can be reached (via time evolution and/or via u-sync-transitions), independently from the bb behaviour. the proof of the lemma is rather tedious and omitted due to lack of space. the ideas and all relevant arguments and cases have been given in ex. 2. 4.5 pred∃(φ) – the discrete step for pre∃(φ) in pre∃(φ) the discrete step computes all predecessors such that there exists a bb implementation for which φ can be reached over a discrete transition in the wb. pred∃(φ)(~x,~y) can be computed as in [mps11] using δ alli (~x,~y,~i) and reset all xi (~x,~y, ~i). lemma 4 the resulting state set pred∃(φ)(~x,~y) contains all states for which there exists a bb implementation such that φ(~x,~y) is reachable by a discrete transition in the wb. the proof follows from the following argument: the result corresponds to a backwards evaluation of discrete wb transitions of any kind (nu-transitions, u-transitions, nu-sync-transitions, u-sync-transitions). of course, more transitions can never be enabled in the wb, not even by a bb implementation that always provides all synchronization actions needed to enable synchronizing transitions in the wb. 4.6 prec∃(φ) – the time step for pre∃(φ) the time step for pre∃(φ) can be described by prec∃(φ)(~x,~y) = [ ∧nj=1 (x j ≥ 0) ] ∧¬uno−sync(~x,~y)∧∃∃λ [ (λ > 0)∧( (∃~yallbbφ(~x +~λ ,~y))∧ { ∀λ ′(0 < λ ′ < λ ) =⇒ ( ∃~yallbb¬uno−sync(~x + ~λ ′,~y) )})] (2) lemma 5 the resulting state set prec∃(φ)(~x,~y) contains all states for which there exists a bb implementation such that φ(~x,~y) is reachable through time elapsing. the correctness of the lemma follows from the following facts: there may be a time evolution of length λ > 0 from (~x,~y) to a state (~x +~λ ,~y′) in φ, if (1) ~y′ results from ~y by replacing state bits ~yallbb corresponding to shared integer variables and (2) the time evolution is not stopped by urgent transitions in between. the reason for part (1) is given by the fact that an arbitrary bb is able to interrupt the time evolution by non-synchronizing urgent transitions that change ~y into ~y′ by writing to the shared integers. this is expressed by the existential quantification ∃~yallbb before φ(~x +~λ ) in eqn. (2). part (2) is ensured as follows: first, condition ¬uno−sync(~x,~y) in eqn. (2) ensures that no u-transition is enabled in (~x,~y). secondly, condition ∃~yallbb¬uno−sync(~x + ~λ ′,~y) has to hold for each λ ′ between 0 and λ . since for each λ ′ between 0 and λ the bb may arbitrarily interrupt the time evolution and write on the shared integer variables, it is enough that u-transitions are disabled for an arbitrary value of the shared integer variables ~yallbb (which is expressed by the quantification ∃~yallbb). 4.7 discrete and time steps together in our implementation we apply alternating discrete steps and time steps for the operations pre∃ and pre∀. for pre∃ we additionally apply an existential quantification of the shared integer proc. avocs 2013 12 / 15 eceasst variables~yallbb after each application of pre d ∃ and pre c ∃. this existential quantification corresponds to an interleaving with a potential discrete backwards step of the bb. since we have to consider all possible bb implementations for pre∃, we have to assume that the shared integers can be set to arbitrary values in this step. since for pre∀ we only have to consider effects shared by all possible bb implementations and there are certainly bb implementations that do not write shared integers at all, we completely omit potential discrete bb backward steps (and thus the existential quantification of ~yallbb) for pre∀. 5 experiments we implemented the tctl model checking algorithm for incomplete timed systems in the prototype model checker fsmt-mc [mps11]. tab. 1 shows the results of the new method on several parameterized benchmarks with parameter n. parameterized benchmarks made it easy for us to generate sets of increasingly complex benchmarks for comparison. actually we do not consider parameterized benchmarks as the main field of application for our algorithm and thus we did not make use of symmetry reduction, neither within our tool nor within any competitor. ‘cpp’ is a system of communicating parallel processes. the complete version of cpp has n components, an incomplete version with bb only 2 wb components. the benchmark ‘arbiter’ [mps11] models n processes which are controlled by a distributed arbiter. the complete version contains 2n + 1 components, an incomplete version contains n + 3 wb components. the leader election benchmark (‘leader’) [efgp10] models a timed leader election in a ring protocol. we modeled a version of the system with an error such that the leader is not found within a certain time limit. the complete version has n components, the incomplete version has only 3 wb components, but their size increases linearly with n. the carrier sense multiple access with collision detection (‘csma’) benchmark [yov97] is a system with several senders trying to access a common bus. in its complete version it has n + 3 components, the incomplete version has 3 components; one of them increases linearly with n. in all cases the wb components communicate with the bb components which are abstracted away by exchanging integers values and urgent resp. non-urgent synchronization actions.2 the first column (‘nbr.’) in tab. 1 gives the parameters n. all times in tab. 1 are given in cpu seconds. we ran fsmt-mc on the complete version (‘comp.’) and on the incomplete version (‘inc.’) of the benchmarks and compare the results to the state-of-the-art model checkers uppaal v.4 (upp.), red 8 and kronos 2.5 (kr.). uppaal performs a forward analysis and red does a backward traversal. both can only be used for reachability analysis whereas kronos can also be used for full tctl model checking, but cannot handle benchmarks containing integer variables (like ‘arbiter’ and ‘leader’). all benchmarks were originally modeled as tas and were automatically translated into fsmts [mps11]. cpu times of the (un-optimized) translator for the complete (‘comp.’) and the incomplete (‘inc.’) timed systems are given in tab. 1 in columns ta2fsmt. in all cases when the model checker did not timeout, the sum of translation times and model checking times did not exceed the timeout either. the experiments have been conducted on an intel xeon with 3.3 ghz with a time limit of 2 cpu hours and a memory limit of 2 gb. for the benchmark cpp we test freedom of zeno behaviour (‘cpp zeno’) with the property φnz = ag(ef{=1}true). to verify this property we need full tctl model checking and therefore we compare our results only to the tool kronos. for the complete system, we detect zeno behaviour (i.e. φnz is not satisfied) for n up to 6, kronos reaches n = 3. for the incomplete system fsmt-mc easily verifies non-realizability of φnz for n up to 50. this means that the reason for zeno behaviour lies in the wb components and cannot be fixed by bb implementa2 more details about the benchmarks as well as the benchmark files themselves can be found at http://www.informatik.uni-freiburg.de/∼morbe/bb-tctl/. 13 / 15 volume 66 (2013) fully symbolic tctl model checking for incomplete timed systems 1 tions. (for the cpp benchmark this result is more interesting than the shorter cpu times, since the size of the wbs remains constant for increasing n.) for the arbiter benchmark we considered a correct version (arbiter) and an erroneous version (arbiter error). for the complete and correct version our model checking algorithm can prove correctness for n up to 16, whereas uppaal and red cannot go beyond n = 6. for the incomplete (correct) version, fsmt-mc can prove validity of the safety property for n up to 50. for the erroneous version, the situation is similar. fsmt-mc is able to prove that the safety property is not realizable for the incomplete (and incorrect) version, i.e., no bb implementation can prevent the system from reaching the unsafe states. this is achieved with much smaller run times than for the complete version. remember that for the arbiter as well as for the following benchmarks the complexity of the wb increases with n. for the incomplete leader benchmark we can prove unrealizability for large systems as well, i.e., independently from the bb behaviour no leader can be found within a given time limit. in contrast to the cases above uppaal and red outperform our tool for the complete system. on the csma benchmark we tested freedom of zeno behaviour with property φnz . kronos falsifies property φnz for systems with up to 7 senders. for incomplete variants with bb fsmtmc easily proves unrealizability of φnz for large systems using full tctl model checking. nbr. upp. red fsmt-mc ta2fsmt comp. inc. comp. inc. ar bi te r 5 30.5 4.6 12.6 2.3 1.7 6.4 6 3556.9 40.7 20.9 3.0 2.9 8.8 7 to to 25.6 3.3 3.7 10.8 16 to to 1687.6 24.5 18.4 52.2 17 to to to 28.1 20.4 58.3 50 to to to 561.7 214.2 512.5 ar bi te r er ro r 3 0.1 0.6 1.3 1.0 1.2 2.7 4 0.1 to 1.2 1.4 1.4 4.4 10 2648.0 to 5.9 2.3 7.4 21.4 11 to to 6.8 2.3 8.7 25.7 49 to to 122.5 16.9 199.5 490.7 50 to to to 17.2 209.3 509.9 le ad er 5 0.4 18.3 to 124.7 4.0 15.3 6 2.3 to to 72.6 5.7 21.1 10 2960.7 to to 163.0 17.7 59.8 11 to to to 149.5 21.4 72.3 50 to to to 421.8 3702.2 2376.5 nbr. kr. fsmt-mc ta2fsmt comp. inc. comp. inc. c p p ze no 3 0.5 6.1 7.3 1.5 3.0 4 to 131.5 5.5 2.2 4.6 6 to 2205.1 5.5 4.8 9.0 7 to to 8.2 6.4 11.9 49 to to 16.8 345.0 502.9 50 to to 16.0 357.1 522.1 c s m a 3 0.1 to 6.2 1.2 2.2 6 0.7 to 7.2 2.5 5.0 7 0.5 to 10.5 3.2 6.4 8 to to 11.9 4.0 7.9 49 to to 13.0 138.3 184.2 50 to to 18.2 142.5 192.5 table 1: experimental results in summary, we observe that after abstracting timed components our new tctl model checker is still able to prove interesting validity and unrealizability results within much smaller times than needed for the complete system. 6 conclusion we presented a fully symbolic tctl model checking algorithm for fsmts able to handle incomplete timed systems. we described the computation of the discrete step and the time step to be able to handle incomplete fsmts communicating with the bb over shared integers and urgent and non-urgent synchronization. for a given tctl property and an incomplete fsmt our model checking algorithm can prove non-realizability (there is no bb implementation such that the property is satisfied) and validity (the property is satisfied for all possible bb implementations). the experimental results show that it is possible to prove interesting properties early when parts of the overall system may not yet be finished. additionally the results demonstrate proc. avocs 2013 14 / 15 eceasst that fading out complete components of a timed system dramatically reduces the complexity of the system and the verification effort. as mentioned in sect. 4 our algorithm is sound, but approximate since different decisions of the bb can be made based on different states of the wb. an interesting task for the future would be to investigate exact (or more exact) solutions taking the ‘restricted degree of informedness’ of the bb into account (possibly for restricted scenarios like one single bb, e.g..). bibliography [acd93] alur, courcoubetis, dill. model-checking in dense real-time. information and computation, 1993. [ad94] alur, dill. a theory of timed automata. theoretical computer science, 1994. [alu99] alur. timed automata. theoretical computer science, 1999. [amps98] asarin, maler, pnueli, sifakis. controller synthesis for timed automata. 1998. [bcd+] behrmann, cougnard, david, fleury, larsen, li. uppaal-tiga: time for playing games! cav’07. [bdl04] behrmann, david, larsen. a tutorial on uppaal. in sfm. 2004. [bg99] bruns, godefroid. model checking partial state spaces with 3-valued temporal logics. in cav. 1999. [bk08] baier, katoen. principles of model checking (representation and mind series). the mit press, 2008. [bst97] s. bornot, j. sifakis, s. tripakis. modeling urgency in timed systems. in compos. 1997. [cdeg03] chechik, devereux, easterbrook, gurfinkel. multi-valued symbolic model-checking. acm trans. softw. eng. methodol. 12, 2003. [ce82] clarke, emerson. design and synthesis of synchronization skeletons using branching-time temporal logic. in logic of programs. 1982. [ddd+12] damm, dierks, disch, hagemann, pigorsch, scholl, waldmann, wirtz. exact and fully symbolic verification of linear hybrid automata with large discrete state spaces. sci. comput. program. 77, 2012. [ddh+07] damm, disch, hungar, jacobs, pang, pigorsch, scholl, waldmann, wirtz. exact state set representations in the verification of linear hybrid systems with large discrete state space. in proc. of atva. 2007. [efgp10] ehlers, fass, gerke, peter. fully symbolic timed model checking using constraint matrix diagrams. in proc. of rtss. 2010. [emp10] ehlers, mattmüller, peter. combining symbolic representations for solving timed games. in proc. of formats. 2010. [hjs01] huth, jagadeesan, schmidt. modal transition systems: a foundation for three-valued program analysis. in europ. symp. on programming. 2001. [hnsy92] henzinger, nicollin, sifakis, yovine. symbolic model checking for real-time systems. information and computation, 1992. [kv96] o. kupferman, m. y. vardi. module checking. in cav. lncs 1102, pp. 75–86. 1996. [lpy97] larsen, pettersson, yi. uppaal in a nutshell. sttt 1, 1997. [lt88] larsen, thomsen. a modal process logic. in lics. 1988. [lx90] larsen, xinxin. equation solving using modal transition systems. in lics. 1990. [mps95] maler, pnueli, sifakis. on the synthesis of discrete controllers for timed systems. in stacs. 1995. [mps11] morbé, pigorsch, scholl. fully symbolic model checking for timed automata. in proc. of cav. 2011. [ns04] nopper, scholl. approximate symbolic model checking for incomplete designs. in fmcad. 2004. [ns13] nopper, scholl. symbolic model checking for incomplete designs with flexible modeling of unknowns. ieee transactions on computers, 2013. [pem] peter, ehlers, mattmüller. synthia: verification and synthesis for timed automata. cav’11. [sdpk09] scholl, disch, pigorsch, kupferschmid. computing optimized representations for non-convex polyhedra by detection and removal of redundant linear constraints. in tools and algorithms for the construction and analysis of systems. 2009. [yov97] yovine. kronos: a verification tool for real-time systems. journal on software tools for technology transfer, 1997. 15 / 15 volume 66 (2013) introduction preliminaries timed automata timed computation tree logic finite state machine with time (fsmt) related work model checking of incomplete timed systems modeling incomplete systems model checking algorithm pred() – the discrete step for pre() prec() – the time step for pre() pred() – the discrete step for pre() prec() – the time step for pre() discrete and time steps together experiments conclusion what algebraic graph transformations can do for model transformations electronic communications of the easst volume 30 (2010) international colloquium on graph and model transformation – on the occasion of the 65th birthday of hartmut ehrig (gramot 2010) what algebraic graph transformations can do for model transformations gabriele taentzer 10 pages guest editors: claudia ermel, hartmut ehrig, fernando orejas, gabriele taentzer managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst what algebraic graph transformations can do for model transformations gabriele taentzer philipps-universität marburg germany abstract: model transformations are key activities in model-driven development (mdd). a number of model transformation approaches have emerged for different purposes and with different backgrounds. this paper focusses on the use of algebraic graph transformation concepts to specify and verify model transformations in mdd. keywords: model transformation, graph transformation 1 introduction model transformations play a central role in model-driven software development. they are used e.g. to refactor models, to analyze them, to translate them to intermediate models, and to generate code. we distinguish endogenous transformations taking place within one modeling language from exogenous ones which are translations between modeling languages [ch06]. model-to-model transformations are usually distinguished from model-to-text transformations. (compare also eclipse modeling projects at [emp].) why does this distinction exist? while model-to-model transformation approaches such as qvt [qvt], atl [emp] and graph transformation-based approaches [snz08] like atom3 [lv02], fujaba [fntz98], henshin [abj+10], grgen [gbg+06], moflon [akk+08], viatra2 [vb07] and vmts [llmc05], transform models based on their underlying syntax structure only, model-to-text transformations performed by tools such as jet and velocity, are usually mixed approaches. the abstract syntax of an input model is transformed to some text in concrete syntax, often program text. these approaches are usually based on templates which can be considered as “clozes” where gaps are filled with information coming from the input model. i.e. these transformations are often performed in a weakly structured and untyped manner. no guarantees are given that the resulting text is syntactically correct. to better cope with this situation, wachsmuth [wac09] has equipped attribute grammars with template-based model transformations. thus, model transformations are defined based on both, the concrete and abstract syntax definition. in contrast, model-to-model transformations are usually based on abstract syntax structures only. models are often considered to be visual, although this is not an inherent property of models. it is very natural to consider the underlying structure of a visual model as a graph. in case of the eclipse modeling framework [emf] which has developed to a quasi-standard modeling technology, the underlying structure of an emf model can be considered as a graph with a spanning tree (or spanning forest, i.e. several spanning trees) established by containment relations. in the following, we discuss the specification of model transformations by graph transformations and especially, by algebraic graph transformations, in contrast to other transformation volume 30 (2010) what algebraic graph transformations can do for model transformations approaches. since model transformations can be considered as special programs specified by a formal transformation approach, there is the basic hope that their correctness can be verified. we consider interesting properties for model transformation and discuss techniques for showing them. finally, we give an outlook on the future of model transformations and sketch which role algebraic graph transformations can play in future. 2 specification of model transformations a variety of specification paradigms have been applied to model-to-model transformations such as object-oriented, rule-based, constraint-based, and imperative concepts. see [ch06] for an overview on various model transformation approaches following these paradigms purely or in combination. in the following, we highlight some features of the rule and graph-based definition of model transformations using graph transformation concepts and especially, the algebraic approach. basic features. graph transformation is a rule-based technique which can be a great advantage for using them to specify model transformations. instead of explicitly programming each model navigation and each transformation action, model transformation can be specified at a higher level of abstraction. rules define if-then patterns which allow a transformation specification being closer to the model domain it is applied to than usual programming. e.g. to perform a rule-based transformation a pre-defined transformation engine supporting rule matching and application is used. therefore, the implementation of the matching algorithm is hidden in this engine. moreover, the application order of rules needs not necessarily be specified, but may be specified if necessary, in total or just partially. considering the transformation of visual models, graph transformation seems to be a natural choice to manipulate their underlying graph structures. a well-defined approach such as the algebraic graph transformation [eept06] guarantees that the underlying structure of the resulting model is again a graph and thus, is structure consistent (i.e. no dangling edges occur). moreover, the resulting model has to be correctly typed. typed algebraic graph transformations have been shown to always lead to well-typed transformation results. to support a natural mapping of meta modeling concepts, the concept of node type inheritance has been developed for algebraic graph transformation. emf model transformations can be defined as a special kind of graph transformations not destroying the spanning tree (forest) property of models. thus, emf model transformations have to fulfill additional structural properties. algebraic graph transformation can be used to ensure these additional properties [bet08]. a related model transformation approach which formalizes emf models is moment2 [bm09] being based on rewriting logic as implemented in maude. advanced transformation concepts. model transformation approaches based on graph transformation concepts are all rule-based techniques, but differ in the way rules are applied and how non-determinism in rule application is reduced or even eliminated. an early comparison of graph transformation approaches is presented in [aeh+99]. later, several graph transformation tools proc. gramot 2010 eceasst have been applied and compared wrt. one and the same model transformation case in [teg+05]. in the following, we do not compare basic features but highlight some advanced transformation concepts. most graph transformation approaches allow to specify negative application conditions for rules, originally introduced in [hht96]. more complex conditions can be specified by e.g. graph patterns in viatra and nested conditions in henshin. furthermore, the order of rule application can be determined by specifying a control flow using e.g. story diagrams in fujaba, activity diagrams in vmts, asm programs in viatra, and transformation units in henshin. it is up to future work to compare these control mechanisms. for better reuse of transformation parts, generic and meta-transformations can be defined in viatra. for handling collections of flexible size such as the set of all features belonging to a class, a forall construct is needed which is e.g. offered by viatra directly. in the algebraic context, we use amalgamated graph transformation where a kernel rule is applied exactly once and multi-rules which contain the kernel rule as subrule are applied as often as possible. all their applications overlap in the kernel rule application. usually, each multi-rule application covers one collection element. as shown in [bet09], this concept can also be extended to emf model transformation in a straightforward way. kinds of model transformations. graph transformation can be used to specify endogenous as well as exogenous model transformations. moreover, thanks to triple graph grammars [sch94] they are also useful to specify model integrations and model synchronizations. the well-known double-pushout approach to graph transformation [eept06] can be interpreted as a kind of in-place transformation where new parts are directly integrated into the existing graph. in addition, it is also allowed to delete existing graph parts from the given graph. to keep track with graph manipulations, the formal definition distinguishes an original graph from a resulting one. a partial graph morphism in between precisely defines the relation between both graphs. in-place transformations are well suited to specify model refactorings which transform models such that their structures improve while their semantics is preserved. see e.g. [mtr07, rlk+08] for the specification of model refactorings by algebraic graph transformation concepts. a model transformation tool which is based on algebraic graph transformation concepts is henshin [abj+10], an eclipse plug-in for model transformation based on the eclipse modeling framework (emf). in contrast to in-place transformation, out-place model transformations consider source models as input models which are read but not altered, while target models are built up without using them for checking pre-conditions of transformations. a graph transformation approach which is mainly dedicated to this kind of exogenous model transformation is e.g. vmts. a famous approach, not only for exogenous model transformations but also for model integrations and synchronizations, are triple graph grammars (tggs) [sch94, ks06]. they distinguish three graphs, namely a source graph, a target graph, and a correspondence graph which is mapped to each of the other two for establishing a correspondence relation between source and target graphs. a comprehensive implementation of tggs is given by moflon [akrs06] using a declarative qvt-like language based on fujaba. it does not only support model-to-model transformations, but also model-to-text transformations using a template-based code generator which supports xslt and velocity. recently, ehrig et al. started to formalize and to extend the volume 30 (2010) what algebraic graph transformations can do for model transformations main concepts of tggs by algebraic graph transformation concepts in order to provide a clear formal basis to characterize consistent transformation. (compare e.g. [eehp09].) 3 verification of model transformations since model transformations are reused heavily in mdd, they should be of high quality. it is common practice to extensively test model transformations. their verification is still in its infancy. in the following, we discuss which properties are interesting to be verified and spot on first results. structure and type consistency. as pointed out in the previous section, a basic property of model transformations is that resulting models are structure and type consistent. transformation approaches such as algebraic graph transformation guarantee this property already automatically by definition without any additional verification effort. (compare [eept06].) functional behavior. furthermore, model transformations shall terminate. termination is an issue for all model transformations which may contain loops. imperative model transformation approaches offer explicit loops as control constructs, while rule-based model transformations such as those defined by graph transformation concepts can contain implicit loops occurring from the application of rules as long as applicable. termination cannot always be shown, since model transformation approaches are usually turing-complete. thus, we are confronted with the halting problem in general. but there are first approaches to define sufficient termination conditions for model transformation systems, especially for algebraic graph transformation systems (see e.g. [eept06, vve+06, bh10] ). the uniqueness of transformation results is another general property of model transformations to be discussed. in more detail, we like to check if the transformation result is unique up to isomorphism for a given input model. it depends on the kind of model transformation, if this strict property is needed. if e.g. a code generator provided two different programs for one and the same input model, we would expect that they both are semantically equivalent wrt. the input model. (i.e. both programs exhibit the same observable behavior when being executed.) however, since semantical equivalence is often difficult to show, proving the uniqueness of transformation results is, although more strict, more practicable. since rule-based transformations may use an implicit application control, the uniqueness of transformations is especially important for them. algebraic graph transformation offers a rich theory to show that transformation systems are confluent, i.e. yield unique results only. this theory is based on a result for general rewriting systems which states that a rewrite system which is locally confluent and terminating, is confluent in general. local confluence of graph transformations can be shown based on critical pairs, an approach which has been lifted from term rewriting systems to graph transformation systems [plu94, eept06]. a critical pair shows a conflicting situation in a minimal context. if all critical pairs can be shown to be confluent, the complete transformation system is locally confluent. if critical pairs cannot be shown to be confluent, a potential conflict is reported. usual strategies to resolve or to even avoid conflicts from the beginning reduce concurrency and enforce rule applications in fixed orders. proc. gramot 2010 eceasst syntactical and semantical correctness. additionally to these pretty general properties, transformation results also need to be elements of target languages. this means that they have to be syntactically and semantically correct. the syntax of modeling languages is usually given by meta models [mof], i.e. a resulting model has to be type consistent and has to obey all additional well-formedness rules of the meta model. as already pointed out, algebraic graph transformations guarantee type consistent results. well-formedness rules which can be expressed by graph constraints [hp09] can be used as post-conditions to check transformation results. furthermore, there is a technique to translate graph constraints to application conditions of transformation rules, i.e. to translate them to pre-conditions of transformation rules. these new pre-conditions have to compared with already existing ones to find out if the original transformation system leads to syntactically correct models only. if not, additional pre-conditions have to be taken into account to improve the transformation system. that way algebraic graph transformations provide us with an automatic and efficient procedure to check models for syntactical correctness. semantical correctness of transformation results is more difficult to verify. we distinguish between the static and dynamic analysis of transformation results. static analyses of properties which can be specified by additional constraints can be performed analogously to the check for syntactical correctness. further recent approaches apply model checking to graph transformations e.g. [rsv04] or start using a theorem prover as presented in [str08] and [ggl+06]. to analyze the dynamic semantics of transformation results we assume that dynamic semantics have been defined for source and target languages. let us assume that each langauge has an operational semantics given by an algebraic graph transformation and the source semantic rules have been translated to corresponding target semantic rules. in that case, ehrig et al. have shown semantical correctness for behavior models in [ee08] by proving that each execution step in the source model corresponds to an execution step in the target model. for the special case of model refactorings, semantics preservation can be shown by bisimilarity of the original and the resulting model after a model refactoring step using the borrowed context technique (see [hhk10]). verification of bidirectional model transformations. in [ste08], stevens argues that bidirectional model transformations should have the following properties: (1) correctness meaning that forward and backward transformations have to enforce consistency between source and target models, (2) hippocraticness ensuring that forward and backward transformations are applied only if the consistency relation is not established, and (3) undoability meaning that a model change which is immediately undone leads again to a consistent model pair. for triple graph grammars, the consistency relation between source and target models is specified by triple rules. in [eehp09], the equivalence of triple transformations and their corresponding forward and backward transformations is investigated. thus, conditions for the correctness of forward and backward transformations are elaborated. furthermore, results concerning completeness and termination of forward and backward transformations, always wrt. their triple transformations, are considered. a forward transformation is called complete if each model of the source language can be transformed to a model of the target language, and vice versa. it is up to future work to develop further results which are concerned with hippocraticness and undoability as stated above. we presented essential verification techniques for model transformations here and sketched volume 30 (2010) what algebraic graph transformations can do for model transformations how they can be verified based on algebraic graph transformation. it is up to future work, to perform an in-depth comparison of different verification techniques for model transformations. of course, we have to keep in mind that only a few model transformation approaches are formally defined such that verifications can be performed. 4 outlook model transformations form an interesting research field with a lot of new research problems to be solved. in addition future work already mentioned, we spot on a selection of topics in the following where the application of algebraic graph transformation concepts seems to be very promising: the application of algebraic graph transformation concepts to emf model transformation as presented in [bet08] shows that formal concepts can be well applied in a practical setting. furthermore, we showed the important property that resulting emf models are structure and type consistent by construction. we expect that the rich theory of algebraic graph transformation can be easily adapted to this kind of emf model transformations leading to interesting verification techniques for emf model transformations. as stated above, distinct transformation approaches have emerged for model-to-model and model-to-text transformations. we can observe a recent trend where model-to-model transformation approaches such as atl are also applied to model-to-text transformations. this means that transformation results, being texts in this case, are computed on the basis of abstract syntax structures. approaches like jamopp [hjsw09] for example, define meta models for java and provide model parsers and printers. thus having a meta model for a textual language at hand, model-to-model transformation approaches and especially graph transformation approaches can be applied guaranteeing well-structured and well-typed transformation results also for model-totext transformations. moreover, verification of model-to-text transformations concerning interesting properties would become possible. it is up to future work to test and probably improve the efficiency of model-to-model transformation implementations compared to model-to-text transformations. especially a comparison with extended model-to-text transformation approaches such as the one by wachsmuth [wac09] would be interesting. last but not least, we can observe that the deployment of model transformation techniques in software engineering increases and more complex forms of model transformations are needed where not only one input and one output model are considered but a number of models are involved. see e.g. multi-directional model transformations in [ks06]. example scenarios are coherent refactorings of several heterogeneous models and/or code, code generation from several interrelated models such as those in the graphical modeling framework [gmf] yielding a number of code files and model weaving. to conclude, algebraic graph transformation seems to be a promising formal basis for different kinds of model transformations. it is especially promising to be used for specifying and reasoning about larger networks of model transformations, since it is based on category theory which provides us with rigorous structuring concepts. proc. gramot 2010 eceasst bibliography [abj+10] t. arendt, e. biermann, s. jurack, c. krause, g. taentzer. henshin: advanced concepts and tools for in-place emf model transformation. in model driven engineering languages and systems, 13th international conference, models 2010, oslo, norway. proceedings. lncs 6394, pp. 121–135. springer, 2010. to appear. [aeh+99] m. andries, g. engels, a. habel, b. hoffmann, h.-j. kreowski, s. kuske, d. plump, a. schürr, g. taentzer. graph transformation for specification and programming. sci. comput. program. 34(1):1–54, 1999. doi:http://dx.doi.org/10.1016/s0167-6423(98)00023-9 [akk+08] c. amelunxen, f. klar, a. königs, t. rötschke, a. schürr. metamodel-based tool integration with moflon. in icse ’08: proceedings of the 30th international conference on software engineering. pp. 807–810. acm, new york, ny, usa, 2008. doi:http://doi.acm.org/10.1145/1368088.1368206 [akrs06] c. amelunxen, a. königs, t. rötschke, a. schürr. moflon: a standard compliant metamodeling framework with graph transformations. in model driven architecture foundations and applications: second european conference. pp. 361–375. springer verlag, lncs 4066, 2006. [bet08] e. biermann, c. ermel, g. taentzer. precise semantics of emf model transformations by graph transformation. in czarnecki et al. (eds.), model driven engineering languages and systems, 11th international conference, models 2008, toulouse, france, september 28 october 3, 2008. proceedings. lecture notes in computer science 5301, pp. 53–67. springer, 2008. [bet09] e. biermann, c. ermel, g. taentzer. lifting parallel graph transformation concepts to model transformation based on the eclipse modeling framework. eceasst 26, 2009. [bh10] d. bisztray, r. heckel. combining termination criteria by isolating deletion. in graph transformations 5th international conference, icgt 2010, enschede, the netherlands, september 27 october 2, 2010. proceedings. lncs 6372, pp. 203– 217. springer, 2010. [bm09] a. boronat, j. meseguer. moment2: emf model transformations in maude. in xiv jornadas de ingenierı́a del software y bases de datos (jisbd 2009), san sebastián, spain, september 8-11, 2009. pp. 178–179. 2009. [ch06] k. czarnecki, s. helsen. feature-based survey of model transformation approaches. ibm systems journal 45(3):621–646, 2006. [ee08] h. ehrig, c. ermel. semantical correctness and completeness of model transformations using graph and rule transformation. in ehrig et al. (eds.), proc. international conference on graph transformation (icgt’08). lncs 5214, pp. 194–210. springer verlag, heidelberg, 2008. volume 30 (2010) http://dx.doi.org/http://dx.doi.org/10.1016/s0167-6423(98)00023-9 http://dx.doi.org/http://doi.acm.org/10.1145/1368088.1368206 what algebraic graph transformations can do for model transformations [eehp09] h. ehrig, c. ermel, f. hermann, u. prange. on-the-fly construction, correctness and completeness of model transformations based on triple graph grammars. in schürr and selic (eds.), acm/ieee 12th international conference on model driven engineering languages and systems (models’09). volume 5795, pp. 241–255. springer lncs, 2009. [eept06] h. ehrig, k. ehrig, u. prange, g. taentzer. fundamentals of algebraic graph transformation. monographs in theoretical computer science. an eatcs series. springer, 2006. [emf] emf. eclipse modeling framework. http://www.eclipse.com/emf. [emp] emp. eclipse modeling project. http://www.eclipse.org/modeling/. [fntz98] t. fischer, j. niere, l. torunski, a. zündorf. story diagrams: a new graph rewrite language based on the unified modeling language. in engels and rozenberg (eds.), proc. of the 6th int. workshop on theory and application of graph transformation. lncs 1764, pp. 296–309. springer, november 1998. [gbg+06] r. geiß, g. v. batz, d. grund, s. hack, a. szalkowski. grgen: a fast spo-based graph rewriting tool. in graph transformations, third international conference, icgt 2006, natal, rio grande do norte, brazil, september 17-23, 2006, proceedings. lncs 4178, pp. 383–397. springer, 2006. [ggl+06] h. giese, s. glesner, j. leitner, w. schäfer, r. wagner. towards verified model transformations. in in proc. of modeva workshop associated to models’06. pp. 78–93. le commissariat l’energie atomique cea, 2006. [gmf] gmf. graphical modeling framework. http://www.eclipse.com/gmf. [hhk10] f. herrmann, m. hülsbusch, b. könig. specification and verification of model transformations. eceasst 30, 2010. in this volume. [hht96] a. habel, r. heckel, g. taentzer. graph grammars with negative application conditions. fundam. inform. 26(3/4):287–313, 1996. [hjsw09] f. heidenreich, j. johannes, m. seifert, c. wende. jamopp: the java model parser and printer. technical report tud-fi09-10, technical university of dresden, institut für softwareund multimediatechnik, 2009. technical report. [hp09] a. habel, k.-h. pennemann. correctness of high-level transformation systems relative to nested conditions. mathematical structures in computer science 19:1 – 52, 2009. [ks06] a. königs, a. schürr. tool integration with triple graph grammars a survey. electronic notes in theoretical computer science 148, 113-150, 2006. proc. gramot 2010 http://www.eclipse.com/emf http://www.eclipse.org/modeling/ http://www.eclipse.com/gmf eceasst [llmc05] t. levendovszky, l. lengyel, g. mezei, h. charaf. a systematic approach to metamodeling environments and model transformation systems in vmts. electron. notes theor. comput. sci. 127(1):65–75, 2005. doi:http://dx.doi.org/10.1016/j.entcs.2004.12.040 [lv02] j. de lara, h. vangheluwe. atom3: a tool for multi-formalism and metamodelling. in fundamental approaches to software engineering, 5th international conference, fase 2002, held as part of the joint european conferences on theory and practice of software, etaps 2002, grenoble, france, april 8-12, 2002, proceedings. lncs 2306, pp. 174–188. springer, 2002. [mof] mof. meta object facility (mof) core. url: http://www.omg.org/spec/mof. [mtr07] t. mens, g. taentzer, o. runge. analysing refactoring dependencies using graph transformation. software and system modeling 6(3):269–285, 2007. [plu94] d. plump. critical pairs in term graph rewriting. in mathematical foundations of computer science 1994, 19th international symposium, mfcs’94, kosice, slovakia, august 22 26, 1994, proceedings. lncs 841, pp. 556–566. springer, 1994. [qvt] qvt. mof 2.0 query / views / transformation (qvt). url: http://www.omg.org/ spec/qvt. [rlk+08] g. rangel, l. lambers, b. könig, h. ehrig, p. baldan. behavior preservation in model refactoring using dpo transformations with borrowed contexts. in graph transformations, 4th international conference, icgt 2008, leicester, united kingdom, september 7-13, 2008. proceedings. lecture notes in computer science 5214, pp. 242–256. springer, 2008. [rsv04] a. rensink, schmidt, d. varró. model checking graph transformations: a comparison of two approaches. in ehrig et al. (eds.), international conference on graph transformations (icgt). lecture notes in computer science 3256, pp. 226– 241. springer verlag, berlin, 2004. [sch94] a. schürr. specification of graph translators with triple graph grammars. in mayr et al. (eds.), graph-theoretic concepts in computer science, 20th international workshop, wg ’94, herrsching, germany, june 16-18, 1994, proceedings. lecture notes in computer science 903, pp. 151–163. springer, 1994. [snz08] a. schürr, m. nagl, a. zündorf (eds.). applications of graph transformations with industrial relevance, third international symposium, agtive 2007, kassel, germany, october 10-12, 2007, revised selected and invited papers. lecture notes in computer science 5088. springer, 2008. [ste08] p. stevens. towards an algebraic theory of bidirectional transformations. in graph transformations, 4th international conference, icgt 2008, leicester, united kingdom, september 7-13, 2008. proceedings. lecture notes in computer science 5214, pp. 1–17. springer, 2008. volume 30 (2010) http://dx.doi.org/http://dx.doi.org/10.1016/j.entcs.2004.12.040 http://www.omg.org/spec/mof http://www.omg.org/spec/qvt http://www.omg.org/spec/qvt what algebraic graph transformations can do for model transformations [str08] m. strecker. modeling and verifying graph transformations in proof assistants. electron. notes theor. comput. sci. 203(1):135–148, 2008. doi:http://dx.doi.org/10.1016/j.entcs.2008.03.039 [teg+05] g. taentzer, k. ehrig, e. guerra, j. de lara, l. lengyel, t. levendovsky, u. prange, d. varro, s. varro-gyapay (eds.). model transformation by graph transformation: a comparative study. 2005. http://sosym.dcs.kcl.ac.uk/events/mtip05. [vb07] d. varró, a. balogh. the model transformation language of the viatra2 framework. sci. comput. program. 68(3):214–234, 2007. [vve+06] d. varró, s. varró-gyapay, h. ehrig, u. prange, g. taentzer. termination analysis of model transformations by petri nets. in graph transformations, third international conference, icgt 2006, natal, rio grande do norte, brazil, september 17-23, 2006, proceedings. lncs 4178, pp. 260–274. springer, 2006. [wac09] g. wachsmuth. a formal way from text to code templates. in fundamental approaches to software engineering, 12th international conference, fase 2009, held as part of the joint european conferences on theory and practice of software, etaps 2009, york, uk, march 22-29, 2009. proceedings. lncs 5503, pp. 109– 123. springer, 2009. proc. gramot 2010 http://dx.doi.org/http://dx.doi.org/10.1016/j.entcs.2008.03.039 http://sosym.dcs.kcl.ac.uk/events/mtip05 introduction specification of model transformations verification of model transformations outlook simulating multigraph transformations using simple graphs electronic communications of the easst volume 6 (2007) proceedings of the sixth international workshop on graph transformation and visual modeling techniques (gt-vmt 2007) simulating multigraph transformations using simple graphs iovka boneva, frank hermann, harmen kastenberg, and arend rensink 14 pages guest editors: karsten ehrig, holger giese managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst simulating multigraph transformations using simple graphs iovka boneva1, frank hermann2, harmen kastenberg1, and arend rensink1 1 bonevai, h.kastenberg, rensink [at] cs.utwente.nl department of computer science, university of twente p.o. box 217, nl-7500 ae enschede, the netherlands 2frank [at] cs.tu-berlin.de department of electrical engineering and computer science technical university of berlin, d-10587 berlin, germany abstract: application of graph transformations for software verification and model transformation is an emergent field of research. in particular, graph transformation approaches provide a natural way of modelling object oriented systems and semantics of object-oriented languages. there exist a number of tools for graph transformations that are often specialised in a particular kind of graphs and/or graph transformation approaches, depending on the desired application domain. the main drawback of this diversity is the lack of interoperability. in this paper we show how (typed) multigraph production systems can be translated into (typed) simple-graph production systems. the presented construction enables the use of multigraphs with dpo transformation approach in tools that only support simple graphs with spo transformation approach, e.g. the groove tool. keywords: graph transformations, graph transformation tools, tool interoperability, multigraphs, simple graphs 1 introduction application of graph transformations for software verification and model transformation is an emergent field of research. in particular, graph transformation approaches provide a natural way of modelling object oriented systems and semantics of object-oriented languages [kkr06] or graphical modelling languages such as the uml [omg05], see for instance [hau06]. for performing the actual graph transformations, different approaches are around ranging from hyperedge replacement approach (see e.g. [dkh97]), logic based approach (see e.g. [cou97]) to different algebraic approaches such as single pushout (spo) [ehk+97] and double pushout (dpo) [cmr+97] approach. these different approaches all have specific application areas in which their features are used in an optimal fashion. another difference is the use of either multigraphs or simple graphs for modelling the application domain. whereas the former is more general, the latter suites better when using graphs for representing relations between objects in order to reason about these objects using (first-order) logical formulae [ren04b]. while spo can be applied for both multigraphs and simple graphs, dpo is not defined for simple graphs in general. 1 / 14 volume 6 (2007) mailto:bonevai, h.kastenberg, rensink [at] cs.utwente.nl mailto:frank [at] cs.tu-berlin.de simulating multigraph transformations for most tools performing graph transformations, the graph representation formalism and the transformation approach are determined by the targeted application domain. for instance, the groove tool [ren04a] is designed for modelling dynamic systems and verifying properties about their behaviour by generating all possible system configurations. groove uses simple graphs and performs spo based graph transformations. another example is the agg tool [ter99] which handles multigraphs with spo and is used e.g. for independence and termination analysis on graph grammars. the main drawback of this diversity in tools is their poor interoperability. one attempt to bridge this gap is the introduction of a common language used for exchanging models among tools, called the graph exchange language (or gxl for short) [sshw]. in order to extend this work for also exchanging the transformation specifications, gtxl [tae01] has been proposed. however, since every implementation of a specific approach is not aware of details of other approaches, it is very difficult to include all the features in one common standard and thereby enable tools to perform semantically equivalent transformations. in a previous work [hkm06] we have proposed translations of graph production systems between groove and agg, but these translations were too specific and are not applicable in a more general context. moreover, these translations were not invertible. in the current paper, we generalise these translations to a context that is tool independent. we show how one can encode typed multigraph production systems into simple-graph production systems, and simulate dpo transformations of multigraphs with spo transformations on simple graphs. then we shortly discuss how dpo transformations for multigraphs can be handled by a tool supporting only spo on simple graphs. these results should allow, for instance, to use the groove tool (or any other tool using simple graphs) with multigraphs. as a further extension, we believe that it would be possible to apply the theory of subobject transformation systems [chs06] in groove. running example. throughout this paper we will clarify our ideas and results using a simple example. in the example we model the dynamic behaviour of lists and objects that can be elements of some specific lists. one object may occur in a list several times. we assume that objects can be created instantly by the environment (which we do not model in this example). once objects are around, different actions can be performed on lists and objects, like adding objects to lists and moving, removing or copying objects. fig. 1 depicts a possible configuration with two lists: one containing a single object and another having two entries referring to the same object. in each configuration we assume that all listand object-instances have their own identity, although we do not show these identities. entryentry object object entry list list figure 1: example configuration of lists and objects. proc. gt-vmt 2007 2 / 14 eceasst organisation of the paper. the remaining of the paper is structured as follows. in section 2 we provide a formal basis for the rest of the paper. in section 3 we define our translation of multigraphs to simple graphs and prove the equivalence of dpo transformations on multigraphs on the one hand, and spo transformations on (special) simple graphs on the other hand. in section 4 we describe how this equivalence can be extended to typed/labelled graphs. then, in section 5 we describe how dpo transformations on multigraphs can be handled by tools implementing the spo transformation approach, such as the groove tool. finally, in section 6 concludes and gives some hints on the way we would like to use the results of this work for improving state space exploration in groove. 2 background 2.1 graphs and graph morphisms graphs are a very powerful means of modelling systems and their behaviour. as will become clear in this paper, in some cases it is very important which notion of graphs is used, since the theory applied may depend on this choice quite heavily. the graph concept is differently interpreted by people working in different domains or even in the same domain. graphs can e.g. be deterministic, directed or labelled. in this paper we will explicitly distinguish between what we call multigraphs and simple graphs. definition 1 (multigraph, multigraph morphism) a multigraph is a tuple g =〈vg, eg, srcg, tgtg〉 where: • vg is a set of nodes (or vertexes); • eg is a set of edges; • srcg, tgtg : eg→vg are source and target functions. a multigraph morphism f : g→h is a pair 〈 fv , fe〉, where fv : vg →vh and fe : eg →eh are functions compatible with src and tgt functions, i.e. • fv ◦srcg = srch ◦ fe ; • fv ◦tgtg = tgth ◦ fe . � definition 2 (simple graph, simple graph morphism) let lab be a finite set of labels. a simple graph labelled over lab is a tuple g = 〈vg, eg〉 where • vg is a set of nodes (or vertexes); • eg ⊆vg ×lab×vg is a set of edges. the source and target functions srcg, tgtg : eg →vg are defined for any edge e = (v, l, v ′) ∈ eg by srcg(e) = v and tgtg(e) = v ′. a simple graph morphism f : g→h is a pair 〈 fv , fe〉, where fv : vg →vh and fe : eg→eh are functions compatible with src and tgt functions and with labelling, i.e. for any edge (v, l, v′)∈ eg, fe ((v, l, v ′)) = ( fv (v), l, fv (v ′)). � 3 / 14 volume 6 (2007) simulating multigraph transformations in the sequel we will call a graph morphism f : g→ h total if its components fv and fe are total functions, and partial if its components are total functions from g′ to h , where g′ is some subgraph of g. an injective morphism is a morphism induced by injective functions. we will denote the set of multigraphs as m g and the set of simple graphs over lab as s g (lab). hereafter, we will use the term graph to designate either a multigraph or a simple graph. in our formal definitions we use unlabelled multigraphs and labelled simple graphs. we start with unlabelled multigraphs in order to keep proofs simple. however, all results of the paper can be extended to labelled graphs, as it will be discussed in section 4. therefore, our examples will already freely use labels on both nodes and edges. 2.2 graph transformations when modelling system states as graphs, the dynamics of the system can be specified by graph transformations. the changes of states are then described by graph productions, also called graph transformation rules. definition 3 (graph production) a graph production p consists of two graphs l and r, being its left-hand-side and right-hand-side, respectively, together with a partial graph morphism from l to r, called the rule morphism. we often denote a graph production p as p : l→r, also using p when referring to the rule morphism. when combining a graph g with a set p of graph productions, we get a graph production system gps = 〈g, p〉. in a graph production system, g is called the start graph. by applying graph productions to g we can derive other graphs. the applications of graph productions are defined on categories in which the objects are multigraphs or simple graphs and the arrows are the corresponding graph morphisms. for an introduction to category theory, see e.g. [bw95]. whether a rule is applicable and to what resulting graph a derivation leads depends on the particular graph transformation approach being applied. in this paper we distinguish between the single pushout (spo) [ehk+97] and the double pushout (dpo) [cmr+97] approach. for applying a production in the spo approach, we only need an occurrence of the left-hand-side of the graph production. when the application of a graph production would delete a node but not all of its adjacent edges, those dangling edges will also be removed. furthermore, if the application prescribes one node (or edge) to be both deleted and preserved, this conflict is solved in favour of deletion. these conflicts are resolved in the dpo approach by forbidding such applications of productions, i.e. the dpo approach requires additional conditions on the applications which are called the dangling edge condition and the identification condition (together referred to as the gluing condition). in the dpo approach, a graph production p : l→r is depicted as a span l l ← k r → r of total graph morphisms, such that k = l∩r, l : dom(p)→l, and r : dom(p)→r. to be deterministic, it is necessary that either rule morphisms or matchings are injective. we will now define applications of graph productions and the corresponding derivations for both spo and dpo. definition 4 (derivation) given a graph production p : l→r and a graph g, a total graph morphism m : l→g is called matching. the direct derivation from a graph g to a graph h through proc. gt-vmt 2007 4 / 14 eceasst the production p via matching m, denoted g = p,m =⇒ h , is constructed: (spo) as the pushout of p and m in the category of graphs and partial graph morphisms (see fig. 2(a)); (dpo) by taking, in the category of graphs and total graph morphisms, first the pushout complement d (with k : k→d and l∗: d→g) of l and m, if it exists (ensured by the gluing condition), and then the pushout of r and k (see fig. 2(b)). � l p / m �� (po) r m∗ �� g p∗ / h (a) spo l m �� (po) k l oo r // k �� (po) r m∗ �� g d l∗ oo r∗ // h (b) dpo figure 2: graph h as the result of an spo and a dpo derivation. intuitively, applying a graph production p to a graph g can be seen as a sequence of two actions: find an occurrence (matching) of l in g and then replace that occurrence by r. this then results in the graph h . an example direct derivation is shown in fig. 4. an important difference between spo and dpo is the fact that dpo does not work on simple graphs with arbitrary matchings, because in some cases the required pushout construction is not unique or does not exist. in this paper we do apply dpo on simple graphs, but then ensure that we restrict to a special class of matchings and/or morphisms. this issue will be discussed in section 3. 2.3 back to the example now that we have introduced the notion of graphs and the graph transformation technique, we can recall the example and give a formal description of the actions. in fig. 3 we specify some of the actions from the example as graph transformation rules by showing their left-hand-side and right-hand-side graph. the rule morphisms in fig. 3 are defined by the placing of the elements. entry listlist r object p l object (a) add p l object list entry list r object entry list entry list (b) copy figure 3: graph transformation rules for some of the actions in the example. in fig. 4 we show a single (spo) rule application in which we apply the copy-rule (fig. 3(b)) on a graph g consisting of two lists each containing one object, also showing the resulting graph h . 5 / 14 volume 6 (2007) simulating multigraph transformations list entry list entry list entry list entry list entry list object list entry entry m p* m* p g h rl entry object object objectobject object list figure 4: an example direct derivation. 3 from multigraphs to simple graphs and back again in this section we describe our translation between multigraphs and simple graphs. at a categorical level we will show that these translations are functors which are isomorphisms, moreover being each others inverse. 3.1 from multigraphs to simple graphs consider the set of labels lmg = {s, t}. the function sim maps multigraphs from m g into simple graphs in s g (lmg) as follows: every edge e in the multigraph with source node vs and target node vt becomes a special node (this we call a proxy node) with two outgoing edges (e, s, vs) and (e, t, vt). thus, we will use e as a variable ranging over edges of multigraphs and proxy nodes in simple graphs. fig. 5 shows an example applying the sim function. formally, let g = 〈vg, eg, srcg, tgtg〉 be a multigraph. then sim(g) is the graph h = 〈vh , eh〉 with • vh = vg ∪eg, that is, edges of g are nodes in h ; • eh = ⋃ e∈eg {(e, s, srcg(e)), (e, t, tgtg(e))}. the sim function can be extended on graph morphisms. that is, if g and h are multigraphs and m : g→h is a morphism, then sim(m) : sim(g)→sim(h) is the morphism defined by 1: • for all v in vsim(g) (i.e. v ∈vg ∪eg), (sim(m))(v) = m(v); • for all (e, l, v) in esim(g), (sim(m))((e, l, v)) = (m(e), l, m(v)). note that the definition of sim(m) on edges of sim(g) ensures that sim(m) is indeed a simple graph morphism. 1 in this definition m is supposed to be a total morphism. this is not a restriction as a partial morphism is a total morphism on a subgraph. proc. gt-vmt 2007 6 / 14 eceasst t s s t figure 5: encoding of a multigraph (on the left) into simple graphs with proxy nodes (on the right) by the sim function. 3.2 from simple graphs to multigraphs let s g m g be the set of bipartite simple graphs over lmg satisfying the following conditions: g = (v, e) ∈ s g m g if 1. v = vn ∪ve where vn and ve are two disjoint sets; 2. e = es∪et where es and et are disjoint sets and es ⊆ve×{s}×vn, and et ⊆ve×{t}×vn; 3. any node e in ve has exactly two adjacent edges (e, s, v ′ n)∈es and (e, t, v ′′ n ) for some v ′ n, v ′′ n ∈ vn. we now define the function sim−1 : s g m g →m g as follows: if g = 〈vn ∪ve, eg〉 where vn and ve are as in the description of s g m g stated above, then h = sim −1(g) is the graph 〈v, e, src, tgt〉 such that v = vn, e = ve, and for any e ∈ e , src(e) = vs and tgt(e) = vt, where vs, vt ∈vn are the nodes such that (e, s, vs), (e, t, vt)∈eg. we know by condition 3 of the definition of the set of graphs s g m g that the nodes vs and vt exist and are unique. the sim−1 function can also be extended on graph morphisms. if m : g→h is a simple graph morphism, then sim−1(m) : sim−1(g)→sim−1(h) is the multigraph morphism such that for any x in vg, (sim −1(m))(x) = m(x). we now show that sim−1(m) defined this way is indeed a multigraph morphism. let g′ = sim−1(g), h′ = sim−1(h) and m′ = sim−1(m). then for any edge e ∈ eg′, (m ′◦ srcg′)(e) = m(vs) where vs is the unique node in g such that (e, s, vs) is an edge of g. as m is a simple graph morphism, (m(e), s, m(vs)) is an edge in h . on the other hand, (srch′ ◦m ′)(e) = srch′(m(e)) is the unique node v ′ s in h such that (m(e), s, v ′ s) is a edge in h . we deduce then that both (m(e), s, v′s) and (m(e), s, m(vs)) are edges in h . by uniqueness of v ′ s, necessarily v ′ s = m(vs), so m′◦srcg′ = srch′ ◦m ′. we can see in a similar way that m′◦tgtg′ = tgth′ ◦m ′. it is not very hard to see that s g m g is exactly the set of simple graphs that are images of multigraphs by the sim function, and that the function sim−1 is the inverse of the function sim. this will be formally stated in the following section. 3.3 categories for multigraphs and simple graphs in this section we define the categories mg and sgmg(lmg) on which dpo transformation is defined for multigraphs and for simple graphs that are encodings of multigraphs. we show also that the functions sim and sim−1 define free functors from mg to sgmg(lmg) and from 7 / 14 volume 6 (2007) simulating multigraph transformations sgmg(lmg) to mg respectively. this will guarantee that performing dpo transformations on multigraphs can be simulated by dpo transformations on simple graphs that belong to s g m g , as stated in theorem 1. the reader who is not familiar with category theory will probably only be interested in the result of this theorem. definition 5 (categories mg, sg(l), and sgmg(lmg)) mg is the category whose objects are elements of m g and whose arrows are multigraph morphisms. sg(l) is the category whose objects are simple graphs over the set of labels l and whose arrows are simple graph morphisms. finally, sgmg(lmg) is the category whose objects are elements of s g m g and whose arrows are simple graph morphisms. note that sgmg(lmg) can be equivalently defined as the full subcategory of sg(lmg) induced by s g m g . recall that a functor f =〈 fo, fm〉 from a category c to a category d is a function with fo (resp. fm) associating objects (resp. morphisms) of d with objects (resp. morphisms) of c and such that f preserves morphisms, identities and composition. the following lemma easily follows from the definitions. lemma 1 it holds that 1. sim is a functor from mg to sgmg(lmg) and 2. sim−1 is a functor from sgmg(lmg) to mg; 3. the functors sim and sim−1 are isomorphisms: sim◦sim−1 = idsgmg(lmg) and sim −1 ◦sim = idmg. graph morphisms are called edge reflecting if edges are reflected along their boundary, i.e. whenever there is an edge between two nodes in the image of the morphism, there should be an edge between the pre-images of these nodes in the domain of the morphism (see next lemma). lemma 2 all morphisms f : g → h in sgmg(lmg) are edge reflecting, i.e. if ( f (x), l, f (y)) ∈ eh then (x, l, y) ∈ eg. proof. it is enough to show that sim translates to edge reflecting morphisms, because the categories are isomorphic. by definition, sim translates edges to special nodes with two outgoing edges to other nodes. nodes in mg are connected via structured edges in sgmg(lmg), thus edges connect an original node with a proxy node. let f be a graph morphism in mg. if sim( f ) reaches a proxy node, f has to map to the original edge. therefore, also the adjacent edges are reached by sim( f ) and thus, sim( f ) is edge reflecting. 3.4 multigraph versus simple graph transformations in the sequel we combine the graph categories mg, sgmg(lmg) and sg(lmg) with the transformation approaches spo and dpo. we will denote such combinations with mg+dpo etc. the proc. gt-vmt 2007 8 / 14 eceasst aim of this paper is to translate mg+dpo into sg(lmg)+spo. this is achieved in two steps: mg+dpo → sgmg(lmg)+dpo → sg(lmg)+spo the first step consists in encoding multigraphs and production rules using the sim function, thus obtaining simple graphs in s g m g and simple graph morphisms. the second step consists in encoding the dpo rules into spo rules. in [hht96] (proposition 3.5) it has been shown that it is possible to translate the application conditions of a dpo derivation (i.e. dangling edge and identification condition) in mg to equivalent negative application conditions (nacs) for performing spo derivations in mg. in theorem 1 we show that the initial dpo transformations in mg can be simulated by the translated spo transformation in sg(lmg). remark 1 (uniqueness of derivations) to be deterministic for given graph production and matching, dpo derivations need the uniqueness of pushout complements. in adhesive categories this is the case if the rule morphisms are, or the match is, monomorphic (see lemma 15 in [ls04]), meaning injective in the category graph. in our setting, the category mg is adhesive and therefore also sgmg(lmg) is, because it is isomorphic. the monomorphisms in the latter one are also equalisers by their property of being edge reflecting and thus, they are regular monomorphisms. given a dpo rule p = l l ← k r → r, we use sim(p) to denote sim(l) sim(l) ← sim(k) sim(r) → sim(r), and we denote by sim∗(p) the translated rule equipped with additional nacs, as described in [hht96]. for the following lemma we interpret graphs of sgmg(lmg) as graphs in mg by forgetting all labels. this allows us to show that pushouts are not only translated to those in a different category, but also remain pushouts in the original category of multigraphs, after applying sim. an extension of mg with labels is direct and only adds information, which does not interfere with the pushout construction. lemma 3 a // �� (po) b �� c // d in mg implies sim(a) // �� (po) sim(b) �� sim(c) // sim(d) in mg up to label information. proof. (sketch) pushouts in mg are constructed component-wise for the sets of edges and nodes by building the disjoint union and factorising along the equivalence generated by the span of morphisms. the definition of sim is compatible with the standard pushout construction, i.e. sim(d) = sim(b +a c) ∼= sim(b) +sim(a) sim(c). theorem 1 (simulation) given a rule p = l l ← k r → r and a match m : l → g in mg, where l is injective, the following three are equivalent: 1. g = p,m =⇒dp o g ′ in mg; 2. sim(g) = sim(p),sim(m) ========⇒dp o sim(g ′) in sgmg(lmg); 9 / 14 volume 6 (2007) simulating multigraph transformations 3. sim(g) = sim∗(p),sim(m) =========⇒s p o sim(g ′) in sg(lmg). furthermore, if a rule in 2 or 3 is applicable, then the result is always a graph in sg(lmg). proof. 1 ⇔ 2 sim and sim−1 are isomorphisms by lemma 1 and hence, they preserve all limits and colimits. since l is injective the dpo-derivations are unique up to isomorphism. 2 ⇒ 3 the derivation in 2 can be considered as a derivation in mg up to labels, according to lemma 3. then using [hht96], it is equivalent to an spo derivation with nacs in mg with result sim(g′), that is, sim(g′) is the pushout of p and m in mg. but, as sim(g′) is a simple graph, it is also the pushout of p and m in sg(lmg), up to labels. because of the strict relation between the labels in graphs in s g m g and their structure, it is not difficult to see that sim(g′) is also the pushout of p and m in sg(lmg) without ignoring the labels. 3 ⇒ 2 let h′ be the result of the derivation (a) sim(g) = sim∗(p),sim(m) =========⇒s p o h ′ in mg. by [hht96] we know that then (b) sim(g) = sim(p),sim(m) ========⇒dp o h ′ is a derivation in mg. since sim(p), sim(m) are morphisms in sgmg(lmg), by lemma 2 we know that they are edge reflecting, and this allows to deduce that the graph h′ is a simple graph, that is, an object of sg(lmg). now, as sg(lmg) is a full subcategory of mg and by (a), we have that h′ is the pushout of sim∗(p) and sim(m) in sg(lmg). by uniqueness of this pushout and the derivation in point 3 we deduce that h′ = h , thus (b) is a derivation in sg(lmg). finally, one can see that h′ and the context graph in (b) are also objects of sgmg(lmg) because the translated rule will only produce and delete complete structured edges by definition of sim. hence, no garbage (i.e. proxy nodes with either an outgoing s-edge or a t-edge, but not both) will occur. thus, (b) is also a derivation in sgmg(lmg). result h ∼= sim(g′) is a direct consequence of the last part of the proof for the previous item. 4 extensions theorem 1 immediately extends to rules with negative application conditions, because they contain just additional graphs and morphisms of the same kind. thus, we will not describe this aspect in more detail. we are also confident that the results from this paper can be extended in a straightforward manner to hypergraphs [kön02], which differ from multigraphs in not having source and target functions, but rather a single function ends : eg →v ∗ g that associates with every edge a string of nodes. hypergraphs can be translated to simple graphs using precisely the same technique of encoding edges as proxy nodes, with in this case as many auxiliary edges (to nodes) as there are elements in ends(e). up to now we have only considered unlabelled and untyped multigraphs, but all the results that we have shown can be easily extended to typed multigraphs, and hence to labelled ones, since labelling can be insured by typing; see, e.g., [eept06]. fig. 6 shows how one of our example labelled multigraphs would be encoded into a simple graph. proc. gt-vmt 2007 10 / 14 eceasst entry t s tentry s list object entry entry list object figure 6: encoding of a labelled multigraph. a typed graph 〈g, m〉 is a graph g together with a morphism m : g → tg to some graph tg called the type graph. a typed graph morphism f : 〈g, m〉→〈g′, m′〉 is a morphism for which m = m′◦ f . transformations of typed graphs should involve only typed graph morphisms. it is equivalent to consider transformations in a slice category. that is, typed transformations in c w.r.t. the type graph tg are equivalent to transformations in the slice category c ↓ tg, where c is either mg or sgmg(lmg) and tg is a multigraph or simple graph, respectively. now, as mg and sgmg(lmg) are isomorphic with sim as isomorphism functor, it is trivial to see that the slice categories are also isomorphic. thus, there is a pushout in mg ↓ tg if, and only if, there is a pushout in sgmg(lmg) ↓ sim(tg). then the simulation result stated in theorem 1 also holds for a typed transformation. however, in this case, an additional translation step is still required to translate to untyped simple graphs. then we have to extend the labels to encode the typing; hence, the translation is from [sgmg(lmg) ↓ sim(tg)]+spo to [sgmg(lmg ×(vt g ∪et g))]+spo. we are convinced that this translation is straightforward, but we have not given the proof. 5 simulation in spo tools tools performing graph transformations often implement spo since this requires only one pushout construction whether for dpo an additional pushout complement construction is needed. problems arise when performing rule applications using spo that do not satisfy the gluing condition. in the running example such a situation would occur when applying the delete rule on an object that is contained in more than one list. in order still to be able to perform dpo transformation, there are basically two alternatives: 1. restrict rule applications by checking the gluing condition after searching for matchings; 2. encode the gluing condition using additional negative application conditions in the transformation rules. choosing the first alternative requires that the tool performs an additional gluing check on the found matches. this gluing check means that for all identifications in the matching and for all node deletions we need to ensure that there is no preserve-delete conflict (identification condition) and that the node-deletions do not cause dangling edges (dangling condition), respectively. the agg tool’s kernel implements spo and uses a similar mechanism for handling dpo transformations. 11 / 14 volume 6 (2007) simulating multigraph transformations the second alternative is based on theorem 1, in which we show that it is possible to simulate dpo on our special simple graphs by adding additional negative application conditions as described in [hht96]. let us now briefly describe how one can use the groove tool (or some other tool supporting simple graph transformations with spo) for performing dpo transformations on multigraphs. given a (multi-) graph production system (gps) t = 〈g, p〉, one first has to create the production system sim(t ) by encoding the graph g and all graphs and morphisms that are parts of the productions in p in the manner described in section 3. note that if some productions include negative application conditions, these conditions together with the morphisms that relate them to the corresponding production are encoded just as normal graphs and morphisms. now, if the tool offers the possibility to check for the gluing condition (choice 1 above), then the gps sim(t ) can be submitted to the tool, specifying that the check for the gluing condition has to be performed. otherwise (choice 2 above), one has to construct the production system sim∗(t ) by augmenting sim(t ) with additional nacs for encoding the gluing condition in sim(t ). the gps sim∗(t ) is then submitted to the tool as a normal (simple) graph production system. any derivation results obtained by the tool (e.g. graphs that can be derived from the start graph or the actual rule applications) can be transformed back to multigraphs using the sim−1 mapping. this forth and back translation can be used, for instance, for exchanging results between different graph transformation tools. 6 conclusion and future work we have proposed a method for performing dpo multigraph transformations using tools handling spo simple graph transformations. compared to previous work [hkm06], this method is generic, i.e. has been proved correct on categorical level and does not depend on the tools to be used. pushing theory to work in practise. tool interoperability is one major motivating point to translate graph transformation systems using multigraphs and dpo to equivalent systems with simple graphs and spo derivations. on the more fundamental level it is even more interesting to have the possibilities of applying a wide range of theoretical results and implementing them in the tool of favour. during the last three decades, a lot of theory was developed using dpo and multigraphs. one special new technique is the analysis of derivations using subobject transformation systems (sts) presented in [chs06]. since the groove tool performs graph derivations to verify systems, the translation presented in this paper could give the possibility of combining the power of both (which was not possible before, because sts are not defined for spo). and indeed, this idea already has a concrete structure: basically one can exploit the possible results of dependencies using a translation to stss and furthermore, the branching derivations of the state space can be folded into one summary object. thus, only a small number of derivation steps will have to be performed to construct an abstraction of a much bigger state space. the idea is then to use the abstraction equipped with an sts to deliver only effective states and perform model checking on these states and their concrete successors. proc. gt-vmt 2007 12 / 14 eceasst acknowledgements. the first and third authors are employed in the groove project funded by the dutch nwo (project number 612.000.314). bibliography [bw95] m. barr, c. wells. category theory for computing science. prentice hall, 1995. [chs06] a. corradini, f. hermann, p. sobociński. subobject transformation systems. applied categorical structures, 2006. to appear. [cmr+97] a. corradini, u. montanari, f. rossi, h. ehrig, r. heckel, m. löwe. algebraic approaches to graph transformation, part i: basic concepts and double pushout approach. pp. 163–246 in [roz97]. [cou97] b. courcelle. the expression of graph properties and graph transformations in monadic second-order logic. pp. 313–400 in [roz97]. [dkh97] f. drewes, h.-j. kreowski, a. habel. hyperedge replacement graph grammars. pp. 95–162 in [roz97]. [eept06] h. ehrig, k. ehrig, u. prange, g. taentzer. fundamentals of algebraic graph transformation. eatcs monographs in tcs. springer verlag, 2006. [ehk+97] h. ehrig, r. heckel, m. korff, m. löwe, l. ribeiro, a. wagner, a. corradini. algebraic approaches to graph transformation, part ii: single pushout approach and comparison with double pushout approach. pp. 247–312 in [roz97]. [hau06] j. h. hausmann. dynamic meta modeling: a semantics description technique for visual modeling techniques. phd thesis, universität paderborn, 2006. [hht96] a. habel, r. heckel, g. taentzer. graph grammars with negative application conditions. special issue of fundamenta informaticae 26(3,4):287–313, 1996. [hkm06] f. hermann, h. kastenberg, t. modica. towards translating graph transformation approaches by model transformation. in proc. of the int. workshop on graph and model transformation (gramot’06). 2006. [kkr06] h. kastenberg, a. kleppe, a. rensink. defining object-oriented execution semantics using graph transformations. in gorrieri and wehrheim (eds.), proc. of the 8th ifip int. conf. on formal methods for open object-based distributed systems (fmoods’06). lncs 4037, pp. 186–201. springer verlag, 2006. [kön02] b. könig. hypergraph construction and its application to the static analysis of concurrent systems. mathematical structures in computer science 12(2):149–175, 2002. 13 / 14 volume 6 (2007) simulating multigraph transformations [ls04] s. lack, p. sobociński. adhesive categories. in walukiewicz (ed.), proc. of the 7th int. conf. on foundations of software science and computation structures (fossacs’04). lncs 2987, pp. 273–288. springer verlag, 2004. [omg05] omg. unified modeling language specification. 2005. http://www.omg.org/technology/documents/formal/uml.htm [ren04a] a. rensink. the groove simulator: a tool for state space generation. in pfaltz et al. (eds.), applications of graph transformations with industrial relevance (agtive’03). lncs 3062, pp. 479–485. springer verlag, 2004. [ren04b] a. rensink. representing first-order logic using graphs. in ehrig et al. (eds.), proc. of the 2nd int. conf. on graph transformations (icgt’04). lncs 3256, pp. 319–335. springer verlag, 2004. [roz97] g. rozenberg (ed.). handbook of graph grammars and computing by graph transformation. volume i: foundations. world scientific, 1997. [sshw] a. schürr, s. e. sim, r. holt, a. winter. the gxl graph exchange language. http://www.gupro.de/gxl [tae01] g. taentzer. towards common exchange formats for graphs and graph transformation systems. in padberg (ed.), proc. of the workshop on uniform approaches to graphical process specification techniques (unigra’01). entcs 44. 2001. [ter99] g. taentzer, c. ermel, m. rudolf. the agg approach: language and tool environment. in ehrig et al. (eds.), handbook of graph grammars and computing by graph transformations. volume ii: applications, languages and tools, pp. 163– 246. world scientific, 1999. proc. gt-vmt 2007 14 / 14 http://www.omg.org/technology/documents/formal/uml.htm http://www.gupro.de/gxl introduction background graphs and graph morphisms graph transformations back to the example from multigraphs to simple graphs and back again from multigraphs to simple graphs from simple graphs to multigraphs categories for multigraphs and simple graphs multigraph versus simple graph transformations extensions simulation in spo tools conclusion and future work modelling distributed cognition systems in pvs electronic communications of the easst volume 45 (2011) proceedings of the fourth international workshop on formal methods for interactive systems (fmis 2011) modelling distributed cognition systems in pvs paolo masci, paul curzon, ann blandford, dominic furniss 16 pages guest editors: judy bowen, steve reeves managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst modelling distributed cognition systems in pvs paolo masci1∗, paul curzon1, ann blandford2, dominic furniss2 1 queen mary university of london school of electronic engineering and computer science 2 uclic, ucl interaction centre university college, london abstract: we report on our efforts to formalise dicot, an informal structured approach for analysing complex work systems, such as hospital and day care units, as distributed cognition systems. we focus on dicot’s information flow model, which describes how information is transformed and propagated in the system. our contribution is a set of generic models for the specification and verification system pvs. the developed models can be directly mapped to the informal descriptions adopted by human-computer interactions experts. the models can be verified against properties of interest in the pvs theorem prover. also, the same models can be simulated, thus facilitating analysts to engage with stakeholders when checking the correctness of the model. we trial our ideas on a case study based on a real-world medical system. keywords: higher order logic, pvs, distributed cognition, dicot, interactive system design. 1 introduction and motivation designing a system involves specifying the characteristics that are necessary for it to accomplish given tasks in given environments. design errors are well-known sources of system failures: in computer systems, they represent the major cause of failures; in interactive systems, they are also a major cause of systematic human errors. for instance, in the healthcare domain the ‘system’ of importance is often not just a single computer device but the whole work environment. whether it was explicitly designed, or more likely evolved and was adapted by those working within it over time, errors in its ‘design’ can cause either kind of failure. the development process of a system of whatever level, therefore, must adopt appropriate means to eliminate design errors. this is specially relevant in safety-critical domains, such as healthcare. formal methods represent appealing techniques for eliminating design errors, because they are based on mathematical logic and provide a non-ambiguous language for describing the system. furthermore, formal methods are supported by analytical tools and methodologies that enable the prediction of possible system behaviours. to date, two main classes of formal approaches have been explored for reasoning about interactive system design: machine-centred approaches, which aim to verify functional properties of interactive systems’ specifications, such as deadlockfreedom and consistency of assumptions (e.g., [ch97]); and user-centred approaches, which ∗ corresponding author. 1 / 16 volume 45 (2011) modelling distributed cognition systems in pvs explicitly model human behaviour, and reason about systems where users interact with devices according to a cognitively plausible behaviour (e.g., [rbcb09]). such formal approaches generally explain information processing in the use of devices at the level of the individual, and point attention at localised phenomena happening between a user and an interactive device. although useful, this way of reasoning is sometimes insufficient to capture the distributed nature of the mechanisms that usually enable users to carry out their tasks in the real world [re94]. in fact, humans deliberately use and organise the whole environment to support their behaviour [nor02]. hence, when analysing and designing complex interactive systems, experts should consider the whole work system [thi08], and study collections of humans, devices, artefacts, and their relations to each other in the work practice. distributed cognition [fh91] represents a promising conceptual framework for studying the design of complex interactive systems. the idea of distributed cognition is that cognition is not confined in the mind of humans, but it spans across humans and artefacts. as such, cognition is a property of the whole system, and can be described in terms of transformations of the representational state of information. for instance, in familiar everyday interactions we use to-do lists to organise attention to tasks, we use shopping lists to extend our memory and we group piles of paper to organise our work. kirsh and maglio [km94] argue that people will change their external environment to help them with the problem solving space they are working within, i.e. manipulating the world changes the cognitive space. an example of this is moving tiles about when playing scrabble so players can group letters together and improve their ability to find longer words. moving toward more complex systems, hutchins [hut95] analysed how a cockpit “remembers its speed” through a combination of different people, in different roles, with different tools and artefacts collectively moving and changing the representation of information. dicot [bf06] is an informal structured methodology that has been proposed in the humancomputer interaction community for applying the framework of distributed cognition to the design of teamwork settings. the approach has been successfully used to analyse different realworld systems, see, for instance [srsf06], [md08] and [fb06]. briefly, dicot proposes five interdependent models to analyse socio-technical systems: the information flow model, physical model, artefact model, social model and evolutionary model. associated with each of these models is a representation or diagram and distributed cognition principles that are distilled from the literature, e.g. in the physical model the analyst might look for factors influencing the situation awareness in the system, or lack there of. these models are described further below. dicot’s models are specified using an informal notation based on a mixture of semi-formal diagrams and natural language. designers and analysts also reason about properties of the models with informal deduction methods. whilst the flexibility of informal notation can be useful in some ways, it may lead to ambiguous specifications, which may reduce the repeatability of the analysis. similarly, the informal deduction methods used in dicot are high-level proof sketches, and there is a concrete risk of using hidden assumptions when proving properties. contribution. the aim of this work is to support human-computer interaction experts in describing how tasks are carried out in complex work systems, and in identifying error-prone system designs. to this end, we report on our efforts to formalise dicot in the specification and verification system pvs [orr+96]. we focus here on dicot’s information flow model, which studies how information is transformed and propagated in the system. our contribution is a set of generic pvs theories that can be used by analysts to describe work practice and proc. fmis 2011 2 / 16 eceasst work settings. such generic theories can be naturally mapped to the informal description of dicot’s information flow models, i.e., the relationship between the developed theories and the concepts used in dicot’s information flow models can be easily seen and justified. also, the developed theories can be executed within the pvs system, thus facilitating analysts to engage with stakeholders when checking the correctness of the model. to trial these ideas, we have applied them to the domain of medical work, and we have formally modelled and analysed a case study based on the london ambulance service. the case study is based on already published work presented by [bf06]. with our models and analysis, we were able to spot some potential issues that were not reported in the published study. the original analyst confirmed that having such issues highlighted while the study was carried out would have been useful in gaining a more complete and insightful analysis. the rest of the paper is organised as follows. in section 2, we introduce dicot’s models and present details of the information flow model. in section 3, we present a brief overview of the pvs specification and verification system. in sections 4 we report on the developed pvs theories, and explain how the theories can be used to formalise dicot’s information flow model. in section 5, we trial our theories by specifying the dicot information flow model of the london ambulance service. in section 6, we discuss related work and draw the conclusions. 2 dicot models dicot uses five models to describe work systems. each model provides a different perspective on the system: the physical model studies the physical layout of the system; the artefact model studies how artefacts are designed and used in the system; the information flow model studies how information is transformed and propagated in the system; the social model studies the roles, skills and knowledge in the system; and the evolutionary model studies how the system has changed over time. here, we focus on the information flow model. such a model highlights the role of the various actors in the system, the content of information items exchanged among actors, and the sequences of actions carried out by actors for processing and exchanging information items. the model consists of a textual description, which specifies the activities carried out in the system in natural language, and a diagram, which graphically depicts the dependency relations among activities. in the following, we show the information flow model for a case study based on the central ambulance control room of the london ambulance service. the case study has been described and analysed in [bf06] and [fur04]. we formalise this case study in section 5. 2.1 information flow model example: the london ambulance service the london ambulance service (las) is the world’s largest emergency healthcare system, caring for more than one and a half million patients every year. the ambulance service is coordinated from a central ambulance control room, which consists of two main areas: call taking and dispatching. operators in the call taking area receive calls from external callers and filter out relevant information about the incident. operators in the dispatching area use the information entered in the system by call-takers for deciding which ambulance should be allocated to which incident. there is a dispatching area for each zone of the city (london has seven zones). 3 / 16 volume 45 (2011) modelling distributed cognition systems in pvs figure 1: dicot information flow model diagram of the london ambulance service. textual description. the informal specification of the activities carried out in the call taking and dispatching areas, based on that from the original analysis, follows. in our description, we will use a level of detail appropriate for the purposes of this article. readers interested in a more detailed informal specification of the whole system should refer to [fur04]. activities carried out in the call taking area. call-takers interview external callers according to a protocol captured in the ‘advanced medical priority dispatch system’. this protocol defines a structured dialogue between call-takers and external callers that enables call-takers to distill information for classifying incidents in terms of their medical urgency. proqa [pri05] is a computerised version of the system, and is currently used in the central ambulance control room. proqa structures the dialogue between a call-taker and an external caller as follows. first, the call-taker greets the external caller and verifies the caller’s location and telephone number, which are automatically entered by proqa. second, the call-taker starts a questioning procedure for gathering information on the incident’s location and details. this focuses the system’s attention on the critical factors needed to prioritise the incident. as soon as the call-taker enters the incident’s location in the system, the relevant sector desk is activated to receive live information on the incident. specifically, the allocator responsible for the incident’s zone is notified about the new incident, and is updated in real-time as the call-taker inputs further information. third, the call-taker provides support and advice, and then closes the call. activities carried out in the dispatching area. allocators can view the position of all ambulances, and they are selectively updated on new incidents when call-takers enter information on them. as soon as a call-taker enters a new incident location, a communication is automatically established between the call-taker and the allocator responsible for the relevant city area, and the allocator is able to view in real-time the incident details entered by the call-taker. while the incident’s details are entered, the allocator can start checking that the call is actually a new incident, and not an additional call about an incident that has already been reported. in the case of a new incident, the allocator mentally selects possible ambulances on the basis of their location and availability. the allocator will have good situation awareness about where ambulances are and what incidents they may be attending to. as soon as the incident priority is known, the allocator alerts the ambulance crew and coordinates with it. depending on the actual position of the ambulance, the coordination between allocator and ambulance crew is supported either by a phone operator (the ambulance is at the station) or a mobile operator (the ambulance is on the proc. fmis 2011 4 / 16 eceasst streets). if the ambulance crew accepts the mission, the allocator sends the incident information to the ambulance crew. if no ambulances are available in the allocator’s zone, then the allocator transfers the incident’s details to another allocator in a neighbouring sector. diagram. the diagram was not included in the published work, and we define it here in collaboration with the human-computer interaction experts that conducted the original study. the diagram is shown in figure 1: labelled boxes represent activities, and edges represent causal and temporal dependency relations among activities. an activity can be performed only if all directly connected activities have already been performed. for instance, activity “1: call-taker takes a call” can be performed only if “0: proqa gathers number and location” has already been performed. some activities can be performed concurrently, e.g., “4: call-taker enters incident location” and “7: allocator receives incident location”. edges may have labels that specify control-flow conditions. for instance, the outgoing edges from “9: allocator receives incident priority” have labels “ambulance available on street?” and “ambulance available at station?”, which define two possible ways of continuing the task. 3 background on pvs the specification and verification system pvs (prototype verification system) [orr+96] combines an expressive specification language with an interactive proof checker. the pvs specification language builds on classical typed higher-order logic with the usual base types (e.g., bool, nat, integer and real), function type constructors [a -> b] (predicates are functions with range type bool), and abstract data types. the language supports predicate subtyping, which is a powerful mechanism to express complex consistency requirements. pvs specifications are packaged as theories. theories can be parametric in types and constants, and they can use definitions and theorems of other theories by importing them. pvs provides a pre-defined built-in prelude, and a number of loadable libraries that provide a large number of standard definitions and proved facts that can be used when developing new theories. pvs has an automated theorem prover that can be used to interactively apply powerful inference procedures within a sequent calculus framework. the primitive inferences procedures include, among others, propositional and quantifier rules, induction, simplification using decision procedures for equality and linear arithmetic, data and predicate abstraction [orr+96]. pvs has a ground evaluator [cor+01] that automatically compiles executable constructs of a specification into efficient lisp code. in order to be able to execute theories that include non-executable constructs (e.g., declarative specifications), the ground evaluator can be augmented by so-called semantic attachments. through these, the user can supply pieces of lisp code and attach them to the declarative parts. the ground evaluator was subsequently extended by a component, denominated pvsio [muñ03], which provides a high-level interface for writing semantic attachments, as well as a set of proof rules to safely integrate the attachments to the theorem prover of pvs. 4 formal specification of dicot’s information flow model we have developed a customisable set of pvs theories for specifying dicot’s information flow model. since one of the key aims of our work is to support human-computer interaction experts 5 / 16 volume 45 (2011) modelling distributed cognition systems in pvs in their analysis, we designed the theories such that a natural mapping exists between the pvs specification and dicot’s information flow model, i.e., the relationship between the developed theories and the concepts used in dicot’s information flow models can be easily seen and justified. this opens the possibility of enabling human-computer interaction experts to directly use such formal models for specifying the system. the developed theories can be re-used and refined for building models of different systems at different level of details. also, the models can be animated with pvsio, thus facilitating the dialogue between analysts and stakeholders when checking the correctness of the model. in order to support model animation, we developed a simulation engine that can be conveniently used to automatically schedule activities and generate execution traces. the simulation engine is specified as a higher-order function in pvs, thus the correctness of its specification can be formally proved in the pvs theorem prover. 4.1 generic models in order to build a set of pvs theories that can be naturally mapped to the informal description of dicot’s information flow model, we draw concepts from activity networks [mm84], a widely used formalism for modelling complex concurrent systems, and from approaches for the analysis of protocols for distributed systems of autonomous and cooperating nodes [bmp08, bmp09]. specifically, we use three basic modelling concepts for developing our pvs theories: system state, activities, and task. system state. a system state is a snapshot of the value of information items and of the characteristics of system elements. in pvs, system states can be conveniently specified with structured data-types. each field of the data structure represents either the value of an information item or the characteristics of a system element. we assign unique identifiers to each modelled item; identifiers can be either natural numbers or enumerated types. when using enumerated types, the pvs type system automatically checks that the enumerated identifiers are unique, and automatically generates predicates for recognising the enumerated values (the predicate is given by a function whose name is the value’s name followed by a question mark). since the level of details for specifying a system state generally depends on the property of interest, we exploit information hiding when defining theories for the system state, i.e., each pvs theory is assimilated to the class concept used in object-orient programming languages, where interface functions are used for accessing and modifying data types in a consistent way. we will show an example of the system state in section 5. activities. an activity is an action carried out in the system. activities can be carried out either by humans, devices, or collections of humans and devices, and they are specified as transition functions over system states. we identify each activity with a unique identifier. we developed a pvs theory, activity th, that contains the following definitions: activity, a function type suitable for specifying activities as state transitions over system states; activity id, a bounded natural number type for defining unique identifiers for activities; an execute function, which specifies that a new system state can be obtained by applying an activity to the current system state. the type definition of system state and the number of activities are theory parameters. we will show examples of specifications in section 5. activity_th[system_state: type, n_activities: posnat]: theory begin proc. fmis 2011 6 / 16 eceasst activity: type = [system_state -> system_state] activity_id: type = below(n_activities) execute(act: activity): [system_state -> system_state] = lambda(sys: system_state): act(sys) end activity_th tasks. a task defines how and when activities carried out in the system. we specify tasks with a graph-based notation: nodes in the graph represent activities, and edges between nodes represent dependency relations between activities. an activity is enabled when all directly connected activities have already been performed. whenever an activity becomes enabled, such an activity can be performed. when several activities are enabled at the same time, then such activities can be performed concurrently. dependency relations among activities can be parametric with respect to control flow conditions, which define different ways of continuing the task. control flow conditions are specified by associating dependency predicates to edges. in pvs, we specify tasks as structured data types consisting of four fields: f, a function that associates a unique identifier to each activity that can be performed in the task; s, a status vector that defines the progress status of each activity in the task; g, a directed graph that defines dependency relations among activities (nodes in the graph are identifiers of activities); p, a function that associates dependency relations to dependency predicates. the type definition of g uses the nasa library on directed graphs [bs98], which provides a large number of standard definitions and already proved theorems. the type definition of dependency predicates, on the other hand, has been defined as a function from system states to booleans. the type definitions of system state, activity, activity identifier, and activities’ progress status are theory parameters, i.e., they are left unspecified, and must be instantiated by the theories that import task th. the theory follows. task_th[system_state, activity, activity_id, progress_status: type]: theory begin importing digraphs[activity_id] dependency: [system_state -> bool] task: type = [# f: [activity_id -> activity], g: digraph[activity_id], p: [edgetype[activity_id] -> dependency], s: [activity_id -> progress_status] #] end task_th 4.2 simulation engine we developed a simulation engine for animating the formal specification. in our work, the main utility of the simulation engine is to facilitate the dialogue between analysts and stakeholders when checking the correctness of the formal specification. the developed simulation engine takes care of scheduling activities, and uses the pvsio extension for generating a visual feedback of the execution. the engine is defined as a higher-order function, exec, that iteratively selects at most n times the activity to be performed, and generates the new system state by executing the selected activity. the engine selects the activity on the basis of its progress status (defined in theory progress status th), which can be one of the following: ready, i.e., the activity is ready for execution, needs action, i.e., the activity cannot be performed because other activities need to be completed first, completed, i.e., 7 / 16 volume 45 (2011) modelling distributed cognition systems in pvs the activity has been performed, cancelled, i.e., the activity will not be executed (this may happen, e.g., because of control flows); and deleted, i.e., the activity has not been executed. activities are chosen non-deterministically from two work-lists, c and r. work-list c contains cancelled activities. work-list r contains activities ready for execution. activities in work-list c have priority over those in work-list r —this way, dependency relations due to cancelled activities can be automatically removed from the dependency graph of the task. whenever an activity is selected from a work-list, the activity is also removed from such a work-list. two auxiliary functions, update deleted and update completed, are used in the engine for updating the status of activities according to (i) the status of the performed activity, and (ii) the dependency relations specified in the task. the execute function defined in activity th is used to generate the new system state when an activity completes (the system state remains unchanged when an activity is deleted). the execution terminates when either n steps have been performed or both work-lists r and c are empty. the theory follows. basic_engine_th[system_state: type, n_activities: posnat, state2string: [system_state -> string]]:theory begin %--imports omitted execution_engine: type = [task, system_state -> system_state] exec(n: nat): recursive execution_engine = lambda(t: task, sys: system_state): if n = 0 then sys else let dbg = print(state2string(sys)), c = { x: activity_id | cancelled?(s(t)(x))}, r = { x: activity_id | ready?(s(t)(x))} in if empty?(c) and empty?(r) then sys else let (t_prime, sys_prime) = cond not empty?(c) -> let x = choose(c) in (update_deleted(x)(t,sys), sys), not empty?(r) and empty?(c) -> let x = choose(r) in (update_completed(x)(t,sys), execute(f(t)(x))(sys)) endcond in exec(n-1)(t_prime, sys_prime) endif endif measure n end basic_engine_th 5 case study in this section, we use the developed pvs theories for modelling and analysing the dicot information flow model of section 2.1, which describes the activities carried out in the london ambulance service. we show how the level of abstraction of the specification can be seamlessly changed by importing different versions of the theories. when importing abstract theories containing only declarations, the specification of the task defines only the overall structure of the task, which is useful for checking a number of consistency constraints related to control flow conditions. when importing concrete theories that provide details on how activities modify the system state, the specification can be used to detect covert dependency relations due to read/write operations on the system state. also, we show how to use the developed simulation engine. proc. fmis 2011 8 / 16 eceasst 5.1 high-level specification the high-level specification of the london ambulance service is given by the dicot diagram reported in figure 1. the formal specification in pvs was obtained by defining a function, las task, that specifies the dependency relations among activities. the system state and the name of the activities carried out in the task are declared in the imported theory. in the following, we show an excerpt of function las task. in section 5.1, we show how this high-level specification can be refined in order to detect covert dependency relations. in section 5.2, we show how the high-level specification can be conveniently used for checking consistency constraints on control flow conditions. las_task_th: theory begin importing las_activities_th, task_th[system_state, activity, activity_id, progress_status], %--more imports omitted las_task(sys: system_state) (task_status: [activity_id -> progress_status]): task = let f: [activity_id -> activity] = lambda(id: activity_id): cond id = 0 -> proqa_gathers_number_and_location, id = 1 -> call_taker_takes_a_call, id = 2 -> call_taker_verifies_number, ... g: digraph[activity_id] = lambda(id: activity_id): cond id = 0 -> {x: activity_id | x=1}, id = 1 -> {x: activity_id | x=2}, ... p: [edgetype[activity_id] -> dependency] = lambda(id1,id2: activity_id): cond (id1,id2) = (2,3) -> number_validated?, (id1,id2) = (7,8) -> new_incident?, ... in (# f := f, g := g, p := p, s := task_status #) end las_task_th 5.2 refining the high-level specification the high-level specification can be refined by specifying the informative content of the system state, and how activities actually modify the system state. specifically, without changing the specification of function las task, we can add details by importing a different version of theory las activities th. in the following, we show how we refined the theory. system state. in order to refine the system state, we need (i) to define the characteristics of system elements, and (ii) to define the informative content of information items. system elements. we defined a pvs theory, las actors th for defining elements’ characteristics. specifically, we defined a new enumerated type, element id, for identifying actors in the london ambulance service, and we used predicate sub-typing for deriving a new type 9 / 16 volume 45 (2011) modelling distributed cognition systems in pvs of identifiers, las staff, for the staff members of the london ambulance service. this new type is useful for specifying activities that can be carried out only by staff members — in pvs, all functions must be total, but partial functions can be specified as total functions over a restricted domain [so99]. in the theory, we define the characteristics of an ambulance (ambulance state) in terms of its availability status and location. an excerpt of the theory follows. las_actors_th: theory begin element_id: type = {na, external_caller, call_taker, allocator, ...} las_staff : type = {n: element_id | call_taker?(n) or allocator?(n) or ...} %-ambulance state ambulance_availability: type = {na, available, not_available, on_duty} ambulance_location: type = {na, on_street, at_station} ambulance_state : type = [# status: ambulance_availability, loc : ambulance_location #] %-more definitions omitted end las_actors_th information items. information items flowing within the system describe, in this case, information exchanged between call-takers and allocators through the proqa system. information items handled by call-takers include incident locations and incident details. such information items are automatically augmented by the proqa system, which enters phone numbers of external callers and assigns unique computer aided dispatch (cad) numbers to calls. information items handled by allocators include a set of incidents (each of which is uniquely identified by a cad number), incidents’ details, ambulances’ location and availability. a pvs theory suitable for modelling the state of such information items contains two structured data types: call taker info, which includes information entered by call-takers and information automatically entered by proqa; and allocator info, which defines information items handled by allocators. an excerpt of the theory follows. las_information_items_th: theory begin %-imports omitted call_taker_info: type = [# caller_cad : cad_number, caller_phone : phone_number, caller_location : location, incident_location: street, incident_details : details #] allocator_info: type = [# cad_set : finite_set[cad_number], incidents : [cad_number -> incident_state], ambulances: [ambulance -> ambulance_state] #] %-more definitions omitted end las_information_items_th system state. the system state, according to a distributed cognition view, identifies the representational state of information. in our example, we are interested in the representational state of an incident. according to the narrative description given in section 2.1, we need to consider the items handled by a call taker and an allocator. hence, the system state can be defined with a proc. fmis 2011 10 / 16 eceasst structured data type containing two fields: call taker state, of type call taker info, which describes the representational state handled by a call taker, and allocator state, of type allocator info, which describes the representational state handled by an allocator. las_system_state_th: theory begin importing las_information_items_th, las_actors_th system_state: type = [# call_taker_state: call_taker_info, allocator_state : allocator_info #] %-more definitions omitted end las_system_state_th activities. here we show how to define the first two activities carried out by call-takers with a functional notation that uses the let-in construct of the pvs syntax. the first activity, “0: proqa gathers number and location”, changes the system state by assigning a unique cad number and by entering the caller’s phone number and location; the second activity, “1: calltaker takes a call” leaves the system state unchanged. las_activities_th: theory begin importing las_system_state_th, activity_th[system_state, n_activities] %-0: proqa gathers number and location proqa_gathers_number_and_location: activity = lambda(sys: system_state): let cad = new_cad({c: cad_number | not cad_set(allocator_state(sys))(c)}), c_phone = proqa_gathers_phone_number, c_location = proqa_gathers_location, c_state = (# caller_cad := cad, caller_phone := c_phone, caller_location := c_location, incident_location := na, incident_details := na #) in sys with [ call_taker_state := c_state ] %-1: call-taker takes a call call_taker_takes_a_call(i: call_taker): activity = lambda(sys: system_state): sys %-more definitions omitted end las_activities_th 5.3 formal analysis we carried out two kinds of formal analysis on the formal specification of the london ambulance service. the first analysis is performed on the high-level specification for ensuring semantic constraints on control-flow conditions. the second analysis aims at comparing the work practice, which reports how activities are carried out by users in the real system, against the reference manual of the proqa system, which reports how activities should be carried out in the system according to the system designer’s point of view. this second analysis has similarities with that carried out by rushby in [rus02]; in his work, rushby compared the specification of an interactive system with the mental model created by its users for discovering possible sources of mode confusion. checking semantic constraints. one of the constraints that we need to check in our specifications is that control flow conditions cover all possible situations. we can specify such a 11 / 16 volume 45 (2011) modelling distributed cognition systems in pvs figure 2: dicot’s information flow model diagram of proqa’s manual (some details of the dispatching activities are omitted); gray boxes are activities that were not reported in [bf06]. constraint as a predicate on the dependency predicates associated to the incoming and outgoing edges of each node in the graph. we found a violation for the following activities: “2: call-taker verifies number”, “7: allocator receives incident location”, “12: allocator discusses mission”. the issue is probably due to the following hidden assumptions: (i) call-takers are supposed to know what to do when a number cannot be validated and when an ambulance does not accept the mission, and (ii) allocators are supposed to wait for new incidents before performing any action. the utility of this analysis is to force us to expose all the assumptions made on the system and check their validity. comparing work practice and reference manual. the comparison of work practice and reference manual is useful for pointing out possible mismatches between mental models developed by users (i.e., how users understand the functionalities of the system), and the reference specification of the system (i.e., how the system should work according to the designer’s pointof-view). in order to trial this possibility, we formalised the proqa user manual (ver 3.4) [pri05]. an excerpt of the high-level description of the manual is graphically depicted in figure 2. in the figure, we use a level of detail appropriate for the purposes of this article. the exercise of building the specification enabled us to spot several mismatches related to the understanding of when and how information flows from call-takers to allocators. for instance, according to the description obtained with the ethnographic study performed in [bf06], the mental model developed from speaking to the call-takers seems to describe the flow of information from call-takers to allocators as an automatic procedure guaranteed by the system (in the following, some parts of the text reported in [bf06] are omitted; for such parts we show dots within square brackets): “as soon as the call-taker enters the incident’s location in the system [...] the allocator responsible for the incident’s zone is notified about the new incident, and is updated in real-time as the call-taker inputs further information.”. the specification of the user manual, on the other hand, suggests that such communication happens only when the proqa system disproc. fmis 2011 12 / 16 eceasst plays a send dispatch screen: “the send dispatch screen appears as soon as proqa has enough information to recommend a dispatch code. [...] click on the send button to immediately send the dispatch code.” (page 88 of proqa’s user manual [pri05]). furthermore, from the manual it emerges that the user may delay sending the information: “when appropriate, click on the delay and continue button to delay dispatch and continue caller interrogation.” (page 89 of proqa’s user manual [pri05]). this last mismatch is potentially a serious problem, because allocators cannot proceed if call-takers delay sending the dispatch code. the issue, indeed, seems to have been foreseen by the system designers, because proqa’s user manual reports the following warning on delaying the dispatch: “exercise caution when delaying dispatch. do it only when you need to ask additional questions before sending dispatch.” (page 89 of proqa’s user manual [pri05]). the original analyst confirmed that having such issues highlighted during the study would have been useful in gaining a more complete and insightful analysis. 5.4 simulations in this context, the main role played by simulations is to facilitate the dialogue among analysts and stakeholders when checking the correctness of the formal specification. the formal specification can be animated with the simulation engine presented in section 4.2. we customised the traces generated by the execution engine by defining functions that automatically translate the system state into a string that can be easily interpreted by humans. as an example of such a function, let us consider the theory for incidents’ locations. assume that the theory encodes the incident location with a natural number. in order to present the street name in a more humanreadable format, a function (street2string) can be defined for converting numbers into actual street names. the function will be seamlessly used by the pvsio environment whenever printing the output —to this end, we exploit a pvs mechanism for defining automatic type conversions. street_th: theory begin %-imports omitted street: type = posnat street2string(s: street): string = cond s = 0 -> " boulevard rd. " s = 1 -> " terrace pl. " ... endcond conversion street2string end street_th the conversion can be defined for any pvs data type used in the system state, thus enabling a full customisation of the output. in the following, we show an example of simulation trace that can be obtained with the simulator. the simulator executes four simulation steps. for simplicity, here we have redefined the print function of the simulator so that it shows only the initial and final system states, and the sequence of actions performed. exec(4)(las_task(sys)(initial_task_status), sys); == initial state ============= caller_cad( n/a ) caller_phone( n/a ) caller_location( n/a ) 13 / 16 volume 45 (2011) modelling distributed cognition systems in pvs ------------------incident_location( n/a) incident_details( n/a ) ================================= >> proqa gathers number and location << >> call-taker takes a call << >> call-taker verifies number << >> call-taker enters incident location << == final state ========= caller_cad( 1 ) caller_phone( +23 322 3860 843 ) caller_location((# latitude = 0.4w, longitude = 51.30n #)) ------------------incident_location( terrace pl. ) incident_details( n/a ) =================== 6 related work and conclusion tasks and work-flow analysis has been explored in several studies with different techniques and different aims. for instance, in [fumk10], work-flows are initially modelled with a web service business process language (ws-bpel), and then such semi-formal models are translated into a finite state process (fsp) model suitable for verifying properties with model checking approaches; in [zaw+10] and [dxw08], petri nets based formalisms are used for modelling and analysing industrial and business processes. doherty et al [dch00] used pvs for defining an approach suitable for studying representational issues in distributed cognition systems. in our work, on the other hand, the main goal is to build a formal specification that can be naturally mapped to the informal description of dicot information flow models. a dicot analysis of a system can have several ultimate aims, but whatever the overall aim, the immediate purpose is to draw out understanding and so create an accurate description of the distributed system. our hope in providing a formalisation of dicot is that it would facilitate the creation of such a description with a non-ambiguous language that could be directly used by humancomputer interaction experts for modelling the system. formalising the informal dicot information flow model for the london ambulance control room did prove insightful in several ways. even the exercise of building a formal specification of the system and simulating it highlighted several issues, mainly due to under-specified procedures and hidden hypotheses. the original dicot analysts of the london ambulance system agreed this was potentially useful in improving the analysis. hence, even before using automated reasoning tools and techniques, the formal specification can be a suitable means for triggering questions to feed discussions on system design and ensure that the ultimate description obtained covers the important aspects of the system. acknowledgements: funded as part of the chi+med: multidisciplinary computer-human interaction research for the design and safe use of interactive medical devices project, epsrc grant number ep/g059063/1, and extreme reasoning, grant number ep/f02309x/1. proc. fmis 2011 14 / 16 eceasst bibliography [bf06] a. blandford, d. furniss. dicot: a methodology for applying distributed cognition to the design of teamworking systems. interactive systems, pp. 26–38, 2006. [bmp08] c. bernardeschi, p. masci, h. pfeifer. early prototyping of wireless sensor network algorithms in pvs. in harrison and sujan (eds.), proc. of safecomp08. lecture notes in computer science 5219, pp. 346–359. springer, 2008. [bmp09] c. bernardeschi, p. masci, h. pfeifer. analysis of wireless sensor network protocols in dynamic scenarios. in proc. of sss09. lecture notes in computer science 5873, pp. 105–119. springer, 2009. [bs98] r. butler, j. sjogren. a pvs graph theory library. nasa technical memorandum 1998-206923, nasa langley research center, hampton, virginia, 1998. [ch97] j. c. campos, m. d. harrison. formally verifying interactive systems: a review. in proc. of the 4th intel. eurographics workshop on design, specification, and verification of interactive systems. pp. 109–124. springer, berlin, 1997. [cor+01] j. crow, s. owre, j. rushby, n. shankar, d. stringer-calvert. evaluating, testing, and animating pvs specifications. technical report, computer science laboratory, sri international, menlo park, ca, 2001. [dch00] g. j. doherty, j. c. campos, m. d. harrison. representational reasoning and verification. formal aspects of computing 12(4):260–277, 2000. issn: 0934-5043. [dxw08] h. dun, h. xu, l. wang. transformation of bpel processes to petri nets. in theoretical aspects of software engineering, 2008. tase ’08. 2nd ifip/ieee international symposium on. pp. 166–173. june 2008. [fb06] d. furniss, a. blandford. understanding emergency medical dispatch in terms of distributed cognition: a case study. ergonomics journal 49:1174–1203, 2006. [fh91] n. v. flor, e. l. hutchins. analyzing distributed cognition in software teams: a case study of team programming during perfective software maintenance. in empirical studies of programmers: fourth workshop. pp. 36–64. 1991. [fumk10] h. foster, s. uchitel, j. magee, j. kramer. an integrated workbench for modelbased engineering of service compositions. services computing, ieee transactions on 3(2):131–144, april/june 2010. [fur04] d. furniss. codifying distributed cognition: a case study of emergency medical dispatch. 2004. msc thesis, uclic, ucl interaction centre. [hut95] e. hutchins. how a cockpit remembers its speed. cognitive science 19:265–288, 1995. 15 / 16 volume 45 (2011) modelling distributed cognition systems in pvs [km94] d. kirsh, p. maglio. on distinguishing epistemic from pragmatic action. cognitive science 18:513–549, 1994. [md08] j. mcknight, g. doherty. distributed cognition and mobile healthcare work. in proc. of bcs-hci ’08. pp. 35–38. british computer society, swinton, uk, 2008. [mm84] a. movaghar, j. meyer. performability modelling with stochastic activity networks. in proc. of the 1984 real-time systems symposium. pp. 215–224. 1984. [muñ03] c. muñoz. rapid prototyping in pvs. technical report nia report no. 2003-03, nasa/cr-2003-212418, national institute of aerospace, hampton, va, 2003. [nor02] d. a. norman. the design of everyday things. basic books, new york, reprint paperback edition, 2002. [orr+96] s. owre, s. rajan, j. rushby, n. shankar, m. srivas. pvs: combining specification, proof checking, and model checking. in alur and henzinger (eds.), computeraided verification, cav ’96. lecture notes in computer science 1102, pp. 411–414. springer-verlag, new brunswick, nj, july/august 1996. [pri05] priority dispatch corp. inc. proqa 3.4, emergency dispatch software. 2005. www.prioritydispatch.net/support/pdf/proqa user guide.pdf. [rbcb09] r. rukšėnas, j. back, p. curzon, a. blandford. verification-guided modelling of salience and cognitive load. formal aspects of computing 21:541–569, 2009. [re94] y. rogers, j. ellis. distributed cognition: an alternative framework for analysing and explaining collaborative working. journal of information technology 9:119– 128, 1994. [rus02] j. rushby. using model checking to help discover mode confusions and other automation surprises. reliability engineering and system safety 75(2):167–177, february 2002. available at http://www.csl.sri.com/users/rushby/abstracts/ress02. [so99] n. shankar, s. owre. principles and pragmatics of subtyping in pvs. in bert et al. (eds.), proc. of wadt ’99. lecture notes in computer science 1827, pp. 37–52. springer-verlag, toulouse, france, september 1999. [srsf06] h. sharp, h. robinson, j. segal, d. furniss. the role of story cards and the wall in xp teams: a distributed cognition perspective. in proceedings of the conference on agile 2006. pp. 65–75. ieee computer society, washington, dc, usa, 2006. [thi08] h. thimbleby. ignorance of interaction programming is killing people. acm interactions, pp. 52–57, september/october 2008. [zaw+10] h. zha, w. van der aalst, j. wang, l. wen, j. sun. verifying workflow processes: a transformation-based approach. software and systems modeling, pp. 1–12, 2010. 10.1007/s10270-010-0149-9. proc. fmis 2011 16 / 16 http://www.csl.sri.com/users/rushby/abstracts/ress02 introduction and motivation dicot models information flow model example: the london ambulance service background on pvs formal specification of dicot's information flow model generic models simulation engine case study high-level specification refining the high-level specification formal analysis simulations related work and conclusion electronic communications of the easst volume ? (2009) proceedings of the ninth international workshop on automated verification of critical systems (avocs 2009) automatic translation of c/c++ parallel code into synchronous formalism using an ssa intermediate form loı̈c besnard, thierry gautier, matthieu moy, jean-pierre talpin, kenneth johnson and florence maraninchi 15 pages guest editors: markus roggenbach managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 eceasst automatic translation of c/c++ parallel code into synchronous formalism using an ssa intermediate form loı̈c besnard1, thierry gautier1, matthieu moy2, jean-pierre talpin1, kenneth johnson1 and florence maraninchi2 1inria centre rennes-bretagne atlantique/cnrs irisa. campus de beaulieu. 35042 rennes cedex, france. e-mail: firstname.lastname@irisa.fr 2verimag. centre équation. 2, avenue de vignate. 38610 gières, france. e-mail: firstname.lastname@imag.fr abstract: we present an approach for the translation of imperative code (like c, c++) into the synchronous formalism signal, in order to use a model-checker to verify properties on the source code. the translation uses ssa as an intermediate formalism, and the gcc compiler as a front-end. the contributions of this paper with respect to previous work are a more efficient translation scheme, and the management of parallel code. it is applied successfully on simple systemc examples. keywords: ssa, synchronous, signal, c, compilation, gcc, model-checking 1 introduction 1.1 context and motivations nowadays, embedded systems are becoming more and more complex, with stronger and stronger constraints of many kinds: cost, reliability, short life-cycle, and so on. design correctness of software and hardware functionalities of embedded systems is one of the major challenges and priorities for designers using software programming languages such as systemc and c/c++ to describe their systems. these programming languages allow for a comfortable design entry, fast simulation, and software/hardware co-design. moreover, as the complexity of systems increases, designers are bound to reuse existing intellectual property components (ips) in their design to improve the design productivity. however, system validation is a critical challenge for design reuse based on software programming languages. in recent years, many automated simulators and test tools have been developed to deal with design verification problems. however, mere simulation with non-formal development tools does by no means cover all design errors. what we therefore need is to use formal methods to ensure the quality of system designs. among formal methods, model-checking [cgp99] has proved successful at increasing the reliability of some systems. on the other hand, synchronous languages [bb91, bce+03] have been introduced and used successfully for the design and implementation of real-time critical software. they rely on mathematical models such as data-flow equations or finite state machines that enable formal reasoning 1 / 15 volume ? (2009) translation of c/c++ parallel code into synchronous formalism on designs. as a matter of fact, their associated toolsets provide among other formal transformations, automatic code generation, and verification of properties. relying on these bases, we propose an approach in which we automatically translate c/c++ models into the synchronous formalism signal [lgll91, ltl03], hence enabling the application of formal methods without having to deal with the complex and error prone task to build formal models by hand. in particular, this allows one to use the signal toolbox, which includes in particular a code generator and a model-checker. we base our approach and associated tool on previous studies for the translation of imperative languages to the synchronous data-flow language signal [tlsg05, ktbb06]. this translation relies on the use of ssa (“static single assignment”) as intermediate representation of programs. until now however, those previous works had not been fully implemented nor experimented. only manual experiments had been completed. moreover we extend the existing approach in two ways: first, the new translation scheme is more efficient, since it generates as few state variables as possible, thus reducing the work of the model-checker, and secondly, the tool now manages parallel, non-preemptive code. as an example of such parallel language, we study the particular case of systemc, a library for c++ for the high-level modeling of systems-on-a-chip, which provides among other things a non-preemptive scheduler for c++ processes. the translation specified here was implemented in the polychrony toolset [inra]. modelchecking was successfully applied with the tool sigali. an approach that could be compared to ours, although different (uses neither ssa nor synchronous formalisms) is that presented in [hfg08]. the authors define a semantic mapping from systemc to uppaal timed automata in order to get model-checking for systemc designs. it can be observed that our approach, thanks to the different strategies of code generation available for signal programs [bgt09], also provide simulation code corresponding to the parallel systemc description, including e.g. static scheduling code. in this paper, we give in section 1.2 an overview of the synchronous data-flow language signal and in section 1.3 a brief description of ssa, which is the basis for our translation. the principles of the translation from ssa to signal and its implementation are described in section 2. then section 3 addresses the addition of co-routine parallelism in the programs, using a systemc flavour. experimental results are provided for the model-checking of properties on some use case. some concluding remarks are given in section 4. 1.2 an overview of signal in signal, a process p consists of the composition of simultaneous equations x := f (y, z) over signals x, y, z. a signal x ∈ x is a possibly infinite flow of values v ∈ v sampled at a discrete clock noted ˆx. p, q ::= x := y f z | p where x | p|q (signal process) the synchronous composition of processes p|q consists of the simultaneous solution of the equations in p and in q. it is commutative and associative. the process p where x restricts the signal x to the lexical scope of p. proc. avocs 2009 2 / 15 eceasst an equation x := y f z denotes a relation between the input signals y and z and an output signal x by a combinator f . an equation is usually a ternary and infixed relation noted x := y f z but it can in general be an m + n-ary relation noted (x1, . . . xm) := f (y1, . . . yn). such equations are built with usual boolean or arithmetic operations such as or, and, not, =, <, +, ∗, . . . in addition, signal requires primitive combinators to perform delay x := y $1 init v, sampling x := y when z, merge x = y default z and specify scheduling constraints x → y when ˆz. the equation x := y f z where f is or, =, +, . . . defines the nth value of the signal x by the result of the application of f to the nth values of signals y, z. all signals x, y, z are synchronous (have the same clock): they share the same set of tags t1,t2, . . . (a tag represents a clock tick). the equation x := y $1 init v initially defines the signal x by the value v and then by the previous value of the signal y. the signal y and its delayed copy x are synchronous: they share the same set of tags t1,t2, . . . initially, at t1, the signal x takes the declared value v and then, at tag tn, the value of y at tag tn−1. the equation x := y when z defines x by y when z is true (and both y and z are present); x is present with the value v1 at t1 only if y is present with v1 at t1 and if z is present and true at t1. the equation x := y default z defines x by y when y is present and by z otherwise. if y is absent and z present with v1 at t1 then x holds v1 at t1. if y is present with v2 (at t2 or t3) then x holds its value v2 whether z is present (at t2) or not (at t3). the equation x → y when ˆz forces the constraint that y cannot occur before x when z is present. in signal, the presence of a value along a signal x is the proposition noted ˆx that is true when x is present and that is absent otherwise. the clock expression ˆx can be defined by the boolean operation x = x (i.e. y := ˆx =defy := (x = x)). specific operators are defined on clocks. for instance, yˆ+z is the union of the clocks of signals y, z (x := yˆ+z =defx := ˆy default ˆz). clock expressions naturally represent control, the clock when x represents the time tags at which the boolean signal x is present and true (i.e. y := when x =defy := true when x). the clock when not x represents the time tags at which the boolean signal x is present and false. we write ˆ0 for the empty clock (the empty set of tags). a clock constraint e is a signal process. the constraint eˆ= e′ synchronizes the clocks e and e′. it corresponds to the process (x := (ˆe = ˆe′)) where x. composition e |e′, written also (|e |e′ |), corresponds to the union of constraints, and restriction e where x to the existential quantification of e by x. a useful derived operator is the memory x := y cell z init v, that allows to memorize in x the latest value carried by y when y is present or when z is true (x := y cell z init v =def(|x := y default (x $1 init v)|xˆ= yˆ+(when z)|)). 1.3 ssa: an intermediate representation a program is said to be in static single assignment (ssa) form whenever each variable in the program appears only once on the left hand side of an assignment. following [cfr+91], a program is converted to ssa form by replacing assignments of a program variable x with assignments to new versions x1, x2, . . . of x, uniquely indexing each assignment. each use of the original variable x in a program block is replaced by the indexed variable xi when the block is reachable by the ith assignment. for variables in blocks reachable by more than one program block, the φ 3 / 15 volume ? (2009) translation of c/c++ parallel code into synchronous formalism operator is used to choose the new variable value depending on the program control-flow. for example, x3 = φ (x1, x2) means “x3 takes the value x1 when the flow comes from the block where x1 is defined, and x2 otherwise”. this is needed to represent c programs where a variable can be assigned in both branches of a conditional statement or in the body of a loop. in this paper, we consider the ssa intermediate representation of the gcc compiler (other modern compilers usually have a similar intermediate format). the compiler provides a language independent, locally optimized intermediate representation for c, c++, and java programs where programming units such as functions and methods are transformed into a structure in which all native operations are represented by 3-address instructions x = f (y, z). a c program pgm is represented by a sequence of labeled blocks l:blk, where each block is a sequence of statements. statements may be function calls x = f (y∗) or branches ifxgotol. each block is terminated by either a return rtn or gotol statement. we summarise this representation in figure 1. (program) pgm ::= l:blk|pgm; pgm (instruction) stm ::= x = f (y∗) (call) (instruction) stm ::= x = φ (y∗) (phi) | ifxgotol (test) (block) blk ::= stm; blk|rtn (return) rtn ::= gotol (goto) | return (return) figure 1: intermediate representation for c programs 2 translating sequential code from ssa to signal 2.1 ssa to signal: an example we depict the structure of the ssa form of a typical c program, figure 2. the function ones counts the number of bits set to 1 in a bit-array data. it consists of four blocks (labeled bb 0, l0, l1, l2). the block bb 0 initializes the local state variable idata to the value of the input signal data and icount to 0. then it passes control to the block l1. label l1 evaluates the termination condition of the loop and passes control accordingly. as there are several possible sources in the control flow for the variables idata and icount, it determines the most recent value with the help of φ functions. if the termination condition is not yet satisfied, control goes to block l0, which corresponds to the actual loop contents that shifts idata right and adds its right-most bit to icount. if the termination condition is satisfied (all available bits have been counted) control goes to block l2 where the result is copied to the output signal ocount. figure 3 depicts the translation of function ones into signal. signals data and ocount are respectively input signal (line 2) and output signal (line 3) of the corresponding signal process. lines 4–8 define the labels as boolean signals being true when control flow is in the corresponding block. for instance, bb 0 is true at the first instant, then it is false forever; l1 is true when either l0 or bb 0 is (control can go to l1 from l0 or bb 0). note that there is no need to introduce a delay when control passes to l1. this is not the case for l0, for which there is a transition from l1 when the termination condition of the loop is not satisfied ((idata 3/=0) when l1): in that case, control will be in l0 at the next step. proc. avocs 2009 4 / 15 eceasst void ones(int data, int *ocount) { int icount, idata; idata = data; icount = 0; while (idata) { icount += idata & 1; idata >>= 1; } *ocount = icount; } bb_0: idata_1 = data; icount_1 = 0; goto l1; l0: d = idata_3 & 1; icount_2 = d + icount_3; idata_2 = idata_3 >> 1; l1: idata_3 = phi; icount_3 = phi; if (idata_3 != 0) goto l0; l2: *ocount = icount_3; return; figure 2: from c to static single assignment lines 14–15, 17–19 and 24 represent respectively the computations that are done in blocks bb 0, l0 and l2: this is expressed by the sampling (when) on the corresponding boolean. note that state variables are necessary to memorize the values of idata 3 and icount 3 (lines 10– 11). line 18, the operands of the plus operator have to be memorized at some common clock ( pk 1, line 27) since the arguments of the plus must be synchronous. the φ functions of block l1 are simply defined with merge (default) operators in signal (lines 21–22). 2.2 ssa to signal: translation scheme a general scheme for the translation is described in figure 4 with a function i [[pgm]], defined by induction on the formal syntax of pgm. the overall idea is to translate one (or several) ssa basic blocks into a parallel assignment in signal. the sequence of instructions in ssa is then considered within a signal clock tick. in the presence of loops (i.e. backward gotos), we must represent the successive values taken by variables at different laps of the loop with different clock ticks. the control flow is modeled with the notion of clock: a parallel assignment in signal has its clock activated when the corresponding piece of ssa code would be executed. the present value of a signal is noted x, its next value is noted x′. with each block of label l ∈ l f in a given function f , the function i [[pgm]] associates an input clock xl, an immediate clock ximml and an output clock x exit l (note that all these clocks are not necessarily generated in the effective translation). the clock xl is true iff l has been activated in the previous transition (by emitting the event x′l). the clock x imm l is set to true to activate the block l immediately. the clock xexitl is set to true when the execution of the block labeled l terminates. the default activation condition of this block is the clock xl ∨ ximml (union of clocks xl and ximml : equation (1) of figure 4). the block blk is executed iff the proposition xl ∨ ximml holds, meaning that the program counter is at l. for a return instruction or for a block, the function returns a signal process p. for a block instruction stm, the function i [[stm]]e1l = 〈p〉e2 takes three arguments: an instruction stm, the label l of the block it belongs to, and an input clock e1. it returns the process p corresponding to the instruction and its output clock e2. the output clock of stm corresponds to the input clock of the instruction that immediately follows it in the execution sequence of the block. rules (1-2) in figure 4 are concerned with the iterative decomposition of a program pgm into 5 / 15 volume ? (2009) translation of c/c++ parallel code into synchronous formalism 1 process ones = 2 ( ? integer data; 3 ! integer ocount; ) 4 (| (| bb_0 := (not (ˆbb_0)) $1 init true 5 | next_l0 := ((idata_3/=0) when l1) default false 6 | l0 := next_l0 $1 init false 7 | l1 := (true when l0) default (true when bb_0) 8 | l2 := (not (idata_3/=0)) when l1 9 |) 10 | (| z_idata_3 := idata_3 $1 11 | z_icount_3 := icount_3 $1 12 |) 13 | (| data_1 := data cell (ˆbb_0) |) 14 | (| idata_1 := data_1 when bb_0 15 | icount_1 := 0 when bb_0 16 |) 17 | (| d := bit_and(z_idata_3, 1) when l0 18 | icount_2 := ((d cell _pk_1)+(z_icount_3 cell _pk_1)) when l0 19 | idata_2 := bit_right_shift(z_idata_3, 1) when l0 20 |) 21 | (| idata_3 := idata_2 default (idata_1 default z_idata_3) 22 | icount_3 := icount_2 default (icount_1 default z_icount_3) 23 |) 24 | ocount_1 := icount_3 when l2 25 | (| when bb_0 ˆ= data 26 | bb_0 ˆ= l0 ˆ= idata_3 ˆ= icount_3 ˆ= data_1 27 | _pk_1 := z_icount_3 ˆ+ d 28 |) 29 | (| ocount := (ocount_1 cell l2) when l2 |) 30 |) 31 where ... end; figure 3: from ssa to signal blocks blk and with the decomposition of a block into stm and rtn instructions. in rule (2), the input clock e of the block stm; blk is passed to stm. the output clock e1 of stm becomes the input clock of blk. the input and output clocks of an instruction may differ. this is the case, rule (3), for an ifxgotol1 instruction in a block l. let e be the input clock of the instruction. when x is false, then control is passed to the rest of the block, at the output clock e∧¬x (intersection of clocks e and ¬x). otherwise, the control is passed to the block l1, at the clock e∧x. there are two ways of passing the control from l to l1 at a given clock e. they are defined by the function gl(l1, e): either immediately, by activating the immediate clock ximml1 , i.e., e ⇒ ximml1 (the notation e ⇒ p means: if e is present then p holds); or by a delayed transition to l1 at e, i.e., e ⇒ x′l1 . this choice depends on whether l1 is after l in the control flow, i.e. whether the block l1 can be executed immediately after the block l. rule (4) is concerned with the translation of native and external function calls x = f (y∗). the generic translation of f is taken from an environment e ( f ). it is given the name of the result x, of the actual parameters y∗ and of the input clock e to obtain the translation of x = f (y∗). this proc. avocs 2009 6 / 15 eceasst (1) i [[l:blk; pgm]] =i [[blk]] xl∨ximml l |i [[pgm]] (2) i [[stm; blk]]el=let〈p〉e1 = i [[stm]]el in p|i [[blk]]e1l (3) i [[ifxgotol1]]el=〈gl(l1, e∧x)〉e∧¬x (4) i [[x = f (y∗)]]el=〈e ( f )(xy∗e)〉e (5) i [[gotol1]]el=(e ⇒ xexitl |gl(l1, e)) (6) i [[return]]el=(e ⇒ (xexitl |xexitf )) where gl(l1, e)= if l1 is after l in the control-flow then e ⇒ ximml1 else e ⇒ x′l1 e ( f )(xyze)=e ⇒ (x̂|x = [[ f ]](y, z)), ∀ f xyze figure 4: translation scheme translation works when there is only one call to f at the same time. recursive calls of f would require an explicit stack, and parallel calls would require duplicating the generated code for f for each thread. the generic translation of 3-address instructions x = f (y, z) at clock e is given by e ( f )(xyze). instructions goto and return, rules (5-6), define the output clock xexitl of the current block l by their input clock e. this is the right place to do that: e defines the very condition upon which the block actually reaches its return statement. a gotol1 instruction, rule (5), passes control to block l1 unconditionally at the input clock e by gl(l1, e). a return instruction, rule (6), sets the exit clock x f to true at clock e to inform the caller that f is terminated. 2.3 c/c++ to signal: implementation signal models are automatically generated from c/c++ component descriptions with the help of the gnu compiler collection (gcc) [fre] and its static single assignment (ssa) intermediate representation [gcc03, the]. this is obtained in three main stages, as described below: 1. converting c/c++ into ssa: the first step of the translation scheme consists in converting c/c++ models into the ssa form. this step is performed by gcc, which goes through several intermediate formats (gimple trees, then control-flow graph (cfg)), and then produces the ssa form which is used by gcc for optimizations. 2. converting ssa into signal: the next step of the translation scheme consists in converting ssa into signal processes. it is implemented in the gcc front-end. the output of this step is a signal program which reflects directly the ssa code in a signal syntax (but without a correct semantics at this point). the implementation of the signal generation is inserted in the gcc source tree as an additional front-end optimization pass. gcc currently features over fifty optimization passes. it can be chosen to use all of these by inserting this additional pass at the very end, but it may also make sense to exclude some of the optimizations. the resulting syntactic signal program is another view of the ssa code without any transformation (so the connexion to some other c compiler with an 7 / 15 volume ? (2009) translation of c/c++ parallel code into synchronous formalism ssa internal representation would be easily possible). this code is composed of a set of labeled blocks, composed of a set of φ definitions, a set of computations, and a branching. 3. transforming the signal program: the next step consists in the definition of (i) the control induced by the references to the labels in the branching statements; (ii) the memories induced by the loops and the control. the control is given first to the first block (through the signal bb_0 in the function ones example). 3 modeling parallelism in the ssa to signal line the previous section described a translation of sequential, imperative code, into signal. we now present a way to extend this translation scheme to parallel code. we consider the case of co-routine semantics (i.e. non-preemptive scheduling with a single processor). systemc is an example of an execution platform with co-routine semantics. it is built on top of the c++ language, augmented with a scheduler, and communication and synchronization primitives. we implemented a translation from a small subset of systemc which has basically two elements with respect to parallelism: pieces of code to be executed “atomically”, and a yield() instruction, that stops the execution of a thread, and yields the control back to the scheduler. the scheduler then elects any thread, non-deterministically. the official systemc library does not have a yield() instruction, but this instruction can be implemented either with a slight modification of the scheduler as proposed in [hel07], or more simply by a wait(random(), sc ns);. the motivation for choosing yield() instead of the usual wait() statements of systemc is to start with the simplest scheduling, to keep the focus on the notion of parallelism. we will show later that implementing an arbitrary scheduling policy on top of this is possible. in this subset of systemc, we do not have any specific communication and synchronization primitives, but processes can communicate using shared variables. 3.1 presentation of systemc the core of the systemc syntax relevant to the present study is represented in figure 5. a system consists of the composition of classes and modules sys. a class declaration class m{dec} associates a class name m with a sequence of fields dec. it is optionally parameterized by a class with template〈class m1〉. to enforce a strong typing policy, we annotate the class parameter m1 with #type(m1, m2) to denote the type of m1 with the virtual class m2. a module sc module(m) is a class that defines an architecture component. its constructor sc ctor(m) {new; pgm} allocates threads (e.g. sc thread( f )) and executes an initialization program pgm. modules define threads whose execution is concurrent. declarations dec associate locations x with native classes or template class instances m〈m∗〉, and procedures with a name f and a definition pgm. pgm can be any c++ code. we assume x to denote the name of a variable or signal and to be possibly prefixed as m :: x by the name of the class it belongs to. a simple example in given in figure 6. it defines two n-bits counters in parallel. the macro declare counter declares n boolean state-variables bi, the function step performs one step (applying next(bi) = bi xor ci−1 and ci = bi and ci−1, ci being the carry), and the macro proc. avocs 2009 8 / 15 eceasst sys ::= [ template〈class m1〉#type(m1, m2) ] class m{dec} (class) | sc module(m) {dec; sc ctor(m) {new}}; (module) | sys sys (sequence) dec ::= m〈m∗〉x (field) | void f () {pgm}; (thread) | dec dec (sequence) new ::= sc thread( f ); sensitive ¿ x∗ | new; pgm (constructor) figure 5: abstract syntax for systemc beginning of process declares the local variables ci. each counter comes with two additional variables ... started and ... finished, maintained up-to-date by step(), that are true respectively after the counter did its first step, and once each bit of the counter is true. sc_module(module) { declare_counter(count1_); declare_counter(count2_); void compute1() { beginning_of_process; while(!(count2_started)) { yield(); } while(!(count1_finished)) { step(count1_); yield(); } assert(count2_finished); } void compute2() { beginning_of_process; while(!(count2_finished)) { step(count2_); // yield(); } } sc_ctor(module) { init_counter(count1_); init_counter(count2_); sc_thread(compute1); sc_thread(compute2); } }; figure 6: parallel counters 3.2 principle of the translation for systemc code in systemc, the bodies of processes are described using plain c++ code (plus function calls to the systemc api, i.e. yield in our example). as a consequence, the translation from c/c++ to signal can be reused for that purpose with a few adjustments, detailed in the following. the general principle is to represent each thread by a signal process, and the scheduler may be also represented as another signal process. these processes communicate through added control signals corresponding to communication events. the clocks of these signals have to be precisely defined as signal expressions. 9 / 15 volume ? (2009) translation of c/c++ parallel code into synchronous formalism 3.2.1 isolation of system calls first it can be noticed that gcc considers systemc macros (including synchronization primitives (“system calls”) like yield as plain c++. as opposed to that, our approach requires a special handling of these macros in the signal code. thus they have first to be visible in the ssa code generated for the systemc threads. to this end, they have to be viewed by gcc as external function calls. this is the case, for instance, for the instruction yield used in the program of figure 6: it is passed as such in the ssa code. however, if system calls are processed by gcc as usual external calls, they are not distinguished from other instructions in the ssa code and they may appear among other computations in ssa labeled blocks. a first requirement for being able to process system calls specifically in signal is thus to isolate them in specific blocks in ssa. this is an easy transformation that consists in breaking up the blocks containing system calls, while respecting the control flow. in the ssa to signal transformation, it is implemented as the very first step of the transformations applied on the syntactic signal code (see section 2.3, step 3). in the resulting signal translation, the label of the block containing a system call will be viewed as the activation clock of the call of the primitive. then, suppose that l0, . . . , ln are the labels corresponding to the different calls of a given primitive (say yield, for instance) in a given thread, then the following signal: yield := (when l0) default . . . default (when ln) represents the clock at which control has to be returned to the scheduler, from a yield primitive, for the considered thread. also, it is necessary to take into account that the block that follows a system call cannot be run in the same logical instant than this system call (the os has to take the control). thus, the signal representing the label of this block has to be delayed by one instant and additional memories may be required for some variables. 3.2.2 addition of control signals in the c to signal translation, input and output signals of the signal process resulting from the translation of a c procedure correspond to the parameters of the procedure. when translating a thread in a multi-thread context, a few input or output control signals have to be added, in order to communicate with the system. these signals are the following: input signal running: this signal is defined by the system. it specifies the clock at which the process is actually running (the processor is attributed to this process). remind that in the signal code obtained from a ssa form, each operation is sampled, either directly or recursively, by the clock corresponding to a given label (for instance, ocount 1 := icount 3 when l2). in the process corresponding to a thread, each label is additionally sampled by the signal running (for instance, l2 := (not (idata 3/=0)) when l1 when running). output signal end processing: this signal is defined by the clock corresponding to the final block of the ssa (for the example of figure 3, it would be: end processing := when l2). this is the way for processes to inform the scheduler that a yielding instruction was reached, letting the scheduler decide which process to wake up after. output signals corresponding to system calls in the thread: for example, a signal yield , as defined above, is produced, corresponding to the clock of the calls of the yield primproc. avocs 2009 10 / 15 eceasst itive in the thread. other signals correspond to wait or signal primitives, for instance. if the primitives are not used in the process, their clock is the empty clock. these signals complement end processing in that end processing says whether a yielding instruction was reached, while other signals like yield tell which one. these signals are added automatically in the translation when the application is a multithreaded one. note that another input signal, start, can be added if restart is possible. it is then used to replace the definition of the initial label of the process: bb 0 := (start default false) when running. 3.2.3 shared variables care has to be taken for variables shared by different threads. first, when a variable is not declared in the procedure where it is used, gcc does not produce real ssa for these variables: there is no creation of distinct instances for them, no φ function for merging their different definitions. they are considered as “virtual ssa”. for these variables, the mechanism of partial definitions provided in signal is used. let x be such a variable and suppose one of its definitions is x = e in a ssa block labeled li. the corresponding signal definition will be: x ::= e when li (the use of ::= means that there are possibly other definitions for x). the shared variables are necessarily state variables in signal, for which their previous value is kept, when they are not redefined. 3.2.4 inclusion in a simulator in order to validate the translation scheme described above, a mock-up scheduler is described in signal. this scheduler contains a non-preemptive scheduler that attributes non-deterministically the processor to one process when several processes are ready to execute. this corresponds to the systemc scheduler with the yield() instruction described above. in signal, if conflict represents the clock at which there is a potential conflict for the attribution of the processor (several processes are ready), the running process is chosen by: pid := (any when conflict) default ..., where any is an input signal that can take any value. the scheduler manages the status of each one of the processes pi corresponding to the threads of the application. a signal process set status is associated with each pi, with state variables representing the current and next status of pi (ready, running). the scheduler receives and uses the control signals that are produced in the processes pi. for instance, the clock of the signal yield produced in some process pk defines instants at which the next status of pk, whose current status is running, will be ready (so that the scheduler will have to choose, non-deterministically, a new running process). thus, in return, the scheduler defines the control signals running provided to each one of the pi’s. for a given pk, the corresponding signal running represents the clock at which pk has the running status. it is worth noticing that the control of a given application is represented very differently in signal than it would be in some usual imperative parallel language. there is no explicit program counter, no imperative description of suspend or resume actions. the control is fully described by the clocks of the signals of the application. the signal equations defining some process pi define its behavior as invariant equations. we explained that all operations in pi are 11 / 15 volume ? (2009) translation of c/c++ parallel code into synchronous formalism conditioned by a given input signal running. periods of time in which pi is not running (or is otherwise suspended) correspond to the instants at which the signal running is absent. so that suspend/resume, for instance, is automatically handled through the clock of the signal running. 3.2.5 possible extensions the scheduler described above is very simple. with the signals running, and end processing, it can model a non-preemptive scheduler. by adding more signals between the scheduler and the processes, and a more complex state-machine in the scheduler, one can relatively easily model a more complex scheduler, like the complete scheduler of systemc. indeed, a similar approach was followed in the tool lussy [mmm06] and could easily be adapted, since lussy also uses a synchronous formalism to model the scheduler. the scheduler used in lussy omits a few details of the actual scheduler specifications, but a more complete version is described in [tkvs08], and even this version is still only a dozen states, and could be modeled with a few tens of lines of code in signal. the main difference with the translation implemented in lussy is that the latter does not use ssa as an intermediate form, and is indeed less efficient for the translation of plain c++ code (a more detailed comparison of the tools is in progress and will not be detailed here). 3.3 experiments the example described in section 3.1 (figure 6) is used for basic experiments. the program is automatically translated into signal via ssa following the general scheme described above. then simulation code (in c) is generated from the signal program with the polychrony toolset [inra]. traces have been added in the signal program to be able to follow the simulation. the results are those expected, whatever is the choice of the scheduler. besides these first results, a main objective of the experiments is to demonstrate the possibility of formal validation of models using this methodology. we use again the same example (parallel counters) to prove formal properties using model-checking. the first counter waits that the second one has started counting to count also. at the end, it checks that the second counter has finished (property assert(count2 finished)). indeed, from the point of view of the first counter, when the second one has started, it has also terminated, so that the property is true. a variant of the program (parallel counters with variant) is when a yield() is introduced in the body of the loop of the second counter. in that case, it is possible to start the second counter without finishing it, and then the first counter can run till the end, so that the property is false. the signal compiler included in the polychrony toolset allows for checking static properties such as contradictory clock constraints, cycles, null clocks, exclusive clocks. . . in order to check dynamic properties, the signal companion model-checker sigali [inrb, mr] may be used. it is an interactive tool specialized on algebraic reasoning in z/3z logic. sigali transforms signal programs into sets of dynamic polynomial equations that basically describe an automaton. then it can analyze this automaton and prove properties such as liveness, reachability, and deadlock. the fact that it is reasoning only on a z/3z logic constrains the conditions to the boolean data type (true, false, absent). this is practical in the sense that true numerical verification very soon would result in state spaces that are no longer manageable, however it requires, proc. avocs 2009 12 / 15 eceasst depending on the nature of the underlying model, major or minor modifications prior to formal verification. for many properties, numerical values are not needed at all and can be abstracted away thus speeding up verification. when verification of numerical manipulations is sought, an abstraction to boolean values can be performed (like replacing any condition depending on integers with non-deterministic boolean), that suffices in most cases to satisfy the needs. note that the translation to the sigali format is done after the so-called clock calculus completed by the signal compiler. this clock synthesis allows to reduce significantly the number of constraints. unfortunately, sigali does not provide counter-examples for the system when the proof fails. for the parallel counters example and its variant, all data types are boolean (and the mock-up scheduler has been encoded also using only boolean types). the results of the verification of properties using signal and sigali are those expected. performances (time and size of the system) for obtaining the results are provided in figure 7 for 2-bits and 8-bits versions of the counters (they are obtained using a reordering of variables in sigali). size time program state var. states reach. states transitions 2-bits parallel counters (property true) 24 224 36 116 0.15 s 2-bits parallel counters with variant (prop. false) 25 225 107 359 0.27 s 8-bits parallel counters (property true) 36 236 1.296 3.896 66 s 8-bits parallel counters with variant (prop. false) 37 237 328.715 1.117.223 124 s figure 7: performances for proving properties with sigali 3.4 discussion on performances one common mis-conception about ssa is that since multiple assignments to the same variable are translated into assignments to multiple intermediate variables, the explosion of the number of variables introduces a huge overhead. this paper shows that the explosion of the number of variables is indeed not a problem: most variables are encoded into temporary variables in signal, and will be dealt with very efficiently by a model-checker (no additional nodes in bdds). our experiments show that the number of state variables does not explode. on the other hand, one real advantage of this approach is that it creates very few transitions in the generated code. in the absence of loops, a portion of code between two yielding instructions is indeed encoded in one clock tick in the synchronous world. as opposed to this, a naive approach translating each instruction with an explicit control-point would generate huge automata, with a lot of control-points. the encoding of this automaton would introduce either a lot of boolean state variables (with a one-hot encoding) or state variables with a large number of possible values. our ssa-based translation avoids this overhead. 13 / 15 volume ? (2009) translation of c/c++ parallel code into synchronous formalism 4 conclusion we described the principle and implementation of a translation of imperative code into the synchronous data-flow language signal. using ssa as an intermediate format, the translation is natural. since the ssa form we are using (the one of gcc) is very simple, the implementation does not have to deal with all the particular cases of the source language (c++), and can focus on optimizations and performances. we also showed that the extension to a simple model of parallelism was possible and relatively straightforward, and showed the way to encode a more complex scheduling policy. the main limitation of the approach with respect to parallelism is that although the co-routine semantics (non-preemptive scheduling) is encoded as a natural extension of the sequential translation, a preemptive scheduling, or even real parallelism, would be much harder to model faithfully with this principle. indeed, the main point of our approach is to encode a sequence of assignments, in one or several basic blocks, into a single parallel assignment, within one clock tick. this turns the sequential piece of code into large atomic actions, which were not atomic in the original code. in other words, applying the translation naively would reduce the set of possible interleaving, thus reducing the set of possible behaviors, and missing bugs in the proof. applying the translation to real parallel code would therefore require identifying which portions of code can be considered atomic, and where to introduce preemption points. each preemption point could then be encoded in the same way as the yield() instruction. actually, identifying which section can be considered atomic, which instructions can permute and move from a section to another, is an active research domain (see for example [qrr04]). another limitation of the current implementation is that we currently manage only a small subset of systemc. modeling the scheduling algorithm itself would probably not be the most difficult part. one bigger difficulty is to take the architecture of the platform into account. for example, when one process writes wait(event); and the other writes event.notify();, the translation obviously has to take into account the fact that event is the same object in both cases. another example is when one does a port.write(value); and the other a another port.read(): in this case, the translation has to depend on whether port and another port are bound together or not. extracting such information from systemc code requires a systemc front-end, and not just a c++ one. many such front-ends exist, like pinapa [mmm05] used by lussy, but none of them use ssa as an intermediate representation. unfortunately, re-using an existing compiler to get both an ssa intermediate form and the architecture of the platform, linked together, is not easy [bgm+08]. the approach followed by pinapa does reuse an existing compiler, but relies partly on the fact that the intermediate format is a high-level abstract syntax tree. we are working on a new version of pinapa that would use an ssa-based compiler, but this requires a substantial rework of the approach, and a complete rewrite of the code itself. bibliography [bb91] a. benveniste, g. berry. the synchronous approach to reactive and real-time systems. proceedings of the ieee 79(9):1270–1282, sep. 1991. proc. avocs 2009 14 / 15 eceasst [bce+03] a. benveniste, p. caspi, s. a. edwards, n. halbwachs, p. le guernic, r. de simone. the synchronous languages 12 years later. in proceedings of the ieee. pp. 64–83. 2003. [bgm+08] l. besnard, t. gautier, f. maraninchi, m. moy, j.-p. talpin. comparative study of approaches to semantics extraction and virtual prototyping of system-level models. technical report, verimag, grenoble inp, france; irisa, inria rennes, france, 2008. http://www-verimag.imag.fr/∼moy/fotovp/rapport-fotovp.pdf. [bgt09] l. besnard, t. gautier, j.-p. talpin. code generation strategies in the polychrony environment. research report rr-6894, inria, 2009. http://hal.inria.fr/inria-00372412/en/ [cfr+91] r. cytron, j. ferrante, b. rosen, m. wegman, f. zadeck. efficiently computing static single assignment form and the control dependence graph. acm transactions on programming languages and systems (toplas) 13(4):451–490, 1991. [cgp99] e. clarke, o. grumberg, d. peled. model checking. springer, 1999. [fre] free software foundation. the gnu compiler collection. http://gcc.gnu.org. [gcc03] proceedings of the 2003 gcc developers summit. ottawa, ontario canada, 2003. [hel07] c. helmstetter. validation de modèles de systèmes sur puce en présence d’ordonnancements indéterministes et de temps imprécis. phd thesis, inpg, grenoble, france, march 2007. http://www-verimag.imag.fr/∼helmstet/these-fr.html [hfg08] p. herber, j. fellmuth, s. glesner. model checking systemc designs using timed automata. in codes/isss ’08: proceedings of the 6th ieee/acm/ifip international conference on hardware/software codesign and system synthesis. pp. 131–136. acm, new york, ny, usa, 2008. [inra] inria espresso team. polychrony tool. http://www.irisa.fr/espresso/polychrony. [inrb] inria vertecs/espresso teams. sigali tool. http://www.irisa.fr/vertecs/softwares/sigali.html. [ktbb06] h. kalla, j.-p. talpin, d. berner, l. besnard. automated translation of c/c++ models into a synchronous formalism. in engineering of computer based systems, 2006. ecbs 2006. 13th annual ieee international symposium and workshop on. pp. 426–436. march 2006. [lgll91] p. le guernic, t. gautier, m. le borgne, c. le maire. programming real-time applications with signal. proceedings of the ieee 79(9):1321–1336, sep. 1991. [ltl03] p. le guernic, j.-p. talpin, j.-c. le lann. polychrony for system design. journal for circuits, systems and computers 12(3):261–304, april 2003. [mmm05] m. moy, f. maraninchi, l. maillet-contoz. pinapa: an extraction tool for systemc descriptions of systems-on-a-chip. in emsoft. pp. 317 – 324. september 2005. [mmm06] m. moy, f. maraninchi, l. maillet-contoz. lussy: an open tool for the analysis of systems-on-a-chip at the transaction level. design automation for embedded systems, 2006. special issue on systemcbased systems. http://www-verimag.imag.fr/∼moy/publications/springer.pdf [mr] h. marchand, e. rutten. sigali user manual. http://www.irisa.fr/espresso/polychrony. [qrr04] s. qadeer, s. k. rajamani, j. rehof. summarizing procedures in concurrent programs. in popl ’04: proceedings of the 31st symposium on principles of programming languages. pp. 245–255. acm, new york, ny, usa, 2004. [the] the tree ssa project. tree-ssa. http://gcc.gnu.org/projects/tree-ssa. [tkvs08] d. tabakov, g. kamhi, m. vardi, e. singerman. a temporal language for systemc. in formal methods in computer-aided design, 2008. fmcad ’08. pp. 1–9. 2008. [tlsg05] j.-p. talpin, p. le guernic, s. k. shukla, r. gupta. a compositional behavioral modeling framework for embedded system design and conformance checking. international journal of parallel programming 33(6):613–643, 2005. 15 / 15 volume ? (2009) adaptive task automata with earliest-deadline-first scheduling electronic communications of the easst volume 70 (2014) proceedings of the 14th international workshop on automated verification of critical systems (avocs 2014) adaptive task automata with earliest-deadline-first scheduling leo hatvani, alexandre david, cristina seceleanu and paul pettersson 15 pages guest editors: marieke huisman, jaco van de pol managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst adaptive task automata with earliest-deadline-first scheduling leo hatvani1, alexandre david2, cristina seceleanu3 and paul pettersson4 1leo.hatvani@mdh.se 3cristina.seceleanu@mdh.se 4paul.pettersson@mdh.se mälardalen university västerås, sweden 2adavid@cs.aau.dk aalborg university aalborg, denmark abstract: adjusting to resource changes, dynamic environmental conditions, or new usage modes are some of the reasons why real-time embedded systems need to be adaptive. this requires a rigorous framework for designing such systems, to ensure that the adaptivity does not result in invalidating the system’s real-time constraints. to address this need, we have recently introduced adaptive task automata, a framework for modeling, verification, and schedulability analysis in adaptive, hard real-time embedded systems, assuming a fixed-priority scheduler. in this work, we extend the adaptive task automata framework to incorporate the earliest-deadline-first scheduling policy, as well as enable implementation of any other dynamic scheduling policy. to prove the decidability of our model, and at the same time maintain a manageable degree of conciseness, we show an encoding of our model as a network of timed automata with clock updates. to support this, we also show that reachability in our class of timed automata with updates is decidable. our contribution helps to streamline the process of designing safety critical adaptive embedded systems. keywords: model-checking, task automata, earliest-deadline-first scheduling 1 introduction one way to enable real-time embedded systems to cope with environment, application, or platform changes is to introduce adaptivity at the design phase of system development. adaptivity lets the system adjust to a new situation, but at the same time may introduce new errors such as breached timing constraints or other extra-functional requirements. our goal is to propose a way to streamline modeling and verification of adaptive embedded systems (aes) in order to minimize the introduction of such errors at the design stage. in the framework of adaptive task automata (ata) that we have recently proposed [hps12], we have started to address this need by providing formal support for modeling the aes behavior, simulation of the system execution, and verification of the schedulability. by formally verifying the 1 / 15 volume 70 (2014) mailto:leo.hatvani@mdh.se mailto:cristina.seceleanu@mdh.se mailto:paul.pettersson@mdh.se mailto:adavid@cs.aau.dk adaptive task automata with earliest-deadline-first scheduling t1 t2 c d t1 6 8 t2 3 3 t′2 2 2 t1 t′2 t1 t2 x ≥ 3 t1 t2x ≥ 3∧ sched (t1, t2) t′2 x ≥ 3∧¬sched(t1, t2) (a) (b) x ≤ 3 x ≤ 3 0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 7 8 9 10 figure 1: an adaptation example: (a) task automaton model, and (b) ata model. system’s schedulability, we ensure that the system is going to meet its hard real-time specifications as well as satisfy any other extra-functional properties. in our previous work on adaptive task automata, we have assumed fixed priority scheduling (fps) policy. in this work we are extending the framework to support dynamic scheduling policies by incorporating the earliest-deadline-first (edf) scheduling policy into the framework. hereinafter we will refer to the specific variant of ata with the edf scheduling policy as ataedf. the main contribution of this work is to find solutions to the challenges of verifying the edf schedulability of hard real-time tasks, in ata. to tackle this, we show that verification of schedulability in ataedf, described in section 2, is decidable, by proposing an encoding of the framework as a network of timed automata with (clock) updates (section 3). we present a summary of the proof of bisimilarity between the model and its encoding as well as decidability of reachability for our class of timed automata with updates (section 4). 2 adaptive task automata the adaptive task automata framework builds on top of task automata [fkpy07] by providing predicates that influence task release patterns based on the content of the ready queue. the task automata framework, in turn, is based on timed automata [alu99] extended with: tasks that can be released upon entering locations, a queue, and a scheduler to handle the released tasks and simulate their execution. since the current work elaborates on ata extensively, we refer the reader to the cited literature for more in-depth information. in our model, we assume a uniprocessor system with independent, non-suspending tasks. for each task, computation time and relative deadline are known and are specified as natural numbers. at any point in time, there can be at most one task instance (job) per task in the queue and will be also referred to as task. 2.1 introductory example as a simple example, consider the set of tasks in figure 1. each task is characterized by its execution time c and a relative deadline d. figure 1(a) models the release of the task t1 at time 0 by annotating the initial location (double concentric circle) with the task. task t2 is released in the second location after 3 time units. the delay is modeled by adding a zero-initialized clock (x) to the system, annotating the initial location with the invariant x ≤ 3 that models that the location will be exited after at most 3 time units, and adding a guard x ≥ 3 on the edge, denoting that the proc. avocs 2014 2 / 15 eceasst edge will not be taken until at least 3 time units have passed. if we schedule the model in figure 1(a) using edf, the deadline of the task t1 will be reached before the task has a chance to complete. assuming that we have t′2, a lower quality alternative to task t2, having a lower computation time, we could release t′2 instead. to be able to chose the variant of the task to be released, we have introduced the following predicates in our previous work [hps12]: • inqueue(ti) which is true iff the task ti is waiting in the ready queue or currently executing. • sched (ti) evaluates whether the task ti is going to complete its execution by the deadline. • sched (ti,t j), assuming that the task ti is already in the queue, evaluates whether it will complete in time if the task t j is released into the queue. by incorporating the predicate sched (ti,t j) into the model of figure 1(a), we get the model presented in figure 1(b). here, task t2 is released only if it will not disrupt task t1, otherwise, task t′2 is released. with this modification, which can be seen as adaptive behavior, both tasks can successfully complete. 2.2 overview of the existing framework in ata, the ready queue is a sequence of tasks ordered by the scheduling policy. each task ti in the ready queue is defined by two real values ci and di. they represent the remaining execution time until completion (ci) and the time until the task reaches its deadline (di). let us denote by t the set of tasks, and by p(t ), ranged over by p, the set of various boolean combinations of the above predicates over the set of tasks. utilizing this notation, an adaptive task automaton can be defined as follows. definition 1 [hps12] an adaptive task automaton over actions act, clocks x , invariants φ(x), guard constraints b(x), tasks t , and predicates over tasks p(t ) (definition 3) is a tuple 〈act,x,l,l0,e,i,m〉 where l is a finite set of locations, l0 ∈ l is the initial location, e ⊆ l×b(x)×p(t )×act×2x ×l is the set of edges, i : l 7→ φ(x) is a function assigning each location an invariant, and m : l ↪→ t is a function annotating locations with tasks. guard constraints b(x) are a set of conjunctions of atomic constraints of the type x ∼ c or x−y ∼c where x,y ∈ x are clocks, c is a natural number, and ∼∈{<,≤,=,≥,>}. invariants φ(x) are a set of conjunctions of atomic constraints of the type x ∼c where x ∈ x is a clock, c is a natural number, and ∼∈{<,≤}. in the case of (l,g, p,a,r,l′) ∈ e, we write l g,p,a,r−→ l′, where g ∈ b(x) is a guard constraint, a ∈ act is an action, and r is the subset of clocks that will be reset on taking the edge. we can represent the state of an adaptive task automaton as a triple 〈l,u,q〉, where l ∈ l is the current location, u 7→ r≥0 is a function mapping clocks to non-negative real values, and q = [t0(c0,d0),...,tn(cn,dn)] is the current ready task queue. sch(q) is a function that returns the ready queue sorted according to the scheduling policy, and runsch(q,δ ) is a function that returns the ready queue after it was executed for δ time units. 3 / 15 volume 70 (2014) adaptive task automata with earliest-deadline-first scheduling definition 2 [hps12] given an adaptive task automaton 〈act,x,l,l0,e,i,m〉 with an initial state 〈l0,u0,q0〉, and a scheduling strategy sch, its semantics is a transition system defined as: 〈l,u,q〉 a−→sch 〈l′,r(u),sch(m(l′) :: q)〉 if l g,p,a,r−→ l′ ∈ e, q |= p, and u |= g 〈l,u,q〉 δ−→sch 〈l,u⊕δ ,runsch(q,δ )〉 if (u⊕δ ) |= i(l) where r(u) is 0 for all xi ∈ r and u(xi) otherwise, t :: q is the result of releasing t into the queue q, and u⊕δ is the result of adding δ ∈r≥0 to all clock values in u. if both transitions are enabled, the choice is non-deterministic. intuitively, in the context of tasks, transitions are possibilities to release new tasks, while delays in locations correspond to the execution of tasks. definition 3 [hps12] given a task automaton state 〈l,u,q〉, with q = [t0(c0,d0),...,tn(cn,dn)], a scheduling policy sch, and two distinct tasks, ti and t j, let p be the set of predicates {inqueue(ti), sched (ti),sched (ti,t j)} satisfied as follows: 〈l,u,q〉 |= inqueue(ti) if ti ∈ q 〈l,u,q〉 |= sched (ti) if inqueue(ti)∧(ci + ∑ j∈hp(ti) c j)≤ di∨ ¬inqueue(ti)∧〈l,u,sch(ti :: q)〉 |= sched (ti) 〈l,u,q〉 |= sched (ti,t j) if inqueue(ti)∧〈l,u,sch(t j :: q)〉 |= sched (ti) where hp(ti) is the set of all tasks that have higher priority than ti, and sch(t j :: q) is the queue ordered by the scheduling policy sch after the release of the task t j. boolean combinations of the above predicates over a set of tasks t give us the set of all possible combinations of predicates denoted by p(t ). 3 encoding of ataedf in order to show the decidability of the ataedf framework, we have encoded the universal ataedf model as a network of timed automata with (clock) updates (tau). first we present the framework of timed automata with updates. the framework was introduced previously by bouyer et al. [bdfp04], yet we use a variant whose decidability has to be proven for our result to hold. then the encoding itself is laid out in three steps. the first step shows a way to encode task releases, the second provides the intuition behind the encoding of the predicates used for adaptivity, and the third introduces the encoding of the scheduler. after we have encoded the system as timed automata with updates, we provide a proof that the reachability problem for our class of timed automata with updates is decidable and that the encoding is bisimilar to the original model. the ataedf is more challenging than ata as the task priorities are decided online. 3.1 timed automata with updates the timed automata framework, as defined by alur and dill [ad94], has served as the basis for several modeling variations proposed in order to fit specific design purposes [fkpy07, bdfp04, lbb+01]. along the same line, our approach also relies on a variant of timed automata. proc. avocs 2014 4 / 15 eceasst to concisely encode the scheduler model as timed automata, we need to allow for “clock to clock” assignments. although such clock assignments are already present in the updatable timed automata framework [bdfp04], they are defined on models without invariants on locations. since our work depends on location invariants, let us define the extension of timed automata that supports clock to clock assignments as well as location invariants. definition 4 a timed automaton with updates (tau) over clocks x and actions act is a tuple 〈act,x,l,l0,e,i〉, where l is a finite set of locations, l0 is the initial location, e ⊆ l×b(x)× act ×2x ×2x 2 ×l is the set of edges, and i : l → φ(x) assigns invariants to locations. in the set of edges e, b(x) is the set of guard constraints, 2x represents the set of clock resets, and 2x 2 represents the set of clock assignments of the form x := y, where x,y ∈ x . the set of invariants φ(x) is a set of conjunctions of atomic expressions of the type x ∼ c where x ∈ x is a clock, c is a natural number, and ∼∈{<,≤}. the set of guard constraints b(x) can be defined as a set of boolean combinations of atomic expressions of the type x ∼c or x−y ∼c where x,y ∈ x are clocks, and ∼∈{<,≤,=,≥,>}. in the case of (l,g,a,r,s,l′)∈ e, we write l g,a,r,s−→ l′, where r is the subset of clocks that will be reset on taking the edge, and s the set of clock assignments. the semantics of tau is defined in terms of a timed transition system over states of the form (l,u), where l is a location, u 7→r≥0 is an assignment of clocks to non-negative real values, and the initial state is (l0,u0), where u0 assigns all clocks in x to 0. definition 5 given a timed automaton with updates 〈act,x,l,l0,e,i〉 with an initial state 〈l0,u0〉, its semantics is a transition system defined as: • 〈l,u〉 a−→〈l′,r(s(u)))〉 if l g,a,r,s−→ l′ ∈ e and u |= g • 〈l,u〉 δ−→〈l,u⊕δ〉 if (u⊕δ ) |= i(l) where s(u) performs the assignments xi := x j for every (xi,x j)∈ s, r(u) is 0 for all xi ∈ r and u(xi) otherwise, and u⊕δ is the result of adding δ ∈r≥0 to all clock values in u. if both transitions are enabled, the choice is non-deterministic. a timed trace σ of a tau, as is also the case with timed automata [ad94], is a sequence of delay and action transitions σ = (l0,u0) a1→ (l1,u1) a2→ ... an→ (ln,un) where ai can be either action ( a→) or delay ( δ→) transition, and a location l is said to be reachable if there exists a timed trace ending in the state (l,u). a network of tau, a1||...||an over x and act is defined as the parallel composition of n tau over x and act. semantically, a network of tau again describes a timed transition system obtained from those components, by requiring action transitions to synchronize on complementary actions (i.e., a? is complementary to a!) [by04]. 3.2 eearliest-deadline-first scheduling policy to encode the scheduler, we need to clearly define the edf policy in the context of this paper. since the strategy for choosing the next task between two or more tasks with equal deadlines does 5 / 15 volume 70 (2014) adaptive task automata with earliest-deadline-first scheduling not impact the optimality of the edf algorithm [gd99], we can give the following definition of edf with deterministic tie resolution. definition 6 according to the edf scheduling policy with deterministic tie resolution, the priority pi of task ti is greater than the priority pj of task t j if the time left until the absolute deadline di of task ti is smaller than the time left until the absolute deadline d j of task t j, or their absolute deadlines are equal and i > j holds. this can be expressed as pi > pj ⇐⇒ di < d j ∨(di = d j ∧i > j) where i and j represent strictly ordered task indices. 3.3 task releases in ata, tasks are released on changing to locations that are annotated with sets of tasks. a straightforward method to realize instant task triggering upon entering a location is to use synchronization channels on the edges of the corresponding tau representation. this is demonstrated in figure 2. l1 {t0} x = 0 x = 5 l1 x = 0 release0! x = 5 release0! idle busy release0? (a) (b) (c) figure 2: (a) task automaton, (b) (a)’s encoding, (c) part of (b)’s scheduler in figure 2(a), we have a basic task automaton location with two disjunctive edges leading to it. location l1 is annotated with the task set {t0}. by entering the location via any of the edges, the task t0 should be released and handled by the scheduler. modeling this behavior in tau requires annotating every edge entering the location l1 with a synchronization channel that creates a network of timed automata between the observed automaton presented in figure 2(b) and the corresponding edges in the scheduler automaton as seen in figure 2(c). in some cases, additional committed locations [bgk+02] might be needed to accomplish this. 3.4 schedulability predicates the ata model implements adaptivity via a set of scheduling predicates that may restrict edge guards: sched (ti), sched (ti,t j), and inqueue(ti). all predicates are evaluated within the context of the current ready queue. to express the predicates in timed automata with updates, we need to define an adequate encoding of the relevant variables that describe tasks in ata models. the task automata model and consequently the adaptive task automata model define the task ti in terms of remaining computation time ci and time left until the deadline di. we encode the remaining computation time as the difference between the response time ri and the computation time ci: ci = ri −ci. proc. avocs 2014 6 / 15 eceasst c d t1 2 3 t2 1 1 t3 2 2 t4 1 2 t1 t2 t4 t3 r2 r3 r1 r4 c2 c3 c1 c4 t2 t3 t4t1 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 figure 3: gantt chart and the encoding specific representation of tasks to illustrate this encoding, let us observe figure 3. the left side of the figure presents a gantt chart of task releases, while the right side presents a graph of the values of the variables c and r for the same set of tasks. note that, in the graph, the tasks t2 and t3, as well as t1 and t4 are presented on the same level to conserve vertical space. at time 0, task t1 is released. a higher priority task t2 preempts it at time 1. at the moment of preemption, the response time r1 is increased by c2, the computation time of t2, while the response time of task t2 is equal to its computation time. both tasks complete when their computation time becomes equal to their response time, respectively. two time units after task t1 completes, task t3 is released. it is already executing when task t4 is released. although task t4 has computation time of only 1 time unit, its response time already accounts for t3. due to the continuous nature of timed automata clocks, we cannot extract information on how much of the computation time of task t3 has been already used, so we have to use the full response time of task t3 increased by the response time of task t4. in order for this response time to be in context, we also need to copy the clock value of c3 to c4, hence the clock c4 starts from 1. the time until deadline is encoded by simply comparing an increasing clock to the relative deadline, but it is not shown here. 3.5 scheduler and queue next, we encode the edf scheduling policy together with the queue as a single automaton, which we will hereafter refer to as the scheduler automaton. our scheduler is created assuming the encoding of predicates outlined in the previous section and the edf policy presented earlier. these two constraints, addressed at the same time, have significantly increased the complexity of the encoding. in figure 4, we show the entire scheduler model encoded as a timed automaton with updates, using synchronization channels to release tasks. to reduce the presentation complexity of the encoding and make it more accessible to human readers, we have used a number of shorthands. for example, the queue is encoded as the set q. since this set is referenced in every location, we need to replicate each location for every possible value of q. since the number of tasks in the system (n) is finite and known in advance, this means that there will be 2n replications of every location to reflect the set q. next, only those locations that imply values that satisfy the incoming guards are connected by the edges to the originating location. the same approach can be applied to all other integer variables and translate 7 / 15 volume 70 (2014) adaptive task automata with earliest-deadline-first scheduling idle busy error crun ≤ rrun∧ ∀tj∈q : dj ≤ dj ∧ cj ≤ cx first task release task trun done and q = ∅ high priority task release task trun done and q 6= ∅ low priority task releasedeadline miss maintain ci ≤ cx first task release sync releasei? update q := q∪{ti}; trun := ti; ri := ci; ci := 0; di := 0; pi := n task trun done and q = /0 guard crun = rrun ∧drun ≤ drun ∧q ={trun} update q := q\{trun} task trun done and q 6= /0 guard crun = rrun ∧drun ≤ drun ∧ti ∈ q∧ ti 6= trun ∧pi = prun −1 update q := q\{trun}; trun := ti; ∀t j ∈ q : pj := pj + 1 maintain ci ≤cx guard ci = cx ∧ti ∈ q update ci := 0; ri := ri −cx deadline miss guard ti ∈ q∧ci < ri ∧di ≥ di low priority task release guard t edfnext (ti) = t j ∧crun < rrun sync releasei? update q := q∪{ti}; ∀k ∈ q|pk < pj : pk := pk −1; pi := pj −1; ri := r j; ci := c j; di := 0; ∀tk ∈ q|pk < pj : rk := rk +ci high priority task release guard t edfnext (ti) = /0∧crun < rrun sync releasei? update q := q∪{ti}; ci := 0; di := 0; ri := 0; ∀t j ∈ q\{ti} : pj := pj −1; pi := n; ∀t j ∈ q : r j := r j +ci; trun := ti figure 4: overview of the encoding e(sch). this representation into a pure tau. the exception to this approach is the function t edfnext () that will be addressed later. the scheduler consists of three locations: idle, busy, and error. the edges are classes of edges that are instantiated by iterating the variable ti over the set of tasks. task identifiers such as ti and i are used interchangeably to reduce the maximum subscript level. since a task can be in the queue or not, the queue is encoded as a set q. tasks themselves are represented via a number of variables: ti represents the i-th task, trun keeps track of the currently running task, ci represents task computation clock explained in subsection 3.4, ri contains the current response time of the task, and ci is compared to ri to evaluate if the task has completed its execution; di is a clock that is reset when a task is released, and is compared to the natural di to check if the task’s deadline has passed, pi is the current priority of the task. the priority n, equal to the number of tasks in the system, is the highest priority and it corresponds to the currently proc. avocs 2014 8 / 15 eceasst executing task. the scheduler starts in the location idle. this location corresponds to an empty task queue and it will be reentered on any occasion when there are no tasks left in the queue. the edge going out of the location idle is first task release. this edge is taken whenever the encoding of the adaptive task automaton synchronizes on releasei channel without any additional constraints. consequently, the task ti is added to the queue, the currently running task is set to ti, the response time is set to the computation time, the deadline clock is reset, and the task is assigned the highest priority. in busy location, there are four edges looping in the state, one returning to idle and one leading to error location. the invariant on busy location, shown in dashed rectangle in figure 4, ensures that, in the busy location, the currently running task will not execute longer than its computation time, and that all of the tasks in the system have not missed their deadlines. in case that a deadline is missed, the edge deadline miss is taken. the deadline is considered missed when the task is in the queue, still has some execution left, and has reached or exceeded its deadline. in such case, the system enters the error location and deadlocks. to explain the looping edges on the busy location, let us first define the selector t edfnext (). definition 7 the selector t edfnext (ti) = t j selects the task t j that has the next higher priority in the queue relative to the task ti, regardless of whether the task ti is in the queue or not according to the deterministic edf policy (definition 6). the selector returns the empty set if it is invoked for the highest priority task in the queue or any not-yet-released task that would become the highest priority task if it were released. due to the nature of the edf algorithm, a pure tau implementation of this selector requires replication of any edge annotated with this selector into several edges. for the current permutation of tasks in the queue (implied by the current pure tau location, and expressed via pi and q variables in the representation), edges are created to test whether the new task will fit into any of the given possible positions in the queue. during verification, due to the determinism outlined in definition 7, only one of those edges will be enabled at any time. the edge high priority task release employs this selector to check if the newly released task has higher priority than any of the tasks in the queue. the edge guard also checks whether the currently running task is still running. this check ensures that whenever a task completes it is removed from the queue before any further actions are taken. since the newly released task has a higher priority than any other task in the queue, its response time is equal to its computation time. all of the other tasks’ response times need to be increased by the computation time of the newly released task. priorities of other tasks are reduced and the newly released task acquires the highest priority. on the other hand, when the newly released task has lower priority than the currently running task, it needs to be placed at the correct place in the queue via low priority task release edge. this is where the determinism of our edf implementation via t edfnext selector comes into play. we need to ensure that the tasks added to the queue via this edge will be executed in the same sequence as they are added to the queue. otherwise, the computed response times would be invalidated. as with the previous edge, we add the task to the queue, but this time we need to copy the response time and computation clock from the higher priority task. then, we increase the response time of 9 / 15 volume 70 (2014) adaptive task automata with earliest-deadline-first scheduling the new task, as well as any of lower priority, with the computation time of the released task. as the time passes in busy state, tasks are executing and will be removed from the queue when they complete, by one of the task trun done edges. the edge task trun done and q 6= /0 is taken if the task has completed its execution before the deadline and if the next task is present in the queue. to switch the currently running task, the latter is taken out of the queue, a new task is set to currently running task and all of the active tasks’ priorities are increased by one to keep priority values bound between 1 and n. if the task is the last task in the queue, the edge task trun done and q = /0 is enabled and removes the task from the queue while moving the automaton into the idle location. to keep all clocks and response times bound the edge maintain ci ≤ cx, resets the clock ci to 0 every time an active clock reaches the maximum clock value cx and the corresponding response time is decreased by cx. while this edge alters the value of clocks, it does not influence the relevant difference ri −ci. this mechanism resolves the potential unboundedness of the system caused by the inheritance of ci and ri values in low priority task release. without it, any system that repeatedly releases tasks of lower priority than the currently running task can become unbounded. 4 decidability the decidability of schedulability verification for our model depends on two things: decidability of reachability for our variant of timed automata with updates (subsection 4.1) and that the encoding of ataedf model into timed automata with updates represents the original model correctly (subsection 4.2). 4.1 decidability of timed automata with updates alur and dill [ad94] observe that we can partition the state space of a timed automaton into a finite number of discrete regions that can be exhaustively explored in a finite amount of time. hence, the location reachability problem is decidable. our refined region equivalence relation is based on the relation given in [ad94] and extended by the region equivalence relation for timed automata with diagonal constraints presented by bengtsson and yi [by04], and fersman et al. [fkpy07]. definition 8 (refined region equivalence ≈ [fkpy07, ad94, by04]) for a clock x ∈ x , let cx be a natural number. for a positive real number t, let {t} denote the fractional part of t, and btc its integer part. let u,v ∈ v be two regions, g a finite set of diagonal constraints in the form x−y ./ z≥0 where z≥0 is the set of non-negative integers, and ./∈{<,≤,=,≥,>}. we define u ≈ v, i.e. u and v are refined-region-equivalent iff 1. for each clock x, either bu(x)c=bv(x)c or u(x) > cx and v(x) > cx, 2. for each clock x, if u(x)≤cx, then {u(x)}= 0 iff {v(x)}= 0, 3. for all clocks x,y, if u(x)≤cx and u(y)≤cx then {u(x)}≤{u(y)} iff {v(x)}≤{v(y)}, and 4. u |= g iff v |= g for all g ∈ g . proc. avocs 2014 10 / 15 eceasst given definition 8 of refined region equivalence, we can postulate that operations over regions will not disrupt the refined region equivalence relationship on tau. lemma 1 given a timed automaton with updates, let g denote the set of diagonal constraints in the automaton and cx be the maximum of mx (the ceiling of x) and all constants appearing in the guards and invariants of the automaton involving clock x. let u,v ∈ v and t,t′ ∈ rr≥0. then u ≈ v implies 1. u + t ≈ v + t′ for some real number t′ such that btc=bt′c, 2. u[x 7→ 0]≈ v[x 7→ 0] for a clock x, and 3. u[x 7→ y]≈ v[x 7→ y] for all pairs of clocks x and y. proof outline. lemma 1 can be trivially proven for the case when only one clock is assigned a new value. the case with multiple clocks being assigned new values can be proven by observing that we can reduce the problem to relative ordering of fractional parts of clocks which are consistent for all clocks between regions based on the third criterion of definition 8. the full proof is given in [hdsp14]. lemma 2 (bisimulation of tau) let us assume a timed automaton with updates, a location l and clock assignments u and v. then u ≈ v implies that: 1. when (l,u)→ (l′,u′) then (l,v)→ (l′,v′) for some v′ such that u′ ≈ v′, and 2. when (l,v)→ (l′,v′) then (l,u)→ (l′,u′) for some u′ such that u′ ≈ v′. proof outline. the proof follows from lemma 1. assume a location l and clock assignments u, and v, such that u ≈ v. the refined region equivalence relation ≈ defines that the guards will evaluate in both u and v to the same truth values. therefore, the set of enabled transitions is equal in both valuations. lemma 3 (location reachability) the location reachability problem for timed automata with updates and invariants is decidable if the bound mx for each clock x is known. proof. lemma 1 shows that for each location l of the automaton, there is a finite number of equivalence classes derived from the bisimulation relation ≈. since the number of locations is finite, the entire state space of an automaton can be partitioned into a finite number of equivalence classes and these equivalence classes can be effectively generated and searched. 4.2 model bisimulation once we have encoded the entire ataedf system as a network of tau, we need to show that there exists a bisimulation between the original model and the encoding. our main result is described by lemma 4 below, for which we outline the proof. in definition 9, we first introduce the concept of schedulability as reachability. definition 9 (schedulability) the adaptive task automaton a with initial state (l0,u0,q0) and scheduling strategy sch is not schedulable iff there exists a trace (l0,u0,q0)(−→sch)∗(l′,u′,q′) 11 / 15 volume 70 (2014) adaptive task automata with earliest-deadline-first scheduling such that in the state (l′,u′,q′) there is a task ti with more than zero computation time left, ci > 0, and no more time to execute, that is di ≤ 0. the state (l′,u′,q′) is marked as (l′,u′,error). lemma 4 let a be an adaptive task automaton and sch the edf scheduling strategy presented in definition 6 . assume that (l0,u0,q0) and (〈l0,idle〉,u0 ∪v0) are the initial states of a, and the product automaton e(a)||e(sch), respectively, where l0 is the initial location of a, u0 and v0 are clock assignments assigning all clocks with 0, and q0 is the empty task queue. then: for all l and u: (l0,u0,q0)→∗ (l,u,error) implies (〈l0,idle〉,u0 ∪v0)→∗ (〈l,error〉,u∪v) for some v. for all l, u, and v: (〈l0,idle〉,u0 ∪v0)→∗ (〈l,error〉,u∪v) implies (l0,u0,q0)→∗ (l,u,error). proof outline. the encoding of the ataedf automaton differs from the automaton itself in two key aspects: invocations of tasks and adaptivity predicates. since the task releases in ataedf can be said to be of a non-blocking nature, we essentially verify that the scheduler will be non-blocking as well. indeed, the only situation when there are no enabled edges annotated with a synchronization channel is when the scheduler automaton enters the error state. our encoding exposes the values required for the evaluation of the encoded schedulability predicates directly. in order to check that the ataedf adaptivity predicates are going to evaluate to the same results, we establish a correlation between tasks’ parameters in ataedf and the encoding. once these mappings have been properly established, we check edge-by-edge that they are maintained. the full proof is given in [hdsp14]. since we have proven that the reachability problem is decidable for tau, stated by lemma 3, also that every ataedf can be translated into a bisimilar tau, we can conclude that the problem of checking schedulability of ataedf is decidable as well. 5 related work our work tries to unify schedulability analysis with modeling and analysis of adaptive embedded systems. at the same time, a number of works address problems in those two separate fields, as well as non-modeling methods for analysis of schedulability in adaptive contexts. while this is by no means an exhaustive list of the works in these areas, we will try to list those that are closest to ours. in the following works, verification of adaptive embedded systems is done on a more coarse scale than in our approach. most of these approaches could be used in synergy with ours to provide system level verification, while ours provides task level granularity. adler et al. [assv07] use kripke structures as the underlying presentation of the system and specify the system’s properties using ltl. schneider et al. [sst06] have proposed a method to describe and analyze adaptation behavior in embedded systems in which the data flow is augmented with quality descriptions used by configuration rules to determine potential adaptations. goldsby et al. [gcz08] provide the amoeba-rt model focused on run-time verification and monitoring. in the area of adaptive scheduling, most work [jpg04, lrk03] was done to achieve a lower proc. avocs 2014 12 / 15 eceasst energy consumption by exploiting dynamic voltage scaling features of modern cpus. while such approaches can be used to analyze schedulability in some adaptive contexts, our approach makes it possible to model and analyze more precisely task release patterns of non-periodic tasks. finally, other works have approached verification of schedulability by means of timed automata for uniprocessors [dils09, mlr+10], and multiprocessors [ylx10] without explicit inclusion of adaptive functionality. 6 conclusion in this work, we have shown that the verification of adaptive task automata with earliest-deadlinefirst scheduling policy is decidable. to support our claim, we have encoded our adaptive task automata model as timed automata with updates and presented that the model and its encoding are bisimilar, as well as given a proof that reachability in our variant of timed automata with updates is decidable. our main result is the proof of decidability of our ata extensions. using ata, it is possible to model the environment of an embedded system as well as behavior of functional and extrafunctional properties in response to internal or environmental changes. thus we verify the behavior of specified properties throughout the execution of the system. in this work, we have implemented the edf scheduling policy. however, by replacing the selector t edfnext (), we can implement any other policy that is deterministic and does not change relative task priorities after their release into the queue. a non-deterministic selector would invalidate the schedulability testing predicates (sched ()) since the response times predicted when testing a task would not necessarily correspond to the actual response times after the task is released. during the encoding, we have faced a number of challenges. to support dynamic scheduling policies and schedulability predicates, we have required dynamic construction of task response times, which, in turn, have required a clock copying mechanism that had to be added as an extension of timed automata. as future work, we plan to further explore removal of the assumptions, specifically extend the framework to support modeling of multi-core systems, smart handling of tasks with variable execution time, shared resources, as well as create a set of templates that correctly model the most commonly utilized task release patterns. acknowledgements: this research has been supported by the swedish research council, which is gratefully acknowledged. bibliography [ad94] r. alur, d. l. dill. a theory of timed automata. theoretical computer science 126:183–235, april 1994. doi:10.1016/0304-3975(94)90010-8 13 / 15 volume 70 (2014) http://dx.doi.org/10.1016/0304-3975(94)90010-8 adaptive task automata with earliest-deadline-first scheduling [alu99] r. alur. timed automata. in halbwachs and peled (eds.), computer aided verification. lecture notes in computer science 1633, pp. 8–22. springer berlin heidelberg, 1999. doi:10.1007/3-540-48683-6_3 [assv07] r. adler, i. schaefer, t. schuele, e. vecchié. from model-based design to formal verification of adaptive embedded systems. in butler et al. (eds.), formal methods and software engineering. lecture notes in computer science 4789, pp. 76–95. springer berlin heidelberg, 2007. doi:10.1007/978-3-540-76650-6_6 [bdfp04] p. bouyer, c. dufourd, e. fleury, a. petit. updatable timed automata. theoretical computer science 321(23):291 – 345, 2004. doi:10.1016/j.tcs.2004.04.003 [bgk+02] j. bengtsson, w. d. griffioen, k. j. kristoffersen, k. g. larsen, f. larsson, p. pettersson, w. yi. automated verification of an audio-control protocol using uppaal. the journal of logic and algebraic programming 52 – 53(0):163 – 181, 2002. doi:10.1016/s1567-8326(02)00036-x [by04] j. bengtsson, w. yi. timed automata: semantics, algorithms and tools. in desel et al. (eds.), lectures on concurrency and petri nets. lecture notes in computer science 3098, pp. 87–124. springer berlin heidelberg, 2004. doi:10.1007/978-3-540-27755-2_3 [dils09] a. david, j. illum, k. larsen, a. skou. model-based framework for schedulability analysis using uppaal 4.1. pp. 93–119. crc press, 2011/12/27 2009. doi:10.1201/9781420067859-c4 [fkpy07] e. fersman, p. krcal, p. pettersson, w. yi. task automata: schedulability, decidability and undecidability. information and computation 205(8):1149 – 1172, 2007. doi:10.1016/j.ic.2007.01.009 [gcz08] h. j. goldsby, b. h. cheng, j. zhang. amoeba-rt: run-time verification of adaptive software. in giese (ed.), models in software engineering. lecture notes in computer science 5002, pp. 212–224. springer berlin heidelberg, 2008. doi:10.1007/978-3-540-69073-3_23 [gd99] j. goossens, r. devillers. feasibility intervals for the deadline driven scheduler with arbitrary deadlines. in real-time computing systems and applications, 1999. rtcsa ’99. sixth international conference on. pp. 54 –61. 1999. doi:10.1109/rtcsa.1999.811193 [hdsp14] l. hatvani, a. david, c. seceleanu, p. pettersson. adaptive task automata with earliest-deadline-first scheduling. technical report issn 1404-3041 isrn mdhmrtc-287/2014-1-se, mälardalen real-time research centre, mälardalen university, august 2014. http://www.es.mdh.se/publications/3661proc. avocs 2014 14 / 15 http://dx.doi.org/10.1007/3-540-48683-6_3 http://dx.doi.org/10.1007/978-3-540-76650-6_6 http://dx.doi.org/10.1016/j.tcs.2004.04.003 http://dx.doi.org/10.1016/s1567-8326(02)00036-x http://dx.doi.org/10.1007/978-3-540-27755-2_3 http://dx.doi.org/10.1201/9781420067859-c4 http://dx.doi.org/10.1016/j.ic.2007.01.009 http://dx.doi.org/10.1007/978-3-540-69073-3_23 http://dx.doi.org/10.1109/rtcsa.1999.811193 http://www.es.mdh.se/publications/3661eceasst [hps12] l. hatvani, p. pettersson, c. seceleanu. adaptive task automata: a framework for verifying adaptive embedded systems. in lara and zisman (eds.), fundamental approaches to software engineering. lecture notes in computer science 7212, pp. 115–129. springer berlin heidelberg, 2012. doi:10.1007/978-3-642-28872-2_9 [jpg04] r. jejurikar, c. pereira, r. gupta. leakage aware dynamic voltage scaling for real-time embedded systems. in proceedings of the 41st annual design automation conference. dac ’04, pp. 275–280. acm, new york, ny, usa, 2004. doi:10.1145/996566.996650 [lbb+01] k. larsen, g. behrmann, e. brinksma, a. fehnker, t. hune, p. pettersson, j. romijn. as cheap as possible: effcient cost-optimal reachability for priced timed automata. in berry et al. (eds.), computer aided verification. lecture notes in computer science 2102, pp. 493–505. springer berlin heidelberg, 2001. doi:10.1007/3-540-44585-4_47 [lrk03] y.-h. lee, k. reddy, c. krishna. scheduling techniques for reducing leakage power in hard real-time systems. in real-time systems, 2003. proceedings. 15th euromicro conference on. pp. 105–112. july 2003. doi:10.1109/emrts.2003.1212733 [mlr+10] m. mikučionis, k. larsen, j. rasmussen, b. nielsen, a. skou, s. palm, j. pedersen, p. hougaard. schedulability analysis using uppaal: herschel-planck case study. in margaria and steffen (eds.), leveraging applications of formal methods, verification, and validation. lecture notes in computer science 6416, pp. 175–190. springer berlin / heidelberg, 2010. doi:10.1007/978-3-642-16561-0_21 [sst06] k. schneider, t. schuele, m. trapp. verifying the adaptation behavior of embedded systems. in proceedings of the 2006 international workshop on self-adaptation and self-managing systems. seams ’06, pp. 16–22. acm, new york, ny, usa, 2006. doi:10.1145/1137677.1137681 [ylx10] f. yu, g. li, n. xiong. schedulability analysis of multi-processor real-time systems using uppaal. in information science and engineering (icise), 2010 2nd international conference on. pp. 1 –6. dec. 2010. doi:10.1109/icise.2010.5689944 15 / 15 volume 70 (2014) http://dx.doi.org/10.1007/978-3-642-28872-2_9 http://dx.doi.org/10.1145/996566.996650 http://dx.doi.org/10.1007/3-540-44585-4_47 http://dx.doi.org/10.1109/emrts.2003.1212733 http://dx.doi.org/10.1007/978-3-642-16561-0_21 http://dx.doi.org/10.1145/1137677.1137681 http://dx.doi.org/10.1109/icise.2010.5689944 introduction adaptive task automata introductory example overview of the existing framework encoding of ata_edf timed automata with updates eearliest-deadline-first scheduling policy task releases schedulability predicates scheduler and queue decidability decidability of timed automata with updates model bisimulation related work conclusion preface electronic communications of the easst volume 29 (2010) proceedings of the ninth international workshop on graph transformation and visual modeling techniques (gt-vmt 2010) preface jochen m. küster, emilio tuosto 2 pages guest editors: jochen küster, emilio tuosto managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst preface this volume contains the post-proceedings of the ninth gt-vmt international workshop on graph transformation and visual modeling techniques held in paphos (cyprus) on march 20-21 2010, as a satellite event to the european joint conference on theory and practice of software (etaps). the gt-vmt workshop series serves as a forum for all researchers and practitioners interested in the use of graph-based notations, techniques, and tools for the specification, modeling, validation, manipulation, and verification of complex systems. previous workshops were organized in geneva (2000), crete (2001), barcelona (2002 and 2004), vienna (2006), braga (2007), budapest (2008) and york (2009). the aim of the workshop is to promote engineering approaches that provide effective, sound tool support for visual modeling languages, enhancing formal reasoning at the semantic level (e.g., for model analysis, transformation, and consistency management) in different domains, such as uml, petri nets, graph transformation, or business process/workflow models. this year’s workshop had a special focus on visualization, simulation, and verification of concurrent and distributed systems; gt-vmt 2010 featured the invited speech of prof. fernando orejas from the department of software, technical university of catalonia, in barcelona who presented recent advancements on symbolic attributed graphs and attributed graph transformation. we received 30 submissions of which 13 were accepted after the usual reviewing process (each paper was reviewed by 3 reviewers) followed by the programme committee discussion. the papers balance theoretical and applied concepts, including tool support. the workshop program was organized into five technical sessions spanning over two days: saturday, march 20, 2010 sunday, march 21, 2010 foundations model transformations modeling and modeling environments foundations interactions we would like to thank the members of the programme committee and the two external reviewers (listed below) for their excellent work in selecting the papers for this workshop. we also thank all the participants who attended gt-vmt 2010 and contributed to its success by stimulating interesting scientific discussions. the organizers acknowledge the support of the organizing committee of etaps, the european association of software science and technology (easst), and the ist integrated project sensoria (software engineering for service-oriented overlay computers) funded by the european union in the 6th framework programme as part of the global computing initiative. may 2010 jochen küster and emilio tuosto pc chairs of gt-vmt 2010 1 / 2 volume 29 (2010) preface programme chairs jochen küster, ibm research zurich emilio tuosto, university of leicester programme committee paolo baldan (university of padova, italy) artur boronat (university of leicester, uk) andrea corradini (university of pisa, italy) claudia ermel (tu berlin, germany) gregor engels (university of paderborn, germany) reiko heckel (university of leicester, uk) thomas hildebrandt (it university of copenhagen, denmark) holger giese (hpi potsdam, germany) barbara könig (university of duisburg-essen, germany) jochen küster (ibm research zurich, switzerland) alberto lluch lafuente (imt institute for advanced studies lucca, italy) juan de lara (university of madrid, spain) mark minas (universität der bundeswehr münchen, germany) francesco parisi-presicce (university of rome, italy) arend rensink (university of twente, netherlands) gabriele taentzer (universiy of marburg, germany) emilio tuosto (university of leicester, uk) dániel varró (tu budapest, hungary) ehrard weinell (rwth aachen university, germany) albert zündorf (university of kassel, germany) external reviewers christian kissig (university of leicester) tobias heindel (university of duisburg-essen) proc. gt-vmt 2010 2 / 2 open source verification under a cloud electronic communications of the easst volume 33 (2010) proceedings of the fourth international workshop on foundations and techniques for open source software certification (opencert 2010) open source verification under a cloud peter t. breuer and simon pickin 20 pages guest editors: luis s. barbosa, antonio cerone, siraj a. shaikh managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst open source verification under a cloud peter t. breuer1 and simon pickin2 1 ptb@cs.bham.ac.uk dept. comp. sci., university of birmingham, birmingham, uk 2 spickin@it.uc3m.es dpto. ing. telemática, universidad carlos iii de madrid, leganés (madrid), spain abstract: an experiment in providing volunteer cloud computing support for automated audits of open source code is described here, along with the supporting theory. certification and the distributed and piecewise nature of the underlying verification computation are among the areas formalised in the theory part. the eventual aim of this research is to provide a means for open source developers who seek formally backed certification for their project to run fully automated analyses on their own source code. in order to ensure that the results are not tampered with, the computation is anonymized and shared with an ad-hoc network of volunteer cpus for incremental completion. each individual computation is repeated many times at different sites, and sufficient accounting data is generated to allow each computation to be refuted. keywords: formal methods, software verification, static analysis, open source, cloud computing, distributed computation 1 introduction we have developed a fledgling volunteer cloud computing system for the formal verification and static analysis of large open source software code bases, and performed experiments on some millions of lines of c code with it. what has motivated this development is the vision of a future in which a formal verification problem can be sent out to a cloud of volunteer solvers somewhere on the internet for completion. hopefully, those supporters of an open source project who do not have the skills to provide help at first-hand will instead contribute by lending their cpu cycles to the task of certifying their favourite new release free from certain semantic errors – or detecting them if they exist. they might also contribute extra regression tests or novel verification procedures. in this kind of framework, the bottleneck presented by the certification authority in a traditional approach is removed. moreover, the abundance of available cpu cycles allows the calculation to be duplicated many times over for reliability, while enough intermediate results are stored for accounting processes to check the computation as may be required. our prototype software provides a skeleton for a possible ‘open certification’ method, in other words. while neither the design nor the implementation is perfect and complete, it is to be hoped that the initiative stimulates better efforts and further progress in this direction. 1 / 20 volume 33 (2010) mailto:ptb@cs.bham.ac.uk mailto:spickin@it.uc3m.es open source verification an ‘open verification cloud’ as prototyped here physically consists of a database back-end and its servers plus volunteer clients running the bespoke verification solver software. the clients have volunteered to help perform the computations that resolve the verification problems stored on the cloud’s database. the cloud-computation nature of the process is manifested in the fact that no client knows about the other clients currently helping the computation and none knows where the servers are physically located. the code treated in the work reported here is ansi c [ansi89, iso99] with embedded assembler, and no significant restrictions. there is no inherent limitation to a particular language, however. it is of course universally realized that (unrestricted) c is an inherently intractable candidate for verification because of its indirections via pointers and other infelicitous language features, and those obstacles are overcome in this approach by using deliberately approximate (but sound) verification logic [bg04, bp06a, bp06b]. 1.1 context and related work the verification technology used in the work reported here falls in the class of ‘lightweight’ verification technologies. it is based at the top level on a symbolic programming logic [bp06b] and at the very bottom level on decision procedures using mixed integer linear programming implemented using the gnu linear programming kit (glpk). the glpk is intended for solving large-scale linear programming, mixed integer programming, and other related problems. it is a set of routines itself written in ansi c and organised as a library. it is available as part of the gnu project and is released under the gnu general public license [bob01, gou99]. that is particularly appropriate here because the principal target for our technology has historically been the open source c code of the linux operating system kernel (see for example [bg04]). other lightweight verification technologies in the same class include splint [el02] (derived from larch [gh91]), also esc/java and spec# [brls04]. all these tools make some sacrifices in the area of completeness or precision in order to be useful on the undecorated original source codes, and some require expert annotations to be added to the source. and while the c language is always a particularly difficult target for such technologies, some notable attempts at it have been made. david wagner and collaborators in particular have been active in the area (see for example [jw04], where linux user space and kernel space memory pointers are given different types, so that their use can be distinguished, and [wfba00], where c strings are abstracted to a minimal and maximal length pair and operations on them abstracted to produce linear constraints on these numbers). that research group often uses model-checking [ces86]. their approach in [wfba00, jw04] makes use of both model-checking and abstract interpretation [cc77] (abstraction is used in general in order to ‘airbrush out’ the more unsavoury aspects of c from the formal view of it), and therefore contrasts with contributions like jeffrey foster’s work with cqual [fta02], which seek to extend the type system of c in a more controllable direction. in particular, cqual has been used to detect “spinlock-under-spinlock”, a sub-case of one of the analyses routinely performed by the tools used in the experiment reported here. the slam project [br02] originating at microsoft also analyses c programs using a mixture of model-checking, abstract interpretation and deduction. that technology is intrinsically an proc. opencert 2010 2 / 20 eceasst order or more of magnitude slower than the basic technology used in the experiment described here, but it also works by creating an abstraction of the program code, and it also generates intermediate state descriptions mechanically. the coverity checker [ecch00] has also come to be used in the context of the linux kernel source code. coverity is a commercial tool based on an user-extensible version (a meta-compiler) of the gnu c compiler, gcc [gri02]. coverity itself is proprietary, and its innards are not accessible to review, but it may be guessed that the staff of the company can configure into the compiler framework any finite state machine-based computation for the purposes of a custom analysis that they have in mind. it is a less abstract technological solution than the one used here, but shares with it the characteristic of customizability. efforts to distribute verification computations to a large number of solvers organised in a well-defined topology are made regularly – see [abu09], for example – and it is a recognised conference topic. researchers have particularly sought to distribute model-checking problems onto grid-based machinery. holzmann defines the notion of ‘swarm verification’ to describe the technique [hjg08a], adapting the spin [hol03] model-checking tool to the paradigm. in passing, it may be noted that the verification technology used here seems to be part of a recent trend observed by holzmann in [hjg08b] towards verification of an abstraction of the actual code rather than of a design model. however, the work reported here aims to accommodate the lower performance targets obtainable from zero-cost volunteer cpu cycles available out on the internet. existing infra-structure projects support so-called ‘volunteer computing’ -type projects. see for example the boinc software [and04, akw05] from berkeley. it is not clear at the time of writing if that software would have been a significant aid to our exploratory project, because boinc clients expect a single data file and return a single result file to the database server, rather than engaging in a substantially continuous interchange, as is the case here. nevertheless, it may in the future be very helpful in the organisation of the architecture in a full-scale project, particularly in terms of the organisation of the permissions for access and the classification of the provenance and reliability of the data returned. peter lee [nl96] has approached the problem of automatically checking the trustworthiness of machine code to be executed by an operating system. the idea in proof carrying approaches is that incoming code snippets carry a proof that a desired security property is satisfied, and the operating system automatically checks the syntactic relationship of the machine code to the proof. our approach is to check the source code instead and is designed to handle large code bases such as the linux kernel in reasonable time. 1.2 contents this article is organised as follows. section 2 formally describes the process of certification from the top down. after describing certification properties, the section describes in more detail the process of analysis that produces the certification here, showing in particular how the calculation is adapted to the exigencies of a part-time volunteer cloud-computing context. section 3 succinctly presents the programming logic used in order to provide a self-contained account of the technology here, and readers may wish to skip that section if they are not interested in formal logic. section 4 describes an experiment performed on about a million lines of c source code. 3 / 20 volume 33 (2010) open source verification that experiment was previously conducted using monolithic analysis tools [bp06a] and it has been repeated in the volunteer cloud computing trial [bp09]. 2 certification in this section a global view of the certification process is set out and related to the procedure implemented. 2.1 certification in the abstract this section describes formally what certification means as implemented in the prototype project. three characteristics stand out. firstly, certification is a process and it produces both a result and a certificate. secondly, the certificate has the property that it can be checked to have been generated by following the purported process applied to the purported source code, generating the purported result. thirdly, the result apports certain guarantees about the code. consider then the certification process in the abstract. an automated procedure m takes a software code base c and, in the presence of a list l of known defects, produces a certificate x that says that the list is complete. that is, the process takes code c and (sometimes – the alternative is that the certification process fails) produces a certificate x : c m = x moreover, if ld is the sub-list of l of defects of kind d, and we write dp to mean that there is a defect of kind d at point p in the code, then ld contains all the points p in the code at which a defect of kind d arises. that is: {p ∈ c | dp} ⊆ ld putting those two together, one gets a fundamental description of what certification means: x = c m ⇒ ∀p ∈ c − ld : ¬dp (1) i.e. code that has more defects than stated does not get a certificate. 2.2 what is a defect? in our implementation, a defect dp is defined by a condition expressed in symbolic logic as dp(x) that is deduced to be possibly reachable after p. that is, logical analysis deduces a post-condition . . . p { postp } for p and checking the formula using a model-based technique shows there is a non-empty intersection of the post-condition with dp(x). that is: dp ⇔ ∃x. dp(x)∧ postp (2) for some values of the logical variables x. an example follows in subsection 2.3 immediately below. proc. opencert 2010 4 / 20 eceasst 2.3 example an example of an interesting defect condition is dexp =   x > 1, p a lock call x < 0, p an unlock call false, otherwise (3) where x is a logical (i.e., non-program) variable which counts the number of stacked locks taken in the program. the variable x is incremented by lock calls and decremented by unlock calls. the pre-/post-condition logic describing x for the analysis is: {φ [x + 1/x]} lock( ) {φ} {φ [x − 1/x]} unlock( ) {φ} (4) where this particular defect condition checks out as feasible in the sense of (2), it indicates either that (a) a lock might have been taken twice by that point without a release between the two takes; or (b) a lock may have been released twice by that point without a lock attempt between. these defects dexp can by definition (3) only be detected at the sites of a lock or unlock call p. certification in this case means that the code c has been scanned and defects dexp have been ruled out. that is, no lock can be taken twice in a row, nor unlocked twice in a row, without an unlock, respectively a lock, operation occurring between the two. 2.4 false positives note that there may be codes c which are flagged as having a defect in the sense of (2) but which are nevertheless semantically correct (‘false positives’), in the sense of never in practice triggering the condition dp(x). that is the rationale for in practice maintaining a list ld of detected defect sites – they have individually to be signed off by the developer as ‘false positive’ or ‘noted for correction in the next release’, or ‘noted but no solution yet’. the certificate certifies that it is unequivocally the case that the defined defect cannot arise anywhere other than the sites listed. false positives generally fall into two classes. in the first class, a guard condition such as y2 < 0 cannot in practice be breached, but the analysing logic does not know that, and explores a factually impossible code trace as though it were possible. that kind of semantic ‘inexactness’ is a result of the deliberately approximating nature of the symbolic logic used in any real life analysis. the analysing logic has to be less exact (‘more alarmist’) than reality or the computation would never finish in practice. a typical instance of the second class of false positive arises naturally in the context of the example above in subsection 2.3. it occurs when two different locks are taken in sequence in the code, without an unlock between them. a defect will be detected. the fault here is purely a definitional one. the situation is factually harmless in itself, but it is captured by the defect definition. the problem may be said to be rooted either in the poverty of the analysis language – different counts for different locks may be difficult to define – or in the poverty of the analysis logic – one may not be able to reliably distinguish references to different locks in c. the latter is the case here. different pointers may point to the same underlying lock, and the same pointer may point to different locks at different times. 5 / 20 volume 33 (2010) open source verification 2.5 accountability it is important for a certification procedure that it can be checked that the certificate x produced relates the certified code c and the method m used to certify it. that is, there is a checking procedure k such that k(x ,c, m) = { true, if x = c m false, otherwise (5) how is that guaranteed? the answer is, in our procedure, via digital signatures, namely, the following: (a) σ (t ‡) is generated from a printout of intermediate results t ‡ of the analysis in m; (b) σ (a ) is generated from the short ascii file that configures the analysis; (c) σ (h ) is generated from the ascii file that expresses the defect condition(s) being scanned for; (d) σ (l) is generated for the list of allowed defect exceptions l; (e) σ (c) is generated for the code c; (f) σ (p) is generated from the file that configures the code parse p. those digital signatures comprise x , as will be detailed in the following paragraphs. then, provided the code developer holds on to a copy of the intermediate results, a copy of the analysis method configuration, and a copy of the original code, then any part of the computation via m can be repeated at will for the benefit of anyone that doubts it. that is the procedure k, modulo checking the digital signatures to confirm the veracity of the three components. that is to say k(x ,c, m) ⇔ cm = x as required in (5). that means that k(x ,c, m) ⇔ ∀p ∈ c : ¬dp ∨ p ∈ ld according to (1). the important idea here is that a part of the calculation can be repeated as needed in order to check the result, and that in order to be sure that the repeated calculation starts from the right place (and finishes in the right place) the digital signatures in the certificate are necessary – as is the data signed, but that has to be stored separately. it is not present in the certificate. where the data is kept is a separate question. to explain how the calculation can be reconstructed when required, the calculation needs first to be described in more detail. the certification method m consists first of a parse p to give a syntax tree t : t = c p (6) next an analysis a is applied to the tree t to decorate it with symbolic logic expressions, giving the decorated tree t †: t † = t a (7) then a checker h is applied which further decorates the tree with evaluations of the logic to see if defects are feasible: t ‡ = t † h (8) proc. opencert 2010 6 / 20 eceasst the list of sites p within the code c at which defects dp are detected is what is basically of interest to developers and consumers alike, and it is supposed to be covered by the list l of knowns. ld ⊇ {p ∈ c : d decoration of t ‡ at p is not false} (9) the certificate x consists exactly of the digital signatures of the code, (printed out) tree decorations, and the configuration used for the parser, for the analysis and for the checker, and the list of known defects: x = (σ (c), σ (p), σ (t ‡), σ (a ), σ (h ), σ (l)) (10) every step of this procedure can be repeated unambiguously. for example, to get to t ‡, one needs to repeat at least the step (8). that starts from t †. but t † is just t ‡ with some of the decoration dropped. so it can be unambiguously obtained from t ‡, which is signed. the configuration for h is signed and available, and so h can be applied unambiguously to check the derivation of t ‡ from t †. 2.6 analysis and evaluation the analysis procedure a is organised in detail according to the structure of the code. it generates a pre-/post-condition pair for each program fragment p: {prep} p {postp} the pair is computed from the results for the component fragments pi ∈ p : p = p i (pi) where p is the constructor (if, while, etc.) that produces p from the pi. that is (prep, postp) = [p] i (prepi , postpi ) (11) where {prepi} pi {postpi} for pi ∈ p and [p] is the appropriate generator of symbolic logic. it is specified for the source language (here c) being treated in the configuration file for the analysis. ‘appropriately’ here means that the logic is sound with respect to the semantics of the language, in that for each pre-/post-condition pair generated by the above formula (11): prep ⇒ wp[p](postp) (12) where wp is the semantic weakest precondition constructor for the language. that (12) is an implication and not necessarily an equivalence means that the symbolic logic generated by the scheme (11) is approximate (but sound, according to (12)). that gives rise to the name symbolic approximation [bp06b] for the general technique. in practice, a slightly different customized approximate symbolic logic is used for each defect analysis. note that some complexity reduction is performed by our tools via lightweight automatic theorem-proving techniques at the stage of producing the tree t † with the symbolic logic annotations. for example, a formula of the form p ∧ q 7 / 20 volume 33 (2010) open source verification will be reduced to q if p → q is proved on the fly as the formula is generated. similarly for p∨q. that has proven very effective in reducing complexity. what our tools are not good at is reducing formulae of the general shape ∨ i ∧ j qi j to a simpler expression p when there is one, such as in the case of p∧q∨ p∧¬q. the inadvertent and unrecognised splintering of simple logical expressions into multiple complex cases in this style is the most significant source of the computational explosions that are occasionally encountered during processing. in principle the situation could be detected and repaired at the checking stage of the process when t ‡ is generated (all the atomic propositional forms here are linear inequalities and one could detect when dropping one failed to relax the problem), but that is not done, because the extra computation is usually prohibitively expensive and apparently only rarely productive in practice. in the final phase that produces t ‡, the volunteer clients in the cloud apply a modelling technique to decide whether postp ∧ dp(x) is satisfiable at any node p of the abstract syntax tree. since all questions of satisfiability for the predicates in our logic can be reduced to questions of the feasibility of systems of linear inequalities in integer variables, the evaluation is performed using mixed linear integer programming. the implementation uses only open source libraries, principally gnu’s linear programming kit (glpk). a non-negative answer to the question asked by the evaluation procedure indicates a possible defect dp. 2.7 the cloud computation the analysis a and evaluation calculations h are incremental, stateless, and can be broken off and restarted from the break-off point, as well as repeated either partially or wholly. that is the basis for performing the computation via a cloud and the following paragraphs describe the properties that permit that implementation in formal terms. let the constructs p (the nodes and leaves of the abstract syntax tree t produced by the parse) that appear in the code c be p = p i (pi) for a syntactic constructor p and components pi. the constructions define a dependency pre-order: p = p i (pi) ⇔ pi < p (13) which extends uniquely to a minimal partial order via transitivity. in the partial order, one code construct ‘depends on’ (is greater than) another if the second is a component or subcomponent, etc., of the first. for example, if(x<0){ x++; y++; } depends on the component x++; y++ and on its component x++. the operations a and h can then be split up into fragments ap and hp at p ∈ c as follows: a = ◦ p ap (14) h = ◦ p hp (15) proc. opencert 2010 8 / 20 eceasst where the order of the compositions is constrained only by the dependencies pi < p. formally, operations on different parts of the tree can be performed in any order: ap1 ◦ ap2 = ap2 ◦ap1 (16) hp1 ◦hp2 = hp2 ◦hp1 (17) where p1 6≤ p2 and p2 6≤ p1 in the dependency relationship. also, since a and h work on different decorative features on the tree ap1 ◦hp2 = hp2 ◦ap1 (18) whenever p1 6= p2. when p1 = p2 then h requires the decoration produced by a first. in practice, the computation of the symbolic logic forms and their evaluation is performed at the same time, because the former is usually a computationally cheap task relative to the latter. that is, the computation a ◦h = ◦ p (ap ◦hp) (19) is performed. (16, 17, 18) justify the reordering of the components in (19). that the computation can be broken off and restarted means only that (19) can be further reordered via (16, 17, 18) as a ◦h = ◦ p∈p (ap ◦hp) = ◦ p∈p1 (ap ◦hp) ◦ p∈p2 (ap ◦hp) (20) where p1, p2 is a partition of the full set of code fragments p = p1 ] p2 such that p1 ∈ p1 ∧ p2 ∈ p2 ⇒ p2 6≤ p1 (21) i.e., p1 already contains all the pre-dependencies p2 < p1 for any p1 ∈ p1. p1 is the set of code fragments that have been completely analyzed at the time of the break, and p2 is the remainder at that time. moreover, the computation can be broken off and re-started any number of times. that is, the equation (20) may be extended to match with any partitioning p = p1 ]···] pn that respects the dependency order, as in (21). p1 is the set of code fragments completely analysed at the time of the first break, p1 ] p2 the set completely analysed at the time of the second break, and so on. the enabling conditions are (16, 17, 18). 3 logic readers uninterested in formal logic may wish to skip this section, which is included to provide a self-contained account here. it is not needed by what follows after. the program logic used to generate the assertions which decorate the syntax tree t † from (7) is called nrbg, for ‘normal, return, break, goto’, the principle kinds of program flow treated. in a program there is the normal program flow, which passes from the beginning of a statement through to its (normal) end, and there are exceptional flows, the break, return and goto flows 9 / 20 volume 33 (2010) open source verification (and also others in other languages), which exit a statement before it ends normally. the logic considers the interaction of these flows though each code construct. for example, the rule for sequential statements states that either a; b may terminate normally with condition r or it may terminate exceptionally with condition x. on the way to doing so, a may either terminate normally with condition q and b continue from q to the required termination conditions, or else a may terminate exceptionally with condition x right away. that is: {p} a {nq ∨e x} {q} b {nr ∨e x} {p} a; b {nr ∨e x} where n stands for ‘normal’ and e stands for any of the r (‘return’), b (‘break’), gl (‘goto’) exceptional flows, where l is not a label defined in a or b. the logic has been presented and explained many times over the years. see for example [bp06a]. the presentation given here is innovative in that it introduces the n, r, b, gl as modal operators. the earlier presentations used a set of interacting logics n, r, b, g. the advantage of the new presentation is that the number of logical rules falls to about seven from about twenty. the rule for a do-forever loop says that breaking from the body of the loop with condition q is the same as terminating the loop normally with q. that is: {p} a {bq ∨ n p ∨e x} {p} while(true) a {nq ∨e x} where e stands for any of r, gl , where l is not a label defined in a. the rule also captures the idea that exiting exceptionally in another way than through break (that is, with either return or goto) from the body of the loop with condition x means exiting the whole loop with condition x too. the normal termination condition p for the body of the loop that appears in the rule is a fixpoint, and finding a useful fixpoint (lower than ‘true’) in practice is a non-trivial feat of leger-de-main. exceptional modal conditions r p, b p, gl p are generated uniquely by the corresponding statements, return, break and goto respectively: {p} return {rp} {p} break {bp} {p} goto l {gl p} the rule for conditionals is, unsurprisingly: {p ∧ c} a {nq ∨e x} {p ∧¬c} b {nq ∨e x} {p} if(c) a else b {nq ∨e x} where e stands for any of r, b, gl , where l is not a label defined in a or b. a suitable assignment rule is always: {q[e/x]} x = e {nq} but in practice some weaker rule is usually implemented, with special cases that depend on the form of the expression e. from the point of view of the correctness of the logic, it does not matter what weaker rule is implemented because it will be sound. the practical effect of a weaker implementation is eventually to generate more ‘false positive’ alerts for defects than proc. opencert 2010 10 / 20 eceasst would otherwise have been the case. for example, non-linear update expressions are typically described in practice by very approximate logic such as: {x > 0 ∧|x||y| < 231} x = x ∗ y {sign(y) = sign(x)} (the preconditions avoid overflow). the rule for a labelled statement l : b says that an initial condition p is required that is the same as the exit condition p from all the goto l statements within b. i.e., p is a fixpoint: {p} b {nr ∨e x ∨ gl p} {p} l : b {nr ∨e x} compare the rule for while forever loops. a derived rule for labelled statements deals with the more general situation where a label occurs in the middle of a sequence of statements a; l : b, rather than at the beginning. there it is the case that the entry condition q for l : b must not only be the normal exit condition from a, but also the condition that arises from the ‘forwards pointing’ gotos within a, as well as the ‘backwards pointing’ gotos in b: {p} a {gl q ∨ nq ∨e x} {q} b {nr ∨e x ∨ gl q} {p} a; l : b {nr ∨e x} where e stands for any of r, b or gl′ where l ′ is not a label defined in a or b. there is a more convenient way to deal with the goto computations, however. it consists of loading the rules with prior ‘assumptions’ gl pl (written to the left of a . in gentzen style) about the exit condition pl that will be imposed by the goto l statements encountered within the program. the initial estimates are modified upwards by the conditions p found at the sites where the gotos are located in the program. the initial guess pl needs to be loosened to p ∨ pl , and so on round and round until a fixpoint is found. a goto fixpoint achieved in practice is not usually the least fixpoint, but it is generally a useful and nontrivial one. p ⇒ pl gl pl . {p} goto l {gl p} the fixpoint pl is available as an entry condition at the point in the code where the label l is sited: gl pl . {pl} a {nr ∨e x ∨ gl pl} . {pl} l : a {nr ∨e x} the model underlying the logic is of individual states s which assign values to the program variables, and links between them that are ‘coloured’ n, r, b or gl according to whether the transition is as a result of respectively a normal program termination, hitting a return statement, hitting a break statement, or hitting a goto. the following diagram is of a r-coloured (‘return coloured’) transition from state s1 to state s2: s1 © r © s2 11 / 20 volume 33 (2010) open source verification each state has only one exit in the present (deterministic) setting, but there may be many entries to any state. the semantics of the n, r, b, gl operators is that, for example, a modal statement like rp holds at the pair of a state s2 and an arc e entering the state. for example, rp holds at (e, s2) if p holds at s2 and e is coloured with r. in general: (e, s) |= e p ⇔ s |= p ∧ e is coloured by e for e any of n, r, b, gl . an atomic programming language statement a causes a change from a state s1 to a state s2 via a link e that is of a ‘colour’ that is normally n, but is exceptionally r, b or gl , depending as the statement executed in a is a return, break or goto respectively. suppose that for the (non-atomic) statement a, the sequence © s0 e1 © s1 e2 . . . en © sn is a sequence of states run through by the execution of a. then {p} a {q} means {p} a {q} ⇔ ∀s0, e1, s1, . . . , en, sn. p(s0) ⇒ (en, sn) |= q (22) by convention, not specifying a ‘colour’ means that colours are ignored, i.e.: p ⇔ n p ∨ rp ∨ bp ∨ gl p ∨. . . (23) for all possible labels l in the program. then (22) can more symmetrically be written as ∀e0, s0, e1, s1, . . . , en, sn. (e0, s0) |= p ⇒ (en, sn) |= q making (23) work requires a few axioms for the modal operators. firstly, repetition of modal ‘colouring’ operators has no effect: e p ⇔ e e p (24) for e any of n, r, b, gl . also, an arc cannot be two colours at the same time: e1 p ∧e2 q ⇒ false (25) for e1, e2 from n, r, b, gl and e1 6= e2. similarly e1 e2 p ⇒ false (26) for e1 6= e2. and colouring a (positive) formula is the same as colouring its parts: e (p ∨ q) ⇔ e p ∨e q (27) e (p ∧ q) ⇔ e p ∧e q (28) for e from n, r, b, gl . together, (23), (24), (25), (26), (27), (28) mean that all modal formulae have the form n pn ∨ rpr ∨ bpb ∨ gl pgl ∨. . . for non-modal formulae pn , pr, etc. proc. opencert 2010 12 / 20 eceasst 4 implementation and experiment we report briefly here on our experience [bp09] in converting what were originally a set of monolithic semantic analysis tools [bg04, bp06a] for c code to the service of the volunteer cloud computing approach, and the re-running on the cloud of an experiment that had previously been run locally. the exact goal of the experiment was to solve a particular large formal verification problem via an ad-hoc distributed network of automated solvers. the task consisted of an analysis of the linux kernel source code (written in c [ansi89, iso99] and assembler) to detect a particular kind of runtime deadlock in the operating system as compiled for multi-cpu 32-bit intel (ia32) platforms. those faults detected during the experiment are not intrinsically specific to the intel platform, however, because 80-90% of the code is shared with and common to the 15 other major architectural types supported by the linux kernel, and any faults found in a common section are relevant to the other platforms too. the deadlock is known as ‘sleep under spinlock’. it happens when a thread of computation sets a ‘spinlock’ (one which another thread will wait busily for, spinning in a tight loop until it is released), but then ‘sleeps’ (is ejected from the cpu). since the ejected thread is the only one that will eventually release the lock, if a thread enters the cpu meanwhile and spins waiting on the spinlock the situation is deadlocked. the cpu is occupied by a spinning thread that will do nothing except keep the only thread that will release the lock out of the cpu. the experiment detects about three such faults per million lines of code. it also simultaneously checks for other similar deadlock possibilities (notably ‘spinlock under spinlock under spinlock . . . ’), which are detected at close to the same frequency. the average lifetime from appearance to elimination in the source code of the faults detected appears to be about six months, checking against the version histories. 4.1 populating the database the first practical task for any submitter in presenting a problem to the cloud for solution consists of parsing the source code and storing the resulting syntax tree into the cloud’s remote database. but it is a considerable logistical problem, and it turned out to be too difficult to treat naively. in our experiment [bp09], a million or so lines of linux kernel source code was offered up for analysis, and that gave rise to over ten million syntax tree nodes. each insertion involved several relational database updates on the (postgresql [dou05]) back-end and the acknowledgement and locking requirements slowed the transactions down to as much as a second or more across the network (the average time was a tenth of a second or so). there are only 86400 seconds in a day, and no developer is going to wait on the order of weeks to upload their problem. the efficiency might have been improved tenfold with effort, but it would have still been too slow for multi-million line source code bases. this ‘population problem’ was eventually overcome by writing the parse data to a fast local non-relational data store (a gnu dbm 1.8.3 based store was used), then copying it to the remote database site in one lump, and converting it to relational database format in situ at the remote database. that got the job done in a day. it may be expected that incremental updates will comfortably handle new point releases of the source code base from there on. attempts to use local and remote database replication pool services to upload the data in trickle mode failed. 13 / 20 volume 33 (2010) open source verification table 1: top-level definitions with multiple instances (∑ xy = 746844) 1 10 100 1000 10000 100000 1 10 100 1000 # u n iq u e d e fs #instances each stream tended to stop completely while the database was otherwise in use, and the end result was slower overall. clearly in the future source code will have to be uploaded whole to an extra cloud service from where it can be transferred into the database from close by. 4.2 pruning the analysis a single analysis task downloaded for solution by a volunteer client in the cloud usually consists in practice of the analysis of a single top-level functional unit. however, it turned out in our experiment that many of the function definitions from common header files had effectively been duplicated up to thousands of times through being declared static and inline, a combination which, in c, signals local scope and context at every implantation site. see table 1 for a count of the number of implanted definitions. at right in the table are represented the dozens of function definitions implanted into more than a thousand different sites. the number of analysis tasks was reduced tenfold overall by choosing to analyse only one representative from each class of syntactically identical functional definitions. there is a potential problem in that the semantics of some of these apparent duplicates might have been modified unexpectedly by the differing contexts into which they were copied. it was supposed that that did not happen. the assumption was made that no two syntactically identical definitions captured identically named but different external references. this is a good assumption for well-written code, but it was not checked systematically. the numbers were certainly prohibitive there were three quarters of a million top level function definitions in the database. only seventy-two thousand of them corresponded to non-duplicates, and those were the ones eventually allowed to proceed to analysis. proc. opencert 2010 14 / 20 eceasst 4.3 improving performance fetching data from the database in the cloud to a client as needed turned out to be far too inefficient as a general strategy. the latency of each database transaction was sufficient that the computation as a whole proceeded about one thousand times as slowly as it would have done on locally stored data (that experiment had already been tried [bp06a]). the situation was improved firstly by avoiding downloading syntax trees (node by node) in favour of downloading the relevant source code text in one lump and re-parsing it locally on the volunteer client. the issue of generating the same database keys locally as remotely was handled by storing an elaborated version of the source decorated with extra annotations, among them the in-database key for each identifier reference (each reference appeared in the elaborated text as ‘x@123456’, where ‘x’ was the label in the original source, and ‘123456’ the primary database key indexing the reference to ‘x’ at that line and column in that source code file). the primary provides enough information to generate all other keys locally too. secondly, a persistent cache was added on the client side just atop the database interface. the cache scored hits around the 95% level, with the corresponding order-of-magnitude-and-more speed-up. thirdly, the few database interactions that turned out to take minutes each – queries involving complex searches and aggregates across millions of database entries, such as calculating new priorities for the remaining work tasks after each task completion by a volunteer client – were amortised by calculating up to five hundred results ahead of time and then doling them out as needed. that implied that work task priorities in particular were never quite what they should have been according to theory, but the effect was not significant in practice. finally, significant reductions in the complexity of the logical formulae generated during the processing were achieved by building in automatic theorem-proving techniques to the mechanisms that generated the formulae in the first place. there is a trade-off between expending time to reduce complexity and gaining time through the reduced complexity, but there were huge gains made by the simplest reduction techniques, based essentially on automatic deduction in the symbolic logic in order to remove extraneous terms from the formulae. if the automatic deduction failed to obtain an improvement, abstract interpretation and finally mixed integer linear programming were used first to see if a reduction in complexity could possibly be achieved and then to check definitively [bp09]. 4.4 allocation and management strategy allocating work to volunteer clients required an allocation strategy. naively sending out the next work task in alphabetical order would have eventually gotten all working clients stuck executing very hard tasks with no appreciable progress being made. the group of volunteer clients makes more progress overall if they complete the easy work tasks first. but which are the easy tasks? there is no definite way to tell other than by trying and seeing. the size of analysis task taken on by volunteer clients was initially set to ‘one complete functional unit’, i.e. a top-level function definition. each functional unit was initially assumed to be equally as hard to analyse as every other. each volunteer was initially given t0 = 10 minutes of cpu time (normalised to a 1ghz cpu) in which to complete the work task. if the limit was exceeded, the client abandoned the task, reported back the incompletion statistic to the cloud’s 15 / 20 volume 33 (2010) open source verification database, and moved on to a different work task. the task’s estimate of intrinsic difficulty was raised, as reflected by an increased timeout value t1 > t0 now associated with it. it was intended by this means to tamp down as much as possible on the total concurrent interactions with the cloud’s database. network bandwidth is a finite bound that cannot be exceeded, and the database has a limit on the number of transactions per second it can absorb. the cache at each client served to prevent 90% of that client’s database transactions from escaping onto the net but work task startup and shutdown are points where large amounts of novel information are exchanged with the cloud. giving volunteer clients by default a relatively large work unit to chew on reduces the number of data requests flying about the network and thus in principle helps the computation overall. the downside is that clients may be given more than they can deal with, plugging progress overall. unplugging by imposing a timeout was the simplest cure. the downside is that it implies the loss of the data accumulated by the client up to the point of abandonment. every time a work task was abandoned uncompleted, the estimated time required to complete it was increased by 50% (i.e., tn+1 = 1.5 tn), so that the next client to take it on would spend longer on it before abandoning. moreover, tasks with a higher timeout were handed out with lower frequency (i.e., with lower priority) so that clients would tend to take the easier tasks first. in the end, the ‘hard’ work tasks that took longer than the initial 10 minutes turned out to comprise only 0.5% (three hundred-odd) of the total. one might argue that the tasks handed out initially were not difficult enough since 99.5% failed to prevent their host from emitting significant noise on the network for less than ten minutes at a time. however, of the hard tasks, two thirds (about two hundred) eventually did complete in an hour or less, availing of lengthened timeouts. abandonment wastes the earlier effort put in, but the time taken overall is still dominated by the successful final stint, so at most three hours of computation time were spent for each hour-long completion here. those ‘very hard’ work tasks that still were taking longer than an hour without completion (a hundred or so, or 0.15% of the original total) were dealt with in accord with the theory developed in section 2. that is to say, the incremental progress in the client dealing with them was checkpointed to the cloud’s database every minute. that pushed up the number of remote database transactions, but in return for guaranteed progress. any volunteer client could take up the work where another had left off. that eventually successfully dealt with all but 0.03% of the original set of seventy-two thousand functional units submitted for analysis. twenty or so ‘ultra hard’ exemplars remained intractable. a few of these contained constructs particular to gnu c that could not be handled by the parser, ‘interior’ (local) function definitions within other function definitions being the most significant such. the rest were most notably characterised by the presence of generated symbolic logical assertions of great complexity, containing more than 40,000 terms each. clearly, making progress on those requires better techniques with which to reduce the complexity of the symbolic logic expressions encountered or else better techniques for reducing the granularity of the calculations still further. see table 2 for a graph of the time taken per task against the percentage of the overall time taken. this graph shows inflexion points at about the 3600s point (corresponding to the one hour mark at which tasks were shifted to checkpointing execution) and also at about the 4500s mark, if not also the 60s mark. the cause behind the latter two inflections is not known. proc. opencert 2010 16 / 20 eceasst table 2: percentage of total time taken per analysis task (cumulative) 0 20 40 60 80 100 1 10 100 1000 10000 100000 \% ti m e time taken per task in seconds the graph shows that the tasks taking up to ah hour of computation time comprised only abut 30% of the total time taken. two thirds of the computation time overall was spent on those only a hundred or so ‘very hard’ tasks that in number comprised only 0.15% of the total numbers. that is a very surprising observation. 4.5 statistical inferences it should take around 500 1ghz volunteer clients in the cloud to complete the work undertaken in the experiment in under six hours. a rough average time needed overall for processing per top-level functional unit in the source code was 116 seconds on a notional 1ghz cpu. the ‘very hard tasks’ (taking more than an hour), though they accounted for not much more than 0.15% of the numbers, required around 8% of the processing time. see table 3 for a straightforward graph of the timing spreads. regarding the cpu load expressed on a volunteer, one may conclude that it is only significant in the case of the hard work tasks, which comprise approximately 0.5% of the total number. for these cases, cpu load could in the future be limited by throttling the software automatically. it was not limited during the experiment undertaken, and cpu load was rarely more than a few percent for 99.5% of the tasks undertaken, rising towards maximum levels only on the hard tasks. the implication is that the clients were generally i/o bound, or cpu load would have routinely been much higher. the relatively infrequent queries to the cloud database that penetrated the local caches apparently stalled the client software significantly. the clients could be observed averaging between 150-500 accesses per second to the local cache layer on a 1ghz system (about 90% reads, 10% writes), leaving about 10 transactions per second per client to wend their way out to the rest of the cloud and back. 17 / 20 volume 33 (2010) open source verification table 3: time taken per analysis task (cumulative count) 0 20 40 60 80 100 1 10 100 1000 10000 100000 % ta sk s time in seconds the back-end database fanout is presently limited to about 10 clients per server in the cloud, though that figure could be improved with better client-side caches. a fanout of around 40 would appear to be feasible by doubling the number of cores per server and increasing server ram to 64gb (our experiment used a single core 1.8ghz athlon with 3gb ram), since a large proportion of real server load appears to come about through paging data to disk and back in order to accommodate database images that exceeded the available ram. so between 12-50 servers in the cloud are needed to support the 500 volunteer clients projected as necessary to analyse a million lines of source code in 6 hours. how does the cloud computation compare to the original monolithic computation from which it is descended? the short answer is ‘about 50 times as slow’, at present, making parity with respect to the original experiment occur about the 50-client mark now. but the original computation threw away all its intermediate calculations as it produced answers, meaning that accountability meant repeating the whole computation from scratch. it was not a scalable solution, while the cloud-computing approach is scalable. 5 summary the computation of a certificate guaranteeing the absence of formally defined defects in an open source code base has been formally described. it has been shown that the computation may be handled incrementally by a distributed ‘volunteer cloud’ of client cpus each taking a fragment of the work upon themselves at a time. an experiment in which the cloud was organised to analyse about a million lines of c code (requiring about nine million seconds of standardised 1ghz cpu time) has validated the idea. proc. opencert 2010 18 / 20 eceasst bibliography [abu09] f. abujarad, b. bonakdarpour and s. kulkarni. parallelizing deadlock resolution in symbolic synthesis of distributed programs. in proc. 8th intl. workshop on parallel and distributed methods in verification, nov. 2009 (with formal methods 2009). [and04] d. p. anderson, boinc: a system for public-resource computing and storage. in proc. 5th ieee/acm intl. workshop on grid computing, nov. 2004. [akw05] d. p. anderson, e. korpela and r. walton. high-performance task distribution for volunteer computing, in proc. 1st ieee intl. conf. on e-science and grid technologies, dec. 2005. [ansi89] american national standard for information systems – programming language c. ansi x3.159-1989. american national standards institute. 1989. [br02] t. ball and s. k. rajamani. the slam project: debugging system software via static analysis. in proc. 29th acm symp. on principles of programming languages, jan. 2002. [bob01] p. k. bobko. open-source software and the demise of copyright. rutgers computer & technology law journal 51, 2001. [brls04] m. barnett, k. rustan, m. leino and w. schulte. the spec# programming system: an overview. in proc. intl. workshop on construction and analysis of safe, secure and interoperable smart devices, mar. 2004. lncs 3362, springer, 2004. [bg04] p. t. breuer and m. garcı́a valls. static deadlock detection in the linux kernel. in a. llamosı́ and a. strohmeier (eds.), reliable software technologies – ada-europe 2004, proc. 9th ada-europe intl. conf. on reliable software technologies, june 2004. lncs 3063, springer, 2004. [bp06a] p t. breuer and s. pickin. one million (loc) and counting: static analysis for errors and vulnerabilities in the linux kernel source code. in l. m. pinho and m. gonzález harbour (eds.), reliable software technologies – ada-europe 2006, proc. 11th ada-europe intl. conf. on reliable software technologies, june 2006. lncs 4006, springer, 2006. [bp06b] p. t. breuer and s. pickin. symbolic approximation: an approach to verification in the large. innovations in systems and software engineering 2(3-4), dec. 2006. [bp09] p. t. breuer and s. pickin. a formal nethod (a networked formal method). innovations in systems and software engineering, 6(4), dec. 2010. [ces86] e. clarke, e. emerson and a. sistla. automatic verification of finite-state concurrent systems using temporal logic specifications. acm trans. on programming languages and systems, 8(2), 1986. 19 / 20 volume 33 (2010) open source verification [cc77] p. cousot and r. cousot. abstract interpretation: a unified lattice model for static analysis of programs by construction or approximation of fixpoints. in proc. 4th acm symp. on principles of programming languages, jan. 1977. [dou05] k. douglas. postgresql. sams publishing (2nd ed.), 2005. [ecch00] d. engler, b. chelf, a. chou and s. hallem. checking system rules using systemspecific, programmer-written compiler extensions. in proc. 4th symp. on operating system design and implementation, oct. 2000. [el02] d. evans and d. larochelle. improving security using extensible lightweight static analysis. ieee software 19(1), jan/feb 2002. [fta02] j. s. foster, t. terauchi, and a. aiken. flow-sensitive type qualifiers. in proc. acm sigplan conf. on programming language design and implementation, june 2002. [gou99] r. w. gomulkiewicz. how copyleft uses license rights to succeed in the open source software revolution and the implications for article 2b. 36 houston law review 179, 1999. [gh91] j. v. guttag and j. j. horning. introduction to lcl, a larch/c interface language. http://ftp.digital.com/pub/compaq/src/research-reports/abstracts/src-rr-074.html. [gri02] a. griffith. gcc: the complete reference. mcgrawhill/osborne, 2002. [hol03] g. j. holzmann. the spin model checker: primer and reference manual. addison-wesley, sep. 2003. [hjg08a] g. j. holzmann, r. joshi1 and a. groce. swarm verification. in proc. 23rd ieee/acm intl. conf. on automated software engineering, sep. 2008. [hjg08b] g. j. holzmann, r. joshi1 and a. groce. model driven code checking. automated software engineering, 15(3-4), dec. 2008. [iso99] iso/iec 9899-1999, programming languages – c. international standards organisation, 1999. [jw04] r. johnson and d. wagner. finding user/kernel pointer bugs with type inference. in proc. 13th usenix security symp., 2004, aug. 2004. [nl96] g. c. necula and p. lee. safe kernel extensions without run-time checking. sigops operating systems review 30, si, oct. 1996. [wfba00] d. wagner, j. s. foster, e. a. brewer and a. aiken. a first step towards automated detection of buffer overrun vulnerabilities. in proc. network and distributed system security symp., feb. 2000. proc. opencert 2010 20 / 20 http://ftp.digital.com/pub/compaq/src/research-reports/abstracts/src-rr-074.html introduction context and related work contents certification certification in the abstract what is a defect? example false positives accountability analysis and evaluation the cloud computation logic implementation and experiment populating the database pruning the analysis improving performance allocation and management strategy statistical inferences summary visualization of business process modeling anti patterns electronic communications of the easst volume 25 (2010) proceedings of the workshop visual formalisms for patterns at vl/hcc 2009 visualization of business process modeling anti patterns ralf laue and ahmed awad 12 pages guest editors: paolo bottoni, esther guerra, juan de lara managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst visualization of business process modeling anti patterns ralf laue1 and ahmed awad2 1chair of applied telematics / e-business computer science faculty, university of leipzig, germany laue@ebus.informatik.uni-leipzig.de 2business process technology group hasso plattner institute, university of potsdam, germany ahmed.awad@hpi.uni-potsdam.de abstract: the most common way to model business processes is to use a graphical modeling language. the most widespread notation are business process diagrams modeled in the language bpmn. in this paper, we formalize structural patterns that can lead to control flow errors in such graphical models. for expressing such error patterns, we use the visual query language bpmn-q . by using a query processor, a business process modeler is able to identify possible errors in business process diagrams. moreover, the erroneous parts of the business process diagram can be highlighted when an instance of an error pattern is found. this way, the modeler gets an easyto-understand feedback in the visual modeling language he or she is familiar with. keywords: business process model, business process diagram, bpmn-q, visualization 1 introduction patterns are used in software engineering to describe reusable solutions for common problems. a prominent example are design patterns [ghjv95], reusable solutions in the field of software design. patterns have also been used to describe commonly occurring bad practices. these patterns are also known as anti-patterns. in this article, we will formalize structural anti-patterns in business process models (bpm). bpm are advanced variants of flow charts. different business process modeling languages share a core set of modeling constructs. within a bpm, activities can be arranged in sequential order, and routing constructs can be used for modeling alternative and parallel threads. in the last years, several approaches for detecting errors in the control flow of bpm (for example deadlocks) have been published. those approaches varied from structural analysis of bpm to the examination of behavioral state space. there are already several tools that detect problems in bpm. examples can be found in [esh02, ck04, wyn06] – this list is far from being complete. while the problem of detecting errors can be regarded as being solved, many of the tools still fail to give a readable feedback on how to correct the error. 1 / 12 volume 25 (2010) visualization of business process modeling anti patterns in this paper, we address the presentation of errors a visual manner. we formalize several error patterns as bpmn-q queries [awa07]. when a query is structurally matched by a bpm, the matching part of the model is the part containing a problem. 2 preliminaries 2.1 business process modelling notation there are several visual languages for modeling business processes. the business process modeling notation (bpmn) is the most widespread language, for this reason we use it for the examples in this paper. however, the techniques described in this paper can also be applied for other languages, because most business process modeling languages share certain basic constructs. in this section, we will shortly describe those basic constructs of the bpmn language. for more details about bpmn, the reader is referred to www.bpmi.org. events (something that happens during the lifetime of a business process) are represented by a circle. although not formally required by the standard, every bpmn model should have at least a start event (depicting the fact that the process is instantiated) and an end event (depicting the fact that the process has been completed). activities (tasks that have to be performed) are represented by a rectangle with rounded corners. the flow of control (called sequence flow in bpmn terminology) between the activities is depicted by arcs. the direction of such an arc shows in which order the activities have to be performed. gateways can be used for forking and joining paths that have to be performed in parallel or (based on certain conditions) alternatively. there are two kinds of gateways: splits have more than one outgoing arc, and joins have more than one incoming arc. gateways are represented by a diamond shape. when used as a split, an exclusive gateway splits the sequence flow to exactly one of its outgoing branches. when used as a join, it awaits one incoming branch being completed before triggering the outgoing flow. this kind of gateways (which we call xor-gateways) is depicted by a symbol. when splitting, a parallel gateway activates all outgoing branches; the activities on these branches are executed in parallel. when used as a join, a parallel gateway waits for all incoming branches to complete before triggering the outgoing flow. parallel gateways are depicted by a symbol. we will refer to this kind of gateways as and-gateways. the inclusive gateway is something in-between the exclusive and the parallel gateway. when used as a split, some of the outgoing branches (but at least one) are activated. when merging, an inclusive gateway waits until all active incoming branches have been completed before triggering the outgoing flow. inclusive gateways (or or-gateways) are depicted by a symbol. fig. 1 contains all mentioned kinds of gateways. the model shows a simplified business process in a bank. when a customer applies for a real-estate credit, the customer’s credit rating, the real estate construction documents and the land register record are checked. all these activities are done in parallel, therefore an and-gateway is used in the model. as the result of those assessments, the application either will be rejected or the contract is to be prepared. the xorgateway means that only one of the activities ”reject application” and ”prepare contract” can take place. after the contract has been prepared, the process either can end or the bank might offer additional products: a loan protection insurance and a residence insurance. whether a loan proc. vffp 2009 2 / 12 eceasst protection insurance, a residence insurance or both are offered, has to be decided case-by-case. the or-gateway shows that only one of the activities or both of them (in parallel) can take place. 2.2 bpmn-q: a visual language for querying business processes bpmn-q [awa07, adw08] is a visual language based on bpmn. it is used to query bpm by matching a process model graph to a query graph. a bpmn-q query is represented as a business process diagram that might contain the following additional elements (whose graphical representation is shown in shown in fig. 2): (a) variable node: refers to (unknown) activities in a query. (b) generic node: refers to an unknown node in a process. it could evaluate to any node type. (c) generic split / generic join: refers to any type of split / join gateways. (d) negative sequence flow: states that there is no arc from a node a to a node b. (e) path: states that there must be a path from a node a to a node b. (f) negative path: states that there is no path from a node a to a node b. the result of a graphical query is given by a sub-graph of the original bpm. an exemplary query and its match are shown in fig. 3. when matching the process graph in fig. 3(a) to the query in fig. 3(b), the result of the query is the sub-graph that contains the nodes b and d and all nodes on the path from b to d. (see fig. 3(c)). the query shown in fig. 3 looks for all paths between b and d. it is also possible to exclude some graph elements from a path search by assigning names to elements and adding an exclude property to a path edge: for instance, in the query in fig. 5(a), the xor-split is named ?s. by adding the exclude property to the path search from ?nd1 to ?j, the search will be limited to paths from ?nd1 to ?j which do not pass the xor-split ?s. to process a bpmn-q query, a query graph is matched to the structure of the business process. a bpmn business process diagram can be defined as a directed typed graph as follows: definition 1 a business process diagram (or process graph) is a tuple pg = (n, a, e, g, f) where • n is a finite set of nodes that is partitioned into the set of activities a, the set of events e, and the set of gateways g. an event e ∈ e is called a start event if it does not have incoming edges. it is called an end event if it has no outgoing edges. all nodes in a process graph are attributed by unique ids. • f ⊆ n ×n is the sequence flow relation between nodes. c u s t o m e r a p p l i e s f o r r e a l e s t a t e c r e d i t c h e c k c r e d i t r a t i n g c h e c k r e a l e s t a t e c o n s t r u c t i o n d o c u m e n t s c h e c k l a n d r e g i s t e r r e c o r d r e j e c t a p p l i c a t i o n p r e p a r e c o n t r a c t o f f e r l o a n p r o t e c t i o n i n s u r a n c e o f f e r r e s i d e n c e i n s u r a n c e figure 1: bpmn example model 3 / 12 volume 25 (2010) visualization of business process modeling anti patterns @variable //x x //* s j (a) (b) (c) (d) (e) (f) (g) figure 2: bpmn-q elements. b d// (a) a process model a b c d e (b) a query with path element connecting nodes b, d b c d (c ) a sub-graph from process in (a) matching the query in (b) figure 3: example of a bpmn-q query the query language bpmn-q provides additional types of edges between nodes: definition 2 a query graph is a tuple qg= (nq, aq, eq,gq, sq, pq,xq) where • nq is a finite set of nodes that is partitioned into the set of activities aq, the set of events eq, and the set of gateways gq. • sq ⊆ nq ×nq is the set of sequence flow edges. • pq ⊆ nq ×nq is the set of path edges. • xq ⊆ nq ×nq is the set of negative path edges. nodes of the query graph can be identified by assigning labels. labels can be activity names or special names either starting with ’@’ for variable activities or with ’?’ for other nodes and path edges. thus, a function l : nq∪pq → σ∗ is a labeling function assigning labels (identifiers) to nodes and path edges in the query, where σ is an alphabet. the labels of nodes can be used within the query in the exclude property of path edges. thus, exc : pq → 2{l(n):n∈nq∪pq where l(n) is de f ined} is a function to evaluate the exclude property of a given path edge. with the start of query processing, the query processor tries to bind the nodes in the query graph to the nodes in the process graph. for each node in the query graph, the set of nodes in the process graph having the same type are identified. a bind is considered matching if it satisfies all sequence flow edges, path edges, and negative path edges in the query graph. otherwise, the binding is dropped. for the query to find a match, each node in the query graph must have at least one matching binding. more details about the processing of queries can be found in [awa07]. 3 bpmn soundness patterns 3.1 soundness the most important correctness criterion for bpm is the soundness property, originally introduced by van der aalst for workflow nets [van97]. proc. vffp 2009 4 / 12 eceasst for a business process model to be sound, three properties are required: 1. in every state that is reachable from a start state, there must be the possibility to reach a final state (option to complete). 2. if a state has no subsequent state (according to the transition relation that defines the precise semantics), then only events without outgoing arcs (end events) must be marked as being ”active” in this state (proper completion). 3. there is no element of the model that is never processed in any execution of the model (no needless elements). violations of the soundness criterion usually indicate an error in the model. 3.2 pattern catalogs to our knowledge, the first categorization of error patterns based on the structure of a bpm has been compiled at the university of osaka. in [oikk99], five so called deadlock-patterns are discussed. the basic concepts used in [oikk99] are reachability (in a graph) and transferability (the fact that the control flow will always reach some node in a model if another node has been reached before). the authors of [oikk99] claim that a model always has a deadlock if one of the patterns can be detected. unfortunately, this claim is wrong: fig. 4 shows a sound model for which [oikk99] would report a deadlock between split node x and-join node a. the reason behind the wrong error report is that by using the concept of transferability, it is not possible to realize that both incoming control flows at join a1 will always synchronize. x aa 1 figure 4: [oikk99] would wrongly report a deadlock for this model in [lk05], liu und kumar analyzed how unstructured bpm can be mapped into structured ones with the same behavior. for this purpose, they categorized entries into and exits from a control structure between a split and a corresponding join. in particular, they named the combinations that will lead to control-flow errors. koehler and vanhatalo discuss ”typical modeling errors extracted from hundreds of actual process models created in different tools” [kv07]. the anti-patterns discussed in [kv07] are well-known cases for an incongruity between the type of a split and the type of a join. mendling [men07] uses reduction rules for finding errors in event driven process chains. these reduction rules include information about possible error cases in a model. all mentioned pattern systems have in common that they include the typical errors that result from a mismatch between the type of a split and the type of a join and from choosing a non-xor gateway as a loop entry or loop exit. in the next chapter, we will use bpmn-q for expressing these patterns. 5 / 12 volume 25 (2010) visualization of business process modeling anti patterns 4 anti patterns expressed in bpmn-q in this section, we express the patterns mentioned in the previous section as bpmn-q queries. when a query finds a match, the result is the matching sub-graph of the process. this way, the localization of the erroneous part of the bpm is given for free without a need to translate between verification tools and the visual representation of the model. 4.1 (x)or-split/and-join combination * *// exclude(?p1,?s,?j) //exclude(?s,?j) ?nd1 ?nd2 ?p1 ?s ?j x // (a) the query a b (b) a process matching the query a b (c) a process not matching the query figure 5: query for an (x)or-split/and-join combination a deadlock can occur when an (x)or-split opens alternative paths that are later joined by an and-join. the query in fig. 5(a) captures the this situation between an xor-split ?s and the and-join ? j. in order to find two paths from ?s to ? j whose only common nodes are ?s and ? j, we try to find a path from ?nd1 (the successor of ?s) to ? j. this path is given the name ? p1. similarly, we try to find another path from s to ?nd2. the exclude property of the latter path is set to ?s, ? j, ?p1. exclusion of ?p1 instructs the bpmn-q query processor to evaluate path ? p1 first and then to search for other paths which do not share any node with p1. the exclusion of ?s, ? j on both paths is necessary to prevent false alarms that can result from loops. finally, the negative path from ?nd1 to ?nd2 prevents false alarms in cases like the one shown in fig. 9(c). 4.2 entry into a parallel control block * * // exclude(?p1,?s,?j) //exclude(?s,?j) ?nd1 ?nd2 ?p1 ?j ?e // exclude(?p1,?s,?j) //exclude(?s) ?s // ?ev1 ?ev2 (a) the query a b (b) a process matching the query figure 6: query for an entry into a parallel control block proc. vffp 2009 6 / 12 eceasst usually, in a block that starts and ends with an and-gateway, there is no chance for a deadlock, because all incoming branches of the and-join have been activated before. however, if on a path from the split to the join there is an (x)or-join that can receive activations not originating from the and-split, a deadlock can occur. we call this (x)or-join an entry into the and block. this situation is captured declaratively in fig. 6. the use of two different start events, ?ev1,?ev2, forces the query processor to find matches in bpms having more than one start event. 4.3 and-join as an entry into a loop x // // * * ?in1 ?in2 ?j (a) the query a b c (b) a process matching the query figure 7: query for an and-join as an entry into a loop the query in fig. 7 describes another situation where a bpm could suffer from a deadlock. whenever an and-join is part of a loop where only a subset of its input points are activated, a deadlock occurs. this is declaratively represented by a path edge from ? j to ?in1 and a negative path edge from ? j to ?in2. 4.4 and-join after (x)or-split does not synchronize * // * x // x // //exclude(?s) ?s ?j ?nd1 ?nd2 (a) the query a b c (b) a process matching the query figure 8: query for an and-join after (x)or-split a deadlock can occur if an and-join awaits to be activated on all its incoming arcs, but an (x)or-split before this and-join can lead the flow of control away in another direction. the query in fig. 8 describes this situation. 7 / 12 volume 25 (2010) visualization of business process modeling anti patterns 4.5 and-split/xor-join combination lack of synchronization is a modeling error that occurs whenever an and-split is combined with an xor-join. all outgoing branches from the and-split will be activated. however, the semantics of the xor-join is to wait for the completion of exactly one of its incoming branches. due to space limitations, we do not provide a separate query for this type of errors. rather, we can reuse the query in fig. 5(a) with modifications: we switch the roles of the xor and the and in that query. also, we drop the negative path between ?nd1 and ?nd2. the resulting query captures the ”lack of synchronization errors”. 4.6 infinite loop //exclude(?p) // ?s ?p (a) the query a b c (b) a process matching the query a b (c) a process not matching the query figure 9: query for an infinite loop another modeling error occurs when a part of the process is activated infinitely often. this can happen when a modeler mistakenly represent a loop exit with an and-split rather than an xor. the query in fig. 9(a) describes this situation: path edge ?p from the and split ?s back to itself represents the looping case. to prevent reporting false alarms, e.g., the case of a parallel block nested in a loop, the query requires to have a totally distinct path from ?s to an end event. 5 using the patterns as common bpm languages share the most basic modeling elements, the application of our patterns is not restricted to the language bpmn. previously, the patterns have been successfully used for the language event-driven process chains [van99]. for this purpose, they have been implemented into the modeling tool bflow1, using the openarchitectureware check language2 [kkgl08]. another implementation, using a larger repository of 23 patterns, has been made using logical reasoning with prolog. in [gl09], it has been shown that a pattern-based heuristic reasoning detects control-flow errors almost as accurate as model checkers which explore the whole state space of a model. however, other than approaches using model checkers, it does not suffer from the state-space explosion problem. to test our approach based on graphical bpmn-q queries, we searched for the patterns discussed in the previous section in 109 models taken from the public repository of the modeling 1 http://www.bflow.org 2 http://www.eclipse.org/gmt/oaw/ proc. vffp 2009 8 / 12 eceasst figure 10: a process model with a false alarm tool oryx (www.oryx-editor.org). table 1 shows how many models were detected that contained instances of the patterns. it also shows the false alarms, i.e. the cases for which the model does not suffer from the discussed problem despite matching the query. the query processor ran on a pc with 2gb ram and an intel dual core processor at 1.83 ghz under the operating sytem windows xp with service pack3 . an observation that is worth mentioning is that all false alarms occurred because of other errors that are located elsewhere in a model. an example is shown in fig. 10. it matches the bpmn-q query and-split/xor-join combination, because there are two distinct paths from the and-split to the xor-join. however, at execution, this error would never occur because the process would either terminate without problems or deadlock before reaching the xor-join. of course, this possible deadlock will be detected by the pattern and-join after (x)or-split does not synchronize. in situations like this, our pattern-based approach delivers too many warnings (which is better than missing a legitimate warning). anti-pattern erroneous models false alarms processing time (x)or-split/and-join combination 4 0 208.735 sec entry into a parallel control block 0 0 237.515 sec and-join as an entry into a loop 1 0 219.453 sec and-join after (x)or-split 7 0 221.250 sec does not synchronize and-split/xor-join combination 2 5 212.391 sec infinite loop 0 0 229.578 sec table 1: results of applying anti-pattern queries 9 / 12 volume 25 (2010) visualization of business process modeling anti patterns 6 related work while soundness is necessary for the correctness of a bpm, it does not yet guarantee that the model really conforms to the business rules. for this reason, several researchers applied modelchecking in order to verify statements like ”each delivery must always be preceded by a payment”. these approaches make it necessary to specify the properties to validate as temporal formulas. usually, this is too difficult for the business people who work with the models. as an alternative, several authors developed notations based on a process modeling language to express the allowed executions of a bpm. such approaches have been presented for event-driven process chains [rum99, sm06, ff08], bpml [bra05], uml activity diagrams [fess07] and for bpel specifications [wkh08, lmx07]. quartel et al. [qds05] use the interaction systems design language for expressing dependencies among (distributed) business processes. van der aalst and pesic [vp06] suggested a new language decserflow for specifying the properties of a single service or service compositions. as a different stream of research, barros et al. [bdg07] and rommelspacher [rom08] suggested graphical languages for expressing complex events in business processes. the main difference between those graphical languages and bpmn-q is that bpmn-q is used to formulate queries about the business process model itself (i.e. its graphical structure), not about the state space of its executions. this makes it possible to use bpmn-q for searching for modeling problems without having to compute the state space of all possible executions. another query language that is working on the graphical structure of a model is bpmn vql [ft08]. its main purpose is to find crosscutting concerns in bpm. our language bpmn-q is more expressive than bpmn vql. for instance, generic nodes, negative paths, and variable names in bpmn-q have no equivalent constructs in bpmn vql. 7 conclusion and directions for future research the approach presented in this paper can be used for detecting control flow errors in business process models. by using bpmn-q queries, it is possible to give a business process modeler a feedback not only about the presence of errors but also about the part of the model that causes the error. this information is given in the visual formalism the modeler is familiar with. so far, more advanced bpmn constructs like exception handling have not yet been considered in the graphical language. inclusion of such constructs would enable us to express even more complex patterns like the ones published in [gl07] and [rph08]. another direction of future research can be to reduce false warnings in cases like the one shown in fig. 10 where a model contains more than one instance of one of our error patterns. bibliography [adw08] a. awad, g. decker, m. weske. efficient compliance checking using bpmn-q and temporal logic. in bpm ’08: proceedings of the 6th international conference on business process management. pp. 326–341. 2008. proc. vffp 2009 10 / 12 eceasst [awa07] a. awad. bpmn-q: a language to query business processes. in reichert et al. (eds.), proceedings of the 2nd international workshop on enterprise modelling and information systems architectures (emisa’07). lni p-119, pp. 115–128. gi, 2007. [bdg07] a. p. barros, g. decker, a. großkopf. complex events in business processes. in abramowicz (ed.), proceedings of the 10th international conference on business information systems. lncs 4439, pp. 29–40. springer, 2007. [bra05] m. brambilla. ltl formalization of bpml semantics and visual notation for linear temporal logic. technical report, politecnico di milano, 2005. [ck04] n. cuntz, e. kindler. on the semantics of epcs: efficient calculation and simulation. in epk 2004: geschäftsprozessmanagement mit ereignisgesteuerten prozessketten, proceedings. pp. 7–26. 2004. [esh02] r. eshuis. semantics and verification of uml activity diagrams for workflow modelling. phd thesis, university of twente, enschede, 2002. [fess07] a. forster, g. engels, t. schattkowsky, r. v. d. straeten. verification of business process quality constraints based on visual process patterns. in symposium on theoretical aspects of software engineering. pp. 197–208. 2007. [ff08] s. feja, d. fötsch. model checking with graphical validation rules. engineering of computer-based systems, ieee international conference on the 0:117–125, 2008. [ft08] c. d. francescomarino, p. tonella. crosscutting concern documentation by visual query of business processes. in proceedings of the international workshop on business process design. 2008. [ghjv95] e. gamma, r. helm, r. johnson, j. vlissides. design patterns: elements of reusable object-oriented software. addison-wesley professional, 1995. [gl07] v. gruhn, r. laue. good and bad excuses for unstructured business process models. in proceedings of 12th european conference on pattern languages of programs (europlop 2007). 2007. [gl09] v. gruhn, r. laue. a heuristic method for business process model evaluation. in 5th international workshop on enterprise and organizational modeling and simulation (eomas 2009). 2009. [kkgl08] s. kühne, h. kern, v. gruhn, r. laue. business process modelling with continuous validation. in pautasso and koehler (eds.), mde4bpm 2008 1st international workshop on model-driven engineering for business process management. 2008. [kv07] j. koehler, j. vanhatalo. process anti-patterns: how to avoid the common traps of business process modeling, part 1 modelling control flow. ibm websphere developer technical journal 10.4., april 2007. 11 / 12 volume 25 (2010) visualization of business process modeling anti patterns [lk05] r. liu, a. kumar. an analysis and taxonomy of unstructured workflows. in aalst et al. (eds.), business process management. volume 3649, pp. 268–284. 2005. [lmx07] y. liu, s. müller, k. xu. a static compliance-checking framework for business process models. ibm systems journal 46(2):335–361, 2007. [men07] j. mendling. detection and prediction of errors in epc business process models. phd thesis, vienna university of economics and business administration, 2007. [oikk99] s. onoda, y. ikkai, t. kobayashi, n. komoda. definition of deadlock patterns for business processes workflow models. in proceedings of the 32nd annual hawaii international conference on system sciences. p. 5065. ieee computer society, 1999. [qds05] d. quartel, r. dijkman, m. van sinderen. an approach to relate business and application services using isdl. in edoc ’05: proceedings of the ninth ieee international edoc enterprise computing conference. pp. 157–168. 2005. [rom08] j. rommelspacher. modelling complex events with event-driven process chains. in hesse and oberweis (eds.), sigsand-europe. lni 129, pp. 79–82. gi, 2008. [rph08] t. rozman, g. polancic, r. v. horvat. analysis of most common process modeling mistakes in bpmn process models. in 2008 bpm and workflow handbook. 2008. [rum99] f. j. rump. geschäftsprozeßmanagement auf der basis ereignisgesteuerter prozeßketten. b. g. teubner verlag stuttgart leipzig, 1999. [sm06] c. simon, j. mendling. verification of forbidden behavior in epcs. in mayr and breu (eds.), modellierung. lni 82, pp. 233–242. gi, 2006. [van97] w. m. van der aalst. verification of workflow nets. in azéma and balbo (eds.), application and theory of petri nets 1997, 18th international conference, icatpn ’97, toulouse, france, june 23-27, 1997, proceedings. pp. 407–426. 1997. [van99] w. m. van der aalst. formalization and verification of event-driven process chains. information & software technology 41(10):639–650, 1999. [vp06] w. m. van der aalst, m. pesic. specifying, discovering, and monitoring service flows: making web services process-aware. technical report bpm-06-09, bpm center report, bpmcenter.org, 2006. [wkh08] r. wörzberger, t. kurpick, t. heer. checking correctness and compliance of integrated process models. in proceedings of the 10th international symposium on symbolic and numeric algorithms for scientific computing (synasc 2008). 2008. [wyn06] m. t. wynn. semantics, verification, and implementation of workflows with cancellation regions and or-joins. phd thesis, queensland university of technology brisbane, australia, 2006. proc. vffp 2009 12 / 12 introduction preliminaries business process modelling notation bpmn-q: a visual language for querying business processes bpmn soundness patterns soundness pattern catalogs anti patterns expressed in bpmn-q (x)or-split/and-join combination entry into a parallel control block and-join as an entry into a loop and-join after (x)or-split does not synchronize and-split/xor-join combination infinite loop using the patterns related work conclusion and directions for future research symbolic attributed graphs for attributed graph transformation electronic communications of the easst volume 30 (2010) international colloquium on graph and model transformation on the occasion of the 65th birthday of hartmut ehrig (gramot 2010) symbolic attributed graphs for attributed graph transformation fernando orejas and leen lambers 25 pages guest editors: claudia ermel, hartmut ehrig, fernando orejas, gabriele taentzer managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst symbolic attributed graphs for attributed graph transformation fernando orejas1 ∗ and leen lambers2 1 orejas@lsi.upc.edu dpt. de llenguatges i sistemes informátics universitat politècnica de catalunya, barcelona, spain. 2 leen.lambers@hpi.uni-potsdam.de hasso plattner institut universität potsdam, germany abstract: in this paper we present a new approach to deal with attributed graphs and attributed graph transformation. this approach is based on working with what we call symbolic graphs, which are graphs labelled with variables together with a formula that constrains the possible values that we may assign to these variables. in particular, in this paper we will compare in detail this new approach with the standard approach to attributed graph transformation. keywords: graph transformation, attributed graphs, symbolic graphs 1 introduction the study of graph grammars and graph transformation started 40 years ago. however, the first formal approach to deal with attributed graphs is much more recent [12], even if this kind of graphs are needed in many applications of the field. actually, the development of the fundamental theory of graph transformation for the case of attributed graphs is quite recent [7]. the reason for this late development is probably that, even if the attributed case may seem to be a straightforward generalization of the standard case, it presents some difficulties which have hampered the development of this fundamental theory. one of these difficulties lies on the complication of putting together two theoretical frameworks, algebraic specification and graph transformation, even if both are algebraic and categorical frameworks. in fact, to avoid this problem, at least to some extent, in [12] graphs are coded as algebras with the aim of having a uniform setting. the problem is that, in general, algebra transformation does not enjoy the right properties to ensure that the basic theory of graph transformation will hold. the approach studied in [12], based on the approach presented in [10] is, in a sense, the opposite. in this case, the data algebra is embedded in the graph. more, precisely, an attributed graph is seen as a pair formed by an algebra, to define the values of the attributes of the graph, and a graph that includes all the values of the algebra as (a special kind of) nodes. this approach still has some difficulties caused by the fact that, even if the graphs of interest are defined over the same data algebra, we have to consider categories including graphs over different algebras. the reason is that, most often, the algebras in the graphs occurring in the transformation rules are ∗ this work has been partially supported by the cicyt project (ref. tin2007-66523) and by the agaur grant to the research group albcom (ref. 00516). 1 / 25 volume 30 (2010) mailto:orejas@lsi.upc.edu mailto:leen.lambers@hpi.uni-potsdam.de symbolic attributed graphs different from the algebras in the graphs to which we apply these rules. in [7] the algebra used in rules is the freely generated term algebra over a given set of variables, i.e. attributes are terms with variables. however, one could use different algebras for defining transformation rules. in particular, for the formalization of attribute conditions, the term algebra over a set of variables is not sufficient. in this sense, in this paper we introduce a specific way to do this by taking the initial algebra associated to a given specification. in [19], plump and steinert present an approach that avoids the complexity of having to deal, in a single concept, with graphs and algebras. this approach is essentially based on two ideas. on the one hand, attributed graphs are seen as labelled graphs, where the labels are defined as elements of an algebra. on the other hand, graph transformations involving computations on the labels are defined by rule schemas, which are similar to graph transformation rules, but defined in terms of graphs labelled by terms with variables. then, to apply a rule schema to a given graph we must first instantiate the schema assigning data values to the variables in the schema. the result of the instantiation is a rule where the terms labeling the graphs have been replaced by the values of these terms. in our opinion, the approach has two main drawbacks. the first one is the fact that rule schemas are not first class citizens, in the sense that they need to be instantiated to define the rules. this causes that one may need to explicitly reformulate in terms of that framework most constructions and results associated to graph transformation. this would be the case, for instance, if we would want to define in that framework notions like graph constraints, typing or borrowed contexts. on the other hand, in that approach, a limitation is imposed on the number of labels that each node or edge can have. in particular, in that paper, at most one label is allowed, though it would not be difficult to fix a different limitation. the main aim of this paper is to present a new approach to deal with attributed graph transformation, which we believe is conceptually simple but more powerful than previous approaches, as we show. the approach is partially inspired on how the clausal part and the data part are conceptually separated in constraint logic programming [11, 14]. in particular, attributed graphs are presented as symbolic graphs consisting of a graph that includes as nodes some variables which represent the values of the attributes, together with a set of formulas that constrain the possible values of these variables. this means that the underlying algebra of values remains only implicit to define the satisfaction of these formulas. the idea underlying this approach was first introduced in [16, 17] to study graph constraints over attributed graphs and, then, used again with a similar aim to specify model transformations by means of patterns [8]. symbolic graphs can be seen as specifications of attributed graphs. actually, to compare the standard approach to attributed graph transformation, we define a semantics of symbolic graphs in terms of classes of attributed graphs and we show how attributed graphs can be identified with some specific kind of symbolic graphs, which we call grounded symbolic graphs. then, to compare the expressive power of the two approaches with respect to attributed graph transformation, we first show that symbolic graphs, as it happens with attributed graphs [10], form an adhesive hlr category [13, 4] to ensure that symbolic graphs inherit the fundamental theory of graph transformation. a variant of this proof is already included in [17]. finally, we show that attributed graph transformation systems can be coded into symbolic graph transformation systems but that the converse is not true in general. the paper is organized as follows. in section 2 we provide a reminder of some notions that are used in the rest of the paper. in particular, first, we briefly enumerate some notions from proc. gramot 2010 2 / 25 eceasst algebraic specification; then, we present e-graphs which are used as the graph part for both attributed graphs and symbolic graphs; finally, we define the category of attributed graphs as presented in [4]. in section 3 we present the category of symbolic graphs, showing that it is adhesive hlr. section 4 is dedicated to relate the categories of attributed and symbolic graphs and section 5 to compare the expressive power of both approaches with respect to attributed graph transformation. in section 6, we draw some conclusions. finally, in an appendix some technical details and proofs are provided. 2 preliminaries we assume that the reader has a basic knowledge on algebraic specification and on graph transformation. for instance, we advise to look at [6] for more detail on algebraic specification or at [20, 4] for more detail on graph transformation. 2.1 basic algebraic concepts and notation as usual, a signature σ = (s, ω) consists of a set of sorts s, and a family of operation symbols of the form op : s1 ×···×sn → s, denoted by ω, where n ≥ 0 and s1, . . . , sn, s ∈ s. however, in this paper, signatures include also predicates. we can deal with this extended case in two ways. the first one is to consider that σ consists, in addition, of a family of predicate symbols. the second one, which we will use, because it is simpler, is based in considering that there is a special sort in s, which we could call logical, and that predicate symbols are just operation symbols with profile s1×···×sn → logical. in this case, logical connectives can be treated as operation symbols over the logical sort. in addition, the truth values t and f may be seen as constants in the signature of sort logical. a σ-algebra a consists of an s-indexed family of sets {as}s∈s and a function opa : as1 ×···× asn →as for each operation op : s1×···×sn →s in the signature. a σ-homomorphism h : a→a ′ consists of an s-indexed family of functions {hs : as → a ′ s}s∈s commuting with the operations. σ-algebras and σ-homomorphisms form the category algς. a congruence ≡ on an algebra a is an s-indexed family of equivalence relations {≡s}s∈s which are compatible with the operations. in this case, a/ ≡ denotes the quotient algebra whose elements are equivalence classes of values in a. between a and a/ ≡ there is a canonical homomorphism mapping every element in a into its equivalent class. given signatures σ, σ′, with σ′ ⊆ σ, every σ-algebra can be seen as a σ′-algebra, by forgetting all the sorts and operations which are not in σ′. in particular this is called the σ′-reduct of a σ-algebra a and is denoted by a|σ′. given a signature σ, we denote by tς the term algebra, consisting of all the possible σ-(ground) terms. tς is initial in algς, and the unique homomorphism ha : tς → a yields the value of each term in a. similarly, tς(x ) denotes the algebra of all σ-terms with variables in x , and given a variable assignment σ : x → a, this assignment extends to a unique homomorphism σ # : tς(x ) → a yielding the value of each term after the replacement of each variable x by its value σ (x). in particular, when an assignment is defined over the term algebra, i.e. σ : x → tς, then σ #(t) denotes the term obtained by substituting each variable x in t by the term σ (x). 3 / 25 volume 30 (2010) symbolic attributed graphs a σ-algebra a is finitely generated if every element in a is the value of some ground term. it is not difficult to see that if a is finitely generated there is at most one homomorphism between a and any other σ-algebra a′. a specification sp = (σ, ax) consists of a signature σ and a set of axioms ax, which may be seen as terms of logical sort. equational specifications are a special case, where the only predicate symbol is the equality. similarly, conditional equations may be considered as a special kind of terms. given sp, algsp denotes the full subcategory of algς, consisting of all σ-algebras a satisfying the axioms in the specification, i.e. a |= ax. in the case where sp consists of equations or conditional equations there is an initial algebra in algsp, denoted by tsp. 2.2 e-graphs e-graphs are introduced in [4] as a first step to define attributed graphs. intuitively, an e-graph is a kind of labelled graph, where both nodes and edges may be decorated with labels from a given set e . the difference with labelled graphs, as commonly understood, is that in labelled graphs it is usually assumed that each node or edge is labelled with a given number of labels, which is fixed a priori. in the case of e-graphs, each node or edge may have any arbitrary (finite) number of labels, which is not fixed a priori. actually, in the context of graph transformation, the application of a rule may change the number of labels of a node or of an edge. formally, in e-graphs labels are considered as a special class of nodes and the labeling relation between a node or an edge and a given label is represented by a special kind of edge. notice that, for instance, this means that the labeling of an edge is represented by an edge whose source is an edge and whose target is a node (a label). definition 1 (e-graphs and morphisms) an e-graph over the set of labels l is a tuple g = (vg, l, eg, enl, ee l,{s j,t j} j∈{g,nl,e l}) consisting of: • vg and l, which are the sets of graph nodes and of label nodes, respectively. • eg, enl, and ee l, which are the sets of graph edges, node label edges, and edge label edges, respectively. and the source and target functions: • sg : eg →vg and tg : eg →vg • snl : enl →vg and tnl : enl → l • se l : ee l → eg and te l : ee l → l given the e-graphs g and g′, an e-graph morphism f : g → g ′ is a tuple, 〈 fvg : vg →v ′ g, fl : l → l′, feg : eg → e ′ g, fenl : enl → e ′ nl, feel : ee l → e ′ e l〉 such that f commutes with all the source and target functions. e-graphs and e-graph morphisms form the category e−graphs. the following construction, which tells us how we can replace the labels of an e-graph, is used in the sections below. proc. gramot 2010 4 / 25 eceasst definition 2 (label substitution) given an e-graph g = (vg, l, eg, enl, ee l,{s j ,t j} j∈{g,nl,e l}), a set of labels l′, and a function h : l → l′ we define the e-graph h(g) resulting from the substitution of l along h as h(g) = (v ′g, l ′, e′g, e ′ nl, e ′ e l,{s ′ j,t ′ j} j∈{g,nl,e l}) with: • v ′g = vg, e ′ g = eg, e ′ nl = enl, e ′ e l = ee l,{s ′ j = s j} j∈{g,nl,e l}, and t ′ g = tg • for every e ∈ e′nl : t ′ nl(e) = h(tnl(e)) • for every e ∈ e′e l : t ′ e l(e) = h(te l(e)) moreover, h induces the definition of the e-graph morphism h∗ : g → h(g), with h∗ = 〈idv , h, ideg , idenl , ideel〉. it is routine to see that h(g) is indeed an e-graph and h∗ is an e-graph morphism. in addition, it should be obvious that if h is a bijection then h∗ is an isomorphism. 2.3 attributed graphs following [4], an attributed graph is an e-graph whose labels are the values of a given data algebra that is assumed to be included in the graph. definition 3 (attributed graphs and morphisms) given a signature σ an attributed graph over σ is a pair 〈g, d〉, where d is a given σ-algebra, called the data algebra of the graph, and g is an e-graph such that the set lg of labels of g consists of all the values in d, i.e. lg = ⊎ s∈s ds, where s is the set of sorts of the data algebra and ⊎ denotes disjoint union. given the attributed graphs over σ ag = 〈g, d〉 and ag′ = 〈g′, d′〉, an attributed graph morphism h : ag → ag′ is a pair 〈hgraph, halg〉, where hgraph is an e-graph morphism, hgraph : g → g ′ and halg is a σ-homomorphism, halg : d → d′ such that the values in d are mapped consistently by hgraph and halg, i.e. for each sort s ∈ s the diagram below commutes: ds halg // � _ �� d′s� _ �� lg hgra ph // l′g attributed graphs and attributed graph morphisms form the category attgraphs. moreover, given a data algebra d we will denote by attgraphsd the full subcategory of attgraphs consisting of attributed graphs over d. when defining transformation rules over graphs in attgraphsd, usually the algebra underlying the graphs in the rules is not d but a term algebra over the signature of d. that is, the attributes in the rules are not values but terms, typically with variables. we call these graphs term-attributed graphs. definition 4 (term-attributed graphs) given a signature σ = (s, ω), a term-attributed graph over σ is an attributed graph over the algebra tς(x ), for some s-sorted set of variables x . 5 / 25 volume 30 (2010) symbolic attributed graphs moreover, as we will see in section 5, it is also useful to define transformation rules where the underlying algebra has been defined using a specification. in particular this is useful when we want that the match morphism used to apply the given rule satisfies some specific condition. for instance, suppose that the graph below is the left-hand side of a rule. x1 x2 and suppose that, whenever we apply this rule, we would like that the corresponding match m satisfies that m(x1) ≤ m(x2). we can do this as follows. first we define a specification sp extending σ with the variables x1 and x2 as constants, and the desired condition as an axiom, i.e.: sp = sorts nat, bool opns 0 : nat x1, x2 : nat suc : nat → nat true, f alse : bool + : nat ×nat → nat ≤: nat ×nat → bool axms (x1 ≤ x2) = true now, let tsp be the initial algebra associated to sp, and tsp|σ its σ-reduct. in tsp the term x1 ≤ x2 and the term true belong to the same congruence class, which means that they denote the same element in tsp|σ. therefore, any homomorphism m from tsp|σ into a σ-algebra d must satisfy that, in this algebra, m(x1) ≤ m(x2) yields the true value. hence, we should define the transformation rule over the algebra tsp|σ. definition 5 (term-attributed graphs over a specification) given a signature σ and a specification sp = (σ′, ax), with σ ⊆ σ′, a term-attributed graph over the specification sp extending σ is an attributed graph over the algebra tsp|σ. in [4] it has been proven that attgraphs is an adhesive hlr category for a given class of m-morphisms. let us first recall this notion [4, 13]: definition 6 (adhesive hlr category) a category c is adhesive hlr with respect to a class m of morphisms if: 1. m is a class of monomorphisms closed under isomorphism, composition (i.e. if f : a → b ∈ m and g : b → a ∈ m then g◦ f ∈ m), and decomposition (i.e. if g◦ f ∈ m and g ∈ m then f ∈ m). 2. c has pushouts and pullbacks along m-morphisms. moreover, m-morphisms are closed under pushouts and pullbacks. 3. pushouts in c along m-morphisms are van kampen squares, i.e. for any commutative diagram as the one below, assuming that h1 and g2 are m-morphisms, if the bottom diagram proc. gramot 2010 6 / 25 eceasst is a pushout and the back faces are pullbacks then the top diagram is a pushout if and only if the front diagrams are pullbacks. a′0 h′1 wwoo oo oo oo oo oo oo o h′2 ��? ? ? ? ? ? ? f0 �� a′1 g′1 ��? ? ? ? ? ? ? f1 �� a′2 f2 �� g′2 wwoo oo o oo oo oo o oo o a′3 f3 �� a0 h1 wwoo oo oo oo oo oo oo o h2 ��@ @ @ @ @ @ @ @ a1 g1 a a a a a a a a2 g2 wwnn nn nn nn nn nn nn n a3 the key idea to show that attgraphs is adhesive hlr is the choice of the right kind of mmorphisms. actually, attgraphs is not adhesive1 because it fails to satisfy the van kampen property for arbitrary monomorphisms. theorem 1 attgraphs is adhesive hlr, with respect to the class of m-morphisms consisting of all monomorphisms 〈hgraph, halg〉 such that halg is an isomorphism. 3 the category of symbolic graphs a symbolic graph can be seen as the specification of an attributed graph (or of a class of attributed graphs). in particular, a symbolic graph consists of an e-graph g whose labels are variables, together with a set of formulas φ that constrain the possible values of these variables. in this sense, we consider that a symbolic graph denotes the class of all attributed graphs where the variables in the e-graph have been replaced for values that make φ true in the given data domain. for instance, below on the right, we can see an example of a very simple symbolic graph and, on the left, the (unique) attributed graph denoted by that symbolic graph. 27 45 3712 15 18 x y zd1 d2 d3 with (x = 27)∧(y = 45)∧z = 37 ∧ (d1 = 12)∧(d2 = 15)∧(d3 = 18) however, as said above, a symbolic graph, in general denotes a class of graphs. for instance, the graph below specifies a class of attributed graphs that includes the graph depicted above on the left, but it also specifies many other graphs. 1 roughly speaking, an adhesive category [13] is like an adhesive hlr category, where m is the class of all monomorphisms 7 / 25 volume 30 (2010) symbolic attributed graphs x y zd1 d2 d3 with d3 ≤ d1 + d2 it may be noted that the class of attributed graphs denoted by a symbolic graph may be empty if the associated condition is unsatisfiable. therefore, let us define what is a symbolic graph over a given data algebra. definition 7 (symbolic graphs and morphisms) a symbolic graph over the data σ-algebra d, with σ = (s, ω), is a pair 〈g, φ〉, where g is an e-graph over an s-sorted set of variables x = {xs}s∈s, i.e. lg = ∪s∈sxs, and φ is a set of first-order σ-formulas built over the free variables in x and including the elements in d as constants. given symbolic graphs 〈g1, φ1〉 and 〈g2, φ2〉 over the same data algebra d, a symbolic graph morphism h : 〈g1, φ1〉→〈g2, φ2〉 is an e-graph morphism h : g1 → g2 such that d |= φ2 ⇒ h#(φ1), where h#(φ1) is the set of formulas obtained when replacing in φ1 every variable x1 in the set of labels of g1 by hl(x1). symbolic graphs over d together with their morphisms form the category symbgraphsd. in what follows, to simplify notation, even if it may be considered an abuse of notation, we will write h(φ) instead of h#(φ). moreover, also for simplicity, we may identify the set of formulas φ with the formula consisting of the conjunction of all the formulas in φ, even if that formula may be infinitary in the case where φ is an infinite set. notice that, according to the above definition, given any e-graph g, if d |= φ ⇔ φ′ then 〈g, φ〉 and 〈g, φ′〉 are isomorphic in symbgraphsd. to show that symbolic graphs are an adhesive hlr category, first, we have to define our notion of m-morphism over symbolic graphs. we consider that m-morphisms are monomorphisms where the formulas constraining the source and target graphs are equivalent (in most cases they will just be the same formula). the intuition of this definition is based on the use of our category of symbolic graphs to define graph transformation. more precisely, we think that the most reasonable formulation of graph transformation rules in our context is based on defining a graph transformation rule as an e-graph transformation rule, together with a set of formulas that globally constrain and relate all the variables in the rule. this is equivalent to consider that the left and right-hand sides (and also the interface) of a rule are constrained by the same set of formulas. definition 8 (m-morphisms) an m-morphism h : 〈g, φ〉→〈g′, φ′〉 is a monomorphism such that lg ∼= lg′, i.e. hl is a bijection, and d |= h(φ) ⇔ φ′. it is not difficult to see that m-morphisms satisfy the required properties. then, to define pushouts and pullbacks in symbgraphsd we use pushouts and pullbacks in e−graphs, respectively. more precisely, the pushout of 〈g1, φ1〉 h1 ←〈g0, φ0〉 h2 →〈g2, φ2〉 is a graph 〈g3, φ3〉, where g1 g1 → g3 g2 ← g2 is the pushout of g1 h1 ← g0 h1 → g2 and φ3 is the conjunction of g1(φ1) and g2(φ2). the case of pullbacks is similar, but the pullback of 〈g1, φ1〉 g1 →〈g3, φ3〉 g2 ←〈g2, φ2〉 is the graph 〈g0, φ0〉, where g1 h1 ← g0 h2 → g2 is the pullback of g1 g1 → g3 g2 ← g2 and φ0 is the proc. gramot 2010 8 / 25 eceasst disjunction of h1(φ1) and h2(φ2). however, since g0 may include a strict subset of the variables of φ1 and φ2, in this case φ0 is existentially quantified by the variables not in g0. proposition 1 symbgraphsd has pushouts and pullbacks. to see that pushouts and pullbacks preserve m-morphisms we just have to do some basic logical deduction. if the diagram below is a pushout and h1 is an m-morphism then we have to prove that d |= φ2 ⇔ (g2(φ2)∧g1(φ1)). but, since h1 is an m-morphism we may consider without loss of generality that h1 is the equality on variables and φ0 = φ1. moreover, we may also consider without loss of generality that g2 is also the equality on variables and that h2 and g1 coincide when restricted to the variables. as a consequence, what we would need to prove is that d |= φ2 ⇔ (φ2 ∧h2(φ0)), since g2(φ2) = φ2 and h2(φ0) = g1(φ1). but this is obvious, since we know that d |= φ2 ⇐ h2(φ0). the case of pullbacks is slightly more complex because of the existential quantifiers in φ0. 〈g0, φ0〉 h1 // h2 �� 〈g1, φ1〉 g1 �� 〈g2, φ2〉 g2 // 〈g3, φ3〉 proposition 2 pushouts and pullbacks preserve m-morphisms. finally, to prove the van kampen property we show that a cube in symbgraphsd is a van kampen square if and only if the underlying cube in e−graphs is also a van kampen square. to do this, again we just need to do some basic logical reasoning. as a consequence we have: theorem 2 symbgraphsd is adhesive hlr. 4 symbolic graphs and attributed graphs in this section we present the relation between the categories of symbolic and attributed graphs over a given data algebra. on one hand, we will see that every symbolic graph may be seen as denoting a class (a subcategory) of attributed graphs, which may be considered its semantics. on the other hand, we will see that every attributed graph can be represented in a canonical way by a symbolic graph, which means that, for a given data algebra, the category of attributed graphs can be seen as a subcategory of the corresponding category of symbolic graphs. definition 9 (semantics of symbolic graphs) given a symbolic graph 〈g, φ〉 over a data algebra d, its semantics is a class of attributed graphs defined as follows: sem(〈g, φ〉) = {〈σ (g), d〉 | σ : lg → d and d |= σ (φ)} where σ (g) denotes the graph obtained according to def. 2. for example, given the symbolic graph below: 9 / 25 volume 30 (2010) symbolic attributed graphs x y zd1 d2 d3 with d3 ≤ d1 + d2 we have that its semantics would include the following attributed graphs: 27 45 3712 15 18 6 7 88 25 4 conversely, we can identify every attributed graph ag with a grounded symbolic graph whose semantics consists only of ag. more precisely a grounded graph is a symbolic graph 〈g, φ〉 that includes a variable xv for each element v of the data algebra and where the only substitution σ : lg → d such that d |= σ (φ) is defined for each variable xv as σ (xv) = v. definition 10 (grounded symbolic graphs) a symbolic graph 〈g, φ〉 over a data algebra d is grounded if 1. lg includes a variable, which we denote by xv, for each value v ∈ d, and 2. for every substitution σ : lg → d, such that d |= σ (φ), we have σ (xv) = v, for each variable xv ∈ lg. moreover, we define gsymbgraphsd as the full subcategory of symbgraphsd consisting of all grounded graphs. notice that if 〈g, φ〉 is grounded and σ : lg → d is a substitution such that d |= σ (φ) then σ∗ : g → σ (g) is an isomorphism. it should be obvious that the semantics of a grounded graph includes exactly one attributed graph, and that grounded graphs are closed up to isomorphism. moreover, we can see that for every attributed graph ag there is a unique grounded symbolic graph (up to isomorphism) gsg(ag) such that sem(gsg(ag)) consists of ag. in particular, the e-graph associated to gsg(ag) is obtained substituting every data value v in a set of labels by a variable xv, and the set of formulas in the symbolic graph consists of an equation xv = v, for each value v in d. definition 11 given an attributed graph ag = 〈g, d〉, we define the grounded symbolic graph associated to ag, gsg(ag) as the symbolic graph 〈g′, φ〉, where: • the set of labels x of the e-graph g′ consists of a variable xv for each element v ∈ d. • g′ = f∗(g), where f : d → x is a substitution such that for every v ∈ d, f (v) = xv. • φ = {xv = v | v ∈ d}. proposition 3 1. if sg is grounded then sem(sg) consists exactly of one attributed graph. proc. gramot 2010 10 / 25 eceasst 2. grounded symbolic graphs are closed up to isomorphism. 3. for each attributed graph ag = 〈g, d〉, sem(gsg(ag)) = {ag}. proof. 1. if sg = 〈g, φ〉 is grounded, by definition we know that sem(sg) is not empty, since φ is satisfiable in d. moreover, if ag1, ag2 ∈ sem(〈g, φ〉) then this means that there are substitutions σ , σ ′ : lg → d such that d |= σ (φ) and d |= σ ′(φ). but if 〈g, φ〉 is grounded this means that lg = {xv | v ∈ d} and for each v ∈ d: σ (xv) = v and σ ′(xv) = v. but this implies that σ = σ ′ and therefore ag1 = ag2. 2. let sg = 〈g, φ〉 be a grounded graph and let sg′ = 〈g′, φ′〉 be isomorphic to sg. this means that there is an e-graph isomorphism h : g → g′ such that d |= φ ⇔ h(φ′). but this implies that hl : lg → lg′ is a bijection and if σ ′ : lg′ → d is a substitution such that d |= σ ′(φ′) then σ ′◦h : lg → d is a substitution such that d |= σ ′◦h(φ), and this means that for every v ∈ d σ ′◦h(xv) = v. therefore, if for every v ∈ d we call yv the variable h(xv) then we have that, for each v ∈ d, σ ′(yv) = v, which means that sg′ is grounded. 3. it should be obvious that, by construction, gsg(ag) is grounded and, moreover, ag ∈ sem(gsg(ag)). now, suppose that sg0 = 〈g0, φ0〉 is a symbolic graph such that ag =〈g, d〉∈ sem(sg). let us prove that sg and gsg(ag) = 〈g′, φag〉 are isomorphic. first of all, we know that g = σ∗0 (g0) for a substitution σ0 such that d |= σ0(φ0). but, since sg0 is grounded, σ ∗ 0 is an isomorphism. for similar reasons, we know that f∗ : g → g′ is also an isomorphism therefore f∗◦σ∗0 : g0 → g ′ is an e-graph isomorphism. finally, it is easy to see that d |= φ ⇔ f ◦σ0(φ0). in particular, if σ is a substitution such that d |= σ (φ) we have to prove that d |= σ ◦ f ◦σ0(φ0) or, equivalently, that σ ◦ f ◦σ0 = σ0. but this is obvious since, on one hand, by construction, v∈d: f (v) = xv, and, on the other hand, we know that for every v ∈ d: σ (xv) = v, which means that f = σ−1. conversely, if σ is a substitution such that d |= σ ◦ f ◦σ0(φ0) we can prove similarly that this implies that d |= σ (φ). it should also be obvious that the encoding of attributed graphs in terms of symbolic graphs defined by gsg can be applied to all kinds of attributed graphs, i.e. not only to attributed graphs defined over a data algebra d, but also to term-attributed graphs or to term-attributed graphs defined over a specification sp. however, in the latter case, we prefer to define a different encoding which may actually be seen as a variation of gsg, that we call its symbolic representation, denoted sr, and which will be used in the following section. in particular, if g is a term-attributed graph defined over a specification sp, we define sr(g) as follows. first, we assume that we have a function that chooses a term from every congruence class of terms in tsp. we call this function a choice function. then, the symbolic representation of g would be 〈g′, φ′〉, where g′ is obtained replacing each label a in g (i.e. each congruence class in tsp) by the variable xt , where t is the term chosen by the choice function when applied to a, and where φ′ consists of all the equations in sp and all the equations xt = t for each term t returned by the choice function. 11 / 25 volume 30 (2010) symbolic attributed graphs definition 12 given a specification sp = (σ∪x , φ), such that there is an initial algebra tsp in the category of sp-algebras, we say that ch : tsp → tς∪x is a choice function for tsp if for every element |t′|∈ tsp if ch(t) = t ′ then tsp |= t = t ′, where |t′| denotes the congruence class of t′ with respect to the congruence defined by sp. given sp, an attributed graph ag = 〈g, tsp|σ〉, and a choice function ch for tsp we define the symbolic representation of ag with respect to ch, srch(ag) as the symbolic graph 〈g ′, φ′〉, where: • the set of labels of the e-graph g′ is x ∪y , where y is disjoint with x and it consists of a variable ych(a) for each element a ∈ tsp such that a /∈{|x| | x ∈ x}. • g′ = f∗(g), where f : tsp → y is a substitution such that for every a ∈ tsp, if a /∈{|x| | x ∈ x} then f (a) = ych(a). otherwise, f (|x|) = x. • φ′ = φ∪{ych(a) = t | ych(a) ∈y ∧ch(a) = t}. this means that g′ includes as labels the variables in x and a variable ya for every element a in tsp which is not the congruence class of a variable in x . this means that the substitution f is a bijection. as a consequence, for every attributed graph ag = 〈g, tsp|σ〉, if srch(ag) = 〈g ′, φ′〉 then g and g′ are isomorphic e-graphs. it may be noted that we have not stated over which algebra d the symbolic graph srch(ag) is defined. the reason is that we may consider that srch(ag) is a symbolic graph over any σ-algebra d. anyhow, if we consider that srch(ag) is defined over tsp|σ then srch(ag) is a grounded graph in symbgraphstsp|σ , i.e. srch(ag) is an object in gsymbgraphstsp|σ . this means that, following proposition 3, srch(ag) and gsg(ag) are isomorphic graphs in symbgraphstsp|σ . according to proposition 3, we can identify each attributed graph with a grounded symbolic graph, and vice versa. therefore, we may ask whether attgraphsd is isomorphic to gsymbgraphsd. the answer is negative since gsg cannot be made injective on morphisms as the following counter-example shows. example 1 let d be a data algebra consisting of two values of the same sort, which we call a and b. let ag be an attributed graph having no graph nodes and no graph edges (i.e. the graph structure of ag is empty, which means that it consists only of the label nodes a and b). as a consequence, gsg(ag) = 〈g, xa = a∧xb = b〉, where g is an e-graph consisting only of the label nodes xa and xb. now, there are four morphisms, f1, f2, f3 and f4, from ag to itself: • f1(a) = a, f1(b) = b. • f2(a) = a, f2(b) = a. • f3(a) = b, f3(b) = b. • f4(a) = b, f4(b) = a. however the only morphism from gsg(ag) to itself is the identity. for example we may see that the mapping g : {xa, xb}→{xa, xb}, defined g(xa) = xa, g(xb) = xa, does not define a proc. gramot 2010 12 / 25 eceasst symbolic graph morphism. in particular, if g is a morphism it should hold that d |= (xa = a∧xb = b) ⇒ g(xa = a∧xb = b). but this is equivalent to d |= (xa = a∧xb = b) ⇒ (xa = a∧xa = b), which is obviously false. the problem in the above counter-example is that we assume that we can define any mapping between the elements of the algebra, while for the variables of the grounded graphs we are forced to map the variable xv associated to a value to the corresponding variable associated to the same value. this problem disappears if the value algebra is finitely generated. in that case, we know that the only homomorphism of an algebra into itself is the identity causing that morphisms on attributed graphs should be the identity on data values. this means that, if d is finitely generated then the categories attgraphsd and gsymbgraphsd are equivalent. moreover, this kind of restriction is quite reasonable since, otherwise, the algebra would include values which we cannot refer to. nevertheless, as we will see in the following section, attributed graph transformation rules are usually defined over non-finitely generated algebras. proposition 4 if d is finitely generated then attgraphsd and gsymbgraphsd are equivalent. proof. first, we will show that gsg can be extended to a functor and, then, that gsg is full, faithful and essentially surjective. let f : 〈g1, d〉→〈g2, d〉 be an attributed graph morphism. since d is finitely generated, falg is the identity and fgraph is an e-graph morphism. hence, if f : d → xd is a substitution defined for every v ∈ d as f (v) = xv, and φ = {xv = v | v ∈ d} we know that gsg(〈g1, d〉) = 〈 f (g1), φ〉 to gsg(〈g2, d〉) = 〈 f (g2), φ〉. we define gsg( f ) as follows: • for every x ∈{vg, eg, enl, ee l}: gsg( f )x = fx. • gsg( f )l is the identity. then, it is routine to prove that gsg( f ) is indeed a symbolic graph morphism. to prove that gsg is full, we have to show that if ag1 = 〈g1, d〉 and ag2 = 〈g2, d〉 are two attributed graphs and h : gsg(ag1) → gsg(ag2) is a symbolic graph morphism then there exists an attributed graph morphism f : ag1 → ag2 such that gsg( f ) = h. but it is enough to define f as follows: • for every x ∈{vg, eg, enl, ee l}: fx = hx. • falg (and, therefore, fl) is the identity. to prove that gsg is faithful we have to show that gsg is injective on morphisms, but this is straightforward by construction. finally, to prove that gsg is essentially surjective, we have to show that for every grounded graph sg there is another grounded graph sg′, which is isomorphic to sg, and an attributed graph ag such that gsg(ag) = sg′. but by prop 3 we know that sem(sg) is not empty and that if ag ∈ sem(sg) satisfies that gsg(ag) = sg. 13 / 25 volume 30 (2010) symbolic attributed graphs 5 symbolic graph transformation and attributed graph transformation in this section we compare attributed graph transformation with symbolic graph transformation. this comparison may seem trivial: if attributed graphs may be seen as a special case of symbolic graphs then we can conclude that attributed graph transformation is a special case of symbolic graph transformation. however things are not so obvious. as we have seen, if the given data algebra d is finitely generated, we can identify attributed graphs over d with grounded symbolic graphs over d. this means, in that case, that if transformation rules are spans of m-morphisms in attgraphsd then these transformation rules can be considered equivalent to spans of mmorphisms in gsymbgraphsd, and the application of these rules to a graph ag in attgraphsd is equivalent to the transformation of gsg(ag) by the corresponding rules in gsymbgraphsd. the problem is that if the graphs that we want to transform are in attgraphsd, usually, the transformation rules will not be spans of m-morphisms in attgraphsd, but in attgraphsd′, where d′ is some free algebra over d and, hence, different from d. that is, typically, transformation rules over attributed graphs are defined using term attributed graphs. in order to compare attributed and symbolic graph transformation we start giving an example of symbolic graph transformation rules and symbolic graph transformation. example 2 let us suppose that we are dealing with a class of graphs whose edges have an attribute that represents the distance between the source and target nodes. for instance, the graph g0 below may be an example of a graph in this class: a b c d 10 20 10 15 30 more precisely, let us consider that the underlying algebra in this class of graphs is the algebra d of natural numbers, defined over the signature σ: sorts nat, bool opns 0 : nat suc : nat → nat true, f alse : bool + : nat ×nat → nat ≤: nat ×nat → bool we can see the above graph as a grounded symbolic graph. in this case we would need to replace the values which are bound to the edges of the graph by the variables x10, x15, x20, and x30, respectively, and we would need to include the formula (x0 = 0)∧(x1 = 1)∧(x2 = 2)∧···∧(x10 = 10)∧···∧(x15 = 15)∧···∧(x20 = 20)∧···∧(x30 = 30)∧ . . . . however, since proc. gramot 2010 14 / 25 eceasst we know that grounded symbolic graphs and attributed graphs are equivalent, for readability, we will directly use the attributed graph representation. let us also suppose that we want to compute the distance of the shortest paths between any two nodes. the symbolic graph transformation rule p, depicted below, describes how a new distance can be computed: d1 d2 l 1 2 3 1 2 3 1 2 3 d1 d2 k with d3 = d1 + d2 d3 d1 d2 r if we match 1 with d, 2 with c, and 3 with b, and the variables d1, d2, and d3 with 10, 15, and 25, respectively2 , then we can apply this rule to the above graph, because 25 = 10 + 15 holds in d3, which is the translation of the rule condition, when d1, d2, and d3 are replaced by their corresponding matches. therefore, we would transform g0 into g1: a b c d 10 20 10 15 25 30 similarly, matching 1 with a, 3 with b, and 2 with c, and the variables d1, d2, and d3 with 10, 15, and 25, respectively, as before, it would be possible to apply the above transformation rule, getting the graph g2: a b c d 10 20 10 15 25 30 25 2 to be more precise, we would match d1, d2, and d3 with the variables x10, x15, and x25, respectively. 3 again, to be more precise, the condition that holds is (x10 = 10)∧(x15 = 15)∧(x25 = 25)∧ . . . implies (x25 = x10 + x25) 15 / 25 volume 30 (2010) symbolic attributed graphs now, if we want to get rid of all the edges between two given nodes, except of the one labelled with the smallest distance, we could use the rule p′ depicted below4: d1 d2 l′ d1 1 2 1 2 1 2 k′ with (x1 ≤ x2) = true d1 r′ we can apply the above rule to the graph g2, matching nodes 1 and 2 to nodes a and c, and variables d1 and d2 to 25 and 30, respectively, and also matching the edges bound to the former variables to the corresponding edges in g2 bound to 25 and 30. the result would be g3: a b c d 10 20 10 15 25 25 remark 1 obviously, symbolic graph transformation rules may be applied not only to grounded symbolic graphs, but to arbitrary symbolic graphs. actually, the fact that the category of symbolic graphs is adhesive hlr ensures that the fundamental theory of graph transformation [4] applies to symbolic graph transformation. however, in practice, it may be impossible to apply a graph transformation rule to an arbitrary symbolic graph, even if seems very reasonable. for instance, we may expect that it should be possible to apply the rule p, depicted above, to the symbolic graph g depicted below on the left, yielding the graph on the right: x y 1 2 3 with x < y x y z 1 2 3 with x < y∧z = x + y however, this is not possible. the first problem we find to apply the rule p to g is that if g only includes the variables x and y then the variable d3 in the rule could only be matched 4 a different alternative for the same problem would be to use some nacs in the first rule to avoid creating more than one edge between any two nodes proc. gramot 2010 16 / 25 eceasst to x or y. moreover, it would be unclear where do the variable z in g′ comes from. we can overcome this problem by assuming that g already included the variable z, although it was not explicitly depicted because it was not bounded to any node or edge in g. actually, we could think that a symbolic graph is supplied with an unlimited number of variables. however this is not the main problem. we cannot apply p to g because x < y does not imply z = x + y in d. this problem is solved in [18], where a new form of symbolic graph transformation, called lazy graph transformation, is studied. more precisely, using lazy graph transformation, g′ would be obtained applying p to g in the obvious way. now, let us describe how we can define attributed graph transformation rules having a similar effect to the symbolic rules in example 2. example 3 let us suppose that we want to describe the same procedure as in example 2 for computing shortest paths, but now using attributed graph transformation rules. in this case, rule p for computing a new distance between two nodes could be: d1 d2 l 1 2 3 1 2 3 1 2 3 d1 d2 k d1 + d2 d1 d2 r the first thing that we should note is that the graphs g0, g1, g2 and g3 in example 2 are defined over the algebra d of natural numbers, which means that they include the natural numbers and the booleans as label nodes, even if they are not depicted in the above figures. but the graphs l, k, and r in the transformation rule p are not defined over the same algebra. the reason is that the labels d1, d2, or d1 + d2 are not in d, since they are not natural numbers. the simplest solution that we can use here, is to consider that l, k, and r are term-attributed graphs over the algebra tς({d1, d2}), i.e. the term algebra over the variables d1 and d2. these graphs would include as label nodes all the possible σ-terms over these two variables, even if they are not depicted explicitly. now, according to the example, when we apply p to g0 in example 2 we define a morphism m from l into g matching 1 with d, 2 with c, and 3 with b. obviously, m would also match the edges in l with the edges in g in the expected way and it would also match d1 with 10 and d2 with 15. but this is not all. the match m includes a σ-homomorphism malg from tς({d1, d2}) to d matching not only d1 with 10 and d2 with 15, but also each possible term over d1 and d2 with its corresponding value, after assigning to d1 and d2 the values 10 and 15, respectively. this means that, for instance, m would also match suc(d1) with 11 or suc(d1) ≤ suc(suc(d2 )) to t. in particular, m would also match d1 + d2 with 25, even if d1 + d2 is not explicitly depicted in l, i.e. we need to compute the resulting value of d1 + d2 when defining the match, before computing the transformation. the fact that the values of the underlying algebra are considered (label) nodes of the attributed 17 / 25 volume 30 (2010) symbolic attributed graphs graphs, together with the fact that match morphisms must be homomorphisms for the algebra part, allow us to do some kind of conditional graph transformation without using a negative application condition (nac) [3, 9], but using term-attributed graphs over a given specification, as discussed in section 2.3. for example, we can have an attributed graph transformation rule p′′, similar to rule p′ in example 2, for deleting all edges between two nodes except the one labelled with the shortest distance. in particular, p′′, could be the rule below: d1 d2 l′ d1 k′ 1 2 1 2 1 2 d1 r′ when defined over the algebra tsp|σ, where sp is defined: sp = sorts nat, bool opns 0 : nat d1, d2 : nat suc : nat → nat true, f alse : bool + : nat ×nat → nat ≤: nat ×nat → bool axms (d1 ≤ d2) = true for instance the application of p′′ to the graph g2 in example 2 matching node 1 to node a and node 2 to node c would necessarily match d1 to 25 and d2 to 30 yielding the graph g3, also in example 2. therefore, we can consider that, in a transformation system for attributed graphs over a σalgebra d, each rule r is a span on the category attgraphsdr , where dr = tspr|σ and spr is a specification spr = (σr, φr), such that σr = σ∪x and φr is a set of σr-equations or conditional equations, since this ensures the existence of initial algebras. under this assumption, we may see that attributed graph transformation systems can be seen as a special case of symbolic graph transformation system. the idea is that every rule r as above can be represented by a symbolic transformation rule r′, using the symbolic representation of the graphs in r. more precisely: definition 13 given a specification sp = (σ∪x , φ), such that there is an initial algebra tsp, a choice function ch for tsp, and an attributed graph transformation rule r = (〈l, tsp|σ〉 ←֓ 〈k, tsp|σ〉 →֒ 〈r, tsp|σ〉), we define the symbolic representation of r with respect to ch, srch(r) as the symbolic transformation rule r′ = 〈l′ ←֓ k′ →֒ r′, φ′〉 where: • 〈l′, φ′〉 = srch(〈l, tsp|σ〉), proc. gramot 2010 18 / 25 eceasst • 〈k′, φ′〉 = srch(〈k, tsp|σ〉), • 〈r′, φ′〉 = srch(〈r, tsp|σ〉). remark 2 the inclusions k′ ⊆ l′ and k′ ⊆ r′ are a consequence, first, of the fact that we assume that k ⊆ l and k ⊆ r5; second, of the definition of how a label substitution is applied to an e-graph; and third of the fact that the use of the choice function ensures that the substitution of values in tsp|σ by variables in y is the same on the three graphs l ′, r′, and k′. moreover, it may be noticed that, by definition of the choice functions, diagrams (1), (2), (3), and (4) below are pushouts, where f∗l , f ∗ k , and f ∗ r are, respectively, the isomorphisms relating l, k, and r with l′, k′, and r′, and where f∗−1l , f ∗−1 k , and f ∗−1 r are their inverses: l (1)f∗l �� k (2) ? _oo � � // f∗k �� r f∗r �� l′ (3)f∗−1l �� k′ (4) ? _oo � � // f∗−1k �� r′ f∗−1r �� l′ k′? _oo � � // r′ l k? _oo � � // r theorem 3 let r = (al ← ak → ar) be an attributed graph transformation rule, where al, ak, and ar are attributed graphs over tsp|σ and sp = (σ∪x , φ), let ch be a choice function for tsp, and let r ′ = srch(r), then for every attributed graph ag = 〈g, d〉 and every morphism m : al → ag there is a morphism m′ : 〈srch(al), φ′〉→ gsg(ag) such that ag is transformed into ah by r with match m, i.e. ag⇒mr ah , if and only if gsg(ag)⇒ m′ r′ gsg(ah). conversely, for every morphism m′ : 〈srch(al), φ′〉→ gsg(ag) there is a morphism m : al → ag such that gsg(ag) ⇒m ′ r′ gsg(ah) if and only if ag ⇒ m r ah . proof. let us assume that al = 〈l, tsp|σ〉, ak = 〈k, tsp|σ〉, ar = 〈r, tsp|σ〉), and r ′ = 〈l′ ←֓ k′ →֒ r′, φ′〉, and let us consider the following diagram in e−graphs: l′ (3)f∗−1l �� k′ (4) ? _oo � � // f∗−1k �� r′ f∗−1r �� l (5)m �� k (6) ? _oo � � // �� r �� g (7)g∗l �� i (8) ? _ h1 oo � � h2 // g∗k �� h g∗r �� g′ i′? _ h′1 oo � � h′2 // h′ where (5) and (6) are the pushouts defining the application of r to ag with match m, 〈g′, ψ〉 = gsg(ag),〈i′, ψ〉 = gsg(〈i, tsp|σ〉), 〈h′, ψ〉 = gsg(〈h, tsp|σ〉), g∗l, g ∗ k , g ∗ r are, respectively, the isomorphisms relating g, i, h with g′, i′, h′, and finally the morphisms h′i, for i = 1, 2 are 5 since the morphisms relating l and r are m-morphisms, without loss of generality, we may assume that they are the identity on the algebra part and an inclusion on the graph part 19 / 25 volume 30 (2010) symbolic attributed graphs defined as follows. for every element e ∈ i′ which is not a label, h′i(e) = hi(e), and for every label e, h′i(e) = e. it is routine to see that, by definition of gsg and as a consequence of the fact that h1 and h2 are m-morphisms, h ′ 1 and h ′ 2 are morphisms and, moreover, diagrams (7) and (8) not only commute but are pushouts. therefore, since we know that diagrams (3) and (4) are pushouts, then diagrams (3)+(5)+(7) and (4)+(6)+(8) are also pushouts. therefore, if we define m′ = g∗l ◦m◦ f ∗−1 l and we show that m ′ is a morphism in symbgraphsd the first part of the theorem will be proved. therefore, we have to prove that d |= ψ ⇒ m′(φ′). we now that φ′ = φ∪{ya = t | ya ∈y ∧ch(a) = t} and ψ = {xv = v | v ∈ d} we also know that the only substitution σ such that d |= σ (ψ) is defined ∀v ∈ d : σ (xv) = v. therefore, we have to show that d |= σ (m′(φ′)) or, equivalently, d |= σ (m′(φ)) and d |= σ (m′({ye = t | ye ∈ y ∧ch(e) = t})). finally, by definition, on the one hand, we have that for every a ∈ tsp|σ we have m ′(ya) = xv, where m(a) = v, which means that σ (m′(ya)) = m(a), and on the other hand, for each x ∈ x , σ (m′(x)) = m(x). now, let t1 = t2 be an equation in φ. since malg is a σ-homomorphism and tsp satisfies this equation, we have that d |= m(t1) = m(t2), implying d |= σ (m′(t1)) = σ (m′(t2)). let ya = t and ch(a) = t. then, on the one hand, we have that σ (m′(ya)) = m(a) and, on the other, since ch(a) = t we have that in a = |t|, implying σ (m′(t)) = m(a). therefore, σ (m′(ya)) = σ (m′(t)). the proof of the second part of the theorem is similar to the proof of the first part. we only have to consider the diagram below: l (1)f∗l �� k (2) ? _oo � � // f∗k �� r f∗r �� l′ (9)m′ �� k′ (10) ? _oo � � // �� r′ �� g′ (11)g∗−1l �� i′ (12) ? _ h′1 oo � � h′2 // g∗−1k �� h′ g∗−1r �� g i? _ h1 oo � � h2 // h the theorem above shows that attributed graph transformation can be seen as a special case of symbolic graph transformation. one may wonder whether both kind of transformations can be considered equivalent in the sense that every symbolic graph transformation rule r can be coded into an attributed graph transformation rule r′ such that the application of r to a grounded graph produces the same effect as the application of r′ to the corresponding attributed graph. the answer is negative as the counter-example below shows, which means that symbolic transformation rules have more definitional power than attributed graph transformation rules. proc. gramot 2010 20 / 25 eceasst example 4 let us suppose that the following symbolic graph sg is the left-hand side of a symbolic graph transformation rule r: x y with (x = 0)∨(y = 0)∨(x = y) where the signature of the data domain is: sorts nat opns 0 : nat suc : nat → nat and where the given data algebra d is the algebra of natural numbers. this means that, if r could be represented by an attributed graph transformation rule r′, then r′ would include as a left-hand side an attributed graph ag like: a1 a2 where a1 and a2 are elements of some σ-algebra a. moreover, there should exist a match m from sg into any grounded symbolic graph sg′ if and only if there exists an equivalent match m′ from ag into the corresponding attributed graph. in particular, given the symbolic graph: x y with (x = n1)∧(y = n2) where n1 and n2 are two natural numbers, there should exist a homomorphism from a to d mapping a1 to n1 and a2 to n2 if and only if n1 = 0 or n2 = 0 or n1 = n2. let us see that this is impossible. in particular, first, we will see that a1 and a2 cannot be the value of a ground term (i.e. they cannot be obtained applying the suc operation some number of times to 0. then, we will see that neither a1 nor a2 can be obtained applying any number of times the suc operation to some other value in the algebra. but, then this means that we can match a1 and a2 to any pair of natural numbers, which implies that for instance we can match a1 to 2 and a2 to 1, violating the condition in the symbolic graph. first, we may notice that we may assume without loss of generality that a satisfies the axiom: e : suc(x) = suc(y) ⇒ x = y since for every homomorphism h : a → d there is a unique homomorphism h′ : a/ ≡e→ d such that the diagram below commutes: a i �� h // d a/ ≡e h′ 77 ooooooooooooo 21 / 25 volume 30 (2010) symbolic attributed graphs where ≡e is the congruence on a defined by the axiom e and i is the canonical homomorphism from a into its quotient, mapping every element from a into its congruence class. vice versa, for every homomorphism h′ : a/ ≡e→ d there is a unique homomorphism h : a → d such that the diagram above commutes. finally, we know that h(a1) = 0 or h(a2) = 0 or h(a1) = h(a2) if and only if h′(|a1|) = 0 or h ′(|a2|) = 0 or h ′(|a1|) = h ′(|a2|). therefore, let us assume that a satisfies the above axiom. now, let us notice that neither a1 nor a2 can be the value of some ground term suc n(0), for 0 ≤ n. the reason is that, otherwise, if n1 = n2 6= n the match would be impossible. we can also see that it is not possible that a1 is the value of some term sucn(a0), for 1 ≤ n and any a0 ∈ a. otherwise, if n1 = 0 the match would be impossible, against the assumption, since if the match m′ satisfies m′(a0) = n0 then m ′(a1) would be n + n0. for similar reasons, we know that it is not possible that a2 is the value of some term sucn(a0), for 1 ≤ n and any a0 ∈ a. as a consequence, we can see that a′ = a\{a | (a = sucna(a1))∨(a = suc n a(a2)) for some n ≥ 0} is a subalgebra of a. suppose, otherwise, that a′ is not a subalgebra of a. this would mean that there is an element a′ ∈ a′ such that suca(a ′) ∈ a\a′. but this would mean that suca(a ′) = sucna(a1) or suca(a ′) = sucna(a2). but this would imply one of the following cases: 1. suca(a ′) = a1 or suca(a ′) = a2. these two cases are impossible according to what we have proved above. 2. suca(a ′) = sucna(a1) or suca(a ′) = sucna(a2) for n ≥ 1. however, since a is assumed to satisfy the axiom e, this means that a′ = sucn−1a (a1) or a ′ = sucn−1a (a2), implying that a′ ∈ a\a′, against the hypothesis. as a consequence of the previous facts we know that every homomorphism h : a → d is uniquely determined by a homomorphism h′ : a′ → d and by the values of h(a1) and h(a2), in the sense that given h′, there is a unique h extending h′ satisfying h(a1) = n1 and h(a2) = n2, for any n1, n2 ∈ d, and vice versa. but this implies that there is a morphism m ′ : a → d satisfying m′(a1) 6= m ′(a2). in general, a symbolic transformation rule r′ = 〈l′ ←֓ k′ →֒ r′, φ′〉 over a σ-algebra d can be simulated by an attributed graph transformation rule r = (al ← ak → ar) over a σ-algebra a, if the specification sp, whose signature is σ plus the labels in r′ (considered as constants), and whose set of axioms is φ′, has an initial algebra tsp. the problem in the previous counterexample is that the associated specification has no initial algebra. in particular, to ensure the existence of initial algebras φ′ should include only equations and conditional equations. 6 related work and conclusion in this paper we have presented a new approach to deal with attributed graphs based on the new notion of symbolic graphs, showing that the new category is adhesive hlr, which means that it is adequate to define graph transformation. proc. gramot 2010 22 / 25 eceasst as far as we know, there are essentially three kinds of approaches to define attributed graphs and attributed graph transformation. first, we have the approaches [10, 7] where an attributed graph is a pair (g, d) consisting of a graph g and a data algebra d whose values are nodes in g. second, we have the approaches [12, 1] where attributed graphs are seen as algebras over a given signature asig, where asig is the union of two signatures assig, the graph signature and dsig, the data signature, that overlap in the value sorts. in particular, assig may be seen as a representation of the graph part of an attributed graph. in [2] these two approaches are compared showing that they are, up to a certain point, equivalent. finally, we have the approach [19] based on the use of labelled graphs to represent attributed graphs, and of rule schemas to define graph transformations involving computations on the labels. that approach has some similarities with our approach, including the simplicity provided by the separation of the algebra and the graph part of attributed graphs. however, that approach has also some drawbacks that are briefly discussed in the introduction. however, a fundamental theory of graph transformation has been formulated only for [7], as a consequence of its characterization as an adhesive hlr category (for more detail see [4]). for this reason, in this paper we have essentially used that approach to study it in connection with our approach based on symbolic graphs. as we have seen, our approach can be considered an abstract version of [7], since we work at the specification level, rather than dealing directly with algebras to define the attributes. however, as we have shown, it has more expressive power than [7] for the definition of graph transformation rules. in addition to the expressive power, using symbolic attributed graphs has some other advantages. for instance, in [15] working with symbolic attributed graphs simplifies certain kinds of operations defined on transformation rules. for example, this is the case of the operation that, given two transformation rules r1 and r2, where r1 is a subrule of r2, yields a rule r3 that computes the remainder of r2 with respect to r1, i.e. what has not been computed by r1 but is computed by r2. in particular, when working with symbolic graphs the attribute conditions of r3 are just a simple combination of the attribute conditions of r1 and r2. however, if we would have worked with attributed graphs, computing the attributes for r3 may involve some complex equation solving. moreover, we think that there are further aspects related to symbolic graph transformations that deserve some further study. in particular, using logical conditions to specify the attributes of a graph may allow us to postpone finding the solution to attribute constraints when performing graph transformation. this can make attributed graph transformation more efficient. in addition, a generalization of this idea would allow us to define a certain form of narrowing that may be useful in connection to several kind of problems. bibliography [1] m. berthold, i. fischer, m.koch: attributed graph transformation with partial attribution. technical report 2000-2 (2000). [2] h. ehrig: attributed graphs and typing: relationship between different representations. bulletin of the eatcs 82: 175–190 (2004) 23 / 25 volume 30 (2010) symbolic attributed graphs [3] h. ehrig, a. habel: graph grammars with application conditions. in the book of l (grzegorz rozenberg and arto salomaa, eds.), springer (1986), 87–100. [4] hartmut ehrig, karsten ehrig, ulrike prange, gabriele taentzer: fundamentals of algebraic graph transformation, springer (2006). [5] hartmut ehrig, annegret habel, julia padberg, ulrike prange: adhesive high-level replacement categories and systems. in graph transformations, second international conference, icgt 2004. springer lecture notes in computer science 3256 (2004),144–160. [6] h. ehrig, b. mahr: fundamentals of algebraic specifications 1: equations and initial semantics. vol. 6 of eatcs monographs on theoretical computer science. springer, 1985. [7] h. ehrig, u. prange, g. taentzer: fundamental theory for typed attributed graph transformation. in graph transformations, second international conference, icgt 2004. springer lecture notes in computer science 3256 (2004), 161–177. [8] esther guerra, juan de lara, fernando orejas: pattern-based model-to-model transformation: handling attribute conditions. in theory and practice of model transformations, second international conference, icmt 2009, richard f. paige (ed.), springer lecture notes in computer science 5563 (2009), pp. 83–99. [9] a. habel, r. heckel, g. taentzer: graph grammars with negative application conditions. fundam. inform. 26(3/4): 287–313 (1996). [10] r. heckel, j. küster, g. taentzer: towards automatic translation of uml models into semantic domains. in proc. appligraph workshop on applied graph transformation 2002, pp. 11–22. [11] j. jaffar, m. maher, k. marriot, and p. stukey. the semantics of constraint logic programs. the journal of logic programming, (37):1–46, 1998. [12] m. löwe, m. korff, a. wagner: an algebraic framework for the transformation of attributed graphs. in term graph rewriting: theory and practice. john wiley and sons ltd. (1993) 185–199. [13] s. lack, p. sobocinski: adhesive categories. in foundations of software science and computation structures, 7th international conference, fossacs 2004 (igor walukiewicz, ed.), springer lecture notes in computer science 2987 (2004), 273–288. [14] p. lucio, f. orejas, e. pasarella and e. pino. a functorial framework for constraint normal logic programming. in algebra, meaning, and computation, essays dedicated to joseph a. goguen on the occasion of his 65th birthday, kokichi futatsugi, jean-pierre jouannaud, josé meseguer (eds.), springer-verlag lecture notes in computer science 4060 (2006), 555–577. [15] m. naeem, r. heckel, f. orejas, f. hermann, incremental service composition based on partial matching of visual contracts. in fundamental approaches to software engineering, proc. gramot 2010 24 / 25 eceasst 13th international conference, fase 2010, springer lecture notes in computer science 6013 (2010), 123–138. [16] f. orejas: attributed graph constraints. in graph transformations, 4th international conference, icgt 2008 (hartmut ehrig, reiko heckel, grzegorz rozenberg, gabriele taentzereds.), springer lecture notes in computer science 5214 (2008): 274–288. [17] f. orejas: attributed graph constraints for attributed graph transformation. journal of symbolic computation. to appear. [18] f. orejas, l. lambers: delaying constraint solving in symbolic graph transformation. to appear in icgt 2010. [19] d. plump, s. steinert: towards graph programs for graph algorithms. in graph transformations, second international conference, icgt 2004. springer lecture notes in computer science 3256 (2004), 128–143. [20] rozenberg, g. (ed.): handbook of graph grammars and computing by graph transformation, vol 1 foundations, world scientific, 1997. 25 / 25 volume 30 (2010) introduction preliminaries basic algebraic concepts and notation e-graphs attributed graphs the category of symbolic graphs symbolic graphs and attributed graphs symbolic graph transformation and attributed graph transformation related work and conclusion middleware for the internet of things, design goals and challengesthis work is partially funded by the safe-is project of the research foundation flanders and the moves project. electronic communications of the easst volume 28 (2010) proceedings of the third international discotec workshop on context-aware adaptation mechanisms for pervasive and ubiquitous services (campus 2010) middleware for the internet of things, design goals and challenges1 koosha paridel, engineer bainomugisha, yves vanrompay, yolande berbers, wolfgang de meuter 6 pages guest editors: sonia ben mokhtar, romain rouvoy, michael wagner managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 1 this work is partially funded by the safe-is project of the research foundation flanders and the moves project. http://www.easst.org/eceasst/ eceasst middleware for the internet of things, design goals and challenges† koosha paridel1, engineer bainomugisha2, yves vanrompay1, yolande berbers1, wolfgang de meuter2 k.u. leuven1, vrije universiteit brussel2 abstract: as the number of wireless devices increases and their size becomes smaller, there can be more interaction between everyday objects of our life. with advances in rfid chips and the introduction of new generations of these devices that are smaller and cheaper, it is possible to put a wireless interface on almost all everyday objects: vehicles, clothes, foodstuffs, etc. this concept is called the internet of things. interaction with thousands of wireless devices leads to a continuous and massive flow of events which are generated spontaneously. the question of how to deal with this enormous number of events is challenging and introduces new design goals for a communication mechanism. in this paper we argue that a middleware together with suitable linguistic abstractions is a proper solution. we also point out the challenges in developing this middleware. moreover, we give an overview of recent related work and describe why they fail to address these challenges. keywords: internet of things, middleware, linguistic abstractions 1 introduction as a result of the rapid advances in wireless technology and the emergence of a new generation of wireless devices which are cheaper and smaller, many objects in our daily lives are becoming wirelessly interoperable by having tiny and low-powered or even passive wireless devices attached to them (e.g. passive rfid tags). the wireless world research forum predicts that by 2017, there will be 7 trillion wireless devices serving 7 billion people [8]. this means one thousand devices per person. imagine a world where you can interact with most of your daily objects, such as a cup of coffee, shoes, books, etc. what makes this environment different from other domains of ubiquitous computing is its much larger scale in terms of the number of things it involves and the massive number of events that can be generated spontaneously by these things. the characteristics of the internet of things bring new challenges in developing applications and make the existing challenges in the area of ubiquitous computing considerably tougher. some of them are new challenges which only appear in the environment of the internet of things, and some are old challenges which have been addressed to some extent in current solutions, except that those solutions are inadequate for the environment of the internet of things. in a ubiquitous computing environment, it is not possible to impose standards and make everyone comply. we therefore need a system to join heterogeneous components together and to ensure interoperability between them. a middleware offers common services for applications † this work is partially funded by the safe-is project of the research foundation flanders and the moves project. 1 / 6 volume 28 (2010) middleware for the internet of things, design goals and challenges1 and eases application development. moreover, it provides transparency with regard to the heterogeneous components for the application layer. complementary to middleware are programming language approaches for mobile ad hoc networks [3] and wireless sensor networks [6]. these approaches attempt to tackle some of the challenges (such as discovery, network disconnections, and group communication) posed by the internet of things environments. however, they miss out on an important characteristic of context-awareness (e.g., context-aware service discovery) and have not been applied to a massive number of devices. in this paper we discuss some of the existing middleware and programming language approaches and identify their shortcomings. these shortcomings justify our position that new middleware and language abstractions are needed for addressing the challenges posed by the internet of things. in the following, we point out the challenges in section 2. we then give an overview of related work and their shortcomings in section 3. we conclude in section 4. 2 challenges 1. larger scale: scalability, as described in [7] is the ability of a network to support the increase of its limiting parameters. these are parameters whose increase causes the network performance to degrade. these parameters for a communication system in mobile ad hoc networks are network size, number of events, mobility rate, heterogeneity of devices, number of diverse interactions and number of different topics of interest [2]. we discuss the first four scalability issues here. (a) large network size: in the internet of things, we are talking about interaction with thousands of devices in one place. the scale is much larger here compared with the situations assumed in other systems. larger network size makes it harder to build logical structures such as trees [5] and considerably increases the overhead of flooding techniques [10]. (b) massive number of events: a significant challenge is posed by the enormous number of events generated by objects. as there are interactions with a large number of devices, it can be expected that there will also be a massive number of events occurring all the time. this has never been an issue in the previous solutions. to our knowledge, it has always been implicitly assumed that the number of events in the system is not so high that it could cause problems such as event congestion and lack of event processing capability. (c) mobility rate: higher mobility rate causes more breakage of links and causes more routing information becoming out-of-date. the network is a highly unstructured cloud of wireless devices into and out of which nodes are continuously flowing. moreover, because of the very volatile nature of this network, an object can never be sure if another object is active or is in its proximity. when an object is not reachable, it is unknown whether it remains active. the system should be able to deal with this temporary unavailability. a high mobility rate drastically decreases the performance of methods which maintain a set of logical connections such as routing trees and clusters [10]. the internet of things consists of objects with various movement proc. campus 2010 2 / 6 eceasst speeds including objects moving at very fast speeds. thus, we expect to have more overhead in updating routing information and maintaining logical structures. (d) heterogeneous devices: in the internet of things there is a wide variety of hardware and devices, in all shapes and sizes. these devices may vary from a real full-fledged mobile computer to a mobile phone or a pda, or even wireless devices without any processing power, such as rfid tags. in this kind of environment objects have various wireless communication ranges and therefore need to be dealt differently. 2. spontaneous interaction: sudden interactions happen as the objects move around and come into other objects’ wireless range. this leads to the spontaneous generation of events. unlike other context-aware systems and sensor networks, the events are not pulled by the interested parties. here, an interaction with an object means that an event is produced and is pushed to the system without premeditation. 3. zero infrastructure: in the internet of things setting, devices need to discover each other as well as the resources provided by other devices in the surroundings. the challenge here is that there is no fixed infrastructure to manage resource publication, discovery and communication. each device should be capable of announcing its presence and the resources it provides without requiring a fixed infrastructure. this is unlike the traditional distributed systems where resource publication, discovery and communication are managed by a dedicated server. the server coordinates all the interactions between devices and is assumed to be in an “always connected” state. such assumptions do not hold in the internet of things setting because devices continuously move from place to place and new surrounding devices need to be discovered. 4. multiplicity: devices in the internet of things are not “self-contained” and often rely on the services available at other devices in the surroundings. not only does this require selecting the most suitable services from a massive number of available services, but also dealing with massive number of results returned from different services. this challenge is further aggravated by the fact that results from different services may contradict each other. for instance, requesting for location information from nearby devices may return tens of thousands of contradicting location coordinates. another multiplicity issue is that devices often require to communicate to a group devices at the same time. 3 shortcomings of current solutions 3.1 middleware approaches as we discussed earlier, in the internet of things environment, a system is required to join the heterogeneous components together and to provide interoperability between them. this system should process, filter and route events in a scalable manner, given the other challenges such as volatility of network and massiveness of events. given these requirements, a middleware is a very suitable solution for routing and delivering events. a middleware offers common services for the applications and eases application development. however, there are already solutions called publish/subscribe (pub/sub) systems for delivering events from event sources to interested 3 / 6 volume 28 (2010) middleware for the internet of things, design goals and challenges2 clients. although they were originally designed for wired networks, they now offer solutions for mobile and volatile environments. in the rest of this section, we describe and give an overview of pub/sub systems and focus on pub/sub systems for mobile ad hoc networks, which are closer to our type of environment. next, we argue that using a pub/sub mechanism alone cannot address the challenges discussed in section 2. the pub/sub paradigm is designed to deliver events from a publishing source to interested clients in an asynchronous way. the pub/sub systems are very interesting solutions because of their decoupling properties, which means that the interacting parties do not need to know each other. an asynchronous way of communication also has the advantage that parties can communicate even if they are not up at the same time. there are already many decent solutions for pub/sub systems in wired networks and infrastructured mobile networks, where the backbone of the network is still wired. recently, some pub/sub systems have been proposed for mobile ad hoc networks. in [11], the authors propose a pub/sub protocol for mobile ad hoc networks involving the construction of dynamic voronoi regions. all nodes are divided into broker and non-broker categories, and each region is represented by a broker node. the authors propose mechanisms for constructing these voronoi regions and for message deliveries.[10] also propose a pub/sub system for mobile ad hoc networks involving a hybrid model which uses flooding and content-based routing techniques hierarchically. they divide the network into clusters of nodes and use the event flooding technique for inter-cluster communication and content-based routing for intra-cluster communication. they try to utilize the advantages of content-based routing to achieve more efficient subscription propagation and maintenance and also reduce the costs of document delivery, while avoiding the high topology maintenance costs of content-based routing by using clusters and using flooding techniques for inter-cluster communication. also in [5], the authors propose a protocol to organize the nodes of a mobile ad hoc network in a single, selfrepairing tree structure which can be used for efficient content-based routing in the network. their idea of maintaining the tree topology is inspired by a protocol for multicast over mobile ad hoc networks called maodv. however, the pub/sub systems focus purely on routing and delivering events. they do not take into account the possibility of having a very large number of nodes and a massive number of events. the current pub/sub systems do not scale for more than a few hundred nodes in mobile ad hoc environments. [5] do simulations with up to 100 nodes, and the performance of their system rapidly decreases as the size of network increases [10]. [11] simulates only with 200 nodes and does not study the effect of increment in the network size. because of their structure and communication mechanism between brokers it is expected that increasing the network size will decrease the performance of the system rapidly. in [10] the authors run simulations with up to 405 nodes. their simulation shows a sharp decrease in the document delivery rate when network size is increasing. this behavior is worse when they choose larger cluster size (e.g. 10 nodes in each cluster). on the other hand, when they choose smaller cluster sizes average energy consumption increases. the reason is that when cluster sizes are smaller document flooding will be used more than content-based routing and this means sending more messages and consequently consuming more energy. also in the mentioned systems document publication rate is chosen between 0.5 to 1 events per second. only [5] do simulations with more publishing rate up to 24 messages per second and the result is a rapid decrement in document delivery rate. however, in the internet of things environment we expect to deal with at least thousands of nodes in one proc. campus 2010 4 / 6 eceasst place that are continuously generating events. as we discussed in section 2, there are lots of challenges that cannot be addressed solely by pub/sub techniques, although they can be used effectively as a component of a bigger solution. the following table shows how the mentioned systems deal with scalability challenges: system network size number of events mobility rate heterogeneity [10] + n/a [5] + [11] n/a n/a there have been several publications proposing a middleware to tackle some of the challenges of the internet of things. in [4] the authors describe their vision for the internet of things, and propose their smart semantic middleware to deal with the heterogeneity of the components and to allow the creation of self-managed systems. they exploit semantic technologies to provide interoperability and agent technologies for the management of complex systems. in [1], the authors propose their global sensor networks (gsn) middleware to support their vision of the internet of things. they focus on minimizing the development and deployment costs and on data-oriented integration of data sources in what they call the ”sensor internet” environment. neither of these approaches aims to address scalability, event massiveness and network volatility. 3.2 programming language approaches complementary to a middleware, there are programming languages that have been designed for highly dynamic environments such as mobile ad hoc networks (manets) [3] and wireless sensor networks (wsns) [6, 9]. here we discuss a selection of representative language approaches and point out why they fail to cope with the challenges posed by the internet of things. spatialviews [6] is a language extension to java that is specially designed for resource constrained devices in wsns. devices providing the same services and residing in the same location are collectively represented as a spatial view. the language runtime takes care of discovery, communication and migration of computations amongst nodes. in this respect, spatialviews to some extent, tackles the challenge of service discovery in environments characterized by zero infrastructure. however, service discovery based on location and type of service is not enough considering the massive number of services that may be available at the same time providing the same functionality. rather than bombard the user with thousands services to select from, we argue that the service discovery mechanism should be based on richer contextual information (e.g., quality, user preference, cost, availability, e.t.c.). many-to-many invocation (m2mi) [3] enables building applications that run in manets and provides language abstractions for broadcasting messages to multiple devices. messages are broadcast to objects of a specified type or within a defined communication range. m2mi ensures that the application behavior is not hampered by network disconnections. for instance, devices can come and go and still become part of the ad hoc network upon reconnection. this group communication facility somehow addresses the challenge of multiplicity described in section 2. however, m2mi has only been applied to simple applications (chat and printer services). in the internet of things setting, there is need for not only to dynamically compose groups of communication, but also means to filter the massive number of results from the many invocations. 5 / 6 volume 28 (2010) middleware for the internet of things, design goals and challenges3 4 conclusion in this paper we described challenges in developing a middleware for the internet of things. we then discussed some of the existing middleware and programming language approaches and identified their shortcomings. these shortcomings justify our position that new middleware and language abstractions are needed for addressing the challenges posed by the internet of things. bibliography [1] k. aberer, m. hauswirth, and a. salehi. middleware support for the “internet of things”. gi/itg kuvs fachgesprch drahtlose sensornetze, universitt stuttgart, 2006. [2] g. chockler, r. melamed, y. tock, and r. vitenberg. constructing scalable overlays for pub-sub with many topics. in proceedings of the twenty-sixth annual acm symposium on principles of distributed computing, page 118. acm, 2007. [3] alan kaminsky and hans-peter bischof. many-to-many invocation: a new object oriented paradigm for ad hoc collaborative systems. in oopsla, pages 72–73, new york, ny, usa, 2002. acm. [4] a. katasonov, o. kaykova, o. khriyenko, s. nikitin, and v. terziyan. smart semantic middleware for the internet of things. in proc. 5th intl. conf. informatics in control, automation and robotics (icinco’08), volume icso, pages 169–178, 2008. [5] l. mottola, g. cugola, and g.p. picco. a self-repairing tree topology enabling contentbased routing in mobile ad hoc networks. ieee transactions on mobile computing, pages 946–960, 2008. [6] yang ni, ulrich kremer, adrian stere, and liviu iftode. programming ad-hoc networks of mobile and resource-constrained devices. sigplan not., 40(6):249–260, 2005. [7] c.a. santivanez, b. mcdonald, i. stavrakakis, and r. ramanathan. on the scalability of ad hoc routing protocols. in ieee infocom, volume 3, pages 1688–1697. citeseer, 2002. [8] m.a. uusitalo. global vision for the future wireless world from the wwrf. ieee vehicular technology magazine, 1(2):4–8, 2006. [9] matt welsh and geoff mainland. programming sensor networks using abstract regions. in nsdi’04: proceedings of the 1st conference on symposium on networked systems design and implementation, pages 3–3, berkeley, ca, usa, 2004. usenix association. [10] s. yoo, j.h. son, and m.h. kim. a scalable publish/subscribe system for large mobile ad hoc networks. the journal of systems & software, 82(7):1152–1162, 2009. [11] q. yuan and j. wu. drip: a dynamic voronoi regions-based publish/subscribe protocol in mobile networks. in ieee infocom. citeseer, 2008. proc. campus 2010 6 / 6 introduction challenges shortcomings of current solutions middleware approaches programming language approaches conclusion testing as a certification approach electronic communications of the easst volume 33 (2010) proceedings of the fourth international workshop on foundations and techniques for open source software certification (opencert 2010) testing as a certification approach alberto simões, nuno carvalho and josé joão almeida 10 pages guest editors: luis s. barbosa, antonio cerone, siraj a. shaikh managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst testing as a certification approach alberto simões1, nuno carvalho2 and josé joão almeida3 1 ambs@cpan.org, http://www.eseig.ipp.pt/ escola superior de estudos industriais e de gestão, instituto politécnico do porto 2smash@cpan.org, 3jj@di.uminho.pt, http://www.di.uminho.pt/ departamento de informática, universidade do minho abstract: for years, one of the main reasons to buy commercial software instead of adopting open-source applications was the, supposed, guarantee of quality. unfortunately that was rarely true and, fortunately, open-source projects soon adopted some good practices in their code development that lead to better tested software and therefore higher quality products. in this article we provide a guided tour of some of the best practices that have been implemented in the perl community in the recent years, as the pathway to a better communityoriented repository of modules, with automatic distributed testing in different platforms and architectures, and with automatic quality measures calculation. keywords: test-driven development, test-coverage, distributed testing, perl community 1 introduction test-driven development [max03] is not a new approach on the now widely discussed extreme programming techniques [bec99]. the idea is simple and effective: before writing code, or even thinking on how it will be implemented, the programmer is invited to analyze how he would like to use the application (or the function or methods being developed), and look at it, as often young scholars do, as a little black box, and decide what gets in and what should get out. after this first discussion, some tests should be written. these tests will use the application’s functions or methods being developed, invoking them with some kind of input, and checking its output against some kind of gold standard. this is also a great opportunity for developers to analyze the code api, if it should have one, because since there is not any code actually written yet, the signature of operations made available by the api can easily change. only after a few tests are written the developer should start the implementation. this also gives a chance for the developer to meditate about the expected behavior of the new code without any concerns about implementation details. the behavior should always be chosen outside the scope of implementation, since the expected behavior of a function, or method, should not be tailored by implementation difficulties. this is true for most of the cases, but not always. as soon as a first running code is available, it should be run against the written tests. if any test fails, it means the algorithm is not working properly and, if the test passes, it means the code is supporting the cases described in the tests. this process iterates. during development it is natural that the developer thinks of some new situation that should be handled. before coding that portion of code, he should write a new test that tests that specific case. what test-driven development guarantees is that new code will not break previously working code, as the test suite grows. it does not guarantee that the code handles all situations, as it depends on the 1 / 10 volume 33 (2010) mailto:ambs@cpan.org http://www.eseig.ipp.pt/ mailto:smash@cpan.org mailto:jj@di.uminho.pt http://www.di.uminho.pt/ testing as a certification approach written tests and their coverage. also, it does not guarantee that the developer did not cheat, as he is aware of the input of each test. as any other technique, it depends on the good will of the involved persons. another major advantage of using testing frameworks is the ability to easily re-factory. in today’s development environments often happens that different teams put together smaller programs to be used by other teams to build more complex applications. if at any given time one of these smaller programs needs to be re-implemented, because of efficiency problems for example, the developer, being the same or a new one, just needs to make sure that the new implementation passes all the tests. this, in most cases, automatically makes complex programs, that use the re-factored code, immediately also work. this scales very well, meaning that if the complex program also passes its own test suite, because the re-factored program respected the old code behavior, then even more complex programs that rely on both of these will probably automatically work with the new code. the open-source community is investing in this approach for code development. examples are the unit-testing of java, ruby or perl modules, and the number of available frameworks for testing. even in the corporate world more and more often companies release their applications as open-source projects and many times rely on testing frameworks to make sure their code is not only working, since there is the chance of many more contributions and changes to the original code, but also guarantee that the most recent code still maintains the original behavior. in this article we would like to give a tour of the initiatives and techniques that are being used by the perl community to guarantee some minimum quality standard on the modules made available by the well known comprehensive perl archive network [cpa10] (cpan). the article is divided in four main sections. first, section 2, presents briefly the cpan archive, how it works and the available tools for the common perl programmer to interact with it. section 3 covers some of the available frameworks for writing tests for perl modules. these frameworks will be divided in three blocks: testing code behavior, testing documentation (both syntax and coverage) and testing module distribution. trying to overcome the usual problem of discussing who certifies certification agencies, or who controls persons responsible for controlling others, section 4 presents an approach to testing tests using the code that was written to pass those tests. finally, section 5 will focus on two community initiatives: the support for distributed testing on different architectures and operating systems, and the analysis of modules’ code with the computation of a quality measure. in summary, in this article we will present approaches that will help the developer to tell the user here is my code and here is a way to show you that it works properly. the certification itself is basically given by a positive outcome of the testing framework, obviously assuming that the tests themselves are trusted and were written in good faith. 2 quick introduction to cpan the comprehensive perl archive network (cpan) has its origins (in concept and name) in the comprehensive tex archive network [cta10] (ctan), the archive of tex classes and packages. the ctan idea is simple: create a centralized archive of modules, scripts and other tools related to a community of users, where any user can contribute, and the entire community can make use of the entire archive. this same approach is being used by other communities, like r developers with the comprehensive r archive network [cra10] (cran), ruby application archive [raa10] (raa) for ruby developers, or python package index [pyp10] (pypi) for python developers. every one of these archives shares the same basic principles, but adds different functionalities according to their user’s needs. these archives’ baseline of functionalities can be described as: proc. opencert 2010 2 / 10 eceasst 1. any user can contribute any code/package/module (and, normally, the contribution is not reviewed); 2. there are no restrictions on adding contributions that mimic the behavior of other contributions; 3. there is some kind of taxonomy that allows the contributor to classify his contribution (usually contributions are indexed also by contributor name); 4. any user can search the catalog and download any package he wants. usually these archives also add some text explaining the package so that the user can choose using something more elaborate than just the package name, author information and contribution class. it is easy to notice that these operating rules are too liberal. in particular, rules 1 and 2 lead to anarchy very easily, as users can contribute bad, buggy or malicious code, and can even contribute code with similar behavior of other already archived. therefore, the user searching for a module will have to deal with the questions: how to be sure that a module can be downloaded and used safely; and how to choose from a set of possible modules that can be used to perform the same task. unfortunately, unless the rules get replaced by new rigid ones, these two problems do not have a simple solution. of course this contribution flexibility motivates and promotes more developers to make their code available in the archive. nevertheless, some extra meta-information can be added to the repository, making the task of choosing what modules to download, and use, easier for the user. with this objective, cpan includes a few extra meta-information mechanisms: 1. each module can be rated, as if it were a movie, by any user. the user can add comments on it as well. unfortunately it is not easy to convince users to rate modules. while some perform that task, most cpan modules are not rated or commented on; 2. each module has a clearly associated author, with e-mail address and picture (when available). as authors get well known and get reputation, users get confident in using their contributions. this is especially true given the number of conferences organized each year by the community, that work well to introduce developers; 3. together with the module description it is possible to visit, automatically, its documentation. also, as the community suggests a well structured template for documentation, it is relatively easy to compare modules’ documentation and their completeness (therefore, making it easier to choose which module to use); 4. the date of the last update is also shown. usually modules with old dates are not maintained. but it can also mean the module is stable (although this is rarely the case); 5. a detailed matrix of the tests and their status (pass/fail) on different platforms is also shown. refer to section 5.1 for more information on how this data is computed. although not related to tests and software quality, we would like to add a final remark: there are some applications that can be used to install modules from cpan. the fact that more than one tool exists for this task is an example of the multiplicity of available modules for performing the same task. when installation fails the user has the option to automatically report the failure. this will issue an e-mail that will be sent to the module(s) maintainer(s). 3 / 10 volume 33 (2010) testing as a certification approach 3 pure test-driven development every perl module available on cpan includes a test suite (of course, there are a couple of exceptions that prove the rule), from simple and incomplete to fully featured test suites. these test suites’ appearance was not guided by any rule or requirement imposed by cpan. that would not work! instead, an initial framework for testing was born and, at that time, the only tool available to bootstrap empty perl modules from a skeleton template incorporated one or two simple tests of module usability (for instance, checking the module loads). it was this initiative that resulted in a greater number of people writing tests, not because they were a requirement. nobody really cares to complain if a module does not include a test suite, but the author, when creating the module, and noticing there is already a basic framework for writing tests, tries to maintain it, adding new tests. three different aspects of perl modules began to be tested (there are some other aspects that could be included here but that we decided to ignore them, as they can be considered part of one of the categories we present here): • tests started with simple code testing (section 3.1), just like any other programming language unit-testing framework; • then followed the addition of tests for documentation and documentation coverage (section 3.2), checking the syntax of the documentation and its completeness; • finally, tests for checking distribution contents (section 3.3) are arising, to ensure every file required is being shipped in the module tarball. these same tests can be divided in two categories: • developer tests should be checked only by the programmer, locally, before distribution. they normally check that all files are present in the distribution, that the documentation is complete and with the correct syntax; • user tests should be shipped with the module and should be run by every user that wants to install the module. they usually test the algorithm of the application. these tests will guarantee that the relevant code works independently of the architecture, operating system or perl version, as developers might have some difficulty in having different machines for testing purposes (check section 5.1 for more initiatives on multi-architecture testing). note that while we focus primarily the testing frameworks for perl module development, the perl core itself has a complete test suite. 3.1 testing code testing code is the more usual paradigm of testing. as described in the introduction of this article, the developer is invited to declare the behavior of its method or applications, writing a set of typical inputs (hopefully including some edge cases), and the corresponding correct results (outputs). depending on the complexity of the method or application being tested, the complexity of the test can grow. a common good practice is to start writing tests for small auxiliary functions at the beginning of the project, in such a way that every new function has all its dependencies well tested. the more usual tests for code can be divided in the following categories [lc05]: proc. opencert 2010 4 / 10 eceasst • comparing the return value with the correct answer: most tests receive an input and check the output against a gold standard, the correct answer. this verification can be as simple as checking if the return value is the same as a specific integer or string, or checking if the return value is inside the expected range of possible answers. perl frameworks implement a set of functions to help implement these tests. each test includes the code to be tested but also a small description of what is being tested. this is useful, as it makes the process of reading test reports easier. is( add(2,3) , 5 , ’simple test for add’ ) modern test frameworks provide more flexible testing mechanisms, so that strings can be matched against regular expressions, or full complex data structures matched against other sample structures. is_deeply( parse(’2+3’) , [’+’, 2, 3] , ’parse sum op’ ) also, there are other modules that allow checking for other kind of output, like text document generation, analyzing xml structures (matching it against a schema or simply analyzing the contents of some xpath expressions), or checking the values present on a database. my $snoopy = dog->new("snoopy"); isa_ok( $snoopy , ’animal’); # snoopy is an animal can_ok( $snoopy , ’bark’); # snoopy is able to bark all these tests are of the same kind: with some input, the function, method or application delivers the correct output. • checking that the module is loadable without errors: a fundamental test for any program written in any language is that it compiles or gets interpreted correctly without syntax errors. this test is automatically generated for any new module created by the common perl module generators, ensuring that each new module that gets in cpan ships with this basic guarantee. • analyzing an objects’ hierarchy and available methods: object oriented programs can create classes and objects at run time. these classes need to be tested, for instance, checking their parent information (isa relationship) and checking that they can handle some specific methods. more complicated testing mechanisms are also supported in perl. for instance, there are modules for testing regular expressions (checking that they match the required string and that they will not match false positives), xml (that the document is well formed, or valid against a specific schema), xpath expressions (that the expressions are correct and that they yield the correct value when matched against an xml document), images (checking their size, checking specific pixel colors, etc), web applications (simulating an user, interacting with the web application and analyzing the resulting web pages) and many more. last, but not least, testing of coding standards (or best practices [con05]), such as indentation, or function or variable name capitalization, is also contemplated. 3.2 testing documentation perl has a great advantage with documentation over some other languages. while java or c support javadoc [ora10] and doxygen [vh10] respectively, they were never seen as a real standard for writing 5 / 10 volume 33 (2010) testing as a certification approach documentation (probably more with javadoc than doxygen), perl has a de facto standard, named pod1, that is broadly used by all perl modules. it can be used in a literate programming approach, where the programmer can interleave code with documentation. unlike javadoc or doxygen, perl is very flexible on the pod usage. there is no requirement to write the documentation near the respective functions, for example (javadoc or doxygen work as code annotation). pod has a simple textual format. it supports a few headings, some lists, basic word highlighting, and verbatim sections. this documentation should also be tested and, on newly created modules, two kinds of tests are automatically created: • checking documentation syntax correctness: given that perl uses a specific syntax for writing documentation, and that that documentation is interpreted to generate the documentation in different formats (unix man-page, html, pdf, latex), it is important that the documentation syntax is correct. for that purpose, a syntax checker exists that is able to search for all documentation present on a perl module directory and complain about syntax errors. • checking documentation coverage: the second level of quality assurance for documentation is its coverage. it is not enough that the documentation has a valid syntax, it is also required to cover all methods implemented. this framework parses the documentation and ensures that each function or method defined has a corresponding documentation section. as some methods might be irrelevant for documentation (maybe because you just do not want to make users aware of it), their names can be prefixed with an underscore and the testing mechanism will ignore them. once more, these testing approaches do not guarantee any documentation quality, but they assist the developer who is interested in writing and maintaining complete documentation. 3.3 testing distribution when creating a tarball with the module files and uploading it to cpan servers, the developer needs to ensure the tarball is complete, and that all files are edited accordingly. in this area, the perl community also offers some frameworks for testing purposes: • checking distribution tarball completeness: when developing a program or module, there are a bunch of files that are created with small debug programs, small test cases and other information (such as version control software files). these files are not part of the distribution that should be released. therefore, perl adopted the concept of a manifest file with the list of files to be included in the release tarball. while this solution is great, it is also annoying. every time a new file that should be included in the distribution is created the developer needs to edit the manifest file and add the new file. if he forgets to do so, the distribution will be incomplete and unusable. therefore, a mechanism to ensure that all files that are listed in the manifest file exist is required. for that to work, this test uses another manifest file, with regular expressions that match the files that should be ignored and not included in the distribution. then, if a file appears that is not listed in any of the two manifest files, the test will fail. 1 stands for plain old documentation (whilst old, it is not dead, and has been evolving in the last year). proc. opencert 2010 6 / 10 eceasst • checking that generated files were properly edited: another kind of test that should be performed prior to the module distribution is ensuring that all files that were generated by the common module generation tools were edited. to explain the relevance of this test i should explain that about 8 years ago, many modules in cpan had as author “a. u. thor”, the name used by one of the modules generation tools. these tests, named boilerplate, ensure the programmer edited the generated code, installation and other documentation files. other examples of distribution testing include the analysis of modules and sub-modules, change log and read me files, ensuring all refer to the same version. 4 testing test coverage the main problem when writing tests is the question about how to test the quality of the tests. in fact, testing tests it not really possible. but we can assess how much of our code is covered by currently written tests. perl offers a framework for this purpose. for each test, each line of code that gets executed it counted. this results in a table that, for each line of code, shows the number of times it was executed. this kind of coverage testing is great when writing tests. if the written code has some conditional structure, for example, there should be a test to exercise each of the possible branches [joh05]. all this information is presented to the user in html format, with all the code annotated with information about how many times each line was executed. moreover, it also presents some basic statistics, showing the percentage of subroutines or branches that have been tested. with all this information it becomes easier for the programmer to find out what areas of the code need extra testing. 5 automatic distributed testing as already stated, some developers do not have access to all platforms (cpu, architectures or operating systems) where perl can run. this leads to a problem: how can you know if a specific module works correctly on a specific platform? to overcome this problem the perl community created a distributed testing service (see section 5.1). all these initiatives (those already discussed and this distributed testing service) assume the good will of the developer, who wants to make his code better. as an independent initiative, another project named cpants [kla10] (the cpan testing service) was created. the goal of this project is to provide some sort of quality measure (called kwalittee) by code analysis (see section 5.2). 5.1 distributed testing service the perl community has a cpan testers framework [bar10]. community volunteers can join the initiative, registering one or more machines (together with its architecture, operating system and perl version) and offering to test module distributions uploaded to the archive. there are some tools to help in finding the latest uploaded modules so that cpan testers can know what to test. this process can be completely automatic or semi-manual, depending on the testing tool chosen by the tester. currently there are testers running perl versions from 5.004_05 (the maintenance branch of a perl version with more than ten years old) to the most recent, development branch 5.13.2 (about two 7 / 10 volume 33 (2010) testing as a certification approach weeks old). operating systems available for testing include os/2, sunos/solaris, irix, mac os x, openbsd, vms, windows, linux, aix, etc2. if the configuration, compilation and installation succeeds, a success report is inserted in a database that can be queried by any user (therefore, knowing if that module is stable for a specific platform). if some error occurs, an e-mail with a full report is generated (with the full output of the compilation process, and details on the platform and perl configuration variables) and sent to the module maintainers. this same report is stored in the database, so that any user can query it. 5.2 automatic quality measuring by code analysis being a cpan tester is a risky task. while many cpan testers test modules in a virtual machine or some kind of sand box, they are risking their machine or installation to malicious code. as far as the authors are aware, no real malicious code was found yet on cpan, but it is possible (although, if detected, user would be banned and modules deleted). cpants is another project that aims to evaluate perl modules. instead of trying to compile, test and install modules, this approach grabs modules and inspects their code (not executing it). the module code is checked against a list of kwalitee3 metrics. unfortunately, as the basic idea rejects the interpretation of code, the amount of analysis possible to be performed is reduced. nevertheless, cpants tests are relevant. to mention some examples, cpants checks if all module dependencies are listed correctly in the package meta-data file, if any file mentioned in the manifest file is missing, if every module file has a version number, if there is a clear license in the documentation, if a read me and a change log files are present, etc. given the automatic behavior of cpants, and its objectiveness, it can be almost considered a game, where modules with better module distributions get points for their kwalitee. therefore, the web site can show a sorted list of authors, that can play or fight, trying to climb up the table. this playful approach can motivate developers to improve their distributions. 6 conclusions in this article we provided a brief tour to the mechanisms implemented by the perl community to help the development of test suites. helping to guarantee that modules include tests, delivering methods to harness results of running test suites, measuring testing coverage of the source code, and also trying to make sure that modules run correctly on heterogeneous systems by providing distributed approaches to test code in different contexts, architectures and platforms. while the testing techniques described in this article can not be seen as a formal certification approach, they can easily motivate open-source developers to include quality assurance tests. also, a test suite can be used to help demonstrate the end user that the code (implemented by the developer or developers) actually does what it advertises, without the need for the user to browse thousands of lines of source code. assuming the good faith of the tests writers, we can admit that a positive outcome of running the test suite certifies that the module is working properly, at least for the cases tested. and luckily, enough edge cases and gray areas tests were included to certify that the module or application is working as expected for those particular cases too. this can be seen as a way for 2 unfortunately not all platforms have all perl versions available for testing. nevertheless, more common operating systems have most perl versions available. you can check a detailed matrix of what perl version are available in what operating system at http://stats.cpantesters.org/osmatrix-full.html 3 kwalitee is the name chosen to represent this pseudo-quality information. proc. opencert 2010 8 / 10 http://stats.cpantesters.org/osmatrix-full.html eceasst a developer, by himself, without the need of any outside entity, to give some assurance (a small non formal certification) that the code written works as expected. from these different initiatives we would like to stress that it is important that every kind of software packaging approach includes mechanisms to introduce software tests and that, when they are created by some kind of automatic generator tool, some simple tests are automatically generated. this will motivate the developer to keep the test suite up-to-date. on the other hand, if the task of adding a testing framework is a developer task, it is natural that this framework will often never be used. moreover, if the testing framework includes any tool to test the tests’ coverage, it will help interested programmers in detecting what sections of code are lacking testing. modern frameworks should also include tests for doing some documentation validation, namely documentation syntax and coverage, this can help the developer to improve the source code documentation. this introduces another interesting, and positive, side effect of writing a more complete test suite which is to have more code examples. and as tests cover more and more features of the code, more examples the author has, that can be used to enhance the module documentation. finally, knowing that these test suites will be run in different architectures and platforms automatically, without the need to ask for it, can lead the developers to have a greater interest in writing complete tests. clearly there are plenty of advantages on creating and maintaining a test suite, this is so obvious that perl itself has one. once you build the perl interpreter you can run this test suite to validate that the binary files were built correctly, and that perl behaves as expected. the core modules shipped with the perl distribution test suites are also executed in the process to make sure that everything works as intended. all these advantages shared by all contributions can help to promote the use of public code repositories analogous to cpan. since individual people, and companies, can clearly state that there is a continuous effort to improve the overall software quality. deploying better software also improves the level of confidence in this code repositories which helps to promote the language itself, and the adoption of open-source solutions in general. acknowledgments this work was partly sponsored by project grant ptdc/eia-cco/108995/2008 (an infrastructure for certification and re-engineering of open source software), from science and technology foundation of portugal. an extra acknowledgment to paul johnson, author of devel::cover module (that tests test coverage) for comments and suggestions. references [bar10] barbie et al. cpan testers. 2010. http://www.cpantesters.org/. [bec99] k. beck. extreme programming explained: embrace change. addison-wesley professional, october 1999. [con05] d. conway. perl pest practices . o’reilly, sebastopol, ca, 1st ed. edition, 2005. [cpa10] cpan. comprehensive perl archive network. 2010. http://www.cpan.org, http://search. cpan.org. 9 / 10 volume 33 (2010) http://www.cpantesters.org/ http://www.cpan.org http://search.cpan.org http://search.cpan.org testing as a certification approach [cra10] cran. comprehensive r archive network. 2010. http://cran.r-project.org/. [cta10] ctan. comprehensive tex archive network. 2010. http://www.ctan.org. [vh10] d. van heesch. doxygen: generate documentation from source code. 2010. http://www. stack.nl/~dimitri/doxygen/. [joh05] p. johnson. devel::cover – an introduction. in simões and castro (eds.), yet another perl conference, europe (yapc::eu). pp. 85–90. braga, portugal, august 2005. [kla10] t. klausner. cpan testing service. 2010. http://cpants.perl.org/. [lc05] i. langworth, chromatic. perl testing: a developer’s notebook. o’reilly, beijing, 2005. [max03] e. m. maximilien. assessing test-driven development at ibm. in in proceedings of the 25th international conference on software engineering (icse-03. pp. 564–569. ieee computer society, 2003. [ora10] oracle. javadoc tool. 2010. http://java.sun.com/j2se/javadoc/. [pyp10] pypi. python package index. 2010. http://pypi.python.org/pypi. [raa10] raa. ruby application archive. 2010. http://raa.ruby-lang.org/. proc. opencert 2010 10 / 10 http://cran.r-project.org/ http://www.ctan.org http://www.stack.nl/~dimitri/doxygen/ http://www.stack.nl/~dimitri/doxygen/ http://cpants.perl.org/ http://java.sun.com/j2se/javadoc/ http://pypi.python.org/pypi http://raa.ruby-lang.org/ introduction quick introduction to cpan pure test-driven development testing code testing documentation testing distribution testing test coverage automatic distributed testing distributed testing service automatic quality measuring by code analysis conclusions patterns as abstractions of spatial axes electronic communications of the easst volume 25 (2010) proceedings of the workshop visual formalisms for patterns at vl/hcc 2009 patterns as abstractions of spatial axes jens gulden 12 pages guest editors: paolo bottoni, esther guerra, juan de lara managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst patterns as abstractions of spatial axes jens gulden jens.gulden@uni-duisburg-essen.de university duisburg-essen, germany abstract: the decision of how to model patterns as elements of formal systems is a yet sparsely covered research topic. the present article introduces an approach which understands patterns as non-linguistic carriers of formal semantics in models. the notion of patterns is embedded into a theory which links spatial orientation and navigation to the constitution of semantics in human understanding. inside this framework, the concept of patterns is treated conform to the notion of spatial axes on a shared higher level of abstraction. a formal model is presented which expresses the introduced notion of patterns in a practically applicable meta-modeling language. keywords: model, diagram, visualization, patterns, space 1 pattern-based semantics in models and scientific theories in order to communicate and express knowledge, linguistic or non-linguistic devices of expression are used. meaning – or, as a synonym, semantics –, is not an inherent feature belonging to these means of expression, it does not have the status of an ontological entitity that is attached to things [put75]. instead, meaning is a result of interactions carried out by cognitive beings in the world [noë04]. the “final interpretant” [pei31] are the actions performed by participants involved in language use. in order to communicate semantics and constitute understanding, different kinds of means can be consulted. traditional reflections on the notion of semantics have primarily focused on linguistic symbol systems, i.e., spoken and written languages in a narrow sense. languages, both formal and natural, are indeed suitable means for communicating and sharing meaning, and a great extent of everyday communication and scientific reflection is carried out successfully in spoken and written language. however, the phenomenon of understanding is not limited to settings in which language-based communication takes place. it is as well typical for human communication to transfer meaning by non-linguistic carriers, e.g., pictorial symbols, diagrams, gestures, movements or just a combination of colors and locations1. subject-specific communication in different scientific disciplines is also not restricted to linguistic devices of expression. almost any scientific branch has developed means for expressing subject-related knowledge of the discipline in the form of diagrams, tabular structures, symbolic markings etc. using non-linguistic carriers of meaning in addition to written and spoken language allows to exploit a much wider range of cognitive 1 an example of transferring meaning by a combination of colors and locations, together with other contextual aspects, is, of course, the use of traffic lights. 1 / 12 volume 25 (2010) patterns as abstractions of spatial axes resources to create common understanding among participants in a communication setting and to construct and describe complex systems. while language is bound to a linear structure and words cannot easily be used to point out subtle differences between concepts [goo68], a wide range of techniques exist to express scientific knowledge in a non-logocentric way, in the first place visualization techniques [ber84, tuf83]. a wider notion of semantics incorporates any spatial-temporal constellations and processes in space and time as being capable of constituting meaning. since the upcoming sections of the present paper focus on scientific means of communication via diagrams, a light will be put on static spatial constellations and non-moving visual appearances as carriers of meaning. the proposed approach, however, could without frictions be extended by including movements and temporal patterns accordingly. the following section 2 sketches the current state-of-the-art in semantic theory research. it also lays out why traditional approaches have grown insufficient for methodical reflection on sciences and the languages and models they use to communicate. section 3 presents new philosophical approaches conquering the desiderata resulting from the traditional view's deficiencies. based on these works, the requirements for incorporating pattern-based semantics into formal modeling methods in computer science and other disciplines are outlined, and in section 4, a formal meta-model which fulfills the identified requirements is developed. the meta-model includes the formalization of the term “pattern” as an abstract kind of spatial axis. the article ends with section 5 which summarizes the presented work and sketches possible future steps of improvement. 2 in search of a semantic theory able to cope with patterns since non-linguistic carriers of meaning become increasingly important when large and complex systems are described, the use of patterns as non-linguistic devices should be reflected when providing scientific support for formal system design. this task, however, has only been sparsely investigated yet. only since about the 1980s years, philosophical and linguistic underpinnings have been developed to capture a notion of semantics beyond a purely logocentric view. conjoint research of philosophers and cognitive scientists has resulted in conceptualizations which allow for broadening the notion of semantics as constituted by pattern-like constituents of meaning. the concepts of metaphorical constituents of meaning [jl80] and image schemata [joh87, gal05] have provided the methodical tools for acquiring a notion of semantics which can explain phenomena of human understanding and cognition on a level required for coping with patterns. these approaches are commonly subsumed under the label “embodied cognition” [wil02]. the main idea of the embodied cognition view is to explain cognition, understanding and the use of symbols as emerging from cognitive processes bodily beings perform when physically interacting in the world. spatial orientation and navigation of the body are fundamental cognitive operations of all bodily beings which bind cognition to a system of possibilities and limitiations offered by the physical world. according to the embodied cognition view, they form the basis for the development of high-level cognitive operations such as the use of languages and other semantic means of expression. the theoretical groundings developed by the embodied cognition view provide a thorough proc. vffp 2009 2 / 12 eceasst foundation for reconstructing means of expression in computer science and information systems science. capturing knowledge about highly interrelated systems is especially relevant in managing large-scale technological and socio-technical systems, e.g., in the field enterprise modeling [fra02]. however, the transfer of these results into formal modeling research has yet to be performed. modeling theories currently applied by computer science's research often merely refer to an objectivist account of semantics, which is embedded into a narrow notion of models inspired by graph theory. this notion cannot be sufficient for being applied in computer sciences and information systems to describe complex technological and socio-technical systems [gul08], because it is blind towards expressing, e.g., non-linear, interrelated contextual semantics at a glance. 3 incorporating pattern-based semantics into formal modeling techniques the efficiency and effectiveness in using models for complex formal system design and management is expected to be raised when modeling languages are opened up to incorporate new means of expressing semantics, e.g., by offering pattern-based visual language elements. a theoretically better supported notion of models and appropriate model visualizations than provided by traditional approaches can be developed on the basis of semantic theories from the embodied cognition approaches, introduced in the previous section. one place to incorporate a wider notion of semantics is the concrete syntax of a modeling language. a concrete syntax describes the visual appearance of modeling language constructs in a diagrammatic representation. traditionally, this includes, e.g., the element symbols on a diagram plane, line-styles for connections, or variants of arrow-symbols at connection ends. aspects of pattern-based semantics are not taken into account by state-of-the-art concrete syntax descriptions. they get flattened by traditional notation models, which treat positions of graphical elements in a diagram simply as numerical coordinates. from this point of view, a diagram is nothing more than a set of absolutely positioned elements combined with a set of edges that describes relationships between the elements. this view on diagrams originates from traditional graph theory and provides strong restrictions on current conceptualizations of concrete model syntax. to overcome this limitation, the responsibility for locating elements can be taken over by a more precise semantic description of “what it means to be positioned somewhere”. this does not mean to mix the traditional distinction between semantic language description and purely syntactic graphical notation. it rather means to reclaim elements, which have traditionally been treated as simple syntactic aspects in a notation model, back to a level of semantics. to achieve this, the idea of what a model notation generally is needs to be reconsidered. this is done in the following by defining a notation meta-model which expresses an alternative idea of concrete syntax notation. the meta-model is completely developed from scratch and uses concepts of structured space and spatial locations as means for visually expressing semantics. it conceptualizes a mapping technique between the semantic concepts of a formal model on the one hand, and its visual appearance on the other hand. such a mapping associates the semantic content of a model with specific ways of visualization, and separates the notion of knowledge 3 / 12 volume 25 (2010) patterns as abstractions of spatial axes captured by a model from the way a visualization is created to communicate this knowledge and make it cognitively accessible. after performing this methodical division between semantic model and mapping to visualization, it becomes possible to concentrate on generally describing visualization techniques for models in an abstract way, independently from specific concepts reflected by models. a few approaches for conceptualizing mapping techniques for model-visualization have yet been proposed (e.g., [bel+07, esk07]). for practical purposes, the graphical modeling framework (gmf, http://www.eclipse.org/modeling/gmf/) contains a widely used pragmatic mapping approach in form of the gmfmap language. the mapping technique developed here understands describing model-visualizations as constructing abstract spaces into which symbolic objects are placed according to specific matching rules. this way, semantics is expressed by symbols occurring in spatial locations. each spatial occurrence of a symbolic object which expresses semantics is called an allocation in the proposed approach. in such a spatial setting, traditional distinctions made on the meta-type level, such as the notion of entities versus relationships, become expressable by multiple spatial alternatives. entities may straightforwardely be represented by symbols in space, allocated at locations related to axisintercepts that represent features of the entities. relationships can be expressed in the same way, if axis-intercepts represent other entities instead of feature values. nesting view-spaces inside each other (see sect. 4.7) is another way for representing relationships. as a third option, a relationship may be explicated by placing a symbol via an allocation in space, if the allocation references at least two abstract axes with intercepts refering to entities. it is worth noting that by reconsidering meta-types such as “entity” or “relationship” in spatial terms, the dichotomy between both concepts blurs, since both become conceptually exchangeable in the way they are handled and expressed by means of allocations. the idea of space in the model is kept as abstract as possible and is not restricted to euclidian, homogeneous, continuous 3d spaces. instead, spaces are modeled to be spawned by an arbitrary number of abstractaxes. an abstractaxis is any construct that maps the state of a given semantic element (e.g., an attribute value or a combination of values of an object instance) onto axisintercepts, which in turn can be transformed to physical spatial coordinates in a view-space (in german: anschauungsraum). a view-space is a 1-dimensional to 3-dimensional euclidian space, addressable by real-number coordinate vectors in well-known euclidian geometrics. in the most simple case, a spatial mapping from semantic model elements to euclidian coordinates is performed by a numericaxis which reads a numeric value from a semantic element's attribute and, without further transformation, directly places this real number into one coordinate component of a view-space's coordinate. figure 1 gives an example of such a view-space configuration in a notation model. using 2 or 3 axes of this kind allows for simple, direct spatial visualization of real-numbers provided by the semantic element. another simple case are symbolically ordered axes. a symbolicaxis associates string values from a semantic element with discrete axis intercepts in the conceptual space. it then can convert these discrete symbolic values to real-number values by calculating coordinate-positions from axis-intercepts of the symbolic values. an example of using a combination of a symbolicaxis together with numericaxes in a model notation's view-space is shown in fig. 2. when combined with other types of axes as part of a compositeaxis, the resulting view-space dimension can proc. vffp 2009 4 / 12 http://www.eclipse.org/modeling/gmf/ eceasst axis 1 : { coord x = obj.getxval(); } axis 2 : { coord y = obj.getyval(); } axis 3 : { coord z = obj.getzval(); } 1 2 3 4 1 2 3 4 1 2 3 4 obj:mytype1 float x=3f,y=4f, z=1.5f; ... float getxval(); float getyval(); float getzval(); ... 5 6 figure 1: example of using numericaxes in a spatial model-notation for direct coordinate mapping provide additional structure, such as non-equally sized axis-intercepts according to additional cirteria. more complex situations are possible where one abstract axis influences more than one realnumber coordinate component in the view-space, or multiple interdependent abstract axes cooperate to commonly generate one view-space coordinate entry. the number of abstract axes in an abstract space, and the number of euclidian axes in a view-space, thus are not necessarily equal. a more complex example of using conceptual axes is shown in fig. 3. here, one conceptual axis which represents a centerperipherypattern, maps onto 2 physical dimensions in the view-space. the centerperipherypattern conceptually behaves as any abstractaxis: it maps a semantic element's state to a physical location in the view-space. in the conceptual space, thus patterns and axes are treated equally. they only differ with respect to the way they are later visualized in a view-space. besides using values from the semantic element to calcluate the view-space coordinate, the centerperipherypattern may also apply internal rules for equally distributing symbols inside the “center” area or the “periphery” area. such an active behaviour of patterns is part of their ability to invoke understanding through spatial constellations. figure 4 gives another example of the use of a pattern as abstractaxis. the grouppattern locates semantic element according to a set of distinguishable attribute values, and groups together elements with identical values, while keeping those with distinct values apart from each other. in order to utilize the results on conceptualizing model notations for novel kinds of modeling languages and tools, the proposed concepts for expressing notations are now to be incorporated into an overall formal notation meta-model. the notation meta-model prepares the development of corresponding software modeling tools for pattern-based model visualizations. 5 / 12 volume 25 (2010) patterns as abstractions of spatial axes axis 1 : { coord x = obj.getxval(); } axis 2 : { coord y = obj.getyval(); } axis 3 : { coord z = axis.intercept( obj.getgroup() ); } 1 2 3 4 accounting sales production management obj:mytype2 float x=3f,y=4f; str grp='sales'; ... float getxval(); float getyval(); str getgroup(); ... 1 2 3 4 5 6 figure 2: example of using a symbolicaxis, combined with two numericaxes 4 a formal meta-model for model visualizations based on spatial concepts based on the previously elaborated concepts, an overall spatial notation meta-model has been formalized. it consists of three main parts specifying views, axes and allocations, which are described in the following. 4.1 views elements in the first group, views, each specify entire model notations, e.g., to be displayed inside one editor window of a software modeling tool. each view consists of 1 to 3 physical dimensions which are the euclidian axes of the view-space. every location of this euclidian space is described with vectors of real number values as coordinate-vectors. by mapping conceptual abstract axes onto the physical dimensions of the view-space, a structure is induced in the view-space, into which symbols can be placed meaningfully. when the view is rendered, this structure gets filled with allocations derived from the concrete model instance displayed. 4.2 axes the declaration of axes happens in an independent axes-section, which is the second main part of the overall viewmapping model. by separating the declaration of axes from the declaration of axismappings, which are specific to individual views, axes can be reused in multiple views throughout the whole viewmapping model. conceptual axes metaphorically spawn a conceptual space inside which knowledge is represented by identifying locations based on semantic features, i.e., by specifying allocations. to proc. vffp 2009 6 / 12 eceasst pattern 1 : { coord x = pattern.transformx( obj.iscenter() ); coord z = pattern.transformy( obj.iscenter() ); } axis 2 : { coord y = obj.getyval(); } obj:mytype3 float y=2.5; bool centr=true; ... float getyval(); bool iscenter(); ... 1 2 3 4center periphery 5 6 figure 3: example of using a centerperipherypattern as conceptual axis, combined with one numericaxis display elements from the conceptual space inside a physical view-space, axismappings are specified. they bind conceptual abstractaxes to physical dimensions in a view-space. it is up to the algorithmic implementation of an abstractaxis' maptoviewbounds()-method how to relate to physical dimensions with real value coordinates. the relationship between a logical abstractaxis and dimensions is to be understood as general as possible, which means that one abstractaxis may, if desired, be mapped onto more than one physical dimension. the mapping can also be specified in any possible way. this means, any abstractaxis may in principle modify the real-value components of a view-space coordinate-vector in any aspect, no matter which dimensions are assigned to the abstractaxis. 4.3 atomic axes multiple subtypes of abstractaxis can be distinguished. an abstractaxis can be an atomicaxis, which represents a semantic element's feature that is to be expressed in spatial terms. when expressing semantics using allocations, symbols are placed at locations relative to intercepts of atomicaxes. this is done through allocationmappings, see below. any atomicaxis is either a basicaxis, which is an axis that can be mapped to exactly one physical dimension, or a pattern. patterns carry all conceptual features of an atomicaxis, but potentially map onto any arbitrary number of dimensions. three concrete realizations of basicaxes are proposed by the model, which are described in the following. numeric axis a numericaxis maps a numeric feature from a semantic element, or the result of an ocl statement which returns a numeric value, onto a single dimension of a view-space. it can either 7 / 12 volume 25 (2010) patterns as abstractions of spatial axes axis 1 : { coord x = obj.getcosts(); } 1 2 3 4 accounting sales production management obj:department float costs=3; str grp='sales'; ... float getcosts(); str getgroup(); ... pattern 2 : { coord y = pattern.transformx( obj.getgroup() ); coord z = pattern.transformy( obj.getgroup() ); } figure 4: example of using a grouppattern as conceptual abstract axis, combined with one numericaxis be configured to represent a continuous, real-value addressable, homogeneous 1-dimensional number line, or a sequence of distinct intercepts representing integer values. when configured to operate with real-values, the semantic notion of a numericaxis in conceptual space matches directly the notion of a euclidian physical dimension in the view-space. symbolic axis symbolicaxes represent an ordered sequence of distinct intercepts which hold symbolic string values. coordinate values for each intercept are calculated via the maptoviewbounds()method by multiplying the visual intercept size with the index position of the intercept. entity axis an entityaxis represents a set of entities with its intercept values. any set of objects in a model, e.g., any multi-value collection, can be chosen to be lined up as intercepts of an entityaxis. the set of values is specified using the interceptexpression attribute. since the notion of a sequence of intercepts may require to explicate a sorting order of elements, an entityaxis can carry a reference to a comparator class, which may define the sorting order. 4.4 composite axes compositeaxes act as combinations of other axes. a compositeaxis derives its intercept values, either numerical or symbolical intercepts, from other axes and combines them. concrete subtypes of compositeaxis describe different combination strategies. three concrete subtypes proc. vffp 2009 8 / 12 eceasst are initially suggested by the notation meta-model. this set of combination strategies can be extended, if required. the first kind of suggested compositeaxis is the concat axis. this combines an arbitrary number of axes sequentially. another axis composition is join, which resembles the traditional notion of a join in relation theory, i.e., represents a complete one-to-one pairing of each members of the joined axes. a mix composition treats all intercepts of combined axes as one flat set and sorts them sequentially on a combined axis in the order specified by a comparator description. the combination of axes can be recursively applied, i.e., compositeaxes themselves can again be part of compositions of axes, which makes compositeaxes a highly expressive concept for describing the structure of conceptual spaces for model notations. 4.5 patterns patterns in the proposed notation meta-model behave like axes in the sense that they locate semantic elements in conceptual spaces, and are able to transform these conceptual locations to physical real-number coordinates. patterns constitute a conceptual space [gär00] in which meaning is expressed by orientation and navigation in the same sense as axes do. this is achieved because patterns provide meaningful places. spatial axes do the same, they unfold a space and provide means of orientation and navigation by consisting of intercepts which are associated with meaning through semantic allocations. in order to demonstrate the potential uses of the pattern concept specified by the model, a set of concrete subclasses of the pattern class is suggested within the notation meta-model. they are briefly explained in the following. this is a heuristic collection of initially chosen patterns and not limited to the proposed examples. an elaboration of the list of patterns may draw upon theoretical work from diagrammatic reasoning research (e.g., [cfo93]). group pattern one suggested pattern is the grouppattern, which clusters semantic elements according to attribute values. elements with identical values are grouped together, while keeping a distance between elements with different values. it is up to heuristics of the implementation how to choose coordinates to display grouped symbols in a view-space and how to spread clusters of symbols across the available space. spread pattern the spreadpattern serves for equally distributing multiple elements in the view-space to make them distinguishable. it does not map a specific attribute of a semantic element to a location in space, but operates on all semantic elements that are mapped via an allocationmapping onto the spreadpattern. semantically, the spreadpattern allows for expressing a general notion of overview and distinctness, in opposition to notions of detail and a fine-grained perspective. 9 / 12 volume 25 (2010) patterns as abstractions of spatial axes center-periphery pattern sometimes, the notion of a central place with a surrounding area helps to express unbalanced oppositions such as major/minor dichotomies or whole/part relationships. the centerperipherypattern serves for placing elements according to a boolean condition into the notion of a “center” place, or allocates them to a “periphery” area. the pattern may typically be mapped onto 2 physical dimensions to allow a circular representation of the center area and a surrounding periphery. however, it can as well be mapped onto one single dimension, where a center part and two surrounding periphery ranges are possible to displaye. the notions of center and periphery can also be expressed in a 3-dimensional sphere-structure. sequence pattern by applying a sequencepattern, semantic elements are aligned into one direction at equidistant positions in the view-space. the typical use-case is to bind this pattern to exactly 1 physical dimension, however, the implementation of the pattern might also offer to visualize sequences in 2 or 3 dimensional space, which would allow for bind the sequencepattern to any number of possible view-space dimensions. repetition pattern a repetitionpattern indicates a cyclic constellation in a model. this semantic device may be realized by diverse graphical representations, e.g., by circular shapes. random pattern the randompattern places elements randomly in the view-space. the elements are spread across the subspace spawned by those dimensions onto which the randompattern is mapped. the number of physical dimensions that can be mapped onto the pattern ranges from 1 to 3, since naturally any number of dimensions can be chosen to be randomly set. 4.6 allocations the third main section in the notation meta-model is the allocations branch. allocations map the state of semantic elements to locations in the conceptual space spawned by abstractaxes, and place a symbol or a nested view (see sect. 4.7) at this location. by relating the state of semantic elements’ features to abstract axis intercepts, allocations describe an abstract notion of locations in space without having to refer to numeric coordinatevectors. locations in the conceptual space can be understood as spatial means for expressing semantic elements' states, and thus are not limited to fulfilling structural features such as homogenicity or continuity, which are typically associated with the notion of a three-dimensional euclidian space. proc. vffp 2009 10 / 12 eceasst 4.7 nested views allocations can optionally nest views inside each other. they thus provide a way to recursively apply the concept of mapping abstractaxes to physical dimensions via axismappings in a nested subspace. if the innerview relationship is specified for an allocation-instance in a notation model, the allocation will not directly map semantic elements to graphical symbols at the place described by the allocation, instead, it will place a nested inner view at this location. figure 5 shows the part of the notation meta-model which defines the discussed axes concepts. the model has been created using the ecore modeling language, which is part of the eclipse modeling framework (emf, http://www.eclipse.org/modeling/emf/). figure 5: partial notation meta-model suggested by the presented approach 5 summary and future perspectives this article has presented a formal language for describing visual model-notations, which incorporates the notion of patterns as language elements in formal visualization descriptions. this research provides the basis for further elaborating a modeling method which uses spatial means of semantic expression to model complex interdependent systems, as they are being dealt with in computer science and information systems. besides providing the notation model language and a description of the process to be applied, the method should also be supplemented with prototypical software tool support. an implementation of the presented language, including an editor for notation models and a visualization generator which operates on these models, is planned to be developed on top of the eclipse modeling framework. references [bel+07] s. buckl, a. ernst, j. lankes, f. matthes, c. m. schweda, a. wittenburg. generating visualizations of enterprise architectures using model transformation (extended version). enterprise modelling and information systems architectures 2(2):3–13, 2007. 11 / 12 volume 25 (2010) http://www.eclipse.org/modeling/emf/ patterns as abstractions of spatial axes [ber84] j. bertin. semiology of graphics: diagrams, networks, maps. university of wisconsin press, madison, 1984. [cfo93] e. clementini, p. d. felice, p. van oosterom. a small set of formal topological relationships suitable for end-user interaction. in proceedings of the third international symposium on advances in spatial databases. pp. 277–295. springer, london, 1993. [esk07] s. eicker, t. spies, c. kahl. software visualization in the context of serviceoriented architectures. in proceedings of the 4th ieee international workshop on visualizing software for understanding and analysis (vissoft2007). pp. 108–111. alberta, canada, 2007. [fra02] u. frank. multi-perspective enterprise modeling (memo): conceptual framework and modeling languages. in proceedings of the 35th hawaii international conference on system sciences (hicss-35). ieee computer society press, honolulu, 2002. [gal05] s. gallagher. how the body shapes the mind. oxford university press, oxford, 2005. [gär00] p. gärdenfors. conceptual spaces. mit press, cambridge, 2000. [goo68] n. goodman. languages of art. an approach to a theory of symbols. harvester press, sussex, 1968. [gul08] j. gulden. semantik in visuellen modellen: räumliche regularitäten und körperliche erfahrungsmuster als bedeutungsträger visueller modelle. in reichle et al. (eds.), visuelle modelle. wilhelm fink verlag, münchen, 2008. [jl80] m. johnson, g. lakoff. metaphors we live by. university of chicago press, chicago, 1980. [joh87] m. johnson. the body in the mind. university of chicago press, chicago, 1987. [noë04] a. noë. action in perception. mit press, cambridge, 2004. [pei31] c. s. peirce. collected papers of charles sanders peirce. volume 3. harvard university press, cambridge/mass., 1931. [put75] h. putnam. the meaning of “meaning”. in gunderson (ed.), language, mind and knowledge. pp. 131–193. university of minnesota press, minneapolis, 1975. [tuf83] e. r. tufte. the visual display of quantitative information. graphics press, cheshire, connecticut, 1983. [wil02] m. wilson. six views of embodied cognition. psychonomic bulletin & review 9(4):625–636, 2002. proc. vffp 2009 12 / 12 pattern-based semantics in models and scientific theories in search of a semantic theory able to cope with patterns incorporating pattern-based semantics into formal modeling techniques a formal meta-model for model visualizations based on spatial concepts views axes atomic axes composite axes patterns allocations nested views summary and future perspectives re-engineering eclipse mdt/ocl for xtext electronic communications of the easst volume 36 (2010) proceedings of the workshop on ocl and textual modelling (ocl 2010) re-engineering eclipse mdt/ocl for xtext edward willink 15 pages guest editors: jordi cabot, tony clark, manuel clavel, martin gogolla managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst re-engineering eclipse mdt/ocl for xtext edward willink1 1 ed at willink.me.uk, http://www.eclipse.org/modeling eclipse modeling project abstract: the current tooling used for the eclipse ocl project uses an lalr parser generator. enhancing the tooling to support editing motivated a migration to exploit the inherently model-driven characteristics of xtext. this paper summarizes the experiences of that migration, identifies the many benefits and discusses a few changes in implementation approach that were required. objective performance and size comparisons between the old lalr and new xtext approach are provided. keywords: ocl, meta-model, editor, xtext, lalr, lpg, asg, ast, csg, cst 1 introduction the object constraint language (ocl)[objc] evolved, initially within the unified modeling language (uml)[obje], to capture modeling constraints that were inappropriate to express graphically. it was recognized that the textual modeling expression language had utility beyond uml and so ocl 2.0 was separated out when uml 2.0 was proposed. the benefits of this separation have become clear in the last few years as ocl forms the basis for alternate modeling specifications such as the model to text transformation language mofm2t[objb], and the query/view/transformation (qvt)[objd] model to model transformation languages. the eclipse foundation provides a platform and framework for industry1 and researchers that supports a wide variety programming activities. in the modeling domain, the eclipse modeling framework (emf) project provides the widely used ecore foundation. although ecore was originally for java-based code generation, the use of ecore to define meta-models has come to underlie a wide variety of different eclipse modeling projects. more generally ecore is used to define its own meta-model and the eclipse support for the uml meta-model. many eclipse projects endeavor to support specifications such as uml, ocl, qvt and mofm2t defined by the object management group (omg). the eclipse ocl[mdt] support has provided basic ocl for parsing and evaluation for many years, but this support has been primarily suitable for those keen to access it from their java code. the advent of more powerful modeling tools, that do not require java coding, motivates a more user friendly editing and evaluation environment for ocl within eclipse. a very fundamental tool for developing code in any language is a text editor with rich and semantic editing capabilities. a first attempt at an eclipse editor extended the generic text editor facilities, but required a substantial number of repetitive manually coded classes to capture the editing semantics, and each aspect of a rich editor required integration effort. 1 all eclipse code is made available under the eclipse public license (epl) avoiding the problems that arise with the gnu public license (gpl). the epl open source license and eclipse’s ip diligence avoid intellectual property (ip) uncertainty. 1 / 15 volume 36 (2010) mailto:ed _at_ willink.me.uk http://www.eclipse.org/modeling re-engineering eclipse mdt/ocl for xtext figure 1: parsing activities. the next attempt used the ide meta-tooling platform (imp)[imp], which saved much of the repetition by providing integration with the grammar tooling. this provided most of the support for many rich editing facilities. however, ip problems prevented this editor being shipped in the eclipse helios[hel] release and so a rapid redevelopment was required to avoid dependence on an unreleased project. in addition to the support for omg specifications, eclipse projects provide useful complementary facilities. one of the successful eclipse incubation areas has been support for domainspecific languages (dsls), for which the xtext[tmf] tool successfully uses little more than the language grammar to provide a fairly comprehensive editing capability that can be tailored to provide really high quality capabilities. although ocl is perhaps a general purpose rather than domain-specific language, the need for a rapid redevelopment motivated the use of a dsl tool. in this paper we describe this redevelopment, and since this is a redevelopment of a real language, we are able to provide realistic contrasts between the more traditional parsing approaches and the revised approaches required by xtext and, behind the scenes, antlr [ant]. we first review the basic parsing activities and see how the old tools supported it, then we see how xtext provides much simpler and more powerful mechanisms that do much more. the redevelopment was not always straightforward and so we then describe areas where xtext required a different approach to be adopted. finally we conclude with some performance metrics contrasting the traditional and the xtext implementations. the code for both implementations is available as part of the eclipse helios release. the basic eclipse ocl installation provides just the old approach. installation of the optional mdt/ocl examples provides the new xtext editors that use the new xtext approach2. 2 background figure 1 shows the typical parsing activities involved in converting the bytes of a file containing text in some language to the abstract syntax graph (asg)[asu86] for that language. lexical analysis by a lexer combines byte sequences into tokens, then syntactic analysis in the parser establishes a hierarchical structure that is represented by a concrete syntax tree (cst). for very simple languages, that can be described by an abstract syntax tree (ast) rather than 2 install the modeling / ocl examples and editors feature from the http://download.eclipse.org/releases/ helios/ update site. proc. ocl 2010 2 / 15 http://download.eclipse.org/releases/helios/ http://download.eclipse.org/releases/helios/ eceasst graph, there may be no need for analysis to convert the cst into the asg; cst and asg may then be identical. for more interesting languages, such as ocl, significant semantic analysis is required to create the asg from the cst. the successive representations shown as shaded squares conform to corresponding metamodels, although the first two for bytes and strings are perhaps too trivial to merit such a description. in order to appreciate the benefits of using xtext to define a grammar (and cst), it is necessary first to present some excerpts of the more traditional lalr[asu86] implementation using lpg[lpg]. please note that for both lpg and xtext, the examples in this paper are simplified to remove extraneous concerns. 2.1 basic lpg grammar and action code an lalr grammar permits considerable precision in parsing some of the ambiguities in a grammar such as ocl. however the parse performs only syntactical analysis and so the result is a concrete syntax tree that requires significant semantic analysis to create the abstract syntax graph required by the ocl specification3. since the cst closely resembles the grammar, a simple bnf[asu86] clause to define the grammar for a collection range such as 1..10 might be collectionrangecs ::= oclexpressioncs ’..’ oclexpressioncs unfortunately this has to be augmented by significant action code to populate the cst: collectionrangecs ::= oclexpressioncs ’..’ oclexpressioncs /.$begincode collectionliteralpartcs result = createcollectionrangecs( (oclexpressioncs)getrhssym(1), (oclexpressioncs)getrhssym(3) ); setoffsets(result, (cstnode)getrhssym(1), (cstnode)getrhssym(3)); setresult(result); $endcode ./ the action code is very repetitive with many opportunities for error. left recursions produce similarly repetitive code when defining the grammar for a collection literal such as the body of sequence{1,2,3,4}. collectionliteralpartscs ::= collectionliteralpartcs /.$begincode elist result = new basicelist(); result.add((collectionliteralpartcs)getrhssym(1)); 3 the asg is called an ast in the ocl specification. 3 / 15 volume 36 (2010) re-engineering eclipse mdt/ocl for xtext setresult(result); $endcode ./ collectionliteralpartscs ::= collectionliteralpartscs ’,’ collectionliteralpartcs /.$begincode elist result = (elist)getrhssym(1); result.add((collectionliteralpartcs)getrhssym(3)); setresult(result); $endcode ./ while these examples are for lpg, similar overheads apply to yacc/bison, cup, javacc, sablecc or antlr. for lpg, manual definition of • a two-part keyword and lexer grammar with action code • a parser grammar with substantial action code is required and then lpg auto-generates • a two-part lexer • a parser. no assistance is provided with the cst or asg meta-models, analysis rules or well-formedness rules. since lpg doesn’t understand the cst, all aspects of the parser that interact with the cst must be contributed within the action code. 2.2 basic xtext grammar and ‘action code’ the major innovation of xtext is that it is model-driven, so xtext understands the cst metamodel and as a result can auto-generate many additional facilities. by default, xtext autogenerates the cst meta-model from the grammar, but allows an externally defined meta-model to be used if required. for xtext, manual definition of • a parser grammar with cst meta-model annotations is required and then xtext auto-generates • a lexer • a cst meta-model • a parser that populates the cst • a pretty printer to translate the cst to the dsl proc. ocl 2010 4 / 15 eceasst • a rich editor that maintains the cst in its dsl representation • a framework for customization so for less manual input than for lpg, xtext provides much more auto-generated output. as will be seen in the following examples, it is not just less input, it is 80% less input. with xtext, the cst for collectionrangecs (and also collectionitemcs) can be generated automatically from the following 3 lines rather than the 10 above: collectionliteralpartcs: expressioncs=expcs (’..’ lastexpressioncs=expcs)? ; here the ‘action code’ comprises the two assignments to cst properties, as a result of which the collectionliteralpartcs in the cst meta-model class has expressioncs and lastexpressioncs properties. the maintenance of lists is also simplified from 16 lines to 6. collectionliteralexpcs: typecs=collectiontypecs ’{’ (collectionliteralparts+=collectionliteralpartcs (’,’ collectionliteralparts+=collectionliteralpartcs)*)? ’}’ ; here the bnf extensions to support +,* and ? repetition are augmented by the ‘action’ extension += for assignment to a collection property. a further ?= extension supports assignment to a boolean property. these improvements give a significant reduction in line count for the grammar. in the xtext version there is little redundancy and all symbols are subject to validation within the xtext editor. in the lpg version, some symbols are not checked until java code is compiled and many inconsistencies are only detected by run-time malfunction. the xtext version is therefore not only much smaller, but more thoroughly checked by tooling, and of course able to auto-generate much more functionality. 2.3 cross-references few languages parse to pure trees; there are inevitably cross-references to accommodate the requirement for a graph. resolution of these references is not accommodated in a traditional parser whose cst just stores the identifier sequence for a path-name such as a::b::c. locating the model elements for a, b and c is one of the tasks performed by the semantic analyzer as it converts the identifier string in the cst to an element cross-reference in the asg. the simplified lpg grammar for a qualified name such as a::b::c is: pathnamecs ::= identifier ... pathnamecs ::= pathnamecs ’::’ identifier ... 5 / 15 volume 36 (2010) re-engineering eclipse mdt/ocl for xtext in xtext, the cst is actually a concrete syntax graph (csg) since it contains model element cross-references rather than strings. the graph-like relationships enable the auto-generated editor to offer many richer model-driven functionalities such as completion-assist and hyper-linking. a csg is clearly more like an asg than a cst is, so for some languages, it may be possible to dispense with a separate analyzer pass for csg to asg conversion. support for references is provided by the [type|token] syntax which parses for a lexical ‘token’ and then performs analysis for a semantic ‘type’. the correspondingly simplified xtext grammar is: pathnamecs returns pathnameexpcs: (namespace+=[namespace|identifier] ’::’)* element=[namedelement|identifier] ; here an arbitrary number of identifier ’::’ prefixes may precede an identifier. the prefixes are each analyzed as namespace and the pathnameexpcs::namespace feature accumulates them. the final identifier is analyzed as a namedelement and assigned to the pathnameexpcs::element feature. the namespace and namedelement classes are part of the asg, and their instances may be either objects created by conversion of the csg to the asg or objects imported from an external model. xtext is able to auto-generate a default analyzer using hierarchical containment to define scoping, however most real languages have rather more sophisticated scoping and visibility rules. xtext therefore provides a variety of techniques to support customization to solve this and other problems. for the complete ocl grammar, these techniques are used to define the csg to asg manually. 3 changes of approach with semantic analysis integrated into the grammar, the auto-generated parser maintains a csg that is much closer to an asg than is traditional. this increase in capability inevitably requires that some aspects of traditional approaches need revisiting. we will therefore now describe areas where it was necessary to adopt a different approach when using xtext. 3.1 left recursion lalr grammars are traditionally written in left recursive style. multiplicativecs ::= unarycs multiplicativecs ::= multiplicativecs ’*’ unarycs ... multiplicativecs ::= multiplicativecs ’/’ unarycs ... proc. ocl 2010 6 / 15 eceasst a repeated term such as 8/4/2 is parsed first by reduction4 of 8 via unarycs and then via multiplicativecs. this is followed by reduction of 4 via unarycs so that a further multiplicativecs reduction gives the multiplicativecs for (8/4). finally after reduction of 2 via unarycs, reduction of multiplicativecs gives a multiplicativecs for ((8/4)/2). this resolves precedence and associativity in accordance with typical language specifications and makes as much progress as possible with ‘shift’ transitions along the rule before a ‘reduction’ at the end of the rule. lalr grammars parse alternate syntax hypotheses concurrently for ‘shift’s but require only one alternative to remain valid for the ‘reduction’. antlr, and consequently xtext, supports only right recursion and so the corresponding right recursive exposition in xtext would parse 8/4/2 as 8/(4/2) rather than (8/4)/2. this mis-parse is predictable and so could be corrected during the csg to asg conversion. however xtext’s extended bnf comes to the rescue for practical use cases. multiplicativecs: unarycs ((’*’|’/’) unarycs)*; this extends the higher precedence unarycs with an arbitrary repetition of equi-precedence terms. in detail, showing the full ‘action code’ complexity. multiplicativecs returns expcs: unarycs ({infixexpcs.source=current} op=(’*’|’/’) argument=unarycs)* ; the expcs return type is now non-trivial since a multiplicative expression may be one of a wide variety of alternate csg node types. for the simple parse of just a unary expression, the unarycs provides an appropriately typed term that is just ‘returned’ unchanged. for the more interesting case where a multiplicative operator is present, a csg node must be constructed to capture the left-operator-right context. xtext provides special support for this, through the {} action clause, that first defines infixexpcs as the required type of the constructed csg node, and then assigns the left node to the source property from the current csg context. the operator and right nodes are assigned in more obvious fashion to op and argument properties. what could have been a significant xtext limitation appears in practice to once again offer a significant saving compared to the lalr approach. the (’*’|’/’) and recursion save a couple of lines. 3.2 overlapping syntaxes it is difficult to create a parser for the ocl grammar for a variety of reasons. one of these is the status of names. for instance, under what circumstances may string, set, collect, self or true be used as ordinary names as in: java::lang::string, values.collect or mytest.true? the ocl 2.2 specification is not clear and so implementers are forced to use intuition. the resolution of issue 14583[obja] for the ocl 2.3 specification is influenced by experience extending the eclipse ocl implementation for re-use by qvt. iterator names are 4 the reader is referred to [asu86] for a description of shift and reduce transitions. 7 / 15 volume 36 (2010) re-engineering eclipse mdt/ocl for xtext not reserved at all, avoiding any impediment to extension with new names. self and true are totally reserved. string and set are restricted, that is they are reserved except when qualified as in mine::set. with iterator names unreserved, the parser must use lexical structure rather than a keyword to distinguish the iterator and operator call syntaxes. in simple cases such as any(), this is impossible and so resolution must be deferred to the semantic analysis of any. for the more complex case of a.b(c,d, the syntax of b is determined by the token following d: • a.b(c,d|e) is an iterator expression • a.b(c,d,e) is an operation call this can be resolved by an lalr grammar without recourse to precedence rules, provided a ‘reduce’ is avoided. this is awkward since for an operation call c and d may be arbitrary expressions, while for an iterator call they may be variable declarations. it is only when both take their simplest form of just a name that the ambiguity arises: • a.b(c : string,d is obviously iterator syntax • a.b(c*2,d is obviously operation syntax. distinguishing an expression that is just a name from all other expressions is awkward but possible as shown by the lalr(1) grammar in the resolution of issue 10439[obja] for the ocl 2.3 specification. this, perhaps too subtle, precision is just too hard for an xtext (antlr-based) ll grammar to achieve directly. ll tools therefore provide backtracking support and by enabling backtracking in xtext, it is then possible to parse for a more generalized operator call roundbracketexpcs returns roundbracketexpcs: name=nameexpcs (’@’ pre?=’pre’)? ’(’ (variable1=iteratorvariablecs ((’,’ variable2=iteratorvariablecs) |(’;’ variable2=iteratoraccumulatorcs))? ’|’)? (arguments+=expcs (’,’ arguments+=expcs)*)? ’)’ ; here iterator variables optionally precede operation arguments. the parser backtracks if its first attempt to parse iterator variables fails to terminate in a |. the semantic analyzer is left to determine whether the name preceding the parentheses references an operator or iterator definition and whether the number and type of iterator variables and arguments are appropriate to the declaration. since the generalized production rule allows @pre on any call, the semantic analyzer must also validate whether such usage is appropriate. proc. ocl 2010 8 / 15 eceasst 3.3 restricted words a frequently asked question for xtext is how to use of a keyword as both a reserved word and as an identifier. context a::b -context is a keyword self.context -context is an identifier at first sight it appears that the use of ’context’ as a keyword in the grammar precludes the use of context by the id terminal, since the default lexer uses id only when there is nothing more specific. however xtext augments the traditional terminal and production rules with an intermediate datatype rule that can merge terminal rules. thus in: terminal id:(’a’..’z’|’a’..’z’|’_’) (’a’..’z’|’a’..’z’|’_’|’0’..’9’)*; restrictedkeyword: ’context’ | ’package’; identifier: id | restrictedkeyword; id is a terminal rule that defines the behavior of the auto-generated lexer. restrictedkeyword is a datatype rule identifying a list of two grammar keywords. identifier is a further datatype rule merging the lexer terminal with the grammar list. the remainder of the grammar can refer to identifier without worrying about whether the name overlaps a distinct token. this provides a very simple solution, but unfortunately has a very bad effect on the sizes of the generated grammar. the complete ocl grammar has 14 keywords that need treatment in this fashion. unfortunately only 9 can be defined this way before the generated antlr grammar hits the 64 kb java method size limit. this occurs for xtext 1.0.0. it is difficult to believe that this is a fundamental limitation of the antlr technology, so hopefully this problem will go away in a future release. 3.4 complex references in real languages, the type reference in a declaration such as name : type may be a simple name boolean or constructed tuple{name:string,values:sequence(real)}. the absence of a bound on the nesting depth of tuples and collections leads to potentially unlimited complexity. supporting this diversity provides a dilemma to meta-model developers. on the one hand the common use case of a simple reference is efficiently satisfied by a shared reference, while on the other hand the complex construct mandates a tree of composed objects whose root requires an owner. identifying a suitable owner is a further dilemma. figure 2 shows the simplest solution in which both a shared and a composed reference are provided but only one is used. this solution is adopted by uml for the reference from a templateparametersubstitution to its actual parameter. unfortunately there is always one redundant model element and common sub-trees are awkward to share. equivalent usages in the ocl specification omit the composed reference avoiding the redundancy but the result is that complex types just magically exist without a clear specification as to how they are persisted. 9 / 15 volume 36 (2010) re-engineering eclipse mdt/ocl for xtext figure 2: shared and composed references. since the meta-model representation is difficult, it is not surprising that the difficulty appears in an xtext grammar as well. a type reference such as type=[typecs|identifier] in a grammar cannot accommodate a complex type. we could pursue the owned and not owned approach with (type=[typecs|identifier] | ownedtype=complextypecs), but this leaves the generated parser to resolve partial ambiguities between the two syntaxes. in practice with antlr technology, this means that one approach is attempted and if it fails backtracking is invoked and another alternative is attempted. at best this just costs parsing time through erroneous attempts. more of a concern arises when the first attempt succeeds because it is a prefix of the alternative; the parser then proceeds using the ‘wrong’ parse and perhaps fails during a subsequent alternative. it is not obvious that a parser may not have a non-linear growth of backtracking alternatives to examine. with xtext largely hiding the underlying antlr capabilities, it is not clear how an xtext grammar should be written to obtain predictable and efficient results. experience suggests that it is necessary to put more complex alternatives before simpler choices, since the complex can fail and back-track to the simple, but the converse of a false success of a simple choice does not backtrack. the uml-style double feature approach did not appear to work well and the ocl-style magical ownership has no corresponding xtext magic. the solution was to omit the shared reference and so treat all references as complex using ownedtype=typerefcs with typerefcs the abstract type of a family of type reference expressions. typerefcs : simpletyperefcs | complextyperefcs; // etc simpletyperefcs: type=[type|identifier]; complextyperefcs: type=[type|identifier] ’<’ ownedparams+=typerefcs (’,’ ownedparams+=typerefcs)* ’>’; this approach endeavors to use an appropriate meta-model representation without redundant features. this is probably a mistake, since as shown in the simplified example above, the alternative types often share a common prefix. the parser is forced to distinguish between rather similar alternatives which may contribute to some of the adverse parsing speeds reported later. since there is very little prospect of the csg structure for diverse references doubling up as the asg, it is inevitable that a slight restructuring transformation is needed between csg and asg. the minor aesthetic benefits of compact csg objects is probably misguided; fewer alternatives would simplify the parser, so in the above example, simpletyperefcs could be merged into complextyperefcs by making the ’<’ ... ’>’5 terms optional in 5 although ocl 2.2 does not support uml’s templated types, ocl aspires to uml alignment. this example is part proc. ocl 2010 10 / 15 eceasst complextyperefcs. an lalr parser would probably mandate this change in order to eliminate a shift-reduce conflict. the xtext tooling needs stronger diagnostic capability to advise on unwise grammar formulations. 4 performance 4.1 speed the speed of the two parsers was compared by timing the parse of an approximately 350 line complete ocl document based on the royalandloyal example. the first parse took 1.8 seconds with the lpg parser. 100 re-parses then averaged at 97 ms each. the first parse took 4.8 seconds with the xtext parser. 100 re-parses then averaged at 1114 ms each. comparison of the first parse time is not particularly helpful, since the measurement is quite variable, and is confounded by jvm start-up effects and the differing meta-model support. the lpg parse reads a total of two files, one for the complete ocl document and another for the meta-model; the ocl standard library is hard coded. the xtext parse reads six files; a file and a grammar for each of: the complete ocl document, the ecore meta-model and the ocl standard library. since the antlr grammars are huge, it is perhaps surprising that the xtext first parse is only 3 times slower. comparison of the re-parse times is much fairer, since the re-parses use cached meta-models and grammars. during each re-parse, lpg and xtext parsers read just the complete ocl document. the eleven-fold speed degradation for xtext is disappointing but not totally surprising. both lpg and xtext offer opportunities for improvement, but with xtext 1.0.0 being a very new product there are hopefully a few simple improvements that can be made before xtext considers switching to an lalr technology. disclaimer: the above measurements were made using the eclipse helios release of eclipse ocl (3.0.0) and xtext (1.0.0) projects. no thorough analysis of the performance differences has been made, so the above measurements do not distinguish whether it is the xtext parser or the mdt/ocl configuration of the xtext parser that is slow. informal observations suggest that there are many opportunities for caches to avoid repeated work in both projects. the test code for these speed tests is available as an attachment to https://bugs.eclipse.org/ 320703. 4.2 grammar size the example snippets above suggest that xtext provides a three-fold reduction in grammar size. when a full grammar is considered, the line count savings are more substantial, although there is always some uncertainty in terms of exactly what constitutes a line. the figures that follow are raw line count and so include every blank line and copyright notice, but since both sets of files use similar editorial styles, the comparative values should not differ greatly from an alternate of work to achieve alignment. 11 / 15 volume 36 (2010) https://bugs.eclipse.org/320703 https://bugs.eclipse.org/320703 re-engineering eclipse mdt/ocl for xtext metric based on information lines. the entire essential ocl grammar (both parser and lexer) requires a single 395 line xtext file; no further template or library files are re-used. the corresponding lpg support requires a 1485 line parser grammar, a 100 line lexer grammar and a 151 line keyword grammar. the parser extends a 785 line java class with a further 255 lines for a lexer class. the grammars rely on nearly 1000 lines of re-usable imported templates. it seems reasonable to summarize these figures as an at least 5-fold reduction in line count by using an xtext grammar. 4.3 parser size for the complete ocl grammar, the lpg grammars produce three java files for each the keyword, lexer and parser grammars; the total file size of all the parsing class files is 221 kb. this excludes the size of the semantic analyzer. the xtext auto-generates antlr grammars from which antlr generates many classes. after eliminating classes whose functionality supports semantic analysis, the total size of the class files is 2370 kb. the xtext parsers are therefore approximately ten times larger than their lpg counterparts. and unfortunately the editor does not re-use this grammar. the editor support involves a further 1 mb grammar. 5 further work 5.1 ocl re-use the ocl specification re-uses ocl to define constraints • disambiguation rules while constructing the cst, • name lookup and environment propagation within the cst, • asg construction from the cst, • well-formedness rules for the asg, • well-formedness rules for evaluations using asg anyone who studies these ocl constraints soon realizes that the constraints have never been subjected to a tool that provides syntactic, let alone semantic, checking. with so many basic lexical errors, what prospect is there that the constraints actually express the required functionality? the eclipse ocl realization of these constraints is distributed throughout the lpg parser, analyzer and validator as hand-coded java making it difficult to determine the correspondence with the specification, even if the specification was accurate. the xtext re-engineering has hand-coded scoping classes that bear a superficial resemblance to the ‘inherited attributes’ specifications and, as yet, no realization of the well-formedness rules at all. proc. ocl 2010 12 / 15 eceasst for the well-formedness rules, performance concerns seem the only deterrent to a validation implementation that directly executes the ocl constraints expressed in ocl. once the ocl specification is corrected to express the true intent, this would immediately demonstrate equivalence with the ocl specification. the performance concerns can be mitigated by an ocl code generator of modest quality and eventually removed by a high quality ocl to java code generator. referring back to figure 1, we have lexer and parser grammars, analysis and well-formedness rules defined in the ocl specification. the ocl specification is moving towards providing a more usable grammar that could be more obviously equivalent to the xtext exposition. if the ocl constraints defining the rules are used directly, we should get quite close to having ocl tooling fully defined in the specification in ways that are directly consumable by practical tooling. this should then ensure that the ocl present in the ocl specification accurately reflects the true requirements. 5.2 model-driven operators clause 9.3 of the ocl specification defines just the mapping of expression terms and operators from the cst to the asg. precedence is separately specified as a bulleted operator list and associativity is currently unspecified. this is discouraging to any implementer familiar with a grammar such as those for java or c where precedence is integral to the grammar. the ocl 2.2 specification resolved a precedence surprise whereby ocl 2.0 had equal precedences for and, or and xor, at the expense of introducing a compatibility surprise. an ocl tool may therefore want to provide users with a compatibility option. and more generally may want to allow addition of user-defined operators with user-defined precedences and associativity. perhaps the grammar could be generalized binaryexpression : unaryexpression (infixoperator unaryexpression)*; unaryexpression : prefixoperator* atomicexpression; the definitions of infixoperator could be provided as part of a customizable ocl ‘standard’ library model rather than being built-in to the parser. xtext of course makes development of a further editor for the ocl ‘standard’ library quite easy. 5.3 lpg compatibility unless xtext is able to come close to lpg speed, the eclipse ocl project has no alternative but to support two parsers; an lpg parser for speed and an xtext parser for use in interactive environments such as editors. the eclipse ocl project also has a compatibility obligation to its consumers, so the lpg interface cannot easily be discontinued. maintenance of two independent parsers and analyzers is not an attractive prospect. xtext uses xtext to define its own editor and grammar, so it should be possible to perform a model to model and then a model to text transformation on the xtext grammar for ocl and thereby auto-generate an lpg grammar with auto-generated action code to maintain a very similar csg model. 13 / 15 volume 36 (2010) re-engineering eclipse mdt/ocl for xtext this should give an xtext-defined lpg grammar avoiding the adverse performance of the antlr tooling and preserving the general principles of the existing parser and analyzer interface. re-expression of the xtext grammar in lalr form may also provide the missing diagnostics of unwise parser constructs. 6 conclusions re-engineering the eclipse ocl support to use xtext 1.0.0 rather than lpg 2.0.17 has demonstrated many of the powerful benefits that xtext offers. subjectively xtext is much better for common functionality and incomparably better because of the richer tooling and extra autogenerated functionality. objectively, the xtext version of the ocl grammar is at least 5 times smaller, but the generated parser is 10 times larger and 11 times slower. it is hoped that future releases of xtext can make significant reductions to the adverse comparisons. migration of lalr grammars to xtext required re-examination of the parsing approach and some policy changes that were perhaps merited anyway. xtext provides good diagnosis of syntactical and simple semantic errors in an xtext grammar. it is not clear that xtext provides adequate diagnosis of the unexpected results that may arise through the use of backtracking. with the aid of xtext and other modern tooling it may be practical to have ocl editor and parser tooling reusing the exposition of grammars and constraints in the ocl specification. acknowledgements: many thanks to sebastian zarnekow, adolfo sánchez-barbudo herrera and the anonymous reviewers for helpful comments on earlier versions of this paper. bibliography [ant] antlr, another tool for language recognition. http://www.antlr.org [asu86] a. v. aho, r. sethi, j. d. ullman. compilers. principles, techniques and tools. addison wesley, 1986. [hel] eclipse helios release. http://www.eclipse.org/downloads/ [imp] eclipse ide meta-tooling platform project. http://www.eclipse.org/projects/project summary.php?projectid=technology.imp [lpg] sourceforge lalr parser project. http://sourceforge.net/projects/lpg [mdt] eclipse mdt/ocl project. http://www.eclipse.org/projects/project summary.php?projectid=modeling.mdt.ocl proc. ocl 2010 14 / 15 http://www.antlr.org http://www.eclipse.org/downloads/ http://www.eclipse.org/projects/project_summary.php?projectid=technology.imp http://sourceforge.net/projects/lpg http://www.eclipse.org/projects/project_summary.php?projectid=modeling.mdt.ocl eceasst [obja] object management group. first ballot resolutions for object constraint language version 2.3, 2009. http://www.omg.org/archives/ocl2-rtf/msg00331.html [objb] object management group. mof model to text transformation language. v1.0, omg document number: formal/2008-01-16 edition. http://www.omg.org/spec/mofm2t/1.0 [objc] object management group. object constraint language. version 2.2, omg document number: formal/2010-02-01 edition. http://www.omg.org/spec/ocl/2.2 [objd] object management group. query/view/transformation specification. version 2.3, omg document number: ptc/09-12-05, 2009 edition. http://www.omg.org/spec/qvt/1.1/beta2/pdf [obje] object management group. unified modeling language, superstructure. version 2.3, omg document number: formal/2010-05-05 edition. http://www.omg.org/spec/uml/2.3 [tmf] eclipse tmf/xtext project. http://www.eclipse.org/xtext 15 / 15 volume 36 (2010) http://www.omg.org/archives/ocl2-rtf/msg00331.html http://www.omg.org/spec/mofm2t/1.0 http://www.omg.org/spec/ocl/2.2 http://www.omg.org/spec/qvt/1.1/beta2/pdf http://www.omg.org/spec/uml/2.3 http://www.eclipse.org/xtext introduction background basic lpg grammar and action code basic xtext grammar and `action code' cross-references changes of approach left recursion overlapping syntaxes restricted words complex references performance speed grammar size parser size further work ocl re-use model-driven operators lpg compatibility conclusions mobile csp"026b30d b electronic communications of the easst volume 23 (2009) proceedings of the ninth international workshop on automated verification of critical systems (avocs 2009) mobile csp‖b beeta vajar, steve schneider and helen treharne 17 pages guest editor: markus roggenbach managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst mobile csp‖b beeta vajar1, steve schneider2 and helen treharne3 1b.vajar@surrey.ac.uk 2s.schneider@surrey.ac.uk 3h.treharne@surrey.ac.uk department of computing, university of surrey, guildford, surrey, uk abstract: csp‖b is a combination of csp and b in which csp processes are used as control executives for b machines. this architecture enables a b machine and its controller to interact and communicate with each other while working in parallel. the architecture has focused on sequential csp processes as dedicated controllers for b machines. this paper introduces mobile csp‖b, a formal framework based on csp‖b which enables us to specify and verify concurrent systems with mobile architecture instead of the previous static architecture. in mobile csp‖b, a parallel combination of csp processes act as the control executive for the b machines and these b machines can be transferred between csp processes during the system execution. the paper introduces the foundations of the approach, and illustrates the result with an example. keywords: csp, b, mobility 1 introduction numerous methods which combine state and event based models have been proposed: zccs [gs97], csp-oz [fis97], circus [ocw07], csp2b [but00], prob [lb03] and csp ‖ b [ts02, st05]. their advantage is that complex systems can be described and their verification ensures consistency of the models. some integration, e.g., pioz [tdc04] and π | b [kst07], support the description of mobility and dynamic patterns. this additional functionality is suitable for modelling agent systems or peer-to-peer networks where consideration of mobility is important. in this paper, we are interested in extending our csp ‖ b approach to include mobility and we have developed a formal framework so that we can compositionally verify the consistency of csp ‖ b specifications that include mobile aspects. this allows us to extend the range of specifications that we can write in csp ‖ b and retains our philosophy of not changing the underlying csp [sch00, hoa85] and classical b [sch01, abr96] semantics. the framework adopts similar concepts to the architecture proposed in π | b. however, π | b was limited to systems without inputs and outputs and was restricted to a framework to support divergence freedom verification. in this paper, we can deal with specifications that contain inputs and outputs and in addition to divergence freedom we can check for deadlock freedom. these two checks are the minimum verification that should be carried out in order to ensure that a mobile csp ‖ b specification is consistent. we use the divergence freedom check to confirm that b operations are called within their preconditions. in [ros08] roscoe introduces a new operator into a variant of csp, introducing mobility in the way that the rights to use particular events are transferred between processes 1 / 17 volume 23 (2009) mailto:b.vajar@surrey.ac.uk mailto:s.schneider@surrey.ac.uk mailto:h.treharne@surrey.ac.uk mobile csp‖b along special rights channels. our approach is similar, in that channels can be transferred between processes. however, our work is motivated by the desire to retain access to the supporting csp and b toolsets, and so we aim to minimise the extension required to enable the form of mobility we aim to model. 1.1 the b-method the main unit of specification in the b-method is an abstract machine. an abstract machine describes the state of the system in terms of mathematical structures such as sets, relations, functions and sequences. it also provides operations which change the state of the system. each operation has a precondition or a guard. for the purposes of this paper we will restrict ourselves to preconditioned operations, as in classical b. preconditioned operations have the form pre p then s end, where p is the precondition, and s is the body of the operation, written in abstract machine notation (amn), a simple language that contains assignment, choice, conditional, and precondition statements. a precondition expresses a predicate on the state of the machine which must hold when the operation is invoked, in order to ensure that the operation behaves as described by s; otherwise no guarantees can be given. if s is an statement and q is a predicate, the notation [s]q (also wp(s,q)) denotes the weakest precondition which must be true when executing s to guarantee to reach a state in which q is true. the b-method is a formal method supported by many comprehensive tools such as: b-toolkit [bc02], prob, and atelier b [cle09]. 1.2 csp csp is a theoretical notation or language for specifying and verifying concurrent systems, in terms of the events that they can perform. csp provides a framework for describing and analysing interacting aspects of concurrent systems. concurrent systems consist of interacting components known as processes. each process works independently and may interact with its environment and other processes in the system. a process performs various events which describe its behaviour. csp is an event-based formal language for designing and analysing a system behaviour through the events happening in the system. its operators include event prefixing, channel input and output, choice, recursion, and parallel composition in which parallel components synchronise on events that they have in common. the variant of csp that we will use in this paper is given in section 3. csp has a variety of semantic models, based on observations. in this paper we are concerned primarily with traces and with divergences, though also with a need to handle deadlocks (which requires the failures model). a trace tr of a process p is a finite sequence of events which p is able to perform. the set of all possible traces of process p is denoted by traces(p). a divergence of a process p is a sequence of events tr during or after which p can diverge—no guarantees can be made of its behaviour after divergence. csp is supported by highly efficient software tools such as probe [fsel07b] and fdr [fsel07a], supporting state exploration, refinement, divergence, and deadlock checking. proc. avocs 2009 2 / 17 eceasst 1.3 csp‖b csp ‖ b is a parallel combination between csp and b in which a csp process is used as a control executive for a b machine. for each b machine’s operation bb ←− op(aa), there is a channel op between the csp controller and the b machine which carries data types the same as the types of aa and bb. this provides the means for csp controller and its controlled b machine to synchronise and communicate with each other while working in parallel. a b machine and its controller can send or receive values from each other through these channels. for instance, the csp controller sends the value of aa to the b machine and receives the b machine’s output, bb, through channel op. this means that in addition to control the execution order of the b operations, csp controller and b machine can communicate with each other and they can exchange data and information through these channels while working in parallel in the system. in [mor90], morgan introduces traces, failures and divergences semantics of csp for action systems by using weakest precondition formulae. based on this achievement, csp semantics of traces, failures and divergences have been defined for b machines in [st05]. thus, a b machine can be understood as a csp process. this common semantic framework makes it possible to define the parallel combination of b machines and csp processes. in this framework the invocation of an operation outside its precondition corresponds to divergence. according to the definitions in [mor90], a trace of a b machine is a finite sequence of its operations. divergence happens in a b machine when a pre-conditioned operation is called outside its precondition. 1.4 introducing mobility in csp ‖ b, each csp process can be the control executive of only one b machine and each b machine has only one csp process as its controller. the architecture has focused on sequential csp processes as dedicated controllers for b machines. the objective of this paper is to generalise csp ‖ b architecture in designing a new framework, mobile csp ‖ b, which enables us to describe and verify systems in which a parallel combination of csp processes are collectively the controllers of b machines, and each single b machine can be controlled by different csp processes during the execution. by introducing mobility, each csp process can receive a (mobile) machine or give it to another csp process during the execution. an example of these kinds of systems is peer-to-peer networks in which data (b machines) can be transfered between the connected nodes (csp controllers). the following step is the consistency verification. we must ensure that b operations are always called within their preconditions, as they are passed between the controllers. we provide a theorem to establish divergence freedom of the whole mobile combined communicating system containing several csp controllers each controlling several b machines, by establishing properties for each csp controller separately. we also have the result that deadlock-freedom of the controllers implies deadlock-freedom of the combined system. 3 / 17 volume 23 (2009) mobile csp‖b 2 mobile csp || b in standard csp‖b, a controlled component consists of a csp controller p in parallel with a b machine m. operations op with inputs s and outputs t are declared in machines m as t ←− op(s). in the combination they are treated as channels op.s.t. standard csp‖b has a static architecture in which one b machine works in parallel with only one csp controller and each csp controller can be the controller of only one b machine. so, the behaviour of the parallel combination is predictable as we have fixed controlled components during the system execution. in mobile csp‖b, we intend to create a mobile architecture in which b machines are able to be transferred from one controller to another controller and each controller can work with more than one b machine at the same time. as controllers can exchange b machines between each other, b machines can have different controllers during their execution. to enable machines to be passed around the system, we introduce a unique machine channel called machine references. csp controllers use machine references as the link to interact with b machines. a machine reference is the only channel through which a csp controller and a b machine can communicate with each other. as a result, a controller is only able to work with a machine if it owns that machine’s reference. in other words, possession of a machine means having that machine’s reference. in order for machines to be exchanged between controllers, machine references must be passed around between controllers in the system. therefore, when a machine is going to be passed from one controller to another, the sender controller passes that b machine’s reference to the other controller, as illustrated on the right in figure 1. it shows that b machine m1 is passed from csp controller p1 to p2. the figure also shows the difference between static csp‖b architecture and mobile csp‖b architecture. b machine m with machine reference z is presented in the system as z : m. all operations op in m are replaced with z.op. so, operation calls of the machine z : m correspond to the communication z.op.s.t, and the machine reference z can itself be passed between controllers. we introduce channels called control points between pairs of controllers on which machine references are passed around. when a machine is passed from one controller to another, the sender controller passes that b machine’s reference to the other controller through the control point channel which exists between those two controllers. we require that only one csp controller is in possession of z at any one time, so that when z is passed from p1 to p2 then p1 is no longer able to use z to call the operations of the machine. this will be the cornerstone for reasoning about the action of controllers on a mobile machine: that a controller has exclusive control over a machine it is using, and other controllers cannot interfere with its use of the machine. we introduce mr as the set of machine references, cp as the set of control points, and c as the set of regular csp channels. each channel c in the set of regular channels c has a type denoted type(c). the type of channels in cp is mr. each machine reference in mr is associated with a particular b machine. the type of a machine reference z is the set of operations (with inputs and outputs) of the unique machine m that is associated with z. proc. avocs 2009 4 / 17 eceasst figure 1: static csp‖b architecture and mobile csp‖b architecture 3 mobile csp controllers we will use the name loop to denote a mobile csp controller. a process loop has a set of static channels χ(loop), which contains its communication channels and control points. any particular control point in the alphabet of loop will be either incoming or outgoing with respect to loop, and is not permitted to be both. we identify the incoming control points within χ(loop) as χi(loop). the outgoing control points within χ(loop) are denoted χo(loop). the alphabet associated with communication channels is denoted χc(loop). these three sets are pairwise disjoint, and their union is χ(loop). the syntax of mobile csp controllers is defined by the following bnf: p ::= skip | c?x → p(x) | c!v → p termination; communication | cp1?w → p(w) | cp2!z → p (z 6∈ fv(p)) passing machine references | z.op!s?t → p(t) operation call | p′ 2 p′′ | p′ u p′′ | if b then p′ else p′′ choice | e → p prefix | n(e1,...,en) recursive call where b is a boolean expression, e is an atomic csp event which is not a b operation, c ∈ χc(loop), cp1 ∈ χi(loop), cp2 ∈ χo(loop), v is a variable of type type(c), z and w are variables of type mr, t ←− op(s) is an operation of the b machine associated with z. fv(p) is the set of free variables in p, including variables for machine references. in n(e1,...,en), each expression ei either does not mention mr variables at all, or else is an mr variable; and no mr variable in the list is repeated. sequential processes are then defined recursively as follows: ni(wi1,...,win) =̂ pi where fv(pi)⊆{wi1,...,win} loop is then defined as some ni(mi1,...,min) for values mi1,...,min, where all instantiations of mr variables are distinct. 5 / 17 volume 23 (2009) mobile csp‖b the machine references that ni knows initially will appear in the list mi1,...,min. the set of machine references, mr, owned by loop can be defined by mr(loop) ={mi1,...,min}∩mr. 4 parallel combination a mobile combined communicating system including n controllers and m b machines is represented as loop1 || loop2 || ... || loopn || z1 : m1 || z2 : m2 || ... || zm : mm where z1,z2,...zm are the machine references for b machines m1,m2,...mm respectively, and i 6= j ⇒ zi 6= zj mutual recursive csp processes can be composed in parallel, only if (1) they have no machine references in common: ∀1 6 i,j 6 n • mr(loopi)∩mr(loopj) = /0, (2) they differ on their incoming control points and their outgoing control points: ∀1 6 j,k 6 n • χi(loopj)∩ χi(loopk) = /0, ∀1 6 j,k 6 n • χo(loopj)∩χo(loopk) = /0, and (3) each control point in the system has both a sender and a receiver. in other words, any outgoing (or incoming) control point in one controller is an incoming (or outgoing) control point of one of the other controllers in the system: n⋃ j=1 χi(loopj) = n⋃ i=1 χo(loopi). the free variables of the parallel combination of controllers is given as follows: fv(loop1 || loop2 || ... || loopn) = n⋃ i=1 fv(loopi) when a system is constructed, each machine reference must be given a different concrete value. the alphabets for the parallel combination of controllers are given as follows: χi(loop1 || loop2 || ... || loopn) = n⋃ j=1 χi(loopj) χo(loop1 || loop2 || ... || loopn) = n⋃ i=1 χo(loopi) χc(loop1 || loop2 || ... || loopn) = n⋃ i=1 χc(loopi) the language of process terms and the rules for parallel combination of controllers have been designed to ensure that at any point in the system execution, only one controller has possession of any machine reference. controllers do not share any machine references to begin with, and when a machine reference is passed along a control point to another controller, it is not retained by the sending controller. in order to define the traces of parallel composition, it is necessary to keep track of the machine references as they are used and passed between controllers. we can define the projection of a trace onto a particular controller loop given the channels χi(loop), χo(loop), χc(loop), provided we also know the set of machine references mr owned by the controller. this definition is based on the corresponding definition from [vst07]. the projection of a trace tr onto χ(loop) and a set of machine references mr can be defined inductively as shown in figure 2 where tr � χ(loop),mr means the projection of tr onto alphabet of controller loop who owns the set of machine references mr. this enables a definition of proc. avocs 2009 6 / 17 eceasst 〈〉 � χ(loop),mr = 〈〉 (〈cp.z〉atr) � χ(loop),mr =   〈cp.z〉a(tr � χ(loop),mr∪{z}) if cp ∈ χi(loop)∧ z 6∈ mr 〈cp.z〉a(tr � χ(loop),mr−{z}) if cp ∈ χo(loop)∧ z ∈ mr tr � χ(loop),mr if cp 6∈ χi(loop)∪χo(loop)∧ z 6∈ mr undefined otherwise (〈c〉atr) � χ(loop),mr = { 〈c〉a(tr � χ(loop),mr) if c ∈ χc(loop) tr � χ(loop),mr if c 6∈ χc(loop) (〈z.op〉atr) � χ(loop),mr = { 〈z.op〉a(tr � χ(loop),mr) if z ∈ mr tr � χ(loop),mr if z 6∈ mr figure 2: projection of a trace onto χ(loop),mr figure 3: transfer of machine m through control point cp the traces of the parallel combination of controllers to be given: traces(loop1 || ... || loopn) ={tr | ∀1 6 i 6 n • tr � χ(loopi),mri ∈ traces(loopi)} whenever two controllers synchronise on cp, the machine reference is passed from one to the other, thus passing control over the associated machine. this is illustrated in figure 3. 5 consistency verification in this section we discuss how divergence freedom of a mobile combined communicating system can be established. we also consider deadlock-freedom. if the parallel combination of csp controllers is not divergence free, then the whole system will have divergence. therefore, the first step is to establish that the csp part of the system is divergence free. fdr can be used to check divergence freedom of the csp part of the system by checking the divergence freedom of the parallel combination of controllers. if the csp part is divergence free, then any divergence in the system must arise from the b machines. divergence 7 / 17 volume 23 (2009) mobile csp‖b arises in a machine when its operations are called outside their precondition by the controllers and we are essentially using the divergence freedom check to check this. thus, the second step in divergence freedom verification is to establish that the operations of all machines in the system are always called inside their precondition by the controllers during the execution. the key point is that we are allowing b machines to be passed from one controller to another. a controller typically receives a machine from another controller without knowing its state in advance, and so the divergence freedom between a machine and a controller needs to take the combined behaviour of the controllers into account. in order to keep proofs manageable, we need to check the state of the machines when passed from one controller to another, as the target controller does not have any control over the state of the received machine. therefore, we will need to ensure that a machine is always transferred to another controller in a correct state where its operations will be called appropriately. in order to achieve this, for each control point we assign an assertion on the state of the machine whose reference is passed along that control point. the intention is that whenever a machine reference is passed to a csp controller along a control point, it is guaranteed that the assertion is satisfied. the notation assert(cpz) denotes the assertion of the control point cp for a machine whose reference is z. for instance, assert(cpz) : z.n = 0 means that the variable n of the machine with machine reference z must be zero when passing through cp. for each control point, one assertion is assigned for all machines being passed through it. for a machine with machine reference w, the assertion of cp is assert(cpz) with w substituted for z which is w.n = 0. to verify that a controller loop handles the b machines correctly, we translate the body of csp processes ni into amn. we define a translation function, trans(pi), to translate the body of each process ni into the corresponding amn. verifying [trans(p)]q will show that the sequence of operations expressed in p will establish the postcondition q in the b machine, as used later in definition 2. definition 1 the translation of csp expressions into amn is defined as follows: trans(skip) = select false then skip end trans(c?x → p(x)) = any x where x : type(c) then trans(p(x)) end trans(c!v → p) = pre v : type(c) then skip end; trans(p) trans(cp?z → p(z)) = any z where z : mr then select assert(cpz) then trans(p(z)) end end trans(cp!z → p) = pre assert(cpz) then skip end; trans(p) trans(z.op!s?t → p(t)) = t ←− z.op(s); trans(p(t)) trans(p′ 2 p′′) = choice trans(p′) or trans(p′′) end trans(p′up′′) = choice trans(p′) or trans(p′′) end trans(if b then p′ else p′′) = if b then trans(p′) else trans(p′′) end trans(e → p) = skip; trans(p) trans(n(v1,...,vn)) = rec := n(v1,...,vn) the last clause introduces a program counter rec to handle recursive calls. observe that inputs c?x and cp?z are translated to the any statement, which models an assumption that the value being received is of the correct type. in the case of a machine reference, cp?z also contains a proc. avocs 2009 8 / 17 eceasst select statement, which models an extra assumption that the machine is in a state satisfying assert(cp). outputs c!v and cp!z are translated to pre statement rather than any and select statements. v and z are the parameters of the process so there are already some predicates on their value before this stage. therefore, there is no need to have any in their translation. instead, we use the pre statement, which models a guarantee that the condition is met on output values. in the case of a machine reference, there is also no select statement in the translation of cp!z. this is because we are going to use weakest precondition formulae in our consistency verification strategy and the pre statement is the suitable statement in order to detect when the assertion is not ensured by the sender process, which corresponds to divergence in the system. supposing for a process ni in loop we can find an invariant referring to all free variables in ni such that if this invariant is true then whenever ni is called to be executed, it calls the operations of all the machines it owns at the beginning of that recursive call through their precondition. if we can establish that this invariant holds at every recursive call of ni, and if the state of the machines ni receives always satisfy the related assertions, then ni always calls the operations of all the machines it works with through their precondition at all the time during the execution. if we can establish the conditions above for each process ni (1 6 i 6 n), then the parallel combination between loop and any machine it works with during the execution is ensured to be divergence free. as this invariant should be true at each recursive call, we call it control loop invariant, cli. we now present the definition below for loop which contains the conditions we explained above: definition 2 loop is called cli preserver if for each ni (1 6 i 6 n) in loop, a control loop invariant, clii, can be found such that : 1. [init1; init2; ...; initm; rec := n1](cli1) 2. ∀1 6 i 6 n • ((rec = ni ∧clii)⇒ [trans(pi)](∀1 6 j 6 n • (rec = nj ⇒ clij))) where m1,...,mm are the machines that loop owns at the beginning of the execution and init1,...,initm are the initialisation clause of machines m1,...,mm respectively. the theorem below makes use of this definition: theorem 1 supposing loop1,loop2,...,loopn are the csp controllers and m1,m2,...,mm are the b machines in a mobile combined communicating system. if the parallel combination of controllers is divergence free and all controllers are cli preserver, then the whole system, loop1 ‖ loop2 ‖ ....‖ loopn ‖ z1 : m1 ‖ z2 : m2 ‖ ...‖ zm : mm, is divergence free. if each loop is a cli preserver then this allows each loop to be separately checked for divergence-freedom on machines it controls at some point during its execution. this theorem allows all of these individual checks to be combined to an overall consistency result. we can also establish deadlock-freedom of the overall system by checking deadlock-freedom of the combination of controllers. the b machines do not contribute to any deadlocking behaviour. this is because preconditions do not block, and we are not allowing blocking within the 9 / 17 volume 23 (2009) mobile csp‖b bodies of operations. theorem 2 suppose loop1,loop2,...,loopn are the csp controllers and m1,m2,...,mm are the b machines in a mobile combined communicating system and the system is divergence free. if the parallel combination of controllers loop1 ‖ loop2 ‖ ....‖ loopn is deadlock free, then the whole system, loop1 ‖ loop2 ‖ .... ‖ loopn ‖ z1 : m1 ‖ z2 : m2 ‖ ... ‖ zm : mm, is deadlock free. one important issue which has been considered in our work is to allow the refinements of the components into our framework. the intention is to be able to substitute a component by its refinement in such a way that the substitution does not have any effect on the system consistency properties. in [vaj09], it has been proved that if we have a mobile combined communicating system and this system is divergence free and deadlock free, then if we use a refinement of b machines or csp controllers instead of them in the system, the system remains divergence free and deadlock free. this enables us to use a refinement of a component instead of the component in the system. 6 case study: flight tickets sale system in this section, we present a case study within mobile csp ‖ b framework. the case study is a flight tickets sale system which presents the usage of mobile csp ‖ b architecture in designing and developing peer to peer networks. we first provide a mobile csp ‖ b model of a flight tickets sale system and then we verify the consistency of our model by using theorems 1 and 2. this is a simplified version of the case study to appear in [vaj09]. it generalises the language presented in section 3 by introducing a parameter to track a set of machine references. however, the important aspect is that when a machine reference is output then the controller does not retain the machine reference. this case study is designed as a flight tickets sale system in which tickets of different flights are sold or cancelled. the system contains a sell agency which sells tickets of different flights to customers, and it contains one return office which cancels customers’ tickets. the sell agency can only sell flight tickets and it is not able to cancel any tickets of the flights. the return office is only responsible for cancelling tickets and it is not able to sell any flight tickets. if the sell agency or the return office want to sell or cancel a ticket of a flight, they should have access to the information of that flight. otherwise they are not able to sell or cancel any tickets. this description of the system makes it clear what should be modeled as the b machines and what should be modeled as the controllers in the system. the b machines in our system are the individual flights. they manage all the booking information of the flights. so each machine represents one of the flights in the system. the sell agency and the return office play the role of the controllers in our system. each flight machine is given a unique machine reference which is the channel used by the sell agency and the return office to contact and communicate with that flight machine. the sell agency or the return office can sell or cancel a ticket of a flight only if they own that machine’s reference. if they want to sell or cancel a ticket of a flight but they do not have that machine’s reference, they request the machine’s reference from each other. proc. avocs 2009 10 / 17 eceasst the sell agency and the return office behave in such a way so that they do not keep the machines when they can not use them any more. a full machine can not be used any more by the sell agency as all the tickets have already been sold and there is no more ticket available to be sold next. so, if a flight owned by a sell agency is full after selling a ticket, the sell agency passes that full machine to the return office. on the other hand, an empty machine can not be used any more by the return office as there is no sold ticket in the machine to be cancelled next. so, if a flight owned by the return office is empty after cancelling a ticket, the return office passes that empty machine to the sell agency. in other words, the sell agency does not keep full machines with itself and the return office does not keep empty machines with itself. a set s is introduced for the sell agency and for the return office which contains all the machine references owned by the process. as a result, sellagency(s) represents the sell agency which currently owns the machine references in s, and returnoffice(s) represents the return office which currently owns the machine references in s. for the purposes of our case study, we will use two flight machines: flight1 and flight2. we also assume that at the beginning of the system execution, the sell agency owns both flight machines. therefore, the whole system is as below: returnoffice({}) || sellagency({mr1,mr2}) || mr1 : flight1 || mr2 : flight2 where mr1 and mr2 are the machine references of machines flight1 and flight2 respectively. 6.1 design and specification of b machines each b machine manages the information of one flight in the system. the structure of all flights in our system are the same so the b machines have the same specification but with different names. each b machine contains the information about that particular flight such as: the (positive) number of seats of the flight, and the number of tickets which have already been sold. it also contains some operations for state transitions in the flight such as selling or cancelling tickets and some other operations for finding out the current state of the machine such as whether it is empty or full. initially, each flight is empty. in other words, no ticket has been sold to anybody at the beginning of the execution. for reasons of space, only the operations of a flight machine are presented here, in figure 4. after specifying the flight machines in amn, we used prob to verify the internal consistency of our b machines and to explore the behaviour of their operations. as all b machines have the same structure in our system, a single b machine specification was checked, analysed and animated in prob. the b machine was proved to be internally consistent and it behaved as expected. 6.2 system design and specification in mobile csp in this section, we describe the csp specification of our system according to our mobile architecture. the return office and the sell agency are each specified as a csp process which describes their behaviour in the system. in addition, it is defined who is the controller of each machine at the beginning of the execution. 11 / 17 volume 23 (2009) mobile csp‖b response ← sell(pp) = pre pp : passport & sold 6= seats then if pp : passport−customer then customer := customer∪{pp} || sold := sold + 1 || if sold + 1 = seats then response := full else response := available end else response := incorrectinput end end response ← empty = begin if sold = 0 then response := yes else response := no end end response ← cancel(pp) = pre pp : passport & sold 6= 0 then if pp : customer then customer := customer−{pp} || sold := sold−1 || if sold−1 = 0 then response := empty else response := available end else response := incorrectinput end end response ← full = begin if sold = seats then response := yes else response := no end end figure 4: operations in a flight machine a function ref is used to assign a unique machine reference for each machine in the system. by mapping each machine to a machine reference, the flight machines are given a unique machine reference which then can be used to communicate with the csp processes. two control points dp and ep are introduced for passing the machines between the sell agency and the return office. dp is a control point channel used to pass the flight machines from the return office to the sell agency. ep is a control point channel used to pass the flight machines from the sell agency to the return office. the specification of the sell agency and the return office is shown in figures 5 and 6 respectively. a csp process, controller, is introduced which is the parallel combination of the sell agency and the return office. as we said before, we assume that at the beginning of the system execution, the sell agency owns both flight machines. as a result, controller is specified as: controller = returnoffice({}) || sellagency({mr1,mr2}). the system can be coded for tool analysis into standard csp, by treating the machine references as data values rather than as channels, and declaring a global channel mc (machine channel) which carries machine references as the first value, and then operation names and values as further values. in other words, any call of a machine operation z.op!s?t in the body of the csp controllers is modelled as mc.z.op!s?t in the standard csp description of our system. after coding the system in standard csp, the behaviour of the sell agency and the return office was checked individually by using probe. we then used probe to explore the execution of controller in order to check their behaviour while working in parallel in the system. in addition, proc. avocs 2009 12 / 17 eceasst sellagency(s) = p1(s) p1(s) = buy?flight?pn → if ref (flight)∈ s then p2(s,flight,pn) else p3(s,flight,pn) 2 ask?flight → p4(s,flight) 2 dp?z → p1(s∪{z}) p2(s,f ,pn) = ref (f ).sell!pn?resp → if resp = full then p5(s,f ) else p1(s) p3(s,f ,pn) = (require!f → ((dp?w → p2(s∪{w},f ,pn)) 2 (fullmachine → p1(s)))) 2 (ask?flight → p7(s,f ,pn,flight)) 2 (dp?w → if w = ref (f ) then p2(s∪{w},f ,pn) else p3(s∪{w},f ,pn)) p4(s,f ) = ref (f ).empty?resp → if resp = yes then (emptymachine → p1(s)) else (ep!ref (f )→ p1(s−{ref (f )})) p5(s,f ) = (ep!ref (f )→ p1(s−{ref (f )})) 2 (ask?flight → if flight = f then (ep!ref (f )→ p1(s−{ref (f )})) else p6(s,f ,flight)) 2 (dp?w → p5(s∪{w},f )) p6(s,f ,flight) = ref (flight).empty?resp → if resp = yes then (emptymachine → p5(s,f )) else (ep!ref (flight) → p5(s − {ref (flight)},f )) p7(s,f ,pn,flight) = ref (flight).empty?resp → if resp = yes then (emptymachine → p3(s,f ,pn)) else (ep!ref (flight) → p3(s−{ref (flight)},f ,pn)) figure 5: sell agency controller was proved to be divergence free and deadlock free by using fdr. 6.3 verification of the system: divergence-freedom our flight tickets sale system will have divergence if (1) the parallel combination of the sell agency and the return office has divergence, or (2) a sell agency calls the operation sell of a full machine during the execution, or (3) the return office calls operation cancel of an empty machine during the execution. in this section we verify the divergence freedom of our system by using theorem 1. controller has already been proved to be divergence free by using fdr. the next step is to establish that the sell agency and the return office are cli preserver. in order to achieve this, we should first assign assertions for control points in our system. then, we should define control loop invariants for the processes in the sell agency and in the return office. if a machine is passed from the sell agency to the return office, it should not be empty. on the other hand, if a machine is passed from the return office to the sell agency, it should not be already full. ep is the control point which passes the machines from the sell agency to the return office. so, the assertion of ep should be assigned as assert(epz) : z.sold 6= 0. dp is the control point which passes the machines from the return office to the sell agency. so, the assertion of dp should be assigned as assert(dpz) : z.sold 6= z.seats for the sell agency and the return office, we can introduce control loop invariants, shown in figure 7 which establish that both sell agency and the return office are cli preserver. thus, 13 / 17 volume 23 (2009) mobile csp‖b returnoffice(s) = r1(s) r1(s) = return?flight?pn → if ref (flight)∈ s then r2(s,flight,pn) else r3(s,flight,pn) 2 require?flight → r5(s,flight) 2 ep?z → r1(s∪{z}) r2(s,f ,pn) = ref (f ).cancel!pn?resp → if resp = empty then r4(s,f ) else r1(s) r3(s,f ,pn) = ask!f → (ep?w → r2(s∪{w},f ,pn) 2 emptymachine → r1(s)) 2 require?flight → r7(s,f ,pn,flight) 2 ep?w → if w = ref (f ) then r2(s∪{w},f ,pn) else r3(s∪{w},f ,pn) r4(s,f ) = dp!ref (f )→ r1(s−{ref (f )}) 2 require?flight → if flight = f then dp!ref (f )→ r1(s−{ref (f )}) else r6(s,f ,flight) 2 ep?w → r4(s∪{w},f ) r5(s,f ) = ref (f ).full?resp → if resp = yes then fullmachine → r1(s) else dp!ref (f )→ r1(s−{ref (f )}) r6(s,f ,flight) = ref (flight).full?resp → if resp = yes then fullmachine → r4(s,f ) else dp!ref (flight) → r4(s − {ref (flight)},f ) r7(s,f ,pn,flight) = ref (flight).full?resp → if resp = yes then fullmachine → r3(s,f ,pn) else dp!ref (flight) → r3(s − {ref (flight)},f ,pn) figure 6: return office according to theorem 1 our system is divergence free. 6.4 verification of the system: deadlock-freedom by verifying deadlock freedom of our flight tickets sale system, we establish that there will never occur a situation in which the execution of our system is blocked. this is a natural condition checked for concurrent systems. the deadlock freedom of our system is verified by using theorem 2. we have already proved in previous section that the system is divergence free. finally, controller has already been proved to be deadlock free by using fdr. all conditions in theorem 2 are true. thus, our system is deadlock free. 7 conclusion in this paper, we introduced mobile csp ‖ b, a formal framework based on csp ‖ b which enables us to specify and verify concurrent systems with mobile architecture instead of the previous static architecture. in the previous static version of csp ‖ b, for each operation in a b machine, there is one channel between that machine and its controller. however in our work, a machine’s reference is the only channel through which a csp controller and that b machine can interact with each other. in contrast to static csp ‖ b in which each controller is dedicated for one b machine, we designed our framework in such a way that controllers are able to work with proc. avocs 2009 14 / 17 eceasst clip1(s) : s ⊆ mr ∧ ∀k ∈ s • k.sold 6= k.seats clip2(s,f ,pn) : clip1(s) ∧ ref (f )∈ s ∧ pn ∈ passport clip3(s,f ,pn) : clip1(s) ∧ ref (f )∈ (mr−s) ∧ pn ∈ passport clip4(s,f ) : clip1(s) ∧ f ∈ flights clip5(s,f ) : s ⊆ mr ∧ ∀k ∈ (s−{ref (f )})• k.sold 6= k.seats∧ ref (f )∈ s ∧ ref (f ).sold 6= 0 clip6(s,f ,flight) : clip5(s,f ) ∧ flight ∈ flights ∧ f 6= flight clip7(s,f ,pn,flight) : clip3(s,f ,pn) ∧ flight ∈ flights clir1(s) : s ⊆ mr ∧ ∀k ∈ s • k.sold 6= 0 clir2(s,f ,pn) : clir1(s) ∧ ref (f )∈ s ∧ pn ∈ passport clir3(s,f ,pn) : clir1(s) ∧ ref (f ) ∈ (mr − s) ∧ pn ∈ passport clir4(s,f ) : s ⊆ mr ∧ ∀k ∈ (s−{ref (f )})• k.sold 6= 0 ∧ ref (f )∈ s ∧ ref (f ).sold = 0 clir5(s,f ) : clir1(s) ∧ f ∈ flights clir6(s,f ,flight) : clir4(s,f ) ∧ flight ∈ flights ∧ flight 6= f clir7(s,f ,pn,flight) : clir3(s,f ,pn) ∧ flight ∈ flights figure 7: control loop invariants in the sell agency and the return office different machines during the execution. controllers exchange machines between each other by exchanging the machine references. this results from two facts about our system architecture: 1. in mobile csp ‖ b, we have introduced mobile channels: machine references are mobile channels and they can move around the system during the execution. 2. in mobile csp ‖ b, mobile channels (machine references) are allowed to be passed between processes through static channels (control points) in the system. in addition, we defined and verified the conditions which guarantee the divergence freedom and deadlock freedom consistency of the systems specified and designed in mobile csp ‖ b. the case study demonstrates the applicability of our mobile csp ‖ b framework in specifying and verifying mobile communication systems. it shows that the theorems are sufficient to manage concurrent updates of state. it also demonstrates the ability of the csp controllers to interact with numerous machines at the same time. apart from formal method integrations, some other approaches have also been created in modelling and verifying mobile systems one of which is mobile unity. mobile unity [mr96], an extension of the parallel program design language unity [cm88], is a language and proof logic for specifying and reasoning about concurrent mobile systems. in mobile unity, components can move around and execute at different locations and they can interact and communicate with each other during the execution. in mobile unity notation, mobility is modelled as the change of the location of components. in other words, the change in the location of components provides means to model movement in the system. it allows the description of location-sensitive behaviour, e.g., interaction at the same place, or within a certain distance. each component in mobile unity has a distinguished location variable. the location of each component is modelled by assignment of a value to its location variable. the movement of a component is modelled by the change of value of its location variable. mobile unity proof logic is employed to verify the safety and liveness properties of a system expressed in the mobile unity notation. mobile unity has no notion of refinement. 15 / 17 volume 23 (2009) mobile csp‖b we believe using csp language in our approach makes flow of control more explicit in contrast to approaches that use control variables. in addition, mobile csp ‖ b framework supports a refinement approach: it enables the refinements of components to be a substitute of the original components in the system while the system consistency is guaranteed to remain. furthermore, as our framework can be coded into the original constructs of csp and b, we are able to use the comprehensive and highly efficient software tools of csp and the b-method to analyse, animate and check the behaviour and the consistency of the two parts of a mobile system separately. this shows the advantage of using b-method as our chosen state based formal method and csp as the process algebra in our framework. our approach uses syntactic restrictions on process terms to ensure that at most one controller is in possession of a machine reference at any one time. this approach imposes certain restrictions on the language to achieve the required result, for example to do with the careful handling and restrictive use of machine references as process parameters; and avoidance of internal parallelism within controllers. an alternative approach [gol09] would be to use a ‘monitoring process’ for a csp controller process which tracks which machine references the process is supposed to have, and checks that it does not make use of references it should not have. such monitoring processes can be used within fdr checks to ensure that controllers behave in the required way. the approach taken in π | b [kst07] also allows dynamic creation of machines and channels, and reconfiguration of the network. in contrast, the approach taken in this paper provides a more static network between the controllers, but developing the framework to enable reconfiguration, and dynamic process and machine creation, would be an interesting avenue of future research. acknowledgements: we are grateful to michael goldsmith for comments and discussions on various aspects of this paper that have improved our understanding. we are also grateful to the anonymous reviewers for their comments. bibliography [abr96] j. r. abrial. the b book: assigning programs to meaning. cup, 1996. [bc02] b-core. b-toolkit. 2002. http://www.b-core.com/btoolkit.html [but00] m. butler. csp2b: a practical approach to combining csp and b. formal aspects of computing 12, 2000. [cle09] clearsy. atelier b 4.0. 2009. http://www.atelierb.eu/index-en.php [cm88] k. m. chandy, j. misra. parallel program design: a foundation. addison-wesley, 1988. [fsel07a] formal systems (europe) ltd. fdr 2.83 manual. 2007. http://www.fsel.com proc. avocs 2009 16 / 17 http://www.b-core.com/btoolkit.html http://www.atelierb.eu/index-en.php http://www.fsel.com eceasst [fsel07b] formal systems (europe) ltd. probe. 2007. http://www.fsel.com [fis97] c. fischer. csp-oz: a combination of object-z and csp. in fmoods ’97. 1997. [gol09] m. goldsmith. personal communication, 28th october. 2009. [gs97] a. j. galloway, w. j. stoddart. an operational semantics for zccs. icfem ’97, 1997. [hoa85] c. a. r. hoare. communicating sequential processes. prentice-hall, 1985. [kst07] d. karkinsky, s. schneider, h. treharne. combining mobility with state. ifm’07, 2007. [lb03] m. leuschel, m. butler. prob: a model checker for b. in fm 2003. 2003. http://www.stups.uni-duesseldorf.de/prob/overview.php [mor90] c. c. morgan. of wp and csp. in w.h.j. feijen, a. j. m. van gesteren, d. gries, and j. misra, editors, beauty is our business: a birthday salute to edsger w. dijkstra. springer-verlag, 1990. [mr96] p. j. mccann, g. c. roman. mobile unity: a language and logic for concurrent mobile systems. technical report wucs-97-01, department of computer science, washington university in st. louis, 1996. [ocw07] m. v. m. oliveira, a. l. c. cavalcanti, j. c. p. woodcock. a utp semantics for circus. formal aspects of computing 21, 2007. [ros08] a. roscoe. on the expressiveness of csp. 2008. draft of october 23, 2008. [sch00] s. schneider. concurrent and real-time systems: the csp approach. wiley, 2000. [sch01] s. schneider. the b-method: an introduction. palgrave macmillan, 2001. [st05] s. schneider, h. treharne. csp theorems for communicating b machines. formal aspects of computing 17, 2005. [tdc04] k. taguchi, j. dong, g. ciobanu. relating pi-calculus to object-z. iceccs, 2004. [ts02] h. treharne, s. schneider. communicating b machines. zb2002, 2002. [vaj09] b. vajar. mobile csp‖b. phd thesis, university of surrey, in preparation, 2009. [vst07] b. vajar, s. schneider, h. treharne. introducing mobility into csp‖b. in avocs 2007. 2007. 17 / 17 volume 23 (2009) http://www.fsel.com http://www.stups.uni-duesseldorf.de/prob/overview.php introduction the b-method csp csp"026b30d b introducing mobility mobile csp || b mobile csp controllers parallel combination consistency verification case study: flight tickets sale system design and specification of b machines system design and specification in mobile csp verification of the system: divergence-freedom verification of the system: deadlock-freedom conclusion electronic communications of the easst volume 36 (2010) proceedings of the workshop on ocl and textual modelling (ocl 2010) preface 3 pages guest editors: jordi cabot, tony clark, manuel clavel, martin gogolla managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst preface this contribution reports on the 10th ocl workshop held at the models conference in 2010. the workshop’s motivation was to bring together researchers and practitioners in textual modelling standards, such as ocl, to report advances in the field, to share results, to identify common areas and potential for integration, and to identify common tools for developing textual modelling languages, with a view to advancing the state-of-the art. the workshop included sessions with paper presentations and a final discussion session. modelling started out with uml and its precursors as a graphical notation. however, graphical notations were found to have limitations in terms of specifying detailed aspects of a system design and in terms of processing and managing models. limitations in using graphical languages include: specifying detailed behaviour; linking models to other traditional languages; making models executable; model transformation; extensions to modelling languages; model management. many of these limitations have been addressed in recent years by proposals for textual modelling languages (e.g. there is a growing number of tools to textually define uml models ) that either integrate with or replace graphical notations for modelling. typical examples of such languages are ocl, textual mof, epsilon, alloy, etc. the current textual modelling landscape offers many interesting topics for research and experimentation including (but not limited to): new and/or successful applications; mappings to other languages/formalisms; new algorithms; evaluation strategies and optimizations for validation, verification and testing, model transformation and code generation, metamodeling/dsls, and query and constraint specifications; alternative graphical/textual notations; evolution, transformation and simplification of expressions; libraries, templates and patterns; complexity results, quality models and benchmarks for comparing and evaluating tools and algorithms; case studies on industrial applications; experience reports; empirical studies about the benefits and drawbacks; and innovative tools. the papers presented in the workshop covered many of the aforementioned topic of interests. all submitted papers were reviewed by three industrial or academic members from the program committee: • michael altenhofen, sap, germany; • thomas baar, tech@spree, germany; • mariano belaunde, orange labs, france; • achim brucker, sap, germany; • roberto clarisó, universitat oberta de catalunya, spain; • dan chiorean, university of cluj, romania; • joanna chimiak-opoka, university of innsbruck, austria; • birgit demuth, technical university of dresden, germany; • robert france, university of fort collins, usa; • miguel garcı́a, university of hamburg-harburg, germany; 1 / 3 volume 36 (2010) preface • geri georg, colorado state university, usa; • heinrich hussmann, university of munich, germany; • alexander knapp, university of augsburg, germany; • tihamer levendovszky, vanderbilt university, usa; • laurent goubet, obeo, france; • richard paige, university of york, uk; • mark richters, astrium space transportation, germany; • shane sendall, snowie research sa, switzerland; • pieter van gorp, university of eindhoven; • burkhart wolff, lri, university paris-sud, france; and • steffen zschaler, lancaster university, uk. two workshop papers were selected and were published in the additional lncs volume of the models 2010 conference: integrating ocl and textual modelling languages by florian heidenreich, jendrik johannes, mirko seifert, michael thiele, christian wende and claas wilke, and a specification-based test case generation method for uml/ocl by achim d. brucker, matthias p. krieger, delphine longuet and burkhart wolff. the workshop concluded with a discussion of features that the workshop participants would like to see in a future version of ocl. the key points in the discussion were as follows: user defined parameterized types ocl contains types such as set(t ). however there is no way for the user to define such types which would be useful to capture polymorphic structures. functions ocl contains many features that are similar to functional languages such as ml and scheme. iterators involve processing that is traditionally performed by anonymous functions in fp; however iterators are limited in comparison. adding anonymous functions (closures) to ocl would remove the limitations and make ocl much more expressive. overloading operators in ocl cannot be overloaded with respect to the type of the operands. providing a mechanism for defining operator overloading and dynamic dispatch would make ocl more expressive. stereotypes ocl cannot access or define stereotypes in uml. since stereotypes are part of uml that needs to be constrained using ocl, this situation should be addressed. implicit collection operations ocl inserts implicit asset and collect operations when multiple links are traversed. the point was raised that this can cause confusion (as can the difference between ‘−>’ and ‘.’) and makes tooling difficult. no consensus was reached proc. ocl 2010 2 / 3 eceasst on this, but the proposal was made to force the operations to be given explicitly or to introduce different versions of these operations. it would help if tooling gave smart typing advice as expressions were typed. equality ocl provides a single equality operations whereas many languages provide both identity and structural equivalence. these should be added to ocl. reflection ocl should have better support for reflection. it should be able to reason about its own meta-definition. syntax ocl should have a concrete to abstraction syntax mapping. types the standard definition of ocl should include a type construction algorithm. frame condition it is often the case that a specification needs to define a state change and also require that everything else stays the same. currently ocl requires all state in scope to be explicitly referenced in a state change. it would be useful to have a frame condition such as modifies only: and to leave all other state in scope unchanged. tool checking for ocl versions later than ocl 2.2, each chapter should be defined by a tool checked model. it should be possible to have a clear separation between an ocl core with no casting and an upper-layer with appropriate syntax for casting. the specification should define a mapping from the upper layer to the lower layer, and tools must implement this. the workshop organizers are grateful to authors, participants, program committee members, and additional referees for their work and their contributions. jordi cabot, tony clark, manuel clavel, martin gogolla march 2011 3 / 3 volume 36 (2010) a model transformation for automated concrete syntax definitions of metamodeled visual languages electronic communications of the easst volume 4 (2006) proceedings of the second international workshop on graph and model transformation (gramot 2006) a model transformation for automated concrete syntax definitions of metamodeled visual languages gergely mezei, lászló lengyel, tihamér levendovszky, hassan charaf 12 pages guest editors: gabor karsai, gabriele taentzer managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst a model transformation for automated concrete syntax definitions of metamodeled visual languages gergely mezei1, lászló lengyel2, tihamér levendovszky3, hassan charaf4 {gmezei1, lengyel2, tihamer3, hassan4}@aut.bme.hu budapest university of technology and economics goldmann györgy tér 3., 1111 budapest, hungary abstract: metamodeling techniques are popular in describing the rules of special domains, but these techniques do not support defining presentation for these domains , namely the concrete syntax. the aim of our research is to provide a method to create the concrete syntax for metamodeling systems in a flexible, efficient way. several domain-specific languages have been created that support defining the concrete syntax, i.e. the visualization. the main concern of this paper is to present a model transformation method that processes our presentation definitions and transforms them automatically into source code. the source code implements a plug-in capable of editing the models. a termination analysis for the presented method is also provided. keywords: model transformation, concrete syntax, domain-specific modeling 1 introduction special domains of interest require flexible modeling languages. domain-specific modeling languages (dsml) supported by metamodeling techniques are a widely adopted way to create environments for visual modeling languages. a metamodel acts as a set of rules for the model level: it defines the available model elements, their attributes and the possible connections between them. the definition is constructed using a default, domain-independent notation, often called the abstract syntax. since metamodeling can fulfill the structural requirements of the selected domain only, additional techniques are required to define the domain-specific presentation of the elements, namely the concrete syntax. 1.1 problem statement the instantiation relationship and the metamodeling itself are defined by standards, although there are alternative ways. in contrast, handling the concrete syntax definitions is not yet standardized. the custom solutions used in the modeling frameworks are often inefficient and inflexible. the following solution types can be distinguished: (i) manually coding the presentation logic in the modeling framework, (ii) extending the dsml definitions with new properties focusing on the presentation, (iii) using a special dsl that defines the presentation, and then binding the concrete syntax and the structural definition of the metamodel. previous work [mlhvl06] has introduced these solutions in detail and has found that the third solution is the most straightforward. this solution models concrete syntax definitions by using a common domain-specific 1 / 12 volume 4 (2006) a model transformation for automated concrete syntax definitions language (referred to as presentation dsl). the concrete syntax definitions are the models of this presentation dsl. the ability to handle the concrete syntax in the same way as normal dsmls makes editing much simpler, thus, it means uniformity and flexibility. another advantage of the solution is that it allows multiple concrete syntax definitions for a single dsml. visual modeling and transformation system (vmts) [vmts] is an n-layer metamodeling environment that unifies the metamodeling techniques used by the common modeling tools, and employs model transformation applying graph rewriting as the underlying mechanism. a metamodeling environment is based on the vmts presentation framework (vpf) [mlhpf05] that is a flexible, graphical modeling framework using a plug-in-based architecture. vpf promotes creating models for uml 2.0 diagrams and other popular domains such as mobile resource editor, or feature modeling. vpf plug-ins must be customized for each dsml. the base classes of the framework must be subclassed for each model element to provide customized drawing and event-handling code. the concrete syntax used by the vpf plug-ins was originally defined by manual coding, which meant a huge amount of additional work. the open issues are the following: (i) is the solution based on presentation dsl more efficient? (ii) is a model transformation flexible enough to create source code from the concrete syntax definitions? (iii) can the transformation engine grant that the transformation will always terminate? 1.2 architectural overview vmts presentation dsl (vpd) is a presentation dsl realized in vmts. fig. 1 shows the main steps of the concrete syntax definition and processing. figure 1: concrete syntax definition overview the vpd metamodel defines the metamodel for vpd, i.e. the structure of the concrete syntax definitions. by instantiating the vpd metamodel, concrete syntax definitions can be created. in order to facilitate the creation of the concrete syntax, a plug-in (the v pdplugin) was implemented based on vmts presentation framework. to improve the effectiveness, there is support for processing vpd models automatically, using model transformation techniques [ll+06]. the transformation describes by the control flow converts vpd models to codedom models. codeproc. gramot 2006 2 / 12 eceasst dom is an abstract code representation. from the codedom model, source code is generated with the .net codedom technology [th03]. the source code implements a plug-in that can be used directly in vpf. this approach made it possible to avoid manual coding, and create plugins in a user-friendly, graphical way in the same environment as common dsl models. the paper [mlhvl06] has presented the vmts presentation dsl in detail, [mlhc06] has given an overview about the method, but the model transformation has not been introduced in detail. this paper fills this gap and introduces both the transformation control flow and the transformation rules. termination properties of the transformation are also discussed in detail. 2 related work the generic modeling environment (gme) [lbm+01] is a highly configurable metamodeling tool supporting two layers: a metamodel, and a modeling layer. the concrete syntax definitions can be coded either manually, or set by properties both on the metamodel and on the model level. gme supports a special type of property definitions: the registry entries. these entries are assigned to model elements and they can also customize the appearance. meta-case editors (e.g. metaedit+ [medit]) are environments capable of generating case tools. they allow creating the tool definitions in a high-level graphical environment, but they supply a manually coded user interface. these environments store concrete syntax definitions in the metamodel properties. another framework is the diagram editor generator (diagen) [diagen], which is an efficient solution to create visual editors for dsls. diagen is not based on metamodeling techniques; it uses its own specification language for defining the structure of diagrams. diagen supports editing the concrete syntax in a graphical context, but in a tree control-based form only, where there is no support to define the shape of the elements graphically. concrete syntax in diagen is based on properties. diagen can generate an editor based on the specification using hypergraph grammars and transformations. atom3 (a tool for multi-formalism and meta-modelling) [lv02]) is a flexible modeling tool. it employs an appearance editor to define the shape of the model elements graphically; it uses model level properties to store the concrete syntax (model definitions are extended with visualization-based attributes). atom3 can generate plug-ins that use the defined syntax, but the code generation is not based on a presentation dsl. the views of the models are generated with triple graph grammars. eclipse [eclipse] is probably the most popular, highly flexible, open source modeling platform that supports metamodeling. the eclipse modeling framework (emf) can generate source code from models defined by the class diagram definition of uml, but it does not contain concrete syntax definitions. the graphical editing framework (gef) is also a part of the eclipse project. gef provides methods for creating visual editors. emf does not support code generation for gef, therefore gef plug-ins require manual coding to support the concrete syntax. genged [genged] is a tool to generate visualization code with graph transformation. genged has been replaced by the project transformation-based generation of modeling environments (tiger) [eeht] that uses precise visual language (vl) definitions and offers a graphical environment based on gef. tiger can generate source code from the visual language definitions 3 / 12 volume 4 (2006) a model transformation for automated concrete syntax definitions that implements a plug-in based on gef. vl specifications can be created graphically. java is the only language supported in plug-in generation. at the moment tiger can generate editors for activity diagrams and petri nets. the graphical modeling framework (gmf) is also an eclipse project. the goal of gmf is to form a generative bridge between emf and gef, whereby a diagram definition is linked to a domain model as an input to the generation of a visual editor. gmf uses a presentation dsl to define the concrete syntax. the result (the linked concrete, and structural definitions) are processed further to produce source code. the mapping between the domain model and the model items of the concrete syntax is also supported in gmf. the generated source code relies on the features of gef and emf. although the concept of gmf is straightforward, it has some weaknesses: (i) the generation is not based on model transformation. consequently, the compilation steps are coded manually, thus, changing the transformation needs changing the source code and rebuilding the compiler. in case of model transformation such modifications can be accomplished at run-time. (ii) because of emf, gmf is restricted to java only. 3 defining the concrete syntax concrete syntax models, namely concrete syntax definitions are created by instantiating vmts presentation dsl (vpd). concrete syntax models define how the model items of the subject model, namely, the models of the subject domain are visualized, and how they behave. fig. 2 shows the metamodel model, and the structural definition concrete syntax relationships. figure 2: structural definition concrete syntax relationship concrete syntax models are instantiations of presentation dsl. the models of the domain, the subject domain models are created, and the concrete syntax is mapped to the structural definition. subject models are created by instantiating the subject domain model. the framework displays the model using the generated plug-in by automatically combining the abstract and the concrete syntax. proc. gramot 2006 4 / 12 eceasst 3.1 the vpd metamodel the vpd metamodel consists of five nodes as shown in fig. 3. appearance definition can describe the graphical notation of the model elements. weaving contexts are used to define behavioral attributes and to store mapping information between the concrete and the structure definition. the name weaving context describes that these elements weaves two different aspects of the model, the data and the visual definition, namely the abstract and the concrete syntax. for example, in case of controlflow diagrams appearance definitions define the graphical notation, such as rectangle for statement, or diamond for conditions. weaving contexts have a reference to the appropriate metamodel item, thus, statementcontext has a reference to metastatement item in the controlflow metamodel. weaving contexts also contain behavioral attributes, such as the minimum size of the model element. a relation between weaving context and appearance definitions can be constructed using attribute reference relations. in the metamodel, the multiplicity of this relation is many-to-many, which means that the appearance definitions are reusable, and the weaving contexts can have several appearances. this reusability is necessary because modeling languages have a tendency to use the same notation in different languages. for example startstate in uml statechart diagrams and initialstate in uml activity diagrams are denoted the same way. similar separation between the behavioral attributes and the mapping information could be created, but we have found that customized behavioral attributes are harder to reuse. for example, input pins should be aligned to one side of its container in activity diagrams. this property is handled by behavioral attributes (positioning constraints). the constraints describe alignment rules useful only for this type of elements. figure 3: vmts presentation dsl metamodel different fundamental types can have different behavioral and visualization properties, thus, they are distinguished. in vmts, there are three fundamental types: nodes, edges (relations between nodes) and associationnodes (e.g. associationclass in a class diagram). vmts presentation dsl mirrors these fundamental types by customizing general weaving context. for example, the model item nodeweavingcontext can express the mapping information for a node. visualization information described in appearance definitions is based on regions. regions are graphical units that are independent from each other. a region is responsible for visualizing a part of the model item, or the whole model item. since the regions are independent from each other, they can be edited separately, and the model representation can be composed of the regions when displaying the model item. region definitions consist of simple graphical objects, called primitives. primitives are, for example, lines, bzier splines, or rectangles. a region can 5 / 12 volume 4 (2006) a model transformation for automated concrete syntax definitions contain several primitives, for example an actor in a use-case model is defined in a single region although it consists of several primitives (head, body, arms, legs). more information on the vpd metamodel and concrete syntax definition can be found in [mlhvl06]. 4 the transformation several techniques exist to create source code from a given model. model transformations can be modeled in a visual way, they can be changed easily and they can use the efficient graph transformation techniques, along with high level transformation constraints, thus, they are one of the most popular solutions. vmts uses visual model processors (vmps) to process models with graph rewriting-based transformation techniques. the inputs of a vmts vmp are the input model and metamodel, the output metamodel, and the control flow model which defines the transformation. the result of the transformation is the output model. the input model is an instance of the input metamodel, and the output model is an instance of the output metamodel. fig. 4 shows an overview of model transformation. figure 4: model transformation in vmts overview in this case concrete syntax models, namely, the concrete syntax definitions, are transformed to codedom models [th03]. codedom supports describing source code as a language independent tree and then generating source code to other languages automatically. therefore source code generation is easy from the output of the transformation. in vmts, the control flow for the transformation can be constructed using the visual control flow language (vcfl) [ll+06]. vcfl is a domain-specific language based on stereotyped activity diagrams. the transformation rules in the control flow specify the operational behavior of model processing. in vmts, this technique is based on graph transformations [roz97]. the atoms of graph transformations defined by control flow are graph-rewriting rules. rewriting rules consists of two parts: lefthand side (lhs) describes the pattern we are searching for, while the right-hand side (rhs) defines the replacement pattern. in vmts, the lhs and rhs of the transformation rules are built from metamodel elements. besides the rewriting rules, vcfl also supports decisions, fork, proc. gramot 2006 6 / 12 eceasst and join items. model transformation algorithms often require parameter passing between the subsequent transformation rules. in vcfl, external causalities can be defined to pass parameters. in the next sections, we elaborate on the control flow and the corresponding steps of the vpd transformation. 4.1 vpd transformation overview the control flow of the model transformation is shown in fig. 5. the first rewriting rule (createnamespace) is an initialization step for the further operations. the second step (getunprocessednode) searches for an unprocessed weaving context in the host model, namely, in the concrete syntax model. if it does not find any, then there is no item to process in the model, thus the transformation ends. if there is an unprocessed model item, then the next step (matchappearances) pass the associated appearance definitions using the appearance relations to navigate, and generates the required codedom items. the control flow uses external causalities and decorates the host model to pass the matching information between the rewriting steps to indicate the current context. figure 5: vmts presentation dsl control flow 4.2 the transformation rules the transformation initialization consists of two steps: (i) the initialization of the codedom model and (ii) the initialization of the environment of the generated code. the start node of the control flow creates a new model in the underlying database. the newly created model is an empty codedom model that is used as the output model in the later steps. the rule createnamespace constructs a namespace in the codedom model. each plug-in class generated later will be contained by this namespace. the step also creates a diagrammodel class. in vmts presentation framework, diagrammodel classes are used to create a binding between the plug-in and the subject domain. the concrete syntax definition is processed in the steps getunprocessednode and matchappearances. these steps are connected in a loop using a decision item. in vcfl, the decision steps can use ocl constraints, or simply the result of the previous rewriting steps to decide on which branch they continue the execution. in this case the loop exits only if there are no unprocessed node (weaving context) left in the concrete syntax definition (the step getunprocessednode was unsuccessful). the step getunprocessednode is simple: both lhs and rhs contains a general weavingcontext node. matching information is accomplished using an ocl constraint and a virtual attribute. virtual attribute is a special, temporary attribute 7 / 12 volume 4 (2006) a model transformation for automated concrete syntax definitions added to the matched elements during model transformation [ml+06]. using virtual attributes, the original model items can be decorated without changing their meta definitions. virtual attributes are removed at the end of the transformation. in this case the rule getunprocessednode is based on the virtual attribute isprocessed. the weaving context in lhs is extended by an ocl constraint that ensures that the matched node has not been matched before. the rule also contains a modify type internal causality. internal causality is a relationship between lhs and rhs nodes, and they define attribute computations. this causality adds the isprocessed attribute to the matched node. the rule matchappearances is more complex (fig. 6). it matches the weaving context along with the associated appearance definitions. the context element of the lhs is passed to the rule from the getunprocessednode rule using an external causality. an external causality is a parameter passing mechanism which facilitates to assign a host graph node matched to an rhs element to an lhs element of a subsequent rule. the matching algorithm considers these assignments compulsory. a single weaving context can have multiple appearances as mentioned before, thus the relation has a multiplicity of 1..*. the matched context and appearance codedom elements are generated in the rhs. the rule consists of create type internal causalities only. figure 6: the rule matchappearances from the weaving context, three classes (type declaration), a model, a view and a controller class are generated according to the mvc-architecture used in vpf [mlhpf05]. the fundamental types, namely, the types of the weaving contexts result in different base classes. for example, an associationnodeweavingcontext creates type declarations inherited from associationnode base classes defined in vpf. binding between the structural definition and the plug-in items is constructed by an attribute containing the id of the target model item according to the requirements of vpf. other properties and methods of the classes are defined only if they override the default behavior. each appearance definition generates a method in the view class. the methods are called when the model item is drawn out. the main loop of the transformation exits if the codedom model is complete. the step clearhelperinformation deletes the isprocessed attribute from the weaving contexts. the rule is defined as a multiplematch rule, which means it is applied for each weaving context in the host model. endnode supports a special type of proc. gramot 2006 8 / 12 eceasst action, after action that is executed at the end of the transformation. this special action is used to process the codedom model and generate the plug-in. vmts offers a built-in method to apply this task. the generated plug-in can be used directly in vpf. fig. 7 shows two examples: the well-known flowchart and the nassie-schneidermann plugin that were constructed using the introduced method. the concrete syntax was defined in two steps: (i) the notation of the model items were created in a graphical notation editor; (ii) mapping and behavioral properties has been added, such as position constraints for contained elements in nassie-schneidermann diagrams. then, the concrete syntax definition was transformed to source code by a visual model processor, based on the presented control flow. the transformation was not customized for the models, the same transformation is used for every domain. the generated source code, namely the plugin was compiled, and used to edit the models. the time spent with the construction of the plugins was approximately seven times less, than it would be using manual coding. the flowchart example is described in more detail (focusing the construction of the concrete syntax, and the generated source code) in [vmts]. (a) (b) figure 7: example plug-ins (a) nassie-schneidermann (b) flowchart 5 termination analysis using a model transformation to convert the concrete syntax definition into source code is a straightforward solution, because changes in the framework or in the modeling structure can be easily adopted. ’easily’ means that coding can be avoided; only the transformation control flow and the rewriting rules need to be modified. in contrast, classic model to source code compilers would fail for example if a new fundamental type is required. this flexibility has also some drawbacks: if the transformation changes, then its correctness must be proven again. using constraints in transformation rules can help in creating a validated model, but there are transformation-level properties, such as the question of termination, which require further examination. the aim of our analysis is to prove that the transformation terminates for every valid finite input model. we use the definitions and theorems presented in [lpe06] to make the proving method simpler. these theorems are proven to injective rules only, but this is not a problem, because the vpd transformation uses injective matches only. definition 1 an e-concurrent production p∗ is an e-based composition if there is at least one input graph g0 with an e-related transformation g0 p∗ +3h. 9 / 12 volume 4 (2006) a model transformation for automated concrete syntax definitions definition 2 consider a possibly infinite sequence of graph productions pi, (i = 1, 2, ...) and a sequence of e-dependency relations ((ei, e∗i , ei+1)) leading to a sequence of their e-based compositions (p∗i = (l ∗ i ← k ∗ i → r ∗ i )) with p ∗ 1 = p1 and p ∗ n = (p1 ∗e1 p2)∗e2 ...∗en pn. a cumulative lhs series of this sequence is the graph series l∗n consisting of the left-hand side graphs of p∗n. moreover, a cumulative size series of a production sequence is the nonnegative integer series |l∗n|. theorem 1 a gt s = (p) terminates if for all infinite cumulative lhs sequences (l∗i ) of the graph productions created from the members of p, it holds that lim i→∞ |l∗i | = ∞. note that we assume finite input graphs and injective matches. proposition 1 the transformation vpd (depicted in figure 5) always terminates. proof. at first the transformation rules are examined whether they can affect the termination. the initial, final step, and the createnamespace and clearhelperinformation rules are executed only once. they are not exhaustive, thus, they do not affect the termination. in contrast, the loop containing the getunprocessednode, the decision object and the matchappearances step are critical. when the transformation is running, the loop is executed until getunprocessednode can be matched. we unify the execution of consequent rules in the loop, namely we create the e-based composition of the rules, a new rule that has an equivalent effect on the host graph. the key of the proving method is to show that this unification produces an lhs sequence that exceeds all limits. recall that the basics of the proving method is borrowed from [lpe06]. the first step in the e-based composition is to unify a single execution of getunprocessednode and matchappearances. fig. 8/a shows the composition in detail. no other composition structure is valid, because of the external causality between the rules. empty and crossed circles represent weaving contexts, the cross in the circle means that the isprocessed attribute is set to true. filled circles are used to show appearance definitions. the generated codedom model is not shown, because the codedom model is just an output model, nodes in the codedom model are never matched in the rules of the transformation. next, the composition is further composed by the next step in the loop. in this case the first rule is the composite rule, the another rule is getunprocessednode. the composition step is shown in fig. 8/b. the new weaving context has an additional circle to show that it is different from the original one. it can be seen that r21 and l22 cannot be the same node, because r21 has the isprocessed attribute set to true, it cannot be matched again. therefore the composition represented by the figure is the only valid composition. this means also that every time the loop is executed, at least one new node appears in the lhs of the composed rule. therefore, the lhs sequence in the e-based composition exceeds all limits, thus, the transformation always terminates according to theorem 1. proc. gramot 2006 10 / 12 eceasst figure 8: e-based composition 6 conclusions while structural definitions of dsmls can be constructed in an efficient yet user-friendly way using metamodeling, handling the concrete syntax does not have such a well-accepted method. our approach is a way to solve this problem. previous work [mlhvl06] has presented the vmts presentation dsl, a domain-specific modeling language that can express concrete syntax definitions. this paper has completed the introduction of our approach by presenting the model transformation method that can create plug-ins from the concrete syntax definitions. the transformation control flow and the transformation rules were also presented in detail, including the examination of the termination properties of the transformation. the presented technique grants that the constraints enforced in the metamodel are treated separately from presentation of the concrete syntax. we have provided a simple, expressive model transformation based on graph rewriting to process the vpd models. the presented approach is easier and faster to use than manual coding. the presented transformation is flexible enough to convert the model to source code automatically. it has also been shown that the transformation always terminates. the presented transformation and presentation dsl have been successfully used in practice to model several domains, such as flowchart, nassie-schneidermann, and uml activity diagrams. thus, the introduced open issues have been solved. different visualization states for model items are currently supported by attaching several appearance definitions to a single context. these definitions are transformed to method definitions in the source code, but current version does not support modeling dynamic behavior: always the default appearance is used. the generated plug-in can be customized by a few lines of code, but our aim is to eliminate coding. the behavior and the different states of the model items can be modeled as a statechart diagram and attaching this behavioral information to the static visualization definitions can solve the problem. thus, future work focuses on a higher level of automatization. acknowledgements: the paper is established by the support of the national office for research and technology (hungary). 11 / 12 volume 4 (2006) a model transformation for automated concrete syntax definitions bibliography [mlhvl06] mezei, g., levendovszky, t., charaf, h.: a domain-specific language for visualizing modeling languages, in proceedings of the information systems implementation and modelling conference, prerov, czech republic, 2006, pp. 67-74. [vmts] vmts official homapage, http://vmts.aut.bme.hu/ [mlhpf05] mezei, g., levendovszky, t., charaf, h.: a presentation framework for metamodeling environments, workshop in software model engineering, montego bay, jamaica, 2005 (to appear) [ll+06] lengyel, l., levendovszky, t., mezei, g., charaf, h.: control flow support for model transformation frameworks: an overview, in proceedings of the microcad conference, miskolc, hungary, 2006, pp 193-199 [th03] thuan, t.,hoang, l.: .net framework essential, o’reilly, 2003. [mlhc06] levendovszky, t., mezei, g., charaf, h.: automatized concrete syntax definition for domain specific langauges, international conference on technical informatics, timisoara, 2006 [lbm+01] lédeczi, á., bakay, á., maróti, m., völgyesi, p., nordstrom, g., sprinkle, j., karsai, g.: composing domain-specific design environments, ieee computer 34(11), november, 2001, pp. 44-51 [medit] meta-case official homepage, http://www.metacase.com/ [diagen] minas, m.: specifying graph-like diagrams with diagen”, science of computer programming 44: pp 157-180, 2002 [lv02] de lara, j., vangheluwe, h.: atom3 as a meta-case environment, 4th international conference on enterprise information systems, 2002, pp 642 649 [eclipse] the eclipse modeling framework framework, http://eclipse.org/ [genged] genged, tfs.cs.tu-berlin.de/ genged/ [eeht] erhig, k., ermel, c., hansgen, s., taentzer, g.: generation of visual editors as eclipse plug-ins, http://www.tfs.cs.tu-berlin.de/ tigerprj/papers/ [roz97] rozenberg, g.: handbook on graph grammars and computing by graph transformation: foundations, vol.1 world scientific, 1997. [ml+06] mezei, g., lengyel, l., levendovszky, t., charaf, h.: extending an ocl compiler for metamodeling and model transformation systems: unifying the twofold functionality, 10th international conference on intelligent engineering systems, 2006 [lpe06] levendovszky, t., prange, u., ehrig, h., termination criteria for dpo transformations with injective matches, graph transformation for verification and concurrency, 2006 proc. gramot 2006 12 / 12 introduction problem statement architectural overview related work defining the concrete syntax the vpd metamodel the transformation vpd transformation overview the transformation rules termination analysis conclusions modeling of self-organizing systems: an overview electronic communications of the easst volume 27 (2010) workshop über selbstorganisierende, adaptive, kontextsensitive verteilte systeme (saks 2010) modeling of self-organizing systems: an overview richard holzer, patrick wüchner, hermann de meer 12 pages guest editors: klaus david, michael zapf managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst modeling of self-organizing systems: an overview richard holzer1, patrick wüchner2, hermann de meer3∗ 1university of passau, germany, holzer@uni-passau.de 2university of passau, germany, patrick.wuechner@uni-passau.de 3university of passau, germany, hermann.demeer@uni-passau.de abstract: this paper gives a systematic overview on modeling formalisms suitable for modeling self-organizing systems. we distinguish between micro-level modeling and macro-level modeling. on the micro level, the behavior of each entity and the interaction between different object must be described by the model. macrolevel modeling abstracts from the individual entities and only looks at the behavior of the system variables of interest. the differentiations between discrete and continuous time and between discrete and continuous state space lead to different descriptions of the model. keywords: self-organization, modeling, systems 1 introduction one main goal for networking systems is to reduce administrative requirements for users and operators. the system should be able to manage and configure itself as much as possible without requiring human effort. a self-organizing system should also be able to detect and correct failures automatically if possible. the concept of self-organization is a topic that has become more and more important in the last few years. a lot of research effort has been done regarding the design and analysis of self-organizing systems. to assist these technological advances, mathematical models foster the understanding of complex systems and facilitate the design of new systems. the main goal of this paper is to contribute to this issue. this paper gives an overview on modeling methods for self-organizing systems. according to [dk05] and [hey03], typical features of self-organization are adaptivity, autonomy, emergence, decentralization, and self-maintenance. therefore, the focus of this paper lies on the modeling of systems consisting of many entities interacting with each other to fulfill a global goal without any central control. we distinguish between macro-level modeling and micro-level modeling. while during micro-level modeling the behavior of each entity of the system must be described, macrolevel modeling uses the technique of aggregation to derive a model for the system variables of interest. each macro-state can be seen as an equivalence class of micro-states. for both modeling methods, we have to decide which parts of the system are modeled discrete and which parts are modeled continuous. another classification is the determinism: if some entities of a real-world system are too complex to be modeled in all details, the behavior of the entities may be modeled ∗ this research is partially supported by the socionical project (ip, fp7 call 3, ict-2007-3-231288), by the resumenet project (strep, fp7 call 2, ict-2007-2-224619) and by the network of excellence euronf (ist, fp7, ict-2007-1-216366). 1 / 12 volume 27 (2010) modeling of self-organizing systems: an overview as non-deterministic by specifying probability distributions. this leads to stochastic automata on the micro-level or to stochastic processes on the macro-level. the applicability of different approaches to real systems is demonstrated in, e.g., [boc04], [hdb08], [hd08], [bgdt06], [awd08], and [gsb02]. we do not consider the topic of robust control theory due to lack of space. the interested reader is referred to [zd97]. 2 macro-level modeling for macro-level modeling, the global state space of a system is reduced to the relevant properties, while selecting these properties is one of the most crucial decisions the modeler has to take. for defining the macro-level model, the following items of the model have to be specified: • dynamic variables xt = (x (1) t ,x (2) t ,...,x (n) t ) which change their values during the time t. they are usually the variables of interest that we would like to analyze. however, the variables of interest might depend on additional variables. for example, all relevant inputs and outputs of the system are modeled as dynamic variables. • macro-state space s which is a subset of the cartesian product s ⊆ s1×s2×,...sn, where si is the set of all possible values of the dynamic variable x (i) t for i = 1,2,...,n. • set t ⊆ r of points t ∈ t in time at which a macro-state change of the system can be observed. for all other points t ∈ r\t in time, there will be no observable macro-state change. macro-state changes of the system may occur discretely (e.g., t ⊆ n) or continuously (e.g., t ⊆ r+0 ). if the behavior of the system with respect to an initial state is analyzed, time t = 0 usually refers to the initial state, i.e., min t = 0. • static system parameters p = (p1, p2,..., pk): unlike dynamic variables, these parameters do not change over time, but they may influence the change of dynamic variables. • behavior rules r for the dynamic variables that describe the (deterministic or stochastic) change of the dynamic variables xt in dependency of the static system parameters p. after specifying these items, we are able to analyze the behavior of the whole system: for each initial macro-state x0 ∈ s, we can apply the rules r to derive all macro-states of the system as a function depending on the time t: (xt)t∈t . this mapping is called the orbit (also known as sample path or state trajectory [cl08, p. 14]) of the system with respect to the initial value x0. in a deterministic system, the orbit is uniquely determined by the initial macro-state x0. in stochastic systems, the orbit depends on random events. an equilibrium [boc04] is a macro-state x∗ ∈ s such that a system starting in x0 = x∗ will not leave this macro-state, i.e., the orbit of this system contains only one macro-state x∗. the equilibrium x∗ is stable, if a system starting near the equilibrium x∗ will stay near x∗, i.e., for all ε > 0, there exists 0 < δ ≤ ε such that, for each initial macro-state x0 with d(x0,x∗) < δ , we get d(xt,x∗) < ε for all t ∈ t , where d : s2 → r+0 is a metric (distance function) on the macro-state space s (e.g., d(x,y) = |x−y| in the euclidean space rn). a stable equilibrium x∗ is asymptotically stable, if a system starting near the equilibrium x∗ will converge to x∗, i.e., there exists δ > 0 such that, for each initial macro-state x0 with d(x0,x∗) < δ , we get lim t→∞ xt = x∗. saks 2010 2 / 12 eceasst in the following sections, we distinguish between discrete-time and continuous-time macrolevel modeling. moreover, also the macro-state space can be chosen as discrete or continuous. figure 1 illustrates these interrelationships (cp. figs. 24.1 and 24.2 of [jai91]). figure 1: discretevs. continuous-time and discrete vs. continuous state space models. during discrete-time modeling, we only consider a discrete subset t ⊆r for the points in time of interest. when we use continuous time, then the current macro-state may change anytime. modeling using a discrete macro-state space means that the set of macro-states s is a discrete set (usually a finite or countable subset of rn, where n is the number of dynamical variables). models with discrete state space are often also referred to as discrete-event models [jai91, p. 399]. for discussing discrete-event models, a vast amount of literature is available (see, e.g., [jai91, bgdt06, cl08] and the references therein). when modeling a system with continuous macro-state space, the set s of macro-states is uncountable (usually an open subset of rn). 2.1 discrete-time macro-level modeling for discrete-time macro-level modeling, the time is discrete, while the state space may still be continuous or also discrete. due to discrete time, each orbit contains only countable many states since from the (possibly uncountable) set of macro-states, only a countable subset can be chosen. for simplification, the points in time where state changes may occur are here defined as a subset of natural numbers t ⊆n. the initial state of an orbit (x0,x1,...) is state x0 at time t = 0. the behavior rule describes to which macro-state the system changes at each point in time of interest. for further simplification, we can assume that only the current state xt is needed to compute the next state xt+1, because older states xs for s < t can be coded into the current state by extending the state space. again for simplification, we assume time homogeneity, i.e., the point in time t is not explicitly used in the behavior rules. in principle, any time-inhomogeneous model can be transferred to a time-homogeneous model by extending the macro-state space to s×t in order to have access to the current absolute point in time within the behavior rules. 3 / 12 volume 27 (2010) modeling of self-organizing systems: an overview based on these simplifications, the behavior rule can be expressed as a recurrence equation (also known as difference equation [cl08]): xt+1 = f p(xt) for a map f p : s → s, where p = (p1, p2,..., pk) are the static system parameters. a deterministic map f p resembles a deterministic system, i.e., the orbit is uniquely determined by the initial state and the system parameters. if f p is a random variable, we handle a stochastic system. in this case, the orbit also depends on random events, i.e., each initial macro-state may lead to many different orbits. an equilibrium of a deterministic discrete-time system is a solution of the equality f p(x) = x. for the analysis which equilibria are stable, it might be difficult to compute the complete orbit (xt)t∈t , so other methods have been investigated in literature for the stability analysis [boc04]. in the euclidean space s ⊆ rn, the complex eigenvalues of the jordan matrix d f p(x∗) for an equilibrium x∗ may be used for this purpose: first, we have to distinguish between hyperbolic equilibria (|λ| 6= 1 for all complex eigenvalues λ of d f p(x∗)) and non-hyperbolic equilibria (|λ|= 1 for some complex eigenvalue λ of d f p(x∗)). a hyperbolic equilibrium x∗ is asymptotically stable iff |λ| < 1 for each complex eigenvalue. if a hyperbolic equilibrium has |λ| > 1 for some eigenvalue λ , then the equilibrium is unstable. 2.1.1 discrete-time macro-level modeling with discrete state space behavior rules of deterministic discrete-time macro-level models with discrete state space can be described by recurrence equations as described at the beginning of section 2.1. for building stochastic macro-level models with discrete state space, stochastic processes with discrete state space (also known as chains) can be used. frequently employed discrete-time representatives of such chains are discrete-time markov chains (dtmcs, cf. [bgdt06, p. 53]). stable equilibria of (discrete-time) markov chains are called absorbing states (cf. [bgdt06, p. 62]). absorbing states can directly be identified by observing a diagonal element of value 1 within the dtmc’s transition probability matrix p. moreover, attractors of the system can be considered as the highest value within the dtmc’s steady-state probability vector (cf. [dre07, p. 28] or [hey03]). if a unique steady-state probability vector πππ exists, it can be determined by solving the system of equations πππ = πππ p,∑i∈s πi = 1. we refer the interested reader to [bgdt06, chapter 2] for more details on markov chains and their analysis. 2.1.2 discrete-time macro-level modeling with continuous state space behavior rules of deterministic discrete-time macro-level models with discrete state space can also be described by recurrence equations as described in section 2.1. an example for such a model is the discrete logistic model (cf. [boc04, p. 128]). for building stochastic models with continuous state spaces, stochastic processes can be used which can be seen as a generalization of (markov) chains since the former do not rely on a discrete state space (see, e.g., [tri01, bgdt06, cl08] for details on stochastic processes). 2.2 continuous-time macro-level modeling for continuous-time macro-level modeling, the time parameter space is considered continuous. hence, a state change may occur anytime: t ⊆r+0 , where x0 is the initial state at time t = 0. saks 2010 4 / 12 eceasst here, an orbit of the system can be seen as the trajectory (xt)t∈t of the macro-state during the time. the behavior rule describes the state change at each point in time. like in the case of discrete macro-level modeling, we assume that older states are not needed to describe the behavior of the system and also the time is not explicitly needed in the rule. however, we cannot derive a recurrence equation here since the time is not discrete. for discussing the system’s equilibria, we now need to differentiate between models with continuous and models with discrete state space. 2.2.1 continuous-time macro-level modeling with continuous state space for continuous-time macro-level models with continuous state space, a differential equation for the rules can be derived: ẋ = f p(x). an equilibrium is then characterized by the equality f p(x∗) = 0. for stability analysis of equilibria [boc04], the eigenvalues of the jacobian matrix may again be used, like in the discrete-time case (section 2.1): we similarly distinguish between hyperbolic equilibria (real part of each complex eigenvalue is non-zero: re(λ ) 6= 0) and non-hyperbolic equilibria (real part of some complex eigenvalue is zero: re(λ ) = 0). a hyperbolic equilibrium x∗ is asymptotically stable iff re(λ ) < 0 for each complex eigenvalue. if a hyperbolic equilibrium has re(λ ) > 0 for some eigenvalue λ , the equilibrium is unstable. examples for deterministic models are the lotka-volterra model [boc04, p. 17] and the logistic model [boc04, p. 6]. similar to section 2.1.2, stochastic processes can be employed to model continuous-time macro-level models with continuous state space. 2.2.2 continuous-time macro-level modeling with discrete state space unfortunately, differential equations cannot be used for describing the behavior rules of continuous-time macro-level models with discrete state space due to the instantaneous jumps from one state one state to another (discrete events). however, in deterministic systems, the time instants when these jumps happen are pre-determined, and hence, the model can be mapped to a discrete-time macro-level model with discrete state space (see section 2.1.1). a common example for a stochastic continuous-time macro-level models with discrete state space are continuous-time markov chains (ctmcs, cf. [bgdt06, p. 64]). comparable to dtmcs (section 2.1.1), stable equilibria (absorbing states) can directly be identified by observing a row of zeros within the ctmc’s transition rate matrix q. attractors of the continuous-time system can be considered as closely related to the ctmc’s steady-state probability vector. if a unique steady-state probability vector πππ exists, it can be obtained by solving 0 = πππ q,∑i∈s πi = 1. 2.3 bifurcation a change between qualitatively different behaviors by the variation of some system parameters p is called bifurcation [boc04]. such a change could be the appearance of new equilibria, the elimination of existing equilibria, the change of the equilibria’s stability, the appearance of new limit cycles, or the elimination of existing limit cycles. note that such a bifurcation can only appear for non-hyperbolic equilibria. let us first consider the different types of one-dimensional bifurcations, i.e., the system parameter p is a real number. in [boc04], the following types of one-dimensional bifurcations 5 / 12 volume 27 (2010) modeling of self-organizing systems: an overview have been defined for discrete and continuous models: saddle-node bifurcation, transcritical bifurcation, and pitchfork bifurcation. as an example, we are looking at a fish population and the effect of fishing. let n be the size of the fish population, r be the birth rate, and k be the carrying capacity. let c be the intrinsic catch rate. using the logistic model for the birth of fishes, we get ṅ = rn(1− nk )−cn. by introducing the dimensionless variables n = nk , τ = rt, c = c r , we derive the new differential equation dndτ = n(1−n)−cn. this system has two equilibria: n ∗ 1 = 0 and n ∗ 2 = 1−c. for c = 1, we have only one equilibrium at n∗1 = n ∗ 2 = 0. the equilibrium n ∗ 1 = 0 is asymptotically stable for c > 1, instable for c < 1, and non-hyperbolic for c = 1. the equilibrium n∗2 = 1 − c is asymptotically stable for c < 1, instable for c > 1, and non-hyperbolic for c = 1. hence, the equilibria change their stability: the system has a transcritical bifurcation at n∗ = 0 for c∗ = 1. in dimension two, there may also be other types of bifurcations. for example, the asymptotically stable equilibrium of a predator prey model (see [boc04]) becomes a limit cycle, i.e., a closed orbit attracting other trajectories. bifurcation can also been observed in discrete systems. in addition to saddle-node, transcritical, and pitchfork bifurcations which also exist for discrete systems, there is another type of one-dimensional bifurcation: period-doubling bifurcation. here, an equilibrium is split into two different states which form a cycle of length two. since each cycle of length d of the system xt+1 = f p(xt) can be seen as an equilibrium of the system yt+1 = f dp (yt), this concept can also be used for doubling cycles of arbitrary length. 3 micro-level modeling by micro-level models the behavior of the objects in the system is described. for defining the micro-level model, the following items of the model have to be specified: • topology g: the topology describes which object is able to communicate with which other objects. if the topology is static, a graph g = (v,e) (or multigraph) can be used for this purpose, where each node v ∈ v of the graph represents an object of the system and each edge e ∈ e represents a communication channel. the graph may be directed, if the communication channels are not symmetric. if the topology changes dynamically, we could either use a time dependent graph gt for each point of time t or we could use a graph g to describe the boundaries of the changing topology, i.e., g contains all nodes and communication channels which may be existent at any point in time. • micro-state space sv for each node v ∈ v : at each point in time, the node v ∈ v has an internal state s ∈ sv. • set t ⊆r specifying the points in time the state of a node may change. state changes may occur discretely (e.g., t = n) or continuously (e.g., t = r+0 ). time t = 0 usually refers to the system’s initialization. • alphabet a for communication: at each point in time t ∈ t , each node can send data to his successor nodes. the alphabet a describes the possible values for this communication. saks 2010 6 / 12 eceasst • behavior rules r = (rv)v∈v for the nodes: the change of the internal states of the nodes and the communication between the nodes must be described by rules. like macro-level modeling, we also have to decide during micro-level modeling which aspects of the model should be discrete or continuous. there are four main aspects where this decision has a large impact on the model design and behavior: time t , object set v , states of objects sv, and interaction. if we use discrete interaction, each object is able to interact with only a finite or countable number of other objects. a continuous interaction can be seen as a force or an impression of one object to other objects, e.g., gravitation force of a planet. 3.1 discrete-time micro-level modeling here, the behavior of each object v ∈ v can be described by a deterministic or stochastic automaton av: at each point in time t ∈ t , the node v gets some local input from its predecessor nodes v− := {w ∈ v | (w,v) ∈ e}, looks at its current internal state, and then decides (deterministically or stochastically) on the state change and on the local output to the successor nodes v+ :={w ∈v | (v,w)∈ e}. a stochastic automaton av = (av−,av+,sv,pv) for v ∈v consists of • the local input values av− ={(xw)w∈v− | xw ∈ a,w ∈ v−}, • the local output values av+ ={(xw)w∈v+ | xw ∈ a,w ∈ v+}, • the set sv of states, and • a map pv : sv ×av−×sv ×av+ → [0,1], such that p(q,x,·,·) : sv ×av+ → [0,1] is a probability distribution on sv ×av+ for each q ∈ sv and x ∈ av−. the value p(q,x,q′,y) is the probability that the automaton moves from state q ∈ sv into the new state q′∈ sv and gives the local output y ∈ av+ when it receives the local input x ∈ av−. a deterministic automaton can be seen as a special case of such a stochastic automaton, where the probabilities are either 0 or 1. it is also possible to model the clocks of the automata as non-synchronous [hd09]: in this case, the set t is not given in advance, but a map dv : sv →r+ describes the delay between two pulses of the clock when the automaton is in a given state q∈sv, so each automaton has its own clock which depends on the current state. in the global view on a micro-level model, the current configuration of the whole system can be seen: a global state s consists of all local states and all values on the communication channels. 3.2 continuous-time micro-level modeling a change of the nodes’ states may now appear anytime. one possibility to specify the nodes’ behavior in such a system is given in [hd08]: the nodes’ behavior contains the state change and the local output of the nodes. a continuous state change can be described by differential equations. for this purpose, we assume that the state space sv is a subset of a normed vector space for each node v ∈v . like the map f p for macro-level modeling, the right hand side of the differential equation can be described by a family f = ( fv)v∈v of (deterministic or stochastic) maps fv : av−×sv → sv, where fv is called change map of the object v. for the local output, we 7 / 12 volume 27 (2010) modeling of self-organizing systems: an overview can also use a family λ = (λv)v∈v of maps λv : sv×v+→ a, where λv is called output map of the object v. if also non-continuous changes of states should be modeled, we need another family h = (hv)v∈v of maps hv : av−×sv → sv, where hv is called hop map of the object v. a family (sv)v∈v of maps sv : r+0 → sv is called behavior of the system with respect to an initialization i ∈ ∏ v∈v sv, if for all v ∈v (b1) sv(0) = iv, (b2) sv is left-continuous, (b3) {t ∈r+0 | sv is not differentiable in t } is a discrete set, (b4) for each t ∈r+0 , for which sv(t) is differentiable, we have ṡv(t) = fv((λw(sw(t),v))w∈v−,sv(t)), and (b5) lim r↘t sv(r) = sv(t)+ hv((λw(sw(t),v))w∈v−,sv(t)) for t ∈r+0 . therefore, the behavior sv of the node v is just the local orbit of the internal state of v which results from the solution of the differential equation (b4) and the hops given by (b5). 3.3 network properties for very complex systems, the topology is usually not known in every detail. in such a case, the graph g is not specified deterministically, but it is considered as a random graph, where only some static system parameters (e.g., number of nodes) and probability distributions (e.g., the probability that an edge exists between two randomly chosen nodes) are specified. for such a model, it is not easy to find the appropriate probability distributions that are needed to specify the model, since the distributions strongly depend on the network properties of the corresponding system in the real world. to be able to find a good model, many network properties of the real system can be analyzed: • the mean value l for the path length between two randomly chosen nodes, • the mean size and mean diameter of maximal connection component, • the clustering coefficient c, i.e., the conditional probability that two randomly selected vertices are connected given that they are both connected to a common vertex, • and the average node degree. after calculating these network properties, it turns out that for most applications a simple uniformly distributed random graph is not a good system model, since such a random graph has completely different properties. one kind of graphs that appear very often in practice are smallworld networks: they have short characteristic path lengths and high clustering coefficients. to find an adequate model for such a network, some algorithms have been proposed in literature. the model of watts and strogatz [ws98] starts with a lattice structure and rewires each edge with a constant probability p, where the new target node is chosen randomly. it can be shown saks 2010 8 / 12 eceasst that for small values of p, the watts-strogatz model has a clustering coefficient of the same order of magnitude as the lattice, while its characteristic path length is of the order of magnitude of a uniform random graph. other algorithms for small-world networks can be found in [boc04]. since the small world networks are characterized by mean path length and clustering coefficient, there are still some important properties where the model differs to the corresponding system in the real world. one of these properties is the node degree distribution. many systems in the real world are scale-free, i.e., the node degree distribution follows the power law p(d(v) = k) ∼ k−γ for some constant γ , where d(v) is the degree of node v ∈ v . also for this kind of networks, some algorithms have been proposed in literature. usually, these algorithms use the two principles expansion (the size of real networks are not constant, but it usually continuously increases during the time) and preferential attachment (in growing real networks, a new vertex has a higher probability of being connected to a vertex that already has a large degree). barabási and albert [ab02] have proposed such an algorithm to construct a scale-free network. the algorithm starts with a graph without any edges. in each step, a new vertex and m new edges connecting this vertex to m existing vertices are added to the current graph using preferential attachment for the probabilities of the target nodes. this leads to a scale-free network with the power law constant γ ≈ 2.9. other algorithms for scale-free networks can be found in [boc04]. 4 from micro-level to macro-level: quantitative measures since a macro-level model considers only the variables of interest of a system, it is also possible to first specify the micro-level model and then define the variables of interest as numeric attributes in the micro-level model. for this purpose, each global state in the micro-level model must be mapped into the set of real numbers. such a map is called quantitative measure. this concept can be used to analyze the system with respect to properties of interest. in [hdb08, hd09, awd09b, awd09a], this has been done for the properties autonomy, emergence, adaptivity, resilience, homogeneity, target orientation, and state classification. one important tool for such quantitative measures is the statistical entropy h(x) = − ∑ w∈w p(x = w)log2 p(x = w) of a random variable x that measures how many bits are needed to encode the outcome of the random variable in an optimal way. it can be used to measure different properties of the system: • how much information is contained in the system at time t ∈ t ? • how much control information is needed at time t ∈ t to keep the system running? • how much output does the system produce at time t ∈ t ? for example, to measure the emergence of global patterns in the system, the dependencies between the communications of different nodes can be analyzed by comparing the information of the whole system with the sum of the information of each edge [hdb08]: the ratio h(information on all edges) ∑ k∈e h(information on k) indicates how many dependencies are in the communications of the system. such quantitative measures help to analyze existing systems and to design new systems. 9 / 12 volume 27 (2010) modeling of self-organizing systems: an overview 5 from macro-level to micro-level: design approaches when we design a new system, we first have a target function in mind that should be fulfilled by the system. the description of this target function may be easily achieved on the macrolevel. however, it is a non-trivial task to transform the macro-level target function into the corresponding micro-level rules in general (see also design paradigm #1 described in [pb05]). in [ed08], three different design approaches are sketched: the bio-inspired design, the trialand-error approach, and the design by learning from an omniscient entity. the bio-inspired design approach tries to exploit the mechanisms developed by nature with the help of long-term evolution. the approach can be direct (top-down) or indirect (bottom up). the direct approach aims at searching for natural blueprints of mechanisms that achieve solving a problem that is similar to the technical problem under study. the indirect approach first studies a natural phenomenon and then searches for an application of this phenomenon in the technical world. however, the bio-inspired design approach is infeasible when the technical implementation of the natural solution is too intricate or the solution can be technically implemented more efficiently by exploiting approaches that are not available in biological systems. an example for bio-inspired design is the class of ant routing algorithms (see, e.g., [gsb02]). the trial-and-error approach requires a first implementation of the target system in form of a testbed (or simulation). during the design process, extensive evaluation of the testbed’s ability to provide the target functionality is conducted. in this testing process, the system parameters are (purposefully) varied to approach a suitable (or even close to optimal) setting. however, the search space for such settings usually is very large and often the search ends in a local optimum. hence, in general, following this approach is a very timeand resource-consuming tasks. the approach by learning from an omniscient entity in introduced in [awd08]. a generic method is proposed that disburdens the derivation of (close to optimal) micro-level rules by providing a subset of a testbed’s system entities with extended information on global system and environmental properties. the extended information available to these “omniscient” entities (referred to as laplace’s daemons (lds)) simplifies the design of (close to optimal) entities but will not be available to the entities during the operation of the real system. the micro-level behavior, i.e., the series of local inputs and outputs, of these lds is then analyzed by using an algorithm for time series analysis (cssr algorithm; see [ss04]). the method results in a markov chain description of each investigated ld which can then be used as a blueprint for the micro-level behavior of the entities in the real system. 6 conclusion mathematical models are useful for both the analysis and design of systems. in this paper, we have given an overview on different modeling methods for self-organizing systems. micro-level modeling can be used to describe the behavior of each object in the system and the communication between the objects. it’s advantage is that more details of the real system can be integrated into the model. but this leads to a very large global state space for the model. macro-level modeling abstracts from the individual entities of the system and models only the variables of interest. hence, the large state space of the micro-level is strongly reduced by considering equivsaks 2010 10 / 12 eceasst alence classes. for both approaches, some model properties can be specified in different ways: discrete vs. continuous time, discrete vs. continuous space, and deterministic vs. stochastic behavior. the choice of the right model properties depend on the application and on the aspired analysis. each of these models may be useful for a better understanding of the corresponding real-world system and also help in the design process. note that the choice of the model may be done independently of the properties of the real system. for example, many continuous-state population models have been developed in literature (see, e.g., [boc04]) although the size of the population in the real system are natural numbers. also in it, where usually everything is considered being discrete, continuous-state continuous-time models can be used for system analysis (see e.g. [hd08]). a case study may be interesting where some of the models are applied to the same problem to be able to compare the different approaches and to get guidelines which modeling approach fits certain applications best. due to lack of space such a case study is not be included in this paper, but some of the approaches discussed in this paper have been applied to a synchronization algorithm in wireless sensor networks in [hd09], [hdb08], [hd08], and [awd09a], so a comparison between the models and their advantages are left as future work. bibliography [ab02] r. albert, a.-l. barabasi. statistical mechanics of complex networks. review of modern physics 74:47–97, 2002. [awd08] c. auer, p. wüchner, h. de meer. a method to derive local interaction strategies for improving cooperation in self-organizing systems. in hummel and sterbenz (eds.), 3rd int’l workshop on self-organizing systems (iwsos 2008). lecture notes in computer science (lncs) 5343, pp. 170–181. springer verlag, vienna, austria, december 2008. [awd09a] c. auer, p. wüchner, h. de meer. the degree of global-state awareness in self-organizing systems. in thrasyvoulos and hummel (eds.), 4th int’l workshop on self-organizing systems (iwsos 2009). lecture notes in computer science (lncs) 5918, pp. 125–136. springer verlag, zurich, switzerland, december 2009. [awd09b] c. auer, p. wüchner, h. de meer. target-oriented self-structuring in classifying cellular automata. in oliviera and kari (eds.), proc. of 15th international workshop on cellular automata and discrete complex systems (automata2009). pp. 260–271. universidade presbiteriana mackenzie, sao paulo, sp, brazil, 2009. [bgdt06] g. bolch, s. greiner, h. de meer, k. trivedi. queueing networks and markov chains. john wiley & sons, new york, 2nd edition, 2006. [boc04] n. boccara. modelling complex systems. springer, 2004. [cl08] c. g. cassandras, s. lafortune. introduction to discrete event systems. kluwer academic publishers, 2nd edition, 2008. 11 / 12 volume 27 (2010) modeling of self-organizing systems: an overview [dk05] h. de meer, c. koppen. characterization of self-organization. in steinmetz and wehrle (eds.), peer-to-peer systems and applications. lecture notes in computer science (lncs) 3485, chapter 15. characterization of self-organization, pp. 227– 246. springer-verlag, 2005. [dre07] f. dressler. self-organization in sensor and actor networks. john wiley & sons, 2007. [ed08] w. elmenreich, h. de meer. self-organizing networked systems for technical applications: a discussion on open issues. in hummel and sterbenz (eds.), proc. of the 3rd international workshop on self-organizing systems (iwsos ’08), vienna, austria. lncs 5343, pp. 1–9. springer verlag, vienna, austria, december 2008. [gsb02] m. güneş, u. sorges, i. bouazizi. ara – the ant-colony based routing algorithm for manets. in internationalworkshop on ad hoc networking (iwahn 2002). vancouver, british columbia, canada, august 2002. [hd08] r. holzer, h. de meer. on modeling of self-organizing systems. in autonomics 2008. 2008. [hd09] r. holzer, h. de meer. quantitative modeling of self-organizing properties. in iwsos 2009. lncs. springer, 2009. [hdb08] r. holzer, h. de meer, c. bettstetter. on autonomy and emergence in selforganizing systems. in hummel and sterbenz (eds.), iwsos 2008. lncs 5343. springer, 2008. [hey03] f. p. heylighen. the science of selforganization and adaptivity. in kiel (ed.), knowledge management, organizational intelligence and learning, and complexity. the encyclopedia of life support systems. eolss publishers, 2003. [jai91] r. jain. the art of computer systems performance analysis: techniques for experimental design, measurement, simulation, and modeling. john wiley & sons, 1991. [pb05] c. prehofer, c. bettstetter. self-organization in communication networks: principles and design paradigms. communications magazine, ieee 43(7):78–85, 2005. [ss04] c. r. shalizi, k. l. shalizi. blind construction of optimal nonlinear recursive predictors for discrete sequences. in auai ’04: proceedings of the 20th conference on uncertainty in artificial intelligence. pp. 504–511. auai press, arlington, virginia, united states, 2004. [tri01] k. s. trivedi. probability and statistics with reliability, queuing, and computer science applications. john wiley & sons, 2 edition, nov 2001. [ws98] d. j. watts, s. h. strogatz. collective dynamics of ‘small-world’ networks. nature 393:440–442, 1998. [zd97] k. zhou, j. doyle. essentials of robust control. prentice hall, 1997. saks 2010 12 / 12 introduction macro-level modeling discrete-time macro-level modeling discrete-time macro-level modeling with discrete state space discrete-time macro-level modeling with continuous state space continuous-time macro-level modeling continuous-time macro-level modeling with continuous state space continuous-time macro-level modeling with discrete state space bifurcation micro-level modeling discrete-time micro-level modeling continuous-time micro-level modeling network properties from micro-level to macro-level: quantitative measures from macro-level to micro-level: design approaches conclusion a mop based dsl for testing java programs using ocl electronic communications of the easst volume 24 (2009) ocl 09: the pragmatics of ocl and other textual specification languages a mop based dsl for testing java programs using ocl tony clark 15 pages volume editors: j. cabot, j. chimiak-opoka, m. gogolla, f. jouault, a. knapp managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst a mop based dsl for testing java programs using ocl tony clark thames valley university, st mary’s road, ealing, uk, tony.clark@tvu.ac.uk http://itcentre.tvu.ac.uk/~clark/ abstract: ocl is used to specify systems by defining pre and post-conditions for class operations. typically, the conditions refer to properties and operations that are defined in a model. when the model is implemented, various implementation decisions are made regarding properties and operations that cause the ocl conditions to be inconsistent with the implementation. this paper defines a domain specific language (dsl) for testing and shows how a meta-object-protocol for ocl can be used to dynamically run tests written in the dsl against different java implementations of the same model. keywords: ocl, meta-object protocol, domain-specific language, testing. 1 introduction the object-constraint language (ocl) is used to specify the behaviour of system operations in terms of pre and post-conditions that are defined for a uml class model. once specified, the system is implemented. the implementation involves making many technology decisions relating to partitioning, structure, messaging mechanisms, object instantiation, distribution, persistence etc. the system tests are derived from the original model. ideally it should be possible to run the original ocl pre and post-conditions against the implementation. however, ocl does not provide a definition of how to connect to a system implementation. furthermore, the ocl constraints are defined against the original model which is different, due to technology decisions, to the implemented system. in order to make use of a model involving ocl pre and post-conditions in system testing two key issues must be addressed: there must be a mechanism for linking the model with an implementation; and, there must be a mechanism for bridging the difference between the original model and the implementation. our hypothesis is that the language used to express tests in terms of ocl pre and postconditions will depend on the approach taken to testing, therefore it is appropriate to embed ocl within a domain specific language for testing whose semantics provides the required test executions and reporting. furthermore, it is proposed that a meta-object protocol used as the basis for ocl within the dsl is a suitable mechanism for bridging the difference between the original model and the implementation. the contribution of this paper is to show how ocl can be embedded within a dsl for testing. xmf [1] is an open-source object-oriented language for meta-programming and language engineering. xmf is used to define the dsl since it is based on ocl and provides technology for dsl definition; however the approach could be used within any suitable technology. a meta1 / 15 volume 24 (2009) mailto:tony.clark@tvu.ac.uk http://itcentre.tvu.ac.uk/~clark/ testing using an ocl mop figure 1: a sales system object protocol (mop) [17] allows the execution mechansism of a language to be controlled by the programmer. a further contribution is to define the xmf mop that controls how ocl can be linked to java, thereby bridging the implementation issue. this paper is structured as follows: section 2 describes a simple model that will be used as a case study; section 3 describes the key features of the xmf platform that are used to implement the dsl and the mop; section 4 defines a testing dsl and gives examples in terms of the case study; section 5 describes how the dsl is implemented; section 6 describes how the mop can be used to bridge the implementation gap; finally section 7 analyses the approach and describes related systems. 2 a model and its java application fugure 1 shows a model of a sales system (taken from [9]) that consists of components for recording contacts, registering customers, placing orders and delivering orders. the idea is that sales representatives make contact with prospective customers who subsequently register with the system. once registered a customer can place orders for items and the orders are subsequently shipped. consider the operations contact, register and placeorder defined on the class salessystem. each operation can be specified using ocl pre and post-conditions as shown in figure 2: a contact should not be made twice and causes a change in the contacts database; a contact must be made before a customer can register; an order extends a customer’s account with a new item. the operation specifications given in figure 2 are correct with respect to the model in figure 1. the specifications do not constitute a test script since there is no way to link them to an implementation. furthermore, there are a large number of possible implementation choices. for ocl 09 2 / 15 eceasst context salessystem::contact(name:string) pre: not contactsdatabase.contacts->exists(p | p.cid = name) post: contactsdatabase.contacts->exists(p | p.cid = name) context salessystem::register(name:string) pre: contactsdatabase.contacts->exists(p | p.cid = name) and not accountssystem.accounts->exists(a | a.cid = name) post: accountssystem.accounts->exists(a | a.cid = name) context salessystem::placeorder(name:string,amount:int) pre: accountssystem.accounts->exists(a | a.cid = name) post: accountssystem.getaccount(name).items->exists(item | item.amount = amount) and accountssystem.getaccount(name).items->size = self@pre.accountssystem.getaccount(name).items->size + 1 figure 2: sales system operation specifications example, in java, associations with multiplicities greater than 1 may be implemented as vectors or arrays or some associations may be viewed as derived. 3 xmf features this paper proposes that ocl should be embedded into a dsl testing language on an application specific basis and that a mop should be used to map from a model to the system implementation in order that the ocl pre and post-conditions can be run against the implementation. this paper shows how this can be achieved using the xmf platform. this section reviews the key features of xmf that will be used; the features are explained in terms of a simple library example. xmf is an engine that provides a collection of features that support language design. xmf provides an object-oriented language based on an imperative version of ocl. for example, the following is a pair of class definitions for a library containing a collection of books: context root @class book @attribute name : string end end context root @class library @attribute books : seq(book) end end top-level named elements are added to a name-space using the context keyword. in the example above, both book and library are added to the global name-space root. language features in xmf are preceded by @ followed by the name of a syntax class that defines the concrete and abstract syntax representations for the feature. xmf provides many built-in language features, such as class and attribute above, and allows users to define their own. in this paper we will define two new language features that support testing java methods. nested named elements can be defined inside the containing name-space or can be added using context. an operation is a named element that can be added to a class (which is a name-space): 3 / 15 volume 24 (2009) testing using an ocl mop context library @operation addbook(b:book):library self.books := books->including(b) end the addbook operation uses the ocl including operation to add the supplied book to the value of the attribute books. everything in xmf has a type that describes the structure and behaviour of its instances. classes have types which are meta-classes. for example, suppose that the class book is redefined to keep track of all its instances: context root @class instancemanager extends class @attribute allinstances : set(element) end @operation new() let object = super() in self.allinstances := allinstances->including(object); object end end end context root @class book @attribute name : string end end a syntax class introduces a new language feature by defining a grammar that processes concrete syntax. once defined, the new language feature f can occur in any xmf program using the reference @f .... the syntax class is responsible for synthesizing abstract syntax that uses existing language features and ocl. for example, it would be convenient to construct a library by just listing the names of the books initially on the shelves: context library @grammar library ::= names = name* ’end’ { names->iterate(n exp = [| library() |] | [| .addbook(book()) |]) }. end a grammar consists of a collection of named rules, one of which must have the name of the syntax class: this is the starting non-terminal. a library consists of a sequence of names, bound to the rule variable names followed by the terminal ’end’. the synthesizing action within { and } creates an abstract syntax tree that constructs a library and populates it with books. the names of the books are supplied in the language feature; an iterate expression is used to process the names and transform them into calls of addbook. xmf provides quasi-quotes ([| and |]) and drop-quotes (< and >) for syntax templates where quasi-quotes construct abstract syntax trees using concrete syntax and drop-quotes provide template holes. the operation lift is defined for any xmf value and returns an expression that, when executed at run-time, reconstructs the value. therefore the following library: @library book1 book2 end is transformed to: library().addbook(book("book1")).addbook(book("book2")) ocl 09 4 / 15 eceasst xmf provides code walkers that can be used to translate source code. a walker is a class that is supplied with an instance of a given class and then traverses the structure calling operations on the sub-components. a code walker defines operations for all the ocl language features. for example, suppose that large libraries are to be defined and that it is much more efficient to set the books attribute of a library rather than make many calls to addbook. a walker might be defined: context root @class replaceaddbook extends oclwalker @operation walksend(target,name,args) if isnestedaddbook(target,name,args) then [| .books := |] else super(target,name,args) end end end where isnestedaddbook returns true when the supplied arguments are a chained call of addbook, and where getbookexps transforms a collection of nested addbook calls to a sequence expression containing the book expressions. using the code walker, the library feature is translated to: library().books := seq{book("book1"),book("book2")} finally, xmf provides an interface to java where compiled java classes can be manipulated as ordinary xmf classes. for example, suppose that the book class was implemented in java in a package called library then the java class can be loaded: book ::= xmf.javaclass("library.book") after which, subject to a suitable java constructor, the java class can be instantiated and used just like a normal xmf class. when xmf performs an operation (object creation, slot access, slot update and method invocation) on an instance of such a class then the xmf vm makes use of a user defined meta-object protocol (mop) written in java that defines how to handle the operation. a default mop that performs the obvious operation is supplied and used by default. it is useful to be able to extend the java classes that are loaded into xmf. the meta-class javaclass is provided that allows an xmf class to wrap a java class and add new attributes and operations to it. consider a situation where the classes library and book are both implemented in java, then: context root @class library metaclass javaclass javadescriptor("library.library") @operation hasbook(name:string):boolean books->exists(b | b.name = name) end end instantiating the class defined above creates an instance of the java class named in the javadescriptor. methods and fields defined by the java class are available within xmf. the operation hasbook shows how an existing java class in this case library.library) is extended with definitions involving ocl (in this case exists). 5 / 15 volume 24 (2009) testing using an ocl mop context salessystem @mspec successfulcontact[contact](name) pre not contactsdatabase.contacts->exists(p | p.cid = name) do run post contactsdatabase.contacts->exists(p | p.cid = name) end context salessystem @mspec successfulregister[register](name) pre contactsdatabase.contacts->exists(p | p.cid = name) and not accountssystem.accounts->exists(a | a.cid = name) do run post accountssystem.accounts->exists(a | a.cid = name) end context salessystem @mspec successfulplaceorder[placeorder](name,amount) pre accountssystem.accounts->exists(a | a.cid = name) do run post accountssystem.getaccount(name).items->exists(item | item.amount = amount) and accountssystem.getaccount(name).items->size = preself.accountssystem.getaccount(name).items->size + 1 end figure 3: sales system specifications 4 a testing language given a sales system defined in java, our aim is to specify methods in terms of pre and postconditions and to define test scenarios as sequences of method calls. these can be attached to the appropriate java classes by defining a new language feature. each of the java classes are defined in xmf using the meta-class javaclass. the language feature for method specification is: @mspec [] () pre do post end where name is the name of the specification (a given java method may have more than one specification), method-name is the name of the specified java method, args are the names of arguments to the java method, pre-condition and post-condition are ocl expressions, body is an xmf command. the semantics of a method specification is that if the pre-condition is true then the body is performed and the post-condition is expected to be true. the body may reference the special variable run which causes the java method to be called with the supplied arguments. the post-condition may reference preself which is the state of the receiver of the java message before the body is performed. the ocl constraints defined in section 2 are shown, written in the dsl, in figure 3. a scenario language feature just lists the steps in the scenario: context salessystem @test test1 successfulcontact("fred") successfulregister("fred") successfulplaceorder("fred",100) end ocl 09 6 / 15 eceasst 5 language implementation the testing language features described in section 4 are defined as syntax classes in xmf. the method specification feature is defined in section 5.1 and the testing scenario feature is defined in section 5.2. 5.1 method specifications a method specification is added as a new operation to an instance of javaclass. the pre and post-conditions are expressed in ocl and are checked respectively before and after the body of performed. the result of calling a method specification depends on whether the pre and postconditions are satisfied. firstly, the pre-condition is checked, if that fails then the specification returns. otherwise, the body of performed and the post-condition is checked. the rest of this section describes the implementation of the language feature in detail. the structure of the mspec class is defined as follows: context root @class mspec extends xocl::sugar @attribute name : string end @attribute opname : string end @attribute args : seq(string) end @attribute pre : ocl end @attribute body : performable end @attribute post : ocl end @constructor(name,opname,args,pre,body,post) ! end @operation body() subst([| self.send(,args) |]).walk(body) end end note that the pre and post attributes are of type ocl while the body is any performable action. mspec extends the class xocl::sugar which means that the class must provide an operation desugar that is used by the xmf parser to synthesize abstract syntax. therefore, instead of returning abstraction syntax from the grammar rules, the actions simply create an instance of mspec and leave the synthesize work to desugar. the operation body is defined to replace all occurrences of the variable run with a call to the java method. the code walker subst is initialized with an expression and then walks the body of the method specification. its definition is as follows: context root @class subst extends walkers::code::oclwalker @attribute new : ocl end @constructor(new) end @operation walkvar(line,name,arg) if name = "run" then new else super(line,name,arg) end end end the grammar for the mspec language feature is defined below: context mspec @grammar extends ocl::ocl.grammar mspec ::= n = name ’[’ o = name ’]’ as = margs 7 / 15 volume 24 (2009) testing using an ocl mop p = pre d = do q = post ’end’ { mspec(n,o,as,p,d,q) }. margs ::= ’(’ as = cnames ’)’ {as}. cnames ::= n = name ns = (’,’ name)* { seq{n|ns} } | { seq{} }. pre ::= ’pre’ exp. do ::= ’do’ command. post ::= ’post’ exp. end notice that the mspec grammar extends the xmf-supplied grammar for ocl. xmf allows grammars to be extended and therefore all the rules from the parent are included in the child. the ocl grammar provides the rule named exp that parses and synthesizes ocl expressions. the desugar operation is responsible for returning abstract syntax that implements a method specification. the implementation is just an operation with the method specification name. notice that desugar is an operation that returns an operation definition expression. the arguments of the operation expression .args is equivalent to the java args... varargs feature: context mspec @operation desugar() [| @operation (.args) <0.to(args->size-1)->iterate(i x = self.desugarbody() | [| let at(i)> = args->at() in end |])> end |] end the body of the operation is code that binds the names of the arguments to the appropriate element of the args run-time argument. the names are indexed using at at compile-time and the values are indexed at run-time. the body of the specification operation is produced by desugarbody: context mspec @operation desugarbody() [| let preself = self.deepcopy() in if
then let result = in if then callsucceeds(result,,args) else postfails(,args) end end else prefails(,args) end end |] end the body binds a run-time variable preself to a deep copy of the receiver. the implementation of deepcopy (not shown) is implemented on a case-by-case basis by extending the underlying java class from within xmf. the variable preself is used in the post-condition where the values of the fields in the current state of the receiver can be compared to those before the body was performed. there can be three outcomes each of which is an instance of a different class: prefails described the situation where the pre-condition fails; postfails describes the situation where the post-condition fails; and, in callsucceeds both conditions are satisfied and the result is returned. ocl 09 8 / 15 eceasst 5.2 test scripts test scripts are sequences of calls. a call is just a name and argumemts: context root @class call @attribute name : string end @attribute args : seq(performable) end @constructor(name,args) ! end @operation desugar() [| self.send(,iterate(arg x = [| seq{} |] | [| + seq{} |])>)|] end end when a call is translated to abstract syntax using desugar, the resulting expression sends a message to self containing a sequence of arguments. the argument sequence is constructed using iterate which chains together singleton sequences for each argument (expression). the test language feature is defined below: context root @class test extends xocl::sugar @attribute name : string end @attribute calls : seq(call) end @constructor(name,calls) ! end @grammar extends ocl::ocl.grammar test ::= n = name cs = call* ’end’ { test(n,cs) }. call ::= n = name ’(’ as = testargs ’)’ { call(n,as) }. testargs ::= e = exp es = (’,’ exp)* { seq{e | es} }. end @operation desugar() [| @operation () reverse->iterate(call x = [| seq{} |] | [| @case of callsucceeds(result,name,args) do seq{callsucceeds(result,name,args) | } end prefails(name,args) do seq{prefails(name,args)} end postfails(name,args) do seq{postfails(name,args)} end end |])> end |] end end the definition of desugar above uses a case expression to dispatch on the result of calling each method specification. it builds a sequence expression that will terminate if any of the pre or post-conditions fail to be satisfied. the result of a test scenario is a sequence of method specification outcomes which are either all instances of callsucceeds or terminate with a postfails or prefails. 6 a meta-object protocol we have shown that a java implementation of the sales system can be tested using ocl pre and post-conditions by implementing a testing dsl in xmf using an interface that allows java 9 / 15 volume 24 (2009) testing using an ocl mop classes to be manipulated from xmf. the interface supports the creation of new instances, field access and update, and method invocation. the example has assumed that field references and method invocation in ocl maps directly onto the equivalent in java. however, this is not always practical, since implementation choices translate properties and associations in a model and implement them in a variety of ways. the eclipse modelling framework (emf) [2] is used to represent and manipulate models in java. an emf implementation of a model uses factories to create instances of objects and references fields using accessor and updater methods. this is a particular implementation choice compared to, say, using class constructors and direct field reference. a meta-object protocol (mop) can be used to make key execution features extensible. the key features for an object-oriented system are: object creation; field access; field update; method invocation. the mop is implemented using a meta-class and a java class. the defaults are javaclass and foreignobjectmop. this section describes the key features of the standard mop and shows how it can be extended. 6.1 a standard mop a class is instantiated by applying it to initialization arguments. the behaviour for applying a class is defined by the meta-class: context java @class javaclass extends class @attribute descriptor : javadescriptor (?,!) end end the meta-class javaclass defined above extends the basic xmf class with a descriptor that names a java class in the file system. when a descriptor is supplied in the definition of a class with meta-class javaclass the operation adddescriptor is used to process the descriptor: context javaclass @operation adddescriptor(d:javadescriptor) xmf.foreigntypemapping().put(d.type(),self); xmf.foreignmopmapping().put(d.type(),d.mopname()); self.setdescriptor(d) end the operation adddescriptor uses the operations foreigntypemapping and foreignmopmapping in the system object xmf to inform the xmf virtual machine that instances of the xmf class are to be associated with instances of the java class referenced in the descriptor, and to inform the machine of the mop for the class. when a class is applied to arguments in xmf it is instantiated. all meta-classes must implement an operation invoke that describes how to instantiate the receiver: context javaclass @operation invoke(target,args) let class = xmf.javaclass(descriptor.type()) in if class = null then self.error("cannot find java class " + descriptor.type()) else class.invoke(target,args) end end end ocl 09 10 / 15 eceasst public class foreignobjectmop { public void dot(machine machine, int object, int name) { foreignobject f = machine.getforeignobject(object); string string = machine.valuetostring(machine.symbolname(name)); int value = xj.getslot(machine, f.getobject(), string); if (value == -1) machine.sendslotmissing(object, name); else machine.pushstack(value); } public void send(machine machine, int target, int message, int args) { if (!handlebyxocl(machine, target, message, args)) if (!handlebyjava(machine, target, message, args)) nooperationfound(machine, target, message, args); } public boolean hasslot(machine machine, int foreignobj, int name) { foreignobject f = machine.getforeignobject(foreignobj); string string = machine.valuetostring(machine.symbolname(name)); return xj.hasslot(f.getobject(), string); } public void set(machine machine, int obj, int name, int value) { foreignobject f = machine.getforeignobject(obj); string string = machine.valuetostring(machine.symbolname(name)); if(xj.setslot(machine, f.getobject(), string, value) == -1) machine.sendslotmissing(obj, name,value); else machine.pushstack(obj); } } figure 4: a basic java mop when a javaclass is invoked it uses the javaclass operator to load the java class named in the descriptor and then sends it an invoke message. the vm knows that invoking a java class causes it to be instantiated via a suitable constructor. the foreignmopmapping operation associates a java class with a mop. the mop is an instance of the xmf supplied class foreignobjectmop (the default) or one of its sub-classes. the basic features of the default mop are shown in figure 4: the method dot implements field reference; send implements message passing; hasslot tests whether an object has a slot; and, set sets the value. when the vm attempts to perform one of the standard operations on a foreign object it looks up the mop for the object and invokes the appropriate method. the xmf vm is a value of type machine and represents java objects as values of type foreignobject. the xmf library xj uses java.lang.reflect to implement type conversion back and forth between xmf values and java values and also implements basic access to java values. notice in the definition of send we have omitted the definition of handlebyxocl and handlebyjava which use basic machine and xj defined primitives to perform message passing (returning true and pushing the return value if successful). 6.2 ecore mop the mop defined in the previous section could be used to support the testing dsl providing that the implementation of the sales system is in one-to-one correspondence with the model shown in figure 1. consider an emf implementation of the model. in that case instantiation is performed 11 / 15 volume 24 (2009) testing using an ocl mop context java @class emfclass extends javaclass @operation invoke(target,args) let factory = self.getfactory() then package = self.getpackage() then class = package.send("get" + name,seq{}) then object = factory.create(class); constructor = @find(c,self.allconstructors()) when c.names->size = args->size else null end in if constructor <> null then @for name,value in constructor.names,args do object.set(name,value) end end; object end end end figure 5: the emfclass meta-class with respect to a factory and field access must use feature descriptors. this section shows how the basic mop is extended to support ecore. figure 5 shows how javaclass is extended to support ecore instantiation. the invoke operation is modified to use a specialization of javadescriptor that references the appropriate factory and containing package. the package is interrogated for the class to be instantiated and the factory is supplied with the class to produce a new object. since ecore factories do not support constructors (but xmf classes do), the fields are set based on the names defined in the appropriate constructor. figure 6 shows the specialization of foreignobjectmop to support ecore field access. there is no difference between eobjectmop message passing and foreignobjectmop message passing. in all cases, field access and update is performed with respect to feature descriptors. 7 analysis and review a number of ocl interpreters exist, for example [11] and the dresden toolkit (http://dresden-ocl.sourceforge.net/index.php). where these systems address the variations in sut implementation strategies, they do not use a mop. several tools and approaches exist for model based testing including agedis [13], [3] and [19] however, none address the issue of associating ocl with an implementation. ocl is also used to validate models [4] and to describe the behaviour of platform independent models [16] where the implementation issue does not arise. ocl is used as the source of tests and queries in a number of systems. for example [20] and[14] generate code from conditions expressed as ocl. in many cases model transformations ocl 09 12 / 15 eceasst public class eobjectmop extends foreignobjectmop { public void dot(machine machine, int object, int name) { foreignobject f = machine.getforeignobject(object); eobject eobject = (eobject)f.getobject(); eclass eclass = eobject.eclass(); string string = machine.valuetostring(machine.symbolname(name)); estructuralfeature feature = eclass.getestructuralfeature(string); if (feature == null) machine.sendslotmissing(object, name); else machine.pushstack(xj.mapjavavalue(machine, eobject.eget(feature))); } public boolean hasslot(machine machine, int foreignobj, int name) { foreignobject f = machine.getforeignobject(foreignobj); eobject eobject = (eobject)f.getobject(); eclass eclass = eobject.eclass(); string string = machine.valuetostring(machine.symbolname(name)); estructuralfeature feature = eclass.getestructuralfeature(string); return feature != null; } public void set(machine machine, int obj, int name, int value) { foreignobject f = machine.getforeignobject(obj); eobject eobject = (eobject)f.getobject(); eclass eclass = eobject.eclass(); string string = machine.valuetostring(machine.symbolname(name)); estructuralfeature feature = eclass.getestructuralfeature(string); if (feature == null) machine.sendslotmissing(obj, name,value); else { class type = feature.getetype().getinstanceclass(); object newvalue = xj.mapxmfvalue(machine, type, value); eobject.eset(feature, newvalue); machine.pushstack(obj); } } } figure 6: ecore mop are used to produce code; the approach described here allows the user to interact with the system under test (sut) via the xmf interpreter without a separate compilation step. whether code is generated or the ocl is interpreted directly, the problem of taking implementation issues into account that differ from the model remains; the novel approach described here involves the use of a mop to drive an interpretation engine for ocl, the same approach could be used to drive a transformation engine. an earlier version of this work was presented as an invited talk at an astranet workshop [5], as a tutorial [6] and in [7], where ocl expressions are expressed using both textual and graphical formats. this paper extends that work by addressing the issue of the implementation mapping. mops were used in the definition of smalltalk and the original description of how to implement a mop is given in [17]. code generation techniques using a mop are described in [15] where the openc++ compiler is extended to allow tests to be inserted into code. the xmf approach of using syntax classes to define dsls is defined in [8]. the integration of ocl with model-based (i.e. mof defined) dsls is discussed in [18]. other dsls have 13 / 15 volume 24 (2009) testing using an ocl mop been defined that support testing, for example [12] which is not based on ocl and the language reported in [10] which is based on ocl but does not use a mop to link to the implementation. junit can be viewed as a dsl for testing java programs and can be used in conjunction with ocl engines. the work described in this paper is more flexibile through the use of mops and the meta-interface of java. references [1] xmf version 2.2, 2008. http://itcentre.tvu.ac.uk/˜clark/downloads.html. [2] eclipse modelling framework, 2009. http://www.eclipse.org/modeling/emf/. [3] d. arnold, j.-p. corriveau, and v. radonjic. open framework for conformance testing via scenarios. in oopsla ’07: companion to the 22nd acm sigplan conference on object oriented programming systems and applications companion, pages 775–776, new york, ny, usa, 2007. acm. [4] e. g. aydal, r. paige, and j. woodcock. observations for assertion-based scenarios in the context of model validation and extension to test case generation. software testing verification and validation workshop, ieee international conference on, 0:11–20, 2008. [5] t. clark. iswim for testing a model driven approach. invited talk, feb 2007. presentation available at http://itcentre.tvu.ac.uk/˜clark/presentations/iswim for testing.pdf. [6] t. clark. a domain specific language for testing. tutorial, feb 2008. tutorial available at http://itcentre.tvu.ac.uk/˜clark/xmf/. [7] t. clark. model based functional testing using pattern directed filmstrips. in proceedings of the 4th international workshop on the automation of software test. ieee computer society, 2009. [8] t. clark, p. sammut, and j. s. willans. beyond annotations: a proposal for extensible java (xj). in scam, pages 229–238, 2008. [9] d. f. d’souza and a. c. wills. objects, components, and frameworks with uml: the catalysis approach. addison-wesley longman publishing co., inc., boston, ma, usa, 1999. [10] m. felderer, r. breu, j. chimiak-opoka, m. breu, and f. shupp. concepts for model-based requirements testing of service oriented systems. in software engineering, 2009. [11] m. gogolla, f. büttner, and m. richters. use: a uml-based specification environment for validating uml and ocl. sci. comput. program., 69(1-3):27–34, 2007. [12] j. grabowski, a. wiles, c. willcock, and d. hogrefe. on the design of the new testing language ttcn-3. testing of communicating systems. ural, h, probert, r l, von bochmann, g (eds.). dordrect, kluwer, 13:161–176, 2000. ocl 09 14 / 15 eceasst [13] a. hartman and k. nagin. the agedis tools for model based testing. sigsoft softw. eng. notes, 29(4):129–132, 2004. [14] f. heidenreich, c. wende, and b. demuth. a framework for generating query language code from ocl invariants. eceasst, 9, 2008. [15] c. hobatr and b. a. malloy. using ocl-queries for debugging c++. in icse ’01: proceedings of the 23rd international conference on software engineering, pages 839–840, washington, dc, usa, 2001. ieee computer society. [16] p. kelsen, e. pulvermueller, and c. glodt. a declarative executable language based on ocl for specifying the behavior of platform-independent models, 2007. [17] g. kiczales. the art of the metaobject protocol. the mit press, july 1991. [18] d. s. kolovos, r. f. paige, and f. polack. aligning ocl with domain-specific languages to support instance-level model queries. eceasst, 5, 2006. [19] a. pretschner and j. philipps. methodological issues in model-based testing. in modelbased testing of reactive systems, pages 281–291, 2004. [20] šarūnas packevičius, a. ušaniov, and e. bareiša. software testing using imprecise ocl constraints as oracles. in compsystech ’07: proceedings of the 2007 international conference on computer systems and technologies, pages 1–6, new york, ny, usa, 2007. acm. 15 / 15 volume 24 (2009) introduction a model and its java application xmf features a testing language language implementation method specifications test scripts a meta-object protocol a standard mop ecore mop analysis and review electronic communications of the easst volume 31 (2010) proceedings of the second international workshop on visual formalisms for patterns (vffp 2010) visual specification patterns andrew fish, ali hamie, john howse 14 pages guest editors: paolo bottoni, esther guerra, juan de lara managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 eceasst visual specification patterns andrew fish, ali hamie, john howse university of brighton, uk abstract: visual modelling notations such as constraint diagrams can be used for the behavioural specifications of software components. this includes specifying invariants on classes or types and preconditions and postconditions of operations. however, one current problem in specifying components comes from the fact that editing constraints manually is time consuming and error prone and so we may adopt a pattern-based approach to alleviate this problem. one way to simplify the definition of constraints is to identify and capture those recurring constraints in the form of visual specification patterns. such patterns would facilitate the automatic generation of diagrammatic constraints. this paper identifies some specification patterns that frequently occur when specifying software components and provides a diagrammatic representation of these patterns. this will form the basis of a library of specification patterns that could be used in the context of tools. we also show how such patterns can be combined in order to specify more complex constraints. keywords: formal specification, constraint diagrams, visual formalisms 1 introduction component-based development or cbd is a software development approach where software applications are built using components, and these components can come from a number of different sources, be written in several different programming languages, etc. by employing such an approach one can improve the efficiency and quality of software development and increase the flexibility of the resulting software systems [sgm02]. an essential prerequisite towards achieving the goal of cbd is an appropriate and standardized specification of software components. visual modelling notations such as constraint diagrams [ken97] can be used for specifying the behavioral aspects of software components and their constraints. constraint diagrams are a formal diagrammatic language that can be used for describing invariants on classes as well as preconditions and postconditions of operations. however, developing constraint specifications for software components is time consuming and an often error prone task. this is because typical specifications may contain numerous constraints, which in addition often state complex facts about the elements of the component’s model. ackermann [ack05a, ack05b, at06] proposes a solution to this problem based on the idea of specification patterns from which ocl [wk03] constraints can be automatically generated. nine patterns that frequently occur in the behavioural specifications of software components have been identified in [ack05b]. to simplify constraint definition we follow a similar approach by using specification patterns from which visual constraints can be generated automatically. this applies in the context of specifying components in a diagrammatic way. as a first step towards achieving this goal we identify a list of frequently occurring specification patterns and describe them in some detail. the 1 / 14 volume 31 (2010) visual specification patterns a r a class name i a f a b a dc figure 1: an invariant event: addelement(x) a’ x a x i figure 2: event specification main contributions of this paper are: the proposal to use visual specification patterns to simplify component specifications, the identification of frequently occurring specification patterns within the modelling framework and the development of a description scheme to characterize those patterns. the ocl specification for the identified patterns will also be included alongside the diagrammatic specification. 2 the diagrammatic framework a class is modeled in terms of an invariant and its operations, specified as pre/post condition contracts. the diagram in figure 1 is an example of an invariant. this diagram consists of three sub-diagrams. the closed curves (circles, ellipses, rectangles) represent sets. in each sub-diagram, the curves form an euler diagram and their spatial relationships express semantic relationships between the sets: non-overlapping curves assert that the sets are disjoint; a curve placed inside another asserts a subset relationship. we use the convention that labelled rectangles represent types. the dots are called spiders. unlabeled spiders assert the existence of elements in the sets represented by the regions of the diagram in which they are placed. the labeled spiders in this diagram are acting as free variables. an arrow represents a binary relation, where its source and target may be either a spider or a curve; its target then corresponds to the image of its source under a relation identified by the label on that arrow. in the first sub-diagram there are two disjoint sets a and b. the spider labeled a is a free variable and is the source of the arrow f , while the target of f is a spider in b; thus f represents a function mapping each element of a to an element in b. different spiders represent distinct elements, so there is an element in b that is not the image of a under f . in the second sub-diagram c and d are disjoint sets and each is a subset of a. as there are no spiders in it, the shaded region represents the empty set. so this sub-diagram asserts that a is partitioned into subsets c and d. in the third sub-diagram the rectangle represent a type. the arrow labeled r represents a relation as it maps each element of a to a subset of i. the semantics of the sub-diagrams are conjoined to give the semantics of the diagram. operations are divided into queries and events. queries specify operations that may be approc. vffp 2010 2 / 14 eceasst plied to an object of a class leaving its state unchanged, whereas events specify their allowable changes-of-state. either may have inputor output-arguments that are declared in its precondition. each event also has a post-condition, wherein ‘dashed’ names denote values of the corresponding variable after any occurrence of the event, adapting the same convention from z, and playing the role of the @pre operator in ocl. the diagram in figure 2 specifies an event for adding an element to a set. this event is specified in terms of a pre-condition and a post-condition. the pre-condition is specified above the line and the post-condition below the line. the diagram can be interpreted as ‘if the conditions above the line hold then the conditions below the line hold after an occurrence of the event’. in the pre-condition x (which is of type i) is not in a and in the post-condition x is in a′, the updated version of a. so this event adds x to a. this framework uses the convention ‘the rest remains unchanged’ [spb90] to allow operation constraints to be presented in concise from. more details about the framework and the diagrammatic approach can be found in [hs05, ffh05]. some of the benefits of diagrammatic notations are evident in the diagrams we have seen so far, where both set intersection, disjointness and containment are represented visually. these diagrams have properties that are thought to correlate with areas where diagrams are superior to symbolic notations, from a user interpretation perspective, because they are well-matched to their set-theoretic semantics [gur01]. extending this observation, using containment to represent set inclusion has the added benefit that the transitive property of the (semantic) subset relation is mirrored by the transitive property of (syntactic) containment. 3 diagrammatic specifications and visual specification patterns most approaches to component specification recommend the use of formal mathematical notations since they enable a common understanding of specification results across different developers and companies. the use of formal methods, however, is not undisputed. some authors argue that the required effort is too high and the intelligibility of the specification results is too low for a discussion of advantages and liabilities of formal methods see [hal90]. the use of visual notations for specifying components has the advantage of being more intuitive and accessible to developers than formal mathematical notations that are based on set theory and predicate logic. despite their advantages visual modelling notations cannot solve all problems associated with the use of formal methods. writing and editing constraint diagrams manually can sometimes be time consuming and error-prone. according to ackermann [ack05a], the same problem is encountered when using ocl to specify software components. similar experiences were made by other authors that use ocl constraints in specifications (outside the component area) [ldf04, hjr02]. they conclude that it takes a considerable effort to master ocl and use it effectively. however, behavioral aspects have great importance for component specifications. for example, the specification of components within a video rental service case study have filled many pages and required significant effort. for component specifications to be practical it is therefore indispensable to simplify the diagrammatic-based behavioral specification. a strategy to simplify diagrammatic specifications and reduce errors include better tool support and the use of predefined visual specifications patterns. the latter approach seems to be 3 / 14 volume 31 (2010) visual specification patterns particularly promising since the analysis of the video rental service case study reveals that most of the constraints can be derived from a few, frequently occurring, specification patterns. an example of such a pattern is the following: an attribute of a class in the specification type diagram is unique for each instance. that is the attribute plays the semantic role of a key. the way to use such patterns in the specification is as follows. assume that the modeler needs to describe a certain behavioural condition in the diagrammatic notation. first he checks the library of predefined visual specification patterns which is part of his specification tool and finds a matching one. once a suitable pattern is found the modeler does not need to write/draw it manually but instead he selects the pattern and provides the model elements for which the pattern shall be applied. the tool then checks his input for consistency and generates the constraint. the advantage of this approach is that the specification process is simplified because the specification is generated automatically, is less error-prone and requires less expertise in the visual modelling notation. moreover, when the patterns are well-known, it will be enough to specify a pattern (without the generated diagrams) allowing the user to recognize the constraint more easily. in order to achieve this goal we proceed as follows. first, visual constraints that frequently occur in component specifications are identified. then we develop a description technique that enables the description of those patterns in such a way that they can be adapted to special cases and automatically generated into diagrammatic constraints. lastly, the description technique is applied to the identified patterns so that a generator can be implemented for each pattern. any newly identified patterns can easily be included in the pattern library at a later time. 4 frequently occurring specification patterns in this section we present a list of patterns that frequently occur in the behavioral specification of software components. these patterns will be presented in diagrammatic form using constraint diagrams. in order to identify such patterns several case studies were considered, including a video rental service [hs05], library systems, medical information models and a variety of collected specification examples. 4.1 description scheme for specification patterns in this section we provide a description of some specification patterns. this includes all of the relevant details of a pattern presented in a structured and uniform way. the first characteristic is the pattern name that identifies the pattern and serves as a short semantic explanation. all patterns have one or more parameters that allow the adaptation of the pattern to specific contexts. the pattern lists these parameters together with their types unless it is clear from the context in which case the type is omitted. parameter names are a means of matching up diagrammatic entities. parameters can be of elementary type (like string) or are elements from the diagrammatic notation. for example, a parameter could be a curve representing a set or an arrow representing an association or relation. type parameters are omitted when the pattern applies for any type. the description can also document the restrictions on the application of the pattern, such as the conditions that the pattern parameters must fulfill. for example, for a pattern with proc. vffp 2010 4 / 14 eceasst a cb pattern: binarypartition(a,b,c) patient deadalive title excollincoll figure 3: binary partition parameters op (of type operation) and par (of type parameter) it might be required that par is a parameter of op. 4.2 constraint patterns in invariants in this section we consider patterns that frequently occur when specifying invariants on types or components. pattern 1: binary partition the binary partition constraint is very common (figure 3). it partitions a given set a into two subsets b and c. the name of the pattern is binary partition, and the sets a, b, and c are the parameters of the pattern. the pattern constraint is an invariant that is valid for the input parameters. the constraint asserts that sets b and c partition set a (although the sets b and c can be empty). examples of this pattern can be found when specifying medical information and library systems. applying the pattern to these systems yields the invariants shown in the two diagrams on the right hand side of figure 3. the diagram on the left is an instantiation of binarypartition(a, b,c) with parameter a instantiated as patient, b as alive and c as dead and asserts that a patient is either dead or alive (but not both). the diagram on the right is an instantiation of binarypartition(title, incoll, excoll) and asserts that a title is in a library’s collection (incoll) or not in the collection (excoll). the binary partition constraint generalizes to any set partition. in ocl, this constraint (ignoring the context) can be stated as follows: inv : a = b → union(c) and b → intersection(c) = set{} where union and intersection are the ocl operations for set union and set intersection respectively. the → indicates applying an operation on the whole set or collection. the keyword inv indicates that the constraint is an invariant. 5 / 14 volume 31 (2010) visual specification patterns pattern: disjointtargets(x,r,s) r x s rental t reservation figure 4: disjoint targets pattern 2: disjoint targets the pattern shown in figure 4 is also very common, and asserts that the relational images of some value under two relations are disjoint. the name of the pattern is dis jointtargets, and the parameters are the value x and the relations r and s. the constraint asserts that the relational images of x under r and s yields disjoint sets and that these sets do not contain x. the diagram on the right hand side of figure 4 shows an instantiation of the pattern which comes from a video rental store specification. it is dis jointtargets(t, rental, reservation) and asserts that the rentals and reservations of (title) t are disjoint, indicating that no video title can be both rented and reserved (by the same member) at the same time. the set of members renting title t is given by the closed curve at the end of the arrow labeled rental; this set is seen to be disjoint from the set of members reserving t. in ocl, this pattern is common and occurs when navigating associations on a class diagram. suppose that r and s represent role names of two associations between class a and class b with multiplicity ∗ at the b’s end. let x be an object of class a, then x.r and x.s are two subsets of b denoting the relational images of r and s respectively. the constraint is specified in ocl as follows: inv : x.r → intersection(x.s) = set{} and not(x.r → includes(x)) and not(x.s → includes(x)) in the context of ocl, the parameters of the pattern include the classes a and b, and the association roles r and s. proc. vffp 2010 6 / 14 eceasst pattern: commontarget(x,f,g) f x g originator n destination figure 5: common target pattern 3: common target the application of two functions to a value gives the same result. this pattern is shown in figure 5. the pattern name is commontarget and the parameters are the value x and the functions f and g. the pattern constraint asserts that the functional images of x under both f and g yield the same element, which is distinct from x. the diagram on the right hand side of figure 5 shows an instantiation of the pattern that comes from a medical information specification. it is commontarget(n, originator, destination) and asserts that the originator and destination of (note) n must be common; for example, a doctor writes a note to herself. in ocl this pattern can be stated as inv : x. f = x.g and x <> x. f and x <> x.g, where f and g represent role names of two associations between class a and class b with multiplicity 1 at b’s end. pattern dis jointtargets was specified in terms of relations while pattern commontarget was specified in terms of functions. we could have specified variations of each pattern in terms of functions or relations, respectively. there are generalizations of these patterns that could involve, for example, the subset relation on the relational images. 4.3 constraint patterns in operation specifications in this section we consider some patterns that frequently occur when specifying operations in terms of preconditions and postconditions. so the type of constraints the patterns provide are either a precondition or postcondition. pattern 4: add element this pattern is ubiquitous (figure 6). it is common in many specifications when an element is to be added to a set or collection. the pattern name is addelement and the parameters are the set a and the element x. the pattern constraint has two parts. the first part is a precondition 7 / 14 volume 31 (2010) visual specification patterns pattern: addelement(x,a) a’ x a x operation: addtitle(t,title) title’ t title t figure 6: add element constraint (above the line) which states that the element x is not currently a member of the set a. the other part is a postcondition constraint (below the line) which states the effect of applying the operation addelement namely that x becomes an element of a. an instantiation of this pattern is shown on the right of figure 6. it is addelement(t, title) and specifies an operation that adds a new title t to an existing set of titles in the context of a library specification. recall that the framework for the diagrammatic notation assumes that “the rest remains unchanged” so that no existing titles are removed and no title other than t is added. we can extend this pattern to include type information t for the elements. this is shown in figure 7. in this case the type of the element x and the elements of set a are made explicit. type information could, of course, be added to any pattern, such as the patterns considered earlier. in ocl the precondition and postcondition constraints of the add element operation can be stated as pre : a → excludes(x) and post : a → includes(x) respectively. here pre : indicates that the type of constraint is a precondition and post : indicates that the constraint is a postcondition. for the library example, if catalog represents the set of titles for the library at a point in time, then the precondition takes the form catalog → excludes(t) and the postcondition takes the form catalog → includes(t). note that the ocl postcondition states the minimal requirement with the implicit assumption that the rest of the set remains unchanged. an alternative way to write the postcondition is to explicitly state that the rest remains unchanged as catalog = catalog@ pre → union(set{t}), where catalog@pre denotes the set of titles at precondition time. pattern 5: add subset the add element pattern can be generalized to add a set of elements to a set which we name the addsubset pattern. this pattern is shown in figure 8. the parameters of the pattern are sets a and x . the precondition constraint states that a and x are disjoint sets. the postcondition conproc. vffp 2010 8 / 14 eceasst pattern: addelement(x,a,t) a’ x a x t figure 7: add element pattern: addsubset(x,a) a’ a x x figure 8: add subset pattern: removeelement(x,a,t) a x a’ x t figure 9: remove element straint states that x is a subset of a. the condition for applying the pattern is that the elements of both a and x are of the same type. type information can also be included in the diagram. describing the add subset pattern in ocl is similar to the add element pattern. for the precondition we use the operation excludesall instead of excludes, thus pre : a → excludesall(x ). for the postcondition we replace includes with includesall, thus post : a → includesall(x ). pattern 6: remove element removing an element from a set is also a very common pattern. this pattern is shown in figure 9. the name of the pattern is remove element and the parameters include the element x, the set a and the type t . the pattern can be applied under the condition that x and the elements of a are of type t . the pattern constraint consists of the precondition which asserts that the element to be removed is already in the set, and the postcondition which states that x is no longer an element in the set a. the remove element pattern can stated in ocl as pre : a → includes(x) and post : a → excludes(x). 9 / 14 volume 31 (2010) visual specification patterns title excoll incoll t1 t2 nc nc 0 nat figure 10: combining patterns x y f g pattern: distinctsourcesandtargets(x,y,f,g) figure 11: distinct sources and targets 5 combining patterns visual specification patterns can be combined in a variety of ways to specify more complex constraints. the most obvious way of combining patterns is by simple conjunction. in the diagrammatic framework these could be represented by two separate diagrams and frequently this would be the most appropriate way of expressing the combination. however, there are more interesting ways of combining patterns. figure 10 shows a constraint on a library system that specifies that the number of copies (in the library’s collection) of an ex-collection title is zero, while an in-collection title has a positive number of copies. the two subsets of the set title, ex-coll and in-coll are disjoint and partition the set title. nat represents the set of natural numbers and nc is a function that takes a title and delivers the number of copies of that title in the library’s collection. visually, we can see that the number of copies of an ex-coll title t1 is zero, as t1 is mapped to the element 0 by the arrow nc and the number of copies of an in-coll title t2 is positive, because the arrow nc maps t2 to a natural number that is not zero, as it is distinct from zero, and is hence positive. figure 11 shows a variation on the disjoint targets pattern, called distinctsourcesandtargets. a combination of the binary partition pattern (figure 3), binarypartition(title, excoll, incoll), and the distinct targets pattern, distinctsourcesandtargets(t1,t2, nc, nc), can be used to construct the constraint represented in figure 10. however, combining visual patterns is non-trivial. in this example, the elements t1 and t2 need to be placed in the circles excoll and incoll, respectively. defining a framework to facilitate this is challenging and will be considered in further work. finally, some post-application annotation is required in order to label one of the elements 0, although this could also be achieved by adapting distinctsourcesandtargets to include extra, optional, parameters to label the target elements. 6 related work in the context of object-oriented modelling and component specifications, ocl is considered to be a very important formalism. however, developing concise and correct constraints in ocl is difficult. this problem has been addressed by numerous publications some of which use the idea of constraint patterns in order to capture recurring domain constraints and make it reusable. patterns for constraints in model-driven development were considered in [bhss00], which proc. vffp 2010 10 / 14 eceasst proposes a mechanism for connecting design patterns with ocl constraints; it enables the instantiation of ocl constraints automatically whenever a design pattern is instantiated. the notion of constraint patterns is further elaborated in [at06, abb+05], where a small number of simple constraint patterns is presented along with ocl templates. the two publications [em05, cgq+06] introduce a larger number of constraint patterns. the patterns presented there originate from the data modelling domain. [wkb07] builds on these approaches by introducing composite patterns which allows users to negate patterns and to combine existing patterns using logical connectives such as implication. a category-theoretic language independent approach to pattern formalization and composition is presented in [bgl10]. our contribution adopts the idea of constraint patterns to diagrammatic modelling using constraint diagrams and other diagrammatic notations. by mapping some of the ocl constraint patterns to constraint diagrams one gets the benefit of visualizing ocl constraints in the context of object-oriented modelling using uml. 7 discussion and future work we have identified some basic diagrammatic constraint patterns that occur frequently in simple case studies, with the intention of enabling the development of a tool, with access to a library of constraint patterns, that enables a user to instantiate these patterns within their modelling framework. the approach is flexible in general, allowing the use of the diagrams as both a specification and modelling language, or just allowing the use of the diagrams as a constraint language for placing constraints over some metamodel in the same manner as ocl is used, for example. of course, we have only presented some examples of patterns, and one has no means of deciding when one has “enough” patterns. however, as one means of measurement, we can create diagrammatic constraint patterns covering all of the examples of ackermann [ack05b]. however, as usual there is a trade-off between the benefits of utilising diagrammatic notations and textual notations, and attempting to understand the pro/cons of the choice of textual/diagrammatic notation for modelling constraints is one future avenue of interest. attempting to classify constraints into preferential categories of textual, diagrammatic, or either would enable tools to offer choices of presentation of constraints, although of course this brings the disadvantage of requiring the use of more than one modelling notation. for example, some constraints, such as ackermann’s 2nd pattern, “invariant for a property value (e.g. age > 18)”, appear to be be more naturally expressed in textual format, whereas constraints that can be formulated to make use of spatial relationships such as containment or exclusion (e.g. set membership or containment) benefit from the diagrammatic notation. in terms of the approach to pattern development adopted, one can ask the question of how natural certain patterns are within the modelling language. here, we took the stance of developing patterns with reference to existing diagrammatic case studies. as such, one can ask the question: are all of the constraint patterns that arise inherent in the models we are dealing with, or are some of them arising due to the modelling language itself? for example, properties like the uniqueness of some attribute would seem to be inherent, whilst the modelling language may tailor the type of model and constraint one constructs and so specific forms of constraints may 11 / 14 volume 31 (2010) visual specification patterns occur. we observe that there is an overlap between the ocl constraint patterns that ackermann, who took an ocl-oriented developmental approach, identifies, and the diagrammatic constraint patterns presented here, but that they are not the same; some constraints stand out more in one language as opposed to the other (e.g. disjoint targets in the diagrams setting versus invariant attribute value for textual setting). there are obvious extensions of the constraint patterns such as extend binary partition to n-ary partition, depicting this using ellipsis, and similarly for disjoint targets, for instance. another area of future investigation is the development of alternative patterns, within the same language, for the same constraints. for example, using diagrams one can represent relations using labelled arrows, or by allowing sets to be labelled by the cartesian product of two sets, thereby utilising a curve/label based representation. although the use of arrows appears to be the most natural way of visualising functions or relations in this notation, when one considers the combination of constraints or constraint patterns, the choice of representation will play an important role in how well such patterns fit together. the avenue of facilitating the combination of constraint patterns is likely to bring great benefits, extending the expressivity of the approach (enabling the specification of more complex constraints, such as nested constraints) in a natural manner. this approach could take several forms, but one could consider enabling the combination of two patterns that have something (like a set) in common, enabling the building of more complex constraints over the model. one could allow the matching of patterns within other patterns, such as asserting the uniqueness of an attribute after specifying some constraint that contains that attribute. in these cases, the point is that we are allowing the patterns to match not only over the model itself but also over the constraints already constructed. further work also involves the development of a formal framework to facilitate the use of diagrammatic constraint patterns in specification; such a framework could be based on [bgl10]. bibliography [abb+05] w. ahrendt, t. baar, b. beckert, r. bubel, m. giese, r. hähnle, w. menzel, w. mostowski, a. roth, s. schlager, p. h. schmitt. the key tool. software and system modeling 4(1):32–54, 2005. [ack05a] j. ackermann. formal description of ocl specification patterns for behavioral specification of software components. in baar (ed.), proceedings of the models’05 conference workshop on tool support for ocl and related formalisms needs and trends, montego bay, jamaica, october 4, 2005. technical report lgl-report-2005-001, pp. 15–29. epfl, 2005. [ack05b] j. ackermann. frequently occurring patterns in behavioral specification of software components. in component-oriented enterprise applications. proceedings of the conference on component-oriented enterprise applications (coea. pp. 41–56. 2005. proc. vffp 2010 12 / 14 eceasst [at06] j. ackermann, k. turowski. a library of ocl specification patterns for behavioral specification of software components. lecture notes in computer science 4001:255–272, 2006. [baa05] t. baar. ocl and graph-transformations a symbiotic alliance to alleviate the frame problem. in proc. models satellite events 2005. pp. 20–31. 2005. [bgl08] p. bottoni, e. guerra, j. de lara. enforced generative patterns for the specification of the syntax and semantics of visual languages. jvlc 19(4):429–455, 2008. [bgl10] p. bottoni, e. guerra, j. de lara. a language-independent and formal approach to pattern-based modelling with support for composition and analysis. information and software technology 52(8):821–844, 2010. [bhss00] t. baar, r. hähnle, t. sattler, p. h. schmitt. entwurfgesteuerte erzeugung von oclconstraints. softwaretechnik-trends 20(3), 2000. [bkpt00] p. bottoni, m. koch, f. parisi-presicce, g. taentzer. consistency checking and visualization of ocl constraints. in proc. uml 2000. lecture notes in computer science 1939, pp. 294–308. springer, 2000. [cd00] j. cheesman, j. daniels. uml components: a simple process for specifying component-based software. addison-wesley, 2000. [cgq+06] d. costal, c. gómez, a. queralt, r. raventós, e. teniente. facilitating the definition of general constraints in uml. in models. lecture notes in computer science 4199, pp. 260–274. springer, 2006. [dw98] d. f. d’souza, a. c. wills. objects, components, and frameworks with uml: the catalysis approach. addison-wesley, reading, 1998. [em05] l. n. elita miliauskaite. representation of integrity constraints in conceptual models. information technology and control 34:355–365, 2005. [ffh05] a. fish, j. flower, j. howse. the semantics of augmented constraint diagrams. jvlc 16:541–573, 2005. [gur01] c. gurr. aligning syntax and semantics in formalisations of visual languages. in in proceedings of ieee symposia on human-centric computing languages and environments. pp. 60–61. ieee computer society press, 2001. [hal90] a. hall. seven myths of formal methods. ieee software 7(5):11–19, 1990. [hjr02] r. hähnle, k. johannisson, a. ranta. an authoring tool for informal and formal requirements specifications. in fundamental approaches to software engineering, 5th international conference fase. pp. 233–248. grenoble, june 2002. [hs05] j. howse, s. schuman. precise visual modeling: a case-study. software and system modeling 4(3):310–325, 2005. 13 / 14 volume 31 (2010) visual specification patterns [ken97] s. kent. constraint diagrams: visualizing invariants in object-oriented models. in oopsla ’97: proceedings of the 12th acm sigplan conference on objectoriented programming, systems, languages, and applications. pp. 327–341. acm, new york, ny, usa, 1997. [ldf04] y. ledru, s. dupuy, h. fadil. towards computer-aided design of ocl constraints. in proceedings of caise’04 workshops vol. 1 -emmsad’04: evaluating modeling methods for systems analysis and design. pp. 329–338. riga, june 2004. [sgm02] c. szyperski, d. gruntz, s. murer. component software: beyond object-oriented programming. acm press and addison-wesley, ny, second edition edition, 2002. [spb90] s. schuman, d. pitt, p. byers. object-oriented process specification. in rattray (ed.) specification and verification of concurrent systems, proc. facs workshop, springer. pp. 21–70. 1990. [wk03] j. warmer, a. kleppe. the object constraint language: getting your models ready for mda. addison-wesley, reading, ma, 2003. [wkb07] m. wahler, j. koehler, a. d. brucker. model-driven constraint engineering. electronic communications of the easst 5, 2007. http://eceasst.cs.tu-berlin.de/index.php/eceasst/article/view/44/70 proc. vffp 2010 14 / 14 tightly coupled verification of pervasive systems electronic communications of the easst volume 22 (2009) proceedings of the third international workshop on formal methods for interactive systems (fmis 2009) tightly coupled verification of pervasive systems muffy calder, phil gray and chris unsworth 16 pages guest editors: michael harrison, mieke massink managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst tightly coupled verification of pervasive systems muffy calder, phil gray and chris unsworth department of computing science university of glasgow glasgow g12 8rz, uk abstract: we consider the problem of verifying context-aware, pervasive, interactive systems when the interaction involves both system configuration and system use. verification of configurable systems is more tightly coupled to design when the verification process involves reasoning about configurable formal models. the approach is illustrated with a case study: using the model checker spin [hol03] and a sat solver [es03] to reason about a configurable model of an activity monitor from the match homecare infrastructure [mg09]. parts of the models are generated automatically from actual log files. keywords: formal models, pervasive systems, model checking 1 introduction effective verification of interactive systems has been a significant challenge for both the verification and user interface communities for at least the last two decades [ch97, crb07]. more recently, the advent of context-aware, pervasive, interactive systems raises the stakes: can we formulate effective verification techniques and strategies to bring reasoning into the design processes of these volatile systems? in particular, we are concerned with systems where the interaction involves both system configuration and system use. pervasive systems are characterised by their ability to sense their physical environment and a use of data so gathered both as part of the core application functionality and as a way of modifying system behaviour to reflect changes in the context of use. amongst the challenges of designing, building and operating such systems is the volatility that this sensor-based context dependency introduces. the set of sensors may themselves come and go and change their behaviour depending upon environmental conditions. context changes may be difficult to model and predict. in addition, pervasive applications often operate in situations that require practically unpredictable changes to the application functionality itself. for example, a home care system, providing sensor-based monitoring of the cared person’s activities and state, may have to be reconfigured to take into account changes in the person’s medical condition and their home situation, and consequent changes to the services and sensors needed. for these reasons, system configuration must be treated as an ongoing process throughout the lifetime of a system. it must be modelled and reasoned about in the same way that one would model and reason about normal user interaction with the system. at a high level of abstraction these context-aware, interactive systems may be regarded as a number of concurrent processes: agents||sensors||out puts||monitors||con f iguration||system 1 / 16 volume 22 (2009) tightly coupled verification of pervasive systems where • agents are (usually, but not exclusively human) users, there may be several types and (possibly overlapping) instances of user, e.g. patient, carer, social worker, etc. • sensors and out puts quantify physical world data (e.g. thermometer, pressure pad, webcam), or are outputs devices (e.g. speaker, television screen), • monitors are high level abstractions of a physical state (e.g. encapsulating predicates about who is in a room, whether or not is it cold), • con f igurations are sets of rules, or actual parameters, determining how the system varies according to user preferences and needs, • the system is the underlying computational infrastructure. while we might traditionally consider the composition (agents||sensors||out puts||monitors) as the context, i.e. together they reflect a temporal physical context, the con f iguration is also a context, in that it is also temporal and affects system behaviour. in this paper we consider the modelling and verification process for configurable, interactive, context-aware systems in general, and a case study of an event driven system. we begin with a general purpose model of functional behaviour and for this we propose that a (concurrent) process based specification language, temporal logics and reasoning by model checking is a good paradigm, especially when context changes are non-deterministic. in the case study here we develop a general purpose model in promela, for checking with the spin model checker [hol03]. we then refine the verification problem and develop a specialised model for checking redundacies, using a sat solver [es03]. a distinctive feature of this work is parts of the models are generated automatically from actual log files. in the next section we outline our overall vision for the modelling and verification process. the remainder of the paper is an exploration of one iteration of that process, for a case study. section 3 introduces the match case study and in section 4 we give an outline of our promela model. properties for verification are given in section 5, where we give an overview of checking for redundant rules in the promela model. in section 6 we give an outline of the sat model for redundancy checking and results of online verification. in section 7 we consider the more general problem of overlapping left and/or right hand sides of rules, and when these should be interpreted as undesirable. discussion follows in section 8 and an overview of related work follows. conclusions and future work are in section 10. 2 modelling and verification process traditionally, modelling is a manual process with the starting point of a system specification, or a set of requirements, or, when the system is operational, observations and data. one notable exception is [hs99], where the promela model is extracted mechanically from call processing software code: a control-flow skeleton is created using a simple parser, and this skeleton is then populated with all message-passing operations from the original code. our vision for the modelling and verification process is similar in that we aim to more tightly couple the model proc. fmis 2009 2 / 16 eceasst and the system, and indeed the results of the verification. crucial to the process is the notion of configuration and the extraction from the system of configuration details, often stored as log files. our vision is illustrated in figure 1, where ellipses denote agents and rectangles objects. the key feature of our vision is that modelling is tightly coupled with system development and configuration. this is not a waterfall model: activities are concurrent and moreover, while four agent roles are indicated, they may be overlapping or conflated. briefly, activities are as follows. the end users configure the system, and when configured, (possibly different) users interact with the system, as system and users require, according to the context. the configuration is not static, but may be changed repeatedly. log files are a representation of the configuration process and are generated by a live system. the formal model depends upon what kind of analysis is required (e.g. functional behaviour, security, performance, etc.) and it is also configured, according to the log files. the model is analysed; the verification results may inform understandings of the end user, the configurer, the designer, and the modeller, though in different ways. for example, the user develops a better cognitive model, the configurer understands how to improve his/her rules, the designer develops a better interface, and the modeller gains insight in to how to modify the model so that verification is more efficient. note, this is just an example. there may be multiple models and a single agent may have multiple roles as configurer/modeller/user/designer. verification may be performed off-line or on-line, each of which has its merits. on-line verification can inform users in real-time. on the other hand, off-line verification allows more general results e.g. for all configurations with a certain property, a system proprety holds. this kind of verification can then be used by the designer to constrain allowable interactions or configurations. finally, recall that agents may not be human at all, for example, the system might autonomously configure itself, or the modeller may be another software process. properties may support, for example, • end user configurations, e.g. what will happen if i add this rule? or how can i notify/detect x in the event of y? • modalities, e.g. are there multiple speech outputs? or are there multiple speech inputs only when there are multiple users? • hypotheses about resources, e.g. what happens if a webcam doesn’t work? in this paper we report on one iteration of the modelling and verification cycle, starting with log files extracted from actual system trials of a prototype system (deployed in the uk and in france). 3 match system activity awareness systems constitute an increasingly popular category of pervasive application [mrm09]. such systems allow groups of users to share information about their current status or recent activities. they have a variety of purposes, ranging from supporting collaborative work through informal social relationships. we have chosen to investigate our approach to verification using one such activity awareness system, the match activity monitor (hereafter, mam), an 3 / 16 volume 22 (2009) tightly coupled verification of pervasive systems figure 1: tightly coupled verification: configurable systems and configurable models figure 2: mam system architecture experimental platform designed to explore the challenges of the configuration of activity awareness use to support of home-care [mg09]. a mam system consists of one or more hubs (umpc-based subsystems supporting a rich set of inputs and message types) each of which is connected to a set of satellites (web-based clients offering a limited set of inputs and message types) and other hubs, illustrated via the architecture diagram in figure 2. typically, a hub will reside in the home of a person requiring care while the satellites are used by carers, clinicians, family and friends. each hub, placed in the home of a cared person, can communicate with a set of web-based clients and with other hubs. a mam hub supports a set of up to eight monitoring tasks, each of which involves the generation of messages based on user-generated or sensor-generated input indicating an event or activity. monitoring tasks are defined by rules that specify an event or activity to be reported plus the destination and form of the reporting message. for example, a rule might state that use of tony’s coffee cup (captured via an appropriate sensor1) should be reported to me (i.e., the hub in my home) via a speech message. currently, mam supports a variety of data sources, message destinations and message modalities (e.g., speech, graphics, 1 mam uses a jake sensor pack for simple movement sensing, while the jakes more powerful sibling, the shake, provides richer sensing capabilities and tactile feedback [jak, sha]. proc. fmis 2009 4 / 16 eceasst touch, etc.). a full list is given in figure 3. each mam hub can support up to eight monitoring tasks, each of which is specified explicitly as a monitoring rule2. in addition to simple rules, it is also possible to specify combinations of inputs (e.g., a button press or an appointment) or message modalities (e.g., speech and graphics). rules may also have a guard condition; currently mam only supports a location condition such that the message is sent if someone is sensed near a specified location. a user may also choose a system-generated recommendation of the input, destination or modality. the recommendation can be used in an automatic or semi-automatic mode. in the former case, the system will choose the input, destination or modality most commonly associated with the other parameters, based on a history of logged configurations. in the latter case, the system will offer a ranked list of choices, based again on frequency of association, from which the user must select one. a user interface is supplied for specifying monitoring task rules. if a user is not interacting with the mam hub, it operates a digital photo frame application that displays the user’s photos in order to make it a non-intrusive part of the user’s home. to configure the hub, a user touches the screen and the photo application fades away, replaced by the mam application, from which the configuration screen is accessible. figure 4 shows a typical rule configuration. note the eight tabs to the left, one for each rule; rule 1 is selected. the rule configuration view is divided into a left-hand panel for specifying input and a right-hand panel for destination and modality. in this case the blue and red buttons on my hub (left-hand panel) have been selected to create messages to be sent to lucy’s machine(s) (right-hand panel). the large vertical green button on the right of the panel is the on-off toggle switch for the rule; when green, the rule is active and when red the rule is inactive. even with the rather limited set of inputs, destinations and message types, the configuration space (i.e., number of different possible rules) is rather large (1.07e+301). in addition, not all configurations are desirable. it is possible to create redundant rules, which can be a problem given the restriction on the number of rules allowed. also, some configurations may cause difficulties for the user: two speech messages delivered at the same time will be impossible to understand. these configuration challenges provide a motivation for verification that can be used both to guide a designer (in exploring the design of the configuration options offered to a user) and to help an end user (in creating a set of rules that both meet their needs and are understandable and maintainable). 4 general model from a modelling perspective, the mam system is an event driven rule-based pervasive system. events include (but are not restricted to) direct user interaction with the hub, such as pushing buttons, and indirect user interaction such as movement captured by a webcam or external actions such as messages received from other users. rules dictate how the system will react to events. we note that from a modelling perspective, there is no distinction between a user interaction and 2 this limitation, amongst others, is intentional and based on empirical evidence, to limit the complexity of the application. 5 / 16 volume 22 (2009) tightly coupled verification of pervasive systems input sources calendar an online calendar scheduling system reports upcoming appointments accelerometer small custom-built bluetooth accelerometers can be placed around the home (e.g., on a phone, teacup, or door) or on a person, in order to detect movement-signalled activity of the instrumented thing/person. this is performed using jake and shake devices [wmh07]. webcam movement fixed and wireless webcams can be used to provide motion detection. events this allows for room occupancy to be detected and reported. user-generated text users can key in their current activity, mood or needs explicitly using an on-screen keyboard. abstract buttons a user may select an abstract button to which no particular meaning has been assigned in advance by the developers of the system (i.e. the red square). the user may negotiate with other people to assign a particular meaning to these buttons. this concept is derived from markerclock [rm07] that uses a similar abstract marker feature. message destinations local hub messages are directed to one of the output devices associated with the local machine. registered users messages are directed to specified users; the message will be sent to their hub, if they have one, or to their registered web-based client(s). modalities graphical notice of an activity is briefly overlaid on top of the hub photoframe; an icon indicates that there is an unread message waiting. additionally, the message will be added to a scrollable list of messages that is permanently available. speech the content of the message is rendered into voicexml and played through any of the devices speakers. non-speech audio a selection of auditory alerts is provided, such as nature sounds as well as more familiar alert noises. each set of sounds contains multiple .wav files, each of which is mapped to a particular type of alert. as with speech, this can be directed to any distinct speaker. tactile the shake device (but not the jake) is equipped with an inbuilt vibrotactile actuator that can be activated. vibration profiles (i.e. vibrate fast-slow-fast. slow-fast-slow) can be used to distinguish between different types of activity. email activity messages can be delivered to one or more email addresses that the user can specify. figure 3: mam activity monitoring task parameters proc. fmis 2009 6 / 16 eceasst figure 4: sample task configuration screen change of context. while there is intent associated with the former, from a modelling point of view both are simply aspects of state that may be captured by propositions (whose validity may be temporal). promela [hol03] is a high-level, state-based, language for modelling communicating, concurrent processes. it is an imperative, c-like language with additional constructs for non-determinism, asynchronous and rendezvous (synchronizing) communication, dynamic process creation, and mobile connections, i.e. communication channels can be passed along other communication channels. the language is very expressive, and has intuitive kripke structure semantics. our model is centred around a single hub that can take input from one or more satellites or additional hubs. as a result we have a single rule set, which in this case is static. however, it would be a simple matter to extend the model to include multiple hubs and rule sets and dynamic rule sets. as we are considering a configurable system, the model is designed to reflect this. the system behaviour is separated from the system configuration. system behaviour refers to the actions of the available input and output devices. system configuration refers to the current active rule set. 4.1 system each input device is represented by a global variable and a process. for example, a button press is represented by a single bit variable and a process that can arbitrarily assign the values 0 or 1. movement sensors such as a jake, shake or webcam, are represented as an integer variable. the movement process will arbitrarily assign a values 0-3, where 0 represents no movement and 1,2 and 3 represent low, medium and high levels of movement respectively. text based inputs, such as messages from other hubs, are represented as an mtype variable. the associated process will arbitrarily assign values representing one of the users in the system or a null value. these 7 / 16 volume 22 (2009) tightly coupled verification of pervasive systems processes act as sources of events for the system. output devices act as sinks within the system. in the model they are represented as global variables or channels, upon which messages are placed. the associated process for an output device is called when a value is assigned to the variable/posted in the channel. the process then resets the variable or reads the message off the channel. in future versions of the model it may be useful to include users and/or multiple hubs and rule sets in the system. in this case, the input variables will be directly modified by output processes from other hubs and/or as a direct result of a user action. 4.2 rules rules are taken directly from a mam system via the log. an excerpt from a log file can be seen in figure 5, included as an illustration of the content of a log file (and not to be read in detail!). uk.org.match_proj.osgi.evalfunc.manualeachcomponentinputselectionevaluationfunction(selected=["personal messages"]){} uk.org.match_proj.osgi.evalfunc.unionoutputapprovalevaluationfunction() {uk.org.match_proj.osgi.evalfunc.manualeachcomponentoutputselectionevaluationfunction(selected=["gui","twitter"]) {}uk.org.match_proj.osgi.evalfunc.manualeachpersonselectionevaluationfunction(selected=["doms","lionel","anne"]){}} uk.org.match_proj.osgi.evalfunc.manualgroupedpersonselectionevaluationfunction(selected=["everyone"]){} uk.org.match_proj.osgi.evalfunc.manualeachcomponentoutputselectionevaluationfunction(selected=["gui"]){} uk.org.match_proj.osgi.evalfunc.manualeachpersonselectionevaluationfunction(selected=["caroline","lionel","anne"]){} uk.org.match_proj.osgi.evalfunc.manualeachcomponentoutputselectionevaluationfunction(selected=["speech"]){} uk.org.match_proj.osgi.evalfunc.manualeachcomponentinputselectionevaluationfunction(selected=["jake movement"]){} uk.org.match_proj.osgi.evalfunc.unionoutputapprovalevaluationfunction() {uk.org.match_proj.osgi.evalfunc.manualeachpersonselectionevaluationfunction(selected=["caroline","lionel","anne"]) {}uk.org.match_proj.osgi.evalfunc.manualeachcomponentoutputselectionevaluationfunction(selected=["gui","twitter"]){}} uk.org.match_proj.osgi.evalfunc.manualeachcomponentinputselectionevaluationfunction(selected=["work messages"]){} uk.org.match_proj.osgi.evalfunc.manualeachpersonselectionevaluationfunction(selected=["caroline","anne"]){} figure 5: excerpt from a mam log file. in the mam system, rules are defined as evaluation functions that return input or output devices. each rule consists of an input and an output evaluation function. the combination of function name and the list of parameters determine how they are to act. both input and output functions can be composed. the input composition operator acts as a disjunction, meaning that an event will be triggered if either evaluation function is true. however, the output composition function acts as a conjunction, meaning that if the union output function is triggered then the result of both evaluation functions will be used. the evaluation function rule set is then expressed as an informal natural language rule set. an example is shown in figure 6. while this step is not strictly necessary, it can be helpful to have the rules expressed in a more readable format. the rules are then expressed as promela statements. each rule is expressed as a conditional statement, consisting of a guard and a compound statement. therefore, in promela we represent a rule as a single statement c → a, where c is a guard statement made up of a disjunction of statements representing the condition of the rule and a is compound statement consisting of a sequence of statements representing the action. for example, the rule “when the red console button is pressed play the doorbell earcon3 on the hub speaker” maps to the promela statement “(this.red > 0) → this.speaker!earcon doorbell”. rules can also be context sensitive. for example, “if the red button is pressed then, if the webcam has recently detected movement inform 3 an earcon is a short meaningful audio segment. proc. fmis 2009 8 / 16 eceasst if the red or blue buttons are pressed then play the rocket earcon if my webcam detects movement then display a pop-up message on my screen and display a message on the screen list if i receive a message from bill or then inform me using synthesised speech bill presses his red button if i receive a message from bill then send a vibration message via the shake if the red button is pressed then send a message to bill and inform me using synthesised speech if the shake senses movement then send a vibration message via the shake if bill presses his red button then inform me using synthesised speech if the yellow button is pressed then send a vibration message via the shake figure 6: example rule set. me with synthesised speech else send me an e-mail”. in this case the definition of “recently” is a system parameter. an example of a promela representation of a rule set can be seen in figure 7. in this example there are 2 hubs, one that belongs to the user and one that belongs to bill. in the rule set the user’s hub is referred to as this and bill’s hub is billh. this is because in the model a hub is represented by a bespoke variable type. proctype rules() { do :: (this.red == 1) || (this.blue == 1) -> this.audio_out!ec_rocket; :: (this.webcam > 2) -> this.screen_popup = me; this.screen_list = me; :: (this.text_in == bill || billh.red == 1) -> this.audio_out!speech; :: (this.text_in == bill) -> this.shake_out = 1; :: (this.red > 0) -> billh.text_in = me; this.audio_out!speech; :: (this.shake_in_m > 1) -> this.shake_out = 1; :: (billh.red > 0) -> this.audio_out = speech; :: (this.yellow > 0) -> this.shake_out = 1; od } figure 7: promela representation of example rule set. 5 properties we now explore a number of issues in the mam system that may benefit from formal verification. 5.1 redundant rule detection as the rules may be added by non-expert users, some may have overlapping or repeated definitions. it would be advantageous if the system could detect such redundant rules to be able 9 / 16 volume 22 (2009) tightly coupled verification of pervasive systems to streamline the system. this could provide feedback to the user and/or allow the system to remove redundant rules from the active rule set. 5.2 modalities the input and output devices can be classified by their modalities. for example, earcons and speech are sound, screen pop-ups and text messages are visual and vibration alerts are tactile. the acceptability of a system for a user may depend on the correct use of the different modalities. for example, multiple simultaneous audio outputs may confuse a user and result in the loss of messages. visual output devices should be avoided for severely visually impaired users, however, it may still be appropriate to use them to notify carers. overuse of tactile devices may result in the user being unable to differentiate between different types of messages. 5.3 priorities currently mam does not hold information on the relative priorities of rules/messages. however, a user is likely to be more concerned with certain messages than others. it would therefore be useful to check that the output from a given rule has a greater chance of being received by the appropriate target. for example, high priority messages should be distinct from lower priority messages. if a high priority message uses an earcon, then no other message should use a similar sounding earcon. 5.4 verification results we now expand on the redundant rule detection problem using the model checker spin, which verifies (or not) properties expressed in the logic ltl (linear temporal logic). an ltl property can be derived easily from the promela representation of a rule. in the general form, for a rule r of form c → a, where c is a guard and a is a sequence of statements, the associated property is informally described by: the action will always eventually occur after the condition becomes true (recall, conditions are disjunctions and actions are conjunctions. more formally, we define the mapping as f (r) = �( f (c) → ♦ f (a)), where f () maps guards and assignments to propositions in the obvious way. for example, the rule (this.yellow > 0)−> this.shake out = 1 would map to the ltl property �((this.yellow > 0) → ♦(this.shake out = 1)). we define f (r) as the property that the action associated with rule r will always eventually occur after the condition of r becomes true. a rule r in the rule set r is redundant if for model m (r|r), which represents r without r, f (r) |= m (r|r). a rule set r contains no redundant rules if ∀r f (r) 6|= m (r|r). redundancy checking was implemented with a realistic rule set (shown in figure 8) taken from an actual log file from the mam system. each rule was tested in-turn for redundancy. rule r7 was found to be redundant. verification times varied from around 12 minutes to 34 minutes. the search depth was between 4 and 6 million, and the number of states explored was between 65 and 100 million. clearly if this is to be used for real-time verification then significant improvements need to be made in the model efficiency and/or the verification techniques employed. however, proc. fmis 2009 10 / 16 eceasst these results do serve as a proof of concept. r1 ((this.red == 1)||(this.blue == 1) → this.audio out = ec rocket ||(this.yellow == 1)) r2 (this.webcam > 2) → this.screen popup = me; this.screen list = me r3 (this.text in == bill)||(billh.red == 1) → this.audio out = speech; ||(billh.blue == 1)||(billh.yellow == 1) this.screen list = me r4 (this.text in == bill) → this.shake out = 1 r5 (this.red > 0) → billh.text in = me r6 (this.shake in m > 1) → this.shake out = 1 r7 (billh.red > 0) → this.audio out = speech r8 (this.yellow > 0) → this.shake out = 1 figure 8: rule set used in experiments. 6 specialised model from section 5.4 it can be seen that our current general promela model of the mam system is not sufficiently efficient to detect redundancy fast enough to provide feedback to a system configurer in real-time. in this section we show how redundancy can be modelled and solved efficiently with a specialised sat solver [es03]. sat solvers check satisfiability of propositional formulae (usually written in disjunctive normal form). though in general np-complete, sat solvers are highly efficient for many practical applications. the sat model developed here uses literals to represent input devices, output devices and the rules. 6.1 literals inputs and outputs each simple input type is represented by a single literal. for example, a literal represents a button press or receiving a message from someone. similarly, simple output types are also represented as literals. more complex input functions such as movement, which has low, medium and high inputs, can be represented as one literal per input value. a clause then needs to be added to ensure the input values are consistent. for example, if the literal for a movement level high is true, then both medium and low should also be true. to ensure this, the clauses low∨¬medium and medium∨¬high are added, which will need to be done for each movement detection device. however, if only one rule takes input from a movement detection device, then the input can be treated as a simple input device and the clause can be omitted. classes of output, such as the mam auditory icon class “nature”, which consists of the auditory icons {wave, forest, wind}, can be modelled in one of two ways. if none of the individual auditory icons from this group are used as output for other rules, then the group can be represented as a single literal. otherwise, each of the class members will be represented as a single literal and there is an additional literal for the class. for example, the class “nature” will be represented by wave∨ f orest ∨wind ∨¬nature 11 / 16 volume 22 (2009) tightly coupled verification of pervasive systems 1. ∀r ∈ r ∀c ∈ r ri ∨¬c 2. ∀r ∈ r 1 c1 ∨c2 ∨···∨cn ∨¬ri 3. ∀r ∈ r ∀a ∈ r ¬ri ∨a 4. ∀a ∈ r 1 r1 ∨r2 ∨···∨rn ∨¬ai figure 9: clauses required to represent a given rule set r 6.2 clauses rules each rule is represented by a literal ri and a set of clauses as described in figure 9. there are four types of clauses associated with a rule, as follows. the literal ri being assigned the value true indicates that rule i has been triggered. a clause ri ∨¬c is added for each condition c that triggers rule i. to ensure ri is not true if none of its conditions are met, the following clause is added c1∨c2∨···∨cn∨¬ri. if rule i is triggered then the appropriate outputs must be set to true, thus the clause ¬ri ∨a is added for each action a associated with rule i. finally, to ensure that actions are only taken if triggered by a rule, the clause r1 ∨r2 ∨···∨rn ∨¬ai is added, where r1 to rn are all the rules that can trigger action ai. 6.3 rule redundancy to use the above model to detect redundant rules, we need to solve the model once for each atomic condition in the rule, to check if atomic condition c from rule ri is redundant. we add a clause for each input literal, setting the literal related to c to true and all the rest to false. all literals that represent the actions from rule ri are set to true. all clauses related to the rule being checked are removed. if the resultant model is satisfiable then condition c from rule ri is redundant, if all conditions associated with rule ri are redundant, then ri is redundant. 6.4 implementation and complexity the above model was implemented and solved with the same rule set used in section 5.4. a java program was written to read the rules from a file in the mam evaluation function format and generate the sat model. the sat model was then solved using the open-source sat solver minisat [es03]. the problem had 23 literals and around 45 clauses4, each instance of the problem required less than a thousandth of a second to solve. all instances were solved with propagation alone, no search was required. this model was then used in conjunction with a java program, which reads a rule set directly from a mam system log file, generates the models and checks the rule set for redundancy. using the actual hardware that mam runs on, reading in and checking a rule set required approximately 5 seconds. the majority of this time was taken to read and parse the log file. each individual sat model required approximately 15 thousandths of a second to solve. it is clear that the specialised sat model offers improvement of 5−6 orders of magnitude for redundancy checking over the general promela model. 4 the number of clauses is dependant on the rule being checked. proc. fmis 2009 12 / 16 eceasst 7 overlapping rules we have defined a rule to be redundant if it can be removed from a system without affecting how the system operates. however, a rule may also be redundant if it serves no useful purpose. for example, a rule set may include the two rules “if i receive a message from bill then play a bird noise earcon” and “if i receive a message from bill then play a doorbell earcon”. at a system level these rules are different. however, they both play a sound when a message is received from bill. one could interpret this as a lack of confluence, i.e. we have overlapping left hand sides of rules and divergent right hand sides. rules can also overlap in more subtle ways (e.g. a form of superposition). for example, a rule set may include the two rules “if the red or yellow buttons are pressed play the doorbell earcon and send a text message to bill” and “if the red or blue buttons are pressed play the doorbell earcon and inform me using synthesised speech”. both rules cause the doorbell earcon to be played, when one condition is satisfied. while these are only simple examples, they raise the question of what exactly we should be looking for when detecting redundant rules and what is the underlying theory of modalities? moreover, to answer these question we need to know why we are interested in this problem. for example, is it a significant issue in practice? the answer to the latter appears to be positive. while conducting user evaluation studies, the developers of the mam system have found that many test subjects indicated they have trouble understanding complex rules and only want to define simple rules. this means there is significant scope for overlapping conditions and actions. therefore, it would be advantageous for the system to offer assistance. this could be in the form of a message informing the user that a rule they entered is redundant, or makes some other rule redundant, or is overlapping with another rule. alternately, the system may simply detect such rules and only partially implement them. in any case, further study is need to understand user intentions and their relation to modalities and context, and also how best to feedback information from any analysis. 8 discussion a distinctive feature of this work is we are trying to more tightly couple design with modelling, closing the loop between design, use, configuration, modelling and verification. further, we deal with systems as actually deployed, rather than an ideal yet to be implemented. a long term goal is to automate many of these processes and so in this case study, where possible, we have developed scripts to process inputs automatically e.g. log files. the general model is based around the central concept of event – the mam system is after all event-driven. it captures a wide range of functional, temporal behaviour. however, in the context of checking for redundancy within rules, complexity of the model became a concern, especially if we aim for real-time model-checking in a live mam. furthermore, it is not clear that given the form of rules in this application, analysis of the rules requires a temporal logic. to a great extent, in this application, one could argue that the state of a sensor encapsulates a set of computational paths (or at least what is required to know them) and so we do not need to study the paths themselves. so, a sat model is appropriate for this type of verification. furthermore, 13 / 16 volume 22 (2009) tightly coupled verification of pervasive systems the verification then became so efficient it could be applied directly within the mam, running in real time on the same computational hardware. while we have only investigated one of the properties we mentioned section 5, redundancy, how we detect and resolve redundancy depends also on our understanding of modalities, priorities, and more generally, context. for example, a user may not care about overlapping earcons unless one of them has been generated by a certain condition. for example, delivering messages via the television and the beeper simultaneously may be acceptable, unless one of the messages is considered significantly more urgent than the other, or has arisen because of an unsafe context. the area of semantics and ontologies for modalities/context requires further investigation. acceptability and usability of modalities may be regarded as an example of crossing the “semantic rubicon”5 [ka02]. a contribution of our formal modelling and analysis to mam design has been to expose this crossing. 9 related work much formal analysis of pervasive systems is focussed on techniques for requirements involving location and resources, within a waterfall framework. for example, [cd09] employs the ambient calculus for requirements and [ce07] employs a constraint-based modelling style and temporal logic properties. some work has been done on better integration of formal analysis techniques within the context of interactive system interfaces (e.g. [ch08]), but there is little work on more tightly coupled models and analysis. one exception is [rbcb08], where a model of salience and cognitive load is developed and a usability property is considered. the model is expressed in a higher order logic, and the property is expressed in ltl. while our paradigm is different, the authors recognise they are engaged in a cyclic process. in some cases, their verification revealed inconsistencies between experimental behaviour and the formal model, which led them to suggest refinements to the rules and also new studies of behaviour. finally, there is ongoing work to use policy conflict handling mechanisms embedded in telecommunications systems in homecare applications [wt08]. we believe our approach can provide a more generic framework for such a conflict management service. 10 conclusions and future work we have considered the problem of verifying context-aware, pervasive, interactive systems. these kinds of systems present numerous challenges for verification: context-changes may be difficult to model and predict and in addition, such systems often operate in situations that require practically unpredictable changes to the application functionality itself. we have outlined an approach to verification that makes explicit two different types of interaction: system configuration and system use. our long term goal is to more tightly couple reasoning about configurable systems by configuring models, and closing the loop between design, use, configuration, modelling and verification. in particular, we are concerned with feeding back results of verification to users, designers, configurers, and modellers. 5 the division between system and user for high level decision-making or physical-world semantics processing. proc. fmis 2009 14 / 16 eceasst this paper reports on preliminary results from an example concerning an activity monitor from the match homecare system. we have developed an event based general model in promela, formulated and checked a number of properties in the model checker spin. we have concentrated on supporting end user configuration by checking for rule redundancy. results from the general model led us to develop a specialised model for use with a sat solver, and using that model we were able to verify an example set (taken from an actual log file), on the actual mam, in real time. the case study illustrates a number of engineering and foundational challenges for our approach: we have not modelled an idealised system, but one that has been designed and engineered in the context of specific practices and personal conventions. this presents non-trivial challenges for any modelling process. the work is still preliminary, but our results demonstrate proof of concept. a distinctive feature of the work is we generate automatically parts of the model from actual log files. longer term, our plans for further future work include generating more parts of models automatically from log files, for a class of context aware systems, and incorporating aspects of stochastic behaviour, performance, and real-time in the model and properties. we also plan to further investigate semantic models of modalities and context and the best way to present and use verification results, expecially in the context of human and non-human agents. acknowledgements: this research is supported by the vps project (verifying interoperability in pervasive systems), funded by the engineering and science research council (epsrc) under grant number ep/f033206/1. we also acknowledge support from the match project, funded by the scottish funding council under grant hr04016. we also acknowledge the work of tony mcbryan, the designer and implementer of the mam system, who kindly provided the log files we used and offered technical assistance. bibliography [cd09] a. coronato, g. de pietro. formal specification of a safety critical pervasive application for a nuclear medicine department. international conference on advanced information networking and applications workshops, pp. 1043–1048, 2009. doi:10.1109.waina.2009.198 [ce07] a. cerone, n. elbegbayan. model-checking driven design of interactive systems. electron. notes theor. comput. sci. 183:3–20, 2007. doi:dx.doi.org/10.1016/j.entcs.2007.01.058 [ch97] j. campos, m. d. harrison. formally verifying interactive systems: a review. in design, specification and verification of interactive systems 97. pp. 109–124. springer, 1997. [ch08] j. c. campos, m. d. harrison. systematic analysis of control panel interfaces using formal tools. in xvth international workshop on the design, verification and 15 / 16 volume 22 (2009) http://dx.doi.org/10.1109.waina.2009.198 http://dx.doi.org/dx.doi.org/10.1016/j.entcs.2007.01.058 tightly coupled verification of pervasive systems specification of interactive systems (dsv-is 2008). lecture notes in computer science 5136, pp. 72–85. springer-verlag, july 2008. [crb07] p. curzon, r. rŭkėnas, a. blandford. an approach to formal verification of humancomputer interaction. formal aspects of computing, pp. 513–550, 2007. doi:10.10.1007/s00165-007-0035-6 [es03] n. eén, n. sörensson. an extensible sat-solver. in giunchiglia and tacchella (eds.), sat. volume 2919, pp. 502–518. springer, 2003. [hol03] g. j. holzmann. the spin model checker: primer and reference manual. addison wesley, boston, 2003. [hs99] g. holzmann, m. h. smith. software model checking extracting verification models from source code. in proc. forte/pstv ’99. pp. 481–497. kluwer, 1999. [jak] jake project. http://code.google.com/p/jake-drivers/ [ka02] t. kindberg, f. a. system software for ubiquituous computing. pervasive computing, pp. 70–81, 2002. [mg09] t. mcbryan, p. gray. user configuration of activity awareness. lecture notes in computer science 5518:748–751, 2009. doi:dx.doi.org/10.1007/978-3-642-02481-8 113 [mrm09] p. markopoulos, b. de ruyter, w. e. mackay. awareness systems: advances in theory, methology and design. springer, 2009. doi:10.1007/978-1-84882-477-5 [rbcb08] r. rŭkėnas, j. back, p. curzon, a. blandford. formal modelling of salience and cognitive load. entcs, pp. 57–75, 2008. doi:10.10.1016/j.entcs.2008.03.107 [rm07] y. riche, w. mackay. markerclock: a communicating augmented clock for the elderly. proc. interact 07. part ii, lecture notes in computer science 4663:408– 411, 2007. [sha] shake users group. http://www.dcs.gla.ac.uk/research/shake/ [wmh07] j. williamson, r. murray-smith, s. hughes. shoogle: excitatory multimodal interaction on mobile devices. proc. sigchi conference on human factors in computing systems 4663:121–124, 2007. doi:http://doi.acm.org/10.1145/1240624.1240642 [wt08] f. wang, k. turner. policy conflicts in home care systems. proc. 9th int. conf. on feature interactions in software and communications systems, pp. 54–65, 2008. proc. fmis 2009 16 / 16 http://dx.doi.org/10.10.1007/s00165-007-0035-6 http://code.google.com/p/jake-drivers/ http://dx.doi.org/dx.doi.org/10.1007/978-3-642-02481-8_113 http://dx.doi.org/10.1007/978-1-84882-477-5 http://dx.doi.org/10.10.1016/j.entcs.2008.03.107 http://www.dcs.gla.ac.uk/research/shake/ http://dx.doi.org/http://doi.acm.org/10.1145/1240624.1240642 introduction modelling and verification process match system general model system rules properties redundant rule detection modalities priorities verification results specialised model literals inputs and outputs clauses rules rule redundancy implementation and complexity overlapping rules discussion related work conclusions and future work formal specification of model transformations by triple graph grammars with application conditions electronic communications of the easst volume 39 (2011) graph computation models selected revised papers from the third international workshop on graph computation models (gcm 2010) formal specification of model transformations by triple graph grammars with application conditions ulrike golas, hartmut ehrig and frank hermann 26 pages guest editors: rachid echahed, annegret habel, mohamed mosbah managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst formal specification of model transformations by triple graph grammars with application conditions ulrike golas1, hartmut ehrig2 and frank hermann23 1 golas@zib.de, konrad-zuse-zentrum für informationstechnik berlin, germany 2 ehrig|frank@cs.tu-berlin.de, technische universität berlin, germany 3 frank.hermann@uni.lu, snt, université du luxembourg, luxembourg abstract: triple graph grammars are a successful approach to describe exogenous model transformations, i.e. transformations between models conforming to different meta-models. source and target models are related by some connection part, triple rules describe the simultaneous construction of these parts, and forward and backward rules can be derived modeling the forward and backward model transformations. as shown already for the specification of visual models by typed attributed graph transformation, the expressiveness of the approach can be enhanced significantly by using application conditions, which are known to be equivalent to first order logic on graphs. in this paper, we extend triple rules with a specific form of application conditions, which enhance the expressiveness of formal specifications for model transformations. we show how to extend results concerning information preservation, termination, correctness, and completeness of model transformations to the case with application conditions. we illustrate our approach and results with a model transformation from statecharts to petri nets. keywords: model transformation, triple graph grammar, application condition 1 introduction specification of models and model transformations play a central role in model-driven software development. for the specification of visual models and languages, it is common practice to use uml modeling techniques for the concrete syntax with underlying typed attributed graph transformation for the abstract syntax. the visual language can be defined in a declarative way by a meta-model with ocl-constraints or – on the abstract level – by a type graph and suitable graph constraints. alternatively, the visual language can be generated on the abstract level by typed attributed graph grammars [eept06]. it is well-known that the expressiveness of such generative approaches can be enhanced by using graph grammar rules with negative application conditions (nacs), or even more by using nested application conditions in the sense of [hp09], which are known to be equivalent to first order logic on graphs and more expressive than nacs. graph transformation is a suitable approach to define model transformations [teg+05]. especially for exogenous model transformations, triple graph grammars (tggs) [sch94] are a wellsuited formalism [sk08] and they were successfully applied in several domains [ks06, gl06a, gl06b]. formal properties concerning information preservation, termination, correctness, and 1 / 26 volume 39 (2011) mailto:golas@zib.de mailto:ehrig$|$frank@cs.tu-berlin.de mailto:frank.hermann@uni.lu triple graph grammars with application conditions completeness of model transformations have been studied already in [eeh08, eehp09] based on triple rules without nacs, where the decomposition and composition theorem for triple graph transformation sequences in [eee+07] plays a fundamental role. in [ehs09], this theorem has been extended to triple rules with nacs, but not yet to nested application conditions [hp09]. it is the main aim of this paper to extend the theory of model transformations based on tggs to rules with nested application conditions, short application conditions, in order to enhance the expressiveness of model transformations including the generation of the source and target languages by corresponding source and target rules. we show that the decomposition and composition theorem can be extended to rules with application conditions. this allows to enhance the expressiveness of model transformations and to extend termination, correctness, completeness, and backward information preservation to this more general framework. as a case study, we consider a model transformation from statecharts to petri nets, where we use a combination of positive and negative application conditions and boolean operators as available in the framework of general application conditions, but not in the more restrictive framework of nacs. in our example, only one level of nesting is sufficient to model the necessary conditions, but the theory is developed for more complex situations as introduced in [gol11]. this paper is organized as follows. in section 2, we review triple rules and application conditions. we illustrate our approach with a model transformation from statecharts to petri nets in section 3. this case study is used as illustrating example in section 4, where we define model transformations based on tggs with application conditions leading to termination, correctness, completeness, and backward information preservation. a conclusion including related and future work is presented in section 5. we assume the reader to be familiar with the basics of uml statecharts [omg09], petri nets [pet80], and graph transformation in the double pushout approach [eept06]. 2 review of triple graph grammars and application conditions triple graph grammars [sch94] are a well known approach for bidirectional model transformations. in [ks06], the basic concepts of triple graph grammars are formalized in a set-theoretical way, which is generalized and extended in [eee+07] to typed, attributed graphs. a triple graph g = (gs sg← gc tg→ gt ) consists of graphs gs, gc, and gt , called source, connection, and target component, and two graph morphisms sg and tg mapping the connection to the source and target components. a triple graph morphism f : g1 → g2 matches the single components and preserves the connection part. the typing of a triple graph is done in the same way as for standard graphs via a type graph t g in this case a triple type graph and a typing morphism typeg from the graph g into this type graph leading to the typed triple graph (g,typeg). a typed triple graph morphism f : (g1,typeg1)→ (g2,typeg2) is a triple graph morphism f such that typeg2 ◦ f = typeg1 . triple graphs and typed triple graphs, together with the component-wise compositions and identities, form the categories triplegraphs and triple-graphstg. when speaking of triple graphs, we consider both triple graphs and typed triple graphs, but do not explicitly mention the typing. moreover, we define the morphism class m of injective triple graph morphisms which is used throughout the paper. using this class m , both categories can be extended to weak gcm 2010 2 / 26 eceasst adhesive hlr categories [eept06] which allows us to instantiate the theory to transformations of triple graphs. the categorical foundations of weak adhesive hlr categories are not essential to understand this paper. l r g h ls lc lt gs gc gt rs rc rt hs hc ht tr f m n sl tl sg tg ms mc mt sr tr sh th ns nc nt trs trc trt fs fc ft (1) a triple rule tr = (l tr→ r) consists of triple graphs l and r, and an m -morphism tr : l → r. since triple rules are nondeleting, we do not need a span of morphisms for a rule. a direct triple transformation g = tr,m ==⇒ h of a triple graph g via a triple rule tr and a match m : l → g is given by the pushout (1), which is constructed as the component-wise pushouts in the s-, c-, and t -components, where the morphisms sh and th are induced by the pushout of the connection component. note, that due to the structure of the triple rules, double and single pushout approach are equivalent in this case. a triple graph transformation system t gs = (t r) is based on triple graphs with a set t r of rules over them. a triple graph grammar t gg = (t r,s) contains in addition a triple start graph s. for triple graph grammars, the generated language is defined by v l = {g | ∃ triple transformation s ∗⇒ g via rules in t r}. moreover, the source language v ls = {gs | (gs sg← gc tg→ gt )∈v l} contains all standard graphs that are the source component of a derived triple graph. similarly, the target language v lt ={gt | (gs sg← gc tg→ gt )∈v l} contains all derivable target components. trs = ls ∅ ∅ rs ∅ ∅ ∅ ∅ ∅ ∅ trs ∅ ∅ trt = ∅ ∅ lt ∅ ∅ rt ∅ ∅ ∅ ∅ ∅ ∅ trt trf = rs lc lt rs rc rt trs◦sl tl sr tr idrs trc trt trb = ls lc rt rs rc rt sl trt◦tl sr tr trs trc idrt from a triple rule, we can derive a source rule trs and a target rule trt , which specify the changes done by this rule in the source and target components, respectively. moreover, the forward rule trf and the backward rule trb describe the changes done by the rule to the connection and target resp. source parts, assuming that the source resp. target rules have been applied already. intuitively, the source rule creates a source model, which can then be transformed by the forward rules into the corresponding target model. this means that the forward rules define the actual model transformation from source to target models. vice versa, the target rules create the target model, which can then be transformed into a source model applying the backward rules. thus, the backward rules define the backward model transformation from target to source models. an important extension is the use of rules with suitable application conditions as done in the next sections. simple variants are positive application conditions of the form ∃a for a morphism a : l → c, demanding a certain structure in addition to l, and negative application conditions ¬∃a, forbidding such a structure. a match m : l → g satisfies ∃a (¬∃a) if there is a (no) m morphism q : c → g satisfying q◦a = m. in more detail, we use nested application conditions [hp09], short application conditions, which are defined recursively. the application condition 3 / 26 volume 39 (2011) triple graph grammars with application conditions l c g acc a m q true is always satisfied. a more complex application condition ∃(a,acc) on l consists of a morphism a : l →c and an application condition acc on c. for satisfaction, in addition to the existence of q it is required that q satisfies acc. moreover, application conditions are closed under boolean operations. we use ∃a as a short notion for ∃(a,true) and false for ¬true. in general, we write m |=∃(a,acc) if m satisfies ∃(a,acc), and acc ∼= ac′c denotes the semantical equivalence of acc and ac′c on c. in the diagrams, an application condition acc on c is depicted by a triangle pointing towards c. in order to handle rules with application conditions there are two important concepts, called the shift of application conditions over morphisms and morphism spans ([hp09, ehl10]): 1. given an application condition acl on l and a morphism t : l→l′ then there is an application condition shift(t,acl) on l′ such that for all m′ : l′→g holds: m′ |= shift(t,acl)⇐⇒ m = m′◦t |= acl. for acl = ∃(a,ac′l) we define shift(t,acl) = ∨(a′,t′)∈f∃(a ′,shift(t′,ac′l)) with f ={(a′,t′) | (a′,t′) jointly epimorphic,t′ ∈ m ,t′◦a = a′◦t}, l c l′ c′ acl shift(t,acl) ac′l shift(t′,ac′l) l r y x acr ac′rl(tr ∗,ac′r) l(tr,acr) tr tr∗ b a(1) a t t′ a′ 2. given a triple rule tr = (l tr→ r) and an application condition acr on r then there is an application condition l(tr,acr) on l such that for all transformations g = tr,m ==⇒ h with comatch n holds: m |= l(tr,acr)⇐⇒ n |= acr. for acr = ∃(a,ac′r) we define l(tr,acr) = ∃(b,l(tr ∗,ac′r)) if a◦tr has a pushout complement (1) leading to tr∗, and l(tr,∃(a,ac′r)) = false otherwise. r1l1 l2 r2 el r ac1 ac2 ac tr1 tr∗1 e1 u1 tr2 e2 one of the main results for graph transformation needed in this paper is the concurrency theorem, which is concerned with the execution of transformations which may be sequentially dependent. given an arbitrary sequence g = tr1,m1 ===⇒ h = tr2,m2 ===⇒ g′ of direct transformations it is possible to construct an econcurrent rule tr1 ∗e tr2 = (l → r,ac). the object e is a jointly surjective overlap of r1 and l2. the construction of the concurrent application condition ac = shift(u1,ac1)∧l(p∗,shift(e2,ac2)) and p∗ = (l s1←c1 t1→ e) is again based on the two shift constructions. the concurrency theorem states that for the transformation g = tr1,m1 ===⇒ h = tr2,m2 ===⇒ g′ the e-concurrent rule tr1 ∗e tr2 allows us to construct a direct transformation g = tr1∗e tr2 ====⇒ g′ via tr1 ∗e tr2, and vice versa, each direct transformation tr1 ∗e tr2 can be sequentialized. gcm 2010 4 / 26 eceasst 3 model transformation from statecharts to petri nets in this section, we define a model transformation from a variant of uml statecharts [omg09] to petri nets [pet80] using triple rules and application conditions. statecharts may have orthogonal regions as well as state nesting. as a small restriction, we do not handle entry and exit actions, do not allow extended state variables, allow guards only to be conditions over active states, and allow only a depth of two for hierarchies of states. for the target language of petri nets, we use nets with inhibitor arcs, contextual arcs, and open places. a transition with an inhibitor arc from a place (denoted by a filled dot instead of an arrow head) is only enabled if there is no token on this place. a contextual arc between a place and a transition (denoted by an edge without arrow heads), also known as read arc in the literature, means that this token is required for firing, but remains on the place. open places allow the interaction with the environment, i.e. token may appear or disappear without firing a transition within the net. we assume all places to be open. with these restrictions for statecharts and extensions for petri nets we are able to define a model transformation from statecharts to petri nets which preserves the semantical behavior, at least on an informal level. error call repair prod produced prepare empty full wait consumed arrive finish repair finish exit next produce [empty] /incbuff fail incbuff decbuff next consume [full] /decbuff figure 1: the example statechart in concrete syntax in figure 1, the statechart prodcons is depicted modeling a producerconsumer system. the whole state machine contains one region with the states prod, error, and a final state. when initialized, the system is in the state prod, which has three regions. there, in parallel a producer, a buffer, and a consumer may act. the producer alternates between the states produced and prepare, where the transition produce models the actual production activity. it is guarded by a condition that the parallel state empty is also current, meaning that the buffer is empty and may actually receive a product, which is then modeled by the action incbuff denoted after the /-dash. similarly to the producer, the buffer alternates between the states empty and full, and the consumer between wait and consumed. the transition consume is again guarded by the state full and followed by a decbuff-action emptying the buffer. two possible events may happen causing a state transition leaving the state prod: the consumer may decide to finish the complete run or there may be a failure detected after the production leading to the error-state. then, the machine has to be repaired before the error-state can be exited via the corresponding exit-transition and the standard behavior in the prod-state is executed again. for the modeling, we use typed attributed graphs, which are an extension of typed graphs by attributes [eept06]. we do not give details here, but use an intuitive approach to attribution, where the attributes of a node are given in a class diagram-like style. for the values of attributes in the rules we can also use variables. note, that for the typing of the edges we omit the edge types if they are clear from the node types they are connecting. 5 / 26 volume 39 (2011) triple graph grammars with application conditions sm name:string r e name:string t s name:string isinitial:bool isfinal:bool a name:string g r-t3 e-p t-t s-p s-pe s-t1 s-t2 place transition pre inhibitor contextualpost region regions states trigger action guard begin end condition st g tt g figure 2: the triple type graph t g in figure 2, the triple type graph t g is depicted, containing in the left the source component of statecharts in abstract syntax, in the right the target component of petri nets, and the connection component inbetween. to obtain valid statechart models, some constraints are needed which are described in the following but are not shown explicitly. each diagram consists of exactly one state machine sm containing one or more regions r. a region contains states s, where state names are unique within one region. a state may again contain one or more regions. each region is contained in either exactly one state or the state machine. moreover, states may be initial (attribute value isinitial = true) or final (attribute value isfinal=true), each region has to contain exactly one initial and at most one final state, and final states cannot contain regions. a transition t begins and ends at a state, is triggered by an event e, and may be restricted by a guard g and followed by an action a. a guard has one or more states as conditions. there is a special event with attribute value name="exit" which is reserved for exiting a state after the completion of all its orthogonal regions, which cannot have a guard condition. moreover, final states cannot be the beginning of a transition and their name attribute has to be set to name="final". in addition, transitions cannot link states in different orthogonal regions, which means that both regions are directly contained in the same state. the language v lsc consists of all typed attributed graphs respecting the source component t gs of the type graph t g and the constraints as described above. in the following, we present the triple rules that create simultaneously the statechart model, the connection part, and the corresponding petri net. for simplicity, we depict the petri nets in the target component in concrete syntax, while only writing node names in the connection component. 0 state0 state2 state1 1 2 t a state4 state3 3 4 ta a figure 3: the basic correspondences in general, each state of the statechart model is connected to a place in the petri net, where a token on it represents that this state is current. transitions between states are mapped to petri net transitions and fire when the corresponding state transition occurs. events are also connected to places, where all events with the same name share the same petri net place. they are connected via a contextual arc to their corresponding transition gcm 2010 6 / 26 eceasst thus enabling the simultaneous firing of all enabled petri net transitions when a token is placed there. by using contextual arcs it is possible that all transitions connected to an event with this name are enabled simultaneously if also their other pre-places are marked. otherwise, we would not be able to fire all these transitions concurrently. they would not be independent but compete for the token. for independence, we had to know in advance how many of these transitions will fire to allocate that number of tokens on the event’s place. for a guard, the petri net transition of its transition in the statechart diagram is the target of a contextual arc from the place connected to the condition. thus, we check also in the petri net that this guard condition is fulfilled, i.e. the corresponding place holds a token, before firing the transition. such a basic situation is depicted in figure 3, where altogether five states and their corresponding places, two transitions – both in the statechart and the petri net – and an event a with its corresponding place are shown. the hierarchy of the statechart is flattened, since petri nets do not have such a concept. note that all place are open places. 0 state0 state2 state1 1 2 t a state4 state3 3 4 t t2 t2 t2 t2 t3 t3 a a 0 state0 state1 1 f t a state3 3 f t t1 a a figure 4: the additional correspondences additional places and transitions make sure that the effects of a state transition concerning involved subor superstates can be simulated also in the petri net part. each substate is connected via s-t2 to a t2transition which is the target of a pre-arc from its superstate. this makes sure that, when a state transition leaves this superstate, also all substates are no longer current. each region within a state is connected via r-t3 to a t3transition which makes sure that, when no state inside this region is current, also the superstate is deactivated. these two situations are depicted in the example models in the top of figure 4. each state that may contain regions is connected via s-t1 to a t1-transition that is the target of pre-arcs from all places of final states and inhibitor arcs from all other places in its regions, while the superstate’s place is a contextual place as shown in the state0 0 state1 1 2 t af e e exit tt1 t1 t2 t2 t3 state3 a exit figure 5: the handling of exit-events bottom of figure 4. this makes sure that, when all substates are final, these substates are no longer current and, if it exists, the exitaction of the superstate can be initiated. for the handling of the special "exit"-events, each state which may be a superstate is connected via s-pe to an e-place which handles the proper execution of this event regarding t17 / 26 volume 39 (2011) triple graph grammars with application conditions and t3-transitions. the idea behind this place is, that when all final states are reached and an exit transition has to be invoked, the t1-transition delivers a token to the e-place which than triggers the execution of the transition in the petri net as shown in figure 5. for the operational semantics, all places in the petri net corresponding to currently active states will be marked. depending on the semantical steps in the statechart, the open places in the petri net produce and delete tokens. for example, triggering an external event in the statechart leads to a token on the events’s place in the petri net. also for the handling of the hierarchical (de)activation the proper open places may fire triggered by the corresponding semantical rules for the statecharts. for example, when entering a state it’s initial substates become active. this has to be handled in the petri net by firing the corresponding open places. thus, the petri net for itself shows different semantical behavior than the statechart, since arbitrary firing of open places leads to strange behavior, but every semantical step in the statechart can be simulated by the petri net. the rules for the operational semantics of statecharts are given in [gbee11]. start l0,s ∅ l0,c ∅ l0,t ∅ ∅ r0,s r0,c r0,t ∅ sm name="sm" ac0 =¬∃p0 l0 ∅ ∅ sm name="sm" tr0,s tr0,c tr0,t tl0sl0 tr0sr0 p0 figure 6: the rule start the start graph is the empty graph, and the first rule to be applied is the triple rule start shown in figure 6 which creates the start graph of statecharts in the source component, and empty connection and target components. the application condition ac0 is a so-called negative application condition (nac) and forbids that the right hand side of the rule already exists before the rule is applied. since a statemachine has exactly one node sm, the nac ensures that the rule cannot be applied twice. in figure 7, the triple rules newregionsm and newregions are depicted which allow to create a new region of a state machine or of a state, respectively. since each region has to have an initial state, this initial state is also created and connected to its corresponding place via s-p. with newregionsm, the initial state is also connected to a t1-transition in the target component and another place via s-pe. moreover, if the new region is created inside a state by newregions the substate is the inhibitor of the superstate’s t1-transition, the superstate inhibits a new t2-transition and the region and the substate inhibit a new t3-transition. for the triple rule newregions, the application condition forbids that the superstate is final or already a substate of another state. newregionsm has the application condition true which is not depicted. note that we allow parameters for the rules to define the attributes. thus, the user has to declare the name of the newly created state when applying these triple rules. in figs. 8 and 9, the triple rules for creating new states are shown. with newstatesm and newstates, new states inside a region of the state machine or of a state are created, which are not final states. similarly, final states are created by the triple rules newfinalstatesm and newfinalstates. in all cases, a corresponding place is created in the target component. as in the case of a new region, if creating a state as a substate of another state, there is a new t2transition with this superstate as inhibitor and the new place inhibits the region’s t3-transition. in case of a non-final substate, this substate inhibits the t1-transition of the superstate, whereas a final state within a state has to be connected to this superstate’s t1-transition as a pre place. the application conditions of these rules make sure that the new state name is unique within its region and that, for final states, only one final state per region is allowed. gcm 2010 8 / 26 eceasst newregionsm(sname:string) l1,s l1,c l1,t 1:sm ∅ ∅ r1,s r1,c r1,t 1:sm r s name=sname isinitial=true isfinal=false e t1 s-p s-pe s-t1 newregions(sname:string) l2,s l2,c l2,t 1:s s-p s-pe s-t1 e t1 r2,s r2,c r2,t 1:s r s name=sname isinitial=true isfinal=false e t2 t3 t1 s-p s-pe s-p r-t3 s-t2 s-t1 ac2 =¬∃p2 ∧¬∃q2 l2 1:s isfinal=true s-p s-pe s-t1 l2 s r 1:s s-p s-pe s-t1 p2 q2 sl1 tl1 sr1 tr1 tr1,s tr1,c tr1,t sl2 tl2 sr2 tr2 tr2,s tr2,c tr2,t figure 7: the triple rules newregionsm and newregions for the creation of a new transition, the triple rules newtransitionnewevent, newtransitionnewexit, newtransitionoldevent, and newtransitionoldexit in figure 10 and figure 11 are used. a new transition in the source part connected with a new petri net transition in the target part is created, and in case of a new event, this event is connected with a new place which is a contextual place for the transition. otherwise, the transition is connected with the place of the already existing event. in case of an exit-event, the place connected via s-pe to the begin-state has to be connected to the new transition and the begin-state’s t1-transition. the application conditions forbid that the begin-state is a final state and that states over different regions are connected by a transition (r7,s7,t7,u7), and ensure 9 / 26 volume 39 (2011) triple graph grammars with application conditions newstatesm(sname:string) l3,s l3,c l3,t 1:sm 2:r ∅ ∅ r3,s r3,c r3,t 1:sm 2:r s name=sname isinitial=false isfinal=false t1 s-p s-t1 es-pe ac3 =¬∃p3 l3 1:sm 2:r s name=sname ∅ ∅ newstates(sname:string) l4,s l4,c l4,t 1:s 2:r s-p r-t3 s-t1 t1 t3 r4,s r4,c r4,t 1:s 2:r s name=sname isinitial=false isfinal=false t2 t3 t1 s-t1 s-p s-p s-t2 r-t3 ac4 =¬∃p4 l4 1:s 2:r s name=sname s-p r-t3 s-t1 p3 p4 sl3 tl3 sr3 tr3 tr3,s tr3,c tr3,t sl4 tl4 sr4 tr4 tr4,s tr4,c tr4,t figure 8: the triple rules newstatesm and newstates that exit-events only begin at superstates, i.e. a state containing a region. note that the objects and morphisms used for the application conditions ac8, ac9, and ac10 are not shown explicitly, but they correspond to the objects and morphisms used in ac7. in figure 12, the triple rules newguard and nextguard are shown which create the guard conditions of a transition. the guard condition is a state whose corresponding place is connected via a contextual arc to the corresponding net transition. the application conditions ensure that only one guard per transition is allowed and that a transition with exit-event is not guarded at all. with the rule newaction in figure 12, an action is added to a transition in the statechart model if none is specified yet. gcm 2010 10 / 26 eceasst newfinalstatesm l5,s l5,c l5,t 1:sm 2:r ∅ ∅ r5,s r5,c r5,t 1:sm 2:r s name="final" isinitial=false isfinal=true s-p ac5 =¬∃p5 l5 1:sm 2:r s isfinal=true ∅ ∅ newfinalstates l6,s l6,c l6,t 1:s 2:r s-t1 s-p r-t3 t1 t3 r6,s r6,c r6,t 1:s 2:r s name="final" isinitial=false isfinal=true t1 t2 t3 s-t1 s-p s-p r-t3 s-t2 ac6 =¬∃p6 l6 1:s 2:r s isfinal=true s-t1 s-p r-t3 p5 p6 sl5 tl5 sr5 tr5 tr5,s tr5,c tr5,t sl6 tl6 sr6 tr6 tr6,s tr6,c tr6,t figure 9: the triple rules newfinalstatesm and newfinalstates an integrated model containing the statechart example in figure 1 in its source component can be constructed by the application of the following triple rules: 1× start creating the state machine, 1× newregionsm creating the one region inside the state machine and the initial state prod, 1× newstatesm creating the state error, 4× newregions creating one region within error including the initial state call and the three regions within prod including the initial states produced, empty, and wait, 4× newstates creating the state repair within error and the states prepare, full, and consumed within prod, 11 / 26 volume 39 (2011) triple graph grammars with application conditions newtransitionnewevent(ename:string) l7,s l7,c l7,t 1:s 2:s s-p s-p r7,s r7,c r7,t 1:s 2:s t e name=ename t s-p s-p e-p t-t ac7 = ename 6= ”exit”∧¬∃p7 ∧¬∃q7 ∧(∃r7 ∨∃s7 ∨∃t7 ∨∃u7) l7 1:s 2:s e name=ename s-p s-p l7 2:s 1:s isfinal=true s-p s-p l7 r 1:s 2:s s-p s-p l7 rr r s s1:s 2:s s-p s-p l7 r s 2:s r 1:s s-p s-p l7 r 1:s s r2:s s-p s-p newtransitionnewexit l8,s l8,c l8,t 1:s 2:s s-pe s-t1 s-p s-p e t1 r8,s r8,c r8,t 1:s 2:s t e name="exit" t e t1 s-pe s-t1 s-p s-p e-p t-t ac8 =¬∃p8 ∧¬∃q8 ∧∃v8∧ (∃r8 ∨∃s8 ∨∃t8 ∨∃u8) l8 1:s 2:s r s-pe s-t1 s-p s-p e t1 begin end begin end sl7 tl7 sr7 tr7 tr7,s tr7,c tr7,t p7 q7 r7 s7 v8 t7 u7 sl8 tl8 sr8 tr8 tr8,s tr8,c tr8,t figure 10: newtransitionnewevent and newtransitionnewexit gcm 2010 12 / 26 eceasst newtransitionoldevent l9,s l9,c l9,t 1:s 2:s 3:e name=ename s-p s-p e-p r9,s r9,c r9,t 1:s 2:s t e name=ename 3:e name=ename t s-p s-p e-p e-p t-t ac9 = ename 6= ”exit”∧¬∃q9 ∧(∃r9 ∨∃s9 ∨∃t9 ∨∃u9) newtransitionoldexit l10,s l10,c l10,t 1:s 2:s 3:e name="exit" s-pe s-t1 s-p s-p e-p e t1 r10,s r10,c r10,t 1:s 2:s t e name="exit" 3:e name="exit" t e t1 s-pe s-t1 s-p s-p e-p e-p t-t ac10 =¬∃q10 ∧(∃r10 ∨∃s10 ∨∃t10 ∨∃u10)∧∃v10 sl9 tl9 sr9 tr9 tr9,s tr9,c tr9,t begin end sl10 tl10 sr10 tr10 tr10,s tr10,c tr10,t begin end figure 11: newtransitionoldevent and newtransitionoldexit 1× newfinalstatesm creating the final state of the state machine, 1× newfinalstates creating the final state within error, 9× newtransitionnewevent creating all transition except for the exit-transition between error and prod and the next-transition between consumed and wait, 1× newtransitionexit creating the exit-transition between error and prod, 2× newtransitionoldevent creating the next-transition between consumed and wait with the already known event next, 2× newguard creating the guards of the produceand consume-transitions, 2× newaction creating the actions of the produceand consume-transitions. in the target component we find the petri net depicted in figure 13 (without the initial marking), where we have labeled the places and transitions with the names of the corresponding statechart elements and correspondence node names to ease the recognition. 13 / 26 volume 39 (2011) triple graph grammars with application conditions newguard l11,s l11,c l11,t 1:s 2:t s-p t-t t r11,s r11,c r11,t 1:s 2:t g t s-p t-t ac11 =¬∃p11 ∧¬∃q11 ∧¬∃r11 l11 1:s 2:t s-p t-t l11 1:s 2:t g s-p t-t l11 1:s 2:t e name="exit" s-p t-t nextguard l12,s l12,c l12,t 1:s 2:t 3:g s-p t-t t r12,s r12,c r12,t 1:s 2:t 3:g t s-p t-t ac12 =¬∃p12 ∧¬∃q12 l12 1:s 2:t3:g s-p t-t l12 1:s 2:t3:g s-p t-t newaction(aname:string) l13,s l13,c l13,t 1:t t-t t r13,s r13,c r13,t 1:t a name=aname tt-t ac13 =¬∃p13 l13 1:ta t-t sl12 tl12 sr12 tr12 tr12,s tr12,c tr12,t q12 p12 sl11 tl11 sr11 tr11 tr11,s tr11,c tr11,t p11 q11 r11 sl13 tl13 sr13 tr13 tr13,s tr13,c tr13,t p13 figure 12: the triple rules newguard, nextguard, and newaction gcm 2010 14 / 26 eceasst produced prepare empty f ull wait consumed next produce incbu f f decbu f f consume prod f ail exit error call repair f inal arrive repair e error e prod f inish f inal t t t t t t t2 t2 t2 t2 t2 t2 t1 prod t t t1 error t2 t2 t2 t t t t t3 t3 t3 t3 figure 13: the petri net corresponding to the statechart in figure 1 error call repair prod produced prepare empty full wait consumed arrive finish repair finish exit next produce [empty] /incbuff fail incbuff decbuff next consume [full] /decbuff figure 14: the statechart after the initialization step we do not want to show the weak simulation relation between the statecharts semantics and the petri net completely (see [gol11]), but give some intuition how it works. first, the initialization takes place. for the statechart, this leads to the active states prod, produced, empty, and wait as shown in figure 14 with thicker lines, since the initial state and all its initial substates are invoked. in the petri nets, the corresponding open places create a token leading to the initial marking depicted in figure 13. for the first semantical step, an external trigger element next appears. the state transition de15 / 26 volume 39 (2011) triple graph grammars with application conditions activates the state produced and activates the state prepare. in the petri net, the next-place generates a token. now the t-transition with next and produced as pre-places is activated and fires. since no other transition is activated, deleting the next-token leads to the resulting petri net simulation step with tokens on the places prod, prepare, empty, and wait corresponding to the statechart’s current semantical state. the source rules including suitable derived application conditions represent a generating grammar for our statechart models. all models are typed over the type graph and respect the specified constraints. for the target rules, only a subset of petri nets can be generated, but all models obtained from transformations using the target rules are well-formed, because they are typed over the petri net type graph and we cannot generate double arcs. this is due to the fact that the rules either create only arcs from or to a new element or the multiple application is forbidden as for the rule newguard by the expression ¬∃p11 within the application condition ac11. 4 model transformations with application conditions as shown by the model transformation from statecharts to petri nets, rules with application conditions are more expressive and allow to restrict the application of the rules. thus, we enhance triple rules and combine a triple rule tr without application conditions with an application condition ac over l. then a triple transformation is applicable if the match m satisfies the application condition ac. from now on, a triple rule denotes a rule with application conditions, while the absence of application conditions is explicitly mentioned. first, we introduce triple rules which construct the source, connection, and target parts in one step. from these triple rules we derive later the operational source and forward rules for the model transformation. definition 1 (triple rule and transformation) a triple rule tr = (tr : l → r,ac) consists of triple graphs l and r, an m -morphism tr : l → r, and an application condition ac over l. a direct triple transformation g = tr,m ==⇒ h of a triple graph g via a triple rule tr and a match m : l → g with m |= ac is given by the direct triple transformation g = tr,m ==⇒ h via the corresponding triple rule without application conditions. example 1 examples for triple rules using application conditions have been shown in section 3. for the extension of the derived rules with application conditions, we need more specialized application conditions that can be assigned to the source and forward rules. definition 2 (special application conditions) given a triple rule tr : l → r, an application condition ac =∃(a,ac′) over l with a : l → p is an • s-application condition if ac, at are identities, i.e. pc = lc, pt = lt , and ac′ is an sapplication condition over p, and • s-extending application condition if as is an identity, i.e. ps = ls, and ac′ is an s-extending application condition over p. gcm 2010 16 / 26 eceasst (ls lc lt ) (ps pc = lc pt = lt ) ac ac′ s-application condition s-extending application condition (ls lc lt ) (ps = ls pc pt ) ac ac′ sl tl sp tp=tl as idlc idlt sl tl sp tp idls ac at moreover, true is an sand s-extending application condition, and if ac, aci are sor s-extending application conditions for some index set i so are ¬ac, ∧i∈i aci, and ∨i∈i aci. for the assignment of the application condition ac to the derived rules, the application condition has to be consistent to the source and forward rules, which means that we must be able to decompose ac into sand s-extending application conditions. definition 3 (s-consistent application condition) given a triple rule tr = (tr : l → r,ac), then ac is s-consistent if it can be decomposed into ac ∼= ac′s ∧ac ′ f such that ac ′ s is an s-application condition and ac′f is an s-extending application condition. checking s-consistency for arbitrary application conditions may be complex. thus, we generally assume that the designer of the triple rules specifies only conjunctions of s-application conditions and s-extending application conditions. from the application point of view, this still provides sufficient expressive power. in fact, the s-application conditions allow for the specification of first order logic (fol) expressions for the source component and the s-extending ones allow for fol-expressions on the target component. example 2 all triple rules in section 3 have s-consistent application conditions. for example, the application condition ac7 of the rule newtransitionnewevent in figure 10 is an sapplication condition, thus no decomposition is necessary. moreover, the application condition ac11 of the rule newguard in figure 12 can be decomposed into the s-application condition ¬∃q11 ∧¬∃r11 and the s-extending application condition ¬∃p11. for an s-consistent application condition, we obtain the application conditions of the source and forward rules from the sand s-extending parts of the application condition, respectively. definition 4 (derived rules with application conditions) given a triple rule tr = (tr : l→r,ac) with s-consistent ac ∼= ac′s ∧ac ′ f we translate ac ′ s to an application condition acs = tos(ac ′ s) on (ls ← ∅ → ∅) and ac′f to an application condition acf = tof(ac ′ f ) on (rs ← lc → lt ) using the constructions below. this leads to the source rule (trs,acs) and the forward rule (trf ,acf ). given an s-application condition ac′s and an s-extending application condition ac ′ f over l, we define tos(ac′s) and tof(ac ′ f ) by ls ∅ ∅ ps ∅ ∅ ls lc lt ps pc = lc pt = lt tos(ac′s) tos(ac′′s) ac′s ac′′s sl tl sp tp=tl idls as idlc idlt as idps rs lc lt rs pc pt ls lc lt ps = ls pc pt tof(ac′f ) tof(ac′′f ) ac′f ac′′f trs◦sl tl sl tl trs◦sp tp sp tp trs idlc idlt idls ac at idrs ac at trs idpc idpt 17 / 26 volume 39 (2011) triple graph grammars with application conditions newguards l11,s 1:s 2:t ∅ ∅ r11,s 1:s 2:t g ∅ ∅ ac11,s =¬∃q11,s ∧¬∃r11,s l11,s 1:s 2:t g ∅ ∅ l11,s 1:s 2:t e name="exit" ∅ ∅ ∅ ∅ ∅ ∅ tr11,s ∅ ∅ q11,s r11,s newguardf r11,s l11,c l11,t 1:s 2:t 3:g s-p t-t t r11,s r11,c r11,t 1:s 2:t 3:g t s-p t-t ac11,f =¬∃p11,f l11,f 1:s 2:t 3:g s-p t-t tr11,s ◦sl11 tl11 sr11 tr11 idr11,s tr11,c tr11,t p11,f figure 15: the source and forward rules of newguard • tos(true) = tof(true) = true, • tos(∃(a,ac′′s)) =∃((as,id∅,id∅),tos(ac ′′ s)), • tof(∃(a,ac′′f )) =∃((idrs ,ac,at ),tof(ac ′′ f )), and • recursively for composed application conditions. example 3 in figure 15, the source and forward rules newguards and newguardf of the rule newguard in figure 12 are shown. the s-application condition ¬∃p6 ∧¬∃r6 is translated to the source rule, where the source graphs of the original application conditions are kept, but the connection and target graphs are empty now. the s-extending application condition ¬∃q6 is translated to the forward rule, where the source graph is adapted to the new left-hand side. similar to the corresponding result for triple rules without application conditions, in case of s-consistency each triple rule is the e-concurrent rule of its source and forward rules. proposition 1 given a triple rule tr = (tr : l → r,ac) with s-consistent ac, then tr = trs∗e trf with e being the domain of the forward rule. proof idea. from [eee+07] we know that this holds for triple rules without application conditions. for the application conditions, this can be shown in two steps using the definition of the application conditions and the shift properties (see [gol11]). for the first step, we have to show that shift((idls ,∅lc ,∅lt ),acs)∼= ac ′ s. with acs = tos(ac ′ s) this is obviously true for ac′s = true. consider ac ′ s = ∃(a,ac ′′ s) with a : l → p and suppose shift((idps ,∅ls ,∅lc ),tos(ac ′′ s)) ∼= ac′′s . it follows that shift((idls ,∅lc ,∅lt ),tos(∃(a,ac ′′ s))) ∼= ∃(a,shift((idps ,∅ls ,∅lt ),tos(ac ′′ s)) ∼= ∃(a,ac′′s) = ac ′ s because the shift construction implies that only the trivial squares have to be considered for the index set. for the second step, we have to show that l(e2,shift(ide,acf )) ∼= ac′f with e2 = (trs,idlc , idlt ) : l → e. with acf = tof(ac ′ f ) this is obvious for ac ′ f = true. consider ac ′ f = ∃(a,ac ′′ f ) with l((ls ← pc → pt ) → (rs ← pc → pt ),shift(id,tof(ac′′f ))) ∼= ac ′′ f . then (ps = ls sp← gcm 2010 18 / 26 eceasst pc tp→ pt ) is the pushout complement constructed for the left-shift-construction and we have that l(e2,shift(ide,tof(∃(a,ac′′f )))) ∼= l(e2,∃((idrs ,ac,at ),tof(ac ′′ f ))) ∼= ∃((idls ,ac,at ), l(((ls ← pc → pt )→ (rs ← pc → pt )),tof(ac′′f ))∼=∃(a,ac ′′ f ) = ac ′ f . � now we want to analyze how a triple transformation can be decomposed into a transformation applying first the source rules followed by the forward rules. match consistency of the decomposed transformation means that the comatches of the source rules define the source part of the matches of the forward rules. this helps us to define suitable forward model transformations, which have to be source consistent to ensure a valid model. note, that triple transformation sequences always satisfy the application conditions of the corresponding rules. definition 5 (source and match consistency) given a sequence (tri)i=1,...,n of triple rules with s-consistent application conditions leading to corresponding sequences (tris)i=1,...,n and (trif )i=1,...,n of source and forward rules. a triple transformation sequence g00 = tr∗s =⇒ gn0 = tr∗f =⇒ gnn via first tr1s,...,trns and then tr1f ,...,trnf with matches mis and mif and comatches nis and nif , respectively, is match consistent if the source component of the match mif is uniquely defined by the comatch nis. a triple transformation gn0 = tr∗f =⇒ gnn is called source consistent if there is a match consistent sequence g00 = tr∗s =⇒ gn0 = tr∗f =⇒ gnn. we can split a transformation g0 = tr1 =⇒ g1 ⇒ ... = trn =⇒ gn into transformations g0 = tr1s =⇒ g′0 = tr1f ==⇒ g1 ⇒ ... = trns =⇒ g′n−1 = trnf ==⇒ gn. but to apply first the source and then the forward rules, these have to be independent in a certain sense. in the following theorem, we show that such a decomposition into a match consistent transformation can be found and, vice versa, each match consistent transformation can be composed to a transformation via the corresponding triple rules if the application conditions are s-consistent. this result is an extension of the corresponding result for triple transformations without application conditions [eee+07] and with negative application conditions [ehs09]. it is essential for concepts and results of model transformations with application conditions below. theorem 1 (decomposition and composition) for triple transformation sequences with sconsistent application conditions the following holds: 1. decomposition: for each triple transformation sequence g0 = tr1 =⇒ g1 ⇒ ... = trn =⇒ gn there is a corresponding match consistent triple transformation sequence g0 = g00 = tr1s =⇒ g10 ⇒ ... = trns =⇒ gn0 = tr1f ==⇒ gn1 ⇒ ... = trnf ==⇒ gnn = gn. 2. composition: for each match consistent triple transformation sequence g00 = tr1s =⇒ g10 ⇒ ... = trns =⇒ gn0 = tr1f ==⇒ gn1 ⇒ ... = trnf ==⇒ gnn there is a triple transformation sequence g00 = g0 = tr1 =⇒ g1 ⇒ ... = trn =⇒ gn = gnn. 3. bijective correspondence: composition and decomposition are inverse to each other. proof idea. this result has been shown in [eee+07] for triple rules without application conditions. we use the facts that tri = tris ∗ei trif , as shown in prop. 1, and that the transforma19 / 26 volume 39 (2011) triple graph grammars with application conditions tions via tris and tr jf are sequentially independent for i > j. this is shown in [eee+07] for rules without application conditions and can be extended to triple rules with application conditions as shown in the following. thus, the proof from [eee+07] can be done analogously for rules with application conditions. the main idea of the proof is that a triple transformation sequence g0 = tr1 =⇒ g1 ⇒ ... = trn =⇒ gn can be decomposed into a transformation sequence g0 = tr1s =⇒ g′1 = tr1f ==⇒ g1 ⇒ ... = trns =⇒ g′n = trnf ==⇒ gn. the sequential independence of tris and tr jf for i > j allows us to shift all source rules to the beginning and all forward rules to the end of the sequence leading to an equivalent transformation sequence g0 = g00 = tr1s =⇒ g10 ⇒ ... = trns =⇒ gn0 = tr1f ==⇒ gn1 ⇒ ... = trnf ==⇒ gnn = gn. it suffices to show that the transformations g10 = tr1f ,m1 ====⇒ g11 = tr2s,m2 ===⇒ g21 are sequentially independent. from the sequential independence without application conditions we obtain morphisms i : r1f → g11 with i = n1 and j : l2s → g10 with g1 ◦ j = m2. it remains to show the compatibility with the application conditions: • j |= ac2s: ac2s = tos(ac′2s), where ac ′ 2s is an s-application condition. for ac ′ 2s = true, also ac2s = true and therefore j |= ac2s. suppose ac′2s = ∃(a,ac ′′ 2s) leading to ac2s = ∃((as,id∅,id∅),tos(ac′′2s)). moreover, tr1f is a forward rule, i. e. it does not change the source component and g11,s = g10,s. l1f r1f g10 g11 l2s r2s g21 tr1f g1 m1 i=n1 j tr2s g2 m2 n2 ps ∅ ∅ l2,s ∅ ∅ g10,s g10,c g10,t g11,s = g10,s g11,c g11,t tos(ac′′2s) ac2s sg10 tg10 sg11 tg11 as js id g1,c g1,t ps we know that m2 = g1 ◦ j |= ac2s, which means that there exists p : p → g11 with p◦ a = g1 ◦ j, p |= tos(ac′′2s), and pc = ∅, pt = ∅. then there exists q : p → g10 with q = (ps,∅,∅), q◦a = (ps◦as,∅,∅) = j, and q |= tos(ac′′2s) because all objects occuring in tos(ac′′2s) have empty connection and target components. this means that j |= ac2s for this case, and can be shown recursively for composed ac2s. • g2 ◦n1 |= acr := r(tr1f ,ac1f ): ac1f = tof(ac′1f ), where ac ′ 1f is an s-extending application condition. for ac′1f = true also ac1f = true and acr = true, therefore g2 ◦n1 |= acr. now suppose ac′1f = ∃(a,ac ′′ 1f ) leading to ac1f = ∃((idr1,s ,ac,at ),tof(ac ′′ 1f )) and acr = ∃((idr1s ,bc,bt ),ac ′ r) by component-wise pushout construction for the right-shift with ac′r = r(u,tof(ac ′′ 1f )). moreover, tr2s is a source rule which means that g2,c and g2,t are identities. from the shift property of application conditions we know that n1 |= acr using that m1 |= ac1f . this means that there is a morphism p : p → g11 with p◦a = n1, p |= ac′r, and ps = n1,s. it follows that g2◦ p◦a = g2◦n1 and g2◦ p = (g2,s◦ ps, pc, pt ) |= ac′r, because it only differs from p in the s-component, which is identical in all objects occuring in ac′r. gcm 2010 20 / 26 eceasst this means that g2 ◦n1 |= acr = ∃(a,ac′r), and can be shown recursively for composed acr. r1,s l1,c l1,t ps = r1,s pc pt r1,s r1,c r1,t p′c = r1,s p ′ c p ′ t tr1,s◦sl tl sp tp id ac at sr tr sp′ tp′ id bc bt id tr1,c tr1,t id uc ut p′s = r1,s p ′ c p ′ t r1,s r1,c r1,t g11,s g11,c g11,t g21,s g21,c = g11,c g21,t = g11,t ac′r acr sp tp sr tr sg10 tg10 sg11 tg11 id bc bt n1,s n1,c n1,t g2,s id id ps=n1,s pc pt � based on source consistent forward transformations we define model transformations, where we assume that the start graph is the empty graph. definition 6 (model transformation) a (forward) model transformation sequence (gs,g0 = tr∗f =⇒ gn,gt ) is given by a source graph gs, a target graph gt , and a source consistent forward transformation g0 = tr∗f =⇒ gn with g0 = (gs ∅←−∅ ∅−→∅) and gn,t = gt . a (forward) model transformation mtf : v ls vv lt is defined by all (forward) model transformation sequences. definition 7 (model transformation sc2pn) for our triple transformations, the triple rules are given by the set t r ={start, newregionsm, newregions, newstatesm, newstates, newfinalstatesm, newfinalstates, newtransitionnewevent, newtransitionnewexit, newtransitionoldevent, newtransitionoldexit, newguard, nextguard, newaction, newtriggerelement} as introduced in section 3. the model transformation sc2pn from statecharts to petri nets is defined by all forward model transformations using the forward rules t rf . the source rules represent a generating grammar for our statechart models. moreover, the restriction of all derived triple graphs to their source part, the language constructed by the source rules, and the statechart language v lsc are equal. proposition 2 (comparison of statechart languages) consider the languages v ls = {gs | ∃ triple transformation ∅ =start===⇒=tr ∗ =⇒ (gs ← gc → gt ) via rules in t r}, v ls0 = {gs | ∃ triple transformation ∅ = starts ===⇒= tr∗s =⇒ (gs ← ∅ → ∅) via source rules in t rs}, and v lsc as defined by the type graph and constraints. then we have that v ls = v ls0 = v lsc. proof idea. v ls ⊆ v ls0: for a statechart gs ∈ v ls there is a transformation ∅ = start ===⇒=tr ∗ =⇒ (gs ← gc → gt ) = gn, which can be decomposed with theorem 1 into a corresponding sequence ∅ = starts ==⇒= tr∗s =⇒ (gs ←∅→∅) = startf ===⇒= tr∗f =⇒ gn. this means that gs ∈v ls0. 21 / 26 volume 39 (2011) triple graph grammars with application conditions v ls0 ⊆v lsc: for a statechart gs ∈v ls0 there is a transformation ∅ = starts ==⇒= tr∗s =⇒ (gs ←∅→ ∅). gs is typed over the type graph t gs and respects all the specified constraints. this means that gs ∈v lsc. v lsc ⊆v ls: given a statechart model m ∈v lsc we have to show that we find a transformation sequence ∅ =start===⇒=tr ∗ =⇒ g with gs = m. we can show this by arguing about the composition of m and how to select the corresponding triple rule creating each element in m in the source part. this means that m ∈v ls. � example 4 as explained for our example transformation in section 3, applying the corresponding source rule sequence to the empty start graph we obtain our statechart example. this statechart model can be transformed into the petri net via the forward rules. this triple transformation is source consistent, since the matches of the source parts for the forward rules are uniquely defined by the comatches of the source rules. thus, we actually obtain a model transformation sequence from the statechart model in figure 1 to the petri net in figure 13. for all notions and results concerning source and forward rules, we obtain the dual notions and results for target and backward rules. thus, an application condition ac is t -consistent if it can be decomposed into ac ∼= ac′t ∧ac ′ b, where ac ′ t is a t -application condition with identities as,ac and ac′b is a t -extending application condition with identity at . this leads to target and backward rules with application conditions and the dual composition and decomposition properties for triple transformation sequences with t -consistent application conditions. moreover, a backward model transformation sequence (gt ,g′0 = tr∗b =⇒ g′n,gs) is based on a target consistent backward transformation g′0 = tr∗b =⇒ g′n with g′0 = (∅ ∅←−∅ ∅−→ gt ) and g′n,s = gs. 4.1 results for model transformations with application conditions based on theorem 1 we can show correctness, completeness, backward information preservation, and termination of model transformations. the first result shows that transformations are correct and complete regarding the source and target languages. theorem 2 (correctness and completeness w.r.t. v ls, v lt ) each model transformation sequence (gs,g0 = tr∗f =⇒ gn,gt ) and (gt ,g′0 = tr∗b =⇒ g′n,gs) is correct with respect to the source and target languages, i.e. gs ∈v ls and gt ∈v lt . for each gs ∈ v ls there is a corresponding gt ∈ v lt such that there is a model transformation sequence (gs,g0 = tr∗f =⇒ gn,gt ). similarly, for each gt ∈ v lt there is a corresponding gs ∈v ls such that there is a model transformation sequence (gt ,g′0 = tr∗b =⇒ g′n,gs). proof. if g0 = tr∗f =⇒ gn is source consistent we have a match consistent sequence ∅ = tr∗s =⇒ g0 = tr∗f =⇒ gn by definition 5 . by composition in theorem 1 there is a triple transformation ∅ = tr∗ =⇒ gn with gs = gn,s ∈v ls and gt ∈v lt . for gs ∈ v ls there exists a triple transformation ∅ = tr∗ =⇒ g, which can be decomposed by theorem 1 into a match consistent sequence ∅ = tr∗s =⇒ g0 = (gs ∅←− ∅ ∅−→ ∅) = tr∗f =⇒ g, and by gcm 2010 22 / 26 eceasst definition (gs,g0 = tr∗f =⇒ g,gt ) is the required model transformation sequence with gt ∈v lt . dually, this holds for backward model transformation sequences. example 5 since our example in section 3 represents a well-defined model transformation sequence, our statechart and petri net are correct. moreover, for each valid statechart model we obtain a correct petri net model, and vice versa. note, that for the backward translation this only holds for petri nets which are correct w.r.t. our target language, and not the language of all well-formed petri nets. a forward model transformation from gs to gt is backward information preserving concerning the source component if there is a backward transformation sequence from gt leading to the same source graph gs. definition 8 (backward information preserving) a forward transformation sequence g = tr∗f =⇒ h is backward information preserving if for the triple graph h′ = (∅ ∅←− ∅ ∅−→ ht ) there is a backward transformation sequence h′ = tr∗b =⇒ g′ with g′s ∼ = gs. this theorem is an extension of the corresponding result in [eee+07] to triple transformations with application conditions. theorem 3 (backward information preservation) if all triple rules are sand t -consistent, a forward transformation g = tr∗f =⇒ h is backward information preserving if it is source consistent. proof. if g = tr∗f =⇒ h is a source consistent sequence then by def. 5 there exists a match consistent sequence ∅ = tr∗s =⇒ g = tr∗f =⇒ h leading to the triple transformation sequence ∅ =tr ∗ =⇒ h using theorem 1. from the decomposition, we also obtain a match consistent sequence ∅ = tr∗t =⇒ h′ = tr∗b =⇒ h using the target and backward rules, with h′t = ht and h ′ c = h ′ s = ∅. thus, g = tr∗f =⇒ h is backward information preserving. example 6 the petri net in figure 13 can be transformed into the statechart in figure 1 using the backward rules of our model transformation in the same order as the forward rules were used for the forward transformation. indeed, this holds for each petri net obtained of a model transformation sequence from a valid statechart model. if the source and target rules are creating, i.e. each rule actually creates at least one element, forward and backward transformation sequences are terminating. this means that we do not find infinite model transformation sequences. theorem 4 (termination) consider a source model gs ∈ v ls (target model gt ∈ v lt ) and a set of triple rules such that gs (gt ) and all rule components are finite on the graph part and the triple rules are creating on the source (target) component. then each model transformation sequence (gs,g0 = tr∗f =⇒ gn,gt ) ((gt ,g′0 = tr∗b =⇒ g′n,gs)) is terminating, i.e. any extended sequence g0 = tr∗f =⇒ gn = tr′+f ==⇒ gm (g′0 = tr∗b =⇒ g′n = tr′+b ==⇒ g′m) is not source (target) consistent. 23 / 26 volume 39 (2011) triple graph grammars with application conditions proof. let g0 = tr∗f =⇒ gn be a source consistent forward sequence such that ∅ = tr∗s =⇒ g0 = tr∗f =⇒ gn is match consistent, i.e. each comatch ni,s determines the source component of the match mi,f . thus, also each forward match mi,f determines the corresponding comatch ni,s. by uniqueness of pushout complements along m -morphisms the comatch ni,s determines the match mi,s of the source step, thus mi,f determines mi,s (∗). if g0 = tr∗f =⇒ gn = tr(n+1,f),m(n+1,f) =========⇒ gn+1 = tr′′∗f ==⇒ gm is a source consistent forward sequence then there is a corresponding source sequence ∅ = tr∗s =⇒ g′ = trn+1,s ===⇒ g′′ = tr′′∗s ==⇒ g0 leading to match consistency of the complete sequence ∅ =⇒∗ gm. using (∗) it follows that g′ ∼= g0, which implies that we have a transformation step g0 = trn+1,s ===⇒ g′′ ⊆ g0, because triple rules are non-deleting. this is a contradiction to the precondition that each rule is creating on the source component implying that g′ 6∼= g0. therefore, the forward transformation sequence g0 = tr∗f =⇒ gn cannot be extended and is terminating. dually, this can be shown for backward model transformation sequences. example 7 all triple rules in our example in section 3 are finite on the graph part and source creating. thus, all model transformation sequences based on finite statechart models are terminating. note, that this does not hold for the backward direction, since the rule newaction is not target creating. thus, the corresponding backward rule can be applied infinitary often. 5 conclusion in this paper, we have extended the theory of model transformations based on tggs to rules with nested application conditions [hp09], which are known to be equivalent to first order logic (fol) on graphs. using the slight restriction to s-consistent application conditions we have shown that the main results known for model transformations are preserved. in fact, this is a substantial extension of the existing theory, because s-consistent application conditions provide the expressive power of fol separately for the source and target components of triple graphs, respectively. this enhances the expressiveness of model transformations including that of the generation of source and/or target languages. we have discussed in detail a model transformation from statecharts to petri nets, where the use of application conditions allows to specify and translate more general statecharts then those considered in [eept06]. there, an inplace model transformation is used, which means that the model itself is changed in contrast to our approach, where the original source model is kept and an additional target model is created. we have presented main results for termination, correctness, completeness, and information preservation extending those for the case with nacs in [ehs09] and without nacs in [eee+07]. our new results are based on the local church–rosser, parallelism, and concurrency theorems with nested application conditions in [ehl10]. as future work it remains to extend also the results concerning functional behaviour in [heog10] and [hego10] to the case of rules with nested application conditions based on the “on-the-fly construction” in [eehp09]. this would allow to meet the “grand research challenge of the tgg community” in [sk08] for our enhanced framework. it is out of the scope of this paper to show that our model transformation from statecharts to gcm 2010 24 / 26 eceasst petri nets is semantically correct, where the semantics of the source and target language could be based on a suitable operational semantics. for statecharts, an operational semantics based on amalgamated graph transformation is presented in [gbee11]. in [gol11], also an operational semantics for petri nets using amalgamated graph transformation is defined and the model transformation given in this paper is shown to be semantics-preserving. it is future work to obtain general criteria for semantical correctness of model transformations. another future point of work is the construction of source and forward application conditions for general, not necessarily s-consistent application conditions. obviously, in this case a different property for the compatibility of the source and forward solutions would be required to ensure the corresponding decomposition and composition result. bibliography [eee+07] h. ehrig, k. ehrig, c. ermel, f. hermann, g. taentzer. information preserving bidirectional model transformations. in dwyer and lopes (eds.), proceedings of fase 2007. lncs 4422, pp. 72–86. springer, 2007. [eeh08] h. ehrig, c. ermel, f. hermann. on the relationship of model transformations based on triple and plain graph grammars. in karsai and taentzer (eds.), proceedings of gramot 2008. pp. 9–16. acm, 2008. [eehp09] h. ehrig, c. ermel, f. hermann, u. prange. on-the-fly construction, correctness and completeness of model transformations based on triple graph grammars. in schürr and selic (eds.), proceedings of models 2009. lncs 5795, pp. 241–255. springer, 2009. [eept06] h. ehrig, k. ehrig, u. prange, g. taentzer. fundamentals of algebraic graph transformation. eatcs monographs. springer, 2006. [ehl10] h. ehrig, a. habel, l. lambers. parallelism and concurrency theorems for rules with nested application conditions. eceasst 26:1–23, 2010. [ehs09] h. ehrig, f. hermann, c. sartorius. completeness and correctness of model transformations based on triple graph grammars with negative application conditions. eceasst 18:1–18, 2009. [gbee11] u. golas, e. biermann, h. ehrig, c. ermel. a visual interpreter semantics for statecharts based on amalgamated graph transformation. eceasst 39:1–24, 2011. this volume. [gl06a] e. guerra, j. de lara. attributed typed triple graph transformation with inheritance in the double pushout approach. technical report uc3m-tr-cs-2006-00, universidad carlos iii, madrid, spain, 2006. [gl06b] e. guerra, j. de lara. model view management with triple graph grammars. in corradini et al. (eds.), proceedings of icgt 2006. lncs 4178, pp. 351–366. springer, 2006. 25 / 26 volume 39 (2011) triple graph grammars with application conditions [gol11] u. golas. analysis and correctness of algebraic graph and model transformations. phd thesis, technische universität berlin, vieweg + teubner, 2011. [hego10] f. hermann, h. ehrig, u. golas, f. orejas. efficient analysis and execution of correct and complete model transformations based on triple graph grammars. in bézivin et al. (eds.), proceedings of mdi 2010. pp. 22–31. acm, 2010. [heog10] f. hermann, h. ehrig, f. orejas, u. golas. formal analysis of functional behaviour for model transformations based on triple graph grammars. in proceedings of icgt 2010. lncs 6372, pp. 155–170. springer, 2010. [hp09] a. habel, k.-h. pennemann. correctness of high-level transformation systems relative to nested conditions. mscs 19(2):245–296, 2009. [ks06] a. könig, a. schürr. tool integration with triple graph grammars a survey. entcs 148(1):113–150, 2006. [omg09] omg. unified modeling language, superstructure, version 2.2. 2009. [pet80] c. petri. introduction to general net theory. in brauer (ed.), net theory and applications. lncs 84, pp. 1–19. springer, 1980. [sch94] a. schürr. specification of graph translators with triple graph grammars. in tinhofer (ed.), proceedings of wg 1994. lncs 903, pp. 151–163. springer, 1994. [sk08] a. schürr, f. klar. 15 years of triple graph grammars. in ehrig et al. (eds.), proceedings of icgt 2008. lncs, pp. 411–425. springer, 2008. [teg+05] g. taentzer, k. ehrig, e. guerra, j. lara, l. lengyel, t. levendovsky, u. prange, d. varró, s. varró-gyapay. model transformation by graph transformation: a comparative study. in proceedings of mtp 2005. 2005. http://sosym.dcs.kcl.ac.uk/events/mtip05/submissions/. gcm 2010 26 / 26 introduction review of triple graph grammars and application conditions model transformation from statecharts to petri nets model transformations with application conditions results for model transformations with application conditions conclusion damages and benefits of certification: a perspective from an independent assessment body electronic communications of the easst volume 33 (2010) proceedings of the fourth international workshop on foundations and techniques for open source software certification (opencert 2010) damages and benefits of certification: a perspective from an independent assessment body mario fusani, eda marchetti 12 pages guest editors: luis s. barbosa, antonio cerone, siraj a. shaikh managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst damages and benefits of certification: a perspective from an independent assessment body mario fusani1, eda marchetti2 1systems and software evaluation centre and 2software engineering laboratory isti-cnr, pisa, italy abstract: the paper investigates on the nature of software certification and its reasons of being. the numerous factors that impact on the achievement of its purposes are discussed, and also compared in the cases of proprietary software and open source software. some relevant features of a certification process for open source software are finally proposed. keywords: certification, standardisation, open source software 1 introduction traditionally, software certification has started as a need about proprietary software. the objective of such a need has been the achievement and transfer, among the numerous parties involved in software production and use, of the confidence that a software-related product or service actually possesses declared behavioural, in case structural, characteristics. the reason for considering here the software along the proprietary/non-proprietary perspective is that proprietary software, or closed source software (css), and its ”opposite” open source software (oss), have considerable mutual impact with certification. we are not investigating here the nature of oss, object of endless streams of literature. the purpose of this paper is instead to show a research line for determining what oss certification can be, which are the factors that impact in its goals, and how could such factors be put under control. to do so, the reasons for software certification and its very concept, that has been maturing in the css realm for many years, have to be revisited. this is because it seems that the certification concept and its implications, yet extensively spoken about, have not been discussed deeply enough in literature and even little understood, and it is this lack of understanding that, in our opinion, carries more weight to the ”damages” side of the balance damage/benefit for all certification users. we believe that the various stakeholders around both css and oss, especially oss, can benefit from added-value of certification, but such benefits depends on a number of ways certification process is defined and conducted. inappropriate goals and use can bring more disadvantages than advantages, especially to end-users. end-users are our favorite stakeholders when we speak of certification, because it’s us (us who can enjoy in our daily life, although indirectly, of services generated by css and, more and more, by oss). the objective of investigating the various aspects (both in terms of goals and means) of oss certification cannot be adequately achieved without analysing first them in the case of css, 1 / 12 volume 33 (2010) where they have been established for long, and, even before that, in the more general case of products and processes. the risk of being biased by css-related issues is low if we keep in mind the final oss objective. thus, the rest of this paper is organised as follows: in section 2, the basic concepts of certification are re-visited in the light of the 25-year experience of the systems and software evaluation centre working with css. this overview is believed to be useful because, as mentioned above, most often ”certification” is used as a term and done as a practice, but without a clear notion of what it is about. in section 3, factors (technological, managerial, knowledge-oriented) that impact into the achievement of the css certification goals are evidenced and discussed. in section 4, the goals of css and oss certification are compared, and factors and impacts considered in section 3 are checked for survival or adaptation for the oss case. new factors, pertinent to the oss certification goals, are introduced. pros and cons of various factors impacting in the oss certification are discussed. in section 5, concluding remarks are drawn and future developments lines of the current research are sketched. the abbreviations used in this paper are recollected at the end, in table 6. 2 basic concepts and practice of certification 2.1 what is certification? many representatives of various professional backgrounds use the term ”certification”, possibly with different meanings. official definitions, as we see below, contain expressions that must be interpreted in turn. for instance, in that from the iso guide [iso96]: a procedure by which a third party gives written assurance that a product, process or service conforms to specified requirements some terms need to be clarified, to avoid too many different interpretations: third party seems to be a crucial role in the procedure, and will be discussed below as a member of the stakeholders list. assurance can be given as a result of an activity, the conformity assessment, defined in the same guide but perfected by the standard iso/iec 17000 [iso04] as follows: an activity that provides demonstration that specified requirements relating to a product, process, system, person or body are fulfilled. there are more acceptable definitions, but the mentioned ones are sufficient to illustrate the concept. the terms that need to be interpreted are related to most of the factors determining how the certification goals are achieved and will be discussed in the next two sections. notice that nothing like a guarantee is mentioned in the definitions. typically in software technology, the proc. opencert 2010 2 / 12 eceasst word ”guarantee” has not been welcomed ever since this standard was defined (in facts, vendors have been preferring to issue a good deal of variants on the use of disclaimers). we want to observe that in most technologies, including software, the mentioned demonstration, can be better and more realistically understood as ”confidence transfer” among certification stakeholders (for example, from a third party organism to an user) and this, as we mention in the following, can work as a value-added aspect of certified objects such as products and processes. it seems that the confidence and confidence-transfer concepts, probably because of apparent self-evidence, has not been deeply discussed in literature: mostly it was insisted in describing tests and measures [voa00] [tri02] [mtt09], and little attention was paid to the ”confidence” aspect itself. this is probably one reason why certification was often mistaken by users as a guarantee, and by producers as particularly severe verifications and validations. if we consider the software, then the confidence is generally weakened, and it can be observed again that responsibility disclaimers associated to products are much more frequent than certificates. even the term ”certification” was somewhat banished in the us for years, because of the unspoken threat that customers unions could claim refunds for unsatisfying certified services. certification cannot be well explained without reporting the most general scenario in which it usually happens. figure 1 shows, in a rather simplified way, how a stakeholder such as a certification body (cb) operates according to two distinct categories of standards (one for the cb process, another for object references). the actual certification targets are properties of some types of entities, such as products, processes, people, environment. cb credibility, one of the bases of the mentioned confidence (see also next section), is supported by cb accreditation according to a refereed process, via international accreditation bodies (ab) that, in turn, monitor each other in a periodical peer-to-peer process. other stakeholders such as suppliers and users at various levels are not shown here, but their relationships in the scheme can be rather easily figured out. a more comprehensive discussion can be found in [ffl06]. 2.2 confidence spreading among stakeholders if we accept the principle that confidence and confidence passing is the bottom-line of the value of certification and its reason of being, an investigation about its nature is necessary, before checking how it can vary in different contexts, mainly in the css and oss cases. one first research question is: who should possess such confidence? if we scan a possible list of stakeholders, such as the rich one reported in [tay09] for both commercial off-the-shelf (cots) software and oss, we may think of various candidates including customers and possibly end users, but likely in different measures. other related research questions are: where does confidence start? how could it be transferred? can it, purposely or accidentally, change during transfer? and how? working on such questions means finding out the elements or factors that determine not only the success of certification and then the possible added value it gives to products, but also the mechanisms by which confidence is passed and changed. to give a quantitative nature to such factors seems quite hard to achieve. an attempt to express their strength by an ordinal scale is made in the next section. figure 2 shows a typical scenario where a supplier who is confident that the product to be supplied has certain properties, but wants the (generally non technical) customer share the same confidence. here a cb acts as a catalyst in confidence passing from supplier to customer, who 3 / 12 volume 33 (2010) figure 1: simplified certification scheme might be wanting or not to continue the transfer down to final users. two more remarks on confidence are useful before analysing what it can depend on. first, there are different views of confidence, depending on the considered stakeholder. for example, a developer may want the confidence that the software is deadlock-free (this particular one can be achieved only by proof), whilst an end-user may be wanting that a software-related product behaves efficiently and safely, or, as a more subjective, imprecisely defined but more probable wish, that the product is ”fit for use”. next, we can be tempted of interpreting the demonstration mentioned in the definition given in section 2.1 as ”proof” in mathematical sense. just regarding the software, this is more realistic achievement now than used to be when the defining standards was last issued and reviewed, as formal methods and tools are becoming interesting, useful, and likely will be the most important technical ingredient of the certification process. however, the scope of formally provable statements, with all the necessary math to get to the final statement, is restricted only to portions of the chain ”user needs-requirements-architecture-code”. in many cases, more traditional, yet possibly automated means would be necessary, that are no proof, yet still there can be confidence. for example, a formal proof could be used to verify and then certify that a software has a property such as deadlock-freeness. if the property to be certified is maintainability, we would most likely have less rigorous but nevertheless workable alternatives, such as informal, procedure-guided analyses, simulations and tests. confidence can be built, and should be, on proofs, but is generally no proof itself. proc. opencert 2010 4 / 12 eceasst figure 2: confidence transfer 3 certification goals: what their achievement depends on we can now summarise an important certification goal in terms of confidence: maximum, well-grounded confidence (that product properties declared by certifier are actual properties) can be transferred to stakeholders who 1) benefit of the products and associated services; 2) decide of products adoption. the same definition is simplified when the certifier is in one of the two stakeholders categories, but this is not the case in which confidence can get higher. now we can examine what elements, or factors, can facilitate or inhibit the achievement of this goal in various contexts. if certification is no proof (which is not), then the elements that give it some value (our factors) deserve to be investigated and discussed. 3.1 impact factors in css environment whilst the certification goal is the same for both css and oss, the factors on which it depends may vary to one another. we start examining the css-related factors, to check them also for the oss case in next section. the following is a list of factors categories. it can possibly be an open-ended one, but it is sufficient for a comprehensive enough discussion of their impact on the certification goals. • references used by cb • certification objects • certification process references used by cb are those denoted as ”reference models” in figure 1. certification objects are, in our case, properties of products to be certified. certification process represents the activities to get to the certificate, executed mainly by the cb but also by other stakeholders. 5 / 12 volume 33 (2010) table 1: ”cb references” impact factors factor supp cust user euser requirements specifications l m h h functional standards m h m m life-cycle standards h m l l product quality standards m h h h table 2: ”certification objects” impact factors factor supp cust user euser functional m h m h performance m m m h architectural h m l l quality in use m h h h internal quality h h m l all these factors categories are expanded into lower-level factors in the first columns of tables 1, 2 and 3, respectively. in order to be helpful, the impact into the certification goal (that, we recall, is expressed by confidence acquired by stakeholders about the product) of each of the above factors categories, and especially of the lower-level factors, should be measurable. that is, it should be possible to find a mapping between each factor and a measure scale for its impact. although this is a typical case of human judgement, for which measurability is questionable, we wish to express in some way the intensity of the impact. a scale could have a binary nature (there is impact or not), or could be expressed in an ordinal scale of judgement, for example {low (l), medium (m), high (h) impact}. here we use the latter type of scale. in tables 1, 2, 3 only the most relevant types of stakeholders are taken into account, as targets of the various impact factors. limited space prevents discussion of the reasons for assigning all these measures, which are still an ongoing investigation. some of these reasons are reported in the following discussion. the information in these tables should be interpreted in the following way: ”if stakeholder s is informed (typically by a certificate) that: • cb certified a product property against a factor x of table 1, then its confidence on the certification results is as entry (s, x) of table 1; • the certification object is factor y of table 2, then its confidence on the certification results is as entry (s, y) of table 2; • cb process has the same characteristic as factor z of table 3, then its confidence on the certification results is as entry (s, z) of table 3.” proc. opencert 2010 6 / 12 eceasst table 3: ”certification process” impact factors factor supp cust user euser cb is independent m m h h cb is accredited on a refereed accreditation process h h m l cb processes follow rigorous standards themselves h h m l tests are severe h m l l formal methods used when possible h m l l reverse engineering used when possible h m l l reference standards easy to adopt h h m m reference standards easy to check conformance m m h h traceable product m l l l evidence of product lifecycle is available h h l l confidence is build up as a list (not a sum because we have ordinals) of measures or scores l, m, h when multiple entries are enabled. notice that the factors regarding the objects are directly related to the reference factors. 3.2 discussion on impacting factors in css environment to start working on the research questions given above, a short discussion on the impacting factors follows. out of the yet limited set of stakeholders of the certification, the figures cust (that may coincide with the user) and the euser are more relevant for our declared purposes. the former is the entity thyat pays for the product, which is sold, possibly as a service, to the latter. then usually euser pays for all, and enjoys the good or service. most often euser is not able to judge about factors such as life-cycle or internal quality, and often does not even know that software is in the product / service, neither that a cb has certified it. when she/he knows that, say from an advertisement, that’s where her/his only confidence comes from. the factors shown in table 3 are facts about cb and its actions. just to comment on one of these, the factor ”test are severe” does not necessary mean that cb executes tests. it may do it, as it can witness supp’s tests or thoroughly inspect supp’s testing documentation, make use of an independent, accredited testing laboratory, request re-execution of some tests or a combination of all that. those three lists of lower-level factors limit in some way the investigation area about the causes that determine the certification goals. moreover, to direct the research along some line, we should further restrict to examine single cases, to try to generalise afterwords. let us examine here just two cases in which certification can give misleading confidence to stakeholders. case 1: what if, for the same product, the quality of the reference standards (see table 3, entries 7 an 8) was not so good ? this fact could be missed by both supp and cust, that hardly look at such quality aspects: the main supp’s and cust’s concern about a standard is compliance for liability reasons, and not standard quality. here a risk arises for euser if the certificate was only 7 / 12 volume 33 (2010) issued for protect supp against liability and for commercial reasons (certificates can be excellent advertisement), in case the standard, yet technically correct, does not possess the qualities that facilitate its adoption and the certifiability of products against its (of the standard) requirements. the probability of such a case is not a remote one [bcf+10], as eusers representatives are rarely included in standard-making groups, a fact our centre knows well, having been involved in both iso and cenelec standards working groups for years. case 2: this is a typical problem our centre has been found since long as an independent, if not yet accredited, product and process assessment body (factors 1 and 3 of table 3 hold, factor 2 does not yet) . the target software product, a fiscal software for electronic cash registers (ecr) (fiscal software is now a reality in over 30 countries), must be approved by the government on the basis of evidence that some defined properties are certified by the centre. then, copies of the software (by the tens of thousands) are allowed to be installed in the ecrs. any variant must be submitted again to certification before being installed in the field. the problem is how to monitor, in an inexpensive way, that no variant exists in the field, different from that that passed through the certification process. the problem, here reported in a rather simplified way, is hard to solve: check in table 3, entry 9, that cust and user have little notion about product traceability (even supp may or may not have that notion). there are solutions, but not inexpensive ones, since they imply the definition and se-tup of a (virtual) network with identified and securely communicating nodes, that was not possible at the beginning of the regulations about fiscal software for ecrs. so, a variant, unchecked ecr software could be officially certified, and confidence of euser would be quite high, but definitely ungrounded. 4 impact factors in oss environment tables 4 and 5, corresponding to the first and third higher-level factors, revisited, are shown below. in this environment, the picture of the stakeholders and of their relationships is different. it seems important to evidence the cb because of its tighter connections with the other stakeholders. cb may well happen to work with user and then with the developers too [voa00], because they are often also users, even if they take the suppliers’ place. developers could have been also shown in css environment, and were not just to keep the tables comparatively simpler. so, the boundaries among stakeholders roles become much more indistinct than in css, and what is shown from column 2 on in tables 4 and 5 is nothing but emerging aspects. the scenario gets more complicated as the tester figure also emerges. in fact, oss properties mostly get verified by testing in operational environment, especially for product selection and adoption, and also during actual service. testing before delivery is only a fraction of the testing process. also, some of the factors mentioned in section 3.1 are far less realistic (a consideration that is not worrying too much) and new factors become evident. without the pretend to be exhaustive, we point out some most relevant differences. we think important the possibility of having open source specifications in the references for the cb. in fact, in oss the specifications are not any more controlled by a single organization but proc. opencert 2010 8 / 12 eceasst table 4: ”cb references” impact factors for oss factor dev cb cust tester user euser product reqs specifications m h h h h m open source specifications m h h h m h functional standards m h m m m m life-cycle standards l m l l l l product quality standards m h h h m h table 5: ”certification process” impact factors for oss factor dev cb cust user tester euser cb is independent m m m m l h cb is accredited m h h l l m standard conformant cb processes m h m l l l tests are severe m h m m h m formal methods used when possible h h m m m m reverse engineering used when possible m m l m m l reference standards easy to adopt h h h h h m reference standards easy to check conformance m m m m m m traceable product h h m m h m evidence of product lifecycle is available m m m l m l use of collaborative tools h h m m h m automated process h h h h h m independent development h h h h h m history of evolution h h h m h m they continuously evolve according to exigencies of individuals or companies, influencing therefore the certification process. thus a certification process for oss should reflect this adaptation, providing certificates with validity and a scope changing over the time. the adoption of oss also introduces the possibility of having independent development and the history of evolution. the possibility of independent development from developers and companies having different skills could influence the certification process in different ways: from one side, high variability and evolution (versioning) of the same open source product could evidence unstable and not yet mature releases; from the other, the abilities and reliability of a specific (group of) developers could be part of the certification process itself and influence the final decision. also the history of the software evolution as well as any other information derivable by the current available osi certification [ope08] could be useful for a certification process. the certificates could be associated only to a certain evolution of the oss and then related to a specific time and version. regarding life-cycle evidence, less impact here does not mean that we should have less interest in oss life-cycle. on the contrary, if life means being alive, then oss life-cycles can 9 / 12 volume 33 (2010) be much more alive than css. such evolutionary dynamism does not fit well with most established standard and independent certification as it was shown in sections 2 and 3. and all those verifications of requirements and design documents and their management are no more an issue. testing and configuration management processes are still there [omk08], but their actors are geographically distributed. moreover, novel, peculiar oss processes are in place, related with web-based co-operative environments. oss life-cycle processes are only in part conformant to ”software lifecycle processes” [iso08], but could be anatomically dissected and described accordingly: this may be a good promising derived research but is out of the scope of this paper. to this purpose we can refer to a recent paper [bou10] that compares the development process of css with that of oss. actors performing these processes are non-necessarily co-ordinating to each other, but the process can have much more impact if some collaborative tools are used among such stakeholders. in fact, we propose automation in certification process, to outline the characteristic of de personalisation of decisions together with that of (at least virtually) centralised repositories for oss product releases and certification records. in our opinion, cb independence and cb accreditation should hold. only, the cb cannot assess the oss life-cycle processes as it does in css, but basically analyses process results, including product versions, that were deposited in a repository by the oss developers. stakeholders such as customers would not pick the products from developers to submit them to cb, but would get the certified software directly from a repository. re-considering the previous case 1, we can notice the following for oss: end users could be even more protected by defective standards in oss, as potentially all the developers and users communities can have access to the ways a reference standard has been interpreted to certify a product. as all the stakeholders roles are intercommunicating, they can monitor all the certification process steps the cb carries on whose execution track can be recorded in the same repository that also collects the product versions. and, re-considering previous case 2: even it is hard to think that a public administration can be convinced at adopting secure oss, this is not impossible. the mentioned problem could be resolved because all the variants would be taken from a repository in which only certified versions are available, even in the case the control has passed from suppliers to the repository administrators or to privileged users, such as the cb. 4.1 value of a virtual repository as a support of oss certification there would be rules for interacting with the repository. this would not alter the ”unruled” nature of typical oss stakeholders, because repository interactions can happen only on a voluntary basis. only, to get a (possibly dynamic) certificate, with all the advantages, made possible as long as the described factors hold, some firm modalities to act must be in place, to ensure the cb can operate. this way, subscribing an oss project to a virtual certification repository would be appealing indeed. we insist on the unchangeability of some factors regarding the cb: i) independence, ii) having a process that follows publicly available standards for assessment and certification (adapted proc. opencert 2010 10 / 12 eceasst table 6: abbreviations abbreviation text ab accreditation body cb certification body cots commercial off-the-shelf css closed source software cus customer dev developer ecr electronic cash register euser end user oss open source software supp supplier to oss environment), iii) accreditation according to a well-known and refereed accreditation scheme, which implies periodical monitoring of the cb by a recognised accreditation body. 5 conclusions in this paper we presented an overview of the most important aspects of the css certification process and how they can be put in relation with the emerging oss. as discussed in the paper, many of the impact factors of the css have to be readapted and rediscussed to face the innovations and the exigencies of the oss context. in this paper we proposed a first tentative of revising the important factors of the css adding wherever is possible new and specific ones in relation with the peculiarities of the oss process. what emerges from a first analysis is that the results of certification should not be unique anymore, but would show several degrees or scores depending on the characteristics of the oss version considered. it is therefore thinkable that the metrics for assigning a certificate could include either the evaluation of specific open source specifications or (and) evidences about the released version or (and) the reliability score of developers. the certification could also be related to the history of the oss and would have a period of validity (start and end date), which is an evolution of the traditional certification policies. to facilitate, and perhaps to make it possible, an oss certification process, we think it is be important to have a repository in which, in addition to the conventional information, further and more specific data for certification analyses are included. this should involve information about the verification and validation activities performed as well as scores about the reliability attitude of the developers. in the authors’ opinion, one contribution of this paper is the summary of important aspects of the certification process for oss. these aspects could not be completed here, and further analyses and improvements are necessary. our intention was to make a first step on the construction of a oss certification process trying to exploiting as much as possible of the evidences and the experiences of the css environment. 11 / 12 volume 33 (2010) bibliography [bcf+10] i. biscoglio, a. coco, m. fusani, s. gnesi, g. trentanni. an approach to ambiguity analysis in safety-related standards. in proc. of quatic 2010 (7th international conference on the quality of information and communications technology). september 29-october 2, 2010. [bou10] a. boulanger. open-source versus proprietary software: is one more reliable and secure than the other? ibm systems journal 44(2):239–248, 2010. [ffl06] f. fabbrini, m. fusani, g. lami. basic concepts of software certification. in proc. of 1st international workshop on software certification (certsoft’06). pp. 4–16. mcmaster university, 2006. [iso96] iso/iec. iso/iec guide 2:1996, standardization and related activities general vocabulary. 1996. [iso04] iso/iec. iso/iec 17000: 2004, iso/iec 17000:2004, conformity assessment vocabulary and general principles. 2004. [iso08] iso/iec. iso/iec 12207:2008 information technology: software life cycle processes. 2008. [mtt09] s. morasca, d. taibi, d. tosi. towards certifying the testing process of open-source software: new challenges or old methodologies?. in proc. of the 2009 icse workshop on emerging trends in free/libre/open source software research and development. pp. 25–30. ieee computer society, 2009. [omk08] t. otte, r. moreton, h. d. knoell. applied quality assurance methods under the open source development model. in proc. of the 32nd annual ieee international computer software and applications conference. pp. 1247–1252. compsac, 2008. [ope08] opensource.org. osi certified open source software. 2008. [tay09] r. taylor. understanding how oss development models can influence assessment methods. in proc. of the third international workshop on foundations and techniques for open source software certification. 28 march 2009. [tri02] l. tripp. software certification debate: benefits of certification. ieee computer, pp. 31–33, june 2002. [voa00] j. voas. developing a usage-based software certification process. ieee computer 33:32–37, 2000. proc. opencert 2010 12 / 12 introduction basic concepts and practice of certification what is certification? confidence spreading among stakeholders certification goals: what their achievement depends on impact factors in css environment discussion on impacting factors in css environment impact factors in oss environment value of a virtual repository as a support of oss certification conclusions checking graph-transformation systems for confluence electronic communications of the easst volume 26 (2010) manipulation of graphs, algebras and pictures essays dedicated to hans-jörg kreowski on the occasion of his 60th birthday checking graph-transformation systems for confluence detlef plump 15 pages guest editors: frank drewes, annegret habel, berthold hoffmann, detlef plump managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst checking graph-transformation systems for confluence detlef plump the university of york, uk abstract: in general, it is undecidable whether a terminating graph-transformation system is confluent or not. we introduce the class of coverable hypergraph-transformation systems and show that confluence is decidable for coverable systems that are terminating. intuitively, a system is coverable if its typing allows to extend each critical pair with a non-deletable context that uniquely identifies the persistent nodes of the pair. the class of coverable systems includes all hypergraph-transformation systems in which hyperedges can connect arbitrary sequences of nodes, and all graphtransformation systems with a sufficient number of unused edge labels. keywords: confluence, graph transformation, coverable systems 1 introduction confluent sets of graph-transformation rules can be executed without backtracking since all terminating derivations produce the same result for a given input graph. applications of confluence include the efficient recognition of graph classes by graph reduction [acps93, bf01, bpr04], the parsing of languages defined by graph grammars [fkz76, rs97], and the deterministic input/output behaviour of programs in graph-transformation languages such as agg [tae04], fujaba [nnz00], grgen [gbg+06] or gp [plu09]. in the settings of string and term rewriting, confluence is decidable for terminating systems [bo93, bn98, bkv03]: one computes all critical pairs t ← s → u of rewrite steps and checks whether t and u are joinable in that they reduce to a common string resp. term. in contrast, confluence is undecidable in general for terminating graph-transformation systems [plu05]. the problem is, in brief, that the joinability of all critical pairs need not imply confluence of a system. to guarantee confluence, one has to impose extra conditions on the joining derivations, leading to the notion of a strongly joinable critical pair. however, strong joinability of all critical pairs is not a necessary condition for confluence and hence, in general, cannot be used to decide confluence. in this paper, we introduce coverable hypergraph-transformation systems and show that confluence is decidable for coverable systems that are terminating. intuitively, a system is coverable if its typing allows to extend each critical pair with a non-deletable context—a cover—that uniquely identifies the persistent nodes of the pair. we give a decision procedure for confluence that processes each extended critical pair γ̂ : û1 ⇐ ŝ ⇒ û2 by reducing û1 and û2 to normal forms x1 and x2, and checking whether x1 and x2 are isomorphic. if this is the case, then the critical pair underlying γ̂ is strongly joinable; otherwise, a counterexample to confluence has been found. roughly speaking, a cover for a critical pair can be constructed if the signature of the hypergraph-transformation system under consideration contains (hyper-)edge labels that do not occur in rules and that can be used to connect the persistent nodes of the critical pair by edges. such a 1 / 15 volume 26 (2010) checking graph-transformation systems for confluence cover cannot be deleted by rules. moreover, there must be a unique surjective morphism from the cover to each of its images under a graph morphism. we give different conditions under which covers can be constructed and show, in particular, that the class of coverable systems includes all hypergraph-transformation systems in which hyperedges can connect arbitrary sequences of nodes. the rest of this paper is organised as follows. the next section recalls some terminology for binary relations and defines hypergraphs and their morphisms. section 3 reviews the doublepushout approach to (hyper-)graph transformation in a setting where rules are matched injectively and can have non-injective right-hand morphisms. we define confluence of hypergraphtransformation systems and recall the fact that confluence is undecidable for terminating systems. in section 4 we review the role of critical pairs in establishing confluence. section 5 introduces covers for critical pairs and coverable systems, discusses our main result and the associated decision procedure for confluence, and presents special cases where confluence is decidable. in section 6, we conclude and discuss a topic for future work. 2 preliminaries we recall some terminology for binary relations (consistent with [bn98, bkv03]) and define hypergraphs and their morphisms. 2.1 relations let → be a binary relation on a set a. the inverse relation of → is denoted by ←. we write →+ for the transitive closure of → and →∗ for the transitive-reflexive closure of →. two elements a, b ∈ a have a common reduct if a →∗ c ←∗ b for some c. if a →∗ c and there is no d such that c → d, then d is a normal form of a. the relation → is (1) terminating if there is no infinite sequence a1 → a2 → a3 → . . . , (2) confluent if for all a, b and c with b ←∗ a →∗ c, elements b and c have a common reduct (see figure 1(a)), (3) locally confluent if for all a, b and c with b ← a → c, elements b and c have a common reduct (see figure 1(b)). • • • ∗ ∗ • ∗ ∗ • • • • ∗ ∗ (a) confluence (b) local confluence figure 1: confluence properties festschrift h.-j. kreowski 2 / 15 eceasst by the following well-known result, local confluence and confluence are equivalent in the presence of termination. lemma 1 (newman’s lemma [new42]) a terminating relation is confluent if and only if it is locally confluent. 2.2 hypergraphs we deal with directed, labelled hypergraphs and use a simple type system where the label of a hyperedge restricts the number of incident nodes and their labels. a signature σ =〈σv, σe, type〉 consists of a set σv of node labels, a set σe of hyperedge labels and a mapping type assigning to each l ∈ σe a set type(l) ⊆ σ∗v. unless stated otherwise, we denote by σ an arbitrary but fixed signature over which all hypergraphs are labelled. a hypergraph over σ is a system g = 〈vg, eg, markg, labg, attg〉 consisting of two finite sets vg and eg of nodes (or vertices) and hyperedges, two labelling functions markg : vg → σv and labg : eg → σe, and an attachment function attg : eg → v∗g such that mark ∗ g(attg(e)) ∈ type(labg(e)) for each hyperedge e. (the extension f ∗ : a∗ → b∗ of a function f : a → b maps the empty string to itself and a1 . . . an to f (a1) . . . f (an).) we write h (σ) for the set of all hypergraphs over σ. in pictures, nodes and hyperedges are drawn as circles and boxes, respectively, with labels inside. lines represent the attachment of hyperedges to nodes, where numbers specify the leftto-right order in the attachment string. for example, figure 2 shows a hypergraph with four nodes (all labelled with •) and three hyperedges (labelled with b and s). s 1 2 1 b 2 3 s 1 2 figure 2: a hypergraph a hypergraph g is a graph if each hyperedge e is an ordinary edge, that is, if attg(e) has length two. ordinary edges may be drawn as arrows with labels written next to them. given hypergraphs g and h , a hypergraph morphism (or morphism for short) f : g → h consists of two functions fv : vg → vh and fe : eg → eh that preserve labels and attachment to nodes, that is, markh ◦ fv = markg, labh ◦ fe = labg and atth ◦ fe = f ∗ v ◦attg. a morphism incl : g→h is an inclusion if inclv(v) = v and incle(e) = e for all v∈vg and e∈eg. in this case g is a subhypergraph of h which is denoted by g ⊆ h . every morphism f : g → h induces a subhypergraph of h , denoted by f (g), which has nodes fv(vg) and hyperedges fe(eg). morphism f is injective (surjective) if fv and fe are injective (surjective). if f is surjective, then h is an image of g. if f is both injective and surjective, then it is an isomorphism. in this case g and h are isomorphic, which is denoted by g ∼= h . 3 / 15 volume 26 (2010) checking graph-transformation systems for confluence the composition of two morphisms f : g → h and g : h → m is the morphism g◦ f : g → m consisting of the composed functions gv ◦ fv and ge ◦ fe. the composition is also written as g → h → m if f and g are clear from the context. a partial hypergraph morphism f : g → h is a hypergraph morphism s → h such that s ⊆ g. here s is the domain of definition of f , denoted by dom( f ). 3 graph transformation we briefly review the double-pushout approach to graph transformation. in our setting, rules are matched injectively and can have non-injective right-hand morphisms. (see [hmp01] for a comparison with other variants of the double-pushout approach.) 3.1 rules and derivations a rule r : 〈l ← k → r〉 consists of two hypergraph morphisms with a common domain, where k → l is an inclusion. the hypergraphs l and r are the leftand right-hand side of r, and k is the interface. the rule is injective if the morphism k → r is injective. let g and h be hypergraphs, r : 〈l ← k → r〉 a rule and f : l → g an injective morphism. then g directly derives h by r and f , denoted by g ⇒r, f h , if there exist two pushouts as in figure 3. given a set of rules r, we write g ⇒r h to express that there exist r ∈ r and a l k r g d h f figure 3: a double-pushout morphism f such that g ⇒r, f h . we refer to [plu05] for the definition and construction of hypergraph pushouts. intuitively, the left pushout corresponds to the construction of d from g by removing the items in l−k, and the right pushout to the construction of h from d by merging items according to k → r and adding the items in r that are not in the image of k. a double-pushout as in figure 3 is called a direct derivation from g to h and may be denoted by g ⇒r, f h or just by g ⇒r h or g ⇒ h . a derivation from g to h is a sequence of direct derivations g = g0 ⇒ . . . ⇒ gn = h , n ≥ 0, and may be denoted by g ⇒ ∗ h . given a rule r : 〈l←k →r〉, an injective morphism f : l→g satisfies the dangling condition if no hyperedge in eg− fe(el) is incident to a node in fv(vl−vk). it can be shown that, given r and f , a direct derivation as in figure 3 exists if and only if f satisfies the dangling condition [hmp01]. with every derivation ∆ : g0 ⇒∗ gn a partial hypergraph morphism can be associated that tracks the items of g0 through the derivation: this morphism is undefined for all items in g0 that are removed by ∆ at some stage, and maps all other items to the corresponding items in gn. festschrift h.-j. kreowski 4 / 15 eceasst definition 1 (track morphism) given a direct derivation g ⇒ h as in figure 3, the track morphism trg⇒h : g → h is the partial hypergraph morphism defined by trg⇒h (x) = { c′(c−1(x)) if x ∈ c(d), undefined otherwise. here c : d → g and c′ : d → h are the morphisms in the lower row of figure 3 and c−1 : c(d)→ d maps each item c(x) to x. the track morphism of a derivation ∆ : g0 ⇒∗ gn is defined by tr∆ = idg0 if n = 0 and tr∆ = trg1⇒∗gn ◦trg0⇒g1 otherwise, where idg0 is the identity morphism on g0. definition 2 (hypergraph-transformation system) a hypergraph-transformation system 〈σ, r〉 consists of a signature σ and a set r of rules over σ. the system is injective if all rules in r are injective. it is a graph-transformation system if for each label l in σe, all strings in type(l) are of length two. as graph-transformation systems are special hypergraph-transformation systems, results for the latter also apply to the former. in particular, theorem 2, theorem 3 and corollary 1 below hold for graph-transformation systems, too. example 1 figure 4 shows hypergraph-transformation rules for reducing control-flow graphs (see also [plu05]). the associated signature contains a single node label • and two hyperedge seq: x y ⇒ y x while: y x ⇒ y x dec1: y x ⇒ y x dec2: y z x ⇒ y z x figure 4: hypergraph-transformation system for flow-graph reduction labels which are graphically represented by hyperedges formed as squares and rhombs. instead of using numbers to represent the attachment function, we use an arrow to point to the second attachment node of a square and define the order among the links of a rhomb to be “top-leftright”. the rules are shown in a shorthand notation where only the leftand right-hand sides are depicted, the interface and the morphisms are implicitly given by the node names x,y,z. this example will be continued as example 2, where it is shown that the system is confluent. 5 / 15 volume 26 (2010) checking graph-transformation systems for confluence 3.2 independence and confluence two direct derivations h1 ⇐r1 g ⇒r2 h2 do not interfere with each other if, roughly speaking, the intersection of the left-hand sides of r1 and r2 in g consists of common interface items. if one of the rules is not injective, however, an additional injectivity condition is needed. for i = 1, 2, let ri denote a rule 〈li ← ki → ri〉. definition 3 (independence) direct derivations h1 ⇐r1 g ⇒r2 h2 as in figure 5 are independent if there are morphisms l1 → d2 and l2 → d1 such that the following holds: commutativity: l1 → d2 → g = l1 → g and l2 → d1 → g = l2 → g. injectivity: l1 → d2 → h2 and l2 → d1 → h1 are injective. r1 k1 l1 l2 k2 r2 h1 d1 gg d2 h2 figure 5: independent direct derivations if r1 and r2 are injective, the direct derivations of figure 5 are independent if and only if the intersection of the two left-hand sides coincides with the intersection of the two interfaces. lemma 2 (independence for injective rules) let r1 and r2 be injective rules. then direct derivations h1 ⇐r1, g1 g ⇒r2, g2 h2 are independent if and only if g1(l1)∩g2(l2) ⊆ g1(k1)∩ g2(k2). to define confluence and local confluence of hypergraph-transformation systems, we slightly relax the properties of figure 1. rather than require that converging ⇒r -derivations must end in the same graph, we allow them to end in isomorphic graphs. definition 4 (confluence of 〈σ, r〉) a hypergraph-transformation system 〈σ, r〉 is confluent (locally confluent) if for all g, g1, g2 ∈ h (σ), g1 ⇐∗r g ⇒ ∗ r g2 (g1 ⇐r g ⇒r g2) implies that there are h1, h2 ∈ h (σ) such that g1 ⇒∗r h1 ∼= h2 ⇐ ∗ r g2. this definition is equivalent to that in subsection 2.1 as long as the converging derivations g1 ⇒ ∗ r h1 and g2 ⇒ ∗ r h2 do not both have length 0. this is because, by pushout properties, a ⇒r b ∼= b ′ always implies a ⇒r b ′. if the converging derivations have length 0, however, we may have g1 ∼= g2 without g1 and g2 being transformable into a common graph. it is natural to consider this still as confluence, because in (double-pushout) graph transformation the results of rule applications are unique only up to isomorphism. this view on confluence can be substantiated by considering hypergraph transformation “up to isomorphism”, that is, the transformation of isomorphism classes of hypergraphs. given a hypergraph g, denote by [g] the isomorphism class {g′ | g′ ∼= g}. for a hypergraph-transformation festschrift h.-j. kreowski 6 / 15 eceasst system 〈σ, r〉, define the relation ⇒r,∼= on isomorphism classes of hypergraphs over σ by: [g] ⇒r,∼= [h] if g ⇒r h . (this is well-defined since g ′ ∼= g ⇒r h ∼= h ′ implies g′ ⇒r h ′.) then (local) confluence in the sense of definition 4 is equivalent to (local) confluence of ⇒r,∼= in the sense of subsection 2.1, as shown by the next lemma. lemma 3 ([plu05]) a hypergraph-transformation system 〈σ, r〉 is confluent (locally confluent) if and only if the relation ⇒r,∼= is confluent (locally confluent). a system 〈σ, r〉 is terminating if the relation ⇒r is terminating. the following result follows with newman’s lemma. lemma 4 a terminating hypergraph-transformation system is confluent if and only if it is locally confluent. proof. the “only if” direction holds trivially, so assume that 〈σ, r〉 is terminating and locally confluent. then ⇒r,∼= is locally confluent by lemma 3. moreover, ⇒r,∼= is terminating because [g] ⇒r,∼= [h] if and only if g ⇒r h . thus, by lemma 1, ⇒r,∼= is confluent. using lemma 3 again shows that 〈σ, r〉 is confluent. in general, confluence is undecidable even for terminating graph-transformation systems. the precise result is as follows. theorem 1 ([plu05]) the following problem is undecidable in general: instance: an injective and terminating graph-transformation system 〈σ, r〉 such that σv is a singleton and σe and r are finite. question: is 〈σ, r〉 confluent? note that since graph-transformation systems are special hypergraph-transformation systems, the result also applies to the latter. 4 critical pairs critical pairs consist of direct derivations of minimal size that are not independent. we recall their definition from [plu93, plu05]. definition 5 (critical pair) let ri : 〈li ← ki → ri〉 be rules, for i = 1, 2. a pair of direct derivations u1 ⇐r1,g1 s ⇒r2,g2 u2 is a critical pair if (1) s = g1(l1)∪g2(l2) and (2) the steps are not independent. moreover, we require g1 6= g2 in case r1 = r2. two critical pairs u1 ⇐r1,g1 s ⇒r2,g2 u2 and u ′ 1 ⇐r1,g′1 s ′ ⇒r2,g′2 u ′ 2 are isomorphic if there is an isomorphism f : s → s′ such that for i = 1, 2, g′i = f ◦gi. in the sequel, we equate isomorphic 7 / 15 volume 26 (2010) checking graph-transformation systems for confluence critical pairs so that condition (1) guarantees that a finite set of rules has only a finite number of critical pairs. example 2 figure 6 shows the critical pairs of the hypergraph-transformation system of figure 4 and demonstrates that all pairs are strongly joinable in the sense of the next definition. (track morphisms are indicated by node names.) w y z ⇐ seq w x y z ⇒ seq w x z x z ⇐ seq x y z ⇒ seq x y w y z ⇐ while ⇒ seq x y w z z w ⇒ dec2 ⇐ wh ile x z w w y v z ⇐ dec2 w x v y z ⇒ seq w x v z w y v ⇐ dec2 w x v y ⇒ seq w x v w y v ⇐ dec2 w x v y ⇒ seq w x v figure 6: the critical pairs of the system of figure 4 festschrift h.-j. kreowski 8 / 15 eceasst given a critical pair γ : u1 ⇐ s ⇒u2, let persistγ be the subhypergraph of s consisting of all nodes v such that both trs⇒u1 (v) and trs⇒u2 (v) are defined. definition 6 (joinability) let 〈σ, r〉 be a hypergraph-transformation system. a critical pair γ : u1 ⇐ s ⇒u2 is joinable if there are derivations ui ⇒∗r xi, for i = 1, 2, and an isomorphism f : x1 → x2. moreover, γ is strongly joinable if, in addition, for each node v in persistγ, (1) trs⇒u1⇒∗x1 (v) and trs⇒u2⇒∗x2 (v) are defined and (2) fv(trs⇒u1⇒∗x1 (v)) = trs⇒u2⇒∗x2 (v). in [plu05] it is shown that a hypergraph-transformation system is locally confluent if all its critical pairs are strongly joinable. combining this result with newman’s lemma yields a sufficient condition for the confluence of terminating systems. theorem 2 ([plu05]) a terminating hypergraph-transformation system is confluent if all its critical pairs are strongly joinable. for example, the system of figure 4 is terminating since each of the rules reduces the size of a hypergraph it is applied to. thus, by theorem 2, the system is confluent. 5 coverable systems in general, by theorem 1, confluence of a terminating hypergraph-transformation system 〈σ, r〉 cannot be decided by checking whether all critical pairs are strongly joinable. for, suppose we encounter a critical pair u1 ⇐ s ⇒ u2 that is joinable but not strongly joinable, that is, there are hypergraphs x1 and x2 such that u1 ⇒ ∗ r x1 ∼= x2 ⇐ ∗ r u2 but no isomorphism x1 → x2 is compatible with the track morphisms trs⇒ui⇒∗xi . then, assuming that all other critical pairs are joinable, 〈σ, r〉 may or may not be confluent. this is demonstrated by the following example. example 3 consider the graph-transformation system 〈σ, r〉 consisting of singletons σv and σe, and the following rules: r1 : x y ⇒ x y r2 : x ⇒ x r3 : x y ⇒ x y this system is terminating as every rule application reduces the number of edges. it is also confluent since whenever h1 ⇐ ∗ r g ⇒∗ r h2, there are derivations h1 ⇒ ∗ r h′1 ∼= h′2 ⇐ ∗ r h2 where h′1 and h ′ 2 consist of |vg| nodes and either no edges (if g is loop-free) or one loop and no other edges. however, despite confluence, the critical pair 9 / 15 volume 26 (2010) checking graph-transformation systems for confluence x y ⇐ r1 x y ⇒ r1 x y is not strongly joinable because the outer graphs are normal forms1 and the isomorphism between them is not compatible with the track morphisms as required by condition (2) of definition 6. thus, we cannot report non-confluence if we encounter a joinable critical pair that is not strongly joinable. on the other hand, joinability of all critical pairs does not guarantee confluence. suppose, for instance, that we add an edge label a to σe. then all critical pairs are still joinable but confluence breaks down, as witnessed by the following counterexample: a ⇐ r1 a ⇒ r1 a this example also shows that signature extensions need not preserve confluence. in particular, hyperedge labels that do not occur in rules turn out to be crucial for ensuring that local confluence implies strong joinability of all critical pairs. given a hyperedge e in a hypergraph g, the pair 〈labg(e), mark ∗ g(attg(e))〉 is the profile of e. if r is a set of hypergraph-transformation rules, we write prof(r) for the set of all hyperedge profiles occurring in r and mark(r) for the set of all node labels occurring in r. definition 7 (gr and g⊖) let 〈σ, r〉 be a hypergraph-transformation system and g ∈ h (σ). we define subhypergraphs gr and g⊖ as follows: (1) gr consists of all hyperedges with profile in prof(r) and all nodes with label in mark(r). (2) g⊖ consists of all hyperedges in eg−egr , all attachment nodes of these hyperedges, and all nodes in vg−vgr . it follows that g = gr ∪g⊖, where gr and g⊖ may share some attachment nodes of edges in g⊖. these shared nodes cannot be removed by any rule in r, by the dangling condition for direct derivations. definition 8 (cover) given a critical pair γ of a hypergraph-transformation system 〈σ, r〉, a cover for γ is a hypergraph c ∈ h (σ) such that (1) persistγ ⊆c, (2) c⊖ = c, and (3) for every image c̃ of c, there is a unique surjective morphism c →c̃. remarks 1. by condition (2), the profiles of the hyperedges in c are distinct from those in prof(r). also, since all node labels in persistγ belong to mark(r), (1) and (2) imply that each node in persistγ is incident to some hyperedge in c. 1 a graph g is a normal form with respect to a system 〈σ, r〉 if there is no graph h such that g ⇒r h. festschrift h.-j. kreowski 10 / 15 eceasst 2. intuitively, c uniquely identifies the nodes in persistγ in that for every image c̃ of c, each node in persistγ corresponds to a unique node in c̃. moreover, the rules in r can affect c at most by merging some nodes in persistγ. 3. by condition (3), c does not possess nontrivial automorphisms. that is, the identity idc : c →c is the only isomorphism on c. example 4 consider a critical pair γ : u1 ⇐ s ⇒u2. 1. if persistγ = /0, then the empty hypergraph is a cover for γ. 2. let persistγ consist of a single node v with label m. if there is some l ∈ σe such that m ∈type(l) and 〈l, m〉 6∈prof(r), then the hypergraph c consisting of v and an hyperedge e with labc(e) = l and attc(e) = v is a cover for γ. alternatively, if mm ∈ type(l) and 〈l, mm〉 6∈ prof(r), then the graph c consisting of v and an edge e with labc(e) = l and attc(e) = vv is a cover for γ. 3. let persistγ consist of nodes v1, . . . , vn with n ≥ 2 and marks(vi) = mi, for i = 1, . . . , n. if there is l ∈σe such that m1 . . . mn ∈type(l) and 〈l, m1 . . . mn〉 6∈prof(r), then c consisting of v1, . . . , vn and an hyperedge e with labc(e) = l and attc(e) = v1 . . . vn is a cover for γ. alternatively, suppose that there are distinct labels l1, . . . , ln−1 ∈ σe such that for i = 1, . . . , n−1, mimi+1 ∈ type(li) and 〈li, mimi+1〉 6∈ prof(r). then a graph cover c for γ is given by v1, . . . , vn and edges e1, . . . , en−1 where for i = 1, . . . , n−1, labc(ei) = li and attc(ei) = vivi+1. (for instance, the critical pair discussed in example 3 can be covered in this way after the edge label a with type(a) = {••} has been added to σe.) figure 7 shows the alternative covers of example 4.3 for a critical pair with n persistent nodes. note that l1, . . . , ln−1 need to be distinct as otherwise condition (3) of definition 8 may be violated. l 1 m1 . . . . . . n mn m1 m2 l1 l2 . . . ln−1 mn figure 7: alternative covers for a critical pair with n persistent nodes definition 9 (coverable system) a hypergraph-transformation system is coverable if for each of its critical pairs there exists a cover. our main result is that for coverable systems, local confluence is equivalent to the strong joinability of all critical pairs. 11 / 15 volume 26 (2010) checking graph-transformation systems for confluence theorem 3 a coverable hypergraph-transformation system is locally confluent if and only if all its critical pairs are strongly joinable. sketch of proof. theorem 2 establishes the “if” direction. we outline the proof for the converse, which is based on extending critical pairs with their covers. consider a critical pair γ : u1 ⇐ s ⇒u2 and a cover c for γ such that s∩c = persistγ. then there are extended direct derivations û1 ⇐ ŝ ⇒ û2, where ŝ = s∪c. by local confluence, there are hypergraphs x1 and x2 such that û1 ⇒ ∗ x1 ∼= x2 ⇐ ∗ û2. the derivations ŝ ⇒ûi ⇒ ∗ xi, i = 1, 2, preserve the nodes in persistγ because the latter are incident to edges in c . hence, after taking the cover c off, one obtains restricted derivations s ⇒ui ⇒ ∗ x i, i = 1, 2, that satisfy condition (1) of definition 6. moreover, one can show that x 1 = x r 1 ∼= x r2 = x 2. restricting the morphisms trŝ⇒ûi⇒∗xi , i = 1, 2, to ŝ⊖ and x⊖i yields surjective morphisms ti : ŝ ⊖ → x⊖i . also, given an isomorphism f : x1 → x2, its restriction f ⊖ : x⊖1 → x ⊖ 2 is an isomorphism. hence both f ⊖◦t1 : ŝ ⊖ → x⊖2 and t2 : ŝ ⊖ → x⊖2 are surjective morphisms. since ŝ ⊖ = c, condition (3) of definition 8 implies f ◦t1 = t2. it then follows that condition (2) of definition 6 is satisfied. thus γ is strongly joinable. � assumption for the rest of this section, we consider hypergraph-transformation systems 〈σ, r〉 in which σv, σe and r are finite. as a consequence of theorem 3, confluence of terminating coverable systems is equivalent to the strong joinability of all critical pairs. this allows to decide confluence by testing for the latter property. corollary 1 confluence is decidable for coverable hypergraph-transformation systems that are terminating. given a terminating and coverable system, algorithm 1 checks whether all critical pairs are strongly joinable by extending critical pairs with covers and then testing for simple joinability of all “covered pairs”. by the (full) proof of theorem 3, joinability of a covered pair implies strong joinability of the underlying critical pair. given a covered pair γ̂ : û1 ⇐ ŝ ⇒ û2, one nondeterministically computes a normal form xi of ûi, for i = 1, 2, and checks whether x1 and x2 are isomorphic. if they are, then the critical pair γ underlying γ̂ is strongly joinable, otherwise a counterexample to confluence has been found. example 5 consider again the hypergraph-transformation system of example 1. suppose that its typing allows a rhomb hyperedge to have two attachment nodes and a square hyperedge to have three attachment nodes, besides the versions of rhombs and squares occurring in the rules. then each critical pair of this system can be covered and algorithm 1 determines that the system is confluent. for instance, figure 8 shows the extended version of a critical pair of figure 6 and its joining derivations. the graph-transformation system of example 3, on the other hand, is not coverable. it becomes coverable after the edge label a has been added to the signature, when algorithm 1 determines that the resulting system is non-confluent. festschrift h.-j. kreowski 12 / 15 eceasst algorithm 1 decision procedure for confluence input: a terminating and coverable hypergraph-transformation system 〈σ, r〉 and its set of critical pairs cp for all γ : u1 ⇐r1,g1 s ⇒r2,g2 u2 in cp do {let c be a cover for γ such that s∩c = persistγ} ŝ := s∪c {for i = 1, 2, let ĝi be the extension of gi to ŝ} for i = 1 to 2 do construct a derivation ŝ ⇒ri,ĝi ûi ⇒ ∗ r xi such that xi is a normal form end for if x1 6∼= x2 then return “non-confluent” end if end for return “confluent” w y z 1 2 ⇐ while ⇒ seq x y 1 2 w z ⇒ dec2 ⇐ wh ile x z 1 2 w z w 1 2 figure 8: an extended critical pair of the system of figure 4 particular classes of hypergraphand graph-transformation systems for which confluence is decidable can be obtained by specialising corollary 1 with the conditions given in example 4.3 or with similar conditions. for instance, in the case of graph transformation, another sufficient condition for terminating systems is that for each critical pair γ with persistent nodes v1, . . . , vn, there are distinct labels l1, . . . , ln ∈ σe such that for i = 1, . . . , n, marks(vi)marks(vi) ∈ type(li) and 〈li, marks(vi)marks(vi)〉 6∈ prof(r). in this case a cover can be constructed by attaching to v1, . . . , vn loops labelled with l1, . . . , ln. in the case of hypergraph transformation, a sufficient condition for the decidability of confluence (of terminating systems) can be given purely in terms of the signature σ. we call a signature σ universal if for each l ∈ σe, type(l) = σ∗v. corollary 2 confluence is decidable for terminating hypergraph-transformation systems with universal signatures. 13 / 15 volume 26 (2010) checking graph-transformation systems for confluence for, if hyperedges can have arbitrary sequences of attachment nodes, we can cover critical pairs with hyperedges that have longer attachment sequences than any hyperedges in rules by using repeated nodes in the attachment. 6 conclusion confluence is an undecidable property of terminating graphand hypergraph-transformation systems. we have identified coverable systems as a subclass that comes with a decision procedure for confluence. the class is nontrivial and properly includes all hypergraph-transformation systems with universal signatures. a topic for future work is to extend algorithm 1 such that it decides confluence for certain non-coverable systems. the idea is to add to the signature of an input system a hyperedge label whose typing allows to cover all critical pairs. one then runs the algorithm as before: if all extended pairs are joinable, one can conclude that the underlying critical pairs are strongly joinable and hence that the system is confluent. however, if a non-joinable extended pair is encountered whose underlying critical pair is joinable, then the procedure has to give up because the input system may or may not be confluent. bibliography [acps93] s. arnborg, b. courcelle, a. proskurowski, d. seese. an algebraic theory of graph reduction. journal of the acm 40(5):1134–1164, 1993. [bf01] h. l. bodlaender, b. van antwerpen-de fluiter. reduction algorithms for graphs of small treewidth. information and computation 167(2):86–119, 2001. [bkv03] m. bezem, j. w. klop, r. de vrijer (eds.). term rewriting systems. cambridge university press, 2003. [bn98] f. baader, t. nipkow. term rewriting and all that. cambridge university press, 1998. [bo93] r. v. book, f. otto. string-rewriting systems. texts and monographs in computer science. springer-verlag, 1993. [bpr04] a. bakewell, d. plump, c. runciman. specifying pointer structures by graph reduction. in applications of graph transformations with industrial relevance (agtive 2003), revised selected and invited papers. lecture notes in computer science 3062, pp. 30–44. springer-verlag, 2004. [fkz76] r. farrow, k. kennedy, l. zucconi. graph grammars and global program data flow analysis. in proc. 17th annual symposium on foundations of computer science. pp. 42–56. 1976. festschrift h.-j. kreowski 14 / 15 eceasst [gbg+06] r. geiß, g. v. batz, d. grund, s. hack, a. m. szalkowski. grgen: a fast spobased graph rewriting tool. in proc. international conference on graph transformation (icgt 2006). lecture notes in computer science 4178, pp. 383–397. springer-verlag, 2006. [hmp01] a. habel, j. müller, d. plump. double-pushout graph transformation revisited. mathematical structures in computer science 11(5):637–688, 2001. [new42] m. newman. on theories with a combinatorial definition of “equivalence”. annals of mathematics 43(2):223–243, 1942. [nnz00] u. nickel, j. niere, a. zündorf. the fujaba environment. in proc. international conference on software engineering (icse 2000). pp. 742–745. acm press, 2000. [plu93] d. plump. hypergraph rewriting: critical pairs and undecidability of confluence. in sleep et al. (eds.), term graph rewriting: theory and practice. chapter 15, pp. 201–213. john wiley, 1993. [plu05] d. plump. confluence of graph transformation revisited. in middeldorp et al. (eds.), processes, terms and cycles: steps on the road to infinity: essays dedicated to jan willem klop on the occasion of his 60th birthday. lecture notes in computer science 3838, pp. 280–308. springer-verlag, 2005. [plu09] d. plump. the graph programming language gp. in proc. algebraic informatics (cai 2009). lecture notes in computer science 5725, pp. 99–122. springer-verlag, 2009. [rs97] j. rekers, a. schürr. defining and parsing visual languages with layered graph grammars. journal of visual languages and computing 8(1):27–55, 1997. [tae04] g. taentzer. agg: a graph transformation environment for modeling and validation of software. in applications of graph transformations with industrial relevance (agtive 2003), revised selected and invited papers. lecture notes in computer science 3062, pp. 446–453. springer-verlag, 2004. 15 / 15 volume 26 (2010) introduction preliminaries relations hypergraphs graph transformation rules and derivations independence and confluence critical pairs coverable systems conclusion performance analysis of distributed and asynchronous systems using probabilistic timed actors electronic communications of the easst volume 70 (2014) proceedings of the 14th international workshop on automated verification of critical systems (avocs 2014) performance analysis of distributed and asynchronous systems using probabilistic timed actors ali jafari , ehsan khamespanah , marjan sirjani , and holger hermanns 15 pages guest editors: marieke huisman, jaco van de pol managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst performance analysis of distributed and asynchronous systems using probabilistic timed actors ali jafari 1, ehsan khamespanah 21, marjan sirjani 1, and holger hermanns 3 1 reykjavik university, school of computer science and cress 2 university of tehran, school of ece 3 university of saarland, school of computer science abstract: many real-time distributed applications exhibit probabilistic and non-deterministic behaviors. in this paper, we introduce probabilistic timed rebeca (ptrebeca) as an actor-based language for modeling probabilistic distributed real-time systems with asynchronous message passing. we propose the semantics of ptrebeca model in timed markov decision process (tmdp), the integral semantics of probabilistic timed automaton (pta) with one digital clock. to analyze ptrebeca models, we develop a tool set to automatically generate a tmdp model from a ptrebeca model in the form of the input language of prism model checker. we use prism for performance analysis of ptrebeca models against expected reachability and probabilistic reachability properties. we show the applicability of our approach using a few case studies and experimental results. keywords: probabilistic real-time system, probabilistic timed automata, timed markov decision process, probabilistic timed rebeca, model checking, performance analysis 1 introduction our society more and more relies on computing systems that are distributed, consisting of concurrently executing components which communicate asynchronously over networks. modeling and analyzing such systems is a nontrivial and intricate task, owed to their complex behavior. there is thus a need for modeling languages that match well with computational models and are supported by tools to analyze performance and dependability aspects of such systems. the actor model was proposed for modeling distributed and asynchronous systems, advocating that software systems are built by composing concurrent objects. actors are distributed, autonomous objects that interact by asynchronous messages. building on an event-driven and message-based foundation, actors provide scalability and also less error-prone concurrent models. with the growth of cloud computing, web services, networks of embedded computers, and multicore architectures, programming using the actor model has become increasingly relevant. popular actor programming languages and frameworks include erlang and the scala / akka family. many projects in industry, e.g. at google (like dart) and microsoft (like 1 / 15 volume 70 (2014) performance analysis of distributed and asynchronous systems using probabilistic timed actors asynchronous agents library), have explored the actor model. large applications such as twitter’s message queuing, image processing in ms visual studio 2010, as well as the vendetta game engine have been designed on the basis of this model. rebeca [sm01, smsb04] is an actor-based modeling language designed to enable formal verification of actor models and hence bridge the gap between formal methods and software engineering. using rebeca we can deploy a model-driven development approach with formal basis. rebeca is supported by formal verification tools and techniques which are based on the formal semantics of the language [sj11]. an extension of rebeca [aci+11] has been proposed to provide the ability of modeling and verification of distributed systems with real-time constraints. in this context, floating time transition system (ftts) were introduced to significantly reduce the state space generated for model checking of timed rebeca (trebeca) models [kss+14]. deadlock freedom and schedulability analysis of trebeca models can be performed using ftts. since its introduction, trebeca has been used in different areas. one example is in analyzing different routing algorithms and scheduling policies in noc (network on chip) designs [smms13, sms13]. another example is schedulability analysis of distributed real-time sensor network applications [mksa13], more specifically a realtime continuous sensing application for structural health monitoring in [lms13]. an ongoing project is on evaluating different dispatching policies in clouds where we have priorities and deadlines in mapreduce clusters, based on the work in [gcr+09]. in analyzing all the above mentioned applications, we observed the need for modeling probabilistic behavior. in an earlier work, prebeca is proposed as an extension of rebeca to model probabilistic systems [vk12], but prebeca does not support the time features. in this paper, we propose probabilistic timed rebeca (ptrebeca) which benefits from modeling features of trebeca and prebeca, combining the syntax of prebeca and trebeca languages. this aims at enhancing our modeling ability in order to cover more properties, by performance evaluation of probabilistic real-time actors. although the syntax of ptrebeca is a combination of trebeca and prebeca, their semantics and supporting tools are not applicable for ptrebeca. consequently, we propose a semantics to support timing, probabilistic, and non-deterministic features. to the best of our knowledge, ptrebeca is the first actor-based language which supports time, probability, and non-determinism in modeling distributed systems with asynchronous message passing. we propose ptrebeca on the basis of a study of different distributed and asynchronous applications, studied to identify what is needed for modeling and analysis of those applications, relative to different probabilistic and timed probabilistic models (discrete, continuous, stochastic) proposed in the literature. in ptrebeca, time is discrete, and discrete probability distributions are used. using probabilistic and non-deterministic assignments, the computation outcomes and network delays can become probabilistic or non-deterministic. for performance evaluation of ptrebeca models we employ probabilistic model checking, as a single computational techniques for both functional verification and performance evaluation. the benefits of combining performance evaluation with functional verification is elaborated upon in [bhhk10]. proc. avocs 2014 2 / 15 eceasst the main contributions of this paper are as follows: • modeling: ptrebeca supports the modeling of non-deterministic and probabilistic behaviors which is widely required in distributed asynchronous real-time systems. • semantics: we propose timed markov decision process (tmdp) as semantics of ptrebeca. tmdp can be regarded as the discrete time semantics of probabilistic timed automata (pta) [knps06]. • analysis: we harvest probabilistic model checking algorithms developed for pta and mdp for the analysis of probabilistic timed properties. for the analysis, we use prism [hknp06] as a back-end model checker, so as to also support expected reachability and probabilistic reachability analysis for ptrebeca models. • implementation: we present a tool developed to generate the tmdp of ptrebeca models automatically. the generated tmdp is in the form of an xml file. the xml file is converted to the input language of prism. • case studies: we present a ticket servicing and a sensor network application example to demonstrate the feasibility of the approach. advantages of ptrebeca in digital time semantics. in ptrebeca, time is discrete, and when generating state space, time can be modeled using a single integer-valued variable. the state space of a ptrebeca model is finite whenever the model represents a recurrent behavior. additionally, the time-shift equivalency approach [kss+14] can be used to bound state space when time progresses, and efficient model checking algorithms developed for untimed systems can be applied to integer-timed models [knps06, hh09]. using this approach, ptrebeca models can be verified against properties specified in pctl [knss02]. the model checker prism supports this and two other performance measures: expected reachability and probabilistic reachability properties [knps06]. this analysis trajectory can be applied to ptrebeca models because the tmdp semantics is equivalent to a diagonal-free and closed pta. a closed pta does not contain strict inequalities, a diagonal-free pta does not compare values of different clocks, which is assured by construction since the sematics has a single clock. the tmdp semantics unfolds parallel composition of ptrebeca components. there is an alternative approach for performance analysis of ptrebeca models where each component of the ptrebeca model is converted to a pta. the parallel composition of pta (of all components) represents the behavior of the ptrebeca model. this approach is explained in [jks], and prism can be used for performance analysis of the ptrebeca model through model checking the resulting pta. the apparent benefit of avoiding the state space explosion often caused by interleaving parallel composition does not manifest itself in the ptrebeca setting: in [jks], we demonstrate that the state space generated via the tmdp semantics is much smaller than the state space generated from the parallel composition approach. therefore we advocate the tmdp semantics as the basis for our mapping to prism and for performance analysis of ptrebeca models. 3 / 15 volume 70 (2014) performance analysis of distributed and asynchronous systems using probabilistic timed actors 2 probabilistic timed rebeca in this section, we introduce probabilistic timed rebeca (ptrebeca). we first present rebeca [sm01, smsb04], and then we show its extension with timing features to build trebeca [aci+11]. finally we discuss how probability and time are added to rebeca to build ptrebeca, enabling the modeling of probabilistic timed behaviors. the syntax of ptrebeca is presented in figure 1. we model a simple ticket service example to explain the modeling features of ptrebeca. rebeca. rebeca is an actor-based modelling language with formal semantics that is supported by model checking tools. a rebeca model consists of the definition of reactive classes and the instantiation part which is called main. the main part defines instances of reactive classes, called rebecs. the behavior of the instances of a reactive class is determined by its message servers. the internal state of a reactive class is represented by the valuation of its state variables. in rebeca, computation is event-driven, where messages can be seen as events. each rebec takes a message from its message queue and executes the corresponding message server. execution of a message server body takes place atomically (non-preemptively). communication takes place by asynchronous message passing, which is non-blocking for both sender and receiver. the sender rebec sends a message to the receiver rebec and continues its work. the message is put in the message queue of the receiver. the message stays in the queue until the receiver takes and serves it. although in theory we define no boundary for the queue length, in the supporting tools we always have a queue length that is defined by the user. the operational semantics of rebeca is introduced in [smsb04], to which we refer for more details. the syntax of rebeca is represented in figure 1. timed rebeca. trebeca was introduced as an extension of the rebeca language to model real-time reactive systems. just as with rebeca, the formal semantics of trebeca is defined using structural operational semantics (sos) [aci+11]. in a trebeca model, each rebec has its own local time, which can be considered as synchronized distributed clocks. methods are executed atomically, but passing of time can be modeled while executing a method. instead of a message queue for each rebec, there now exists a bag containing sent messages together with timing information, which are used to process the message in the intended order in time. different timing primitives are added to rebeca syntax to cover a variety of timing features that a modeler might need to address in a message-based, asynchronous and distributed setting. these timing primitives are delay, deadline and after, and detailed below. the syntax of timing primitives is shown in figure 1. delay: delay(t) increases the value of the local time of the respective rebec by the amount of t. deadline: r.m() deadline(t), after t units of time the message m of rebec r is not valid any more and is to be purged from the bag. proc. avocs 2014 4 / 15 eceasst model f class∗ main main f main { instancedcl∗ } instancedcl f classname rebecname(〈rebecname〉∗) : (〈literal〉∗); class f reactiveclass classname { knownrebecs vars msgsrv∗ } knownrebecs f knownrebecs { vardcl∗ } vars f statevars { vardcl∗ } vardcl f type 〈v〉+; msgsrv f msgsrv methodname(〈type v〉∗) { stmt∗ } stmt f v = e; | v =?(e〈,e〉+); | call; | i f (e) { stmt∗ } [else { stmt∗ }] call f rebecname.methodname(〈e〉∗) (a) abstract syntax of rebeca stmt f v = e; | v =?(e〈,e〉+); | call; | i f (e) { stmt∗ } [else { stmt∗ }] | delay(v); call f rebecname.methodname(〈e〉∗) [after(v)] [deadline(v)] (b) changes in the syntax of rebeca to build trebeca stmt f v = e; | v =?(e〈,e〉+); | call; | i f (e) { stmt∗ } [else { stmt∗ }] | delay(v); | v =?(ep : e〈,ep : e〉 +); (c) changes in the syntax of trebeca to build ptrebeca figure 1: (a) abstract syntax of rebeca. angle brackets 〈...〉 are used as meta parenthesis, superscript + for repetition at least once, superscript ∗ for repetition zero or more times, whereas using 〈...〉 with repetition denotes a comma separated list. brackets [...] indicates that the text within the brackets is optional. the symbol ? shows non-deterministic choice. identifiers classname, rebecname, methodname, v, literal, and type denote class name, rebec name, method name, variable, literal, and type, respectively; and e denotes an (arithmetic, boolean or nondetermistic choice) expression. (b) changes for timed rebeca. the timing primitives are added to stmt and call statements. the value of variable v in timing primitives is a natural number. (c) changes for probabilistic timed rebeca. the probabilistic assignment is added to stmt. the expression epi denotes an expression which returns probability. the symbol ? shows either non-deterministic assignment or probabilistic assignment. after: r.m() after(t), the message cannot be taken from the bag before t time units have passed. upon sending, a message is put in the message bag at the receiver together with its associated time tag and deadline tag. the time tag of a message is the value of local time 5 / 15 volume 70 (2014) performance analysis of distributed and asynchronous systems using probabilistic timed actors of the sender when the message was sent, unless the message is augmented with an after primitive. in this case the value of the argument of after is added to the value of local time of the sender to build the time tag. 2.1 probabilistic timed rebeca ptrebeca language supports the modeling and verification of real-time systems with probabilistic behaviors. the syntax of ptrebeca is a combination of prebeca and trebeca. we propose the appropriate semantics for ptrebeca to be able to model and verify probabilistic properties. in figure 1, we show the extension made to the syntax of trebeca to build ptrebeca. in a probabilistic assignment, a value is assigned to the variable with the specified probability. in probabilistic assignment, ep1 . . . epn are real values between 0 and 1, and sum up to 1. notably, by using probabilistic assignment, the value of the timing constructs (delay, after, and deadline) can also become probabilistic. different probabilistic behaviors can be modeled using ptrebeca, depending on the system under study. we present a simple ticket service system in figure 2 to illustrate how ptrebeca can be applied. each entity in the system is mapped to an actor in ptrebeca model. the ticket service model includes a customer, a ticket service, and an agent. the customer c sends a ticket request by sending the message sendrequest() to the agent a (line 27). the agent forwards the request to the ticket service ts by sending the message requestticket() (line 17). the message requestticket() has a deadline which is set non-deterministically (line 16). the ticket service issues a ticket and replies to the agent request by sending the message sendticket() (line 6). the agent sends the message getticket to the customer to complete the issuing process (line 20). the customer sends a new request after 10 or 30 units of time with probabilities of 0.25 or 0.75, respectively (lines 29-32). 1 reactiveclass ticketservice (4){ 2 knownrebecs {agent a;} 3 ticketservice () { } 4 msgsrv requestticket() { 5 delay(3) ; 6 a.sendticket() ; 7 } 8 } 9 reactiveclass agent(4){ 10 knownrebecs { 11 ticketservice ts ; 12 customer c; 13 } 14 agent(){ } 15 msgsrv sendrequest() { 16 int a = ?(4,5) ; 17 ts . requestticket () deadline(a); 18 } 19 msgsrv sendticket() { 20 c . getticket () ; 21 } 22 } 23 reactiveclass customer(4) { 24 knownrebecs {agent a;} 25 customer() {self . try () ;} 26 msgsrv try() { 27 a.sendrequest(); 28 } 29 msgsrv getticket() { 30 int b = ?(0.75:30,0.25:10) ; 31 self . try () after (b) ; 32 } 33 } 34 main { 35 agent a(ts, c) :() ; 36 ticketservice ts (a) :() ; 37 customer c(a):() ; 38 } figure 2: the model of the ticket service system. proc. avocs 2014 6 / 15 eceasst 3 semantics of probabilistic timed rebeca in this section, we define the timed markov decision process (tmdp) semantics of a ptrebeca model. formally, a tmdp is defined as follows [jls07]. definition 1 (timed markov decision process) a timed markov decision process is a tuple of (tmdp)t = (s,s0,act,→,l) includes the following components: • a set of states s with an initial state s0 ∈ s, • a set of actions act, • a timed probabilistic, non-deterministic transition relation→⊆s×act×n×dist(s) such that, for each state s ∈ s, there exists at least one tuple (s,−,−,−) ∈→, • a labelling function l : s → 2ap, where ap is the set of atomic propositions. � the transitions in a tmdp are performed in two steps: given that the current state is s, the first step is a non-deterministic selection of (s,act,d,ν) ∈→, where act denotes a possible action and d specifies the duration of the transition; in the second step, a probabilistic transition to state s′ is made with probability ν(s′). function ν ∈ dist(s) denotes a discrete probability distribution. in the following, we define some concepts for ptrebeca models before turning to the tmdp semantics of ptrebeca. definition 2 (probabilistic timed rebeca model) a probabilistic timed rebeca model m is the set of rebecs which are concurrently executing. � a computation of probabilistic timed rebeca model m takes place by execution of all rebecs defined in the model according to the sos-semantics in [aci+11]. for a probabilistic timed rebeca model m, the function o(m) returns all rebecs in the model m. definition 3 (state of a ptrebeca model in tmdp) a state of a ptrebeca model m is a tuple s = (∏ ri∈o(m) ( state(ri)×pc×rt )) ×t, where state(ri) is the state of rebec ri, t∈n is the current time of state, pc ∈n is the program counter of rebec ri, and rt ∈n is the resuming time of rebec ri. � each rebec of m has a state which consists of the values of its state variables, its local time, and its message bag. functions sv(s,ri), bag(s,ri), and now(s,ri) return the state variable valuation function, the content of message bag, and the local time of rebec ri in state s, respectively. in tmdp semantics of a ptrebeca model, the local times of rebecs have the same value. we define function now(s) to access the time in state s. the rebec program counter, pc of rebec ri specifies the statement to be executed, and function pc(s,ri) returns the value of program counter of rebec ri in state s. the rebec resuming time, rt of rebec ri determines the time when the statement of the message 7 / 15 volume 70 (2014) performance analysis of distributed and asynchronous systems using probabilistic timed actors server of rebec ri, pointed to by pc, is executed. function rt(s,ri) returns the value of resuming time of rebec ri in state s. in the initial state, the local time of all rebecs are set to zero, and the constructor of all rebecs are executed to initialize state variables and queues content. initially, for all rebecs the value of program counter and the value of resuming time are supposed to be null. definition 4 (the content of a message bag) a tuple tmsg = (msgsig,arrival, deadline) is a message where msgsig is the message content, arrival is the arrival time of the message, and deadline is the deadline of the message. the arrival time of the message is computed based on the local time of the sender and the value of “after” of send message statement. the deadline of the message is also computed based on the local time of the sender. � for tmsg∈bag(s,ri), the functions sig(tmsg), ar(tmsg), and dl(tmsg) return the msgsig, arrival, and deadline of the message tmsg, respectively. the message content msgsig consists of the message name, the sender, the receiver, and its actual parameters and is shown as “sender → receiver.msgname(parameters)”. definition 5 (possible messages) the set of messages tmsg = {tmsg |∀ri,r j ∈o(m),∀ar,dl∈ n,tmsg = (ri → r j.msgname(),ar,dl)} is the set of all possible messages which can be sent by any rebec ri to another rebec r j at any arrival time ar and deadline dl. � definition 6 (rebec enabled messages) enabled messages of a rebec are messages whose arrival time is less than the time of state s: em(s,ri) = {tmsg∈bag(s,ri)|ar(tmsg)≤now(s)}. � definition 7 (tmdp semantics of a ptrebeca model) a tmdp of ptrebeca model m is a tuple (s,s0,act,→,l), where: – s is the set of states according to definition 3, – s0 ∈ s is the initial state, – act is a set of tmsg∪{τ}∪t, where tmsg is the set of all possible messages which can be sent by any rebec to its known rebecs, τ is an internal action and t∈n is the progress of time. – →⊆ s×act×n×dist(s) is the transition relation, where (s,act,d,ν) ∈→ if and only if one of the following conditions hold for s. 1. (taking a message for execution) if in state s, there exists ri ∈o(m) such that pc(s,ri) = null and em(s,ri) ,∅: the execution of tmsg ∈ em(s,ri) results in s′ with probability ν(s′) = 1 and d=0. in this case act is equal to tmsg, tmsg is extracted from the message bag of the rebec ri, pc(s,ri) is set to the first statement of message server tmsg, and rt(s,ri) is set to now(s). proc. avocs 2014 8 / 15 eceasst 2. (internal action τ) if in state s, there exists ri ∈o(m) such that pc(s,ri) , null and rt(s,ri) = now(s): the statement of message server of ri specified by pc(s,ri) is executed and one of the following cases may occur based on the statement execution: (a) the statement is an ordinary statement: the execution of statement may change the value of some state variables of the rebec ri or induce sending a message to a rebec. then, pc(s,ri) is increased by one, the act is τ, d=0, and the execution of τ results in s′ with probability ν(s′) = 1. (b) the statement is a non-deterministic assignment: the execution of nondeterministic assignment a =?(v1,...,vn) results in n different transitions from s to states s′1,s ′ 2,...,s ′ n, where a = vi in state s ′ i . for each transition, the act is τ, d=0, and the execution of τ results in s′i (1 ≤ i ≤ n) with probability ν(s′i ) = 1. (c) the statement is a probabilistic assignment: the execution of probabilistic assignment a =?(p1 : v1,...,pn : vn) results in a transition from s to states s′1,s ′ 2,...,s ′ n, where a = vi in state s ′ i . the act is τ, d=0, and the execution of τ results in s′i (1 ≤ i ≤ n) with probability ν(s ′ i ) = pi. (d) the statement is a delay statement with parameter t ∈n: the execution of the delay statement does not change pc(s,ri) (because the execution of delay statement is not yet complete), and rt(s,ri) is set to now(s) + t. (note: the value of pc(s,ri) will change to the next statement after completing the execution of the delay which can be seen in item 3.) the act is τ, d=0, and the execution of τ results in s′ with probability ν(s′) = 1. when the last statement of the message server of ri is executed, the pc(s,ri) is set to null. 3. (progress of time) if in state s, none of the aforementioned conditions in items 1 and 2 hold: this means @ri ∈o(m),((pc(s,ri) = null∧em(s,ri) ,∅)∨(pc(s,ri) , null ∧ rt(s,ri) = now(s))). in this case, now(s) is increased by the minimum amount of t1 ∈n such that one of the aforementioned conditions becomes true. if pc(s,ri) , null and rt(s,ri) = now(s) (the current value of pc(s,ri) points at a delay statement), pc(s,ri) is increased by one. the act is set to time, d = t1, and the execution of action time results in s′ with probability ν(s′) = 1. – a labelling function l : s → 2ap. when more than one transition is enabled in state s, a non-deterministic selection is made. � 4 analysis of probabilistic timed rebeca and experimental results we have developed a tool set [reb] in order to generate the tmdp semantics from ptrebeca models. this tmdp semantics can be exported to prism as a single mdp module 9 / 15 volume 70 (2014) performance analysis of distributed and asynchronous systems using probabilistic timed actors with one integer-valued variable modeling the passage of time. in [jks], we show the prism code generated for the ticket service example presented in figure 2. using a dedicated time action and the ability of assigning rewards to transitions in prism, we can analyze expected-time reachability and time-bounded probabilistic reachability properties. in ptrebeca models, the capacity of message bags is bounded. the number of states in ptrebeca model can be finitely represented when the system shows recurrent behavior. we also use the time-shift equivalence approach proposed in [kss+14] to avoid state space explosion otherwise induced by time progress. in this approach, two tmdp states s and t (in the sense of definition 3) are time-shift equivalent if the values of all variables except timing variables, i.e. local time, arrival time, deadline, in states s and t are identical. therefore, the two states can be identified by shifting time. the prism modeling language is a state-based language while ptrebeca language benefits from high-level data structures and constructs which arguably makes modeling easier. prism models are thus closer to the underlying probabilistic models and therefore we bridge to prism on the semantics level. 4.1 experimental results in this section, we present an example demonstrating the applicability of the proposed approach for performance analysis of asynchronous systems. we also examine different versions of the ticket service model shown in figure 2, which is detailed in [jks]. sensor network. the sensor network model is shown in [jks]. there is a lab environment in which the toxic level changes periodically after an amount of time, specified by the value of variable changingperiod. the environment is safe at first. the toxic level is changed to a dangerous level with a probability of 0.02. if the toxic level of the environment reaches a dangerous level, the scientist, working inside the lab, will die after a specified amount of time, specified by the value of variable scientistdeadline. one sensor in the lab environment is measuring the toxic level of the lab. the measured information is sent periodically by the sensor to the administrator. a sensor may fail to report the measurement to the administrator with a probability of 0.01. if the toxic level reported by the sensor reaches a predefined dangerous level, the administrator sends a message to the scientist, who is assumed to be working in the environment, to inform him to leave the lab and go to a safe place. the administrator waits for a while for an acknowledgement from the scientist. if the acknowledgement is not received by the admin on time, the admin orders a rescue team to get hold of the scientist. in this model the value of probabilities are small enough to let the model converge to the optimum value; and consequently show the real behavior. since the model includes non-deterministic behaviors, the model checker computes the maximum and the minimum probabilities over all paths in the generated state space. figure 3(a) shows the maximum and the minimum probabilities of the scientist death when the value of variable checkingperiod changes. if the sensor checks the environment with a high frequency, i.e. the value of variable checkingperiod is low, the probability proc. avocs 2014 10 / 15 eceasst sensorfreq pmax pmin sensorfreq pmax pmin 1 0.006519 0.005525 1 0.7259 0.7232 2 0.5675 0.5654 3 0.4668 0.4651 4 0.54 0.3957 2 0.003983 0.003547 admincheck =1 5 1 0.3422 6 0.6378 0.4162 7 0.6833 0.4787 8 0.7096 0.5293 9 0.7434 0.5711 5 10 1 0.6096 12 0.7934 0.662 14 0.8231 0.7041 killafter=10 15 1 0.724 16 0.8308 0.7374 17 0.847 0.7513 18 0.8505 0.7639 20 1 0.7876 22 0.8788 0.804 25 1 0.828 0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0 1 2 3 4 5 6 pmax pmin 0.2 0.4 0.6 0.8 1 pr ob ab ili ty 0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 0 1 2 3 4 5 6 0 0.2 0.4 0 2 4 6 8 10 12 14 16 18 20 22 24 pr ob ab ili ty period in which the sensor checks the environment pmax pmin (a) the value of variable scientistdeadline is 10. sensorfreq pmax pmin 1 0.7259 0.7232 3 0.4668 0.4651 5 0.3488 0.3422 7 0.2763 0.2753 10 0.6016 0.2112 12 0.4501 0.3172 15 0.7184 0.4424 17 0.5944 0.4975 20 0.7832 0.5708 22 0.6798 0.6041 25 0.8245 0.6525 killafter=12 0 0.2 0.4 0.6 0.8 1 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 pr ob ab ili ty period in which the sensor checks the environment pmax pmin period in which the sensor checks the environment pmax pmin (b) the value of variable scientistdeadline is 12. figure 3: the maximum and minimum probabilities that the scientist eventually dies, when the sensor frequency changes. of sensor failure will increase, resulting in high probability of the scientist death. for example, when the sensor checks the environment once every units of time, the environment is checked five times before the first change in the environment. therefore, the cost of the sensor use and consequently the probability of sensor failure increases. when the sensor frequency is low, the environment changes cannot be detected on time; resulting in a high probability of the scientist death. there is an optimum value for the variable checkingperiod, i.e. sensor frequency, which is five according to the obtained results reported in figure 3(a). as the results show, at times 5, 10, 15, 20, and 25, the maximum probability of the scientist death equals one. at these times because of concurrency between time related behaviors in the system, there is a scenario in which the dangerous level is reported too late to the administrator and the scientist will die. at these times, the execution sequence of the following messages is important and causes the special behavior: (1) checking the sensor value by the administrator (it is repeated periodically after 5 units of time), (2) changing the toxic level of the environment to a dangerous level (period is 5 units of time), (3) checking the environment by the sensor (figure 3(a) shows the probability of the scientist death for different value of this period), and (4) sending a message die to the scientist (after 10 units of time) when the environment is dangerous. this experiment shows that the exceptional timing behavior can be revealed by probabilistic performance evaluation. it is not possible to find this special behavior by the tools and techniques developed for trebeca language at this moment. in figure 3(b), the value of variable scientistdeadline equals 12; the scientist has more time to be saved before being killed by the toxic environment. the maximum probability of the scientist death is not equal to one at times 5, 10, 15, 20, and 25, but because of concurrency between time related behaviors, there is a scenario in which the dangerous level is reported too late and consequently the maximum probability of the scientist death increases. there is an optimum value for the variable checkingperiod, i.e. sensor frequency, which is ten in this experiment. 11 / 15 volume 70 (2014) performance analysis of distributed and asynchronous systems using probabilistic timed actors 5 related work prism. prism is a well-established and powerful model checker with a state-based input language. an input model of prism is composed of a number of modules which can share variables and interact with each other. prism is well equipped with theories and reduction techniques [hknp06], but lacks high-level programming constructs like loops, and primary data structures like arrays, which makes modeling hard. in contrast, ptrebeca provides high-level object-based programming features and asynchronous message passing, which makes modeling easier. so, in modeling we benefit from capabilities of ptrebeca, and in analysis we use the capabilities of the prism model checker. modest. modest [hhhk13] is a high-level and convenient language for describing stochastic timed and hybrid systems. it supports loop constructs, structs and arrays, exception handling, and other advanced programming constructs. for the probabilistic timed fragment of modest, model checking can be performed using a digital time semantics [hh09] or by a direct mapping to timed automata. both approaches use prism as a backend model checker. in contrast to modest, ptrebeca supports object-based programming features, and follows the asynchronous message passing paradigm of actors, while modest relies on synchronous message passing. otherwise, the spirit, especially with respect to the analysis via prism, is similar. probmela. probmela is a probabilistic version of promela [hol97]. the operational semantics of probmela is defined as an mdp [bcg04]. in [cb06], probmela is used as input language for the mdp model checker liquor which provides qualitative and quantitative analysis of ltl properties. there is also a mapping from probmela to the prism language, which makes probabilistic analysis possible [cbgp08]. ptrebeca is an event-driven and actor-based language whereas probmela is processbased. both languages are asynchonous in spirit. we proposed a semantics of ptrebeca as tmdp (or pta with digital clocks), enabling the analysis of timing and probabilistic behaviors of asynchronous systems. pmaude. pmaude extends standard rewriting theories of maude with probability [ams06]. there is an actor extension of probabilistic rewriting theories for pmaude which removes non-determinism. a statistical technique is provided to analyze quantitative aspects of systems using discrete-event simulation. in comparison with pmaude, modeling asynchronous systems is more straightforward in ptrebeca language as it is an actor-based language. also ptrebeca supports non-determinism in the model and there is no need to resolve it by assuming distribution on different choices of non-determinism. it is because of the probabilistic model checking facilities which are provided by prism. proc. avocs 2014 12 / 15 eceasst summary. in pmaude, probability distribution functions (rates and stochastic functions) are provided for modeling probabilistic behaviors. also, pmaude implements stochastic continuous-time. in probmela, probabilities are drawn from discrete probability distributions, and passage of time can be modeled using a timer process. modest enables a direct high-level modelling of pta and more complex models. in all aforementioned languages, non-deterministic behavior can be modeled. in analysis, pmaude resolves non-determinism, and uses statistical model checking to verify properties which results in inaccurate results. in the analysis of probmela and modest, non-determinism is not resolved. modest also provides the option of a digital clock semantics, which, just like we do here, is handed over to prism for model checking. our focus in designing ptrebeca has been on ease of modeling and efficiency of analysis mainly for asynchronous applications. to this end, we use discrete time model and discrete probability distributions. these decisions showed to be effective in modeling different applications that we have targeted. moreover, resolving non-determinism by a discrete probability distribution generates inaccurate estimations, so, we avoided that by choosing tmdp as the semantics of ptrebeca. we were able to formalize the advance of time in our model using a single integer-valued variable. the language design of ptrebeca and its analysis approach is closest to the modest approach, apart from the latter not being object-oriented and not being asynchronous by design. 6 conclusion in this paper we introduced the syntax and semantics of probabilistic timed rebeca (ptrebeca) for modeling and verification of probabilistic real-time actor systems. as the model of time in ptrebeca is discrete, we decided to use discrete-time tmdp with an integer-valued time variable for the semantics of ptrebeca. ptrebeca models can thus be analyzed against pctl, expected reachability, and probabilistic reachability properties. our proposed approach is implemented as a part of afra toolset [reb]. prism is used as a back-end model checker for analyzing ptrebeca models. this is similar to the approach put forward for modest, and we are therefore considering a direct connection between ptrebeca and modest. in addition to the benefits of using tmdp semantics for analysis of ptrebeca models, our technique is based on the actor model of computation where the interaction is solely based on asynchronous message passing between the components. hence, the proposed semantics is general enough to be applied to similar computation models where there is message-driven communication and autonomous objects as units of concurrency, and there exists discrete probabilistic behaviors in the model such as agent-based systems. acknowledgement the work on this paper was supported by the project “timed asynchronous reactive objects in distributed systems: taro” (nr. 110020021) of the icelandic research fund. 13 / 15 volume 70 (2014) performance analysis of distributed and asynchronous systems using probabilistic timed actors bibliography [aci+11] l. aceto, m. cimini, a. ingólfsdóttir, a. h. reynisson, s. h. sigurdarson, m. sirjani. modelling and simulation of asynchronous real-time systems using timed rebeca. in foclasa’11. pp. 1–19. 2011. [ams06] g. agha, j. meseguer, k. sen. pmaude: rewrite-based specification language for probabilistic object systems. electronic notes in theoretical computer science (entcs) 153(2):213–239, may 2006. [bcg04] c. baier, f. ciesinski, m. groesser. probmela: a modeling language for communicating probabilistic processes. 2004. [bhhk10] c. baier, b. r. haverkort, h. hermanns, j.-p. katoen. performance evaluation and model checking join forces. commun. acm 53(9):76–85, sept. 2010. [cb06] f. ciesinski, c. baier. liquor: a tool for qualitative and quantitative linear time analysis of reactive systems. in proc. 3rd international conference on quantitative evaluation of systems (qest’06). pp. 131–132. ieee cs press, 2006. [cbgp08] f. ciesinski, c. baier, m. groesser, d. parker. generating compact mtbddrepresentations from probmela specifications. in proceedings of the 15th international workshop on model checking software. spin ’08, pp. 60–76. 2008. [gcr+09] i. gupta, b. cho, m. r. rahman, t. chajed, c. l. abad, n. roberts, p. lin. natjam: eviction policies for supporting priorities and deadlines in mapreduce clusters. 2009. [hh09] a. hartmanns, h. hermanns. a modest approach to checking probabilistic timed automata. in qest. pp. 187–196. ieee computer society, 2009. [hhhk13] e. m. hahn, a. hartmanns, h. hermanns, j.-p. katoen. a compositional modelling and analysis framework for stochastic hybrid systems. formal methods in system design 43(2):191–232, 2013. [hknp06] a. hinton, m. z. kwiatkowska, g. norman, d. parker. prism: a tool for automatic verification of probabilistic systems. in proceedings of 12th international conference on tools and algorithms for the construction and analysis of systems (tacas’06). lecture notes in computer science, pp. 441–444. springer-verlag, 2006. [hol97] g. j. holzmann. the model checker spin. software engineering 23(5):279– 295, 1997. [jks] a. jafari, e. khamespanah, m. sirjani. performance analysis of distributed and asynchronous systems using probabilistic timed actors (technical report). http://rebeca.cs.ru.is/files/documents/ptr2pta.pdf. proc. avocs 2014 14 / 15 eceasst [jls07] m. jurdziński, f. laroussinie, j. sproston. model checking probabilistic timed automata with one or two clocks. in proceedings of the 13th international conference on tools and algorithms for the construction and analysis of systems. tacas’07, pp. 170–184. 2007. [knps06] m. kwiatkowska, g. norman, d. parker, j. sproston. performance analysis of probabilistic timed automata using digital clocks. formal methods in system design 29:33–78, 2006. [knss02] m. kwiatkowska, g. norman, r. segala, j. sproston. automatic verification of real-time systems with discrete probability distributions. theor. comput. sci. 282(1):101–150, june 2002. [kss+14] e. khamespanah, z. sabahi kaviani, m. sirjani, r. khosravi, m.-j. izadi. timed rebeca schedulability and deadlock freedom analysis using bounded floating-time transition system. in journal of science of computer programming. 2014. [lms13] l. linderman, k. mechitov, b. f. spencer. tinyos-based real-time wireless data acquisition framework for structural health monitoring and control. structural control and health monitoring 20(6):10071020, june 2013. [mksa13] k. a. mechitov, e. khamespanah, m. sirjani, g. agha. a model checking approach for schedulability analysis of distributed real-time sensor network applications. in submitted for publication. 2013. [reb] rebeca. rebeca homepage. http://www.rebeca-lang.org. [sj11] m. sirjani, m. m. jaghoori. ten years of analyzing actors: rebeca experience. in formal modeling: actors, open systems, biological systems. pp. 20–56. 2011. [sm01] m. sirjani, a. movaghar. an actor-based model for formal modelling of reactive systems: rebeca. technical report cs-tr-80-01, tehran, iran, 2001. [smms13] z. sharifi, m. mosaffa, s. mohammadi, m. sirjani. functional and performance analysis of network-on-chips using actor-based modeling and formal verification. in proceedings of avocs’13. 2013. [sms13] z. sharifi, s. mohammadi, m. sirjani. comparison of noc routing algorithms using formal methods. in proceedings of pdpta’13. 2013. [smsb04] m. sirjani, a. movaghar, a. shali, f. de boer. modeling and verification of reactive systems using rebeca. fundamenta informatica 63(4):385–410, dec. 2004. [vk12] m. varshosaz, r. khosravi. modeling and verification of probabilistic actor systems using prebeca. in proceedings of the 14th international conference on formal engineering methods. icfem’12, pp. 135–150. 2012. 15 / 15 volume 70 (2014) introduction probabilistic timed rebeca probabilistic timed rebeca semantics of probabilistic timed rebeca analysis of probabilistic timed rebeca and experimental results experimental results related work conclusion development of rabin's choice coordination algorithm in event-b electronic communications of the easst volume 35 (2010) proceedings of the 10th international workshop on automated verification of critical systems (avocs 2010) development of rabin’s choice coordination algorithm in event-b emre yilmaz and thai son hoang 15 pages guest editors: jens bendisposto, michael leuschel, markus roggenbach managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst development of rabin’s choice coordination algorithm in event-b emre yilmaz1 and thai son hoang2∗ 1 yilmaze@ethz.ch 2 htson@inf.ethz.ch department of computer science, eth zurich, switzerland abstract: the paper reports our investigation on tool support for the integration of qualitative probabilistic reasoning into event-b. in the process, we formalise a nontrivial algorithm, namely rabin’s choice coordination. our correctness reasoning is a combination of termination proofs in terms of probabilistic convergence and standard invariant techniques. moreover, we describe how qualitative probabilistic reasoning can be maintained during refinement. keywords: event-b, qualitative reasoning, probabilistic termination, tool support, rabin’s choice coordination. 1 introduction in some systems, termination cannot be guaranteed for certain. instead, a slightly weaker property is mostly appropriate: termination with probability one. an example having such a property is when tossing a fair coin, eventually heads will come up. in other words, the coin will turn up heads with probability one. there are many applications in distributed systems of such a “coin flip” and in particular for symmetry-breaking protocols [iee00, rab82]. this kind of qualitative probability reasoning has been integrated into event-b [hh07]. besides the standard non-deterministic actions in event-b, a new kind of actions is added, namely, probabilistic actions where the probability for each possible alternative is neither 0 nor 1 (i.e. “proper” [mm05]). most of the time, actions of this type behave identically to the non-deterministic actions, except when reasoning about their termination: they are interpreted angelically (as opposed to demonic non-determinism). the result is a practical method for handling qualitative reasoning that generates only proof obligations in the standard first-order logic of event-b. in particular, the exact probability for different alternatives can be left unspecified. we continue our research on tool support for this extension of event-b. in the process, we formalise a non-trivial algorithm, namely, rabin’s choice coordination [rab82]. the reasoning about the probabilistic termination of this algorithm is non-trivial, involving a lexicographic variant which needs to be carefully formalised and mechanically proved to have adequate assurance of the correctness of the algorithm. the case study illustrates the scalability of the approach for reasoning qualitatively in event-b: it can be applied to more complex systems than just “coin tossing” examples. ∗ this author is supported by deploy — an european commission information and communication technologies fp7 project (http://www.deploy-project.eu) 1 / 15 volume 35 (2010) mailto:yilmaze@ethz.ch mailto:htson@inf.ethz.ch http://www.deploy-project.eu development of rabin’s choice coordination algorithm in event-b our development comprises several refinements and includes reasoning about both standard and probabilistic termination, and deadlock-freedom. our approach is to first establish the model of the system without any termination arguments, then having several refinement layers dedicated to proving convergence properties of events according to a lexicographic variant. essentially, with this style of development, our probabilistic termination arguments are preserved with refinement. our contribution hence is a methodology for proving almost-certain termination. the main novelty is the restrictions on refinement and additional condition on variants so that probabilistic termination property can be established. we use rabin’s choice coordination to illustrate our approach and extend the rodin platform in order to support our reasoning. the rest of the paper is structured as follows. in section 2 we give a brief overview of the event-b modelling method, focusing on proofs of convergence and qualitative reasoning. section 3 is dedicated to the formalisation of rabin’s choice coordination algorithm. we present the summary of our tool support in section 4. finally, we draw conclusions in section 5. 2 qualitative reasoning in event-b event-b [abr10] is a modelling method for formalising and developing systems whose components can be modeled as discrete transition systems. we will not describe in detail the semantics of event-b here. instead we just describe some of the proof obligations that are important for our development. event-b models are organised in terms of the two basic constructs: contexts and machines. contexts specify the static part of a model whereas machines specify the dynamic part. contexts may contain carrier sets, constants and axioms. carrier sets are similar to types. axioms constrain carrier sets and constants. we give an overview about machines in section 2.1, then about machine refinement in section 2.2 and finally about convergent, and qualitative reasoning in section 2.3. 2.1 machines machines specify behavioural properties of event-b models. machines may contain variables, invariants, events, and variants. variables v define the state of a machine and are constrained by invariants i(v). possible state changes are described by events. events an event can be represented by the term “any t where g(t,v) then s(t,v) end”, where t stands for the event’s parameters, g(t,v) is the guard (the conjunction of one or more predicates) and s(t,v) is the action. the guard states the necessary condition under which an event may occur, and the action describes how the state variables evolve when the event occurs. we use the short form “when g(v) then s(v) end” when the event does not have any parameters, and we write “begin s(v) end” when, in addition, the event’s guard equals true. a dedicated event of the last form is used for the initialisation event (usually represented as init). the action of an event is composed of one or more assignments of the form “x := e(t,v)” or “x :∈ e(t,v)” or “x :| q(t,v,x′)”, where x are some of the variables contained in v, e(t,v) proc. avocs 2010 2 / 15 eceasst is an expression, and q(t,v,x′) is a predicate. note that the variables on the left-hand side of the assignments contained in the action must be disjoint. the last form refers to q which is a beforeafter predicate relating the values x (before the action) and x′ (afterwards). all assignments of an action s(t,v) occur simultaneously, which is expressed by conjoining together their before-after predicates. hence each event corresponding to a before-after predicate s(t,v,v′) established by conjoining all before-after predicates associated with each assignment and y = y′, where y are unchanged variables. proof obligations event-b defines proof obligations, which must be proved to show that machines have their specified properties. we describe below the proof obligation for invariant preservation. formal definitions of all proof obligations are given in [abr10]. invariant preservation states that invariants are maintained whenever variables change their values. obviously, this does not hold a priori for any combination of events and invariants and therefore must be proved. for each event, we must prove that the invariants i are re-established after the event is carried out. more precisely, under the assumption of the invariants i and the event’s guard g, we must prove that the invariants still hold in any possible state after the event’s execution given by the before-after predicate s(t,v,v′). similar proof obligations are associated with a machine’s initialisation event. the only difference is that there is no assumption that the invariants hold. for brevity, we do not treat initialisation differently from ordinary machine events. the required modifications of the associated proof obligations are straightforward. note that in practice, by the property of conjunctivity, we can prove the preservation of each invariant separately. 2.2 machine refinement machine refinement is a mechanism for introducing details about the dynamic properties of a model [abr10]. for more details on the theory of refinement, we refer the reader to the action system formalism [bac89], which has inspired the development of event-b. here we sketch some central proof obligations for machine refinement which are related to our development in section 3. a machine cm can refine another machine am. we refer to am as the abstract machine and cm as the concrete machine. the states of the abstract machine are related to the states of the concrete machine by gluing invariants j(v,w), where v are the variables of the abstract machine and w are the variables of the concrete machine. typically, the gluing invariants are declared as invariants of cm and also contain the local concrete invariants constraining only w. each event ea of the abstract machine is refined by a concrete event ec (later we will relax this one-to-one constraint). for simplicity, we assume that both events have the same parameters t. let the abstract event ea and concrete event ec be as follows. ea =̂ any t where g(t,v) then s(t,v) end (1) ec =̂ any t where h(t,w) then t (t,w) end (2) somewhat simplifying, we can say that ec refines ea if the guard of ec is stronger than the guard 3 / 15 volume 35 (2010) development of rabin’s choice coordination algorithm in event-b of ea, and the gluing invariants j(v,w) establish a simulation of ec by ea. i(v),j(v,w),h(t,w) ` g(t,v) (grd) i(v),j(v,w),h(t,w),t(t,w,w′) ` ∃v′·s(t,v,v′)∧j(v′,w′) (sim) a special case of refinement (called superposition refinement) is when v is kept in the refinement, i.e. v ⊆ w. in particular, if the actions are deterministic for both abstract and concrete events, and the expressions assigned to v are equivalent, the proof obligation sim reduces to just proving that the gluing invariants j(v′,w′) are re-established. our reasoning in the later sections will often use this fact. in the course of refinement, new events are often introduced into a model. new events must be proved to refine the implicit abstract event skip, which does nothing. the one-to-one correspondence between the abstract and concrete events can be relaxed. when an abstract event ea is refined by more than one concrete events ec, we say that the abstract event ae is split and prove that each concrete ec is a valid refinement of the abstract event. conversely, several abstract events ae can be refined by one concrete ec. we say that these abstract events are merged together. 2.3 convergence and qualitative reasoning at any stage, it may be proved that some set of events does not collectively diverge; we then call these events convergent events. in other words, convergent events cannot take control forever and hence one of the other events eventually occurs. to prove this, one gives a variant v , which maps a state to a finite set. one then proves that each convergent event strictly decreases v . since the variant maps a state to a finite set, v induces a well-founded ordering on system states given by strict subset-inclusion of their images under v . the corresponding proof obligation is as follows. i(v),g(t,v) ` ∀v′·s(t,v,v′)⇒v (v′)⊂v (v) (var) as explained above, we assume that the variant is a set expression. in event-b, a variant can also be a natural number expression with the normal decreasing order “<” [abr10]. later we will use both types of variants for our development. note that in some cases the convergence of some events cannot be immediately shown, but only in a later refinement. in this case, their convergence is anticipated and we must prove that v (v′)⊆v (v), that is, these anticipated events do not enlarge the variant. the convergence attribute of an event is denoted by the keyword status with three possible values: convergent, anticipated, or ordinary (for events which are not necessarily convergent). effectively, the use of anticipated events allows us to construct a lexicographic variant relying on the fact that the standard convergence properties are preserved by refinement. in some cases, termination is not definite but almost certain, i.e., the probability of termination is 1. an example is when flipping a coin, heads will eventually appear with probability one. this type of reasoning has been introduced into event-b in [hh07]. according to this work, the action of an event can be either probabilistic or non-deterministic (but not both). with respect to most proof obligations, a probabilistic action is treated identically as a non-deterministic action. however, it behaves angelically with respect to var: an event with a probabilistic action may proc. avocs 2010 4 / 15 eceasst (as in contrast to must) decrease the variant v (v). the new proof obligation rule for probabilistic events is as follows. i(v),g(t,v) ` ∃v′·s(t,v,v′)∧v (v′)⊂v (v) (prv) note that the rule that we showed here is for an abstract convergent event. for a concrete event, the corresponding proof obligation rule is similar with the exception that one can assume that both abstract and gluing invariants hold. even though probabilistically convergent events can increase the variant v (v), it is required that v (v) is bounded above [hh07]. the upper bound b is a constant1 and the proof obligation bnd, which needs to be discharged for all anticipated events and convergent events (both standard and probabilistic), is i(v),g(t,v) ` v (v)⊆ b . (bnd) finally, it is required that the possible alternatives for a probabilistic action are finite. i(v),g(t,v) ` f inite({v′ | s(t,v,v′)}) (finact) since events with probabilistic actions behave almost identically to standard non-deterministic events (with the exception of convergence proof obligations), we do not introduce additional syntax to event-b. instead, we have an additional value for the convergence attribute of an event, namely probabilistic and treat such events differently when generating proof obligations. a very important point is that in the same refinement, there could be some anticipated events, some (standard) convergent events, and some probabilistically convergent events. however, regardless of their status, they have to use the same variant. 2.4 our contribution the earlier work in [hh07] does not address the refinement of probabilistic events. whereas the standard convergence argument is preserved by refinement, the probabilistic convergence argument is not maintained since a “good” choice for termination could be accidentally removed. forbidding refinement all together after proving probabilistic convergence is no option for us, since we want to construct a lexicographic variant using refinement. as a result we restrict our refinement such that the event and variable system must remain unchanged after proving probabilistic convergence. the only allowed modifications are additional invariants. note that event splitting by having additional guards, e.g. in section 3.2.4 and event merging satisfy this condition, i.e. they preserve the probabilistic convergence proofs. this is also the key aspect of our approach for proving probabilistic termination of an algorithm, with some additional features as follows. • to prove that the algorithm eventually establishes certain conditions, we follow the approach in [hkba09] for reasoning about liveness properties, with the correctness argument combining appropriate proofs of event convergence (both standard and probabilistic) and deadlock freedom. more details on this approach are described in section 3.2.1. 1 in general, this could be a non-decreasing function on the state. 5 / 15 volume 35 (2010) development of rabin’s choice coordination algorithm in event-b • we first establish the full algorithm with several anticipated events, before converting them to convergent or probabilistic events (taking into account the above restriction on refinement). the use of anticipated events is first suggested in [hh07]. • finally, with the use of anticipated events in early refinements and later converting them to either convergent or probabilistic events, we prove that the set of events terminates probabilistically. this is the reason why we need to prove that the combining lexicographic variant is bounded above. as a result, we require that not only the variants concerning probabilistic events, but all other variants need to be bounded above. we have used the rodin platform [abh+10] for our formal development. this is an industrialstrength tool for creating and analysing event-b models. it includes a proof-obligation generator and support for interactive and semi-automated theorem proving. we have extended the tool for specifying probabilistically convergent events and generating appropriate proof obligations. the new obligations are still in first-order logic, hence we can reuse the proof support of the rodin platform without requiring any additional extension. more detailed discussions on the tool support are in section 4. 3 rabin’s choice coordination algorithm rabin’s choice coordination algorithm as explained in [rab82] is an example of the use of probability for symmetry breaking. the choice coordination is a problem where processes p1,...,pn must reach a common choice out of k alternatives a1,...,ak. it does not matter which alternative will be chosen at the end. the protocol uses k shared variables v1,...,vk, one for each alternative. a process pj arriving at ai can access and modify vi in one step without any interruption from other processes. the algorithm proposed by rabin terminates with probability 1. our second contribution is the formalisation of the algorithm in event-b and the proofs of the associated obligations using the rodin platform. 3.1 description of the problem and algorithm we will look at a simplified version of the problem and the corresponding algorithm as described by morgan et. al. [mm05]. instead of n processes and k alternatives we have n tourists and 2 destinations (which we call lef t and right accordingly). we also distinguish the inside and outside for each destination. env 1 each tourist can be in one of the following locations: inside-left, inside-right, outsideleft, and outside-right. each tourist can move between the two outside locations, i.e. from outside-left to outside-right and vice versa. furthermore, a tourist can move from the outside to the inside of the same place, e.g. from outside-left to inside-left. env 2 a tourist can move between the two outside locations. env 3 a tourist can move from the outside to the inside of the same place. proc. avocs 2010 6 / 15 eceasst other movements of the tourists are forbidden. in particular if a tourist enters an inside place, he can no longer change his location. env 4 a tourist in an inside place cannot change his location. the purpose of the algorithm is to have all tourists to reach a common decision of entering the same place, without communicating directly with each other. fun 5 eventually, all tourists enter the same place. rabin’s choice coordination algorithm as described by morgan et. al. in [mm05] is as follows. each tourist carries a notepad and he can write a number on it. moreover, there are two noticeboards at the outside-left and outside-right. alg 6 each tourist has a notepad on which he can write a number. alg 7 there are noticeboards at the outside-left and outside-right. in the beginning, number 0 is written on all tourist notepads and on the two noticeboards. initially, each tourist independently chooses the leftor right-place and goes to the outside location of that place (i.e. outside-left or outside-right). afterwards, a tourist at an outside location can alternate between different locations according to the following algorithm. alg 8 an outside tourist alternates between different locations as follows. • if there is any tourist inside, he enters this place. • otherwise, he compares the number n on his notepad with the number n on the notice board. – if n < n, the tourist goes inside. – if n > n, the tourist replaces n with n on his notepad and goes to the outside of other place. – if n = n, the tourist tosses a coin. if the coin comes up head, the tourist sets n′ to n + 2. otherwise, he sets n′ to the conjugate2 of n + 2. then, he writes n′ on the notice board and his notepad and goes to the outside of the other place. we are going to formalise this version of the problem, algorithm, and proofs from morgan et. al. [mm05] in the next section. note that we make an assumption about the tourist capability: he/she from an outside location can “look” inside of the same place (he still cannot see the other place, neither inside nor outside). a more realistic implementation as described in [mm05] is to have the first tourist entering an inside location to write some special note e.g. “here”, on the notice board. however, this will complicate our reasoning; hence we make this simplification. 3.2 formal development in this section, we present the formal development of rabin’s choice coordination algorithm in event-b3. 2 the conjugate of a number n (denoted by n) is defined to be n + 1 if n is even and n−1 if n is odd. 3 the archive of the development can be found on-line at http://deploy-eprints.ecs.soton.ac.uk/232/. 7 / 15 volume 35 (2010) http://deploy-eprints.ecs.soton.ac.uk/232/ development of rabin’s choice coordination algorithm in event-b 3.2.1 initial model. the sets of inside tourists we assume that there is a context with a finite carrier set t representing the set of tourists. in this initial model, we have two sets of tourists, namely lin and rin, representing those at the insideleft and inside-right accordingly. note that invariant inv0 3 states that at least one of the two locations is always empty. initially, both variables are empty sets, since all tourists are outside. variables: lin,rin invariants: inv0 1 : lin ⊆ t inv0 2 : rin ⊆ t inv0 3 : lin = ∅∨rin = ∅ init begin lin := ∅ rin := ∅ end we have two events l in and r in to model the situation when a tourist enters the inside-left or inside-right accordingly (env 3). moreover there are no leaving events: a tourist once inside cannot change his location (env 4). l in status convergent any t where rin = ∅ t /∈ lin then lin := lin ∪{t} end r in status convergent any t where lin = ∅ t /∈ rin then rin := rin ∪{t} end variant: t \(lin ∪ rin) the two events are convergent, with the variant v0 representing the set of tourists not inside the two places. note that the variant v0 is bounded above by the set of tourists t , which is finite. finally, we have one ordinary event, namely final. this is an observer event (similar to those defined in [hkba09]) in the sense that it does not change the state of the model, but serves to observe a certain condition about the state of the model. the observing condition is encoded as the guard of the event: if the event is enabled, the condition is satisfied. here we are interested in the fact that all tourists will end up in the same place. note that according to invariant inv0 3, if all tourists are in one place, the other place must be empty. final =̂ when rin = t ∨lin = t then skip end further refinements keep the event final unchanged and our goal is to prove that eventually the event final is enabled. at the end of the development, besides the event final we have a number of events e1,...,en. we will prove that all events e1,...,en are convergent (standard or probabilistically). we must prove that the event system containing e1,...,en and final are deadlock-free. according to the convergence argument, all events e1,...,en will eventually converge, i.e., these events will be disabled. together with the deadlock-freedom argument, the only event that does not deadlock is final, whose guard must be satisfied when all other events are disabled. 3.2.2 refinement 1. the sets of outside tourists there are two new variables lout and rout representing the tourists outside the two places. invariant inv1 1 states that a tourist cannot be at two locations at the same time, and each tourist proc. avocs 2010 8 / 15 eceasst must be in one of the locations4. this corresponds to the requirement env 1. initially, some tourists decide to go to the outside-left and some tourists to the outside-right. variables: ...,lout,rout invariants: inv1 1 : partition(t,lin,rin,lout,rout) init begin ... lout,rout :| lout′ = t \rout′ end there are two new events namely l 2 r and r 2 l to model the movement of a tourist between the two outside locations. this corresponds to the requirement env 2. l 2 r status anticipated any t where t ∈ lout lin = ∅ then rout,lout := rout ∪{t},lout\{t} end r 2 l status anticipated any t where t ∈ rout rin = ∅ then lout,rout := lout ∪{t},rout\{t} end the guards lin = ∅ and rin = ∅ state that the tourists can only alternate between the outside locations if there is no one inside. this is a part of the algorithm described by the requirement alg 8. the two new events only modify new variables rout and lout hence clearly refine skip. moreover, invariant inv1 1 is preserved since the events only change the location for one particular tourist from outside-left to outside-right and vice versa. these events are anticipated at the moment. we will consider their convergent property in subsequent refinements. events l in and r in are refined accordingly to take into account the new variables. since the events corresponding to lef t and right are symmetric, from now on, we present only events corresponding to lef t . the refinement of event l in is as follows. (abstract )l in any t where rin = ∅ t /∈ lin then lin := lin ∪{t} end (concrete )l in any t where rin = ∅ t ∈ lout then lin,lout := lin ∪{t},lout\{t} end note that the guard strengthening proof obligation grd follows from the fact that a tourist can only be in one location at a time (invariant inv1 1). the assigned expressions to the old variable lin are the same in both abstract and concrete events. moreover invariant inv1 1 is maintained since the event merely moves a tourist from the outside-left to the inside-left. 3.2.3 refinement 2. rabin’s algorithm we introduce the two notice boards outside the places and the tourists’ notepads where they can write some number on it. initially, the number 0 is written on the notice boards and all the notepads. this corresponds to the requirements alg 6 and alg 7. variables: ...,l,r,np invariants: inv2 1 : l ∈n inv2 2 : r ∈n inv2 3 : np ∈ t →n init begin ... l,r,np := 0,0,t ×{0} end 4 partition(s,s1,...,sn) means that subsets s1,...,sn are pairwise disjoint and their union is s. 9 / 15 volume 35 (2010) development of rabin’s choice coordination algorithm in event-b we can now specify under which condition a tourist can move from one location to another. l in any t where ... l < np(t)∨lin 6= ∅ then ... end events modelling the movement of a tourist from an outside location to an inside location, i.e., event l in (and similarly r in), are guardstrengthened as follows. the guard l < np(t)∨ lin 6= ∅ states that a tourist t can move inside the left place only if the number on his notepad is greater than the number on the left notice board or if there is already someone at inside-left. for events modelling the movement of a tourist between two outside locations, there are two different cases. the events corresponding to the movement of a tourist from lef t to right are modelled by the two events l 2 r eq and l 2 r neq depending on if the number on the tourist notepad is equal or strictly smaller than the number on the notice board. using n for the conjugate number of n, the two events are as follows. l 2 r neq refines l 2 r status anticipated any t where ... np(t) < l then ... np(t) := l end l 2 r eq refines l 2 r status anticipated any t where ... np(t) = l then ... l,np :| l′ ∈{l + 2,l + 2}∧np′ = np c−{t 7→ l′} end the actions of the above events update the tourist notepad and the notice board accordingly. note that both events are refinements of the original event l 2 r, i.e, the original event is split into two cases. note that these events model the movement of a tourist according to the requirement alg 8, with the exception that we use non-deterministic choice currently in l 2 r eq. this is an abstraction of the actual probabilistic choice (i.e. coin tossing), which we will introduce later. up to this refinement model, we have modelled all requirements except fun 5. in other words, we have established the model of the problem and the algorithm. subsequent refinements are dedicated to prove the main properties of the algorithm, i.e., eventually all tourists end up in the same place. 3.2.4 refinements 3–6. convergence proofs recall in the previous model, we have an ordinary event final, two convergent events, namely l in and r in, and anticipated events l 2 r neq, l 2 r eq, r 2 l neq, and r 2 l eq. in this section, we describe our proof of (probabilistic) convergence of the anticipated events. we formalise the variant that has been proposed in [mm05]. the variant is a lexicographic one, with two layers: the outer layer (with higher priority) deals with the changes to l and r, the inner layer (with lower priority) deals with the tourists’ movements. outer layer we compare the values of l and r and notice how they can be varied. in order to understand the variant at this layer, we look at the definition of conjugate numbers. we separate the set of natural numbers into pairs: (0,1) | (2,3) | (4,5) | (6,7) | .... for each pair, a number is the conjugate of the other number in the pair and vice versa. the even number of each pair proc. avocs 2010 10 / 15 eceasst is also the minimum of the two. we will refer to this splitting of natural numbers later in our reasoning. we reason about the outer variant in two refinement steps. invariants: inv3 1 : ∀x·x ∈ lout⇒np(x)≤ r inv3 2 : ∀x·x ∈ rout⇒np(x)≤ l inv3 3 : l̃−r̃ ∈{−2,0,2} inv3 4 : l /∈ np[rout] inv3 5 : r /∈ np[lout] refinement 3. invariants inv3 1–5 constraint the relationship between l and r. below, we use the notation ñ to denote the minimum of n and its conjugate n. we will not go into details about proving the preservation of these invariants, but only give some brief descriptions of them. invariant inv3 1 states that every tourist at the outside-left carries a number not greater than the right notice board. invariant inv3 5 states that there is no tourist at the outside-left carrying the number which is the conjugate of the number on the right notice board. the invariants related to the tourists at the outside-right, i.e. inv3 2 and inv3 4 are symmetric. invariant inv3 3 states that the values of the two notice boards cannot be “too far apart”. referring to the splitting of natural numbers into pairs, this invariant states that l and r must be in the same pair or in two adjacent pairs. note that when l̃ = r̃, i.e. they are in the same pair, there can be two cases, either l = r or l = r (equivalently r = l). we can distinguish the relationship between l and r in three different cases: either l̃−r̃ ∈{−2,2} or l = r or l = r. our variant is based on this relationship. refinement 4. for the outer variant, we define the following constant function re as follows axioms: re 1 : re ∈n×n 7→{0,1,2} re 2 : ∀l,r·l 7→ r ∈ dom(re)⇔ l̃ − r̃ ∈{−2,0,2} re 3 : ∀l,r·l ∈n∧l = r⇒re(l 7→ r) = 2 re 4 : ∀l,r·l ∈n∧l = r⇒re(l 7→ r) = 0 re 5 : ∀l,r·l ∈n∧ l̃ − r̃ ∈{−2,2}⇒re(l 7→ r) = 1 variant: re(l 7→ r) bound: 2 and define the variant v1 as re(l 7→ r) with upper bound 2. we split event l 2 r eq into three different cases, depending on the current value of re(l 7→ r). l 2 r eq 0 refines l 2 r eq status convergent any t where t ∈ lout lin = ∅ np(t) = l re(l 7→ r) = 0 then ... end l 2 r eq 1 refines l 2 r eq status probabilistic any t where t ∈ lout lin = ∅ np(t) = l re(l 7→ r) = 1 then ... end l 2 r eq 2 refines l 2 r eq status convergent any t where t ∈ lout lin = ∅ np(t) = l re(l 7→ r) = 2 then ... end we prove that l 2 r eq 0 and l 2 r eq 2 are convergent, and l 2 r eq 1 is probabilistically convergent whereas l 2 r neq is anticipated (which will be convergent with using the inner variant). the convergence attribute for the events corresponding to the right are symmetric. first of all, we need to prove that the variant is bounded above (bnd) by the declared upper bound. this is trivial since by definition, re(l 7→ r) ≤ 2. next we show that each event satisfies (var) or (prv) depending on their convergence attribute. for l 2 r eq 0, this corresponds to the case that never happens, since we have re(l 7→ r) = 0, i.e. l = r; hence np(t) = r. however, since t ∈ lout and according to invariant inv3 5, we have r /∈ np[lout], which is a contradiction. in other words, the guard of l 2 r eq 0 can 11 / 15 volume 35 (2010) development of rabin’s choice coordination algorithm in event-b be used to derive ⊥. hence anything can be proved under the assumption of the guard of this events, including convergence proof. for l 2 r eq 2, we have re(l 7→ r) = 2, i.e. l = r. the action will change l to either l + 2 or l + 2, and keep r the same, hence the new value l′ will be different from r′, hence re(l′ 7→ r′) 6= 2, which is less than re(l 7→ r). as a result, the variant v1 is decreased and hence satisfies var. for l 2 r neq, it does not change the value of l or r. hence the value of v1 stays the same, i.e. is non-increasing. for l 2 r eq 1, we first have that the possible alternatives of the after states are finite (2 in this case) and hence the event satisfies finact. secondly, we prove that the event may decrease the variant v1, i.e., it satisfies prv. the actual proof obligation (with some simplifications by removing unnecessary hypotheses) is as follows. re(l 7→ r) = 1 ∀x·x ∈ lout⇒np(x)≤ r t ∈ lout np(t) = l ` ∃l′,np′·l′ ∈{l + 2,l + 2}∧np′ = np c−{t 7→ l′}∧re(l′ 7→ r) < re(l 7→ r) we have from re(l 7→ r) = 1 that l̃− r̃ ∈{−2,2}. in particular, from invariant inv3 1, i.e. ∀x·x ∈ lout⇒np(x) ≤ r, and from event’s guards t ∈ lout and np(t) = l, we have that l ≤ r and hence l̃−r̃ must be −2. referring to the splitting of natural numbers into pairs, when we have l̃− r̃ = −2, it means that l is in one pair and r is in the next higher adjacent pair. for example, if l is either 2 or 3 then r is either 4 or 5. the meaning of the action assigning l′ to either l+2 or l + 2 is to have l′ be in the same pair as r; hence one of the alternative will satisfy condition l′ = r. for this case, re(l′ 7→ r) = 0 < 1 = re(l 7→ r) as a result, we have proved that l 2 r eq 1 may decrease the variant v1. inner layer the variant for the inner layer is used to prove the convergence property of events l 2 r neq and r 2 l neq. this is done in two refinement steps. refinement 5. we prove that l 2 r neq converges and r 2 l neq is anticipated with the variant v2 defined to be {t | np(t) < l}, i.e. the set of tourists carrying a number strictly smaller than on the left notice board. event l 2 r neq changes the value of a tourist notepad from strictly less than to equal to l; hence it decreases v2. event r 2 l neq increase the value of a tourist notepad; hence it cannot increase v2. refinement 6. in the second step, we prove that r 2 l neq converges with a symmetric variant v3 that is {t | np(t) < r}. our proof follows similar reasoning as above. note that both variant v2 and v3 are bounded above by the finite set of tourists t . 3.2.5 refinement 7. deadlock-freedom invariants: inv7 1 : ∀x·x ∈ lin⇒np(x)≤ r inv7 2 : ∀x·x ∈ rin⇒np(x)≤ l inv7 3 : lin 6= ∅⇒(∃x·x ∈ lin∧np(x) > l) inv7 3 : rin 6= ∅⇒(∃x·x ∈ rin∧np(x) > r) in this final refinement, we merge the events that have been split earlier together, i.e., l 2 r eq and r 2 l eq. combining the convergent attribute of proc. avocs 2010 12 / 15 eceasst the sub-events, we have now that these two events are probabilistically convergent. we add a theorem to prove that our system at this point is deadlock-free, i.e. the disjunction of all guards always holds. in order to prove the theorem, we need the following additional invariants about the set of tourists inside the two places. together with the proof of convergence earlier, we can now ensure that our system satisfies the requirement fun 5. our reasoning is based on the approach in [hkba09] and is as follows. at the last model, we have the following events: event final which is ordinary, events l in, r in, l 2 r neq, r 2 l neq which are convergent and events l 2 r eq and r 2 l eq which are probabilistically convergent. because of the convergence proof, we ensure that together the set of convergence events (standard and probabilistic) will terminate (being disabled) with probability 1. moreover, because of the deadlock-freedom proof, when the convergent events are disabled, event final is the only one left, and must be enabled, i.e., all tourists are in the same place. 3.2.6 proof statistics model total auto.(%) man.(%) initial model 6 6(100%) 0(n/a) 1st refinement 8 7(88%) 1(12%) 2nd refinement 19 15(79%) 4(21%) outer variant 68 45(66%) 23(34%) inner variant 7 4(57%) 3(43%) deadlock freedom 32 22(69%) 10(31%) total 140 99(71%) 41(29%) table 1: proof statistics the statistics for our proofs are in table 1. a large number of manual proofs are in the models for proving the outer variants and deadlock-freedom, since we need several additional supporting invariants. in particular, in order to prove obligations related to the outer variant, we split the events l 2 r eq and r 2 l eq into different cases. as a result, we have more proof obligations, which are simpler to prove. as an alternative, we can do the split while proving, i.e. to do proof by cases, without splitting the events. this will reduce the number of proof obligations. however, it hides the termination argument inside the proofs and they become more complicated. our development is more intuitive, with the correctness being easier to observe by splitting the events accordingly. finally, most of the manual proofs deal with arithmetic reasoning related to the modulo operator (as a consequent of the use of conjugate number), sometimes involve doing case distinctions, which are known to be difficult for automated provers. 4 tool support we have implemented a plug-in to the rodin platform [abh+10] for supporting the generation of proof obligations for proving probabilistic termination. the summary of the work is as follows. more details are given in [yil10]. probabilistic attribute: an event can be marked as probabilistic. a probabilistic event is only treated differently from a standard event when it comes to convergence proof obligation. bound element: a new modelling element is added for declaring the upper bound. static checking: the conditions below are checked for a model containing probabilistic events. 1. the variant v (declared as usual) is either of the type integer or some set. 2. there is exactly one bound for a model where the probabilistic converge is proved. the bound element b must be of the same typed as the declared variant. 13 / 15 volume 35 (2010) development of rabin’s choice coordination algorithm in event-b 3. every probabilistic event must be refined by a probabilistic event. 4. merging a probabilistic event and a convergent event results in a probabilistic event. proof obligations: given a model, the following additional proof obligations are generated for proving probabilistic convergence property. 1. the variant is always bounded above by the declared bound. (bnd) 2. the variant might be decreased by the probabilistic events. (prv) 3. the bound must be finite if it is a set. (bfn) 4. the bound must be well-defined. (bwd) 5 conclusion and future work we have presented a method for reasoning about termination with probability one using refinement as an extension of the work in [hh07]. we have developed rabin’s choice coordination algorithm [rab82] in event-b. in particular, we have formalised the lexicographical variant as presented in [mm05]. we extended the rodin platform [abh+10] for supporting the generation of appropriate proof obligations concerning with this type of reasoning, and proved all the obligations using the proof support of the rodin platform [abh+10]. the example of rabin’s choice coordination is also used in [hoa05, chapter 3] as an example for reasoning about almost certain termination using classical b. the main difference between the two developments is that in classical b one ends up with a sequential program which is a model of the algorithm. our development in event-b gives us a model of a fully distributed system. moreover, the formalisation of lexicographic variants is suited better for event-b since in classical b one can only have a single natural number variant. as a result, the lexicographic variant has to be encoded (unnaturally) into a natural number variant, which leads to more complicated proofs. using our newly developed tool support, we have modelled other examples for proving termination including contention resolution [hh07] and duelling cowboys [hoa05, chapter 6]. in the future, we will integrate the reasoning about contention resolution with the development of the firewire protocol [acm03] and the full k-version of rabin’s choice coordination algorithm [rab82]. in particular, for the latter example, the model of the algorithm will be straightforward with each event having an additional parameter representing a particular alternative (currently the alternative is “hard-coded” as lef t and right and we have separate events for each alternative). however the challenge will be on finding the right lexicographic variant for proving probabilistic termination of the algorithm using our tool. we have presented our development involving several refinements, which involves reasoning about both standard and probabilistic terminations and deadlock-freedom. however, we only use superposition refinement. in particular, when dealing with convergent proofs, we merely keep the models the same, and the various refinements are there to accommodate the lexicographic variant. for this reason, i.e., having the same model through out, our reasoning about probabilistic termination is preserved. this is a very strong assumption, and it could reduce the effectiveness of using refinement. however, in general, standard refinement does not preserve proc. avocs 2010 14 / 15 eceasst this type of reasoning: a valid standard refinement can accidentally remove the choice that leads to possible termination. the argument becomes more complicated with data refinement, i.e., when one replaces some abstract variables by some new concrete variables. in order to relax the restriction on having the same model through out, additional proof obligation(s) will be needed to guarantee that our reasoning at the abstract level about probabilistic convergence remains valid at the concrete level. we regard this as possible future work. acknowledgements: we thank j-r. abrial, d. basin, a. fürst, s. hallerstede, m. schmalz and anonymous reviewers for their constructive comments on the paper. bibliography [abh+10] j.-r. abrial, m. butler, s. hallerstede, t. hoang, f. mehta, l. voisin. rodin: an open toolset for modelling and reasoning in event-b. internation journal on software tools for technology transfer (sttt), apr. 2010. [abr10] j.-r. abrial. modeling in event-b: system and software engineering. cambridge university press, may 2010. [acm03] j.-r. abrial, d. cansell, d. méry. a mechanically proved and incremental development of ieee 1394 tree identify protocol. formal asp. comput. 14(3):215–227, 2003. [bac89] r.-j. back. refinement calculus ii: parallel and reactive programs. in debakker et al. (eds.), stepwise refinement of distributed systems. lncs 430, pp. 67–93. springer-verlag, mook, the netherlands, may 1989. [hh07] s. hallerstede, t. hoang. qualitative probabilistic modelling in event-b. in david and gibbons (eds.), ifm 2007: integrated formal methods. lncs 4591, pp. 293– 312. springer verlag, oxford, u.k., july 2007. [hkba09] t. hoang, h. kuruma, d. basin, j.-r. abrial. developing topology discovery in event-b. sci. comput. program. 74(11-12):879–899, 2009. [hoa05] t. hoang. the development of a probabilistic b-method and a supporting toolkit. phd thesis, the university of new south wales, july 2005. [iee00] ieee. ieee std 1394a-2000 high performance serial bus – amendment 1. 2000. [mm05] c. morgan, a. mciver. abstraction, refinement and proof for probabilistic systems. springer verlag, 2005. [rab82] m. rabin. the choice coordination problem. acta informatica, 17:121-134, 1982. [yil10] e. yilmaz. tool support for qualitative reasoning in event-b. master’s thesis, department of computer science, eth zurich, switzerland, aug. 2010. http: //e-collection.ethbib.ethz.ch/view/eth:1677?q=yilmaz. 15 / 15 volume 35 (2010) http://e-collection.ethbib.ethz.ch/view/eth:1677?q=yilmaz http://e-collection.ethbib.ethz.ch/view/eth:1677?q=yilmaz introduction qualitative reasoning in event-b machines machine refinement convergence and qualitative reasoning our contribution rabin's choice coordination algorithm description of the problem and algorithm formal development initial model. the sets of inside tourists refinement 1. the sets of outside tourists refinement 2. rabin's algorithm refinements 3–6. convergence proofs refinement 7. deadlock-freedom proof statistics tool support conclusion and future work the jury is still out: a comparison of agg, fujaba, and progres electronic communications of the easst volume 6 (2007) proceedings of the sixth international workshop on graph transformation and visual modeling techniques (gt-vmt 2007) the jury is still out: a comparison of agg, fujaba, and progres christian fuss, christof mosler, ulrike ranger, and erhard schultchen 14 pages guest editors: karsten ehrig, holger giese managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst the jury is still out: a comparison of agg, fujaba, and progres christian fuss, christof mosler, ulrike ranger, and erhard schultchen [fuss|mosler|ranger|schultchen]@i3.informatik.rwth-aachen.de http://www-i3.informatik.rwth-aachen.de department of computer science 3 (software engineering) rwth aachen university, germany abstract: graph transformation languages offer a declarative and visual programming method for software systems with complex data structures. some of these languages have reached a level of maturity that allows not only conceptual but also practical use. this paper compares the three widespread graph transformation languages agg, fujaba, and progres, considering their latest developments. the comparison is three-fold and regards conceptual aspects, language properties, and infrastructure features. because of the different relevance of these aspects, we do not determine a clear winner but leave it to the reader. keywords: graph transformation languages, agg, fujaba, progres 1 introduction graph transformation languages are one branch of visual programming languages, which provide advanced concepts for modeling software tools. some languages reached a level of maturity that allows utilization in practice. in this paper, we compare the three widespread general-purpose languages agg, fujaba, and progres. our goal is to point out main differences in conceptual aspects, language properties, and infrastructure features. there exist some comparisons of graph transformation languages dating back several years, e.g. [btms99, fnt98, roz97]. comparisons that are more recent focus only on particular application areas, e.g. [agr04] deals with model integration aspects. in [vsv05], the runtime efficiency of the generated applications is analyzed. while this paper concentrates on general-purpose languages, [mg05, teg+05] describe also languages dedicated to model transformation and to model checking, e.g. great [kass03] and groove [ren04]. we do not only want to update the older comparisons, considering recent developments, but also lay focus on practical aspects. we do not claim our comparison is complete. this paper shall support users when deciding, which language is most appropriate for his or her application. we hope especially a novice in the area of graph transformation languages will profit from this practical overview. this paper is structured as follows: in section 2, we describe the aspects of the graph transformation languages that we examine and introduce a running application example. in the following sections, we study how each of the languages agg, fujaba, and progres meets the stated requirements and describe specific aspects. finally, section 6, summarizes our comparison and points out strengths and weaknesses of each language. 1 / 14 volume 6 (2007) mailto:[fuss$|$mosler$|$ranger$|$schultchen]@i3.informatik.rwth-aachen.de http://www-i3.informatik.rwth-aachen.de comparison of agg, fujaba, and progres 2 compared aspects the graph transformation languages are compared by different aspects, which are introduced in this section. we compare the theoretical concepts building each language’s background, the language features when specifying a graph transformation system, and the infrastructure offered to edit and run these systems. 2.1 theoretical concepts graphs are clear and intuitive data structures, whose fundamentals are mathematically founded. since the late 1960s, different approaches to graph grammars have been developed, which differ e.g. in their graph model, the expressiveness of transformation rules, and the definition of semantics. basically, two main approaches can be distinguished, which are briefly described in the following. the algebraic approach considers a graph as a 2-sorted algebra, where nodes and edges are typed, attributed, and identified. the derivation of a graph by applying a graph transformation rule is defined by pushouts known from category theory. the approach allows formal and easy to understand proofs of properties on graphs and on graph transformation rules, e.g. the amalgamation of graph transformation rules. two different branches concerning the derivation have been evolved within the algebraic approach, namely the double pushout approach (dpo) [ceh+97] and the single pushout approach (spo) [ehk+97]. in dpo, a derivation is constructed by two pushouts using a gluing graph between the left-hand side and the right-hand side of a transformation rule, which enables to reverse transformations. a graph transformation rule can only be applied if all edges incident to its match in the working graph and to the context graph are specified within the transformation rule, which leads to complex specifications. for this reason, spo has been developed, which overcomes this restriction and constructs only one pushout for a derivation. thus, the graph transformation rules are easier, but the theoretical properties of spo are limited. the set-theoretic approach [nag79] offers an intuitive understanding of graph transformation systems, but does not provide a theoretical foundation that is as powerful as in the algebraic approach. graphs are described as sets of nodes and edges and the effect of applying a graph transformation rule is defined by set-theoretic operations. in contrast to the algebraic approach, edges are considered as relations between nodes and thus are neither identified nor attributed. the approach allows more expressiveness within graph transformation rules, e.g. embedding rules, which enable user-defined embedding of a rewritten sub-graph in its context graph. furthermore, the application of graph transformation rules can be managed by control structures offering a backtracking mechanism for determining matches of transformation rules. the approach does not provide any means for describing static and derived graph properties. these aspects are integrated in the logic-oriented approach [sch91], which is an enhancement of the set-theoretic approach. the approach allows to define an explicit graph schema and uses predicate logic formulas for defining graphs and graph transformation rules. besides the fundamental approach, a graph language may be based on different programming paradigms. as all presented graph languages offer means for typing graph elements, we will analyze in how far they support the object-oriented paradigm. this includes providing typespecific attributes and methods, inheritance relations between types, and polymorphism. proc. gt-vmt 2007 2 / 14 eceasst 2.2 language properties in this subsection, we examine properties of graph transformation languages, concerning the graph model and graph transformations, in general. some of the properties are similar to those compared in [btms99], some are owed to new developments in agg, fujaba, and progres. table 1 shows a feature matrix listing all properties. the sections on agg, fujaba, and progres describe properties implemented for each language in detail. table 1: feature matrix with language properties property agg fujaba progres kind directed, attributed, labeled directed, attributed, labeled directed, attributed, labeled graph schema unchecked type graph uml class diagram graph schema with static rule-check graphs integrity constraints global event-condition rules with manual application  global and node-local eca rules, schema constraints kind typed, attributed, identified typed, attributed, identified typed, attributed, identified nodes derived node types multiple inheritance [multiple] inheritance multiple inheritance kind labeled, attributed, identified, directed, binary, between nodes labeled, directed, binary, between nodes labeled, directed, binary, between nodes derived edge types  paths (textual) paths (materializable) edges constraints  ordered  value types java objects/standard types java objects/standard types, node types internal standard types, c types, node types, sets expressions parsed java expressions unparsed java expressions parsed c or progres expressions derived attributes  simulated using methods directed equations g raph m odel attributes meta attributes  const, static const, static homo-/isomorphic global option explicit folding per rule element explicit folding per rule element matching multiple matches [amalgamated subrules] set nodes, for-each patterns set nodes, star rules subgraphs nodes, edges nodes, optional nodes, set nodes, edges, paths, constraints nodes, optional nodes, set nodes, edges, paths, restrictions, constraints nacs neg. subgraphs neg. nodes, neg. edges, neg. constraints neg. nodes, neg. edges, neg. paths, neg. constraints conditions attribute conditions yes yes yes gluing/embedding gluing  embedding signature in parameters in parameters, return value in/out parameters mechanisms iteration over layers conditional, iteration, sequence, collaboration stmts, method calls conditional, iteration, sequence, nondeterministic choice, transformation calls transactions   yes transform ations control programming backtracking   yes graph model graphs. the working graphs of all discussed languages are directed, attributed, nodeand edgelabeled. the structure of the working graphs is constrained by graph schemas that define node and edge types and their relations. transformation rules should be checked against the schema to avoid syntactical errors at specification time. integrity constraints are used to prohibit certain patterns in the working graph. they are checked at runtime. transformations of hierarchical graphs can be found in literature but are not implemented in any of the languages. nodes. in the three languages, nodes are generally typed, attributed, and identified elements. node types can be derived from other types by inheritance. edges. edges are typed, directed and connect two nodes in all three languages. edges might be identifiable graph objects or represent an unidentified relation of graph objects. further properties of edges are attribution and constraints (e.g. ordered or sorted edges). derived edges in the form of paths can be used to simplify otherwise very complex rules. edges between edges, inheritance of edges, and n-ary edges are supported in neither language. 3 / 14 volume 6 (2007) comparison of agg, fujaba, and progres attributes. besides the type label, graph elements might carry attributes, which are defined by the element type. value types can be standard types, often borrowed from host languages like java or c (evaluation of expressions might also be borrowed). derived attributes are not set directly, but evaluated according to an equation that might reference other graph elements. additionally, sets and graph elements are useful attribute values. graph transformation rules graph transformation rules describe possible transformations of the working graph. they can be divided into compound rules, combining other rules by control structures and simple rules. simple rules have a left-hand side (lhs) and a right-hand side (rhs). if the lhs is found in the working graph (i.e. it can be matched), the match is replaced by the rhs. matching. a rule match is a morphism that maps a rule’s lhs elements to elements from the working graph. if lhs elements are mapped to only one working graph element, the morphism is a homomorphism. non-homomorphic constructs are e.g. set nodes, amalgamated rules (agg), star-rules (progres). if each lhs element is mapped to a different element from the working graph, the morphism is injective (default). whether the matching is non-injective (i.e. one working graph element can play multiple transformation roles) might be determined per graph grammar, per rule, or per rule element. conditions. conditions define constraints for rule applications. structural conditions are found in the lhs of a rule and include nodes, optional nodes, set nodes, paths, and restriction expressions. restrictions constrain the match of a rule node by attribute or structure conditions. attribute conditions are defined by expressions referring to element attributes. negative application conditions (nacs) [hht96] define structures that must not be found in the working graph, if a rule is applied; these might be integrated into the lhs or separated and range from simple negative nodes and edges to negative paths and complete negative partial graphs. gluing/embedding. gluing means the merging of two nodes into one, which owns all incident edges and all non-conflicting attributes of both. embedding is somehow similar: it allows the redirection of incident edges from one node to another. signature. procedure-like signatures support the use of graph transformation rules in a way known from imperative programming. input parameters allow the parameterization of rules, while output parameters let transformation results influence following rules. control structures. with control structures, the definition of compound rules is possible by combination through conditional, iteration, and chaining statements. statements with non-deterministic behavior and backtracking allow the convenient specification of many graph algorithms. the chaining of rules should be accompanied by transactions, in order to rollback a chain of rules if one fails. 2.3 infrastructure besides concepts and language properties, the infrastructure, offered to edit, analyze, and run the graph transformation system is crucial to its applicability. a graph language environment should provide a visual and textual editor for specifications. it should allow free-hand as well proc. gt-vmt 2007 4 / 14 eceasst as syntax-directed editing. at least some analyzing functions, e.g. a sophisticated type checker, should be integrated to detect and explain inconsistencies with respect to the language’s static semantics. basic layout algorithms for the rules should be available in the editor. for testing a specification, the language environment should provide an interpreter. during an interpreter session, the environment performs a sequence of graph transformations and visualizes the working graph. different application strategies for transformation rules should be possible, e.g. a debugging mode allowing step-by-step execution. additionally, a code generator should produce compilable source code for a general programming language to support the development of stand-alone applications. the generator’s backend should be sufficiently flexible to allow the extension to further programming languages. a graphical framework providing access to the specified graph transformation rules should be available to obtain an executable application. to store large graphs and support efficient manipulation of graph structures, a database should be provided. it should also support undo/redo of transformation rules and provide persistence for the working graph. another requirement concerns the extensibility of the language environments. monolithic architectures are hard to extend, while plug-in structures are more flexible. sometimes the user is confronted with limited choices concerning the platform for installation of the language environment. therefore, the language environments should be available for at least the most common operating systems, and offer an easy and fast installation. ideally, the environment should be implemented in a platform independent language like java and be freely available. as all presented languages are distributed under the terms of the gnu (lesser) general public license. 2.4 example to explain the different aspects of each graph transformation system in the next sections, we introduce a simple example of a shipping company. the shipping company resembles the example used in [ert99]. its graph schema is illustrated in figure 1 as a class diagram. in the example, pallets of different weights are kept in stores. every pallet has to be brought to a certain city by a truck, which is modeled by a todestination-edge storing also the due date. a truck has a maximum loading weight (maxload) and stores its current weight (load). the order of a truck’s target cities is determined by a route, which is modeled by ordered onroute-edges. the truck is drivenby an employee of a store. the boolean attribute onduty indicates whether the employee is at work. figure 2 shows the sample graph transformation rule loadurgentpallet, which is used for loading storeemployee onduty : boolean ; drivenby employedby dockedat in onroute {ordered} truck load : integer ; maxload : integer ; on pallet weight : integer ; 1* * 0..1 0..1 0..1 *0..1 * 0..1 ** 0..1 * city name : string ; todestination due : date ; figure 1: graph schema of the shipping company 5 / 14 volume 6 (2007) comparison of agg, fujaba, and progres dest : city e : employee onduty == true ; s : store eb : employedby folding db : drivenby da : dockedat i : in or1 : onroute c : cityc : city before td : todestination dest d e s eb db da or2 td o : on d : employee ::= loadurgentpallet (in pallet p, out truck) = return t ; p p due == tomorrow t : truck maxload >= load + p.weight ; or2 : onroute t load += p.weight; figure 2: graph transformation loadurgentpallet a given pallet p in a suitable truck t. the match for loadurgentpallet is determined by the following constraints: the working graph is searched for the destination city dest and the current store s of the given pallet p, which is due tomorrow. additionally, a truck t dockedat store s has to be found, whose first target city is equal to the destination dest of pallet p. this is modeled by the negative node city c, i.e. there exists no city c, which is before city dest on the route of truck t. furthermore, the maximum load of truck t must not be exceeded by the weight of pallet p. to load pallet p on truck t, an employee is needed, which is onduty. as even the driver d of truck t may help to load pallet p, if he is employed by store s, employees d and e are connected by a folding-construct. this enables the non-injective matching of the driver and the store employee in the working graph. a match found for the lhs is transformed according to the rhs: the in-edge incident to pallet p is deleted and a new on-edge is created connecting pallet p and truck t. the load-attribute of truck t is updated and t is returned. 3 agg conceptually, agg (attributed graph grammar) [ert99] follows the algebraic approach to graph transformation and implements single-pushout behavior. the implementation is based on the colimit library [wol98], which provides colimit construction for category theory of signatures and graph structures. colimit could easily be used for the transformation of hierarchical graphs, but agg does not support this. an agg graph grammar consists of a type graph, a start graph, and simple rules. figure 3 shows a graph grammar for the shipping company example from subsection 2.4. the type graph contains an object-oriented description of node types, edge types, and their relations. node types can be derived from other node types by multiple inheritance. attributes can be defined for node and edge types. all constraints from the schema (attribute types, edges’ source and target types and multiplicities) have to be checked manually within the rules. agg does neither support derived edges (e.g. paths), derived attributes, nor meta attributes (e.g. constant or static). although the colimit library would allow complex edges, the language only supports binary edges between nodes. edge constraints like ordering or sorting are not supported either, thus the ordered onroute-edge has to be modeled as edge-node-edge construct with an ordering before-edge in the example’s type graph (see figure 3, top left). the agg feature of graph constraints is not used in the example, with it one can define graph patterns and their conclusion proc. gt-vmt 2007 6 / 14 eceasst figure 3: a simple agg graph grammar for the shipping company example to check structural properties of the working graph. the start graph defines an initial working graph. all nodes and edges in a working graph are typed, identifiable, and might be attributed. figure 3 (top right) shows a simple start graph for the example, with a small 3.5t truck having two cities on his route (berlin before hamburg) and a driver, who is an employee of the store. two pallets with different weights are stored in the store, with destinations berlin and hamburg. they have to arrive on december 1st resp. 6th. agg only supports simple rules. the lhs consists only of nodes and edges (no other elements are available). injective matching can be switched on and off globally1. with non-injective matching, the employee node from the working graph can be matched for the depicted rule in figure 3 as node 6 (driver) and node 3 (store worker). nacs are subgraphs defined outside the lhs that must not be fulfilled. here there must not be another onroute node before node 9. attribute conditions, e.g. d.before(tomorrow)2, are defined in a special attribute editor (not depicted) and can contain arbitrary java expressions. the match is determined by the lhs, nacs, and attribute conditions. one feature not shown in the example is gluing, i.e. two nodes are merged into one node. the resulting node owns all non-conflicting attributes and edges. merge conflicts have to be solved interactively by the user. for the complete grammar, agg allows to compute critical pairs of rules. i.e. rules which execution disable the application of other rules. the execution of rules can be programmed slightly, by defining layers for the rules. then the execution loops over the sequence of all rules on one layer, until none is executable anymore, then the loop is executed on the next layer until the last. additionally, single rules can be selected for execution manually. the editing of graph grammars is done by a graphical editor, which is completely built in java and easily installed on different platforms. the editor has a gui that is intuitive, but does not 1 non-homomorphic matching, i.e. multiple matches for one rule element, can be obtained in agg with amalgamated subrules [tb94], which is an extension not yet publicly available. 2 d is of type java.util.date and the java method before compares this date with another date (tomorrow). 7 / 14 volume 6 (2007) comparison of agg, fujaba, and progres offer much support for syntax-directed editing. positive is the good integration of the interpreter into the agg editor. the generation of executable code from the graph grammar is not possible but grammar specifications can be exported to xml files. the tiger framework [eeht05] allows the generation of visual editors for an agg graph grammar. for that, the graph grammar has to be decorated by a visual concrete syntax for all elements. the generated editors are gef-based eclipse-plugins, where the user can pick single rules for execution. the editors use agg’s java api to interpret the graph grammar. agg is based on a very sound theory and the editor is simple to use and install. this allows easy testing of prototypical specifications. [mtr06] gives a good example of a small prototypical reengineering editor specified with agg, relying on the notion of critical pair analysis. for an application in larger projects, code generation and control structures are missing. 4 fujaba originally, the focus of fujaba (from uml to java and back again) was to provide a visual modeling tool based on uml diagrams and to generate java code from these models. meanwhile, fujaba also supports other metamodels and output formats. adaptation to special application domains is eased by the template-based code generation module and the plugin based architecture. for example, fujaba has been applied in [bgs05] to model real-time systems, including extensions of the modeling language. fujaba has also been applied in the moflon framework [akrs06] for building model transformation systems based on mof and qvt. in fujaba, graph schemas are modeled using simplified uml class diagrams, resembling the one shown in figure 1. classes can be attributed and any java class or ordinal type is supported as attribute type. derived attributes are not directly offered, but can be simulated by a method replacing the getter-method generated for the attribute. we therefore model the getload method to derive the truck’s load. thus, this attribute does not require manual update when pallets are loaded on the truck. inheritance of classes is supported, although multiple inheritance is restricted to interfaces. overloading of methods and polymorphism is handled by the java environment at runtime. attributed associations, inheritance on associations or n-ary relations are not supported. fujaba provides ordered associations, which impose a total ordering on the link instances during runtime. this feature is well-suited to model the onroute association. the behavior of applications is modeled using so-called story diagrams [fntz98] which combine uml-collaboration diagrams with activity diagrams. from each story diagram, fufigure 4: fujaba story diagram loadurgentpallet proc. gt-vmt 2007 8 / 14 eceasst jaba generates a java method operating according to the modeled transformation rule. story diagrams consist of one start and at least one stop activity, and an arbitrary number of story patterns operating on the runtime graph. these elements are connected through transitions. story patterns correspond to rules in agg, but incorporate lhs and rhs into one diagram using the stereotypes «create» and «destroy». for pattern matching, fujaba offers obligatory, optional, set and negative node variables. by default, fujaba creates injective morphisms from variables to objects, so that two variables are never bound to the same object. this behavior can be disabled per pair of variables. attribute assertions may constrain the matched objects by an unparsed (thus arbitrary) java expression. furthermore, fujaba supports obligatory, optional and negative edges between variables and textual path expressions. for ordered associations, additional constraints can be specified for the matching, e.g. first or last. every pattern requires at least one bound variable which can be provided by a parameter of the story diagram, the this object the method is invoked on, variables bound in preceding patterns or by an arbitrary java expression. from these bound variables, the other variables of the pattern are bound to objects from the runtime graph by traversing links of given type. transformation rules are conducted after the complete pattern has been matched, and may create and delete elements, set attributes and call methods on matched objects. figure 4 shows a story diagram implementing the loadurgentpallet transformation rule. the required bound variable is provided by the method parameter p, from which the other variables are bound. attribute assertions are used to check if the truck t is not overloaded and the given pallet p needs urgent delivery (due attribute denotes tomorrow). injective matching is disabled for variables d and e by adding the {maybe d==e} constraint. for the ordered onroute association, {first} retrieves the first link from t to a city. if pattern matching succeeds, the runtime graph is transformed by removing the pallet’s in edge to the store and creating an on edge to the truck. to model the control flow, story patterns may hold transitions to multiple successors. in the depicted example, two stop activities exist. by the transition guard [success], the left one is called when the transformation rule succeeds and returns the matched truck as return value. otherwise, the right stop activity returns null. transitions may form loops, causing repeated execution of story patterns. also, for-each-patterns allow to process every match of a story pattern instead of only one match. the formal background of story patterns is obtained from the logic-oriented approach described in subsection 2.1. however, some of their semantic aspects are only incompletely defined (cf. [tmg06]). the fujaba environment also performs very limited checks on the modeled diagrams, so the specifier is often not warned about erroneous specifications. the generated source code can easily be integrated into existing projects or used in rapidprototyping frameworks. edobs is a plugin for the eclipse ide which visualizes the runtime graph of a fujaba-generated application. with the help of the coobra framework, generated applications are able to store their runtime states persistently. recently, the graph-oriented database dragos and the related upgrade [bjsw02] framework were adapted to support fujaba. being entirely written in java, fujaba works on multiple platforms and is easy to set up. besides the regular stand-alone application, an eclipse-plugin embedding fujaba into the ide is under development. fujaba’s advantage is its extensible architecture and the use of the well-known uml. major disadvantages are the lack of a complete semantic definition and the rare validity checks. 9 / 14 volume 6 (2007) comparison of agg, fujaba, and progres 5 progres progres (programmed graph rewriting system) [swz99] is the eldest of the presented graph languages and environments. the logic-oriented approach [sch91] forms the basis of progres, which offers a proprietary language allowing the specification of a graph schema and consistent graph transformation rules. progres provides various constructs for defining a graph schema of a specification. for node types, three different types of attributes can be defined: intrinsic attributes, whose values are assigned directly, meta attributes, which constitute class attributes and thus have the same value for every instance, and derived attributes. values of derived attributes are computed dependent on attribute values of other nodes and are automatically updated when their values are invalid. for example, the node type truck shown in figure 5 owns a derived load-attribute, whose value is the sum of all loaded pallet weights. the pallet weights are obtained by traversing the incoming on-edges of the truck. progres supports the object-oriented paradigm regarding node types, which includes inheritance relations between node types, polymorphism, type-specific attributes and methods. edge types define the type name, the source and target node types, and their cardinalities. paths may be modeled allowing complex navigations through the working graph, traversing arbitrary edges of different types. progres also enables the specification of graph constraints, e.g. there are at most n instances of a certain node type within the working graph. if such a constraint is violated, an appropriate repair action can be executed. based on the schema, incremental analyzes check the specification for inconsistencies and show appropriate error messages. besides the graph schema, progres offers modeling of graph queries and graph transformation rules, which may have several input and output parameters. a graph query defines a test for the existence of a graph pattern in the working graph. a graph transformation rule modifies the working graph. for their execution, the underlying graph database dragos [böh04] provides transactions for graph operations (ensuring acid-properties). for every transformation rule, preand postconditions may be specified, which imply constraints on the working graph before ::=`4 : destination `3 : city `5 : store before `8 : onroute `6 : employee `9 : employee `1 = p `2 : truck tocity `7 : onroute todestcity todestination instoreemployedby toroutetoroute drivenby `4 : destination `3 : city `5 : store `6 : employee `9 : employee `1 = p `2 : truck tocity `7 : onroute todestcity todestination employedby toroute drivenby node_type truck : item intrinsic maxload : integer ; derived load : integer = 0 + all self.<-on-.weight ; end ; folding { `6 , `9 } ; condition `2.maxload > `2.load + `1.weight ; `4.due = tomorrow ; `9.onduty = true ; return t := 2´ ; end ; transformation loadurgentpalett ( p : palett , out t : truck) = on dockedat dockedat figure 5: progres transformation rule loadurgentpallet proc. gt-vmt 2007 10 / 14 eceasst resp. after the execution of the rule. furthermore, a qualifier determines if a transformation rule should be applied to one match or to all possible matches in parallel. graph transformation rules are classified as production (simple rule) or transaction (compound rule). productions are similar to agg rules and story patterns in fujaba. they are visually specified and allow to create and delete nodes and edges. they are described by a lhs and a rhs, which may contain obligatory nodes and edges, paths, optional nodes, set nodes, and restrictions on nodes. nacs are modeled by negative nodes, edges, paths, and restrictions. additionally, a production may have a conditionand a transfer-part to imply conditions on attribute values resp. to change the value of node attributes. progres allows the specification of embedding rules for redirecting edges incident to deleted nodes and embedding new nodes into the working graph. the folding-statement enables the non-injective mapping of two nodes in the production to the same node in the working graph. figure 5 shows the progres production loadurgentpallet introduced in subsection 2.4. the production uses two edge-node-edge constructs for the ordered onroute-edge and the attributed todestination-edge, as these sorts of edges are not supported by progres. the folding-construct, the attribute conditions and the return-statement are represented as textual statements. as the load-attribute of truck t is defined as derived attribute, its value is not assigned explicitly. in contrast to productions, transactions contain control structures for combining transformation rules and queries. this includes to sequence transformation rules and to execute one of a set of rules non-deterministically. furthermore, loopand condition-statements may be used. progres is the most expressive graph language of the three presented languages and offers extensive support for modeling big software systems. but the proprietary language is fairly complex and difficult to learn. from a specification, c and java source code can be generated. this code can be used for rapid prototyping by applying the upgrade-framework. ahead [jsw00] is a good example of an industrial-sized project specified with progres. the syntax-directed progres editor, that also features an interpreter, guides the user well, but is not really intuitive. in addition, it is only available for linux. a further disadvantage of progres is its monolithic architecture, which makes the development and implementation of new language concepts difficult. 6 summary table 2 summarizes aspects of the three languages that are most important to their practical applicability, e.g. their support at specification time through a rich editor. table 2: language aspects most important to practical applicability agg fujaba progres language expressiveness o ++ most wanted features for practical applicability control structures, paths, check against schema paths, check against schema, search without bound object namespaces, view concept language learnability graphical part intuitive (but many things hidden in dialogs) uml-like, easy hard due to rich expressiveness specification editor mixed graphical/dialog-based mixed graphical/unparsed java mixed graphical/textual, syntax-directed interpreter manually controllable  step-through code generation  adaptable, template-based, java not adaptable, c and java gui support tiger [eeht05] edobs, upgrade upgrade [bjsw02] language extensibility  plug-in architecture  11 / 14 volume 6 (2007) comparison of agg, fujaba, and progres with the algebraic approach, agg offers a graph transformation language with a sound theoretical basis. this offers convenient implementation possibilities for projects relying on theoretical notions. it provides a well-developed environment which can easily be installed and applied. however, the language does not seem rich enough for general purpose applications, the main disadvantage being the lack of control structures. therefore, agg still has to prove that it can be applied in large-scale projects. the biggest advantage of fujaba is its use of uml, which requires only little learning effort from the user. in addition, the vivid community is working intensively on improvements and further extensions. however, the language lacks a formal definition, forcing the user to inspect the code when in doubt about language semantics. additionally, due to the lack of analyzes the user is not sufficiently guided during the specification process, often leading to malfunctioning or unexpected behavior of the generated code. progres offers the most sophisticated language, although there are still some features missing. the infrastructure, including a syntax-directed editor, an interpreter, and a code generation mechanism, provides the highest level of maturity. the experience with industrial-sized projects proves the practical usability of progres. however, the environment does not conform to today’s standards, requiring a painstaking installation process and providing a relatively inconvenient interface, particularly to new users. additionally, it is very hard to extend this extensive environment and language for new features. the jury is still out: because of the different relevance of the compared aspects, we cannot give final advice, but leave it to the reader to decide which language to use. bibliography [agr04] a. agrawal. model based software engineering, graph grammars and graph transformations. area paper, eecs at vanderbilt university, 2004. [akrs06] c. amelunxen, a. königs, t. rötschke, a. schürr. moflon: a standardcompliant metamodeling framework with graph transformations. in rensink and warmer (eds.), model driven architecture foundations and applications (ecmda-fa’06). lncs 4066, pp. 361–375. springer, 2006. [bgs05] s. burmester, h. giese, w. schäfer. model-driven architecture for hard realtime systems: from platform independent models to code. in proc. of the european conf. on model driven architecture foundations and applications (ecmdafa’05), nürnberg, germany. lncs 3748, pp. 25–40. springer, 2005. [bjsw02] b. böhlen, d. jäger, a. schleicher, b. westfechtel. upgrade: a framework for building graph-based interactive tools. in mens et al. (eds.). entcs 72, pp. 149– 159. elsevier science publishers, 2002. [böh04] b. böhlen. specific graph models and their mappings to a common model. pp. 45– 60 in [pnb04]. [btms99] r. bardohl, g. taentzer, m. minas, a. schürr. application of graph transformation to visual languages. in [eekr99], pp. 105–180, 1999. proc. gt-vmt 2007 12 / 14 eceasst [ceh+97] a. corradini, h. ehrig, r. heckel, m. korff, m. löwe, l. ribeiro, a. wagner. algebraic approaches to graph transformation – part i: basic concepts and double pushout approach. in [roz97], pp. 163–245, 1997. [eeht05] k. ehrig, c. ermel, s. hänsgen, g. taentzer. generation of visual editors as eclipse plug-ins. in 20th ieee/acm int. conf. on automated software engineering, ase’05. pp. 134–143. acm press, new york, 2005. [eekr99] h. ehrig, g. engels, h.-j. kreowski, g. rozenberg (eds.). handbook on graph grammars and computing by graph transformation: applications, languages, and tools. volume 2. world scientific, 1999. [ehk+97] h. ehrig, r. heckel, m. korff, m. löwe, l. ribeiro, a. wagner, a. corradini. algebraic approaches to graph transformation – part ii: single pushout approach and comparison with double pushout approach. in [roz97], pp. 247–312, 1997. [ert99] c. ermel, m. rudolf, g. taentzer. the agg approach: language and environment. in [eekr99], pp. 551–603, 1999. [fnt98] t. fischer, j. niere, l. torunski. konzeption und realisierung einer integrierten entwicklungsumgebung für uml, java und story-driven-modeling. master thesis, university of paderborn, 1998. [fntz98] t. fischer, j. niere, l. torunski, a. zündorf. story diagrams: a new graph rewrite language based on the unified modeling language. in ehrig et al. (eds.), 6th int. workshop on theory and application of graph transformation (tagt). lncs 1764, pp. 296–309. springer, 1998. [hht96] a. habel, r. heckel, g. taentzer. graph grammars with negative application conditions. fundamenta informaticae 26(3/4):pp. 287–313, 1996. [jsw00] d. jäger, a. schleicher, b. westfechtel. ahead: a graph-based system for modeling and managing development processes. in nagl et al. (eds.). lncs 1779, pp. 325–339. springer, 2000. [kass03] g. karsai, a. agrawal, f. shi, j. sprinkle. on the use of graph transformation in the formal specification of model interpreters. journal of universal computer science 9(11):1296–1321, nov. 2003. [mg05] t. mens, p. v. gorp. a taxonomy of model transformation and its application to graph transformation. 2005. , presented at the 1st international workshop on graph and model transformation, gramot’05, tallinn, estonia. [mtr06] t. mens, g. taentzer, o. runge. analysis refactoring dependencies using graph transformation. software systems modeling (sosym), 2006. [nag79] m. nagl. graph-grammatiken: theorie, anwendungen, implementierung. vieweg verlag, 1979. 13 / 14 volume 6 (2007) comparison of agg, fujaba, and progres [pnb04] j. l. pfaltz, m. nagl, b. böhlen (eds.). 2nd int. workshop on applications of graph transformations with industrial relevance, agtive’03. lncs 3062. springer, 2004. [ren04] a. rensink. the groove simulator: a tool for state space generation. pp. 479– 485 in [pnb04]. [roz97] g. rozenberg (ed.). handbook on graph grammars and computing by graph transformation: foundations. volume 1. world scientific, 1997. [sch91] a. schürr. operationales spezifizieren mit programmierten graphersetzungssystemen. phd-thesis, rwth aachen university, 1991. [swz99] a. schürr, a. j. winter, a. zündorf. the progres approach: language and environment. in [eekr99], pp. 487–550, 1999. [tb94] g. taentzer, m. beyer. amalgamated graph transformations and their use for specifying agg an algebraic graph grammar system. in int. workshop on graph transformations in computer science. pp. 380–394. springer, 1994. [teg+05] g. taentzer, k. ehrig, e. guerra, j. de lara, l. lengyel, t. levendovszky, u. prange, d. varró, , s. varró-gyapay. model transformation by graph transformation: a comparative study. in proceedings of the international workshop on model transformations in practice, mtip’05 (satellite event of models 2005). montego bay, jamaica, 2005. [tmg06] m. tichy, m. meyer, h. giese. on semantic issues in story diagrams. in giese and westfechtel (eds.), fujaba days 2006. technical report tr-ri-06-275, pp. 10–14. university of paderborn, germany, 2006. [vsv05] g. varró, a. schürr, d. varró. benchmarking for graph transformation. in 2005 ieee symposium on visual languages and human-centric computing (vl/hcc). pp. 79–88. ieee computer society, 2005. [wol98] d. wolz. a colimit library for graph transformations and algebraic development techniques. phd-thesis, tu berlin, 1998. proc. gt-vmt 2007 14 / 14 introduction compared aspects theoretical concepts language properties infrastructure example agg fujaba progres summary a lightweight abstract machine for interaction nets electronic communications of the easst volume 29 (2010) proceedings of the ninth international workshop on graph transformation and visual modeling techniques (gt-vmt 2010) a lightweight abstract machine for interaction nets abubakar hassan, ian mackie and shinya sato 12 pages guest editors: jochen küster, emilio tuosto managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst a lightweight abstract machine for interaction nets abubakar hassan1, ian mackie2 and shinya sato3 1 department of informatics, university of sussex, falmer, brighton bn1 9qj, uk 2 lix, cnrs umr 7161, école polytechnique, 91128 palaiseau cedex, france 3 himeji dokkyo university, faculty of econoinformatics, 7-2-1 kamiohno, himeji-shi, hyogo 670-8524, japan abstract: we present a new abstract machine for interaction nets and demonstrate that an implementation based on the ideas is significantly more efficient than existing interaction net evaluators. the machine, which is founded on a chemical abstract machine formulation of interaction nets, is a simplification of a previous abstract machine for interaction nets. this machine, together with an implementation, is at the heart of current work on using interaction nets as a new foundation as an intermediate language for compiler technology. keywords: interaction nets, programming languages, abstract machine 1 introduction interaction nets [laf90] are a graphical model of computation. it is possible to program with interaction nets [hms09, mac05] and they also serve as an intermediate language for implementing other programming languages. some examples are encodings of λ -calculus, and simple functional programming languages (amongst others, see for instance [ag98, gal92, mac98]). one reason why they have been very successful at implementing other programming languages is that a compilation must explain all the components of a computation. what is rare, is that the compilation can give something back, and this has been observed with the encodings on the λ -calculus where new strategies for reduction have been found. one of the reasons for this is because interaction nets naturally capture sharing, indeed one has to work hard to simulate reduction strategies where duplication of work takes place. in [fm99] a calculus was given which provided a foundation for the operational understanding of interaction nets. this calculus led to the development of an abstract machine [pin00], which in turn led to a very efficient implementation of interaction nets. recently, there have been new developments in the foundations for a calculus of interaction nets. the purpose of this paper is to outline these ideas which led to the main contribution of the paper which is an abstract machine founded on the new calculus. this in turn has led to the development of new implementations of interaction nets which are the most efficient that we are aware of to date. one of the main hopes of this work is that it provides a new foundation for a research programme to build implementations of programming languages through interaction nets: an improvement in the implementation technology for nets will have an impact on all the compilers 1 / 12 volume 29 (2010) interaction nets developed. the main contributions of this paper are: • we define a new term calculus of interaction nets. the novelty is that the notion of substitution is simplified in that it just replaces a name. • we simplify and improve pinto’s abstract machine [pin00] by using this calculus. the main improvement is due to the fact that we no longer need to maintain lists of names, and consequently the transition rules become significantly more simple. • we have built a prototype implementation based on the ideas. we demonstrate that we get a factor of ten improvement over previous implementations, and this implementation is thus the most efficient evaluator to date. overview. the rest of this paper is structured as follows. in the next section we review what we need about interaction nets. in section 3 we give our new calculus. section 4 gives the abstract machine, and gives studied properties of it. we conclude the paper in section 5. 2 interaction nets here we review the basic notions of interaction nets. we refer the reader to [laf90] for a more detailed presentation. interaction nets are specified by the following data: • a set σ of symbols. elements of σ serve as agent (node) labels. each symbol has an associated arity ar that determines the number of its auxiliary ports. if ar(α) = n for α ∈σ, then α has n + 1 ports: n auxiliary ports and a distinguished one called the principal port. …x1 xn� • a net built on σ is an undirected graph with agents at the vertices. the edges of the net connect agents together at the ports such that there is only one edge at every port. a port which is not connected is called a free port. a set of free ports is called an interface. • two agents (α, β ) ∈ σ×σ connected via their principal ports form an active pair (analogous to a redex). an interaction rule ((α, β ) −→ n) ∈ rin replaces the pair (α, β ) by the net n. all the free ports are preserved during reduction, and there is at most one rule for each pair of agents. the following diagram illustrates the idea, where n is any net built from σ. …�…�x1 xn y1 ym n… …x1 xn y1 ym…�…� proc. gt-vmt 2010 2 / 12 eceasst sadd addsr y x r y x zaddr y r y rules: add add z z s z zs s z example of reductions: ssaddadd addaddssr y x r y x zzaddaddr y r y rules: addadd addadd zz zz ss zz zzss ss zz example of reductions: figure 1: an example of a system of interaction nets we use the relation −→ for the one step reduction and −→∗ for its transitive and reflexive closure. interaction nets have the following property [laf90]: proposition 1 (strong confluence) let n be a net. if n −→ n1 and n −→ n2 with n1 6= n2, then there is a net n3 such that n1 −→ n3 and n2 −→ n3. figure 1 shows a classical example of an interaction net system that encodes the addition operation. we can represent numbers using the agents s to represent the successor function (n 7→ n + 1) and z to represent the number 0. the left of the figure contains the two addition rules which we leave the reader to relate to the standard equational term rewriting system definition of addition. the right of the figure gives an example reduction sequence which shows how a net representing 0 + 1 is reduced to 1 using the given rules. 2.1 the calculus for interaction nets in this section we review the calculus for interaction nets proposed by fernández and mackie [fm99]. we begin by introducing a number of syntactic categories: names let n be a set of names ranged over by x, y, z, x1, x2, . . .. we write x̄, ȳ, . . . for sequences of names. we assume n and σ are disjoint. terms are built from σ and n using the grammar: t ::= x | α(t1, . . . ,tn), where t1, . . . ,tn are terms, α ∈ σ and ar(α) = n. if ar(α) = 0, then we omit brackets and write just α . we use t, s, u, . . . to range over terms and t̄, s̄, ū, . . . over sequences of terms. equations have the form: t = s, where t and s are terms. equations are elements of computation. given t̄ = t1, . . . ,tk and s̄ = s1, . . . , sk, we write t̄ = s̄ to denote the list t1 = s1, . . . ,tk = sk. we use ∆, θ, . . . to range over multisets of equations. configurations have the form: 〈 t̄ | ∆ 〉, where t̄ is a sequence of terms representing the interface of the net and ∆ is a sequence of equations. all names occur at most twice in a configuration. we use c1,c2, ... to range over configurations. configurations that differ only on names are considered equivalent. 3 / 12 volume 29 (2010) interaction nets interaction rules have the form: α(t1, ...,tn) on β (s1, ..., sk), where α(t1, ...,tn) and β (s1, ..., sk) are terms. this notation for rules was introduced by lafont [laf90] and we refer to it as lafont’s style. all names occur exactly twice in a rule, and there should be at most one rule between any pair of agents in r. r is closed under symmetry, thus if α(t̄) on β (s̄) ∈ r then β (s̄) on α(t̄) ∈ r. definition 1 (bound names) if a name x occurs twice in a term t, then we say x is bound. we extend this notion to equations, sequences of terms, and multiset of equations. the calculus consists of three reduction rules which reduce (valid) configurations. indirection: 〈 t̄ | x = t, u = s, ∆ 〉−→i〈 t̄ | u[t/x] = s, ∆ 〉 where x occurs in u, collect: 〈 t̄ | x = t, ∆ 〉−→c 〈 t̄[t/x] | ∆ 〉 where x occurs in t̄, interaction: 〈 t̄ | α(t̄1) = β (t̄2), ∆ 〉−→on 〈 t̄ | t̄1 = s̄l , t̄2 = ūl , ∆ 〉 where α(s̄) on β (ū) ∈ r and s̄l and ūl are the result of replacing each occurrence of a bound name x for α(s̄) on β (ū) by a fresh name xl respectively. example 1 the example rules in figure 1 can be represented using lafont’s style 1 as: add(s(x), y) on s(add(x, y)), add(x, x) on z the example net in figure 1 can be represented using the configuration: 〈 a | add(a,z) = s(z) 〉 and the following is a possible reduction sequence using the calculus rules above: 〈 a | add(a,z) = s(z) 〉 −→on 〈 a | a = s(x′),z = y′,z = add(x′, y′) 〉 −→c 〈 s(x′) | z = y′,z = add(x′, y′) 〉 −→i 〈 s(x′) | z = add(x′,z) 〉 −→on 〈 s(x′) | x′ = x′′,z = x′′ 〉 −→c 〈 s(x′′) | z = x′′ 〉 −→c 〈 s(z) | 〉 3 refining the calculus the calculus given in the previous section has nice properties and provides a simple static and dynamic semantics for interaction nets. however, the calculus introduces extra computational steps to reduce a given net to normal form. for example, the example net in figure 1 reduces in two steps using the graphical setting while the same net reduces in six steps using the textual calculus (see example 1). in this section, we answer the following question in the positive: can we optimise the calculus to obtain more efficient computations? the result of this question is our lightweight calculus which will form the basis of the lightweight abstract machine. 1 see [laf90, hms08] for a more detailed description of lafont’s style syntax proc. gt-vmt 2010 4 / 12 eceasst interaction rules. the notation of lafont’s style generates (redundant) equations which will be reduced by the indirection rule. in particular, if an auxiliary port of an interacting agent in a rule is connected to another auxiliary port, the application of an interaction rule will generate an equation with a variable x on one side of the equation. since all variables appear twice in a rule, x will eventually be eliminated using the indirection rule. for example, this can be traced in example 1 where the equation z = y′ is generated in the configuration after applying the first rule add(s(x), y) on s(add(x, y)). in other words, the application of an interaction rule to an active pair (α, β ) where α(t̄1, x, t̄2) on β (s̄1)∈r will generate a configuration where an indirection rule is applicable. in order to eliminate the generation of redundant equations we introduce an alternative notation to represent interaction rules. we represent rules using the syntax: lhs −→ rhs where lhs consists of an equation between the two interacting agents and rhs is a list of equations which represent the right-hand side net. all rules α(t̄) on β (s̄) in lafont’s style can be written using our notation: α(t̄1) = β (s̄1) −→ t̄1 = t̄, s̄1 = s̄ where t̄1, s̄1 are meta-variables for terms. as a concrete example, the rule add(s(x), y) on s(add(x, y)) can be represented as add(t1,t2) = s(u1) −→ t1 = s(x),t2 = y, u1 = add(x, y) moreover we can simplify rules by replacing equals for equals. the above rule can be simplified to: add(t1,t2) = s(u1) −→ t1 = s(x), u1 = add(x,t2) therefore we obtain a more efficient computation by using the notation of term rewriting systems. definition 2 (lightweight interaction rules) a lightweight rule r ∈ rlt is of the form: α(t1, ...,tn) = β (s1, ..., sk) −→ ∆ where α, β ∈ σ, ar(α) = n, ar(β ) = k, and t1, ...,tn, s1, ..., sk are meta-variables for terms. each meta-variable occurs exactly twice in a rule: once on the lhs and once on the rhs. the set rlt contains at most one rule between any pair of agents; rlt is closed under symmetry — if α(t̄) = β (s̄) −→ ∆ ∈ rlt then β (s̄) = α(t̄) −→ ∆ ∈ rlt. indirection rules. let us now examine the indirection rule of the calculus which eliminates bound variables by means of variable substitution. the application of this rule will search through the list of terms to locate a term which contains an occurrence of a particular variable. in order to reduce the searching costs, pinto’s abstract machine [pin00], which is based on this calculus, attaches a list of variables to the head of every term. this again introduces management overheads, hence the increase in the number of operations required to perform rewirings. taking into consideration that every change of connection does not affect interactions directly, it turns out that we do not have to perform all substitutions eagerly. therefore we decompose the indirection rule into: communication rules that will replace just a name, and substitution rule that will perform other substitutions. 5 / 12 volume 29 (2010) interaction nets definition 3 (lightweight reduction rules) we define lightweight reduction rules as follows: communication: 〈 t̄ | x = t, x = u, ∆ 〉 com−→〈 t̄ | t = u, ∆ 〉, substitution: 〈 t̄ | x = t, u = s, ∆ 〉 sub−→〈 t̄ | u[t/x] = s, ∆ 〉 where u is not a name and x occurs in u, collect: 〈 t̄ | x = t, ∆ 〉 col−→〈 t̄[t/x] | ∆ 〉 where x occurs in t̄, interaction: 〈 t̄ | α(t̄1) = β (t̄2), ∆ 〉 int−→〈 t̄ | θl , ∆ 〉 where α(s̄) = β (ū) −→ θ ∈ rlt and θl is the result of replacing each occurrence of a bound name x for θ by a fresh name xl and replacing each occurrence of s̄, ū by t̄1, t̄2 respectively. we use just −→ instead of com−→, sub−→, col−→, int−→ when there is no ambiguity. we define c1 ⇓c2 by c1 −→∗ c2 where c2 is in normal form. from now on, we use t, s,u, ... for non-variable terms. example 2 rules in figure 1 can be represented as follows: add(x1, x2) = s(y) −→ x1 = s(w), y = add(w, x2) add(x1, x2) = z −→ x1 = x2 and the following computation can be performed: 〈 a | add(a,z) = s(z) 〉 int−→ 〈 a | a = s(w′),z = add(w′,z) 〉 col−→ 〈 s(w′) | z = add(w′,z) 〉 int−→ 〈 s(w′) | w′ = z 〉 col−→ 〈 s(z) | 〉 3.1 properties of lightweight reduction rules in this section, we present some properties of the lightweight reduction rules. first, we show that we can postpone the application of collect rules as in abramsky’s computational interpretations of linear logic [abr93]. lemma 1 if c1 col−→· com−→c2 then c1 com−→· col−→c2. proof. let c1 = 〈 t̄ | x = t, u = y, y = v, ∆ 〉 col−→〈 t̄[t/x] | u = y, y = v, ∆ 〉 com−→〈 t̄[t/x] | u = v, ∆ 〉 = c2. then, c1 com−→〈 t̄ | x = t, u = v, ∆ 〉 col−→c2. lemma 2 if c1 col−→· sub−→c2 then c1 sub−→· col−→c2. proc. gt-vmt 2010 6 / 12 eceasst lemma 3 if c1 col−→· int−→c2 then c1 int−→· col−→c2. by lemma 1, 2, 3, the following holds. lemma 4 if c1 ⇓ c2 then there is a configuration c such that c1 −→∗ c col−→ ∗ c2 and c1 is reduced to c without the application of any collect rule. next, we examine whether or not we can postpone the application of substitution rules. note that applying the substitution rule to an equation does not generate any other equations which require the application of an interaction rule. therefore the following properties hold. lemma 5 if c1 sub−→· com−→c2 then c1 com−→· sub−→c2. lemma 6 if c1 sub−→· int−→c2 then c1 int−→· sub−→c2 or c1 int−→· com−→c2. by lemma 4, 5 and 6 the following theorem holds. theorem 1 if c1 ⇓c2 then there is a configuration c such that c1 −→∗ c sub−→ ∗ · col−→ ∗ c2 and c1 is reduced to c by applying only communication and interaction rules. this theorem shows that all interaction rules can be performed without applying substitution rules. we define c1 ⇓ic c2 by c1 −→∗ c2 where c2 is a { int−→, com−→}−normal form. 4 lightweight abstract machine in this section we define the lightweight abstract machine which is based on the lightweight rewriting rules. definition 4 (machine configuration) a configuration of our abstract machine state is given by a 5-tuple ( γ | φ | t̄ | θ | ∆ ) where γ is an environment which maps a variable to a term. we use [] as an empty map and the following notation: γ[x 7→ t](z) = { t (z is x) γ(z) (otherwise) φ is a connection map. when φ (x) is undefined, we use the following notation: φ [x ↔⊥](z) = { undefined (z = x) φ (z) (otherwise) t̄ is a sequence of terms θ is a sequence of error codes that are not executable 7 / 12 volume 29 (2010) interaction nets ∆ is a sequence of equations which we also regard as codes. we write “−” for an empty sequence of codes. in figure 2 we give the semantics of the machine as a set of transitional rules of the form: ( γ | φ | t̄ | θ | ∆ ) =⇒ ( γ′ | φ ′ | t̄ | θ′ | ∆′). the functions interaction(s = t ) and error(s = t ) are defined as follows: interaction(s = t ) = { ∆1 (when 〈 | s = t 〉 int−→〈 | ∆1 〉), − (otherwise) error(s = t ) = { − (when 〈 | s = t 〉 int−→〈 | ∆1 〉), s = t (otherwise) for readability purposes we present the transitions in a table format. for example, the entry: before after ii.0 connections φ [x ↔⊥] φ [x ↔⊥] env. γ [x 7→⊥] γ [x 7→u ] code x = u, ∆ ∆ corresponds to: ( γ [x 7→⊥] | φ [x ↔⊥] | t̄ |− | x = u, ∆ ) =⇒ ( γ [x 7→u ] | φ [x ↔⊥] | t̄ |− | ∆ ) 4.1 correctness in order to show the correctness of our abstract machine, we first define a decompilation function from configurations to terms. several lemmas follow before the correctness theorem. definition 5 (decompilation) we define a translation b.cenv from an environment γ into a multiset of equations as follows: b[]cenv def = empty, bγ[x 7→ t]cenv def = x = t,bγcenv. the function b.ccon translates a connection map φ into a multiset of equations as follows: b[]ccon def = empty, bφ [x ↔ y]ccon def = x = y,bφccon. we write just b.c instead of b.cenv, b.ccon when there is no ambiguity. the machine will stop when there is no executable code. these cases arise not only when the code sequence is empty, but also when names are included in both the domains of γ and φ . we define the latter case as inconsistent: proc. gt-vmt 2010 8 / 12 eceasst before after i error θ error(u = t ), θ code u = t, ∆ interaction(u = t ), ∆ ii.0 connections φ [x ↔⊥] φ [x ↔⊥] env. γ [x 7→⊥] γ [x 7→u ] code x = u, ∆ ∆ ii.c connections φ [x ↔ y] φ [x ↔⊥][y ↔⊥] env. γ [x 7→⊥][y 7→⊥] γ [x 7→⊥][y 7→u ] code x = u, ∆ ∆ ii.e connections φ [x ↔⊥] φ [x ↔⊥] env. γ [x 7→ t ] γ [x 7→⊥] code x = u, ∆ t = u, ∆ ii.− code u = x, ∆ x = u, ∆ iii.0 0 connections φ [x ↔⊥][y ↔⊥] φ [x ↔ y] env. γ [x 7→⊥][y 7→⊥] γ [x 7→⊥][y 7→⊥] code x = y, ∆ ∆ iii.0 c connections φ [x ↔⊥][y ↔ w] φ [x ↔ w][y ↔⊥] env. γ [x 7→⊥][y 7→⊥] γ [x 7→⊥][y 7→⊥] code x = y, ∆ ∆ iii.0 e connections φ [x ↔⊥][y ↔⊥] φ [x ↔⊥][y ↔⊥] env. γ [x 7→⊥][y 7→u ] γ [x 7→u ][y 7→⊥] code x = y, ∆ ∆ iii.c 0 connections φ [x ↔ z][y ↔⊥] φ [x ↔⊥][y ↔ z] env. γ [x 7→⊥][y 7→⊥] γ [x 7→⊥][y 7→⊥] code x = y, ∆ ∆ iii.c c connections φ [x ↔ z][y ↔ w] φ [x ↔⊥][y ↔⊥][z ↔ w] env. γ [x 7→⊥][y 7→⊥] γ [x 7→⊥][y 7→⊥] code x = y, ∆ ∆ iii.c e connections φ [x ↔ z][y ↔⊥] φ [x ↔⊥][y ↔⊥][z ↔⊥] env. γ [x 7→⊥][y 7→u ] γ [x 7→⊥][y 7→⊥][z 7→u ] code x = y, ∆ ∆ iii.e 0 connections φ [x ↔⊥][y ↔⊥] φ [x ↔⊥][y ↔⊥] env. γ [x 7→ t ][y 7→⊥] γ [x 7→⊥][y 7→ t ] code x = y, ∆ ∆ iii.e c connections φ [x ↔⊥][y ↔ w] φ [x ↔⊥][y ↔⊥][w ↔⊥] env. γ [x 7→ t ][y 7→⊥] γ [x 7→⊥][y 7→⊥][w 7→ t ] code x = y, ∆ ∆ iii.e e connections φ [x ↔⊥][y ↔⊥] φ [x ↔⊥][y ↔⊥] env. γ [x 7→ t ][y 7→u ] γ [x 7→⊥][y 7→⊥] code x = y, ∆ t = u, ∆ figure 2: transitions ( γ | φ | t̄ | θ | ∆ ) =⇒ ( γ′ | φ ′ | t̄ | θ′ | ∆′) 9 / 12 volume 29 (2010) interaction nets definition 6 (consistency of a machine state) a state ( γ | φ | t̄ | θ | ∆ ) is consistent iff • 〈 t̄ | bγc,bφc, θ, ∆ 〉 is a configuration, thus every name occurs at most twice, • for every x ∈ n , x is not included in both domains of γ and φ . the following lemma shows that consistency is preserved during transitions: lemma 7 let m1 be a consistent state. if m1 =⇒ m2, then m2 is also consistent. let m1 and m2 be two abstract machine states. we define m1 ⇓ m2 by m1 =⇒∗ m2 where m2 is a =⇒−normal form. lemma 8 let m1 be a consistent state, if m1 ⇓ ( γ | φ | t̄ | θ | ∆ ), then ∆ is empty. proof. there exists a transition which can be applied to an equation t = s whenever ( γ | φ | t̄ | θ | t = s, ∆ ) is consistent. lemma 9 let m1 be a consistent state ( γ1 | φ1 | t̄ | θ1 | ∆1 ). if m1 =⇒ ( γ2 | φ2 | t̄ | θ2 | ∆2 ), then one of the following holds: • 〈 t̄ | bγ1c,bφ1c, θ1, ∆1 〉 = 〈 t̄ | bγ2c,bφ2c, θ2, ∆2 〉, • 〈 t̄ | bγ1c,bφ1c, θ1, ∆1 〉 int−→〈 t̄ | bγ2c,bφ2c, θ2, ∆2 〉, • 〈 t̄ | bγ1c,bφ1c, θ1, ∆1 〉 com−→〈 t̄ | bγ2c,bφ2c, θ2, ∆2 〉, • 〈 t̄ | bγ1c,bφ1c, θ1, ∆1 〉 com−→· com−→〈 t̄ | bγ2c,bφ2c, θ2, ∆2 〉. theorem 2 let 〈 t̄ | ∆ 〉 be a configuration. if ( [] | [] | t̄ |−| ∆ ) terminates at ( γ | φ | t̄ | θ | ∆′), then ∆′ is empty and 〈 t̄ | ∆ 〉⇓ic 〈 t̄ | bγc,bφc, θ 〉. proof. by lemma 8, ∆′ is empty. since ( γ | φ | t̄ | θ |−) is consistent by lemma 7, bγc and bφc cannot contain equations that are reducible using the communication rule. therefore, by lemma 9, 〈 t̄ | ∆ 〉⇓ic 〈 t̄ | bγc,bφc, θ 〉. definition 7 we define the operation update as follows: • update( γ | φ [x ↔ y] | t̄ | θ |−) = update( γ[x/y] | φ | t̄[x/y] | θ |−), • update( γ[x 7→ s] | [] | t̄ | θ |−) = update( γ[s/x] | [] | t̄[s/x] | θ |−), • update( [] | [] | t̄ | θ |−) = t̄. each execution of update corresponds to an application of either substitution or collect rules. therefore, we can show the following property: theorem 3 (correctness) let 〈 t̄ | ∆ 〉 be a configuration. if ( [] | [] | t̄ | − | ∆ ) ⇓ ( γ | φ | t̄ | θ | ∆′), then ∆′ is empty and there is a reduction path such that 〈 t̄ | ∆ 〉 ⇓ 〈 ū | θ′ 〉 where update( γ | φ | t̄ | θ |−) = ū. proc. gt-vmt 2010 10 / 12 eceasst amine light amine/light 255ii 14.07 0.09 156.33 264ii 50.02 0.14 357.29 256ii 119.93 0.23 521.43 a 3 6 4.14 0.18 23.00 a 3 7 40.15 0.71 57.04 a 3 8 612.19 1.70 360.11 table 1: the execution times in seconds on linux pc (2.6ghz, pentium 4, 512mbyte) example 3 the computation of 〈 r | add(r,z) = s(z) 〉 is given below: ( [] | [] | r |− |add(r,z) = s(z) ) =⇒ ( [] | [] | r |− | r = s(x),z = add(x,z) ) (i) =⇒ ( [r 7→s(x)] | [] | r |− |z = add(x,z) ) (ii.0) =⇒ ( [r 7→s(x)] | [] | r |− | x = z) (i) =⇒ ( [r 7→s(x)][x 7→z] | [] | r |− |−) (ii.0). update( [r 7→s(x)][x 7→z] | [] | r |− |−) = update( [r 7→s(z)] | [] | r |− |−) = s(z). 4.2 benchmark results we compare the lightweight version with pinto’s implementation (amine). both are written in c language. table 1 shows execution times in seconds of our implementation and amine. the final column gives the ratio between the two. the first three input programs are applications of church numerals where n = λ f .λ x. f nx and i = λ x.x. the encodings of these terms into interaction nets are given in [mac98]. the next programs compute the ackermann function. the following rules are the interaction net encoding of the ackermann function: pred(z) on z, dup(z,z) on z, pred(x) on s(x), dup(s(a),s(b)) on s(dup(a, b)), a(r,s(r)) on z, a1(pred(a(s(z), r)), r) on z, a(a1(s(x), r), r) on s(x), a1(dup(pred(a(r1, r)),a(y, r1)), r) on s(y), and a 3 6 means computation of 〈 r | a(s(s(s(s(s(s(z)))))), r) = s(s(s(z))) 〉. the results that we have obtained are better than previous implementation results, and allow substantially larger classes of functions to be executed very efficiently. depending on the architecture used, these results will vary slightly. we however invite the reader to try some of these examples by downloading our implementation: http://www.interaction-nets.org/. 5 conclusion the aim of this paper is to report on current work on the foundations of the implementations of interaction nets. specifically, we have presented a new implementation that is the most efficient to date. in the work where interaction nets are considered as an intermediate language for compilation, this work gives a speedup by a factor of ten or more. 11 / 12 volume 29 (2010) http://www.interaction-nets.org/ interaction nets implementation work for interaction nets is currently being investigated very actively, and although this step is a considerable one, we believe that there is still much more to do. our implementations are still very much prototype in nature, and no program optimisations have been included here. future work will be directed towards developing stable and efficient implementations for both sequential and parallel architectures. bibliography [abr93] s. abramsky. computational interpretations of linear logic. theoretical computer science 111:3–57, 1993. [ag98] a. asperti, s. guerrini. the optimal implementation of functional programming languages. cambridge tracts in theoretical computer science 45. cambridge university press, 1998. [fm99] m. fernández, i. mackie. a calculus for interaction nets. in nadathur (ed.), proceedings of the international conference on principles and practice of declarative programming (ppdp’99). lncs 1702, pp. 170–187. springer-verlag, 1999. ftp://lix.polytechnique.fr/pub/mackie/papers/calin.ps.gz [gal92] g. gonthier, m. abadi, j.-j. lévy. the geometry of optimal lambda reduction. in proceedings of the 19th acm symposium on principles of programming languages (popl’92). pp. 15–26. acm press, jan. 1992. [hms08] a. hassan, i. mackie, s. sato. interaction nets: programming language design and implementation. eceasst 10, 2008. [hms09] a. hassan, i. mackie, s. sato. compilation of interaction nets. electron. notes theor. comput. sci. 253(4):73–90, 2009. doi:http://dx.doi.org/10.1016/j.entcs.2009.10.018 [laf90] y. lafont. interaction nets. in seventeenth annual symposium on principles of programming languages. pp. 95–108. acm press, san francisco, california, 1990. [mac98] i. mackie. yale: yet another lambda evaluator based on interaction nets. in proceedings of the 3rd acm sigplan international conference on functional programming (icfp’98). pp. 117–128. acm press, september 1998. ftp://lix.polytechnique.fr/pub/mackie/papers/yalyal.ps.gz [mac05] i. mackie. towards a programming language for interaction nets. electronic notes in theoretical computer science 127(5):133–151, may 2005. [pin00] j. s. pinto. sequential and concurrent abstract machines for interaction nets. in tiuryn (ed.), proceedings of foundations of software science and computation structures (fossacs). lecture notes in computer science 1784, pp. 267–282. springerverlag, 2000. proc. gt-vmt 2010 12 / 12 ftp: //lix.polytechnique.fr/pub/mackie/papers/calin.ps.gz http://dx.doi.org/http://dx.doi.org/10.1016/j.entcs.2009.10.018 ftp: //lix.polytechnique.fr/pub/mackie/papers/yalyal.ps.gz introduction interaction nets the calculus for interaction nets refining the calculus properties of lightweight reduction rules lightweight abstract machine correctness benchmark results conclusion rule-based integration of domain-specific modelling languages electronic communications of the easst volume 42 (2011) proceedings of the 4th international workshop on multi-paradigm modeling (mpm 2010) rule-based integration of domain-specific modelling languages benjamin braatz, christoph brandt 12 pages guest editors: vasco amaral, hans vangheluwe, cécile hardebolle, lazlo lengyel managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst rule-based integration of domain-specific modelling languages benjamin braatz∗, christoph brandt secan-lab, université du luxembourg, http://wiki.uni.lu/secan-lab/ benjamin.braatz@uni.lu, christoph.brandt@uni.lu abstract: domain-specific modelling languages (dsmls) can increase the acceptance of (semi-)formal modelling techniques. they allow all stakeholders in an application domain to participate in the modelling process using notations that are close to their understanding of the domain. when several groups of stakeholders are concerned with a certain aspect of the modelled system, the question arises how different dsmls can be integrated with respect to this aspect. in this paper, we propose rule-based transformations as a means to integrate heterogeneous dsmls overlapping on dedicated aspects. we illustrate the approach by a running example of a small visual dsml for it landscapes and a textual dsml for firewall configurations. keywords: domain-specific modelling language, language integration, resource description framework, algebraic graph transformation 1 introduction our motivation for the work presented in this paper is to obtain a framework for the definition and management of families of domain-specific modelling languages (dsmls). we use the term dsmls to denote small, flexible, visual and textual languages that are tailored to the needs of their users in a certain application domain. among other features, this framework should allow families of integrated dsmls, which means that several dsmls—each created for a specific task or a specific group of users—are integrated on their common overlapping aspects. in section 2, we present a running example to illustrate this requirement. this running example comprises a visual dsml for it landscapes and a textual dsml for firewall configurations. we use the resource decription framework (rdf), defined in [kc04], to represent the abstract syntax of dsmls. this representation is introduced in section 3. since rdf is used as the fundamental data structure for the semantic web, it is well-suited for the distributed management of models in large organisations. with this choice, we expect to reduce the effort that is required for the creation of large integrated models from the knowledge of local users, while also allowing decentralised workflows. in section 4, we introduce algebraic graph transformations on rdf graphs. algebraic graph transformations for rdf were proposed and developed in [bb08, bra09]. they are used in our ∗ this author is supported by the national research fund, luxembourg, and cofunded under the marie curie actions of the european commission (fp7-cofund). 1 / 12 volume 42 (2011) http://wiki.uni.lu/secan-lab/ mailto:benjamin.braatz@uni.lu mailto:christoph.brandt@uni.lu rule-based integration of dsmls approach, an overview of which is given in [bb10a], to provide a single, uniform formalism for all kinds of modifications on models—editing, migration and integration. in section 5, we present the integration of the languages from the running example. the different tasks during the integration of two models are facilitated by dedicated transformation rules for the manual, automatic and semi-automatic integration steps. finally, in section 6 we discuss related work and give some concluding remarks in section 7. 2 running example in this section, we present a running example for the integration of a graphical and a textual language. the graphical language is a dsml for it infrastructures. the language is rather small and simple, but a similar language for the real world would in principle work on the same level of abstraction, tailored to the needs of the users and resembling the informal languages modellers use today. the textual language is a language for the configuration of firewalls, where we restrict ourselves to the specification of which ports are allowed in which direction. in figure 1, we show an example of the concrete syntax of these two languages and their integration. the landscape model on the right side shows some local area networks (lans), the internet as a wide area network (wan) and the connections between them, where most of them are protected by firewalls. for the firewalls, we also specify which protocols are allowed in which direction. the local network lan 1 is connected to the internet through a demilitarised zone (dmz). http queries are allowed from the internet to the dmz and vice versa and from lan 1 through a proxy in the dmz to the internet. moreover, lan 1 can reach a backup network via ssh. the firewall configurations on the left give a textual representation of the allowed protocols. fw1.example.com from if1 to if2 port 5432 allow; from if2 to if1 port 80 allow; fw2.example.com from if1 to if2 port 80 allow; fw3.example.com from if2 to if1 port 22 allow; from if2 to if1 port 53 allow; fw4.example.com from if1 to if2 port 22 allow; from if2 to if1 port 22 allow; lan 1 dmz lan 2 internet backup http http http ssh ssh fw1.example.com from if1 to if2 port 5432 allow; from if2 to if1 port 80 allow; fw2.example.com from if1 to if2 port 80 allow; from if2 to if1 port 80 allow; lan 1 dmz lan 2 internet backup if2 if1 if2 if1 if2 if1 if2 if1 httpdb http http ssh, dns ssh fw3.example.com from if2 to if1 port 22 allow; from if2 to if1 port 53 allow; fw4.example.com from if1 to if2 port 22 allow; figure 1: it landscape and firewall configurations—language integration proc. mpm 2010 2 / 12 eceasst during the integration, we first have to identify which textual firewall configuration corresponds to which firewall in the landscape diagram and which interface name to which connection. then, we can search for inconsistencies between the diagram and the configurations. in our example, we find that the allowance of http traffic from the dmz to the internet has to be added in the configuration of firewall fw2 and the database access from the dmz to lan 1 and the dns access from lan 1 to the internet were forgotten in the diagram. moreover, the configuration of firewall fw4 allowed outbound ssh traffic from the backup network to the internet which is not neccessary according to the diagram and, therefore, removed. 3 rdf graphs: abstract syntax of dsmls the resource description framework (rdf), defined in [kc04], provides the fundamental, generic data structure for the semantic web. it is used to state facts about resources that are identified by uniform resource identifiers (uris). the facts are given by subject–predicate–object triples, where the predicate is given by a uri and the object may also be a literal value. a set of facts is an rdf graph, where the subjects and objects are the nodes and the facts the edges of the graph, labelled with the corresponding predicate (which may also appear as a node). the idea is that everyone can publish such graphs to assert certain facts and these graphs can easily be joined to collect information from heterogeneous sources. in figure 2, we show how such a graph is used to represent part of an it landscape model. the local net lan 1 and the internet are represented by uris “mod:lan1” and “mod:inet”, respectively, where “mod:” is a suitable namespace, e. g., “http://models.example.com/”. the names of the networks, which are shown as inscriptions in the concrete visual representation, are given by literal values in the abstract syntax. the predicate “rdf:type” (abbreviated as “a”) is used to connect nodes with their types. the types as well as the predicates are defined in another namespace “itml:”, which, e. g., might be “http://schema.example.com/”. technically, it would be possible to use the same namespace for both, the language elements and the model instances, but separation of namespaces eases the distributed handling of schemas and (multiple) models by different groups of users. the connection between lan 1 and the internet is represented by a blank node “1”. blank nodes do not have a global identity and, hence, other graphs cannot state additional facts about entities identified by blank nodes. concrete syntax lan 1 internet abstract syntax itml:lan itml:connect itml:wan mod:lan1 1 mod:inet “lan 1” “internet”a =̂ rdf:type a a a itml:conn itml:conn itml:name itml:name figure 2: rdf graph representing the abstract syntax of a dsml model 3 / 12 volume 42 (2011) rule-based integration of dsmls in figure 3, we show how the additional notation for protocols in the it landscape language and the textual firewall configuration language are represented in rdf. in the landscape dsml, the arrows around the firewalls are represented by blank nodes with type “itml:flow”, “itml:src” and “itml:trg” predicates indicating the direction of the arrow and “itml:prot” predicates specifying which protocols are allowed in this direction. the firewall configuration language uses blank nodes of type “fwcl:rule” for each line in a firewall configuration, where the direction is given by “fwcl:from” and “fwcl:to” predicates and the corresponding port by a “fwcl:port” predicate. ssh, dns itml:fw mod:fw3 1 2 3 “ssh” itml:flow “dns” a itml: conn itml:conn itml:src itml: trg itml :pro t a itml:prot fw3.example.com from if2 to if1 port 22 allow; from if2 to if1 port 53 allow; fwcl:fw http://fw3.example.com/ “if2” “if1” 4 5 “22” fwcl:rule “53” a fwcl:iffwcl :if fwcl:from fwcl:from fwcl:t o fwc l:to fwc l:po rt a a fwcl:port figure 3: rdf representation of firewall configurations we choose to base our framework on rdf graphs rather than classical graphs, typed, labelled or attributed graphs for several reasons. they are designed to work well in distributed environments due to the use of uris for identifying nodes and predicates. with literal values as just another type of nodes they provide a lean formalisation for graphs with all kinds of attributations, where other approaches need much heavier formal machinery. last but not least, we want to be able to interface with the rest of the semantic web in the long run. regarding the semantics of the used languages, we restrict ourselves to an implicit semantics in this paper. in [usc03], the fact that not all applications using semantic web data structures necessarily also are “semantic” is discussed. and if they do, there are several levels of semantics—from informal up to machine-processable. as far as we know, there is not much work on formalising the kinds of semantics that are needed for heterogeneous modelling languages in the context of the semantic web–from operational semantics for behavioural techniques to denotational semantics for data type specifications. it is an interesting line of further research to develop ways to represent the semantics of dsmls in a way that is compatible with the idea of the semantic web, i. e., interoperable over distributed, heterogeneous systems and ideally also machine-processable. compared to the definition of languages by meta modelling, e. g., using the meta object facility (mof), defined in [obj06], the approach chosen here is very light-weight. rdf graphs are supposed to be defined in a distributed manner on the semantic web with the help of heterogeneous and extendable vocabularies. in contrast to that, mof enforces that every model strictly conforms to a meta model, which, therefore, has to anticipate all needs of the users. thus, the features of rdf ideally reflect the flexibility requirements of dsmls. proc. mpm 2010 4 / 12 eceasst in [obj09], proposals for a mapping from mof to rdf are requested. such a mapping would allow the representation of mof meta models and corresponding models as rdf graphs and, hence, facilitate the application of the methods of our approach to mof meta models and models. 4 algebraic graph transformations for rdf we use rule-based, algebraic graph transformations to describe all kinds of changes on rdf graphs in a declarative way. a comprehensive overview over the theory of algebraic graph transformation can be found in [eept06]. the adaption of this theory to rdf was proposed in [bb08] and continued in [bra09]. we choose algebraic graph transformation, since it allows to treat all kinds of transformations from language definition by grammars via model migration to language integration with a single, uniform formalism, which can be fully implemented. being a formal technique, it also allows to reason formally about the effects of transformations to show, e. g., that certain derived transformation rules respect a given graph grammar or that transformations are independent of each other and can, hence, be swapped without affecting the final result of the complete transformation sequence. transformations are defined by transformation rules. an example of such a rule is shown in figure 4. this rule removes a connection between two networks, represented by variables x and y and adds a new connection from network x to network z, where z is not allowed to be of type itml:wan and it is not allowed to introduce a self connection, i. e., to assign x and z to the same net. l α y x itml:connect z itm l:co nn itml:conn a l i y x itml:connect z r r y x itml:connect β z itml:conn itml:conn a c1 n1 α y x itml:connect itml:wan z itm l:co nn itml:conn a a c2 n2 α y x,z itml:connect itml:con n itml:conn a α {del} y x itml:connect β {add} z itml :con n {del } itml:conn {del} a {del} a {add} itml:conn {add} itml:conn {add} nacs: itml:wan z a x,z retargetconnection formal structure compact notation figure 4: example transformation rule retargetconnection the rule consists of several rdf patterns, which are graphs with additional variables, and rdf pattern homomorphisms, which are structure preserving maps connecting the patterns, where the homomorphisms l and r are injective, i. e., one-to-one (visualised by the hook at the tail of the 5 / 12 volume 42 (2011) rule-based integration of dsmls arrows). the difference between the left-hand side l and the interface i are the elements of the pattern that are supposed to be deleted and the difference between i and the right-hand side r are the elements that are supposed to be added by the rule. moreover, there is a set of negative application conditions (nacs), which are extensions of l and specify situations in which the rule is not applicable, where the nacs are in an implicit conjunction, i. e., all have to be satisfied and none of the situations is allowed. in the lower right, we show a compact notation for the rule, where irrelevant parts of the nacs are omitted and l, i and r are shown in a single diagram with the additional elements of l marked by “{del}” and the additional elements of r by “{add}”. in figure 5, we show the application of the transformation rule from figure 4 to an example graph. the application is determined by a match homomorphism m from the left-hand side l to the graph g. the application of the rule is then computed by two category theoretical constructions, namely a minimal pushout complement (mpoc) and a pushout (po). (see [ahs09] for an introduction to category theory.) intuitively, a pushout is a disjoint union over a common interface and used to add the additional blank nodes and facts of r to the context graph d. conversely, a minimal pushout complement is used to derive the context graph d by deleting the additional blank nodes and facts of l from g. l α y x itml:connect z itm l:co nn itml:conn a l i y x itml:connect z r r y x itml:connect β z itml:conn itml:conn a m (mpoc) i (po) n g itml:lan itml:connect itml:wan mod:net1 “net 1” 1 mod:net2 mod:net3 itml:lan f d itml:lan itml:connect itml:wan mod:net1 “net 1” mod:net2 mod:net3 itml:lan g h itml:lan itml:connect itml:wan mod:net1 “net 1” 2 mod:net2 mod:net3 itml:lan figure 5: application of transformation rule retargetconnection the use of rule-based graph transformations for modifying rdf graphs has several advantages. an implementation of a transformation engine may be reused for a multitude of purposes, where the search for matches and the transformation only have to be implemented once and for all. modifications are specified on an adequate level of abstraction and automatically respect a given grammar if they are composed from it, which is also the main advantage of using grammars for language definition instead of meta modelling. moreover, a single, uniform formalism can be used for language definition, syntax-directed editing and complex modifications. in the following section, we show how algebraic graph transformation rules can be used to specify the integration of several dsmls on overlapping aspects. proc. mpm 2010 6 / 12 eceasst 5 integration of languages since, the landscape language uses the names of protocols and the configuration language uses port numbers, we need a mapping between them, before we can start our integration effort. this mapping is given in figure 6, where blank nodes with corresponding int:prot and int:port predicates are used to represent this relation. “http” 1 “80” “ssh” 2 “22” “dns” 3 “53” “db” 4 “5432” in t:p ro t int:port in t:p ro t int:port in t:p ro t int:port in t:p ro t int:port figure 6: mapping between protocols and ports for integrating several dsmls, we define some sets of rdf graph transformation rules. first, the rules in figure 7 are used to manually establish the connection between the firewalls in the landscape model and the corresponding configuration language snippets and the connections in the landscape and the corresponding interfaces in the configurations. this has to be done manually, since there is not enough information in the models to deduce these correspondences automatically. it is a constructive choice. itml:fw x fwcl:fw y a a int:fw {add} nacs: x z int:fw z y int:fw intfwtofw x c y i itm l:c on n fw cl: if int:fw int:if {add} nacs: c j int:if d i int:if intconntoif figure 7: manual integration rules the rule in figure 8 can be used to automatically add lines to the firewall configurations, where there is an additional protocol that is allowed according to the landscape model. this rule can be applied as long as possible, since we decide to consider the landscape model as superior in these situations. c d α itml:flow p m i j β {add} fwcl:ruleq itml:src itm l:tr g a itml:prot fwcl:from{add} fw cl:t o {ad d} a {add}fw cl:p ort {ad d} int:if int:if in t:p ro t int:port nacs: i j β fwcl:ruleq fwcl:from fwc l:to afw cl:p ort intflowtorule figure 8: automatic integration rule 7 / 12 volume 42 (2011) rule-based integration of dsmls if there is a line in the firewall configurations that has no corresponding protocol in the landscape model then the rules in figure 9 are used. these rules are supposed to be applied semiautomatically. the matches can be found automatically, but in each case two of the rules are applicable and the user has to decide which should be applied. either the protocol is added to the landscape model by one of the first two rules—intruletoexflow if there is already another protocol in the same direction, intruletononexflow if the arrow also needs to be created—or the line is deleted from the firewall configuration by the third rule intdelrule. c d α itml:flow p m i j β fwcl:ruleq itml:src itm l:tr g a itml:prot{add} fwcl:from fwc l:to afw cl:p ort int:if int:if in t:p ro t int:port nacs: α p itml:prot intruletoexflow c d α {add} itml:flow p m i j β fwcl:ruleq itml:src{add} itm l:tr g {ad d} {add} a itml:prot {add} fwcl:from fwc l:to afw cl:p ort int:if int:if in t:p ro t int:port nacs: c d α itml:flow itml:src itm l:tr g a intruletononexflow c d p m i j β {del} fwcl:ruleq fwcl:from{del} fw cl:t o {de l} a {del}fw cl:p ort {de l} int:if int:if in t:p ro t int:port nacs: c d α itml:flow p itml:src itm l:tr g a itml:prot intdelrule figure 9: semi-automatic integration rules the distinction between manual, automatic and semi-automatic rules is not visible in the rules themselves, since they are all of the same kind as defined in section 4. rather, the distinction will be made in the metadata of the rules in a future implementation, where the difference lies in the treatment of the matches. for the manual rules, the user is required to provide the match for rule applications, where the implementation can guide her on the choice of matches that are legal w. r. t. the application conditions. for the automatic and semi-automatic rules, the implementation is supposed to apply them on all possible matches, where the difference is that there are several conflicting possibilities in the semi-automatic case, which have to be resolved by the user. table 1 shows a comparison of this rule-based model integration with the process of manually integrating models or documents. in any case, the search for inconsistencies is replaced by the proc. mpm 2010 8 / 12 eceasst automatic match-finding for the integration rules. for the deterministic cases that lead to the automatic integration rules in figure 8, the integration can be completely executed without user intervention, while for the non-deterministic cases that lead to the semi-automatic integration rules in figure 9, the user still has to decide which of the two possibilities should be executed. when trying to manually integrate models, the much more error-prone task of constructing inconsistency eliminations is required, while these eliminations are given once and for all in the rule-based approach. thus, the integration by rule-based graph transformation leads not only to less effort for the integration but also to quality gains by reducing missed inconsistencies and inappropriate eliminations. table 1: comparison of rule-based and manual integration rule-based integration manual integration deterministic 1. automatic match-finding find inconsistencies 2. automatic elimination by rules eliminate inconsistencies 1. automatic match-finding find inconsistencies non-deterministic 2. alternatives given by rules construct alternatives 3. decision on alternatives this methodology can also be used to integrate models from other modelling approaches that have a translation to rdf. for example, once a mof to rdf mapping, as requested in [obj09] and already mentioned at the end of section 3, is provided, models of mof-based languages can be integrated with each other and with native languages in our framework. moreover, rdf graph transformation rules can also be used to completely translate models between languages, which is, however, outside the scope of the present paper. 6 related work in [afr06], the authors evaluate several dsml tools, which were available at that time, w. r. t. a catalog of criteria. one of those criteria is the integration with other languages. the tools that fulfil this criterion achieve integration either by building on uml or by technological integration via the eclipse platform. it remains unclear how gaps between similar but slightly different concepts and structures are bridged in these solutions. we believe that our approach of rulebased linking and modification of the models is the right answer to this problem. in fact, most integrated modelling language families, e. g., the domain-specific itml family, presented in [fhk+09], and the uml, specified in [obj10], achieve language integration a priori by defining the common aspects on which the different languages overlap. in contrast to that, our approach allows an a posteriori integration of languages that were designed without knowledge of each other. there are several approaches to language integration based on the triple graph grammar (tgg) formalism. for example, tggs are used on top of the meta modelling environment atom3 in [gl08], the mosl language, presented in [akr06], is the basis of the moflon meta modelling framework and uses tggs in connection with mof, ocl and story diagrams, 9 / 12 volume 42 (2011) rule-based integration of dsmls and language integration with tggs is theoretically examined in [eeh08]. in tggs, the connections between two languages are described by three graphs, one for each of the languages and a third one describing the connection by morphisms into the other two. this structure is simultaneously built up by a tgg, where translation rules in both directions and integration rules can be derived from the tgg. while our approach requires to design integration and possibly also translation rules manually, it also adds the flexibility to decide for the concrete case which is the adequate way to integrate a certain situation. for example, for the language integration of the present paper, it is a design decision that additional elements in the network diagram are transferred to the firewall configurations automatically, while additional rules in the firewall configurations require a user decision if they are to be added to the diagram or deleted from the configuration. such an effect would be cumbersome to achieve with tggs if it is at all possible. moreover, the treatment of all models in the same graph structure—a giant global graph (cf. [bl07])—seems to be more appropriate for the semantic web and relieves us from managing multiple graphs. in the context of the semantic web and knowledge management, the problem of mapping different ontologies is related to our present work. see [csh06] for a survey on different approaches to ontology mapping. our approach to integration is complimentary to the problem of ontology mapping, alignment and integration. while we take the relations between the heterogeneous dsmls as given by a user of our framework and provide means for integrating instances of the dsmls, ontology mapping approaches try to find similarities between concepts in heterogeneous ontologies (semi-)automatically, but usually do not provide means for complex structural changes in the instance integration process as they are provided by our approach. 7 summary and future work in this paper, we have shown how graph transformation rules can be used to integrate domainspecific models that overlap on certain aspects. we have used rdf graphs for the abstract syntax of domain-specific models. algebraic graph transformation provides a single formalism that can be used not only for the manual, automatic and semi-automatic integration tasks shown in this paper but also for specifying domain-specific modelling languages by graph grammars and for providing complex modifications like refactorings. the main contribution of this paper is to show how our combination of rdf and algebraic graph transformation can be used for dsmls and especially to integrate heterogeneous dsml models. the main benefits are the relatively lean abstract syntax graphs in comparison to, e. g., mof, the possibility to treat heterogeneous models in a single, distributed graph structure, which is achieved by using rdf, and the use of the single formalism of algebraic graph transformation for all kinds of tasks from language definition to integration. the limits are the need to bridge the technological gap if models from other approaches need to be imported or accessed and, up to now, the lack of an implementation of this framework. currently, we are implementing this graph transformation on top of an rdf triple store. this leads to a transformation engine, which can be used as a model repository for families of domainspecific modelling languages according to the concepts presented in this paper. a sketch of the architecture and protocol of this transformation engine can be found in [bb10b]. proc. mpm 2010 10 / 12 eceasst references [afr06] d. amyot, h. farah, j.-f. roy. evaluation of development tools for domainspecific modeling languages. in gotzhein and reed (eds.), proc. sam 2006. lncs 4320, pp. 183–197. springer, 2006. doi:10.1007/11951148_12 [ahs09] j. adámek, h. herrlich, g. e. strecker. abstract and concrete categories: the joy of cats. dover, 2009. http://katmat.math.uni-bremen.de/acc/ [akr06] c. amelunxen, a. königs, t. rotschke. mosl: composing a visual language for a metamodeling framework. in proc. vl/hcc 2006. pp. 81–84. ieee, 2006. doi:10.1109/vlhcc.2006.33 [bb08] b. braatz, c. brandt. graph transformations for the resource description framework. in ermel et al. (eds.), proc. gt-vmt 2008. electronic communications of the easst 10. 2008. http://journal.ub.tu-berlin.de/index.php/eceasst/article/view/158 [bb10a] b. braatz, c. brandt. domain-specific modelling languages with algebraic graph transformations on rdf. in proc. sle 2010. 2010. http://planet-sl.org/sle-conference/index.php?option=com_content&task=view&id= 162&itemid=228 [bb10b] b. braatz, c. brandt. how to modify on the semantic web? a web application architecture for algebraic graph transformations on rdf. in proc. swim 2010. 2010. http://mais.dia.uniroma3.it/swim2010/accepted_papers.html [bl07] t. berners-lee. giant global graph. blog post, nov. 2007. http://dig.csail.mit.edu/breadcrumbs/node/215 [bra09] b. braatz. formal modelling and application of graph transformations in the resource description framework. phd thesis, technische universität berlin, 2009. [csh06] n. choi, i.-y. song, h. han. a survey on ontology mapping. acm sigmod record 35(3):34–41, sept. 2006. doi:10.1145/1168092.1168097 [eeh08] h. ehrig, k. ehrig, f. hermann. from model transformation to model integration based on the algebraic approach to triple graph grammars. forschungsbericht 2008-03, fakultät iv, technische universität berlin, 2008. http://www.eecs.tu-berlin.de/fileadmin/f4/techreports/2008/2008-03.pdf [eept06] h. ehrig, k. ehrig, u. prange, g. taentzer. fundamentals of algebraic graph transformation. monographs in theoretical computer science. springer, 2006. doi:10.1007/3-540-31188-2 11 / 12 volume 42 (2011) http://dx.doi.org/10.1007/11951148_12 http://katmat.math.uni-bremen.de/acc/ http://dx.doi.org/10.1109/vlhcc.2006.33 http://journal.ub.tu-berlin.de/index.php/eceasst/article/view/158 http://planet-sl.org/sle-conference/index.php?option=com_content&task=view&id=162&itemid=228 http://planet-sl.org/sle-conference/index.php?option=com_content&task=view&id=162&itemid=228 http://mais.dia.uniroma3.it/swim2010/accepted_papers.html http://dig.csail.mit.edu/breadcrumbs/node/215 http://dx.doi.org/10.1145/1168092.1168097 http://www.eecs.tu-berlin.de/fileadmin/f4/techreports/2008/2008-03.pdf http://dx.doi.org/10.1007/3-540-31188-2 rule-based integration of dsmls [fhk+09] u. frank, d. heise, h. kattenstroth, d. f. ferguson, e. hadar, m. g. waschke. itml: a domain-specific modeling language for supporting business driven it management. in rossi et al. (eds.), proc. dsm 2009. hse b-108. 2009. http://www.dsmforum.org/events/dsm09/papers/heise.pdf [gl08] e. guerra, j. de lara. meta-modelling and graph transformation for the definition of multi-view visual languages. in ferri (ed.), visual languages for interactive computing: definitions and formalizations. chapter iv, pp. 74–101. information science reference, 2008. http://astreo.ii.uam.es/~jlara/multipleviews.pdf [kc04] g. klyne, j. j. carroll. resource description framework (rdf): concepts and abstract syntax. world wide web consortium (w3c), feb. 2004. http://www.w3.org/tr/2004/rec-rdf-concepts-20040210/ [obj06] object management group (omg). meta object facility (mof) core specification. jan. 2006. http://www.omg.org/spec/mof/2.0/ [obj09] object management group (omg). request for proposal. mof to rdf structural mapping in support of linked open data. dec. 2009. http://www.omg.org/cgi-bin/doc?ad/2009-12-09 [obj10] object management group (omg). omg unified modeling language (omg uml). may 2010. http://www.omg.org/spec/uml/2.3/ [usc03] m. uschold. where are the semantics in the semantic web? ai magazine 24(3):25– 36, fall 2003. http://www.aaai.org/ojs/index.php/aimagazine/article/view/1716 proc. mpm 2010 12 / 12 http://www.dsmforum.org/events/dsm09/papers/heise.pdf http://astreo.ii.uam.es/~jlara/multipleviews.pdf http://www.w3.org/tr/2004/rec-rdf-concepts-20040210/ http://www.omg.org/spec/mof/2.0/ http://www.omg.org/cgi-bin/doc?ad/2009-12-09 http://www.omg.org/spec/uml/2.3/ http://www.aaai.org/ojs/index.php/aimagazine/article/view/1716 introduction running example rdf graphs: abstract syntax of dsmls algebraic graph transformations for rdf integration of languages related work summary and future work //.psf/aktuell/refinf/papers/icongmt/gmt2010/gmt2010.dvi electronic communications of the easst volume 30 (2010) international colloquium on graph and model transformation on the occasion of the 65th birthday of hartmut ehrig (gramot 2010) position paper: formal methods in agile development michael löwe 6 pages guest editors: claudia ermel, hartmut ehrig, fernando orejas, gabriele taentzer managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 eceasst position paper: formal methods in agile development michael löwe fhdw hannover abstract: modern software development must be agile. it has to accept that software systems undergo a lot of changes due to changes in the application context (for example changing conditions on the markets and changes due to the jurisdiction) and base technology (e.g. integration of new frameworks or updates of the platform) in their life cycle. thus, most of the activities in the development process are redesign steps. even requirements are not stable. they change in time as the context of the system changes. there is no time for complex correctness proofs of the implementation with respect to the requirements. automatic (regression) testing has proved to be sufficient for correct system behaviour. therefore the agile developer does not learn and apply formal methods himself. in order to be agile, however, he relies on tools for automatic refactoring of the system or of certain parts of it. these tools are able to change the system structure without changing its behaviour. we argue in this paper that, in order to build such tools, further research in the area of formal system modelling and development is needed.1 keywords: agile software development, software refactoring, graph transformation 1 introduction there have been two major trends in software engineering for the last decade: 1. raising the level of abstraction for software systems design (vertical development) and 2. providing (more sophisticated) methods for agile development (horizontal development). notions like ”model-driven development”[bbg05], ”service-oriented architectures”[kbs05], and ”business process modelling”[wes07] are connected to the first trend. the second trend is characterized by concepts like ”software refactoring”[fow99], ”test-first”[bec02], ”extreme programming”[jah00] or ”dynamic systems development”[sta97]. in the first area, formal methods, especially graph transformations, have provided precise semantics for model specifications and transformation concepts from abstract to concrete system descriptions including correctness notions for static as well as dynamic models (i. e. data structures and process models respectively). the level of abstraction that is provided to the standard programmer today by software development environments, modern design and programming languages and especially by program generation tools can hardly be increased. and the mapping 1 the position paper is comprehensive. the references just provide some hints for further reading. they are not meant to be complete or comprehensive for the research area of software evolution and the application of graph transformations in this field. 1 / 6 volume 30 (2010) position paper: formal methods in agile development of abstract levels (with unique semantics) to concrete machine oriented levels can be performed almost automatically and without any interference of the designer. vertical development of the functional aspects of a system from a very abstract level to the concrete level of execution is a high-level compilation process nowadays. research in formal methods has done a good job here. educating the designers such that they can handle the abstractions is the challenge today. in the second area, formal methods have not been applied that much, yet [mt04, mvdj05]. at first glance, agility and formal preciseness do not go together well. we argue in this position paper against this first impression and show that there is great potential for graph transformation techniques in agile contexts. 2 agile development the agenda for agile development is provided by the ”manifesto for agile software devolpment” by kent beck et al.: we are uncovering better ways of developing software by doing it and helping others do it. through this work we have come to value: individuals and interactions over processes and tools working software over comprehensive documentation customer collaboration over contract negotiation responding to change over following a plan that is, while there is value in the items on the right, we value the items on the left more. agile development accepts that nothing is stable in software development. requirements might change dramatically if, for example, customers use first rapid system prototypes. they learn what they want by using what the thought they have wanted. due to these rapid changes, there is no time for an orderly formal development process that enforces correctness proofs of the implemented system wrt. the requirements. if there were such proofs, not only the software has to be refactorized frequently but also these proofs would have to be rewritten over and over again. thus, formal methods do not seem to be applicable in agile contexts. and agile developers are not very likely to appreciate education in these techniques. but there is a different level, where formal methods can support agile processes. the rapid redesign of software systems is not chaotic. it is a continuous process that introduces, changes or removes system structure, mostly without changing the external (functional) behaviour of the system. hence, what is needed is a catalogue of evolution patterns that improve the system’s structure to a certain extent and preserve system semantics (incl. proof). the application of these patterns needs to be automated by a tool (like for example refactorizations in eclipse) and delivered to the agile developer. practical applicability, however, requires that we do not restrict ourselves to the level of static and dynamic models only. since agile development aims at quick system development and early production with the system under development, we have to take into account that the models are populated. this means that there is (typically giga-bytes of) data typed in the static model2 2 for agile database development see [amb03, amb06]. proc. gramot 2010 2 / 6 eceasst and (lots of) running processes typed in the dynamic model3. thus, evolution patterns have to provide canonically induced and correct migrations on the instance level as well. therefore, formal methods that support agile development shall provide 1. suitable models for ”populated” systems (model and instance), 2. formal concepts for model refactorisations and induced instance migrations, 3. notions of correctness for such refactorisations/migrations, and 4. a catalogue of practically useful and correct patterns. the existing body of concepts and results within the research area of ”graph transformation” seems to be a good starting point for this programme: (1) graphs and graph-like structures provide a good formal model for almost all software structures (e.g. class models, activity diagrams, state diagrams, call graphs, data flow structures, control flow or petri nets) and (2) the rulebased transformation process is able to provide semantics to practical rule-based transformations like xsl-transformation for xml-based languages or xtend/xpand in openarchitectureware for model-driven development[ope]. 3 formal model for systems: model and instance agile software development modifies complete running systems. it is not only the information, the operation, or the process model that is changed by refactorisations. this change also comprises at least the current system state. this state is made up by all the data that is accessible by the system (usually in a database) and the current point (or points in the case of multi-threading) of execution. therefore, suitable formal models must be able to specify system models together with system states. a formal model for instance for object-oriented concepts must comprise the class model, the specification of the operations and methods, the currently existing object world, and the current execution context, i. e. the already sent but not yet executed messages and their execution order. if we include explicit process models (for example specified in the business process modelling notation bpmn [wes07]) into our framework, the state can get even more complex. having the process model at hand, the current state not only comprises information about the current execution context but also the process history that has led to the current state. additionally, the indeterministic future of the process (starting at the current point of execution) can be thought of as part of the current state. the model and the state cannot be considered separately. the state is always determined by the model which is usually expressed by a typing relation between state items and elements in the model. for a formal framework of agile development this typing relation is central, since model changes must lead to minimal state restructurings that allow correct retypings. in the context of graph transformation, a suitable model for the typing relation can be given by a morphism from the state graph into the model graph. 3 for process evolution see for example [ab02]. 3 / 6 volume 30 (2010) position paper: formal methods in agile development 4 refactorisations and induced migrations agile development demands automatic refactorizations of whole systems (models and states). if state migrations have to be calculated or performed manually (or by time consuming batch jobs), development becomes slow and looses its agility. since the state continuously changes in a running system, the only way to initiate general changes is to change the model (which is constant while the state is changing). therefore state migrations shall (1) be uniquely induced by model changes and (2) must be executable without any interactions of the developer. it depends on the type of system that is developed whether it can be switched off during migration. real-time embedded systems in critical applications for example can never be switched off. and service orientation requires minimal down-time also for modern information systems. thus, a framework for agile development must provide some means for migration on demand: the state is not changed completely, it is changed step by step as the execution wrt. the new model proceeds and requires retyped state structures. this mechanism requires (i) model versioning, (ii) coexistence of different models within the running system, and (iii) (partial) typings of the same state into different models. in the context of graph transformation, model changes can be expressed by simple graph transformation rules and their application. the canonical extension of the model change to the existing state requires some kind of universal quantification (perform the model change for all instances), which is not a standard mechanism in many approaches to graph transformations. 5 correctness of migrations a formal framework for agile development can provide proof methods by which tool designers can show that their migrations do change the system structure but not its observable behaviour. such proofs are valuable since the tool user can rely on the correctness of the transformation without knowing the formal languages in which the proof was formulated. the basis for such proof methods is formal semantics for complete systems. (the semantics depends on the chosen notion of state!) here well-known notions from for example algebraic specification (observable equivalence) or process algebra (bisimulation) can be reused. if a transformation cannot be proven generally correct for all system states but only for a certain class of states, appropriate tool support shall be provided that checks the required properties of the state. graph transformation techniques for proving invariants of the generated graph language can support the efforts towards such proof methods. 6 catalog of and tool support for correct evolution patterns all the work that has been sketched in the previous sections has one aim, namely a catalog of (partially) correct evolution patterns and its implementation within a software development environment or some software generation tool and if migration on demand is realized the runtime environment of the execution language. this catalog shall amongst others comprise patterns for the • introduction of new structure proc. gramot 2010 4 / 6 eceasst • removal of unused structure • introduction and removal of abstractions (observer, composite, state, etc.) • introduction (and removal) of structural indirection (adapter, proxy, visitor, etc.) • introduction (and removal) of operational indirection (command, event, etc.) • introduction (and removal) of transaction support • introduction (and removal) of locking strategies • introduction (and removal) of versioning and historization • introduction and removal of parallelism • decomposition of process steps • merging of process steps • introduction (and removal) of process alternatives • introduction (and removal) of remote communication and distribution structure the documentation of the patterns can be provided as some sort of graph transformation rules. 7 conclusion in this position paper, we have argued that formal system modelling and transformation can support agile software development. it provides urgently needed concepts and tools for the consistent and correct transformation of complete and running systems. while object-oriented modelling and programming has become a quasi-standard in the software community, the approaches, languages, and methods in the research area of graph transformation are still very different4 in order to produce some remarkable effect on the application domain of agile development (and other application areas), some standardization towards the graph transformation language, framework and development environment is needed. bibliography [ab02] w. m. p. van der aalst, t. basten. inheritance of workflows: an approach to tackling problems related to change. theor. comput. sci. 270(1-2):125–203, 2002. [agg] the agg 1.5.0 development environment the user manual. http://user.cs.tuberlin.de/ gragra/agg/agg-shortmanual/agg-shortmanual.html. 4 there are many different languages. even within one approach, there are some variants. in the algebraic approach, for example, there are the double-pushout [eept06], the single-pushout [löw93], and the sesqui-pushout approach [chhk06]. there are different tools with strengths and weaknesses that cannot be combined with each other easily, for example [agg] or [fuj]. 5 / 6 volume 30 (2010) position paper: formal methods in agile development [amb03] s. ambler. agile database techniques. wiley, 2003. [amb06] s. ambler. refactoring databases: evolutionary database design. addisonwesley, 2006. [bbg05] s. beydeda, m. book, v. gruhn (eds.). model-driven software development. springer, 2005. [bec02] k. beck. test driven development by example. addison-wesley, 2002. [chhk06] a. corradini, t. heindel, f. hermann, b. könig. sesqui-pushout rewriting. in corradini et al. (eds.), icgt. lecture notes in computer science 4178, pp. 30–45. springer, 2006. [eept06] h. ehrig, k. ehrig, u. prange, g. taentzer. fundamentals of algebraic graph transformation. springer, 2006. [fow99] m. fowler. refactoring: improving the design of existing code. addison-wesley, 1999. [fuj] fujaba tool suite. http://www.fujaba.de/about-fujaba.html. [jah00] r. jeffries, a. anderson, c. hendrickson. extreme programming installed. addison-wesley, 2000. [kbs05] d. krafzig, k. banke, d. slama. enterprise soa: service oriented architecture best practices. prentice hall, 2005. [löw93] m. löwe. algebraic approach to single-pushout graph transformation. theor. comput. sci. 109(1&2):181–224, 1993. [mt04] t. mens, t. tourwé. a survey of software refactoring. ieee trans. software eng. 30(2):126–139, 2004. [mvdj05] t. mens, n. van eetvelde, s. demeyer, d. janssens. formalizing refactorings with graph transformations. journal on software maintenance and evolution: research and practice, 2005. [ope] openarchitectureware group. openarchitectureware user guide version 4.3.1. www.openarchitectureware.org. [sta97] j. stapleton. dsdm business focused development: the method in practice. addison-wesley, 1997. [wes07] m. wespe. business process management. springer, 2007. proc. gramot 2010 6 / 6 electronic communications of the easst volume 30 (2010) international colloquium on graph and model transformation on the occasion of the 65th birthday of hartmut ehrig (gramot 2010) second-order value numbering tiziana margaria, bernhard steffen and christian topnik 15 pages guest editors: claudia ermel, hartmut ehrig, fernando orejas, gabriele taentzer managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 eceasst second-order value numbering tiziana margaria1, bernhard steffen2 and christian topnik2 chair service and software engineering, university of potsdam 1margaria@cs.uni-potsdam.de, chair programming systems, tu dortmund 2steffen@cs.uni-dortmund.de abstract: we present second-order value numbering, a new optimization method for suppressing redundancy, in a version tailored to the application for optimizing the decision procedure of jmosel, a verification tool set for monadic second-order logic on strings (m2l(str)). the method extends the well-known concept of value numbering to consider not merely values, but semantics transformers that can be efficiently pre-computed and help to avoid redundancy at the 2nd-order level. since decision procedures for m2l are non-elementary, an optimization method like this can have a great impact on the execution time, even though our decision procedure comprises the analysis and optimization time for second-order value numbering. this is illustrated considering a parametric family of hardware circuits, where we observed a performance gain by a factor of 3. this result is surprising, as the design of these circuits exploits already structural similarity. keywords: program analysis and optimization, monadic second-order logic, (second-order) value numbering 1 introduction value numbering is a well-known compiler optimization technique used to efficiently detect and eliminate redundant code by identifying equality of values [cs70, awz88]. considering this (first order) concept there is a natural generalization to second-order (or even higher-order in general): rather than considering just values, one could lift the analysis to second-order by considering semantics transformers, which may then be efficiently pre-computed and help to avoid redundancy at the second-order level. in this paper we introduce second-order value numbering and illustrate its impact by applying it to improve the decision procedure of jmosel [twms06], a verification toolset for monadic second-order logic on strings (m2l(str)). m2l [chu63] is an extremely expressive specification language with a non-elementary decision procedure. this makes jmosel a good candidate for our new optimization technique, as there is room even for ambitious optimizations due to the huge leverage potential. our experiments support this judgement: we observed a performance gain of a factor of three when analyzing a parametric family of hardware circuits, despite the fact that the optimized decision procedure includes the analysis and optimization time for 2nd-order value numbering as well. this result is surprising, as the design of these circuits exploits already structural similarity. please note that our technique is quite general, and not restricted to the considered application domain. 1 / 15 volume 30 (2010) second-order value numbering this paper is organized as follows: section 2 provides an introduction to the jmosel toolset including the definition of its syntax and semantics. first-order value numbering in the jmosel context is explained in section 3, while section 4 introduces second-order value numbering together with a detailed discussion of a minimal example. subsequently, section 5 illustrates our new method along a realistic case study, before we conclude with section 6. 2 jmosel jmosel is a toolset for m2l(str) that computes the semantics of a formula in terms of a finite state automaton. in this sense, it can be seen as a compiler from this logic into automata models. a detailed presentation of the tool can be found e.g. in [twms06]. its underlying concepts and the predecessor mosel have been presented in [mar96, kmmg97]. the following subsections summarize the required background about jmosel and m2l. 2.1 syntax jmosel’s several user-level logics are built on top of the following minimal logic, which already provides the full expressive power of m2l(str): t ::= id a ::= subseteq(t,t) | shifteq(t,t) f ::= a | ˜ f | f & f | ex id: f | (f) in this bnf, the non-terminal t denotes 2nd-order terms in form of (2nd-order) variables id. atomic predicates a allow comparisons in terms of subset relation and equality after bit-shifting. jmosel’s minimal logic formulas, denoted by the non-terminal and start symbol f, may be constructed using the standard operators of (a minimal) first-order logic. for convenience, we will later also use the usual derived operators like disjunction (here written |), implication and logical equivalence. 2.2 semantics in m2l(str) formulas are interpreted as sets of (ordered) positions in a string of arbitrary, but finite length, which can be conveniently described as finite bitvectors, i.e. a finite word over the alphabet {0,1}. one often refers to the interpretation of these bitvectors as characteristic functions that describe subsets of a given ordered set. typical is their interpretation as finite set of natural numbers, illustrated in figure 1. 10 1 0 1. . . 0, 2, 3, $ x: set x: position: { } 1 figure 1: a set of positions set x and the corresponding bit vector x. proc. gramot 2010 2 / 15 eceasst the bit vector corresponding to a string variable x has value 1 at position n iff n ∈ n0 is included in x , and value 0 otherwise. the figure shows a set x containing the positions 0, 2, 3 and $, its representation as a characteristic set, and its corresponding bit vector. here, the symbol $ stands for the last position in the parametric string, and therefore marks the last bit in the bit vector; a special symbol for this last position is necessary since m2l(str) allows reasoning about strings of finite but arbitrary length, a convenient model for parametric hardware components. the following development will entirely foot on the bit vector interpretation of m2l(str), which we formally define below. semantics of jmosel formulas jmosel translates formulas into complete and deterministic finite automata (dfa) in such a way that the language recognized by one such automaton corresponds to the formula’s interpretation as a bit vector. accordingly, the semantics of a formula is defined via the function j k : φ −→ α , where φ is the set of all jmosel formulas and α is the set of all complete dfas. definition 1 (boolean automaton) a boolean automaton a of α is defined as a = (σ,s,s0,f,δ ), where • σ is the set of all edge labels, which themselves denote subsets of the set of free variable v in the considered formula. they are represented as bitvectors of length |v |. • s is the set of all states. • s0 is the initial state, s0 ∈ s. • f is the set of accepting states f ⊆ s. • δ is the transition function defined as δ : s × σ −→ s. the edge labels determine for every string variable the boolean value at position n, whenever this label is taken as nth step of an accepting run. the number of edge labels is exponential in the size of the formula’s free variables, since the value of every variable v ∈ v has to be checked for equality with 0 or 1. therefore, each label consists of a bit vector of length |v |. boolean automata typically have very many edges between two nodes. we therefore construct the following equivalent symbolic automaton as, whose edges are labelled with boolean functions and therefore compactly represent a set of edges of the original automaton. definition 2 (symbolic automaton) a symbolic automaton as is defined as as = (l ,s ,s0,f ,δ ), where • l is the set of all possible edge labels, consisting of boolean functions. • s is the set of all states. • s0 is the initial state, s0 ∈ s . • f is the set of all accepting states, f ⊆ s . 3 / 15 volume 30 (2010) second-order value numbering t t 0 1 2 ... $ − 1 $ x x0 x1 x2 ... x$−1 x$ y y0 y1 y2 ... y$−1 y$ ... ... ... ... . . . ... ... z z0 z1 z2 ... z$−1 z$ figure 2: values for 2nd-order variables t t ... i ... w ... 0 ... x ... 1 ... y ... 0 ... z ... 1 ... figure 3: representation of edge label ˜w & x & ˜y & z • δ is the transition function defined as δ : s × l −→ s . to describe the transformation from a to as, we observe that values for a jmosel formula’s 2nd-order variables can be represented in table form, where a variable x is expressed as bit vector with position literals x0,x1,...,x$−1,x$. the ordering of variables is arbitrary but fixed. a row for a variable x in fig. 2 represents a word of the language jx k. every column of the table specifies one input symbol of a and must therefore match an appropriate edge label. the position j in this label corresponds to the variable at position j in the ordering of variables. to convert a into an automaton as with boolean formulas as edge labels, the labels of a are first transformed as shown in fig. 3. subsequently, edges sharing the same source and target state are merged; the resulting edge is labelled with the disjunction of the merged edges’ labels. the formulas for the edge labels resulting from this transformation may be large, but their bdd representations are canonical and typically nice and concise [bry86]. the jmosel toolset supports various bdd libraries to optimally exploit this observation. semantic completeness: note that a symbolic automaton as composed this way is typically not complete: its input alphabet consists of all boolean functions, but not every state considers the input of every possible boolean function. however, the automaton is complete at a semantical level: the automaton a with bit vector labels it represents is always complete. it is this semantic notion of completeness and determinism which we will refer to in the sequel of the paper. convention: in the following sections, the semantics of jmosel formulas will always be given in terms of symbolic automata as. in this section we used the index “s” to better distinguish between the two types of automata, but we omit it from now on. in the figures depicting automata, the proc. gramot 2010 4 / 15 eceasst following applies: an arrow marks the initial state, accepting states are denoted as double circles, non-accepting states as plain circles. in the following, we first present the classical (first-order) value numbering for this application domain, before we lift to second order in section . 3 first-order value numbering first-order value numbering is an analysis method that allows the detection and removal of redundant computations from a program [cs70]. this goal is achieved by assigning abstract identification values to computations that imply equality: as soon as an identification value reappears, it is certain that the corresponding computation has been already performed before, thus the previously computed result may be reused instead of performing the computation again. this ‘classical’ optimization is called dagification in [kms02]. 3.1 characterization of 1st-order value numbering given a syntax tree t of a jmosel formula in terms of • l is the set of all labels for predicates, operators, and variables, l = {subseteq,shifteq,̃ ,&,ex}∪{x,y,z,...} • n is the set of nodes of the syntax tree t under consideration • l : n −→ l maps every syntax node to its label. the assignment of abstract identification values can be given by any function v1st : n −→ n that satisfies the following two characteristics: for all nodes n1,n2 ∈ n of the syntax tree, • v1st(n1) = v1st(n2) implies l(n1) = l(n2), i.e. the coincidence of their syntactic labels. in addition we require • if n1 and n2 are internal nodes with children c11,...,c 1 i ∈ n and c 2 1,...,c 2 j ∈ n , respectively i = j ∧ ∀k ∈ {1,...,i}.v1st(c1k) = v1st(c 2 k) 3.2 example as an example for the process of first-order value numbering, we consider the following jmosel formula: f = (subseteq(x,y)&shifteq(a,b))|(subseteq(x,y)&shifteq(a,b)) fig. 4 shows its syntax tree after computation of the value numbers. at compilation, the compiler can benefit from the fact that the subformulas with value numbers 3, 6, and 7 all occur twice by only calculating each of them once, storing the result of the computation, and referring to it when the corresponding value number occurs for the second time. we will illustrate the impact of this optimization in section 5. 5 / 15 volume 30 (2010) second-order value numbering figure 4: 1st order value numbering applied to the jmosel formula f . 4 second-order value numbering while first-order value numbering is used to identify redundant computations and replacing them by previously computed results, the goal of second-order value numbering is to identify redundant transformations the reason for the use of second-order here. as will be clear below, this analysis and its corresponding optimizations is only a bit more involved than in the first-order case, but has a far bigger impact, see section 5. 4.1 characterization of 2nd-order value numbering the only difference in the characterization of the labelling function v1st : n −→ n concerns the treatment of atomic predicates, i.e., of a = {subseteq,shifteq}. their labelling does no longer require the second clause for internal nodes. this results in the following slightly modified characterization: for all nodes n1,n2 ∈ n of the syntax tree, • v1st(n1) = v1st(n2) implies l(n1) = l(n2), i.e. the coincidence of their syntactic labels. in addition we require • if n1 and n2 are internal nodes with children c11,...,c 1 i ∈ n and c 2 1,...,c 2 j ∈ n , respectively i = j ∧ ∀k ∈ {1,...,i}.v1st(c1k) = v1st(c 2 k) unless they are labelled with a = {subseteq,shifteq} after this labelling, nodes sharing the same value number can be replaced by calls to a semantics transformer. however note that transformers should only be created for subtrees containing at least one logical operator, as otherwise the effect of the transformation is vacuous. proc. gramot 2010 6 / 15 eceasst 4.2 semantics transformers when implementing second-order value numbering for jmosel, the semantics transformers can be implemented in terms of custom predicates similar to the atomic formulas subseteq and shifteq. this means that every identification of redundancy results in the automatic definition of a custom predicate. this process can be seen as an “on-the-fly enhancement” of the logic with newly identified predicates with multiple occurrences. for the definition of semantics transformers and calls to these transformers, the syntax of jmosel is enhanced by the let-construct let < predicatename > ( < argumentlist > ) = < de f inition > in < f ormula > that allows one to formulate formulas like: let pred(x,y) =subseteq(x,y) & shifteq(y,x) in pred(a,b) <-> pred(s,t). where a new predicate pred with arguments x and y is defined by the formula subseteq(x,y) & shifteq(y,x) and instantiated twice in the formula pred(a,b) <-> pred(s,t). definition 3 (semantics of the let-construct) for formulas f1, f2 ∈ f and a predicate pred(a1,...,an) ∈ p, the semantics of the letconstruct is defined as follows: jlet pred(arg1,...,argn) = f1 in f2k =d f j f2 [ f1/pred(x1,...,xn)]k where ·[·/·] : f × id × id −→ f denotes the usual syntactic substitution. we use the let-construct to implement second-order value numbering for jmosel. there, the definitions of and calls to semantics transformers are automatically inserted into the considered formula according to the value numbers assigned to the individual computations. in the following we first illustrate on a very simple example how a semantics transformer is identified and inserted into the formula, then we consider a more complex case study in section 5. 4.3 example as a short example for the process of second-order value numbering, we consider the following jmosel formula: (subseteq(a,b) & shifteq(c,d)) | (subseteq(x,y) & shifteq(v,w)) this formula is similar to the one of section 3.2, but cannot benefit from first-order value numbering, since the atomic formulas subseteq and shifteq are called with different parameters. this is a very frequent case in practice: in hardware design, for example, circuits are composed of a small number of component types, each instance of which has the same abstract function, but is connected differently. circuits would thus not be eligible for first order value numbering, but are an excellent application for second-order value numbering. 7 / 15 volume 30 (2010) second-order value numbering figure 5: 2nd-order value numbering applied to a jmosel formula. the formula’s syntax tree after computation of second-order value numbers is shown in fig. 5. the nodes of the tree have been divided into two sets, formulas and terms; nodes representing terms have not been numbered by the 2nd-order value-numbering procedure. the two nodes labeled with “&” share the value number 3; this means they both perform the same set of computations and can therefore be replaced by calls to a same semantics transformer st 3. the nodes with the value numbers 1 and 2 are not taken into account, since they are labeled with atomic predicates. the definition of the st 3 transformer is isomorphic to the subtrees labeled with value number 3, but all occurring variables are replaced by fresh variables “arg n”. this transformer is inserted via let-construct into the formula, and the subtrees labelled with 3 are replaced by calls to st 3 (see the corresponding syntax tree in fig. 7), resulting in the formula: let st 3(arg 1,arg 2,arg 3,arg 4) = subseteq(arg 1,arg 2) & shifteq(arg 3,arg 4) in st 3(a,b,c,d) | st 3(x,y,v,w) when compiling this formula, the conjunction of the predicates subseteq and shifteq is only computed once and stored as a semantics transformer, opposed to the original formula, where the conjunction is computed twice. the detailed course of the optimization and compilation is described in the next section. 4.4 the optimizing transformation the optimization of the syntax tree for the formula (subseteq(a,b) & shifteq(c,d)) | (subseteq(x,y) & shifteq(v,w)) is performed in the following steps: • perform the numbering of the syntax tree, resulting in the labelling shown in fig. 5. • identify the good targets for optimization: the nodes labelled with 3 qualify, as there exist more than one, and the corresponding subtrees contain logical operators. proc. gramot 2010 8 / 15 eceasst figure 6: syntax tree with calls to the semantics transformer. • create a semantics transformer st 3 for the nodes labelled with 3 by duplicating one of the syntax trees of the corresponding subfunction. • replace the two occurrences of syntax nodes labelled with 3 by calls to the newly created semantics transformer st 3 (fig. 6). • add the definition of st 3 to the top of the syntax tree (fig. 7). the compiler operates on the modified syntax tree as follows: • at the “let” construct it compiles the semantics transformer’s definition, identified by the subtree of the second child node of “let”. • at the nodes representing the atomic predicates subseteq(arg 1,arg 2) and shifteq(arg 3,arg 4) it constructs the corresponding basic automata a1 and a2. 9 / 15 volume 30 (2010) second-order value numbering figure 7: syntax tree after optimization. proc. gramot 2010 10 / 15 eceasst • at the node representing the formula subseteq(arg 1,arg 2) & shifteq(arg 3,arg 4) it constructs the product automaton a1∧2 representing the conjunction of a1 and a2. • it stores the resulting automaton as a semantics transformer named st 3 with arguments arg 1,...,arg 4. • the compilation continues with the subtree of the third child node of “let”. • at the node representing the call of a semantics transformer st 3(a,b,c,d) the precomputed definition of st 3 is copied, replacing the arguments arg 1, ...,arg 4 in the edge labels with the terms a,b,c,d to yield the result automaton a3. 11 / 15 volume 30 (2010) second-order value numbering • at the node representing the call of a semantics transformer st 3(x,y,v,w) the precomputed definition of st 3 is copied again, this time the arguments arg 1,..., arg 4 in the edge labels are replaced with the terms x,y,v,w to form the result automaton a4. • at the node representing the formula st 3(a,b,c,d) | st 3(x,y,v,w) it constructs the product automaton a representing the disjunction of a3 and a4 and returns it as the compilation’s result. proc. gramot 2010 12 / 15 eceasst full_adder full_adder full_adder full_adder @cin x y result @cout add $ $ 1 1 1 1 1 1 1 1 1 1 1 1 $ figure 8: structure of the parametric adder 5 application and performance measuring one of jmosel’s main application areas is the specification and verification of parametric hardware systems. we tested the presented optimization with a “real-world” example, applying it to the structural description of a parametric adder that describes the family of adder circuits for bit vectors of length n. structural description of a parametric adder fig. 8 shows the structure for this adder based on n interconnected full adders. the circuit adds two bit vectors x and y and stores the result as the new vector result. the boolean variables @cin and @cout are the carry-in and carry-out bits. the size of input formula and of the resulting automaton are too large for a detailed discussion in this paper, so we only present the results in terms of key data at this point. the compilation times have been measured on an intel centrino duo system (2 x 2.16 ghz) with 1 gb of ram: optimization none 1st-ord. vn 2nd-ord. vn nodes in synt. tree 472 469 452 depth of synt. tree 26 27 32 overall run time 11.50 sec 10.49 sec 3.47 sec sem. transformers 1 6 as we expected, first order value numbering does not contribute significatively to performance: the sharing is at the level of subcircuit types, not of fully instanced values. 13 / 15 volume 30 (2010) second-order value numbering the increased depth of the modified syntax tree is due to the fact that all definitions of semantics transformers are added to the top of the tree. by identifying 6 semantics transformers, the size of the tree could be reduced by 20 nodes. this does not seem too exciting at first sight; however, it has quite some impact: the overall run time of the decision process is accelerated by a factor of three. the enormous speedup is quite surprising, since the adder’s structural description already included user-defined predicates for frequently occurring constructs like the full adder and logical gates. this shows that even a carefully written formula and well structured circuits might still contain significant potential of redundancy, and therefore could benefit greatly from second-order value numbering. 6 conclusion we have presented second-order value numbering, a new optimization technique for suppressing redundancy, in a version tailored to the application for improving the decision procedure of jmosel, a verification tool set for monadic 2nd-order logic on strings. our technique extends the well-known concept of value numbering to consider not merely values, but semantics transformers that can be efficiently pre-computed and help to avoid redundancy at a second-order level. we have illustrated the effect of this optimization for a parametric family of hardware circuits, where we observed a performance gain by a factor of 3. this result is surprising, as the design of these circuits exploits already structural similarity. currently we are working on a careful experimental analysis of the impact of our technique in practice using standard benchmarks and libraries. we conjecture that we will observe a growth of the improvement factor with the size of the system, i.e. a ‘felt’ superlinear speedup. in a more general perspective, second-order value numbering can be regarded as a means for a specific semantic form of procedural abstraction [shkn76, dwf+07] in a similar way as value numbering (or its generalization to value flow graphs) is a semantic support for code motion [skr90]. thus besides looking for further application domains for second-order value numbering, it would also be interesting to investigate how the structural generalization of value numbering presented in [skr90] can be raised to second-order in order to achieve a truly semantic notion of procedure abstraction for imperative programs. bibliography [awz88] b. alpern, m. n. wegman, f. k. zadeck. detecting equality of variables in programs. in popl ’88: proceedings of the 15th acm sigplan-sigact symposium on principles of programming languages. pp. 1–11. acm press, new york, ny, usa, 1988. [bry86] r. e. bryant. graph-based algorithms for boolean function manipulation. ieee transactions on computers 35(8):677–691, 1986. [chu63] a. church. logic, arithmetic and automata. in proc. intern. congr. math. pp. 23– 35. almqvist and wiksells, 1963. proc. gramot 2010 14 / 15 eceasst [cs70] j. cocke, j. t. schwartz. programming languages and their compilers. courant institute of mathematical sciences, new york university, 1970. [dwf+07] a. dreweke, m. wörlein, i. fischer, d. schell, t. meinl, m. philippsen. graphbased procedural abstraction. in society (ed.), proc. of the 2007 cgo. pp. 259– 270. ieee computer society, los alamitos, ca, usa, 2007. [kmmg97] p. kelb, t. margaria, m. mendler, c. gsottberger. mosel: a flexible toolset for monadic second-order logic. in proc. tacas’97. lecture notes in computer science 1217, pp. 183–202. springer verlag, 1997. [kms02] n. klarlund, a. møller, m. schwartzbach. mona implementation secrets. international journal of foundations of computer science, 2002. [mar96] t. margaria. fully automatic verification and error detection for parameterized iterative sequential circuits. in proc. tacas ’96. lecture notes in computer science 1055, pp. 258–277. springer verlag, 1996. [shkn76] t. standish, d. harriman, d. kibler, j. neighbors. the irvine program transformation catalogue. university of california, irvine, 1976. [skr90] b. steffen, j. knoop, o. rüthing. the value flow graph: a program representation for optimal program transformations. in european symposium on programming. pp. 389–405. 1990. [twms06] c. topnik, e. wilhelm, t. margaria, b. steffen. jmosel: a stand-alone tool and jabc plugin for m2l(str). in model checking software: 13th international spin workshop, vienna (austria). lncs 3925/2006, pp. 293–298. springer-verlag, 2006. 15 / 15 volume 30 (2010) a visual notation for declarative behaviour specification electronic communications of the easst volume 42 (2011) proceedings of the 4th international workshop on multi-paradigm modeling (mpm 2010) a visual notation for declarative behaviour specification thomas kühne 10 pages guest editors: vasco amaral, hans vangheluwe, cécile hardebolle, lazlo lengyel managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst a visual notation for declarative behaviour specification thomas kühne victoria university of wellington abstract: logical programming has many merits that should appeal to modellers. it enables declarative specifications that are free from implementation details and even (mostly) abstracts away from control flow specification. however, the textual syntax of, for example prolog, most likely represents a barrier to the adoption of such languages in the modelling community. the visual notation presented in this paper aims to facilitate the understanding of behaviour specifications based on logic programming. i anticipate that the dataflow-like nature of the resulting diagrams will appeal to modellers. i believe the visual notation to be an improvement over the traditional textual syntax for the purpose of specifying prolog programs as such, but the ultimate hope is to have found a vehicle to make declarative logic programming a commonplace activity in multi-paradigm modelling. keywords: behaviour modelling, declarative specification, visual syntax 1 introduction modelling the structure of a subject is well supported by existing languages. for instance, uml class diagrams [brj98] have successfully been used to model the structure of problem domains and software systems. in general, however, modelling the subject’s behaviour is much more challenging. typically, the set of all possible behaviour traces is much more complex than the structure that supports it. as with structural modelling, in behaviour modelling a finite, static description has to be used, however, in this case to capture dynamic behaviour with a multitude of variations, case distinctions, etc. there is an intrinsic disconnect between the static description of behaviour and the latter’s temporal character that supports a potentially infinite unfolding of branches. by restricting the behaviour to be described to simple reactive behaviour, as exhibited by many small embedded systems, it becomes possible to use notations such as uml state diagrams to intuitively and completely capture their behaviour [mb02]. however, when faced with describing more complex behaviour, it seems that one of the three following approaches has to be adopted: 1. visual notations, such as activity diagrams and interaction diagrams, are regarded as constraining potential behaviour, but no attempt is made to completely specify the behaviour. 2. visual notations, such as state diagrams and the above, are extended with action languages. the visual notation thus provides the structure into which conventional behaviour specification fragments are embedded. 3. textual notations, i.e., programming languages are used. typically their syntax is more succinct than that of visual notations. 1 / 10 volume 42 (2011) a visual notation for declarative behaviour specification it is outside the scope of this paper to provide empirical evidence for the following assumptions but we will nevertheless assume them to be true in the context of this paper: • it is desirable to avoid unnecessary media changes. if many properties of the system are described using a visual notation, one should not add textual notations to the mix unless there is a good reason for doing so. • some textual descriptions can benefit from being transcribed into a visual notation in order to acknowledge their graph-like (as opposed to tree-like) structure. in multi-paradigm modelling typically a large variety of different notations will be used and i believe the modeller’s experience will be improved if they can use visual models most of the time, in particular if the visual form is more appropriate to do justice to graph-like descriptions. in this paper, i propose to use a declarative formalism for modelling behaviour (section 2) and present a visual notation for it (section 3), arguing that the visual form bears a number of advantages. i then discuss related work (section 4) and conclude with a final discussion (section 5). 2 declarative behaviour specification the intention of modelling is to focus on the “what?” not on the “how?”. this is why declarative formalisms lend themselves to be used in modelling. logic programming languages could be regarded as quintessential behaviour modelling languages since they attempt to describe the behaviour logic only, leaving control aspects to inference engines [kow79]. execution is achieved by logical inference and in principle the inference engine could use one of many ways to execute the specified logic. a well-known logic programming language is prolog [cr92]. it is one of the most declarative programming languages in existence because • unification is directionless. in general, any parameter of a prolog predicate may be used as an input parameter, or output parameter, or precondition, depending on how the predicate is used. • prolog defines relations rather than functions. as a result, one relation definition often substitutes a number of function definitions. • control flow is implicit rather than explicitly specified. a prolog program specifies facts and rules but no explicit control flow1. all the above make prolog a formalism that should be very useful in modelling and indeed it has already been used for the specification of transformations [ch03]. 1 the extra-logical “cut”-operator is a notable exception but is mainly used to optimise execution speed. proc. mpm 2010 2 / 10 eceasst arguments against prolog include 1. it is difficult to structure large prolog programs. 2. the textual notation is rather dense and will likely meet reservations from modellers used to visual notations. 3. it is easier to write prolog programs than to read them. the fact that only the bare essentials are expressed and that a prolog predicate can often be used in a multitude of ways, can make it hard to understand prolog programs. there is hope that by using other models as structuring aids, it will be possible to address the first of the above issues. in this paper, however, i propose a visual syntax for prolog (the abstract syntax and semantics from prolog are retained) that i believe to somewhat alleviate the last two of the above issues. 3 visual notation a typical problem of reading and writing prolog programs is that one is not sure about the meaning and role of parameters. for instance, in listing 1 it is not clear whether peter is paul’s parent or vice versa. likewise, the road description could first specify the destination and then the starting point or vice versa. the number at the third position could be among other things a road id, the label of a motorway, or a distance specification. parent ( peter , paul ). road( rotorua , hamilton , 109). listing 1: prolog fact definitions this problem can be addressed through comments or using descriptive formal parameter names for other clauses that use the same functor, but in either case the information is at a different location and potentially there are no clauses which could list descriptive formal parameter names. road hamilton d ista n ce rotorua 109 endstart figure 1: visual fact notations figure 1 shows the road definition using a visual syntax. note the use of role names to associate the values with the “road”-functor in a self-explanatory way. it is no longer necessary to mentally associate the position of a value with its role for the clause definition since the role is spelled out explicitly. further note that the visual form becomes agnostic to the ordering of values. they can be associated to the functor in any order or shape. 3 / 10 volume 42 (2011) a visual notation for declarative behaviour specification route ( finish , finish , visited , visited , 0). route ( start , finish , visited , route, distance ) :− road( start , end, length ), not(member(end, visited )), route (end, finish , [ start | visited ], route, accumulateddistance), distance is length + accumulateddistance. listing 2: prolog route clauses listing 2 shows the definition of a prolog predicate that will compute all possible routes between two cities including the respective distances. note that it is next to impossible to understand the meaning of the first clause without consulting the second clause in order to gain an understanding of the parameter roles. the first clause states that if the start and the finish positions are identical then the route is identical to list of previously visited cities and the distance between the start and finish locations is zero. consider figure 2 and note how much easier it is to attain the same understanding of the first clause without consulting any other location of the specification. route sta rt finish 0 distance ro ut evi si te d figure 2: first route clause lines connecting parameters with each other state that these parameters have to have the same value. prolog unification applies so no statement is made whether a start value is transferred to a finish value or vice versa, or whether two values are compared. the second route clause of listing 2 is more interesting as it involves other predicates. figure 3 shows the same clause in my proposed visual notation. several observations can be made regarding figure 3: • the parameter role names function like keyword parameters. associating the result of the addition (bottom right part of figure 3) with the “distance” parameter of “route” is achieved by connecting the result to the “distance” role of “route”. instead of making sure that the result of the addition arrives at the last position of “route” by using a common variable name as in listing 2, one can think of the visual variant to associate the result of the addition with the “distance” keyword parameter of “route”. note again that the visual notation is agnostic to what position the “distance” parameter may have had in the textual form. proc. mpm 2010 4 / 10 eceasst fin ish road sta rt distance route visit ed routeroute end length start not member + se t element s tar t finish [ | ][ | ] visited ro u te distance route figure 3: second route clause • the keyword parameters help to understand the significance of a value for a predicate used as a premise. for instance, it is possible to figure out that the “[start | visited]” value at the third position of the “route” premise is meant to be the updated list of visited locations but this requires looking up the formal parameter name of the clause definition. in comparison, the “visited” role of the “route” premise in the visual notation makes it explicit in what way the value is going to be used. • variable names can appear in more than two places which results in more than two roles being connected by the same line. i currently use little circles as explicit junction points for such n-ary connectors. it is possible to annotate these connectors or lines in order to communicate the role of a value in the context of a clause definition. for instance, one could add an “accumulated distance” annotation to the line that connects “route” with the second operand of the addition operator. • the graph shown in figure 3 offers a direct visual insight into the topology of the clause definition. akin to a dataflow diagram it becomes readily apparent how values are used to form new aggregates or feed into further computations. consider the connection between the “road” and “route” premises. it becomes evident that the end point of the road used in the route becomes the start point of the sub-route that needs to be computed. the same can be inferred from the textual version in listing 2 but it requires to find locate two occurrences of the “end” variable and one has to look for the connection while it is has been turned into explicit geometry in figure 3. in summary, the visual notation appears to be the more natural one since multiple occurrences of one variable in the text form are reduced to one n-ary connector. in other words, coreference 5 / 10 volume 42 (2011) a visual notation for declarative behaviour specification is not encoded by multiple variable occurrences using the same name but becomes explicitly apparent by using visual connectors. the fundamental purpose of using a variable in two positions (e.g., “end” in the “road” and “route” premisses) is to connect the two positions. any arbitrary variable name like “x” would have worked as well. the (potentially n-ary) line in the visual form does just this; it connects positions that need to be connected. if the relevance of the connections is not clear from all the role names involved, one can annotate the line with a label, such as “intermediate location”. 3.1 further applications the graphs created using the visual notation lend themselves to unfolding of premisses. for instance, there are two possibilities in which the “route” premise of figure 3 may be unfolded. either the clause shown in figure 2 or that in figure 3 applies. figure 4 shows the resulting structure if the first clause is inserted within the second. this corresponds to the situation where the final location of a route has been found. it is very easy to manually insert the structure of figure 2 into that of figure 3 (in this case this mainly leads to connection shortcuts) but ideally there should be tool support for this. road sta rt distance route visit ed routeroute end length start not member + se t element fin ish [ | ][ | ] 0 figure 4: unfolding using the first route clause figure 5 shows the insertion of the second clause into itself. this particular unfolding is useful to illustrate the recursive nature of the second clause. one can clearly see how the “visited” list is built up by successive additions of elements to the head of the list. unfolding operations such as the above are useful to check whether special cases are handled correctly and/or whether the clauses cooperate with each other as intended. the unfolded graphs will reveal unexpected structures in case the clause definitions are erroneous. after having looked at figure 4 a developer will realise that the final location is not added to proc. mpm 2010 6 / 10 eceasst road sta rt distance route visit ed routeroute end length start not member + se t element finish [ | ][ | ] visited fin ish road sta rt end length not member + se t element sta rt [ | ] visited ro u te distance route figure 5: unfolding using the second route clause the “visited” locations and hence will not appear as part of the “route” result. after having looked at figure 5, a developer will also know that the “visited” locations, and hence the locations in the “route” result are in reverse order. both these facts are not as apparent from the textual clause definitions in listing 2. the reverse ordering of the locations is caused by the use of an accumulator technique which makes the “route” predicate more efficient. this “route” predicate version was deliberately chosen over a more straightforward definition in order to demonstrate the efficacy of the visual notation in making the reverse ordering apparent. another use for the visual notation is shown in figure 6. here actual values have been provided for “start”, “visited”, and “finish” and the graph shows how these values yield the “route” and “distance” results. again, a simple unfolding of premises using the appropriate clause definitions is all that is required to produce the graph in figure 6. note how actual values flowing between premises are shown as annotations, in this example “hamilton”, “auckland” and the distance values. such usage scenario graphs could prove to be useful for debugging purposes or helping to understand how a predicate works prior to using it. 4 related work often prolog execution is presented through so-called and/or trees [tam95]. these show regular prolog predicates with variable bindings. the depiction of a prolog execution as shown in figure 6 better shows how values flow between predicate invocations and thus pro7 / 10 volume 42 (2011) a visual notation for declarative behaviour specification visite d road sta rt end length rotorua not member + se t elem ent [ | ][ | ] visited road start end length not member + se t element [ | ] [ ] sta rt d ista n ce 235ro u te [ hamilton, rotorua ] auckland fin ish hamilton au ckl an d 109 126 0 [ rotorua ] figure 6: actual usage scenario vides a better understanding of the topology of an execution graph. currently, my visualisation approach does not aim at indicating potential future continuations of execution or depicting past computations and is therefore not as suited as and/or trees for such purposes. sldnf-draw is visualisation system used to support the teaching of prolog [gav07]. as with and/or trees, lines between predicates are motivated by the call graph, not by coreferenced variables. as a result, the system is successful in showing prolog execution including the extra-logical “cut” operator, but does not provide insights into the dataflow between premises in clause definitions. logichart was developed to visualise the execution flow of prolog programs [af07]. similar to and/or trees, no attempt is made to visualise the connections between predicate argument positions. these connections have to be inferred by matching variable names. it is possible that the logichart work on obtaining optimal layouts [atiy99] is transferable to the visual notation presented here. the sparcl language organises terms on the basis of finite sets as opposed to tuples or lists. proc. mpm 2010 8 / 10 eceasst the respective visualisation also uses lines to show variable coreference but visual embedding is used to depict logical inclusion. as a result, the program visualisation seems to yield far less intuitive diagrams compared to the approach presented in this paper. puigsegur et al. also use set inclusion relationships in order to derive a visual layout based on embedding [par96, par98]. while the resulting diagrams may be regarded as intuitive for relations which can be thought of having a set and membership underpinning, the further the stretch to that underpinning, the less intuitive the diagrams appear. the diagrams are not very self-explanatory, in particular because connectors do not use role names. i am of the opinion that the approach by puigsegur et al. overlays a set metaphor on top of the generic relations paradigm that, overall, just adds a complication rather than being helpful. further research is required to evaluate whether the notation proposed in this paper is actually easier to use in practice. vpl aims to use visualisations to emphasise the relational nature of logic programming. it supports program composition and editing in both textual and graphical representations [lr91]. vpl also presents predicates as boxes but replaces variable names with graphical patterns. the task to infer coreferenced variables is therefore turned into the arguably even harder task of matching patterns. the visual notation captures logical conjunction and disjunction. the approach presented in this paper always assumes logical conjunction within one diagram and requires the use of multiple diagrams for including disjunction. it remains to be seen which approach is more advantageous in practice. 5 conclusion in this paper i argued that logical programming has many merits that should appeal to modellers. i briefly discussed prolog as a well-known example for a declarative language that enables the specification of many functions through the definition of comparatively fewer relations. i speculated that the dense textual syntax and the resulting “easier to write than to read”character of such languages may have been a barrier for adopting such approaches in modelling. the visual notation presented in this paper is hoped to facilitate the understanding of prolog programs by prolog programmers, but the fact that role names as known from uml class diagrams are used and that the resulting diagrams resemble dataflow diagrams should appeal to modellers in particular. part of the effectiveness of the visual notation derives from the fact that coreferencing is made visually explicit. instead of requiring the reader to infer the coreferencing through matching variable names, the visual notation shows how predicate argument positions are connected through n-ary connectors. one could argue that prolog clause definitions have an inherent graph structure and that the visual notation is the more natural one to do justice to this property. note that it is trivial to translate any of the diagrams presented in this paper to executable prolog programs. a modeller can therefore obtain an executable behaviour specification by simply drawing diagrams in the spirit as presented here. the work presented here is just the beginning of a number of potential future research directions. empirical studies could look into the effectiveness of the visual notation in terms of understandability and error detection. automatic layout variants that aim to emphasise structure or design decisions should be evaluated with respect to their impact on readability. 9 / 10 volume 42 (2011) a visual notation for declarative behaviour specification bibliography [af07] y. adachi, y. furusawa. logichart: a prolog program diagram and its layout. eceasst 7, 2007. [atiy99] y. adachi, k. tsuchida, t. imaki, t. yaku. logichart intelligible program diagram for prolog and its processing system. electr. notes theor. comput. sci. 30(4), 1999. [brj98] g. booch, j. rumbaugh, i. jacobson. the unified modeling language user guide. addison-wesley, 1998. [ch03] k. czarnecki, s. helsen. classification of model transformation approaches. in oopsla’03 workshop on the generative techniques in the context of model-driven architecture. 2003. [cr92] a. colmerauer, p. roussel. the birth of prolog. in second acm sigplan conference on history of programming languages. pp. 37–52. 1992. [gav07] m. gavanelli. sldnf-draw: a visualisation tool of prolog operational semantics. ceur workshop proceedings, issn 1613-0073, 2007. [kow79] r. kowalski. algorithm = logic + control. communications of the acm 22:424– 436, july 1979. [lr91] d. ladret, m. rueher. vlp: a visual logic programming language. j. vis. lang. comput. 2(2):163–188, 1991. doi:http://dx.doi.org/10.1016/s1045-926x(05)80028-x [mb02] s. j. mellor, m. j. balcer. executable uml: a foundation for model-driven architecture. addison-wesley, 2002. [par96] j. puigsegur, j. agusti, d. robertson. a visual logic programming language. visual languages, ieee symposium on 0:214, 1996. doi:http://doi.ieeecomputersociety.org/10.1109/vl.1996.545290 [par98] j. puigsegur, j. agusti, d. robertson. a visual syntax for logic and logic programming. journal of visual languages and computing 9(4):399–428, 1998. [tam95] d. tamir. a visual debugger for pure prolog. information sciences 3(2):127– 147, 1995. proc. mpm 2010 10 / 10 http://dx.doi.org/http://dx.doi.org/10.1016/s1045-926x(05)80028-x http://dx.doi.org/http://doi.ieeecomputersociety.org/10.1109/vl.1996.545290 introduction declarative behaviour specification visual notation further applications related work conclusion microsoft word edusymp10 final version june 2011 electronic communications of the easst volume 34 (2010) guest editors: peter j. clarke, martina seidl managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 proceedings of the 6th educators’ symposium: software modeling in education at models 2010 (edusymp 2010) teaching object-oriented modelling using concept maps ven yu sien 13 pages eceasst 2 / 13 volume 34 (2010) teaching object-oriented modelling using concept maps ven yu sien help university college, malaysia abstract: as one of the most important tasks in object-oriented analysis and design (ooad) is the abstraction of the problem domain into specific concepts or objects, information technology (it) students need appropriate skills of abstraction in order to identify the essential concepts and relationships within a problem domain. however students in higher education generally find difficulty performing abstractions of real-world problems within the context of ooad. concept mapping is a popular tool used in education for facilitating learning, comprehension and the development of knowledge structures. we have successfully adopted concept maps as stepping-stones to assist students in constructing class and sequence diagrams. in this paper, we present a framework for teaching object-oriented (oo) modelling using concept maps. this framework – comprising four teaching modules – could be integrated into existing ooad courses at the undergraduate or postgraduate level, and ooad workshops to help software engineering educators resolve some of the difficulties they face in trying to teach ooad. we also report results of an evaluative study on the effectiveness of integrating concept mapping techniques into an introductory ooad course. keywords: abstraction, uml models, concept map, class diagram, sequence diagram 1 introduction abstraction skills are especially important for solving complicated problems as they enable the problem solver to think in terms of conceptual ideas rather than their details [kh06]. abstraction skills are also necessary for the construction of the various models, designs, and implementations that are required for a software system. as models are a simplification of reality that help us to understand and analyse large and complex systems, students must therefore possess the necessary abstraction skills to produce them [kra07]. however, being able to understand what details are important to the problem is a difficult skill that requires a great deal of practice. kramer [kra07] believes that the reason why ‘some software engineers and computer scientists are able to produce clear, elegant designs and programs, while others cannot, is attributable to their abstraction skills’. 2 background review this section reviews the challenges faced by students in understanding oo concepts and conceptualising real-world problems as abstractions. most education institutions teach ooad courses in the context of a software development life cycle (sdlc) e.g., iterative and incremental or rational unified process (rup). while development processes differ, they all teaching oo modelling using concept maps edusymp 2010 3 / 13 share some common phases i.e., the requirements specification, analysis, design and implementation phases. each phase produces deliverables that are required by other phases in the life cycle. during the ooad phases, models are produced to show the type of information processing that is required of the new system. a model of an oo system is an abstract representation of the system. it represents the problem domain and emphasises some characteristics of the real-world. modelling a system, however, requires the representation of different perspectives or views of the system and therefore there are different types of diagrams for modelling each of these views. cianchetta [cia95] considers teaching the fundamental concept of identifying objects from the problem domain to be one of the most difficult tasks that he encountered when training oo developers. he found that even though object-oriented analysis (ooa) and object-oriented design (ood) can be easily defined as ‘the modeling of a specific problem domain and a pragmatic solution for that domain’, the essential problem is ‘defining how one should go about modeling a problem domain and its practical, efficient, and cost-effective solution’. students at higher education institutions in general experience considerable difficulty understanding oo concepts and acquiring the necessary skills in ooad. svetinovic et al. [sbg06] investigated the different types of fundamental difficulty their students experienced when performing ooa. the analysis of the results was based on the specification artifacts produced as a result of the students’ ooa of a business system and observation of the students’ behavior. the most common errors committed by the students are:  assignment of a large business activity to a single object while it should be fulfilled through the collaboration with other objects;  missing responsibilities that should be assigned to objects;  missing objects that should participate in the overall responsibilities;  under-specified analysis models – the students were unable to identify most of the appropriate concepts; and  a large number of software concepts were identified at inconsistent abstraction levels. bolloju and leung [bl06] conducted a study to identify errors produced by novice systems analysts in use case diagrams, use case descriptions, and class and sequence diagrams. the errors that they found in class diagrams were:  operations that had not been included in classes;  misassigned operations;  incorrect multiplicities;  misassigned attributes; and  incorrect usage of generalisation-specialisation hierarchies. some of the faults they found in sequence diagrams were:  missing messages;  missing message parameters;  missing objects; and  incorrect delegation of responsibilities. eceasst 4 / 13 volume 34 (2010) 3 proposed concept-driven approach in order to resolve some of the issues discussed in section 2, we presented a concept-driven approach to introduce concept mapping as a tool to help students with oo modelling [sc07, sc08]. concept mapping is a technique for representing the structure of information visually. it was developed by joseph novak [nc06] in 1972 at cornell university and is commonly used for visualising relationships between concepts. concept maps are two-dimensional, hierarchical diagrams that represent the structure of knowledge within a particular domain as nodes (or concepts) and connecting links. a concept is ‘an idea or notion that we apply to the things, or objects, in our awareness’ [mo95]. concepts are related to each other by a link, and each link has a word or word-phrase describing the relationship between the concepts. there are many inherent problems associated with modelling the problem domain with class and sequence diagrams – these are discussed in detail in section 2. we do not claim that it is easy to model the problem domain by using concept maps. we do however consider that concept maps have the following advantages over class diagrams:  it is easier to distinguish between classes and attributes in concept maps by using specifically defined labelled links e.g., ‘has’.  it is easier to identify generalisation-specialisation hierarchies in concept maps by using specifically defined labelled links e.g., ‘is-a’.  relationships between concepts that do not fall in the ‘is-a’ or ‘has’ categories are defined by an appropriate transitive verb from the case study.  substantial guidelines to produce concept maps have been developed. these are defined in [sc07, sc08].  concept maps help clarify the meaning of a concept by means of propositions [nc08].  it is relatively easy to teach concept maps. there are only two types of notations used in a concept map – nodes and links [nc08]. we believe that a significant improvement in the way novices in ooad analyse and design their oo systems can be achieved by adopting the proposed concept mapping techniques. once novices have mastered these techniques, they will be able to effectively produce abstractions of real-world problems represented by ooad models. 3.1 static and dynamic concept maps within the context of oo modelling, we used concept maps as an initial abstraction of the problem domain. a static concept map is a type of static structure diagram that describes the structure of a system by illustrating the system’s concepts and the relationships between these concepts. the concepts defined in the static concept map model classes (and attributes) in the analysis class diagram. for example, a static concept map (see fig. 1) is constructed by identifying concepts and their relationships from an expanded use case (table 1). we adapted some processes from [nb03] for constructing static concept maps. these processes involve the identification of candidate concepts and their relationships from expanded use cases. we included some construction constraints by defining only three types of relationships that concepts can have with each other i.e., attribute, generalisation-specialisation and association. teaching oo modelling using concept maps edusymp 2010 5 / 13 if the type of relationship between two concepts does not fall into the first two relationship categories, then it is considered to be an association. the static concept map is built incrementally from the use cases – it is subsequently transformed to a uml class diagram using the rules described in [sc07]. these rules were constructed by examining the linking words between two concepts to determine whether:  a concept should be converted to a class or an attribute; and  a link should be converted to an association or generalisation-specialisation hierarchy. table 1. expanded use case use case 1 add new employee goal in context an employee is correctly entered into the system. primary actor secondary actors hr manager main course description step action 1 the hr manager enters the employee’s name, address and birth date. 2 a unique employee number is allocated by the system. alt. course description step branching action 1a the hr manager enters the full-time employee’s name, address, birth date and monthly salary. 1b the hr manager enters the part-time employee’s name, address, birth date and hourly rate. an oo system is populated with objects and these objects need to cooperate with each other (by sending messages) in order to fulfil certain responsibilities. students generally have difficulty identifying messages to be sent in uml sequence diagrams. they do not know how figure 1. static concept map converted to a class diagram eceasst 6 / 13 volume 34 (2010) to fulfil the responsibilities of the use case by getting objects to pass messages to each other. students also have difficulty understanding that the interaction diagrams are dependent on the analysis class diagram in terms of its classes, associations and multiplicities a dynamic concept map provides a dynamic view of the system behaviour by showing the key responsibilities that need to be fulfilled by specific concepts in order to fulfil a particular scenario of a use case. the concepts defined in the dynamic concept map model objects in the sequence diagram. for each use case, its key responsibilities are identified and added to the static concept map so as to produce a dynamic concept map. a dynamic concept map is constructed and subsequently transformed to a uml sequence diagram using the rules described in [sc08]. fig. 2 illustrates an example of how a dynamic concept map for creating a part-time employee concept is transformed to a sequence diagram. figure 2. dynamic concept map converted to a sequence diagram the class and sequence diagrams are selected for our study because they represent the essential static and behavioural aspects of a problem domain. the class diagram is fundamental to the oo modelling process and provides a static description of system components and structures in terms of classes and their relationships. the sequence diagram is selected because it is identified as the ‘major uml diagram that captures the detailed behaviour of objects in the system’ [gbvh07] and it is one of the most widely used dynamic diagrams in uml [dp06]. one of the main motivations for developing this concept-driven approach is to assist students produce more appropriate class and sequence diagrams. our concept mapping techniques are developed based on some of the design errors that are reported in section 2:  the processes for deriving appropriate concepts from use cases should help novices avoid producing inappropriate classes, missing controller classes, and missing attributes.  labelled links between concepts should help prevent misassigned attributes and inappropriate relationships.  as the dynamic concept map is based on the static concept map, there should be fewer inconsistent objects, missing objects, and missing controller objects defined in the sequence diagrams. teaching oo modelling using concept maps edusymp 2010 7 / 13  the processes involved in identifying responsibilities and the assignment of these responsibilities to candidate concepts should help novices understand how objects can interact with each other via messages to fulfil the responsibilities of a particular scenario of a use case. it must be emphasised that the concepts defined in the static concept map are transformed to classes (and attributes) in the analysis class diagram, whilst the concepts defined in the dynamic concept map are transformed to objects in the sequence diagram. 3.2 integrating the concept-driven approach into an existing ooad course teaching ooad is not easy. educational institutions have developed/adopted various approaches [bw00, bd05] to help resolve the problems discussed in section 2. we recommend using a concept map as the initial domain model instead of a class diagram or object diagram, and teaching students how to identify concepts and their relationships from textual use cases describing the functionalities of the system. the first module introduces a procedure for producing static concept maps from textual use cases that describe the functional requirements of a system. the second module presents a set of transformation rules for converting the static concept map to a corresponding class diagram. the third module introduces a procedure for producing a dynamic concept map from a use case. the fourth module presents a set of transformation rules for converting a dynamic concept map to a corresponding sequence diagram. these modules can be used as a standalone workshop or integrated into existing ooad courses or workshops. at the end of each module, the students are expected to work on hands-on exercises. the exercises are designed to help students apply theory to practice, and subsequently assist them to improve their abstraction skills. the students are expected to draw the models using pen/pencil and paper. however, the lecturer of the course or facilitator of the workshop may prefer that the students use software applications to draw the models. with these modules, we aim to help students by providing them with:  a good foundation for identifying essential concepts to represent the problem domain;  techniques to help them produce appropriate abstractions of real-world problems to be represented by uml diagrams;  an understanding of oo notations and terminology including familiarity with a core subset of uml notation; and  an understanding of design patterns, and how they can be used to produce interaction diagrams. in a typical introductory ooad course, many oo concepts and definitions are presented first (e.g., objects, classes, inheritance, encapsulation, polymorphism, uml notation) followed by the application of these notations in the various types of uml analysis and design models. our framework, however, consists of the following sequence of topics: 1. requirements analysis and use cases. 2. module 1: static concept map (estimated duration: 1 hour 30 minutes) content: real-world problems conceptualised as abstractions; introduction to concept eceasst 8 / 13 volume 34 (2010) maps; guidelines for producing concept maps to represent a problem domain within the context of ooad [sc07]; hands-on exercises to produce a static concept map representing the problem domain from a case study. 3. analysis class diagram (e.g., classes, attributes, associations, generalisation-specialisation hierarchy, whole-part association, etc.) and uml notation for the oo approach. 4. module 2: static concept map  analysis class diagram (estimated duration: 1 hour 15 minutes) content: transformation rules for converting a static concept map to an analysis class diagram [sc07]; hands-on exercises to produce a class diagram – students continue with the case study that they worked on in module 1. 5. remaining topics in ooa (e.g., system sequence diagrams, contracts, etc). 6. module 3: dynamic concept map (estimated duration: 2 hours) content: multi-objects/containers in a concept map; naming convention for messages; identification of responsibilities from the use case; assignment/delegation of responsibilities to appropriate concepts using basic design patterns; guidelines for producing dynamic concept maps [sc08]; hands-on exercises to produce dynamic concept maps – students continue with the case study that they worked on in module 1. 7. module 4: dynamic concept map  sequence diagram (estimated duration: 1 hour 45 minutes) content: transformation rules for converting a dynamic concept map to a sequence diagram using the rules defined in [sc08]; hands-on exercises to produce sequence diagrams – students continue with the case study that they worked on in module 1. 8. remaining topics in ood (e.g., design class diagram, etc). 9. remaining topics in ooad (e.g., oopl code examples showing domain classes and relationships, oo development, etc). the times allocated to the modules are based on our experience conducting concept mapping workshops. there are many constraints to consider e.g., the time that the facilitator can afford for these topics in his/her syllabus, the speed with which the students can complete the guided sessions, the amount of help that the students require, etc. we incorporated these teaching modules in the workshops reported in [sc07, sc08] to evaluate the effectiveness of using concept maps to produce class and sequence diagrams. since the evaluation results provided strong evidence that the concept-driven approach can be used successfully, we implemented the teaching modules in an introductory ooad course in the february 2009 semester at help university college, malaysia. 4 evaluation study a study was conducted to evaluate the pedagogical effectiveness of adopting concept maps as a stepping stone to assist novices in developing class and sequence diagrams. in order to investigate the effectiveness of integrating the concept mapping techniques in an introductory ooad course, we compared the results of two studies. the participants in study 1 were not exposed to concept mapping techniques while the participants in study 2 were taught concept mapping techniques as part of their ooad course. while we are aware that we are comparing teaching oo modelling using concept maps edusymp 2010 9 / 13 results from two different sets of students, we can nonetheless use the outcome as a basis for considering the implications of incorporating concept mapping techniques in an ooad course. study 1 consisted of fifty-one year 2 it undergraduate students and study 2 consisted of twenty-one year 2 it undergraduate students. all the participants were volunteers and were not paid to take part in the study. information captured on the background of the participants and their experience with ooad is summarised in table 2. the oo experience reported for these participants is based on the experience they gained from their university courses that include oo concepts. table 2. background information on participants from studies 1 and 2 study 1 (n=51) study 2 (n=21) average age (years) 22 22 age range (years) 20-27 19-28 gender  male  female 61% 39% 90% 10% oo experience  < 1 year  12 years  3-5 years  > 5 years 35% 49% 16% 0% 48% 52% 0% 0% the participants from both studies were asked to work on a case study containing four expanded use cases that describe the functional requirements of the system. the solution for the case study consists of nine appropriate classes, two generalisation-specialisation hierarchies and eight associations. we used rubrics to define the assessment criteria for evaluating the appropriateness of the participants’ diagrams. the participants in study 1 were given a case study to work on after they had completed their ooad course at help university college, malaysia. in the subsequent semester modules 1, 2, 3 and 4 were integrated into the ooad course. after completing module 4, the participants in study 2 were given the same case study to work on. the participants in study 1 were given 1 hour to work on the case study as they were required to produce a class and sequence diagram. the participants in study 2, however were given 1 hour 30 minutes to work on the case study as they were required to produce a static concept map, a class diagram, a dynamic concept map and a sequence diagram. 5 results we classified the class and sequence diagrams produced by our participants according to the design categories proposed by eckerdal et al. [emm+06]. the design categories, in order of eceasst 10 / 13 volume 34 (2010) appropriateness are: complete, partial, first step, skumtomte1, restatement and nothing. the class and sequence diagrams produced by the participants are classified according to the categories proposed by eckerdal et al. [emm+06]. the descriptions of the categories, however have been modified to make them more appropriate for our study e.g.,  class diagrams  complete designs: diagrams contain all of the expected classes, attributes and associations. generalisation-specialisation hierarchies and whole-part associations are appropriately applied.  partial designs: diagrams are a good representation of the problem domain with most of the expected classes, attributes and associations defined.  first step designs: diagrams are a good representation of a partial overview of the problem domain with an appropriate number of expected classes. some of the classes may not be appropriately associated with each other and may contain some misassigned attributes.  skumtomte: incomplete diagrams with missing classes, misassigned or irrelevant attributes, and missing or inappropriately defined associations.  restatement: level of detail provided is insufficient. there are significant errors and misunderstandings.  nothing: diagrams do not contain any logical content.  sequence diagrams  complete designs: diagrams contain appropriate sequence of messages passed to the relevant objects to fulfil the responsibilities of the use case.  partial designs: diagrams include an appropriate number of correct objects fulfilling some responsibilities of the use case.  first step designs: evidence of some understanding of the required delegation of responsibilities among the objects.  skumtomte: diagrams are incomplete but contain at least 1 appropriate interaction between 2 appropriately defined objects. the majority of messages are inappropriate.  restatement: diagrams are incomplete but contain at least 2 appropriate objects. all the messages are inappropriate.  nothing: diagrams contain significant errors and misunderstandings. this method allows us to adopt a holistic approach [fh05] for evaluating the appropriateness of the uml diagram. we are, however, aware that this may not be a reliable assessment as it does not explicitly assess the appropriateness of individual components of the diagram. a higher percentage of class and sequence diagrams produced in study 2 are found to be in better design categories than the diagrams produced in study 1 – see table 3. there are 36% of class diagrams produced in study 1 that belong in the restatement and nothing categories – participants in study 2 did not produce any class diagrams belonging in these two categories. there are no sequence diagrams produced in study 1 that belong in the complete category, 1 skumtomte is a swedish word referring to a pink-and-white marshmallow, shaped like a santa claus. it looks as if it contains some matter but in reality it does not contain much substance. teaching oo modelling using concept maps edusymp 2010 11 / 13 compared to 35% of sequence diagrams produced in study 2 belonging in the complete category. table 3. analysis of diagrams produced by participants group diagram complete partial first step skumtomte restatement nothing study 1 class 2% 10% 21% 31% 23% 13% study 2 class 57% 14% 14% 14% 0 0 study 1 sequence 0% 3% 3% 10% 17% 67% study 2 sequence 35% 6% 12% 6% 24% 18% some of the most common faults found in the models produced in study 1 were similar to the types discussed in section 2. we find in this study (study 2) that the number of faults has significantly decreased especially in the following areas:  class diagrams  identification of expected classes representing the key concepts in the problem domain;  assignment of attributes to appropriate classes;  identification of appropriate generalisation-specialisation hierarchies.  sequence diagrams  identification of appropriate objects participating in the scenario of the use case;  identification of objects in the sequence diagram that correspond to classes defined in the class diagram; and  delegation/assignment of responsibilities to objects. 6 threats to validity this section discusses some threats to validity that may affect this study. internal validity. internal validity refers to the extent to which we can correctly state that the introduction of concept mapping techniques caused the participants to produce more appropriate class and sequence diagrams. one of the threats to internal validity consists of the expectations of a particular result by the researcher. in this context, the researcher was responsible for marking the class and sequence diagrams produced by the two groups of participants, and she is fully aware that the scores for the diagrams may bias the hypotheses. to this end, the marking scheme was strictly adhered to. however, in order to eliminate this threat, we should consider using independent assessors to mark the pre-test and post-test diagrams. we have not 'employed' the services of independent assessors due to logistical problems e.g., lack of funding and time constraints. note: the case study, marking scheme and a sample of the marked diagrams were moderated by independent assessors. there may be other factors that contributed to the quality of class and sequence diagrams produced by the participants of study 2 e.g.,  the students from study 2 may be more intelligent than the students from study 1;  as the students from study 2 are currently enrolled in the ooad course, their knowledge of ooad concepts and experience in oo modelling is still fresh in their minds; eceasst 12 / 13 volume 34 (2010)  the students in study 2 have been given a good foundation on ooad concepts;  sufficient emphasis has been placed on the necessary topics that are being evaluated. external validity. the main threat to external validity is generalising our results as our sample may not be representative of all it undergraduate students. 7 conclusion it is evident from the results reported earlier in section 6 that the quality of class and sequence diagrams improved in study 2. we are, however, mindful that the results achieved by the participants in study 2 may not be attributed to concept mapping techniques (as discussed in section 6). we believe that a significant improvement in the way novices in ooad analyse and design their oo systems can be achieved by adopting concept mapping techniques described in [sc07, sc08]. once novices have mastered these techniques, they will be able to effectively produce abstractions of real-world problems represented by ooad models. a significant strength of this approach is that it slows students down so that they need to think things through more thoroughly than they otherwise would. we have also set some design constraints e.g., including specifically defined linking words within the processes for building static concept maps in order to help students stay at the required abstraction level. this is intended to support and improve their skills of abstract thinking, and consequently improve their understanding of ooad. bibliography [bd05] r. beheshti, e. dado. simplified uml techniques for system development in an educational setting. in proc. sixth international conference on information technology based higher education and training. 2005. [bl06] n. bolloju, f. leung. assisting novice analysts in developing quality conceptual models with uml. communications of the acm 49(7), pp. 108112, 2006. [bw00] r. box, m. whitelaw. experiences when migrating from structured analysis to object-oriented modelling. in proc. australasian conference on computing education. 2000. [cia95] t. cianchetta. teaching object-oriented analysis and design by "cruisin' the classifieds for business objects". in proc. 1995 conference of the centre for advanced studies on collaborative research. 1995. [dp06] b. dobing, j. parsons. how uml is used. communications of the acm 49(5), pp. 109-113, 2006. teaching oo modelling using concept maps edusymp 2010 13 / 13 [emm+06] a. eckerdal, r. mccartney, j.e. moström, m. ratcliffe, c. zander. can graduating students design software systems? in proc. thirty-seventh sigcse technical symposium on computer science education. 2006. [fh05] d.r. ferris, j.s. hedgcock. teaching esl composition: purpose, process and practice. lawrence erlbaum, 2005. [gbvh07] j.f. george, d. batra, j.s. valacich, j.a. hoffer. object-oriented systems analysis and design. pearson higher education, 2007. [kh06] j. kramer, o. hazzan. the role of abstraction in software engineering. in proc. twenty-eighth international conference on software engineering. 2006. [kra07] j. kramer. is abstraction the key to computing? communications of the acm 50(4), 2007. [mo95] j. martin, j. odell. object-oriented methods: a foundation. prentice-hall international inc, 1995. [nb03] s. naidu, p. blanchard. concept mapping. http://www.infodiv.unimelb.edu.au/telars/flds/documents/conceptmappingwbo ok.pdf#search=%22concept%20mapping%20naidu%22 [nc06] j.d. novak, a.j. cañas. the origins of the concept mapping tool and the continuing evolution of the tool. information visualization 5(3), pp.175-184, 2006. [nc08] j.d. novak, a.j. cañas. the theory underlying concept maps and how to construct and use them. technical report ihmc cmaptools, 2008. [sbg06] d. svetinovic, d.m. berry, m.w. godfrey. increasing quality of conceptual models: is object-oriented analysis that simple? in proc. 2006 international workshop on role of abstraction in software engineering. 2006. [sc07] v.y. sien, d. carrington. a concepts-first approach to object-oriented modelling. in proc. third iasted international conf on advances in computer science and technology. 2007. [sc08] v.y. sien, d. carrington. using concept maps to produce sequence diagrams. in proc. the iasted international conference on software engineering. 2008. electronic communications of the easst volume 31 (2010) guest editors: paolo bottoni, esther guerra, juan de lara managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 proceedings of the second international workshop on visual formalisms for patterns (vffp 2010) a generic technique for domain-specific visual language model refactoring to patterns karen li, john hosking, and john grundy 12 pages eceasst 2 / 13 volume 31 (2010) a generic technique for domain-specific visual language model refactoring to patterns karen li 1 , john hosking 1 , and john grundy 2 1 {k.li, j.hosking}@auckland.ac.nz department of computer science, university of auckland, private bag 92019, auckland, new zealand 2 jgrundy@swin.edu.au 2 faculty of information and communication technologies, swinburne university of technology, po box 218, hawthorn, victoria, australia abstract: as the popularity of domain-specific visual languages (dsvls) grows, concerns have arisen regarding quality assurance and evolvability of their meta-models and model instances. in this paper we address aspects of automated dsvl model instance modification for quality improvement based on refactoring specifications. we propose a graph transformation-based visual language approach for dsvl authors to specify the matching and discovery of dsvl “bad model smells” and the application of pattern-based solutions in a dsvl meta-tool. as an outcome, dsvl users are provided with patternbased design evolution support as refactorings for their dsvl-based domain models. keywords: meta-tools, domain-specific visual languages, graph transformation, design patterns, model refactoring, model-driven engineering 1 introduction as the popularity of dsvls grows, concerns have arisen over the quality of both dsvl designs and the domain models created by novice users using them [moo09, lb05]. model quality assurance research is immature, with limited outcomes in the areas of model measures, metrics, and transformations [rb09]. in this context, our research aims to enable dsvl authors to specify predictable model quality problems for detection and correction in dsvl model instances. this is supported at the same time and level as specification of a dsvl. we aim to enable cross-dsvl reuse of common pitfalls and solutions to ease both the dsvl specification burden and to improve the quality of domain models created by dsvl end users. refactoring [fb99, ker05] is a mature technique integrated in most popular ides for evolutionary code design, allowing identification of “bad code smells”: such as poor naming, unnecessary code duplication and over-complexity. these code problems are then addressed by using “best practise” solutions, typically sets of design patterns that offer tried-and-tested solutions, to improve code design quality [ker05]. we propose that such a refactoring approach is desirable to improve model quality at higher levels of abstraction by removing “bad model smells”, such as unnecessary model element duplication, over-complexity, poor naming and layout, poor relationships, redundancy, incompleteness and inconsistency. application of appropriate modelling patterns to address these pitfalls would improve model mailto:j.hosking%7d@auckland.ac.nz mailto:j.hosking%7d@auckland.ac.nz a generic visual language technique for dsvl model refactoring proc. vffp 2010 3 / 13 quality. as in code refactoring ides, automated support for refactoring domain models is desirable. however, to date very few modelling tools provide integrated automatic support for detecting bad model smells and invoking appropriate model refactoring techniques. the state-of-the-art only supports very limited types of models (mainly just uml) with pre-defined, hard-coded refactoring methods. these currently lack a generic way of expressing common but customisable smells and their linked refactoring solutions in dsvl tools [mtm07, mrg09]. meta-tools are an approach for specifying dsvls via meta-modelling and generating dsvl environments from specifications. example meta-tools include metaedit+ [klr96], marama [ghhl08], and microsoft dsl tools [mic08]. we see meta-tools as a suitable platform to integrate refactoring specifications. here meta-model level definition of pattern matching and refactoring rules can be integrated as a behavioural extension to the dsvl meta-model. bad model smell detection and model refactoring support can then be generated from the high level specifications in a similar manner to the modelling support features of the target dsvl tools. [mmbj09] outlines a set of problems for reusing refactoring specifications across different meta-models, including: differing element names and types, relationships and roles; and layout and appearance impacts. one technique for customisation of such generic refactoring specifications uses meta-model attributes or parameters for domain context binding and graph patterns or forms (decouple generic pattern-based meta-model and language concept, and facilitate their integration) [gld08, zlg05]. ali’s critic tool is similar, but provides a visual approach [ahhg09]. another technique uses model typing and aspect weaving adaptations: generic meta-model and pattern specifications are defined, followed by adaptations of target domain meta-models to obtain conforming properties applicable to generic specifications [mmbj09, zlg05]. this requires effort from users to develop generic typing and aspect definitions (usually ocl-based). in the above, hidden dependency (e.g. one domain element involved in multiple pattern roles; multiple domain elements share the same pattern role) and visibility (e.g. display of both domain contexts and generic pattern elements, plus pattern participation bindings) are unresolved problems. we believe a sound refactoring technique preserves original domain meta-models, using them as the basis for behavioural extension, while supporting visualisation of separate juxtaposed generic specifications and domain configurations to mitigate reuse and visualisation problems. dsvl refactorings may also need to consider surface notation and layout issues that code and meta-model refactorings may not. our research aims to generalise a family of common bad model smells (antipatterns) and pattern solutions to improve dsvl modelling. we support generic, customisable refactoring specifications for model-driven reuse across different dsvl meta-model definitions in a metatool. we describe integration of a graph transformation-based visual language technique into a dsvl meta-tool for pattern-based dsvl model refactoring specification. 2 common dsvl model refactorings to better illustrate our intent, we describe several pairs of model refactorings and their generic aspects for reuse potential. for each model example pair, we identify the commonality of their bad smell and refactoring solution. eceasst 4 / 13 volume 31 (2010) 2.1. extract duplicate relation example 2.1.1 illustrates the refactoring of a uml model, which involves classes (e.g. wheel and car) and composition relationships (e.g. a car composes one-to-many wheels). the bad smell is a duplicate composition relationship, and a refactoring solution to address this problem is to extract the composition to a super class. example 2.1.2 shows a similar bad smell in a different uml model instance, but with regard to an association relationship. the refactoring solution is similar but deals with extracting the association to a super class. before refactoring after refactoring 2.1.1. extract composition refactoring in a uml model bad smell: a duplicate composition relationship holds from two source classes to one target class refactoring solution: extract the composition relationship for presence between a new super class and the target class 2.1.2. extract association refactoring in a uml model bad smell: a duplicate association relationship holds from two source classes to one target class refactoring solution: extract the association relationship for presence between a new super class and the target class table 1. generic remove duplicate relation refactoring used in uml models extract composition and extract association, can be generalised as a generic extract duplicate relation refactoring pattern, with a generic bad smell: a duplicate relation between two source participants and a target participant in a domain model. a generic refactoring solution extracts the relation for use between a new parent participant of the two sources and the target. this generic articulation can be specialised to the two refactorings above and others. 2.2. pull up common element example 2.2.1 is another uml refactoring. the bad smell is a common attribute between two sub-classes, resolved by pulling the attribute up to the super class. in example 2.2.2 a web service composition dsvl model, comprises a composite service (enrolment service), two sub services (student service and administration service), and a set of service operations (e.g. login, apply enrolment). a similar refactoring pulls up the common operation from the sub services to the composite service. these two examples can be generalised to a generic pull up common element refactoring pattern. a generic visual language technique for dsvl model refactoring proc. vffp 2010 5 / 13 before refactoring after refactoring 2.2.1. pull up common attribute refactoring in a uml model bad smell: a common attribute (with the same name and type) holds for two classes refactoring solution: pull the attribute up in the super class 2.2.2. pull up common operation in a web service composition model bad smell: a common operation (with the same name) holds for two sub services refactoring solution: pull the operation up in the composite service table 2. generic pull up common element refactoring used in uml and web service compostion models before refactoring after refactoring 2.3.1. remove circular inheritance refactoring in a uml model bad smell: circular inheritance relations hold between two classes refactoring solution: remove the last added inheritance relation 2.3.2. remove circular parentrelation in a family tree model bad smell: circular parentrelation links hold among a chain of persons refactoring solution: remove the last added parentrelaion link that caused the circularity table 3. generic remove circular reference refactoring used in uml and family tree models eceasst 6 / 13 volume 31 (2010) 2.3. remove circular reference example 2.3.1 shows a bad smell of circular inheritance relations between two uml classes (component and composite). a refactoring is to remove the last added inheritance relation that caused the circularity. a similar refactoring in a family tree model is shown in example 2.3.2, to resolve circular parentrelations between two persons (catharine and elizabeth). 2.4. dsvl model refactoring pattern library we have identified a range of common refactorings applicable across dsvls such as those above. we are developing a pattern catalogue with a growing number of generic refactoring patterns accessible by dsvl authors in a dsvl meta-tool. each refactoring pattern is represented in a generic visual language described below. dsvl authors can contribute new patterns, and with an ongoing extension, the catalogue can be analysed for overlaps (e.g. identical smells or solutions in different refactoring specifications) and conflicts (e.g. opposite refactoring solutions for identical smells) at the specification time. applying chosen refactoring solutions in the target dsvl tool needs to consider not just model instance update but diagram update, possibly including layout change, update of different representations in different diagrams, and update of multiple diagrams showing the refactored items. 3 visual specification of model refactoring various formalisms have been used to specify model refactoring [mtm07]. one we are convinced is appropriate is graph transformation (rule-based modification of graphs) [roz97]. this is because it presents an intuitive graphical computation paradigm and a natural fit for describing matching of bad model smells. it also empowers effective validations of specifications through parsing graph grammars. in this approach the left-hand side (lhs) model (source) and right-hand side (rhs) pattern solutions (target) correspond well to source and target of transformation rules in our domain. we believe uml-based approaches lack a natural visual linkage between bad smells and refactoring solutions. specification of anti-patterns and patterns using graph transformations to support model evolution is an existing technique [bek+06, zkdz07, gld08]. however, current solutions don’t separate domain meta-model contexts from common transformation specifications. while some pattern-based reuse within the specified domain is facilitated, reuse across different dsvls is not [mtm07]. our approach aims to provide such a separation by using layers and via a generic but configurable visual language. our approach allows dsvl designers to define, with high-level reuse support, refactoring of bad model smells at the same level of abstraction as their dsvl meta-models. the dsvl meta-models are the domain profiles and generic refactoring specifications are customisable using profile stereotypes. 3.1. specifying refactoring at the dsvl meta-model level in our approach refactoring is specified at the meta-model level using a linked view to a dsvl meta-model designer that includes elements such as domain classes, relationships, shapes, connectors and diagram element maps. generic refactoring specifications are to be contextualised with such structural meta-model elements. the view exploits parallel a generic visual language technique for dsvl model refactoring proc. vffp 2010 7 / 13 orthogonal layered representations, as shown in figure 1, for separate but easy to bind generic refactoring pattern specifications in the top layer (a) and dsvl meta-model contexts in the bottom layer (b). this achieves genericity, customisability and reusability. form-based filtering capabilities support adding in interested potential dsvl meta-model elements for pattern participation in the lower domain model layer. customisations of generic refactorings are to be specified via visual cross-layer links. we elaborate the visual notation as follows. figure 1. top: a dsvl refactoring pattern specification environment (showing a generic extract duplicate relation refactoring pattern customised for uml extract composition – see example 2.1.1 in table 1); bottom: a target dsvl environment with refactoring message based on the specification. 3.2. generic notation in graph transformation paradigm our refactoring specifications contain two parts, shown in figure 1 (a). a bad model smell (transformation precondition) is lhs and pattern solution (post-condition) rhs of a graph transformation rule. this effectively specifies when to apply a refactoring (lhs) to the consequence of applying it (rhs). both the lhs and rhs use the same node, edge and attribute notations, with nodes specifying participants and relationships, edges specifying role bindings, and attributes specifying additional property-based condition checking criteria (e.g. property pattern-matching conditions, local or global constraints) or input acquisition (e.g. user prompt, or calculated dependent value). lhs to rhs mappings define the transformation, and are encoded using identical naming, numbering and colouring. mapped constructs represent (a) (b) (c) (i) (ii) (iii) (iv) (v) eceasst 8 / 13 volume 31 (2010) preserved model element structure, unmapped lhs constructs are deleted, unmapped rhs constructs are created, and attributes of mapped constructs represent updates. our visual language defines the following basic notational elements (also shown in figure 1) for a generic dsvl refactoring specification: 1. generic participant nodes (i), represented by rectangular compartment shapes (holding attribute specifications, collapsed by default) with labels encoding identification number and name, and a placeholder for a to-be bound dsvl meta-model context; 2. generic participant relationship nodes (ii), represented by rounded rectangular compartment shapes with labels encoding identification number and name, and a placeholder for a to-be bound dsvl meta-model relationship context; 3. edges (iii), are directed connectors between participants and relationships representing source and target role bindings; 4. attributes (iv), as compartment members of a participant or relationship, specify pattern matching conditions as a mechanism to formulate refactoring rule application conditions as global or local graph constraints. they are currently specified using c# expressions, which we intend replacing by simplified visual ocl expressions as per our earlier dsvl constraint specification mechanism [lhg07]. building on this base representation explained above, we also enrich the node and edge representations with border line styles to explicitly express the following crucial factors: 1. scaling up pattern matching horizontally. consider example 2.1.1 again, we want to catch and refactor the same bad smell when an arbitrary number (>2) of source classes are present, each related by composition to the same target. the default pattern participant/relationship node in our language captures only one matched instance element. we use a dashed border on a participant (e.g. figure 1 (v)) to represent an elision of a number of horizontally like participants (i.e. multiple sibling instances under the same relationship). horizontal scaling-up is clearly distinctive from vertical scaling-up which is represented on a relationship as explained next. 2. scaling up pattern matching vertically. as seen in example 2.3.1 and 2.3.2, a generic remove circular reference refactoring specification should be able to capture the circularity no matter when it presents between two immediate participants, or in a similar role chain of an arbitrary number of participants. we use dashed borders on a relationship and its source and target role edges (e.g. figure 2 (i)), to represent an elision of a role chain with a number of like participants under the same relationship type guardian. 3. imposing implicit (queried) conditions. our node notation has attribute compartment fields for specifying dynamically queried conditional characteristics for pattern matching. for instance, an attribute in a participant may be specified to hold a certain data value; an attribute in a relationship may specify equality of certain data values between related participants (e.g. figure 3 (ii)). we used a thickened and coloured border to represent such a node (e.g. figure 3 (i)) with an implicitly queried attribute. 3.3. configuring with dsvl meta-model elements the customisation of a generic refactoring specification is a domain context binding process where general abstract pattern elements are instantiated with concrete domain element types. a generic visual language technique for dsvl model refactoring proc. vffp 2010 9 / 13 in our approach the context binding of a dsvl meta-model is visually represented by green dotted lines across the two layers connecting elements in the dsvl meta-model with their participations in the refactoring pattern specification layer. it is a simple cross-cutting linking mechanism. the context binding links can be concealed at individual pattern element levels for diagram clutter management. context bindings are supplemented by a dual text encoding on a pattern element, via underlined text in the bound pattern element, which can also be concealed by collapsing the pattern element, to ease context navigations. figure 2. generic remove circular reference refactoring pattern customised for uml and family tree domain models respectively (see example 2.3.1 and 2.3.2 in table 3) figure 3. generic pull up common element pattern customised for uml pull up attribute (see example 2.2.1 in table 2) (ii) (i) (i) eceasst 10 / 13 volume 31 (2010) we elaborate customised refactoring specifications for two examples shown in section 2. with the context binding links established, the generic extract duplicate relation refactoring pattern specification in figure 1 is customised for a uml extract composition use case (example 2.1.1 in table 1). it specialises the two lhs source modelclass 1 participants (p1 and p2, scaled to represent multiple occurrences), which have duplicate composition 2 relationships (r1 and r2), with a target modelclass participant (p3). it defines the rhs as preserving the matched participants (p1, p2 and p3), but creating a new super modelclass (p4) for the two source modelclasses (p1 and p2) using generalization 3 relationships (r3 and r4), and a new composition relationship (r5) for the super modelclass (p4) to connect to the target modelclass (p3). the unpreserved relationships from the lhs, i.e. the duplicate composition relationships (r1 and r2), are removed during this refactoring. figure 3 shows the specification of such a generic pull up common element refactoring pattern customised for a uml pull up attribute use case (see example 2.2.1 in table 2). the matching condition defined on the lhs is that there are attributes 4 (p4 and p5) in modelclasses (p2 and p3) that share the same name and type (queried in an implicit relationship r3). the rhs specifies the preserving of all matched participants (p1, p2, p3 and p4) except a duplicate attribute (p5), and the preserving of the generalization relationships (r1 and r2). however, a new classhasattribute 5 relationship is to be created for the super modelclass (p1) to hold the common attribute (p4). 4 tool support for realisation and reuse our proof-of-concept tool, maramadsl, has been developed as an extension to microsoft dsl tools [mic08], a visual studio-based meta-tool. our tool provides linked designer views, framework code and code generators to allow refactoring specifications to be integrated at meta-model level with a dsvl definition in the microsoft dsl tools. we have developed an extensible library of functional building blocks to be used in code generation for pattern matching based selection, insertion, deletion and update of model elements. with our tool support, a refactoring specification generates code for a dsvl environment that informs users of detected bad smells as they occur, and provides commands to apply pattern solutions to model instances. in a target dsvl tool environment with user-created domain models, matched bad smells are shown to the user in a message window (figure 1, bottom); double clicking smell messages highlights the pattern participants and relationships in the domain diagram. right-clicking on the diagram or the message will bring up a context menu command to enable execution of the refactoring rule as defined. given the genericity characteristic of our visual language, cross-dsvl reuse can be readily achieved. maramadsl provides support for high-level separate and holistic reuse of model bad smell definition, pattern solution specification, and the overall refactoring transformation. 1 modelclass is the name of the meta-model element in a testing uml tool representing a class. 2 composition is the name of the meta-model element representing a composition relationship. 3 generalisation is the name of the meta-model element representing an inheritance relationship. 4 attribute is the name of the meta-model element in a testing uml tool representing an attribute. 5 classhasattribute is the name of the meta-model element in a testing uml tool representing the relationship between a class and an attribute. a generic visual language technique for dsvl model refactoring proc. vffp 2010 11 / 13 it allows a whole specification or the lhs/rhs to be saved context-free (with all context bindings removed) into a pattern catalogue, appearing in an explorer window, as seen in figure 1 (c). this can then be accessed and drag-dropped from there to a refactoring specification diagram for direct adoption, followed by binding with other dsvl meta-models. accessed pattern specifications can also be easily adapted for reuse in a variant way, e.g. modify or remove any existing participant or relationship, or add elements to meet specific needs. figure 2 shows a generic remove circular reference refactoring pattern customised for the uml and family tree domain models respectively (see example 2.3.1 and 2.3.2 in table 3). the same generic refactoring specification is applied directly to both domain models, with the only difference being context binding of the uml and family tree meta-models respectively. we see our concept is general-purpose and can be similarly implemented in other meta-tools such as marama [ghhl08]. 5 discussion the aim of this work is to empower dsvl authors with easy-to-use definition of bad model smells detection and pattern solutions with high level model-driven reuse support. we aim to support this at the same level as dsvl specifications and to equip dsvl users with patternbased evolution support for domain model development. our realization of this concept is a simple visual language for refactoring specifications which is at the dsvl meta-model level, intuitively using the graph transformation paradigm to link model smells with solutions, and providing common pattern abstraction and configurability for reuse across different dsvls. we are conducting usability studies at each stage of the development of our visual language and tool. subsequent to the preliminary design presented here we have conducted a cognitive dimensions [gp96] analysis to evaluate tradeoffs, strengths and weaknesses of our solution. the visual language explicitly models abstract refactoring rule participants and relationships and allow easy configuration across dsvls through decoupled but interacting layers. it has a clear role collaboration model (role expressiveness) specific to refactoring and pattern concepts. it has expressiveness equivalent to domain-specific code written with apis, with the comprehensiveness of model query and transformation functions (select, insert, delete and update), but with a lower abstraction gradient, augmented understanding, reduced effort, and a much shallower learning curve via closeness of mapping to users’ cognitive models of refactoring pattern presentation and use. we have mitigated areas of hidden dependency and visibility in the language by juxtaposition of orthogonal layered views, and dual coding of custom values through context links and dynamic properties. initiating a refactoring specification requires some hard mental operations and premature commitment when choosing appropriate pattern elements to compose, and understanding overlapping and conflicts in multiple refactorings. however adding abstractions in the form of pre-defined patterns in a pattern catalogue reduces complexity and diffuseness. the use of the visual language reduces error proneness compared to coding, but requires proactive checking of model semantics for correctness. progressive evaluation is allowed but requires a compileand-run cycle for the generated code. the language uses a terse set of graphical symbols but eceasst 12 / 13 volume 31 (2010) with a rather verbose set of textual labels for expressing pattern elements and domain-specific context bindings. diffuseness caused by that is mitigated by using them within typed symbol groups. we wanted to use layout (e.g. align preserved pattern structure elements in lhs and rhs) as a secondary notation as it does not affect any semantics but is good for promoting readability and identification of high-level graph matching patterns. the usual diagram update viscosity problems occur i.e. hard-to-change, and require automatic layout support to mitigate. we are currently focusing on a variety of designs to address the completeness and correctness of the meta-model level refactoring models and to allow multiple specifications to be analysed in order to detect overlapping and conflicts. we aim to provide automated validation of both generic and customised refactoring models. we are looking to integrate an existing graph grammar parser as the backend for validating generic refactoring specifications. we have considered several design options to use visual feedback to inform dsvl authors with missing or conflicting context bindings for customised refactoring specifications. an option we are exploiting is a consistent message window-like notification mechanism as per what we used for notifying of bad smells and refactorings in a dsvl model instance. multiple refactoring rules may share common bad smell patterns present in the lhss, which means that multiple transformations may be due to execute at the same time. in some situations executing one will break the condition matched to execute the other. we want to enable dsvl authors to identify overlapping lhss in multiple specified refactorings and also conflicts if exists, and allow them to set priority order for the detection rules to fire. allowing this to be identified at dsvl design time removes the burden on dsvl users in determining which refactoring to execute when multiple are due to be executed. our intent is to provide a high-level visual analysis graph that automatically gathers information from existing refactoring specifications, represents refactorings as nodes with links indicating overlapping lhss or conflicting rhss, and allows dsvl authors to set execution orders from there. to better support dsvl end users with model evolution based on the refactoring specifications, we are also designing dynamic visualisation of pattern matching and refactoring transformation at model instance level with helpful annotation, playback and rollback features. 6 conclusion model refactoring should be generic and reusable across dsvls, in a similar way that code refactoring has been applied across different programming languages and platforms. we propose adding into a dsvl meta-tool a generic and reusable specification technique for dsvl authors to define model refactorings to support dsvl users evolve their model instances. a graph transformation based visual language approach is proposed for this purpose. bibliography [ahhg09] n.m. ali, j. hosking, j. huh, j. grundy. template-based critic authoring for domain-specific visual language tools, in proc. of the ieee symposium on visual languages and human-centric computing, 2009. pp.111-118, 20-24 sept. 2009. a generic visual language technique for dsvl model refactoring proc. vffp 2010 13 / 13 [bek+06] e. biermann, k. ehrig, c. köhler, g. kuhns, g. taentzer, e. weiss. emf model refactoring based on graph transformation concepts. in proc. of the third workshop on software evolution through transformations: embracing the change (setra2006), 2006. [fb99] m. fowler, k. beck. refactoring: improving the design of existing code. reading, ma: addison-wesley, 1999. [ghhl08] j. grundy, j. hosking, j. huh, k. li. marama: an eclipse meta-toolset for generating multi-view environments, in proc. of the 30th international conference on software engineering (icse’08). 2008: leipzig, germany. [gld08] e. guerra, j. d. lara, p. diaz. visual specification of measurements and redesigns for domain specific visual languages. journal of visual languages and computing 19(3), pp. 399-425, 2008. [gp96] t.r.g. green, m. petre. usability analysis of visual programming environments: a 'cognitive dimensions' framework. journal of visual languages and computing 7, pp. 131-174, 1996. [ker05] j. kerievsky. refactoring to patterns. boston: addison-wesley, 2005. [klr96] s. kelly, k. lyytinen, and m. rossi. meta edit+: a fully configurable multiuser and multi-tool case environment, in proc. of caise'96. 1996. [lb05] f. leung, n. bolloju. analyzing the quality of domain models developed by novice systems analysts. in proc. of the 38th hawaii international conference on system sciences, 2005. [lhg07] n. liu, j. hosking, j. grundy. maramatatau: extending a domain specific visual language meta tool with a declarative constraint mechanism. in proc. of the ieee symposium on visual languages and human-centric computing, 2007. [mic08] microsoft domain specific language tools. http://msdn.microsoft.com/enus/vsx/default.aspx, microsoft, 2008. [mmbj09] n. moha, v. mahe, o. barais, j.-m. jezequel. generic model refactorings. in proc. of models, pp. 628-643, 2009. [moo09] d.l. moody. the “physics” of notations: towards a scientific basis for constructing visual notations in software engineering. ieee tse 2009. [mrg09] m. mohamed, m. romdhani, k. ghedira. classification of model refactoring approaches. journal of object technology 8(6), 2009. [mtm07] t. mens, g. taentzer, d. müller. challenges in model refactoring. in proc. of 1st workshop on refactoring tools, university of berlin, 2007. [rb09] j. rech, c. bunse. model-driven software development: integrating quality assurance. hershey: information science reference, 2009. [roz97] g. rozenberg. handbook of graph grammars and computing by graph transformation. world scientific, c1997. [zkdz07] c. zhao, j. kong, j. dong, k. zhang. pattern-based design evolution using graph transformation. journal of visual languages and computing 18(4), pp. 378-398, 2007. [zlg05] j. zhang, y. lin, j. gray: generic and domain-specific model refactoring using a model transformation engine. volume ii of research and practice in software engineering, pp. 199-218, 2005. electronic communications of the easst volume 3 (2006) guest editors: jean-marie favre, reiko heckel, tom mens managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 proceedings of the third workshop on software evolution through transformations: embracing the change (setra 2006) generating requirements views: a transformation-driven approach lyrene fernandes da silva, julio cesar sampaio do prado leite 14 pages eceasst 2 / 14 volume 3 (2006) generating requirements views: a transformation-driven approach lyrene fernandes da silva1, julio cesar sampaio do prado leite2 1 federal university of rio grande do norte (ufrn) brazil 2 pontifícia universidade católica do rio de janeiro (puc-rio) brazil abstract: this paper reports the use of transformations based on xml to generate requirements views. a strategy to generate views is defined and scenarios and class diagrams are automatically created from a goal oriented model; the v-graph. keywords: requirements models, views, traceability, transformations, xml. 1 introduction during software construction, we may use different types of models and languages such as: scenarios, requirements sentences, lexicons, component models, class diagrams, entityrelationship models, and activity diagrams. these different software representations are necessary because each one of them portrays a different and limited set of characteristics. this is done in order to decrease software complexity and help the engineer to focus on scoped problems. however, because of the volatility of the requirements, it is necessary to be ready for changes, or evolution. requirements evolution happens in two ways: during software development, changing from the high abstraction level to the implementation level, i.e., from the requirements to the code; and in order to make the model ready to attend new requirements or fix errors and omissions [19][23]. in both cases, knowing and managing the interactions between requirements (the traceability) is of fundamental importance. as a consequence it is important to decompose and modularize the concerns of the system for two main reasons: (a) the concerns indicate the coupling and cohesion among their components, and (b) it is important in order to analyze the impact of changes between requirements at the same abstraction level and requirements and software artifacts on different abstraction levels [28]. as defined in [33], traceability means the ability to find related requirements in a requirements specification, discovering: the source of the requirements (pre-traceability); the components that implement them (post-traceability); or requirements that affect each other [28]. traceability is important to manage and to propagate changes in requirements, thus supporting software construction [15]. however, if many different models are used during the construction process, it is necessary to map the information from one kind of model to others, propagating changes, verifying correctness and conflicts among them. in order to address this problem, in this paper, we present an approach based on transformations to create different views of requirements models. the transformations are defined by using rules and have been implemented in the context of xml (extensible markup language) technology, by means of xslt transformations. we exemplify this approach by the creation of rules to transform a goal model, called v-graph, into models: scenarios [23] and class diagrams [4]. generating requirements views: a transformation-driven approach proc. setra 2006 3 / 14 this approach was defined in the context of an aspect-oriented requirement modeling strategy [31][32]. in this context, we have considered that using views is extremely important because they can be an alternative way to separate concerns and decrease tangling and scattering problems that occur due to the tyranny of the dominant decomposition [34]. the vgraph model was used because it can represent both non-functional and functional requirements. furthermore, it explicitly represents the positive and negative interactions between requirements in opposition to use cases, scenarios and requirements sentences which do not tackle the issue of requirements interference. therefore, we can identify crosscutting concerns by analyzing the interactions among them. in this paper, we present our approach to generate views from v-graph, but we omit the details about “aspects” defined in [31][32] because of the limited space available. the remainder of this paper is organized as follows. in section 2, we present the context of this work, the concept of views and the v-graph. in section 3, we present how we can generate different views by using transformations, the benefits of this strategy and the defined transformation rules to generate scenarios and class diagrams from v-graph models. in section 4, we present a case study to illustrate the visualization mechanism. in section 5, we cite some related work. finally, in section 6, we present the concluding remarks and guidelines for future works. 2 state of the art considering software development as an evolutionary process, in which the design and the programming are based on the requirements definition and the requirements are continually changing, software evolution happens: during the development process by refining the models created during the requirements definition process into architecture models and code; and during each activity, by making a set of models better, generating different versions of the same model. in both cases, it is necessary to be able to identify where changes impact, modify and propagate these changes for all the used models. the traceability (or mapping) between models can be supported by a transformation-driven approach [3]. transformations are interesting in this case because they can be used to:  generate views – different total or partial models can be generated from a base model. partial models can represent the system focusing on different concerns or different viewpoints. total models can represent the information of a base model using another notation. in both cases, generating views helps software evolution.  facilitate analysis – by using different views, the engineer can focus on scoped problems, analyze and modify the modeling in a more effective way. consistency and completeness checking are facilitated because transformations can generate models with the same information but changing the perspective to analyze it. a proper inspection mechanism, when in place, can point out errors and omissions between views.  propagate changes – changes made in a model can be automatically propagated to other models. this decreases the rework, increases the engineer’s productivity and guarantees that all models are updated; on the other hand, it is difficult to use a transformation-driven approach, because it is hard to map one model to others. this is not always possible, usually the concerns represented in a model are not represented in another model, some information can be omitted, and thus it is difficult to guarantee the consistency and completeness of these models. eceasst 4 / 14 volume 3 (2006) in the requirements definition process, non-completeness and inconsistencies are more tolerable than in other activities because models created in this stage will be refined by future feedback. these models cannot have all of the information about the solution to the problem and they have to accommodate some conflicts and ambiguities from the domain because these conflicts have to be analyzed and resolved. for us, the creation of views provides different perspectives of the same model, separating the crosscutting concerns in different ways and offering the requirements engineer different ways to analyze these concerns. in section 2.1 we present the concept of views used in this work and in section 2.2 we present the syntax and semantic of the v-graph. 2.1 views views are representations of the overall architecture that are meaningful to one or more stakeholders in the system (ieee st.1471). using views is a way of separating different concerns in order to focus on one at a time. views help understanding and elaborating solutions [33], therefore, they are necessary during all the development process. in the requirements engineering area, the words viewpoints, views and point-of-view are sometimes used with similar or different meanings [22]. in order to make the view concept clear, in [16], three categories of views are presented:  views as opinions (viewpoints) – in the social context, each stakeholder has his premises, priorities and experiences, and they use different ways to deal with the problems. therefore, it is necessary to know how to compare and negotiate the different opinions or different ways of how to look at the things, for example, what is the opinion of the manager, of the seller and of the buyer about an e-commerce site?  views as services (concerns) – the idea of partitioning the system into a set of services that can be connected in different ways provides component-based development. for example, a component for payment of bills, another for security, among others;  views as models (perspectives) – in the context of software engineering many techniques based on languages have been proposed in order to partially portray a system, such as entity-relationship models, use cases diagrams and sequence diagrams. therefore, it is important to detect consistency and completeness problems among these models. these categories of views are not disjointed categories. usually, we use models (perspectives) to represent services (concerns) from the point of view of one or more stakeholders (viewpoint). furthermore, models, by definition, make some types of information explicit and hide others, so we can have models focusing on functions, data, sequence of activities and so on. 2.2 v-graph v-graph is a type of goal model [36]. goal models represent the functional and non-functional requirements through decomposition trees [25]. v-graph, see figure 1(a), is defined by goals, softgoals, tasks and the following decomposition relationships – contribution links (and, or, make, help, unknown, hurt, break) and correlation links (make, help, unknown, hurt, break). each element has a type and topics. the type defines a generic functional or non-functional requirement, for example, security and management. the topic defines the context of that element, for example, data and communication. generating requirements views: a transformation-driven approach proc. setra 2006 5 / 14 figure 1. (a) v-graph and (b) a v-graph example figure 1(b) portrays a v-graph example. in such figure, we can observe that in order to achieve the goal “model [requirements]” (“model” is the type and “requirements” is the topic) the goals “edit [scenarios]”, “edit [lexicon]” and “manage [project]” have to be achieved. the relationships among these four goals are contribution links. the contribution links represent a hierarchy between root (a more abstract element that is father of subelements) and children (an operationalization that can be a leaf or another root of the tree). v-graph is an interesting model to represent requirements because with it we can consider requirements at three abstraction levels (softgoals, goals and tasks). this is important because in the same model we can represent reasons and operations, the context and how each element contributes to achieving the system goals. furthermore, there are important results in goal modeling, concerning: how to analyze obstacles to the satisfaction of a goal [18]; how to qualitatively analyze the relationships in goal models; how to analyze variability [14]; how to analyze conflicts among goals through a propagation mechanism of labels [13]; how to identify aspects in goal models [36]; how to derive a feature, state and component model from goal models [30]; and how to provide goal reuse [24] – this last work mentions a composition mechanism used to integrate a goal model and a reusable goal model from a library. 3 using transformations to generate requirements views views have been used in different activities of software construction because they help the developer to delimit the scope of a problem and thus, its complexity. therefore, the developer can analyze the correctness and completeness of one concern or a set of concerns at a time. during the requirements definition process, as well as during the design process, i.e., during the elaboration of solutions, it is important that developers be able to obtain different views from a base model in order to facilitate the analyses of the solutions created from different viewpoints and perspectives. as we defined in section 2, a view is a representation of the software architecture or of one part of the system's architecture, focusing on one or more concerns, by one or more stakeholders. figure 2(a) presents, through a features model [8], the variability, considering views as models and as services. this feature model shows that a view represents one or more eceasst 6 / 14 volume 3 (2006) services using one or more types of models (notation). therefore, we can create views to the requirements focusing each concern separately (partial views) or in conjunction (total views), using different types of models. (a) (b) figure 2. (a) feature model representing the v-graph views and (b) visualization mechanism therefore, we consider fundamental to have a visualization mechanism in order to facilitate the requirements modeling. an automatic mechanism to generate views can accelerate the modeling process because it decreases reworking and inconsistencies among different requirements models. figure 2(b) summarizes a modeling process using a visualization mechanism to automatically generate views from v-graph. such visualization mechanism consists on a transformation component that needs the following sets of information: the syntax and semantic of the source language (in our case, v-graph) and the target language (representation to be generated), and transformation rules. next subsection deals with how to transform v-graphs into scenarios and class diagrams. 3.1 transformation rules the v-graph is a representation where we can explicitly model functional and non-functional requirements using softgoals, goals and tasks. this is its dominant decomposition manner, an intentional-oriented decomposition. however, the hierarchy and the topics of the v-graph provide new perspectives of the system, based on, for example, situations and data. furthermore, the relationships between goals, softgoals and tasks provide a perspective of interaction, or traceability. using this knowledge, we define rules to transform the information from a v-graph into two different models: scenarios [23] and class diagram [4]. therefore, we provide requirements views that help “combating” v-graph’s dominant decomposition. transforming v-graph into scenarios scenarios are an interesting topic to the software engineering community [35][29]. the scenario-driven software development is based on the concept that using the problem's language (user’s domain) is really beneficial for the interaction and communication between users and developers. scenarios are common situations to the users [31]. they have to take into account the usability, enable the comprehension of the domain and problem and help unifying criteria, the sorting of details and user training [7]. generating requirements views: a transformation-driven approach proc. setra 2006 7 / 14 each scenario describes, through semi-structured natural language, a specific situation of the application or of the domain, focusing on behavior. scenarios can be detailed and used as design, in order to help programming. there are many representation proposals for scenarios, informal representations in free text [7] or formal representations [17]. we opted for an intermediate representation: it facilitates the comprehension using natural language and forces sorting of the information by using a well-defined structure, proposed in [23]. in order to transform the information in v-graph into a scenarios model some steps are followed: 1. first, we generate scenarios and episodes by using the goal tree hierarchy: each node (goals and tasks) of the tree that is not a leaf generates a scenario; each subgoal and subtask that is a leaf generates an episode of that scenario; and each subgoal and subtask that is not a leaf generates an episode with a reference (link) to a scenario; contributions “or” generate optional episodes. 2. second, we generate resources, constraints and context. each topic of goal and task that generated episodes without references to any scenario is a resource of that scenario; each softgoal negatively related (correlation or contribution) to goal/task that generated a scenario generates an exception into that scenario; each softgoal negatively related (correlation or contribution) to goal/task that generated a episode (without reference to any scenario) generates a constraint into that episode; each goal related (contribution) to task that generated a scenario generates the context into that scenario. 3. next, we merge scenarios with the same title, because it is possible there be more than one goal or task with the same name in v-graph in order to facilitate the visualization of the tree of goals. table 1 summarizes the transformation process from v-graph to scenarios and section 4 presents an example of scenarios model generated by using this process. table 1. (a) transformation process and (b) transformations: v-graph  scenarios v-graph scenarios goals, tasks scenarios and episodes in accordance of the hierarchy of goals and tasks softgoals negatively correlated exceptions or constrainsts goals of tasks that generated scenarios context topics of goals and tasks that generated episodes without references to scenarios resources (a) (b) transforming a v-graph into a class diagram objects are executable entities, instances of a class that defines its attributes and services. object or class models, usually, are used when we want to adopt the object-oriented paradigm in the design and programming activities. however, these models can be used during the requirements definition process to represent data and functionalities [33]. in this sense, we derived class diagrams from v-graph models. in order to transform the information in v-graph into a class diagram, we followed the general pattern described below. eceasst 8 / 14 volume 3 (2006) 1. first, we use the hierarchy of goals and tasks to define classes and attributes: each topic of goal/task that is not a leaf generates a class whose name is the topic name; and each topic of goal/task that is a leaf generates an attribute in class generated by its parent node. 2. second, we define the methods of the classes: every goal/task is method of classes whose name is its topic; each goal/task that is a leaf generates a method into class generated by its parent node; if one of the methods refers any topic different of class name then this topic is an attribute of that class. 3. next, we generate the relationships between classes: classes refer at least one similar method are associated; each correlation or contribution between elements that generate classes generates an association into the class diagram; 4. finally, classes with same name are merged. table 2 summarizes the process to transform v-graph into class diagram and section 4 presents an example of class diagram generated by using this process. table 2. (a) transformation process and (b) transformations: v-graph  class diagram v-graph class diagram topic classes and attributes in accordance of the hierarchy of goals and tasks goals, tasks methods contributions, correlations, and goals/tasks that refer similar topics associations (a) (b) 3.2 implementation we implemented this strategy using xml (extensible markup language) and xslt (extensible stylesheet language transformation). v-graph syntax was defined using a dtd (document type definition). the visualization mechanism, i.e., the transformations, was programmed in xslt. therefore, a v-graph model (in xml) is the input to the visualization component and the outputs are scenarios (in html) and class diagrams (in dot). figure 3 shows how we used xml and xslt to implement our strategy. the dot format and the graphviz application [16] are used to create graphic representations to v-graph and class diagrams. the choice for xml based transformations was due to the characteristics of our proposal, models written in xml, and due to the characteristic of our transformation rules. in our case, the transformations were localized and direct, and as such the xslt mechanism was sufficient. of course if more complex rules were necessary, we would have to use a more robust transformation platform. however it is important to stress that despite its simplicity, we generating requirements views: a transformation-driven approach proc. setra 2006 9 / 14 can easily implement different representations and layouts for the information described in xml with its structure defined in a dtd. furthermore, xml can easily be read and changed for different applications. figure 3. xml and xslt used to transform requirements views 4 case study this section presents part of our case study. the complete case study has four goal models: a goal model for an information system that helps writing scenarios and lexicon [32]; a goal model for security; a goal model for reliability; and a goal model for persistence. the vgraph illustrated in figure 1(b) is the part of this case study we have used in this paper to demonstrate our approach. on the right side of figures 4 e 5 we show this same v-graph. the octagons are goals and the hexagons are tasks. pointed links are correlations and the other links are contributions. each goal and task has at least one type and zero or more topics (bracketed text). on the left side of figures 4 e 5, we portray the created views: scenarios and class diagram. figure 4. example of the scenario view eceasst 10 / 14 volume 3 (2006) figure 4 portrays an example of scenarios generated from the v-graph. in this example, there are three scenarios with the titles “model [requirements]”, “edit [scenario]” and “manage [project]”; they were derived from goals with similar names. in the scenario “manage [project]”, there are two resources (project and user) generated from topics of their episodes; the context attribute is generated from the goal “model [requirements]”; the attribute episode is generated based on the goals/tasks that decompose the goals “model [requirements]”, “edit [scenario]” and “manage [project]”; and each underlined episode indicates a relationship with another scenario. figure 5 portrays an example of class diagram to the v-graph (in figure 1b). each goal/task that is not a leaf (and has topics) generates a class into the class diagram. children of goal/task that do not generate classes (and have topics) generate attributes related to the class generated by their goals/tasks parent. relationships between classes are generated from the contribution links between goals/tasks that generate those classes. in figure 5 we can observe the classes “requirement”, “project” and “scenario”, their attributes and operations; the relationships between them are generated based on the relationships between tasks/goals whose topics are source to these classes. figure 5. example of class diagram this case study is available in [32]. the complete modeling has 9 goals, 105 tasks, 12 softgoals, 7 correlations and 173 contributions. after the transformation process applied to this case study, 40 scenarios and 14 classes were generated into the scenarios view and class diagram view, respectively. although the class diagram does not have the types of relationships and cardinality, the models created help the engineer to analyze the domain from the date perspective in opposition to the intentional perspective of the v-graph. scenarios and class diagrams represent two other dominant ways to separate concerns, therefore by using our approach the engineers have these views without having to create them manually. furthermore, any change made in the v-graph can be automatically propagated to the other models. generating requirements views: a transformation-driven approach proc. setra 2006 11 / 14 5 related work although using different types of models helps managing the complexity during software modeling, it causes tangling and scattering of concerns, making it difficult to maintain every model consistent and updated. therefore, integration mechanisms are necessary in order to integrate services and models as well as to integrate opinions (conflicts resolution). this paper focused on the integration of models using a transformation-driven approach. software transformation has been a central topic in different software related areas. in the early seventies/eighties several researchers believed it to be central to the idea of automatic programming and several program transformation initiatives were initiated, notably the irvine transformation catalogue [11]. also in the area of software reuse, the idea of software transformation was particularly successful, for instance [1] and the approaches on product-line [2] and the draco approach to software construction [21][26][30]. the use of transformations, in this type of context, requires a more powerful mechanism, since the control structure is not straightforward and a strict discipline to help the validation of the complex rewrite rules is necessary. there are also many approaches less complex which have been used to transform requirements models into other requirements models or design models. many of them are based on natural language that process or consider the structure of the source language to identify the constructs of the target language, such as: in [6], a process to generate ontology from lel is defined. this approach is based on transformations but it is only semi-automatic. in [5], an approach has been defined to generate activity diagrams from use cases and after that to transform these diagrams into pres, a formal notation that permits verification. therefore, this approach enables the enrichment of the use case model and the production of more precise and complete requirements. in [12], an automated approach to transform feature models into the class diagrams is defined. in [9], a process to integrate rnfs and rfs is defined. this approach uses the constructs of mer, of class diagram and of lexicon extended language (lel) [20], in order to make this integration. such integration process is based on mapping the rnfs specified in lel into the mer and into the class diagram. however, this mapping is not based on transformations, it is based on the analysis of the information in the lel, mer and in the class diagram. in [27], an integration framework of models (modeling methods) is defined. this framework determines the specification of: (1) style – defines the notation; (2) work plan – specifies the activities, strategies and processes to define a view; (3) domain – indicates the domain area; (4) specification – the development method; and (5) work report – indicates the state and history of the modeling. the information described in (1) e (2) is abstract information; they can be applied to every instance of the same type of model whereas information in (3), (4) and (5) of this framework is specific to each instance of the model. the main goal of this work is to give support for consistency checking among different models and managing inconsistencies, facilitating the reuse of information on how to map one representation into others. this framework inspired us to define informally the information described in (1) and (2) in order to specify the transformations from v-graph into scenarios and class diagrams, as we have shown in section 3.2. eceasst 12 / 14 volume 3 (2006) 6 final remarks in this paper, we present a visualization mechanism used to generate requirements models. this mechanism is transformation-driven. we created some transformation rules in order to automatically generate scenarios and class diagrams from the v-graph model. using transformations during the requirements definition helps us make the trace among the different models used. it facilitates modeling because consistent models are generated and changes are automatically propagated. consequently, these transformations help software evolution. the results that we have had using this approach have been satisfactory because we consider that generated views help the engineer analyze the system. however, such views cannot be considered complete models, but initial models that help the engineers because they do not have to begin the modeling from scratch. future work involves: making better transformation rules in order to obtain more detailed models; defining transformation rules to both directions, v-graph  (scenarios and class diagrams) and (scenarios and class diagrams)  v-graph; creating a verification mechanism to report inconsistencies and omissions into each type of view; and also tools are extremely necessary to support the edition of any of these models. furthermore, it is necessary to plan experiments in order to validate our approach at the requirements definition stage and to evaluate what is the impact of using it during the entire software development process. currently, we are working on the definition of the transformation rules to generate the system architecture from the requirements definition. this work is part of our aspect-oriented approach to model requirements [31][32]. when taking crosscutting concerns into account, the visualization approach presented in this paper is equally important because using views is an alternative way to separate crosscutting concerns, facilitating the tasks of modeling, analysis, traceability and software evolution. 7 references 1. d. batory, s. dasari, b. geraci, v. singhal, m. sirkin, j. thomas. achieving reuse with software system generators. in: ieee software, september-1995, pp. 89-94. 2. d. batory, r. lopez-herrejon and p. martin. generating product-lines of product-families. in: automated software engineering conference, 2002. 3. i. baxter. transformational maintenance by reuse of design histories, ph.d. thesis, information and computer science department, university of california at irvine, nov. 1990, tr 90-36. 4. g. booch, j. rumbaugh and i. jacobson. the unified modeling language user guide. addison-wesley, 1999. 5. r. boudour and m. kimour. model transformation for requirements verification in embedded systems, in: asian journal informational technology, 4 (11): 1012-1019, 2005. 6. k. breitman1, j. leite. lexicon based ontology construction. in: lecture notes in computer science 2940editors: c. lucena, a. garcia, a. romanovsky, et al., isbn: 3540-21182-9, springer-verlag heidelberg, february 2004, pp.19-34. 7. j. carroll et al. d'etre: capturing design history and rationale in multimedia narratives. in: human factors in computing systems (chi94), boston-usa, acm press, 1994, p. 192-197. generating requirements views: a transformation-driven approach proc. setra 2006 13 / 14 8. k. czarnecki and u. eisenecker. generative programming: methods, tools, and applications, addison-wesley, 2000. 9. l. cysneiros, j. leite and j. neto. a framework for integrating non-functional requirements into conceptual models. requirements engineering journal, vol. 6, no. 2, p. 97-115, 2001, springer-verlag london limited. 10. draco software reuse, domain analysis and draco information. available at: http://www.bayfronttechnologies.com/l02draco.htm. accessed on: mar, 7th, 2006. 11.m. s. feather. a survey and classification of some program transformation approaches and techniques. in ifip 87, pages 165-195, 1987. 12.f. garcía, m. laguna, y. gonzález-carvajal and b. gonzález-baixauli. requirements variability support through mdd and graph transformation. submitted to elsevier preprint, 2005. 13.p. giorgini, j. mylopoulos, e. nicchiarelli and r. sebastián, reasoning with goal models, proceedings of the 21st international conference on conceptual modeling, 2002, pp. 167181. 14.b. gonzáles, m. laguna and j. leite, “visual variability analysis with goal models”, proceedings of ieee international symposium on requirements engineering (re'04), japan, 2004, pp. 38-47. 15.o. gotel, and a. finkelstein. an analysis of the requirements traceability problem. in: proc. of the first international conference on requirements engineering (icre'94), ieee conputer society press., 1994. p. 94-101. 16.graphviz. available at: http://www.graphviz.org/. accessed on: mar, 7th, 2006. 17.p. hsia et al. formal approach to scenario analysis. ieee software, vol. 11, no. 2, 1994. p. 33-41. 18.a. lamsweerde and e. letier, “handling obstacles in goal-oriented requirements engineering”, ieee transaction software engineering, 26(10):978–1005, 2000. 19.m. lehman. laws of software evolution revisited. lecture notes in computer science, vol. 1149, 1996. p.108-120. 20.j. leite and a. franco. o uso de hipertexto na elicitação de linguagens da aplicação. in: anais de iv simpósio brasileiro de engenharia de software, 1990. p. 134–149. 21. j. leite, m. sant'anna, f. gouveia. draco-puc: a technology assembly for domainoriented software development, international conference on software reuse 1994. 22.j. leite. viewpoints on viewpoints. in: acm joint proceedings of the sigsoft'96 workshops, acm press, 1996. p. 285-288. 23.j. leite et al. enhancing a requirements baseline with scenarios. in: proc. of the third ieee international symposium on requirements engineering (re’97), ieee computer society press, 1997. p. 44-53. 24.j. leite, y. yu, l. liu, e. yu and j. mylopoulos, “quality-based software reuse”, proceedings of the caise 2005-lncs 3520, 2005, pp. 535-550. 25.j. mylopoulos, l. chung, and b. nixon, “representing and using nonfunctional requirements: a process-oriented approach”, ieee transactions on software engineering, 18(6):483–497, june 1992. 26. j. neighbors. the draco approach to constructing software from reusable components. in: ieee trans. on software engineering, vol.se-10, no.5, pp.564-574, september-1984. eceasst 14 / 14 volume 3 (2006) 27.b. nuseibeh. crosscutting requirements. in: proc. of the 3rd international conf. on aspect-oriented software development (aosd 2004), lancaster-uk, 2004. p. 3-4. isbn:1-58113-842-3. 28.w. robinson, s. pawlowski and v. volkov. requirements interaction management. acm computing surveys, vol. 35, no. 2, 2003. p. 132-190. 29.c. rolland et al. a proposal for a scenario classification framework. journal of requirements engineering, vol. 3, springer verlag, 1998. p. 23-47. 30. m. sant’anna, j. leite and a. prado. a generative approach to componentware. in: proc. of the workshop on component-based software engineering, icse'20, kyoto, japan, april 1998. 31.l. silva, j. leite. an aspect-oriented approach to model requirements. in: re'05 doctoral consortium in conjunction on the 13th ieee international requirements engineering conference, paris-france, 2005. 32.l. silva. an aspect-oriented strategy to model requirements. rio de janeiro, 2006. 220p. phd thesis on software engineering puc-rio. in portuguese. 33.i. sommerville. software engineering, ed. 6th, addisonwesley, 2000. 34.p. tarr, et al. “n degrees of separation: multi-dimensional separation of concerns”. in: proc. of the 21st int'l conf. on software engineering (icse'99), 1999. p. 107-119. 35.k. weidenhaupt et al. scenario usage in system development: current practice. ieee software, vol. 15, no. 2, 1998. p. 34-45. 36.y. yu, j. leite and j. mylopoulos, “from goals to aspects: discovering aspects from requirements goal models”, proceedings of ieee international symposium on requirements engineering (re'04), japan, 2004, pp. 38-47. 37.y. yu, j. mylopolous, a. lapouchnian, s. liaskos and j. leite, “from stakeholder goals to high-variability software design”, internal report, 2005. 38.l. zorman. requirements envisaging through utilizing scenarios – rebus. 1995. ph.d. dissertation, university of southern california. enforcement of patterns by constraint-aware model transformations electronic communications of the easst volume 31 (2010) proceedings of the second international workshop on visual formalisms for patterns (vffp 2010) enforcement of patterns by constraint-aware model transformations yngve lamo, adrian rutle and florian mantz 12 pages guest editors: paolo bottoni, esther guerra, juan de lara managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst enforcement of patterns by constraint-aware model transformations yngve lamo1, adrian rutle1 and florian mantz1 1 yla,aru,fma@hib.no, http://www.hib.no ∗ department of computer engineering bergen university college, norway abstract: patterns are descriptions and solutions for recurring problems in software design and implementation. in this paper, some ideas towards a formal approach to the specification of patterns in model-driven engineering (mde) is presented. the approach is based on the diagram predicate framework which provides a formal approach to (meta)modelling, model transformation and model management in mde. in particular, patterns are defined as diagrammatic specifications and constraintaware model transformations are adapted to enforce patterns. moreover, running examples are used to illustrate the facade design pattern in structural models. keywords: pattern, constraint-awareness, model transformation, model refactoring, diagram predicate framework 1 introduction and motivation since the beginning of computer science, developing high-quality software at low cost has been a continuous vision. this has boosted several shifts of programming paradigms, e.g. machine code to compilers and imperative to object-oriented programming. in every shift of paradigm, raising the abstraction level of programming languages and technologies has proved to be beneficial to increase productivity. one of the latest steps in this direction has lead to the usage of models and modelling languages in software development processes. initially, models were adopted in software development processes for sketching the architectural design or documenting an existing implementation. in the latest trend in software engineering, however, models are regarded as first-class entities of the development process. these models are used to automatically generate (parts of) software systems by means of model-to-model and model-to-code transformations. in the literature, this trend is referred to as model-driven engineering (mde). software development projects have traditionally been built following the waterfall approach, a sequential process consisting of requirements specification, design, implementation, testing, deployment and maintenance phases. often a new project was started from scratch by designing the domain model, architecture model, code etc. without any clear methodology or systematic use of earlier experiences. in this context, natural questions which arise are: what is software quality? what is best practice in software engineering? what is a good design? what is an appropriate architecture for a certain kind of software systems? what is a good piece of software? ∗ the research is partially sponsored by the norwegian research council project formgrid. 1 / 12 volume 31 (2010) mailto:yla,aru,fma@hib.no http://www.hib.no enforcement of patterns by constraint-aware model transformations to address the problem with software quality, in the late eighties kent beck and ward cunningham began experimenting with the idea of applying patterns to software engineering [bc87]. moreover, the seminal book [ghjv94] on design patterns published in 1994 by the so-called “gang of four” had a great influence on software development practise. design patterns are usually used as a solution strategy for a common problem, e.g. facade, decorator, singleton, etc, and often describe a solution for a part of a bigger system. although design patterns have been applied in software development for a long time, formalisation of the concept of patterns is still an open research topic [bgl09]. moreover, patterns are usually explained in a semi formal or informal language. in mde the process of developing software is performed by use of (semi-)automatic development steps in form of model transformations. hence, to fully benefit from patterns in mde the patterns should be expressed formally, facilitating model transformations and automatic software development steps. in mde, patterns are used in different phases and for different means during the software development process: • means for communication, e.g. among developers and domain experts • guideline for design; i.e. as a specification for software design and software behaviour • tool for conformance check; i.e. to check whether a model follows a given pattern or not • guideline for design change; i.e. if the design does not follow the desired pattern, the pattern may be forced by use of model transformations and refactoring. to be practically useful, patterns in mde should meet some criteria, e.g they should be formal, abstract, conceptually clear, intuitive, adaptable and reusable. to enhance usability of patterns, it is natural to employ a diagrammatic approach, but still demanding a precise (formal) meaning of the diagrammatic models. the proposed approach of this paper is based on the diagram predicate framework (dpf) [rut10, rrlw10, rrlw09], which is a generalisation and adaptation of the categorical sketch formalism [bw95], where user-defined diagrammatic predicate signatures represent the constructs of modelling languages in a more direct way. in particular, dpf is an extension of the generalised sketches [mak97] formalism [dis03]. dpf aims to combine mathematical rigour – which is necessary to enable automatic reasoning – with diagrammatic modelling. in this paper, we use dpf to formalise concepts related to patterns in mde. we will define these concepts in general in the sense that they may be applied for design patterns or other kinds of patterns such as input and output patterns of model transformation rules. usually patterns describe the structure of an architecture or a problem solution for a (sub)system. in mde a pattern could be represented by a structural model. to ensure the desired behavior of the system the pattern should also have the possibility to describe some of the constraints that the system needs to fulfil. hence a proper formalisation of patterns should also have the possibility to express actual constraints. the remainder of the paper is structured as follows. section 2 outlines dpf as the formal underpinning of our approach. section 3 introduces the formal approach to patterns and pattern enforcement. in section 4, some related research in patterns within mde is presented. finally, in section 5, some concluding remarks and ideas for future work are presented. proc. vffp 2010 2 / 12 eceasst 2 diagram predicate framework dpf is a generic graph-based specification framework that tends to adapt first-order logic and categorical logic to software engineering needs. dpf is generic in the sense that it supports any kind of graph structures (see [dw08] for the general case). however, the variant of dpf which we employ in this paper is based on directed multi-graphs. before introducing the formal foundation of dpf, the terminology adopted in this paper is clarified in the following. the word “model” has different meanings in different contexts. in software engineering, model denotes “an abstraction of a (real or language-based) system allowing predictions or inferences to be made” [küh06]. models in software engineering are typically diagrammatic. the word “diagram” has also different meanings in different contexts. in software engineering, diagram denotes a structure which is based on graphs; i.e. a collection of nodes together with a collection of arrows between nodes. since graph-based structures can be visualised in a natural way, “visual” and “diagrammatic” modelling are often treated as synonyms. in this paper, visualisation and diagrammatic syntax are clearly distinguished. that is, the proposed approach focuses on precise syntax and semantics of diagrammatic models independent of their visualisation. in dpf, models are represented by (diagrammatic) specifications. a specification s = (s, cs: σ) consists of an underlying graph s together with a set of atomic constraints cs [rrlw09, rut10]. the graph represents the structure of the model while atomic constraints add restrictions to this structure. atomic constraints are formulated by predicates from (diagrammatic predicate) signatures. a signature σ = (p σ , ας ) consists of a collection of predicates, each having a name, a shape graph, a visualisation and a semantic interpretation [rrlw09, rut10]. the formal definitions are as follows: definition 1 (signature) a signature σ = (p σ , ας ) consists of a collection of predicate symbols p σ with a mapping ας that assigns a graph to each predicate symbol p ∈ p σ . ας (p) is called the arity of the predicate symbol p. definition 2 (atomic constraint) given a signature σ = (p σ , ας ), an atomic constraint (p, δ) on a graph s is given by a predicate symbol p and a graph homomorphism δ : ας (p) → s 1. definition 3 (specification) given a signature σ = (p σ , ας ), a specification s = (s, cs: σ) is given by a graph s and a set cs of constraints (p, δ) on s with p ∈ p σ . definition 4 (specification morphism) given two specifications s = (s, cs : σ) and s′ = (s′ , cs ′ : σ), a specification morphism φ : s → s′ is a graph homomorphism φ : s → s′ such that (p, δ) ∈ cs implies (p, δ; φ) ∈ cs ′ , illustrated by the following diagram: ας (p) δ δ;φ = s φ s′ nodes and arrows of a specification have to be interpreted in a way which is appropriate for 1 the definition of atomic constraint corresponds to diagrams in category theory. 3 / 12 volume 31 (2010) enforcement of patterns by constraint-aware model transformations table 1: a sample signature σ = (p σ , ας ) p ας (p) proposed vis. semantic interpretation [mult(m, n)] 1 a 2 x f [m..n] y ∀x ∈ x : m ≤ |f (x)| ≤ n, with 0 ≤ m ≤ n and n ≥ 1 [injective] 1 a 2 x f [inj] y ∀x, x′ ∈ x : f (x) = f (x′) implies x = x′ [surjective] 1 a 2 x f [surj] y ∀x ∈ x : ⋃ {f (x)} = y [inverse] 1 a 2 b x f y g [inv] ∀x ∈ x , ∀y ∈ y : y ∈ f (x) iff x ∈ g(y) [composition] 1 f h 2 g 3 x f [comp(f,g)] y g z ∀x ∈ x : h(x) = ⋃ {g(y) | y ∈ f (x)} the corresponding modelling environment [rrlw09]. in object-oriented structural modelling, each object may be related to a set of other objects. hence, it is appropriate to interpret nodes as sets and arrows x f −→ y as multi-valued functions f : x → ℘(y ). the powerset ℘(y ) of y is the set of all subsets of y ; i.e. ℘(y ) = {a | a ⊆ y }. moreover, the composition of two multi-valued functions f : x → ℘(y ), g : y → ℘(z) is defined by (f ; g)(x) := ⋃ {g(y) | y ∈ f (x)}. example 1 (sample signature and specification) table 1 shows a small sample signature σ = (p σ , ας ). fig. 1a shows a sample diagrammatic specification (s, cs: σ) and fig. 1b shows the underlying graph s of s; i.e. the graph of s without any constraints. in s, the nodes x and y are interpreted as sets x and y , and the arrows f and g are interpreted as multi-valued functions f : x → ℘(y ) and g : y → ℘(x), respectively. moreover, the function g is surjective; this is forced by the constraint ([surjective], δ1) on the arrow g. similarly, the function f is total; this is forced by the constraint ([mult(1, ∞)], δ3) on the arrow f. finally, the functions f and g are inverse of each other; i.e. ∀x ∈ x and ∀y ∈ y : x ∈ g(y) iff y ∈ f (x). this is forced by the constraint ([inverse], δ2) on f and g. the graph homomorphisms δ1, δ2 and δ3 are defined as follows: δ1(1) = y , δ1(2) = x, δ1(a) = g δ2(1) = x, δ2(2) = y , δ2(a) = f , δ2(b) = g δ3(1) = x, δ3(2) = y , δ3(a) = f in dpf, we use specifications to represent models at any level of a metamodelling hierarchy. moreover, we distinguish between two types of relations between models and metamodel: typed by and conforms to. a specification sn at level n is typed by a specification sn+1 at level n + 1 if there exists a typing morphism ιsn : sn → sn+1 between the underlying graphs of the proc. vffp 2010 4 / 12 eceasst s(c) f g x y (a)s [inv] f g x [1..∞] [surj] y figure 1: a sample specification (a) s = (s, cs : σ) and (b) its underlying graph s specifications. this corresponds to the relation between a model and its metamodel in the graphbased formalisation of the metamodelling hierarchy. in contrast, a specification sn at level n is said to conform to a specification sn+1 at level n + 1 if there exists a typing morphism ιsn : sn → sn+1 such that (sn, ι sn ) is an instance of sn+1 [rut10]. that is, in addition to the existence of the typing morphism ιsn , the constraints csn+1 are satisfied by (sn, ι sn ). so far we have discussed two concepts for constraining specifications: typing and satisfaction of atomic constraints. these concepts are used to define the relation between models and metamodel. in addition to the conformance requirement, there are other constraints concerning the overall structure of specifications. an example is if one wants to formulate that in emf models “every model must have a root class” and “every class in a model must have the root class as its container, directly or transitively”. in dpf such constraints are expressed by universal constraints [rut10]. a universal constraint is defined as a specification morphism u : l → r, where l and r are the premise and the conclusion of the constraint, respectively. a universal constraint is satisfied by a specification if for any occurrence of the premise an occurrence of the conclusion should also be found. the formal definitions of instance, typed specification and typed specification morphism, conformant specification as well as universal constraints are given in [rut10]. 3 patterns in dpf is this section patterns and pattern matching are formally defined. first a declarative definition of patterns by means of metamodels is given. we also illustrate how patterns (and anti patterns) may be used for model refactoring. pattern enforcement is performed operationally by means of model transformation from a precondition (anti-pattern) in a specification to the desired pattern. 3.1 patterns in mde metamodelling is used for the definition of modelling languages. following this line, we define patterns by metamodels in dpf. that is, a pattern may be seen as an instance of a diagrammatic specification representing the pattern’s metamodel. pattern matching is used to show which parts of a model conform to the metamodel of a given pattern. a match of a pattern in a specification is formalised by a specification morphism. matches may be used to check if a given design follows the desired pattern or not, i.e. pattern finding. definition 5 (pattern) a pattern p is a diagrammatic specification typed over a metamodel m. 5 / 12 volume 31 (2010) enforcement of patterns by constraint-aware model transformations (a) scheduler work workwork1 2 3 computer computer 1 2 (b) conforms to server client facade s c d r :s:s:s :c:c figure 2: metamodel for (a) the facade design pattern and (b) and example of a model following the pattern/metamodel definition 6 (match of pattern) given a pattern p typed over m and a specification s, a match m : p → s of the pattern p in s is a specification morphism m : p → s. the specification s follows a pattern p if there exists a match m : p → s such that m(p) conforms to m. example 2 (facade design pattern) the facade element in the facade design pattern serves as an interface for subsystems. that is, if a system consists of several subsystems which are interacting with each other, the facade design pattern should be followed. in fig. 2a the metamodel for the facade pattern is given. a model following this pattern can be seen in fig. 2b. the model is a snapshot of a scenario illustrating how certain works are deployed on some computers. there are three client elements work1, work2, work3 communicating with two server elements computer1, computer2 via the facade element scheduler. 3.2 pattern enforcement if a pattern p is not followed by a specification s, then the pattern may be enforced by applying a model transformation to s. the precondition for the enforcement of a pattern will then be the source of a model transformation. this is also known as anti-pattern, i.e. a design which is not desired and need to be refactored. an anti-pattern is also defined as a pattern (see fig. 3 for an anti-pattern for the pattern in fig. 2). a model transformation is the automatic generation of target models from source models, according to a transformation definition. a transformation definition is a set of transformation rules that together describe how a source model can be transformed into a target model. definition 7 (model transformation rule) a model transformation rule r is given by a speproc. vffp 2010 6 / 12 eceasst (a) conforms to work workwork1 2 3 computer computer 1 2 (b) server client n d r :n:n:n figure 3: metamodel for (a) anti patterns and (b) an example of anti pattern cification morphism r : l → r. an application of a model transformation rule r is given by a pushout construction, see e.g. [bw95] for a definition of pushout. l m r r m∗ s 〈r,m〉 s∗ p.o. where for each match m : l → s, a match m∗ : r → s∗ is created. definition 8 (pattern enforcement) given a pattern p and a specification s, p may be enforced in s by performing a model transformation t such that t (s) follows the pattern p. the following example shows the enforcement of a pattern by applying model transformation. example 3 (pattern enforcement) building upon example 2. the example illustrates how to refactor a client-server architecture such that it follows the facade design pattern. given the specification in fig. 4b, a model transformation enforces the facade design pattern and creates the design in fig. 4c. the model transformation consists of four rules: 1. there should be exactly one scheduler 2. every connection between a work and a computer is rerouted via the scheduler 3. there should not be more than one connection between a computer and the scheduler 4. there should not be more than one connection between a work and the scheduler 7 / 12 volume 31 (2010) enforcement of patterns by constraint-aware model transformations transformation application scheduler work 1 work 2 work3 computer 1 computer2 (c) work 1 work 2 work3 computer 1 computer2 (b) schedulerscheduler nac lhs rhs rhs scheduler work computer lhs scheduler work computer rhslhs scheduler work scheduler work rhslhs (a) :s :s :s :s :s:s:s :c scheduler computer :c :c scheduler computer :c :c:c :n :n:n:n figure 4: using transformation rules (a) to enforce the pattern in fig. 2, a model (b) with an anti pattern in it is refactored to a model (c) following the required pattern 3.3 constraint-aware pattern enforcement the next step is to take constraints into account while defining, matching and enforcement of patterns. when a constraint-aware pattern is enforced, the constraints of the original specification should be transformed into corresponding constraints in the refactored specification. one way to achieve this is to use constraint-aware model transformations as described in [rrlw10]. in this approach, constraints of the source models are used to control which structures and which constraints should be defined in the target model. adding constraints to patterns can also be used to specify the intended behavior of the design. this section outlines how constraint-aware patterns are formalised and enforced in view of dpf. example 4 (constraint-aware patterns) building on example 3, in fig. 5 we add a constraint to the pattern metamodel in fig. 3. the constraint expresses a requirement that if a client c1 is dependent on a client c2, the host server(s) of c1 should reach the host server(s) of c2. this requirement is expressed by the constraint comp(d, s) ⊆ comp(s, r). that is, the result of the composition of d with s should be included in the results of the composition of s with r. constraints at a modelling level may be expressed as universal constraint on the level below. example 5 (universal constraints) the constraint in example 4 is expressed as a universal constraint in fig. 6a. the specification in fig. 7a satisfies this constraint since for any occurrance of the premise (fig. 6a) an occurrance of the conclusion (fig. 6b) is also found. that is, if work1 is dependent on work2 then computer1 hosting work1 should be able to reach the computer hosting work1. proc. vffp 2010 8 / 12 eceasst figure 5: metamodel of the anti-pattern from fig. 3a extended with constraints figure 6: transformation of (a) source universal constraints to (b) target universal constraints pattern application scheduler work 1 work 2 work3 computer1 (c) work 1 work 2 work3 computer2computer1 computer2 (b) :d :r :d :r :n :n :n :s :s :s :c:c figure 7: a model (a) following an anti pattern is refactored to a model (b) following the required pattern 9 / 12 volume 31 (2010) enforcement of patterns by constraint-aware model transformations example 6 (transformation of universal constraint) building on example 3. fig. 7a shows a specification with a match of the anti-pattern in fig. 5. the rules from fig. 4a are used to transform this specification to the specification shown in fig. 7b. the universal constraint in fig. 6a is transformed to the universal constraint in fig. 6b. this constraint ensures that if work1 is dependent on work2 and the scheduler runs work1 on computer1 then the scheduler should run work2 on a computer2 which is reachable from computer1. 4 related work in [bgl09] a formal definition of patterns is given as a set of graphs and graph morphisms, defining a fixed part and some variable regions. variable regions are used to specify multiple occurrences of sub-patterns. moreover, triple graphs are used for coordinating models with the pattern. the approach also uses synchronisation graphs to relate structural models and behavioral models. in the dpf-based approach patterns are defined by metamodels. moreover, a variable region may be represented in the metamodel with multiplicity [0 . . . ∗]. coordination of patterns with models are done by conformance and match of patterns. pattern-based model-to-model transformation is an algebraic, bidirectional and relational approach to model transformation [lg08] based on triple graph grammar (tgg) [sch94]. this approach is based on triple patterns which express allowed and forbidden relations between two models, where the models are triple graphs. triple patterns can be seen as graph constraints for triple graphs, which specify both negative and positive constraints. pattern-based specifications are compiled to operational tgg rules, which perform forward and backward model transformations by graph rewriting. matches of these patterns are formalised as triple graph morphisms. furthermore, in [löw10], graph rewriting is generalised by using span-categories. in the dpfbased approach, universal constraints are used to express requirements which are expressed by triple patterns in pattern-based model-to-model transformations. these constraints are also used to ensure that pattern enforcement is performed in a way that source constraints are transformed adequately to the target models. in [grø10] a concrete syntax for definition of input and output patterns of model transformation rules is employed. that is, instead of using the abstract syntax of the modelling languages involved in the model transformation, as done usually, one can define transformation rules employing the syntax used for definition of the models themselves. in addition, this approach offers a collection operator which is used for matching and transformation of collections of similar subgraphs. this operator is used for the definition of patterns with variable regions. the dpf-based approach employs also a concrete syntax for definition of patterns. moreover, since patterns are defined by metamodels, variable regions are represented by metamodel elements with variable multiplicity. 5 conclusion and future work in this paper patterns are described by metamodels which are represented as diagrammatic specifications. pattern enforcement is performed by executing model transformations that transform anti-patterns to models following the desired pattern. constraints are used to express requireproc. vffp 2010 10 / 12 eceasst ments that should be fulfilled by models. we require that pattern enforcement adequately transforms these constraints. since patterns are described by metamodels, the relation between anti-pattern and required pattern may be seen as metamodel evolution. in this context, pattern enforcement may be seen as model migration, i.e. transformation of models conforming to the anti-pattern metamodel to models conforming to the required pattern’s metamodel. an interesting line of research in this direction is to find the conditions under which it is possible to automatically generate model migration rules. some preliminary results about model migration is done in [mrr+10]. an other interesting aspect with patterns is the relation between patterns. patterns are diagrammatic specifications and it is natural to relate them to each other by specifications morphisms. a further study of different patterns and their relations should be done to obtain a taxonomy of patterns. references [bc87] k. beck, w. cunningham. using pattern languages for object-oriented programs. technical report cr-87-43, tektronix, inc, september 1987. [bgl09] p. bottoni, e. guerra, j. de lara. formal foundation for pattern-based modelling. in chechik and wirsing (eds.), fase 2009: 12th international conference on fundamental approaches to software engineering. lncs 5503, pp. 278–293. springer, 2009. doi:/10.1007/978-3-642-00593-0_19 [bw95] m. barr, c. wells. category theory for computing science (2nd edition). prentice hall international ltd., hertfordshire, uk, 1995. [dis03] z. diskin. practical foundations of business system specifications. chapter mathematics of uml: making the odysseys of uml less dramatic, pp. 145–178. kluwer academic publishers, 2003. [dw08] z. diskin, u. wolter. a diagrammatic logic for object-oriented visual modeling. in accat 2007: 2nd workshop on applied and computational category theory. entcs 203/6, pp. 19–41. elsevier science publishers b. v., amsterdam, the netherlands, 2008. doi:10.1016/j.entcs.2008.10.041 [ghjv94] e. gamma, r. helm, r. johnson, j. m. vlissides. design patterns: elements of reusable object-oriented software. addison-wesley professional, 1994. [grø10] r. grønmo. using concrete syntax in graph-based model transformations. phd thesis, department of informatics, university of oslo, norway, february 2010. [küh06] t. kühne. matters of (meta-)modeling. software and system modeling 5(4):369– 385, 2006. doi:10.1007/s10270-006-0017-9 11 / 12 volume 31 (2010) http://dx.doi.org//10.1007/978-3-642-00593-0_19 http://dx.doi.org/10.1016/j.entcs.2008.10.041 http://dx.doi.org/10.1007/s10270-006-0017-9 enforcement of patterns by constraint-aware model transformations [lg08] j. de lara, e. guerra. pattern-based model-to-model transformation. in icgt 2008: 4th international conference on graph transformations. lncs 5214, pp. 426–441. springer, 2008. doi:10.1007/978-3-540-87405-8_29 [löw10] m. löwe. graph rewriting in span-categories. in ehrig et al. (eds.), icgt 2010: 5th international conference on graph transformations. lncs 6372, pp. 218–233. springer, 2010. doi:/10.1007/978-3-642-15928-2_15 [mak97] m. makkai. generalized sketches as a framework for completeness theorems. journal of pure and applied algebra 115:49–79, 179–212, 214–274, 1997. doi:10.1016/s0022-4049(96)00007-2 [mrr+10] f. mantz, a. rossini, a. rutle, y. lamo, u. wolter. towards a formal approach to metamodel evolution. in nwpt 2010: 22nd nordic workshop on programming theory. pp. 52–54. november 2010. [rrlw09] a. rutle, a. rossini, y. lamo, u. wolter. a diagrammatic formalisation of mofbased modelling languages. in oriol and meyer (eds.), tools 2009: 47th international conference on objects, components, models and patterns. lnbip 33, pp. 37–56. springer, 2009. doi:10.1007/978-3-642-02571-6_4 [rrlw10] a. rutle, a. rossini, y. lamo, u. wolter. a formalisation of constraint-aware model transformations. in rosenblum and taentzer (eds.), fase 2010: 13th international conference on fundamental approaches to software engineering. lncs 6013, pp. 13–28. springer, 2010. doi:10.1007/978-3-642-12029-9_2 [rut10] a. rutle. diagram predicate framework: a formal approach to mde. phd thesis, department of informatics, university of bergen, norway, 2010. [sch94] a. schürr. specification of graph translators with triple graph grammars. in mayr et al. (eds.), wg :20th international workshop on graph-theoretic concepts in computer science. lecture notes in computer science 903, pp. 151–163. springer, 1994. doi:/10.1007/3-540-59071-4_45 proc. vffp 2010 12 / 12 http://dx.doi.org/10.1007/978-3-540-87405-8_29 http://dx.doi.org//10.1007/978-3-642-15928-2_15 http://dx.doi.org/10.1016/s0022-4049(96)00007-2 http://dx.doi.org/10.1007/978-3-642-02571-6_4 http://dx.doi.org/10.1007/978-3-642-12029-9_2 http://dx.doi.org//10.1007/3-540-59071-4_45 introduction and motivation diagram predicate framework patterns in dpf patterns pattern enforcement constraint-aware pattern enforcement related work conclusion and future work microsoft word eceasst_model_metrics_generation.doc electronic communications of the easst volume 24 (2009) guest editors: j. cabot, j. chimiak-opoka, f. jouault, m. gogolla, a. knapp managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 proceedings of the workshop the pragmatics of ocl and other textual specification languages at models 2009 generation of formal model metrics for mof based domain specific languages marcus engelhardt, christian hein, tom ritter, michael wagner 16 pages eceasst 2 / 16 volume 24 (2009) generation of formal model metrics for mof based domain specific languages marcus engelhardt, christian hein, tom ritter, michael wagner fraunhofer fokus, kaiserin-augusta-allee 31, 10589 berlin, germany {marcus.engelhardt, christian.hein, tom.ritter, michael.wagner}@fokus.fraunhofer.de abstract: the assessment of quality in a software development process is vital for the quality of the final system. a number of approaches exist, which can be used to determine such quality properties. in a model-driven development process models are the primary artifacts. novel technologies are needed in order to assess the quality of those artifacts. often, the object constraint language is used to formulate model metrics and to compute them automatically afterwards. this paper describes an approach for the generation of model metrics expressed as ocl statements based on a set of generic rules. these rules can be applied on any domain specific modeling languages for creating a basic set of metrics which can be tailored for the specific needs of a development process. the paper also briefly describes a prototype of a tool for the generation, computation, and management of these model metrics by using the software metrics meta-model smm. keywords: model metrics, ocl, smm 1 introduction quality of software has become essential to software engineering so that increasingly more resources are provided for tasks dealing with quality assurance in software development processes. in particular, the early and continuous quality assessment can provide quantitative indicators for model quality and help to locate structural problems. but measuring certain properties of software is a hard, timeand resource-consuming task since the tool support for automated quality measurement is still lacking and hence a lot of manual work is required. in model driven engineering the model is the primary artifact of the development process. the quality of the involved models has a significant influence on the quality of the final software. due to the central relevance of a model, the quality requirements for it increase. while numerous quality characteristics for code artifacts have been identified and standardized in various quality models in recent years, the definition of appropriate quality criteria for models is still not well established. an often used means to determine software quality are metrics. applied to several artifacts of the software during its whole life cycle, they can produce comparable evaluations of these artifacts as a basis for later assessments of quality properties. numerous metrics defined on code level can be found in literature. in terms of model driven development, a number of approaches to define metrics, which are useful to determine the quality of models, have been proposed in the meantime. a number of them are referenced in section 2. due to the fact that there is no standard terminology for defining metrics, a great challenge is to find an appropriate mechanism to define them. while the first software metrics had been mostly defined using natural language, which may cause ambiguous definition, others have generation of formal model metrics proc. ocl 2009 3 / 16 been expressed using mathematical formalism. however, the latter requires some kind of formal background and a good mathematical comprehension for understanding. in our approach we use the object constraint language (ocl) [6] for metrics definition which is widely accepted as an interesting balance between formality and understandability. most of the model metrics proposed up to now aim to measure quality properties related to architectural design. therefore, many of these metrics are defined on the uml meta-model in context of uml classes, etc., but are not usable at a lower level. thus, a tool which defines and deals with metrics for domain specific languages (dsl) written in ocl, in particular with capabilities to generate these, is still missing. in this paper we present an approach to automatically generate domain specific metrics for mof based meta-models and a concept to manage and compute them on models which conforms to these meta-models. the paper is organized as follows. in section 2 we briefly summarize related work of model metric definitions and tools for applying metrics to models. in section 3 our approach of how to derive formal model metrics from meta-models will be described. thereby, we briefly introduce the software metrics meta-model smm by the object management group (omg) and describe the main phases of the tool's metrics management and computation concept. furthermore, an overview over some metric generation rules is given including a description and an example for each of them. in section 4 we describe a prototype implementation of the above mentioned approach called metrino. finally, in section 5, we draw conclusions of our work. 2 related work a large number of object oriented metrics is available in literature. a broad overview and comparison obj object oriented design model metrics are given in [12]. several approaches can be found in literature addressing the problem of ambiguous metric definitions. a tool which calculates metrics for object-oriented languages is presented in [1]. in this approach, the metrics are written as sql queries over a relational database schema which serves as the metamodel for the definition of metrics. in [2] the xml query language (xquery) [18] is used to define metrics based on the xmi serializations of meta-models. another approach [3] proposes a formal model for object-oriented design called odem (object-oriented design model) as a foundation to formally define metrics dealing with object-oriented design. baroni et al. [4] were the first authors who proposed the use of ocl (object constraint language) to formalize object oriented metrics. they described the mood metrics based on a meta-model called goodly using ocl. inspired of well known suites of metrics like mood, mood2, moose, emoose and qmood, they have developed a library called flame (formal library for aiding metrics extraction) [5] which contains several object oriented design metrics upon the uml 1.3 meta-model formally expressed with ocl invariants. while numerous approaches for metric tools dealing with formal metrics on code level like ember [13] has been proposed in recent years, the set of metric tools on model level is comparatively small. one approach for the latter is the mova tool [14]. beside some facilities to draw uml class and object diagrams and formulate ocl constraints to precise models, the tool provides some metrics functionality to manually create and compute ocl based metrics for user models in a proprietary environment. for the metric application, the tool internally maps a user model to instances of the mova meta-model which itself is a subset of the uml meta-model. however, the metrics the tool can deal with, are only applicable to the user eceasst 4 / 16 volume 24 (2009) models, but not on instances of them. thus, it is not able to provide the ability to define specific metrics based on the domain the user-defined meta-model describes. [15] proposes a set of tools named moodkit g2 for the extraction of mood design metrics from various ood formalism such as code of oo programming languages like c++ and java and models expressed in modeling languages like uml. for each input type, a specific parser implementation is needed. moodkit g2 uses a textural object oriented design language named goodly as a meta-model for the metric definition. furthermore, borland together [20] is a representative of a so called cots tool which supports metric computation as well. basically, it is a modeling tool that follows the mda approach by supporting the essential technologies such as uml modeling, ocl and qvt. in terms of quality assurance, it utilizes the approach of baroni et al. [4]. the metrics and modeling guidelines, called audits, are also specified as ocl expressions. a standard set of metrics, applicable to uml2 models, is provided. the metric set can be adapted and extended. however, they are limited to uml2 models and no metric generation for dsls is available. there are not many tools available which take domain specific languages into account. one of these tools to mention in this context is dmml (defining metrics at the meta level) [17]. they picked up the approach of [4] and decoupled its metric definitions from the underlying meta-model by defining a separate metrics package containing a single class. each metric is specified as an operation in this class using an ocl body expression. in order to prove the concept, they implemented the chidamber and kemerer metric suite upon the uml 2.0 metamodel for the dmml tool. however, the tool is relatively hard to extend with other metamodels since the user manually has to define a transformation/mapping of the meta-model to a xml schema the tool understands. in addition, the user manually has to create the metrics as ocl queries in a separate file according to the metric names he has to specify when loading the corresponding meta-model. this is necessary, because the tool first creates the metrics package extension to the meta-model needed as the basis for the generation of the corresponding java classes for the metric computation on instances of a model conform to the meta-model. although the dmml tool is with some effort usable to define metrics for domain specific languages, it does not provide any concept for an approach for the generation of metrics for dsls. another relevant approach is the one presented in [20]. it deals with the visual specification of measurements (metrics) and refactorings for any domain specific visual language (dsvl). the approach is based on graph pattern matching. visual patterns expressed in a dsvl called slammer are used to specify relevant elements for a measurement and refactoring type. within a meta-modeling tool called atom, these patterns can be applied to a dsvl in order to generate a modeling environment for the language providing corresponding concrete measurements and refactorings. in addition, the generated environment allows to trigger refactorings when a metric’ threshold is reached or exceeded. though this approach is dedicated to the same problem, it works in a complete different way since it does not ocl but graphical patterns. 3 automatic generation of metrics 3.1 meta‐model for metric definition our approach uses the software metrics meta-model (smm) for the definition of metrics and their computational results. the smm specification [11] distinguishes between measures as the evaluation process of particular quality aspects of software artifacts and measurements generation of formal model metrics proc. ocl 2009 5 / 16 which can be interpreted as the results of those processes. for consistency reasons, we will follow this naming convention. currently being available in beta status, smm is a specification consolidated by the omg for an extensible meta-model that primarily should establish an interchange of measurements over existing software artifacts. those artifacts could be source code or more interesting in the context of this paper – models, as well. smm contains meta-model classes for numerous types of measures and their measurements including a set of contextual information. as mentioned above, the meta-model specifies several types of measures and measurements for different outcome values of the evaluation processes (measures). the latter could assign either numeric values of a domain with a pre-defined ordering relation or numeric values representing ratios (e.g. percentages). in addition, the smm provides appropriate classes for the mapping of values of a particular interval to a related symbol. in terms of smm, these types of measures are called ranking. symbolic values like “good”, “satisfying” and “bad” can be considered as such a ranking. the two basic measure types are dimensionalmeasure for numerical evaluation result values and ranking for correspondent symbolic result values. furthermore, the meta-model specifies three subtypes of the dimensionalmeasure class. one of them is directmeasure whose result value refers to the return value of a given operation stated in the corresponding property of the class. another type is the binarymeasure which associates two base measures and accumulates their evaluation results using a binary function (functor). the last to mention subtype of dimensionalmeasure is the collectivemeasure class. measures of this type are usable for model elements which aggregate other elements (children). applied to such a container, a collectivemeasure itself applies its related base measure to each aggregated element to obtain a set of base measurements. afterwards, these values are combined to the overall value for the measurement of the collectivemeasure itself using a particular accumulator like sum, minimum, maximum, etc. the set of available accumulators is extensible by providing corresponding specializations of the collectivemeasure class. the last to mention smm measure type in this paper is the counting class which is a subclass of directmeasure. the given operation of a counting measure acts as a recognizer function and has to return either 0 or 1 based upon recognizing the measurand. fig. 1. fundamental approach of the smm meta-model the fundamental approach of the smm meta-model is shown in fig. 1. each measure has a scope which determines the set of possible elements the measure can be applied to. this set can be constraint either by mentioning a class name each element in the scope should be an instance of, the explicit enumeration of member elements (a set of mof::elements) or the eceasst 6 / 16 volume 24 (2009) reference to a boolean operation. referred to as the recognizer, the latter provides a boolean value for each element of the examined model which determines whether the particular element should be a member of the scope or not. as already mentioned, each measure produces a measurement as result of the evaluation process. for each measure type the smm specifies a corresponding subtype of the measurement class, e.g. for directmeasure the directmeasurement class with a property value holding the result value of the related operation. each measurement has an association to an object of type observation which stores various contextual information related to the measurement, such as the time of evaluation, the responsible tool, etc. 3.2 model metrics generation rules the definition of model measures using ocl expressions has been done extensively for uml models as outlined in section 2. following these approaches, we also use ocl in our concept to describe measures formally. however, in contrast to many other available solutions, we target on a general approach which is capable of dealing with measures on any model conform to the mof meta-model. in practical environment we have identified the necessity to provide measures for dsls whose significance increase. the definition of domain specific measures could be a very time consuming task, so that a generative approach would be desirable. therefore, beside the possibility to define custom concrete measures for a domain specific model, we provide concepts to automatically generate domain specific measures based on a set of generic rules. fig. 2 shows the correlation between the different relevant terms. fig. 2. correlations between models, rules and measures the generation rules themselves are formulated as ocl expressions upon the meta object facility (mof) [7] meta-model. as part of the eclipse modeling framework [8], the ecore meta-model is a famous and widely used implementation of the essential part of mof (emof) and thereby practically suitable to serve as the meta-model for the ocl expressions used in generation rule definitions. the evaluation of a rule’s ocl expression when applying the rule to a mof conform meta-model results in a set of ocl tuples. each tuple provides measure specific data, e.g. its scope and its generated name, which are required to generate the corresponding smm measure for the meta-model in context. the type of the generated generation of formal model metrics proc. ocl 2009 7 / 16 measures is always identical to the measure type of the corresponding rule. in case of a rule of type directmeasure, the data additionally has to contain a value for the measure’s operation property value which itself is an ocl expression. a detailed explanation of these correlations is given for one of the generation rules presented in the remainder of this section. regarding the measures defined in the currently available metric sets, we encountered basic patterns and common aims of particular groups of metrics. these patterns lead to the definition of numerous generation rules which allow the automatic derivation of domain specific measures depending on the meta-model, the rules are applied to. the generated measures are almost ready to run on models (instances of the meta-model) they are derived from. the only thing, the user has to add in order to make a measure runnable, is its threshold value which naturally depends on the acceptable value for the particular quality property being measured. the measures generated on the basis of this rules can be tailored for the specific requirements of a particular development process. in fact, these measures are able to provide a new kind of model quality assessment since they work on an arbitrary meta-model and assess quality aspects within a particular domain. in the following sections we describe the set of generation rules we identified so far. for each rule we shortly summarize the pattern which upon the rule is based and we illustrate the rule by applying them on a common example. each application of a generation rule results in a set of measures presented as well. due to space limitation we only present the complete specification of the first rule and of the resulting measures. for the specifications of all rules detected so far we refer to the appendix. the sample meta-model used for the following rule examples is based on a meta-model of the eclipse help [9] and illustrated in fig. 3. it is a simplified version of a library concept space. fig. 3. sample meta-model of a library eceasst 8 / 16 volume 24 (2009) 3.2.1 partitioning based on enumeration typed class property description. the rule is applicable to classes in the analyzed meta-model having one or more attributes with an enum type. since an enumeration defines a data type with a finite domain, it is possible to partition the set of instances of such a class based on the enumeration’s literals. the rule generates a specific collective measure with sum accumulator and a corresponding counting measure as base measure for each enumeration literal which aims to count the instances of a matching class grouped by the particular values of the enumerated type. therefore, the number of the generated measures is equal to the number of the literals of the examined enumeration type. as mentioned above, rules in our approach are defined upon the mof meta-model. since we use emf in our prototype, a rule is defined with elements of the ecore meta-model. the model classes and associations, the rule uses, are shown in fig. 4. fig. 4. model elements in ecore meta-model used by the rule the ocl operation property of the base measure which has elements of type eclass in scope is formally specified as: self.eattributes->select(a | a.etype.ocliskindof(eenum)) ->collect(a | a.etype.oclastype(eenum).eliterals->collect(l | tuple { scope = self, namefragments = sequence {'noof', a.etype.oclastype(eenum).geteenumliteral(l.value).literal.upperfirst(), self.name.upperfirst()}, operationfragments = sequence{ generation of formal model metrics proc. ocl 2009 9 / 16 'self.', a.name, ' = ', a.etype.name, '::', a.etype.oclastype(eenum).geteenumliteral(l.value) .literal}})) this rule uses an ocl helper operation “upperfirst” to transform the first letter of a string into the corresponding uppercase letter (see appendix). example. the book class of the library model has an attribute category of the enumerated type bookcategory. this enumeration type contains three literals, namely mystery, sciencefiction and biography. the generation process on the library model using this rule would result in the following three ocl tuples describing the resulting base measures: tuple{scope = book, namefragments = [noof, mystery, books], operationfragments = [self., category, = , bookcategory, ::, mystery]} tuple{scope = book, namefragments = [noof, sciencefiction, books], operationfragments = [self., category, = , bookcategory, ::, sciencefiction]} tuple{scope = book, namefragments = [noof, biography, books], operationfragments = [self., category, = , bookcategory, ::, biography]} the information provided by a tuple for a base measure are also used to generate the collective measure for the model class having a containment reference to the class in scope of the corresponding base measure. in case of the first tuple the collective measure noofmysterybooks will be generated for the enumeration literal mystery. this measure uses a generated base measure of type counting whose operation property in ocl will be defined as follows: self.category = bookcategory::mystery when computed on a snapshot (instance) model of the library meta‐model, the collective measure noofmysterybooks will apply its base measure to all book instances contained in an instance of the library class. for each book whose category value is equal to the enumeration literal mystery, the counting base measure will return the value “1” and thereby increment the measurement value of the collective measure. 3.2.2 number of contained elements description. the rule detects classes in a meta-model having containment references. for each match a specific measure is derived which aims to count the referenced elements of a detected containing element in an instance model of the meta-model. example. according to the example library meta-model the rule produces six measures for the library class. these are:  noofborrowerslibrary  noofemployeeslibrary  noofwriterslibrary  noofbrancheslibrary eceasst 10 / 16 volume 24 (2009)  noofstocklibrary  noofbookslibrary 3.2.3 partitioning based on boolean class property description. the rule matches to meta-model classes which have at least one attribute of type boolean. for each of these attributes the rule leads to the generation of a model specific measure which counts the instances of a matching class whose value for the examined attribute is “true”. example. applied to the example library meta-model, the rule generates three measures for the attribute damaged of the model class audiovisualitem. first of all, the measure noofdamagedaudiovisualitem will be generated. due to the fact that the classes bookontape and videocassette are subclasses of audiovisualitem, the rule would additionally create the measures noofdamagedbookontape and noofdamagedvideocassette, respectively. 3.2.4 referential optionality description. the rule matches to model classes that are the origin of an association with a lower bound value equal to zero. for each match the rule causes the generation of a measure which counts the instances of a matching model class where the reference’s upperbound value is equal to zero. example. applied to our example meta-model the rule generates the following measures:  noofbookontapewithoutauthor  noofbookontapewithoutreader  noofemployeewithoutmanager  nooflibrarywithoutparentbranch  nooflibrarywithoutbranches  nooflibrarywithoutborrowers  nooflibrarywithoutbooks  nooflibrarywithoutstock  nooflibrarywithoutemployees  nooflibrarywithoutwriters  noofwriterwithoutbooks  nooflendablewithoutborrowers  noofvideocassettewithoutcast 3.2.5 depth of instance tree description. this rule matches to nested class structures in a meta-model. these hierarchies are modeled through recursive class associations or associations between classes joining the same inheritance hierarchy (composite), respectively. this rule can be considered as a semantic equivalent to the chidamber & kemerer metric depth of inheritance tree (dit) shifted to a lower model level. example. an example for a nested structure, this rule matches to, can be found in the example meta-model. the library class has a containment reference to the library class itself. this association is meant to model a branch hierarchy of a library. applied to the library model, the rule would create a measure named depthinlibrarytree which is useful to calculate the depth of each branch, e.g. instance of the library class, in the generation of formal model metrics proc. ocl 2009 11 / 16 library’s hierarchy of branches. in case of class inheritance the name of the top level generalization class is used to compose the measure’s name. 3.2.6 number of children of an instance description. like the rule depth of instance tree this rule is applicable to nested class structures in a meta-model. for each match a specific measure will be generated which calculates the number of children of each class instance in the hierarchy. example. based on the example library model, the rule would generate a measure for the library class. this measure, which would be called noofchildrenlibrary, counts the number of branches of each particular library class instance. 3.2.7 referential existence dependencies between classes description. this rule is meant to generate measures which will detect referential existence dependencies between instances of model classes sharing an association. these dependencies can be found regarding the lower bound value of the association. if this value is greater than zero, the existence of the instances of a class at the opposite association end are logically dependent on the existence of instances of the class with the mentioned association end (having the lower bound value greater than zero). the number of minimal required class instances is determined by this lower bound value. this rule assumes that instances which are associated with just so many instances, as the lower bound value suggests, have a greater significance in the model since the deletion of one of the associated instances will affect the deletion of the independent instance in order to maintain the model valid. the rule generates measures for each model class having an association to another class with a lower bound value greater than zero for the opposite association end. a created measure counts the instances of the scope’s class associating just as many instances of the other class as the lower bound value of the meant association end claims. example. in case of the example library meta-model, the rule would match to the association between the borrower class and the interface lendable. a borrower will only be captured in the model if he borrows at least one lendable item. this is modeled by the lower bound value “1” for the association end borrowed. applied to the example meta-model, the rule would create the measure noofborrowersminimalborrowed which will count those instances of the borrower class that are associated exactly with only one instance of a class implementing the lendable interface. 3.2.8 instance (usage) ratio in inheritance structures description. the rule applies to inheritance structures in a meta-model. for each subclass in an inheritance hierarchy it creates a measure which calculates the ratio of the number of its instances to the total number of the (polymorphic) instances of its super type. example. focusing the inheritance tree of the library meta-model’s class item, the rule would generate the following six measures:  ratioofcirculatingitemtoitem  ratioofperiodicialtoitem  ratioofaudiovisualitemtocirculatingitem eceasst 12 / 16 volume 24 (2009)  ratioofbookstocirculatingitem  ratioofbookontapetoaudiovisualitem  ratioofvideocassettetoaudiovisualitem 3.2.9 aggregation of associated elements description. this rule matches to classes which have at least one multiplicity-many association. it creates measures which apply aggregate functions to the instances of such a class to assess the class-wide maximum, minimal, average, etc. value of referenced elements count. example. regarding the association employees of the library model the rule would create measures like:  maxemployeesalllibrary  minemployeesalllibrary  avgemployeesalllibrary 3.2.10 aggregation based on numeric property description. this rule matches to classes which have at least one property with a numeric type. it generates measures which apply aggregate functions to the instances of such a class to assess the class-wide maximum, minimal, average, etc. value for the examined property. example. referring to the book class of the library meta-model this rule would lead to the generation of measures like:  maxpagesallbook  minpagesallbook  avgpagesallbook 4 tool support – metrino in this section we introduce a prototype implementation of our approach for the generation of domain specific measures and its main operational phases. to be practically useful, the tool additionally provides the functionality to manage and compute generated or user-defined measures and to visualize their computational results in appropriate charts. the application of the presented rule set could result in a huge number of metrics (measures). not all of them are of the same importance and therefore an adequate and tool-supported metrics management is inevitable. the tool is implemented as a set of plugins for the eclipse ide and uses the oslo library [10] for the evaluation of ocl expressions occurring in both, rules and measures. since rules and measures in our tool are defined using ocl query expressions, all values of the operations defined in the smm meta-model, like the recognizer property of the scope class and the operation property of a directmeasure, are ocl expressions which are evaluated by the oslo ocl processor used in the prototype implementation. an example ocl expression is presented in section 3.2.1. the metrino tool basically operates in four phases: the rule management phase, the measure generation phase, the measure management phase and the measure evaluation phase. an overview of these phases is depicted in fig. 5. generation of formal model metrics proc. ocl 2009 13 / 16 fig. 5. the four phases of metrino in the rule management phase, the user can either define generation rules from the scratch or load an existing rule model (e.g. based on the rule set presented in section 3.2) and modify its contained rules. the rules defined in the rule model serve as input for the measure generation phase. in order to run the generation process, the user first has to load a meta-model, measures should be derived from, and then select the rules to use from a selection dialog (rule selection). the tool then applies each selected rule to the meta-model and generates a measure for each match. by default, the generated measures are grouped in smm categories on the basis of the model types they are applicable for. the result of the measure generation is an exportable/saveable measure model (smm model) containing all the generated domain specific measures or even a tailored subset of them. the measures are almost ready to be applied to an instance model. the only property, the user has to specify/modify, is the measure's threshold value in order to obtain feasible graphical reports of the measure's evaluation results (measurements). measure management phase: the generated measures can be modified freely. of course, the user additionally can define custom measures for the model or drop existing ones. in addition, the user can group a particular set of measures to run at once, which assess the same quality aspect of the model, as a so called audit. in the measure evaluation phase, the tool applies a set of measures, the user has selected before, to an instance of the model these measures have been generated for. along with the evaluation time and some other contextual information, the resulting measurements are stored in the corresponding measure model. it is important to mention that the four phases do not necessarily have to be run through starting from the first – the rule management – phase since the user can load a existing rule model or measure model. in this case, the rule management phase and the measure management phase are optional so that the user directly can continue with the measure generation and the measure evaluation, respectively. the tool provides several charts for the graphical processing of evaluation results available in the measure model. beside kiviat graphs to display numerous measurements for an element at once and various other graph types, the tool is able to visualize the change of measurements over time since the date of each measurement is available in the measure model. fig. 6 shows eceasst 14 / 16 volume 24 (2009) a screenshot of the prototype implementation depicting the main views of the tool and a kiviat graph for some measurement results. fig. 6. screenshot metrino 5 conclusion and further work in this paper, we have identified the need for a metric tool which is able to deal with domain specific model metrics. since the definition of metrics on this level could be very time consuming due to their uniqueness, an approach for the automatic generation of those measures would be desirable. as outlined in section 4, we were not able to find an approach or even (prototype) implementation which provides such a facility using ocl. in order to meet this deficiency, we have introduced a set of generic rules derived from patterns of model measures already available in literature. furthermore, we have described the fundamentals of our approach for generating metrics for domain specific languages. following the work in [5, 16, 17] we use ocl for the formal definition of both rules and metrics. in order to facilitate our approach, we have developed a prototype which allows the generation and evaluation of model metrics for dsls. based on the smm as the underlying meta-model for the definition of metrics and their computational results, the prototype implementation additionally offers some functionality to manage rules and measures as well as several facilities for the graphical processing of measure evaluation results and even its comparison over history. in further steps, we plan to enhance our approach and the metrino tool in different ways. first of all, we plan to extend the set of measure generation rules in order to provide a broader basis for the generation of domain specific measures. in addition, we intend to realize the measure generation process as a model-to-model transformation using query view transformation (qvt) [19]. therewith, we will avoid the creation of an intermediate structural specification for the generated measures like the currently used ocl tuple sets a rule returns. moreover, we plan to extend the metrino tool with several features to create comprehensive reports for measure evaluation results in standard formats such as microsoft office document formats. generation of formal model metrics proc. ocl 2009 15 / 16 finally, we target on applying our approach to more industrial case studies in order to get more detailed feedback on the usability of our approach. 6 acknowledgement this research has been co-funded by the european commission within the 6th framework programme project modelplex contract number 034081 (cf. http://www.modelplex.org). 7 references 1. wilkie, f.g., harmer, t.j.: tool support for measuring complexity in heterogeneous object-oriented software. in: proceedings of the international conference on software maintenance (icsm’02), 152 (2002) 2. el-walkik, m. m., el-bastawisi, a., riad, m. b., fahmy, a.a.: a novel approach to formalize object-oriented design metrics. in: proceedings of evaluation and assessment in software engineering (ease’05) (2005) 3. reißing, r.: towards a model for object-oriented design measurement. in: quantitative approaches in object-oriented software engineering, (qaoose’01), 2001 4. baroni, a.l., braz, s., brito e abreu, f.: using ocl to formalize object oriented design metrics definitions. in: proceedings of ecoop workshop on quantitative approaches in object-oriented software engineering, malaga, spain (2002) 5. baroni, a., brito e abreu, f.: a formal library for aiding metrics extraction. in: 4th international workshop on oo reengineering, darmstadt, germany (2003) 6. omg: object constraint language. http://www.omg.org/docs/formal/06-05-01.pdf 7. omg: meta object facility (mof) core specification. http://www.omg.org/spec/mof/2.0 8. eclipse foundation: eclipse modeling framework. http://www.eclipse.org/modeling/emf/ 9. eclipse foundation: eclipse documentation. http://help.eclipse.org/ganymede/topic/org.eclipse.emf.validation.doc/references/exam ples/exampleoverview.html 10. fraunhofer institute for open communication systems: open source library for ocl. http://oslo-project.berlios.de/ 11. omg: software metrics meta-model (smm) 1.0 – beta 1. http://www.omg.org/docs/ptc/09-03-03.pdf 12. el-wakil, m., el bastawissi, a., boshra, m., fahmy, a.: object-oriented design quality models a survey and comparison. in: 2nd international conference on informatics and systems (infos04), cairo, egypt, 2004 13. wilkie, f.g., harmer, t.j.: tool support for measuring complexity in heterogenuous object-oriented software. in: proceedings of the international conference on software maintenance (icsm’02), montreal, canada (2002) 14. clavel, m., egea, m., torres da silva, v.: model metrication in mova: a metamodel-based approach using ocl. (2007) 15. brito e abreu, f., ochoa, l., goulão, m.: the goodly design language for mood metrics collection. (1997) eceasst 16 / 16 volume 24 (2009) 16. mcquillan, j.a., power, j.f.: a definition of the chidamber and kemerer metrics suite for uml. report nuim-cs-tr2006-03, department of computer science, national university of ireland, maynooth, ireland (2006) 17. mcquillan, j.a., power, j.f.: towards the re-usability of software metric definitions at the meta level. in: european conference on object-oriented programming, nantes, france (2006) 18. w3c: xquery 1.0: an xml query language. http://www.w3.org/tr/xquery/ 19. omg: meta object facility (mof) 2.0 query/view/transformation specification. http://www.omg.org/docs/formal/08-04-03.pdf 20. guerra, e., de lara, j., díaz, p.: visual specification of measurements and redesigns for domain specific visual languages. journal of visual languages and computing vol. 19(3), elsevier (2008) supporting pervasive and social communications with frascati electronic communications of the easst volume 28 (2010) proceedings of the third international discotec workshop on context-aware adaptation mechanisms for pervasive and ubiquitous services (campus 2010) supporting pervasive and social communications with frascati rémi mélisson, daniel romero, romain rouvoy, and lionel seinturier 13 pages guest editors: sonia ben mokhtar, romain rouvoy, michael wagner managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst supporting pervasive and social communications with frascati rémi mélisson, daniel romero, romain rouvoy, and lionel seinturier inria lille – nord europe, adam project-team, university of lille 1, lifl cnrs umr 8022, 59650 villeneuve d’ascq, france firstname.lastname@inria.fr abstract: in pervasive environments, the runtime adaptation of applications is done considering available event sources and services. to do that, the events have to be collected and processed, and the volatile services identified and accessed. however, although the event flow and service mobility are key issues in the adaptation process, existing solutions fail to deal with them in a simple and flexible way. therefore, in this paper we propose to face these issues by combining the sca (service component architecture) standard, micro-blogging services and discovery technologies. in particular, we benefit from the sca extensibility, supported by the binding concept, for introducing two new communication mechanisms: i) social bindings, allowing asynchronous event exchange via twitter and, ii) pervasive bindings that provide support for discovery using standard protocols such as upnp. we add support for these bindings in frascati (a platform for sca) and illustrate their usage with a smart home scenario that requires the integration of heterogeneous technologies. keywords: social networks, pervasive computing, service-oriented architectures 1 introduction in pervasive environments, the adaptation of applications requires the collection, filtering and processing of events produced by different kinds of sources (e.g., mobile devices and sensors), to decide the required reconfigurations. the different responsibilities of the adaptation—i.e., monitoring, analysis, decision making and execution—can be distributed in several entities, which dynamically join and leave the environment, in order to benefit from the most powerful devices. therefore, we can consider the adaptation as a process that requires the exchange of events between the different participants—i.e., event sources, decision makers and adaptive applications. however, although the information flow and mobility are key issues in the adaptation process, the existing approaches fail to deal with them in a simple and flexible way. in this paper we propose to extend the sca (service component architecture) [ope07] model in order to increase communication capabilities in the changing pervasive environments. in particular, sca provides the flexibility for adding new kinds of interaction by means of bindings. sca bindings encapsulate the communication protocols, isolating distribution concerns from the business logic. we take advantage of this concept in order to bring social and pervasive communications into sca. in this way, we introduce two new bindings: social bindings and pervasive bindings. the formers benefit from micro-blogging services, such as twitter [mak09], to build 1 / 13 volume 28 (2010) mailto:firstname.lastname@inria.fr supporting pervasive and social communications with frascati social networks for asynchronous event exchanges in pervasive environments. the latter supports mobility of entities in the environment by providing discovery support via the upnp (universal plug and play) protocol [upn08]. we choose upnp because it is a well-accepted standard in the home entertainment industry to create, for example, tvs and network-attached storage (nas) devices. furthermore, the digital living network alliance 1 (dlna), which ensures interoperability between devices from different manufacturers, supports the usage of the upnp technology. we integrate the social and pervasive bindings into frascati [smf+09] (a soa platform for the sca standard) and illustrate their use with a smart home scenario exhibiting challenges in terms of protocol heterogeneity and integration. we claim that the encapsulation of the distribution concerns in sca bindings enables the transparent event exchange and dynamic service discovery in pervasive environments. we illustrate the usage of our social and pervasive bindings by defining a smart home scenario the rest of this paper is organized as follows. we start by presenting a smart home scenario (cf. section 2) in order to motive the use of our approach and the foundation of our proposal (cf. section 3). we continue by describing the integration of our pervasive (cf. section 4) and social (cf. section 5) bindings for allowing event distribution. after discussing the state-of-theart (cf. section 6), we conclude and give some promising perspectives (cf. section 7). 2 motivating scenario: the digihome platform the work presented in this paper is motivated by the digihome platform, which introduces the challenges for better connecting smart appliances in home environments. as explained in [rht+10], a digihome environment is characterized by the diversity of communication protocols supported by the physical equipments deployed in a house. although, standards like upnp and more recently zigbee [zig10] have emerged and are supported by a growing number of commercial solutions, there is no general agreement on a single protocol for supporting the integration of home appliances. additionally, the emergence of social networks like facebook and twitter have encouraged new means of communication where users can easily share information with a community of trusted contacts via micro-blogging services. in this context, we describe two scenarios where these technologies are smoothly integrated in a modular platform for implementing advanced context-aware home monitoring situations. scenario 1. alice owns two digital frames at home. one of them is able to display pictures from a upnp media server, via a wifi connection. the other frame has the ability to subscribe to a really simple syndication (rss) feed remotely published. however, alice is not interested in displaying pictures that are randomly or statically selected in a library. she would rather prefer to display pictures according to her personal preferences stored on her smartphone. this feature therefore requires the digihome system to automatically detect alice’s smartphone and retrieve her preferences for customizing display for the two frames. additionally, when bob joins the room, the digihome platform should import his preferences, and try to satisfy bob’s and alice’s desires to display pictures. 1 digital living network alliance: http://www.dlna.org/home proc. campus 2010 2 / 13 http://www.dlna.org/home eceasst scenario 2. alice plans to leave for holidays with bob in a few days. before leaving, alice contacts her neighbors asking them if they could take care of the house while she is abroad. neighbors can accept her proposal by following her on twitter in order to be notified of particular events related to the house. whenever a movement is detected in the house while alice is away, the digihome platform will post a new message on alice’s twitter account to notify her friends that something is happening in the house. furthermore, to ensure the messages reception, the system filters the posts on the alice’s account and displays them on neighbors’ upnp tv. depending on the content of the message, alice’s neighbors can walk to the house and physically check the status of the house. the digihome platform detects the neighbor’s smartphone, disables the house monitoring, and logs the presence of the neighbor by posting another message on twitter. challenges. the scenarios we describe here exemplify situations where the digihome platform has to integrate different technologies (upnp, rss, twitter) to implement advanced situations combining the house equipments (media server, frames, set-top box), smartphones, and the internet. in the remaining of this paper, we introduce a solution that aims to deal with this technology integration. in particular, we build our solution with sca by defining two features: pervasive bindings and social bindings, which we use to implement scenarios 1 and 2, respectively. 3 background on service-oriented architectures in this section, we present the foundation of our proposal—i.e., the sca (cf. subsection 3.1) component model. we also introduce the frascati platform (cf. subsection 3.2), which we use to implement our approach. 3.1 the service component architecture (sca) sca is a set of specifications for building distributed application based on soa and componentbased software engineering (cbse) principles [ope07]. in sca, the basic construction blocks are the software components, which have services (or provided interfaces), references (or required interfaces) and expose properties. the references and services are connected by means of wires. sca specifies a hierarchical component model. this means that components can be implemented either by primitive language entities or by subcomponents. in the latter case the components are called composites. figure 1, from the sca specifications [ope07], provides a graphical notation for these concepts as well as a xml-based assembly language to configure and assemble components. sca is designed to be independent from programming languages, interface definition languages (idl), communication protocols and non-functional properties. in this way, an scabased application can be built, for example, using components in java, php, and cobol. furthermore, several idls are supported, such as wsdl and java interfaces. in order to support interaction via different communication protocols, sca provides the concept of binding. for sca references, bindings describe the access mechanism used to call a service. in the case of services, the bindings describe the access mechanism that clients have to use to call the service. 3 / 13 volume 28 (2010) supporting pervasive and social communications with frascati application view controller legend: composite servicereference wire component property landscape application.composite figure 1: sca graphical notation and assembly language. 3.2 the frascati platform the frascati platform [smf+09] allows the development and execution of sca-based applications. the platform itself is built as an sca application—i.e., its different subsystems are implemented as sca components. frascati extends sca with reflective capabilities at the application level as well as at the platform level. by default, the frascati platform is bundled with various plugins for the components interface (java, wsdl), property (java, xsd), component (java 5, java beans, scala, spring, osgi, fractal, bpel, script), and binding (java rmi, soap, http, json-rpc, sca, osgi, jna). furthermore, the platform has a run-time level that instantiates sca assemblies and components. this run-time is not hard-coded into the architecture description. rather, the run-time level defines a flexible configuration process, which is inspired by the extender and whiteboard [osg04] design patterns of osgi. in particular, both the core platform and various plugins are bundles, which are dynamically composed. 4 scenario 1: bindings for pervasive communications in pervasive environments, the discovery capabilities enable the use of the available services in a transparent way and provide support for mobility. therefore, we bring this functionality into sca by defining pervasive bindings. in this section, we report on the integration of these bindings in the frascati platform, using the upnp technology (cf. subsection 4.1 and subsection 4.2). we also introduce our solution for the automation of service discovery in sca-based applications (cf. subsection 4.3). this integration is validated by the implementation of the first scenario (cf. subsection 4.4). 4.1 upnp foundations for pervasive integration as an internet-based technology, universal plug and play (upnp) is built upon tcp/ip, udp, http, xml, and soap. the recent development of connected devices like set-top boxes (stb) or smartphones has encouraged the integration of this technology as an industry standard for interacting with these smart appliances. therefore, we believe that upnp represents a key technology in pervasive environments for enabling the integration of physical devices with it sysproc. campus 2010 4 / 13 eceasst tems. typically, this integration requires considering four aspects of upnp: service discovery, description, interaction, and profiles. service discovery. the most important feature of upnp technology for pervasive usage is the discovery capacity. using the simple service discovery protocol (ssdp) [upn08], client and server (called, in upnp terminology, control point [cp] and device, respectively) can find themselves without any configuration. in order to establish a connection, a cp sends a lookup request (using http over udp), which includes a device type, a particular service or a specific device. devices can send a response that contains the url of their description. in a similar way, when a device joins the network, it sends an advertisement announcing its presence. finally, the devices multicast bye-bye notifications indicating that they leave the network and therefore the provided services are no more available. service description. like any service-oriented application, upnp devices have to describe their capabilities. to do that, upnp devices and cps are described by means of xml documents. these documents are structured following a collection of schema documents, which are also provided by the standard. for example, the dlna imposes a particular schema for the description of entertainment devices that are able to share their content with each other across a home network. service interaction. to support the remote invocation of services, upnp exploits simple object access protocol (soap) as a privileged communication protocol. thus, the method invocations are described with xml and sent via soap over http. service profiles. additionally, upnp provides a set of profiles representing manufacturer contracts and ensuring interoperability between heterogeneous hardware. actually, the most widespread profiles are the audio video set (av) profiles, which enable media-oriented home networks. however, the use of web technologies, such as soap and xml, makes upnp inappropriate for real-time operations including multimedia streaming or any other kind of operation that requires large amount of data transfer. therefore, the av profiles face this issue by describing upnp devices in terms of their remote control and streaming capabilities. the remote control functionality can be considered as a simple service, while the streaming description allows devices to specify the stream properties, including transfer protocol (e.g., rtsp/rtp, http) and data format. thus, the av specifications split the connection negotiation in two steps: communication description and communication establishment. 4.2 implementing pervasive services using upnp and sca as mentioned previously, sca introduces bindings as an open mechanism supporting communications between components. bindings can be implemented in order to fulfill the requirements of business applications. in pervasive environments, the upnp discovery capabilities—enabling spontaneous communications at runtime—can be considered for dealing with services mobility. the comprehensive upnp communication stack allows the advertisement, discovery, and access of services provided by java applications. therefore, we introduce in sca the element specifying that a service (resp. reference) is advertised (resp. dis5 / 13 volume 28 (2010) supporting pervasive and social communications with frascati covered) via the upnp protocol. thus, upnp can be used as an sca binding for autonomous communications applying soap as an underlying mechanism for service invocations. on the other hand, benefiting from the upnp modularity in terms of the spontaneous communication process, we can discover services with upnp and then access them with different communication protocols (not only soap), which are described by the others bindings (htpp, wsdl, etc.) associated with the sca services. this means that the service descriptions and access mechanisms are only advertised and discovered with upnp. then, using this information, the communications are achieved across a suitable protocol, which may be selected depending on qos attributes. thus, we restrict the usage of upnp to the discovery part of the spontaneous communication process. 4.3 binjiu: facilitating upnp integration into frascati in this section we describe binjiu, our solution to provide the missing elements for implementing upnp bindings in frascati. in particular, this solution provides functionality for upnp interface compilation and descriptor generation. binjiu also enables the sca services advertisement as upnp devices and the casting of sca references to upnp control points. below we describe these functionalities as well as the integration within frascati as a dedicated binding. upnp interface compilation. in order to integrate a standardized upnp profile into the frascati platform, we have to implement an sca component, which is compliant with the profile description. to do that, binjiu provides a upnp2java command that parses upnp descriptions, extract upnp services, and generates the associated java interfaces. thus, this upnp2java command makes easier the integration of existing profiles, such as the content directory upnp profile2, described below: public interface contentdirectory { public int getsystemupdateid(); public searchresponse search(string containerid, string searchcriteria, string filter, int startingindex, int requestedcount, string sortcriteria); public string getsearchcapabilities(); ...} upnp descriptor generation. binjiu supports also the generation of upnp descriptions from java interfaces, according to the upnp schemas. in this way, we can create devices automatically exposing the upnp descriptions of the underlying java interfaces. even if these xml descriptions are not standardized, it is a first step for autonomic bindings of java native interfaces in distributed software. upnp device integration. the advertisement of an sca service via upnp technology requires to consider the different aspects discussed in subsection 4.1. in this way, binjiu dynamically encapsulates a java interface and exposes it as a upnp service, included into a device. this skeleton is able to follow the ssdp advertisement process and answer to upnp connection 2 upnp content directory profile: http://www.upnp.org/standardizeddcps/documents/contentdirectory1.0.pdf proc. campus 2010 6 / 13 http://www.upnp.org/standardizeddcps/documents/contentdirectory1.0.pdf eceasst requests from control points. the current binjiu implementation is based on the cyberlink3 upnp stack for java. upnp control point integration. in the client side, binjiu creates a proxy from a java interface, which dynamically converts method calls to actions towards a upnp device, depending on a device type or name. this stub is also implemented using cyberlink for java. frascati integration. binjiu has been built as an autonomous application to make easier the integration of the upnp technologies in java-based applications. however, we need to integrate the binjiu functionalities into the frascati platform in order to enable the use of pervasive bindings (cf. subsection 4.2) in sca applications. to do that, we take advantage of the frascati extensibility properties. in particular, frascati already provides various sca bindings (e.g., rmi, rest, and webservices), which means that there is an extension mechanism for integration of new kinds of bindings. thus, we can add our support for pervasive bindings without impacting the platform functionality. 4.4 validation the first scenario, introduced in section 2, illustrates how alice’s preferences influence the frames displaying pictures at home. in this section, we describe how frascati and pervasive bindings can be used to realize this scenario. alice’s home is equipped with different entertainment devices. in order to keep the data separated from the different computing resources, a nas is available as a standalone device. this nas broadcasts alice’s multimedia contents over the network, as a upnp audiovideo profile (dlna certified) device. furthermore, we find a set-top box (stb) as a central element of the environment, which is always available and is able to run frascati applications. the two digital frames (upnp av and rss based) are available in the environment and an android smartphone is connected to the home network using a wireless connection. figure 2 depicts the different entities in alice’s home and how they are associated with the digihome system. stbalice smartphone client application gui network area storage upnp frame alice-digihome-system av control point constraint manager av device rssbased frame legend: p wire (remote) p reference with pb service with pb pb pervasive binding 1p pp 2 3 4 p p p pp p figure 2: using frascati with upnp bindings. to access the pictures stored in the nas, we need to generate a java interface compliant with upnp av profile (cf. figure 2:1) using the upnp2java command provided by binjiu. then, we create an sca implementation of the av profile with cp capabilities (the av control point component) for communicating with the nas over upnp. 3 cyberlink for java: http://cgupnpjava.sourceforge.net 7 / 13 volume 28 (2010) http://cgupnpjava.sourceforge.net supporting pervasive and social communications with frascati in order to filter nas content according to alice’s preferences, we define a simple interface, which provides methods for defining constraints on the picture library (cf. figure 2:2): public interface iconstraintmanager { public void addkeywordsconstraint (string[] keywords); public void adddaterangeconstraint (date date1, date date2); public void addfolderconstraint (string foldername);} the constraint manager component provides this interface. this component is able to filter nas responses and is advertised over the network as a upnp device thanks to our upnp binding (cf. figure 2:3). by means of a simple control point generated by binjiu, the alice’s smartphone can interact with this service. finally, the stb exposes the filtered results as a upnp av device and a rss publisher (cf. figure 2:4), that are used by the digital frames for displaying the content. 5 scenario 2: bindings for social collaborations the micro-blogging services enable the sharing of information in real-time by reaching a lot of friends in just a few seconds. one of the main advantages of these services is the short and simple nature of the posted messages. furthermore, there are no restrictions on the subject associated with these messages. in general, this kind of informal communications was conceived for broadcasting simple events in the daily life, such as what people are doing, thinking, and experiencing [zr09, mcf07]. however, nowadays the micro-blogging services are also used for collaborative work in organizations [zr09], publicity purposes, and even for broadcasting real-time news updates for recent crisis situations. therefore, the simplicity and flexibility as well as the real-time notification property of micro-blogs make them a suitable option to enable event-based communication between the participants of the digihome platform. in the rest of this section, we present how we bring micro-blogging-based communications into the sca component model by defining social bindings (cf. subsection 5.1) and the architecture of our solution (cf. subsection 5.2). we finish with the validation of our approach by analyzing the performance overhead of our solution in our smart home scenario (cf. subsection 5.3). 5.1 enabling social collaborations using twitter and sca following the same idea of pervasive bindings (cf. section 4), we enable social communications in pervasive environments by introducing a new kind of binding in sca: the social bindings. these bindings allow the notification of situations identified by the system that may require human intervention, like the detection of an intruder in our smart home scenario (cf. section 2). to do that, social bindings benefit from a simple but widely used micro-blog service: twitter. furthermore of the advantages of any micro-blogging service, the twitter messages (so called tweets) can be posted using different formats (e.g., json, xml, rss and atom) and a simple restful api [mak09]. figure 3 depicts an example of social binding for the twitter micro-blogging service. in the service side (right side of figure 3), we define a service with a twitter binding that indicates that the information provided by the service can be retrieved from a particular twitter account. proc. campus 2010 8 / 13 eceasst service (server-side) reference (client-side) stbalice legend: alice-digihome-system house-movementmonitoring ... stbneighbor neighbor-digihome-system houses-monitoring ... e e e service with sb reference with sbe e sb social binding twitter server e figure 3: example of a social binding for the smart home scenario we use the user and password attributes to indicate the twitter user providing the information. as it can be seen, unlike the typical sca bindings, the sca services defining twitter bindings do not require to define specific interfaces. instead, the services specify the representations and types of the events that can be retrieved from the twitter accounts. this information will be used for marking the tweets with the event type that contains using twitter tags. this metadata is useful for filtering the events exchanged on the twitter account. in the reference side (left side in figure 3), we use the element to indicate that we want to retrieve events from twitter. in the references, the element specifies the event representations. thus, by encapsulating the event notifications as sca social bindings, we support asynchronous event notification as well as interaction with people involved in the smart home. 5.2 architecture of the containers supporting social bindings we have integrated these social bindings into the frascati platform. to do this, we applied the containercomposite architectural pattern promoted by the hulotte platform [lsds10]. this means that we define a container composite that hosts components and implements event notification as tweets. in this way, the social communications are integrated in a transparent way and the event processing logic is not impacted by the technical specificities of twitter. stbalice alice-digihome-system container stbneighbor neighbor-digihome-system container legend: container composite client interface server interface twitter server alice-digihomesystem event notification message handler (post) content type marshaller content type marshaller content type marshaller publish post marshal client notifiable events handler (post) unmarshal twitter user post e twitter followers manager post post neighbordigihome-system submit content type marshaller content type marshaller content type marshaller cliente figure 4: social bindings service and reference architectures 9 / 13 volume 28 (2010) supporting pervasive and social communications with frascati figure 4 depicts the containers implementing the twitter bindings for the neighbor-digihomesystem and alice-digihome-system composites (cf. figure 3). in this architecture, we benefit from the twitter restful api by building the social bindings upon rest bindings [rrsc10]. therefore, in the server side (upper part of figure 4), we observe that the event notification message handler component serializes events via the content type marshaler . the event notification message handler posts the events using the client component, which encapsulates the communication mechanism (i.e., http in the case of twitter). the twitter user component orchestrates the tweets publication process by providing the required information for the twitter requests, such as user name, password, and event types. on the other hand, the client side (low part of figure 4) uses a twitter followers manager component to periodically retrieve the recent tweets on the followed twitter accounts. this component filters the tweets by using the metadata that includes event type. in this side, we also reuse the rest bindings functionality for communication (via the client component) and message processing (via the notifiable events handler and content type marshaler components). thus, the proposed architecture for these components modularizes the twitter functionalities derived from rest principles [fie00], which includes the addressing, access, and message representations. this modularity fosters the component reuse and the flexibility to choose different component implementations. 5.3 validation implementation details. we have integrated our social bindings into the frascati platform (version 1.2). these bindings are based on the comanche web server4. both, frascati and comanche, are based on the fractal component model and use the julia5 implementation of the fractal runtime environment [bcl+06]. performance results. to evaluate the social bindings, we implemented the event exchanges described in the scenario 2 (cf. section 2) using the twitter bindings. table 1 summarizes the results we obtained when executing several physical configurations for the scenario 2 using http and twitter as communication mechanisms for events exchange. event providers configuration event provider b) 1 external provider macbook pro event representation object (ms) 221 228n/a 281.7 293.8 300.8 a) 1 local provider 965.2 971.44 948.2 951.55 json (ms) xml (ms) interaction http twitter json (ms) xml (ms) 209.8 table 1: performances of twitter bindings in terms of latency as it can be seen, the indirection introduced by the micro-blogging service increments the event exchange by approximately 350% compared to the configuration a for the two mecha4 comanche web server: http://fractal.ow2.org/tutorials/comanche.html 5 julia: http://fractal.ow2.org/julia proc. campus 2010 10 / 13 http://fractal.ow2.org/tutorials/comanche.html http://fractal.ow2.org/julia eceasst nisms with the json representation. however, despite of this overhead, the simplicity of this interaction mechanism makes it still a suitable alternative to share events in an asynchronous way. furthermore, the event notification rests less than a seconds, which is a reasonable overhead to communicate relevant situations in the context of smart homes. 6 related work in this section we present two kinds of related work: proposals that benefit from micro-blogging services and approaches dealing with discovery in pervasive environments. pervasive communications. in the literature, we find several middleware solutions, such as indiss [bi05] (interoperable discovery system for network services) and remmoc [gbs05] (reflective middleware for mobile computing), that provide interoperability for discovery protocols. the problem with some of these solutions is that they are not flexible enough for using different interaction mechanisms when the services are discovered. furthermore, they have been designed for working on devices with restricted capabilities, thus limiting the range of applications that can use them. although in our solution we do not support discovery protocol interoperability, by benefiting from frascati platform extensibility, we can easily add new pervasive bindings when required. furthermore, by integrating binjiu as sca pervasive bindings, we promote its usage in different kinds of applications, not only the mobile ones. regarding approaches that exploit specifically upnp, we find some solutions [ft09, mss+09] in domestic environments (i.e., automated homes) that aim to provide control on home appliances. in particular, this kind of approaches uses upnp-based architectures to enable the simple and transparent access of different resources present in the environment. some improvements are included in upnp, such as service configuration persistence and enhanced management options. however, these solutions are difficult to apply in the development of new applications requiring discovery capabilities, while the combination of binjiu and sca make easier the incorporation of the upnp technology when required. social collaborations. to the best of our knowledge, there is no proposal dealing with event propagation via micro-blogging services in pervasive environments. however, we benefit from the ideas proposed in some of these approaches in order to improve our solution. for example, twitterstand [sst+09] and tweetsieve [ggb+09] are systems able to extract relevant news from a noisy medium, such as twitter. thanks to the modular architecture of social bindings, we easily incorporate these techniques to support a smarter event selection. furthermore, these techniques can also be used as a stabilization mechanism to avoid the notification of not relevant events for the system and participants. in [mmc09], the authors propose a social networking middleware that combines social and physical proximity relationships between mobile users in order to suggest them potential people with whom they could perform activities of common interest. the mechanisms proposed in this work for determining the social and physical proximity can be also integrated in the social bindings in order to infer events that could be relevant for the system and home inhabitants. 11 / 13 volume 28 (2010) supporting pervasive and social communications with frascati 7 conclusion in this paper, we reported on the implementation of new bindings for an sca-based distributed system in a home pervasive environment. in particular, we demonstrated their integration into the frascati platform, an open source implementation of the service component architecture (sca) standard [smf+09]. relying on well-accepted technologies, these new bindings increase capabilities of sca in two complementary ways. using upnp discovery and communication capabilities, pervasive bindings supply spontaneous communications between sca components or legacy upnp devices. on the other hand, social bindings use the twitter micro-blogging service in order to disseminate applications events to end users. two scenarios illustrating the integration of these capabilities into the frascati platform have been presented to motivate and validate our proposals. future work includes to add support for new pervasive (e.g., slp [gpvd99] and avahi6) and social bindings (e.g., facebook and ostatus7 ). we will take advantage of frascati runtime reconfiguration capabilities to dynamically integrate these new bindings in sca applications. regarding upnp, we plan to adapt the upnp bindings for making them compliant with the android platform. moreover, we will integrate new upnp certified profile implementations, in order to easily interact with home appliances. on the other hand, the identity management in a home environment represents an interesting issue. we already have to deal with preferences, private information (like twitter login), and therefore, we need to provide a mechanism to ensure identity in pervasive environments. bibliography [bcl+06] e. bruneton, t. coupaye, m. leclercq, v. quéma, j.-b. stefani. the fractal component model and its support in java. software: practice and experience – special issue on experiences with auto-adaptive and reconfigurable systems 36(11-12):1257–1284, aug. 2006. john wiley & sons. [bi05] y.-d. bromberg, v. issarny. indiss: interoperable discovery system for networked services. in middleware ’05: proceedings of the acm/ifip/usenix 2005 international conference on middleware. pp. 164–183. springer-verlag new york, inc., new york, ny, usa, 2005. [fie00] r. t. fielding. architectural styles and the design of network-based software architectures. phd thesis, university of california, irvine, 2000. [ft09] g. b. de freitas, c. a. c. teixeira. ubiquitous services in home networks offered through digital tv. in sac ’09: proceedings of the 2009 acm symposium on applied computing. pp. 1834–1838. acm, new york, ny, usa, 2009. [gbs05] p. grace, g. s. blair, s. samuel. a reflective framework for discovery and interaction in heterogeneous mobile environments. sigmobile mob. comput. commun. rev. 9(1):2–14, 2005. [ggb+09] m. grinev, m. grineva, a. boldakov, l. novak, a. syssoev, d. lizorkin. sifting microblogging stream for events of user interest. in sigir ’09: proceedings of the 32nd international acm sigir conference on research and development in information retrieval. pp. 837–837. acm, new york, ny, usa, 2009. 6 avahi, a zeroconf implementation: http://avahi.org 7 ostatus standard: http://ostatus.org proc. campus 2010 12 / 13 http://avahi.org http://ostatus.org eceasst [gpvd99] e. guttman, c. perkins, j. veizades, m. day. service location protocol, version 2. rfc 2608 (proposed standard). http://tools.ietf.org/html/rfc2608, june 1999. [lsds10] f. loiret, l. seinturier, l. duchien, d. servat. a three-tier approach for composition of real-time embedded software stacks. in 13th international sigsoft symposium on component-based software engineering (cbse). lncs. springer, june 2010. [mak09] k. makice. twitter api: up and running learn how to build applications with the twitter api. o’reilly media, inc., 2009. [mcf07] p. mcfedries. technically speaking: all a-twitter. 44:84–84, 2007. [mmc09] s. b. mokhtar, l. mcnamara, l. capra. a middleware service for pervasive social networking. in m-pac ’09: proceedings of the international workshop on middleware for pervasive mobile and embedded computing. pp. 1–6. acm, new york, ny, usa, 2009. [mss+09] l. f. maia, d. f. s. santos, r. s. souza, a. perkusich, h. almeida. seamless access of home theater personal computers for mobile devices. in sac ’09: proceedings of the 2009 acm symposium on applied computing. pp. 167–171. acm, new york, ny, usa, 2009. [ope07] open soa. service component architecture specifications. nov. 2007. [osg04] osgi alliance. listeners considered harmful: the whiteboard pattern. aug. 2004. [rht+10] d. romero, g. hermosillo, a. taherkordi, r. nzekwa, r. rouvoy, f. eliassen. restful integration of heterogeneous devices in pervasive environments. in proceedings of the 10th ifip international conference on distributed applications and interoperable systems (dais’10). lncs 6115, pp. 1–14. springer, june 2010. [rrsc10] d. romero, r. rouvoy, l. seinturier, p. carton. service discovery in ubiquitous feedback control loops. in proceedings of the 10th ifip international conference on distributed applications and interoperable systems (dais’10). lncs 6115, pp. 113–126. springer, june 2010. [smf+09] l. seinturier, p. merle, d. fournier, n. dolet, v. schiavoni, j.-b. stefani. reconfigurable sca applications with the frascati platform. in proceedings of the ieee international conference on services computing (scc’09). pp. 268–275. ieee computer society, sept. 2009. [sst+09] j. sankaranarayanan, h. samet, b. e. teitler, m. d. lieberman, j. sperling. twitterstand: news in tweets. in gis ’09: proceedings of the 17th acm sigspatial international conference on advances in geographic information systems. pp. 42–51. acm, new york, ny, usa, 2009. [upn08] upnp forum. upnp device architecture 1.1. http://www.upnp.org/resources/documents.asp, oct. 2008. [zig10] zigbee alliance. zigbee technical documents. http://www.zigbee.org, 2010. [zr09] d. zhao, m. b. rosson. how and why people twitter: the role that micro-blogging plays in informal communication at work. in group ’09: proceedings of the acm 2009 international conference on supporting group work. pp. 243–252. acm, new york, ny, usa, 2009. 13 / 13 volume 28 (2010) http://tools.ietf.org/html/rfc2608 http://www.upnp.org/resources/documents.asp http://www.zigbee.org introduction motivating scenario: the digihome platform background on service-oriented architectures the service component architecture (sca) the frascati platform scenario 1: bindings for pervasive communications upnp foundations for pervasive integration implementing pervasive services using upnp and sca binjiu: facilitating upnp integration into frascati validation scenario 2: bindings for social collaborations enabling social collaborations using twitter and sca architecture of the containers supporting social bindings validation related work conclusion model-based engineering of supervisory controllers using cif electronic communications of the easst volume 21 (2009) proceedings of the 3rd international workshop on multi-paradigm modeling (mpm 2009) model-based engineering of supervisory controllers using cif ramon r.h. schiffelers, rolf j.m. theunissen, dirk a. van beek, and jacobus e. rooda 10 pages guest editors: t. levendovszky, l. lengyel, g. karsai, c. hardebolle managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst model-based engineering of supervisory controllers using cif ramon r.h. schiffelers, rolf j.m. theunissen, dirk a. van beek, and jacobus e. rooda ∗ (r.r.h.schiffelers, r.j.m.theunissen, d.a.v.beek, j.e.rooda)@tue.nl department of mechanical engineering eindhoven university of technology, p.o.box 513, 5600 mb eindhoven, the netherlands abstract: in the model-based engineering (mbe) paradigm, models are the core elements in the design process of a system from its requirements to the actual implementation of the system. by means of supervisory control theory (sct), supervisory controllers (supervisors) can be synthesized instead of designing them manually. in this paper, a framework based on the compositional interchange format for hybrid systems (cif) has been developed that integrates the mbe and the sct paradigms. to illustrate the framework, an industrial-size case study has been performed: synthesis of a supervisory controller for the patient support system of an mri scanner. in this case study, we address 1) modelling of the components and the control requirements; 2) synthesis of the supervisor; 3) simulation of the synthesized supervisor and a hybrid model of the plant; and 4) real-time, simulation based control of the supervisor and the actual patient support system of the mri scanner. keywords: model-based engineering, supervisory control synthesis, automata, interchange formats 1 introduction complex manufacturing machines consist of physical components (hardware) and control systems. the physical components, typically sensors, actuators and main structure, provide the means of the machine. the interactions between the physical components result in the so-called uncontrolled behavior of the machine. the control systems interact with the sensors and actuators to employ the means of the machine, which results in the controlled behavior of the machine. the controlled behavior should be such that the machine fulfills its functions, i.e. meets its pre-defined requirements. the control systems can be divided into five functional subsystems, see [pfc89]: 1) regulative control (also known as direct or feedback control) that assures that the actuators reach the desired position in the desired way. 2) errorhandling control (also known as fault detection and isolation or exception handling) that detects erroneous behavior, determines the cause, and acts to recover the machine control system. 3) supervisory control (also known as logic control) that coordinates the control of the individual machine components. this includes planning, scheduling and dispatching functions. 4) the data processing subsystem that stores and manipulates gathered data. 5) the user interface subsystem that allows the user to interact with the machine control system. in this paper, we focus on the development process of supervisory controllers (supervisors). the current practice of developing supervisory controllers is to code them manually, based on (possibly informal) control requirements. creating and changing requirements, a design and/or an implementation can be time consuming and error-prone. an other possibility is to use the model-based engineering (mbe) paradigm, see [ogr00, bra08], in order to design the supervisory controller. in this case, (possibly formal) executable models for the supervisory controller are developed (by hand). using analysis ∗ this work was partially done as part of the darwin project under the responsibility of the embedded systems institute, partially supported by the netherlands ministry of economic affairs under the bsik program, as part of the itea project twins 05004, and as part of the collaborative project multiform, contract number fp7-ict-224249 1 / 10 volume 21 (2009) mailto:(r.r.h.schiffelers, r.j.m.theunissen, d.a.v.beek, j.e.rooda)@tue.nl model-based engineering of supervisory controllers using cif techniques such as simulation and verification, the system controlled by the supervisor can be analyzed. however, the development of a model of the supervisory controller is a highly non-trivial task. an alternative approach is to synthesize the supervisory controller automatically using supervisory control theory, see [won07, cl07]. first, the uncontrolled behavior of the machine to control is modeled precisely (by hand). secondly, the requirements on the function of the machine (with respect to supervisory control) are modeled in detail (by hand). this includes safety and functional requirements. out of these formal requirements and the model of the uncontrolled system, the supervisory controller can be synthesized automatically. this supervisory controller is proven correct by construction. this means that the controlled system behaves according to the prescribed requirements on the function of the machine and that the system is deadlock and lifelock free. although supervisory control theory ensures that the controller is proven correct by construction, it remains a non-trivial task (but easier than the development of the supervisory controller itself) to define the correct plant and requirement models, and errors or undesired behavior might still exist in the plant models and/or requirement models. therefore, in this paper, we describe a framework developed for supervisory controller design. it combines the model-based engineering paradigm, that enables analysis by means of simulation and verification, together with supervisory control theory, that provides automatic synthesis of supervisors. for example, the plant models that are developed for the supervisor synthesis, can be reused for simulation of these plant models controlled by the synthesized supervisor. simulation results can be used to validate whether the controlled plant behaves as intended. at a later stage in the design process, more detailed, e.g. timed or hybrid, plant models can be developed. simulation of the more detailed plant models controlled by the synthesized model of the supervisor, enables a more detailed analysis. early integration and testing can be performed by means of coupling models and realizations of different components via an infrastructure. finally, the realization of all plant and controller components are integrated into one system. to support the design process of industrial-size supervisory controllers, a (software) tool framework, based on the common interchange formalism for hybrid systems, see [brsr07, brrs07], has been developed. to illustrate this tool framework, we describe an industrial-size case study that has been performed: synthesis of a supervisory controller for the patient support system of an mri scanner. the outline of this paper is as follows. section 2 introduces the model-based engineering (mbe) paradigm and supervisory control theory (sct). the developed framework and the accompanying tools are described in section 3. the industrial-size case study is described in section 4. section 5 concludes the paper with conclusions and recommendations of future work. 2 mbe and sct this section provides the required background on model-based engineering and supervisory control theory. 2.1 model-based engineering the model-based engineering (mbe) system development process is depicted in figure 11. it starts with defining system requirements r and creating a system design d. based on system design the system is divided into n components. for each component i ∈ {1, . . . , n} requirements ri are defined and its design di is developed. based on the design of a component, models mi are developed, each with their own purpose and required level of detail. after that, the component implemented resulting in a realization zi. the models of the components can be used to perform further functional and performance analysis 1 in the figure, the following conventions are used: icon denotes documents, denotes models, and denotes realizations. proc. mpm 2009 2 / 10 eceasst r d r1 d1 m1 z1 rn dn mn zn infrastructure define define define design design design model model realize realize integrate integrate model simulation and verification integrate integrate hardware-in-the-loop simulation and testing integrate integrate final implementation testing figure 1: model-based engineering. by means of simulation and/or verification techniques such as model checking. early integration and testing can be performed by means of coupling models and realizations of different components via an infrastructure. at the end, the realization of all components are integrated into one system. to confirm that the resulting system fulfills its requirements, the implemented components and the system as a whole are tested. 2.2 supervisory control theory supervisory control theory (sct) has been developed by w.m. wonham and p.j. ramadge, and their co-workers, in the 1980’s, see [won07, cl07]. it allows to synthesize the models of the supervisors, such that the correctness of these models is predetermined. the behavior of the system under control (further on, uncontrolled system) is considered unsatisfactory and has to be restricted by the supervisor to fulfill certain requirements. first, an uncontrolled system and its requirements are formally specified in terms of automata. then, from these models, the supervisor is derived. the method guarantees that the system consisting of the derived supervisor and the uncontrolled subsystem fulfills the requirements. the theory has been implemented in a software package called tct, see [won07]. for large systems, the method suffers a state space explosion problem. to overcome this problem, research has been and is conducted to reduce complexity by using methods such as modular, decentralized and hierarchical control, see [cl07] and references therein. 3 integrating mbe and sct in this section, we present the framework developed for supervisory controller design. it combines the model-based engineering paradigm, that enables analysis by means of simulation and verification, together with supervisory control theory, that provides automatic synthesis of supervisors. furthermore, we present the developed tool framework that supports the design process. 3.1 integrating mbe and sct figure 2 shows the framework developed for supervisory controller design. from requirements rs/p 2 of the controlled system, a design ds/p of the system is made and decomposed into a plant and a supervisory controller. requirements rs of the supervisor are formally modeled resulting in model mrs of the control requirements . from plant requirements rp, a design dp and one or more models mp can be made, each 2 notation s/p denotes plant p under supervision of supervisor s. 3 / 10 volume 21 (2009) model-based engineering of supervisory controllers using cif rs/p ds/p rs mrs ms zs rp dp mp zp infrastructure define define define design model design synthesize model realize realize integrate integrate integrate integrate figure 2: supervisory controller design framework. with a different level of detail. for instance, a discrete-event model of the plant can be made that serves as input for the supervisory controller synthesis, while a more detailed (possibly hybrid) model can be developed to study the dynamic behavior of the plant by means of simulation. in this way, simulation of the hybrid plant model and the model of the supervisor can reveal invalid assumptions in the models that are used for the supervisor synthesis. using sct, that takes as input the discrete-event model of the plant and the model of the control requirements for the supervisor, the model of supervisor ms is synthesized. using this model and the model(s) of the plant, the analysis techniques provided by the mbe paradigm can be used. by means of, for instance, code-generation, a realization of the supervisor can be made. 3.2 tool framework in this section we describe the tool-framework that is developed to support the development of supervisors using the integrated mbe and sct paradigms. the tool-framework uses the common interchange format for hybrid systems (cif) to connect the controller synthesis tools and the analysis tools such as simulators, and modelcheckers. 3.2.1 the cif language the compositional interchange format (cif) for general hybrid systems, see [brsr07, brrs07, brrs08], was recently developed within the european network of excellence hycon, see [hyc05]. its operational semantics, defined formally in a sos style [plo04], defines the mathematical meaning of a hybrid model and is independent of implementation issues and limitations, such as e.g. circular dependencies and algebraic loops. in [brsr07], the cif has been related to previous work on interchange formats for hybrid systems, such as [mob02], and [pcps06]. the cif has been developed with two major purposes in mind 1) to provide a generic modeling formalism (and appropriate tools) for a wide range of general hybrid systems, and 2) to establish inter-operability of a wide range of tools by means of model transformations. the cif serves as the basis of the european research project multiform, see [mul08]. the main objective of this project is to develop interoperability of tools and methods based on different modeling formalisms to provide integrated coherent tool support for the design of large complex controlled systems. within multiform, algorithms and tools for the translation to/from the cif will be defined for a large variety of modeling languages, including chi, gproms, matlab/simulink, modelica, muscod-ii, phaver, and uppaal. in [ssb+09], the concepts of the cif are illustrated by means of a hybrid model of a supermarket refrigeration system that exhibits both, nonlinear dae dynamics as well as significant discrete dynamics, and serves as a challenging case study for hybrid control techniques in several european research projects. more information about cif and cif tools allowing, e.g., simulation and visualization, can be found in [sys08]. proc. mpm 2009 4 / 10 eceasst 3.2.2 tool framework figure 3 shows the developed tool framework to support the supervisory controller design. documents, models and realizations are graphically depicted according to the convention of figure 1. (software) tools are represented as filled, rounded rectangles. hybrid simulation results real-time control de simulation results real-time simulation results mergecif mergecif cif2py simulator simulator rt simulator rt controller tct ads2cif ads2cif p pde .ads s.cif s.py pde .cif s/pde .cif s/phy .cif s.adsrs .adsrs phy .cif rs/p ds/p rp figure 3: tool framework based on cif. in the tool framework, rs/p and ds/p represent the requirements and the design of plant p under supervision of supervisor s, and rp and rs denote the requirement documents of the plant and supervisor, respectively. the models used in this figures are related to the models from figure 2 as follows: rs.ads ∈ mrs ; s.ads, s.cif ∈ ms; pde.ads, pde.cif, phy.cif ∈ mp; and s.py ∈ zs 3. the control requirements rs are formally modeled by means of automata, resulting in rs.ads. model pde.ads describes the uncontrolled discrete-event behavior of the plant. the tct tool takes as input (discrete-event) model of the uncontrolled system pde.ads and model of the control requirements rs.ads. as output, we obtain model of the supervisor s.ads. using the ads2cif translator, the models of the plant and the supervisor can be translated to equivalent cif models (pde.cif, and s.cif, respectively). a discrete-event model of the plant controlled by the supervisor s/pde.cif is obtained by combining these individual component models using the mergecif tool. at this moment, the translations are implemented using the general-purpose programming language python. recently, we have defined the conceptual model (domain model or meta model) of the cif language by means of ecore class diagrams [sbpm09]. these class diagrams (see [sys08]) will be used for the model-to-model transformations that will be developed in near future. using the cif simulator (simulator), the s/pde.cif model can be simulated to analyse its behavior with respect to the control requirements. after that, the discrete-event model of the plant can be replaced by the hybrid cif model of the plant phy.cif. the next step is to replace the hybrid cif model of the plant by actual hardware of the plant p. the real-time simulator (rt simulator) connects the hardware of the plant and the cif model of the supervisor to analyse the response of the plant hardware as well as the simulation output. after that, using the cif2py compiler, the cif model of the supervisor can be compiled into python code s.py that can be executed on real-time control platform rt control that is connected to the actual hardware of the plant. 3 the (file) extension ‘.ads’ refers to the input language for the controller synthesis software package tct, extention ‘.cif’ refers to the cif language, and extention ‘.py’ refers to the python language. 5 / 10 volume 21 (2009) model-based engineering of supervisory controllers using cif 4 case study: patient support system an mri scanner, see figure 4, is used in medial diagnosis to render pictures of the inside of a patient non-invasively. to position a patient in an mri scanner, a patient support system, consisting of a patient table (see figure 5), a user interface and a light-visor is used. user interface light visor bore patient table figure 4: mri scanner position encoder (on/off) horizontal motor (in/out/stopped) clutch (on/off) tabletop sensor (on/off) max out sensor (on/off) ttr button (on/off) vertical motor (up/down/stopped) max up sensor (on/off) max down sensor (on/off) emergency (on/off) 2× timer (on/off) figure 5: patient table the patient support system can be divided into the following components: vertical axis, horizontal axis and user interface. the vertical axis consists of a lift with appropriate motor drive and end-sensors. the horizontal axis contains a removable tabletop which can be moved in and out of the bore, either by hand or by means of a motor drive depending on the state of the clutch. it contains sensors to detect the presence of the tabletop, and the position of the tabletop. furthermore, the system is equipped with hardware a safety system (emergency stop and tabletop release), that allows the operator to override the control system in emergency situations. finally, the system contains a light-visor for marking the scan plane, and automated positioning of this scan plane to the center of the bore of the mri scanner. 4.1 controller synthesis 4.1.1 models of the uncontrolled plant the model of the uncontrolled plant consists of 5 components: 1) vertical axis consisting of the motor model, the sensors model, and the model of the relation between the motor and the sensors; 2) horizontal axis consisting of separate models for the motor, clutch, sensor, ttr sensor, tt sensor, encoder, and the tts mode, respectively, and a model for the relation between the actuators and the sensors; 3) picu consisting of models for the tumble switch, manual button, light-visor button, tts button, manual led, tts led, and the emergency led, respectively. furthermore, it contains a model to describe the timebehavior of the tumble timer; 4) light visor; 5) emergency subsystem. the complete models of the vertical axis are shown in figure 64. the vertical axis contains two sensors: maximally up and maximally down. initially the table is assumed to be neither up or down, so that both end sensors are inactive. the sensors emit the events v max. . . on or v max. . . off, when a sensor becomes active or ceases to be active, respectively (fig. 6a). because of the physical location, the sensors are never active at the same time. the motor is initially in an error state (fig. 6c). the motor returns to this state after each error. from the error state, the system can be reset, to enter the inactive state. if the system is inactive, movement can be started. when movement is stopped, the system enters the stopping state. if the system is not moving anymore, the motor emits the event stopped, and the motor enters the stopped state. from this state, either movement can be started, or the system can be reset to enter the inactive state. 4 in the figure, solid and dashed edges denote controllable and uncontrollable events, respectively; all states are marked. proc. mpm 2009 6 / 10 eceasst vmiddle vupvdown v maxup on v maxup offv maxdown on v maxdown off (a) sensor model vstopped vmupvmdown v move up v move down v move down v move up v stopped v error v stopped v error v stopped v error v stop upv stop down v maxdown off v maxup on v maxdown on v maxup off (b) motor sensor relation model verror vinactive vmoving vstopping vstopped v re se t v er ro rv move up v move down v error v sto p up v sto p do wn v sto p tu mb le v sto p tt r v er ro r v stopped v error v move up v move down v re se t (c) motor model figure 6: plant model of the vertical axis (∈ pde.ads). vmiddle vupvdown v maxup on v maxup offv maxdown on v maxdown off v move down v stop up v move up v move down v move up v stop down figure 7: example vertical control requirements (∈ sr.ads). the sensors do not change state when the motor is not moving (fig. 6b). only when the vertical motor is moving up, the maximally down sensor can turn off and the maximally up sensor can turn on, and likewise for the opposite direction. note that this model is not a control requirement, it is an physical property of the system. if this model would be included as control requirement, the resulting supervisor would be empty due to restrictions on the uncontrollable sensor events, which cannot be realized by any supervisor. summarized, the model of the uncontrolled plant consists of 27 relatively small, loosely coupled automata. 4.1.2 models of the requirements in total there are 57 automata describing the control requirements for the supervisor. the automaton model of the requirement “the vertical axis should not move beyond its maximally up and maximally down position” is shown in figure 7. when the table is maximally up or down, it should stop (events v stop up and v stop down). in the maximally up position it is not allowed to move up (no event v move up), in the maximally down position it is not allowed to move down (no event v move down). 4.1.3 synthesis of the supervisor by using modular supervisor synthesis, see [won07, cl07], 14 supervisors are synthesized which together implement all control requirements. the global nonblocking property is checked using automaton abstractions, see [ssrh08]. this abstraction procedure removes internal transitions of relevant automata, allowing the nonconflicting check to be performed over relatively small automata, even though the original system is fairly large. 7 / 10 volume 21 (2009) model-based engineering of supervisory controllers using cif e i m s sd ac tv re se t w he n m ai npo w er = 0 no w ac tv er ro r act v move up do speed := 5.0act v move down do speed := −5.0 ac t s to p do sp ee d, t : = 0. 0, 0. 0 when main-power = 0 now act v error do speed := 0.0 when t ≥ 0.1 now act v stopped w he n m ai npo w er = 0 no w ac tv er ro r act v move up do speed := 5.0 act v move down do speed := −5.0 ac t v re se t when main-power = 0 now act v error do speed := 0.0 motor: motor var speed: disc real clock t v error v reset v move up v move down v stopped stop power: cont real position: cont real m u d when vpos ≥ 10.0 now act v maxup on when vpos ≤ 0.0 now act v maxdown on when vpos > 0.0 now act v maxdown off when vpos < 10.0 now act v maxdown off sensor: sensors v maxdown on v maxdown off v maxup on v maxup off position: cont real r s act v stop down act v stop up act v stop tumble act v stop ttr act v stop tabletop now act stop motorstop: motorstop v stop up v stop down v stop tumble v stop ttr v stop tabletop stop vertical: vertical figure 8: hybrid cif model of the vertical axis (∈ phy.cif). 4.2 simulation of the supervisor and a hybrid model of the plant figure 8 shows the hybrid cif model of the vertical axis component. in this figure, an automaton instantiation is represented as a solid box that is labeled with its name and the name of the automaton definition. its internal declarations are listed in the upper left corner, and its external declarations are represented as ports on the borders of the box. the shape of a port depends on the type of declaration: a solid box denotes an action, and a solid triangle on the outer side (inner side) denotes an output (input) variable. modes are visualized by means of circles labeled with the name of the mode. the flow, invariant and time-can-progress predicates are omitted from the figure, the predicates are true unless stated differently. edges are represented as arrows between modes and are labeled with their guard, action, update (e.g. assignment to a variable), and, if the edge is urgent, the keyword now. the cif model of the vertical axis consists of an automata instantiation vertical that instantiates automaton definition vertical. automaton definition vertical consists of the automata instantiations motorstop, motor, and sensor that instantiate the automata definitions motorstop, motor, and sensor, respectively. automaton definition motorstop translates the various stop events from the supervisor to a single stop event; motor models the dynamic behavior of the motor; and sensors models the behavior of the sensors. the invariant predicate for all modes of the motor automaton equals ˙postion = speed, where ˙position denotes the derivative of the position. the automata motor and motorstop synchronize on the stop event. the automata motor and sensors share the continuous variable position. figure 9 shows the simulation results of the following use case. initially, the tabletop is positioned at the maximally out position, and the table is halfway up. the tumble switch is used to move the table to the upper position (t = 2). when the table reaches the upper position (t = 3), the table stops, and the tumble switch is released. then the table is moved inward, first slowly (t = 4), then faster (t = 5). after that the movement is stopped (t = 7). finally the table is moved out (t = 8), and switches automatically to moving down (t = 10) until it reaches the lowest position. proc. mpm 2009 8 / 10 eceasst 0 2 4 6 8 10 0 2 4 6 8 10 12 -1.5 -1 -0.5 0 0.5 1 1.5 p o si tio n a n g le t h_position(t) v_position(t) tumble_angle(t) figure 9: simulation results s/phy.cif. 4.3 real-time, simulation based control the sensors and actuators of the actual patient support table are connected to an industrial grade i/o controller, which in turn is connected to a standard pc. the i/o controller conditions the sensor signals, translates sensor state changes to events, and translates events from the pc to appropriate inputs for the actuators. on the pc, the events from the i/o controller are buffered in an event queue. after receiving an event from the i/o controller, the state of the supervisor is updated, and the set of controllable events that is allowed by the supervisor is calculated. from this set, an event is selected and sent to the i/o controller. in the simulation model, the plant model and the model of the supervisor interact synchronously, i.e. they synchronize on common events. however, during the real-time, simulation based control, the interaction between the patient table and the supervisor is asynchronously. more precisely: after a change of state of a sensor, this change has to be detected by the i/o controller (sensor polling delay). then the i/o controller sends an event to the pc (communication delay between i/o controller and pc). after detection of the event (event queue polling delay), the state of the supervisor is updated, the allowed events are calculated, and an event is selected (calculation delay). in the setup, first all events from the event queue are processed. then, when the event queue is empty, an allowed controllable event is selected and sent to the i/o controller. 5 conclusions in this paper, we developed a framework for supervisory controller design, based on the model-based engineering and supervisory control theory paradigms. this framework enables 1) simulation of the discrete-event plant models controlled by the synthesized supervisor model in order to validate the controlled behavior; 2) simulation of more detailed, e.g. timed or hybrid, plant models; 3) early integration and testing by means of real-time simulation; and 4) code-generation for the supervisory controller. to support the design process of industrial-size supervisory controllers, a tool framework, based on the common interchange formalism for hybrid systems (cif) has been developed. as part of the multiform project, the relations between the discrete-event model of the plant that is used for the supervisory controller synthesis and the more detailed timed and/or hybrid models of the plant will be studied. acknowledgements: the authors like to thank dennis hendriks and albert hofkamp for implementing major parts of the cif tool framework, and peter thijs for implementing the ads2cif translation tool. bibliography [bra08] n. c. w. m. braspenning. model-based integration and testing of high-tech multi-disciplinary systems. phd thesis, eindhoven university of technology, 2008. 9 / 10 volume 21 (2009) model-based engineering of supervisory controllers using cif [brrs07] d. a. v. beek, m. a. reniers, j. e. rooda, r. r. h. schiffelers. revised hybrid system interchange format. technical report hycon deliverable d3.6.3, hycon noe, 2007. [brrs08] d. a. v. beek, m. a. reniers, j. e. rooda, r. r. h. schiffelers. concrete syntax and semantics of the compositional interchange format for hybrid systems. in 17th triennial world congress of the international federation of automatic control. pp. 7979–7986. seoul, korea, 2008. [brsr07] d. a. v. beek, m. a. reniers, r. r. h. schiffelers, j. e. rooda. foundations of an interchange format for hybrid systems. in bemporad et al. (eds.), hybrid systems: computation and control, 10th international workshop. lecture notes in computer science 4416, pp. 587– 600. springer-verlag, pisa, 2007. [cl07] c. g. cassandras, s. lafortune. introduction to discrete event systems. springer, 2nd edition, 2007. [hyc05] hycon network of excellence. http://www.ist-hycon.org/. 2005. [mob02] mobies team. hsif semantics. technical report, university of pennsylvania, 2002. internal document. [mul08] multiform consortium. integrated multi-formalism tool support for the design of networked embedded control systems multiform. http://www.multiform.bci.tu-dortmund.de, 2008. [ogr00] i. ogren. on the principles for model-based systems engineering. systems engineering 3(1):38– 49, 2000. [pcps06] a. pinto, l. p. carloni, r. passerone, a. l. sangiovanni-vincentelli. interchange format for hybrid systems: abstract semantics. in hespanha and tiwari (eds.), hybrid systems: computation and control, 9th international workshop. lecture notes in computer science 3927, pp. 491–506. springer-verlag, santa barbara, 2006. [pfc89] r. j. patton, p. m. frank, r. n. clarke (eds.). fault diagnosis in dynamic systems: theory and application. prentice-hall, inc., 1989. [plo04] g. d. plotkin. a structural approach to operational semantics. journal of logic and algebraic programming 60-61:17–139, 2004. [sbpm09] d. steinberg, f. budinsky, m. paternostro, e. merks. emf eclipse modeling framework. addison-wesley, 2009. [ssb+09] c. sonntag, r. r. h. schiffelers, d. a. v. beek, j. e. rooda, s. engell. modeling and simulation using the compositional interchange format for hybrid systems. in troch and breitenecker (eds.), 6th international conference on mathematical modelling. vienna, austria, 2009. [ssrh08] r. su, j. h. van schuppen, j. e. rooda, a. t. hofkamp. nonconflict check by using sequential automaton abstractions. technical report 2008-010, eindhoven university of technology, 2008. http://se.wtb.tue.nl/sereports [sys08] systems engineering group tu/e. cif toolset. http://se.wtb.tue.nl/sewiki/cif, 2008. [won07] w. wonham. supervisory control of discrete-event systems. dept. elect. comput. eng., univ. toronto, toronto, on, canada, 2007. http://www.control.toronto.edu/des/ proc. mpm 2009 10 / 10 http://se.wtb.tue.nl/sereports http://www.control.toronto.edu/des/ introduction mbe and sct model-based engineering supervisory control theory integrating mbe and sct integrating mbe and sct tool framework the cif language tool framework case study: patient support system controller synthesis models of the uncontrolled plant models of the requirements synthesis of the supervisor simulation of the supervisor and a hybrid model of the plant real-time, simulation based control conclusions systemic modeling of agent coaction: a catalog of decentralized coordinating processes electronic communications of the easst volume 27 (2010) workshop über selbstorganisierende, adaptive, kontextsensitive verteilte systeme (saks 2010) systemic modeling of agent coaction: a catalog of decentralized coordinating processes jan sudeikat2 and wolfgang renz 12 pages guest editors: klaus david, michael zapf managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst systemic modeling of agent coaction: a catalog of decentralized coordinating processes jan sudeikat12 and wolfgang renz1 1 jan.sudeikat; wolfgang.renz @haw-hamburg.de multimedia systems laboratory, faculty of enigneering and informatics, hamburg university of applied sciences, berliner tor 7, 20099 hamburg, germany abstract: taking inspiration from natural self-organizing systems is a successful strategy to solve computational problems in distributed systems. faced with a particular problem, application designers have to identify an appropriate dynamical behavior and decide how to induce similar behavioral modes. in order to consolidate these ad-hoc activities to a systematic dynamical design method, we discuss and exemplify a behavioral modeling approach that describes the macroscopic behavior of agent-based software systems. this formalism is used to catalog the dynamic behavior of prominent examples of natural self-organizing systems. these here presented models represent generic, reusable templates for decentralized system adaptations that serve as analysis templates for application designs. a tailored programming model allows to supplement these templates in agent-based software applications with minimal intervention in the agent models. keywords: self-organization, systemic modeling, process template 1 introduction the research project ”selbstorganisation durch dezentrale koordination in verteilten systemen”3 (sodekovs) addresses the preparation of nature-inspired dynamics as reusable design elements for software engineers. the conception of this project was reported in the last year’s issue of this workshop [sbp+09]. coordinating processes that have been found in natural selforganizing systems are understood as reusable templates that describe field-tested processes of inter-agent coordination. within this research project, a tool set is elaborated (cf. section 2) that allows to treat these processes as design elements, i.e. artifacts for the incremental revision and integration in applications. part of this tool set is a modeling approach that expresses processes as structures of feedback loops among system entities. self-organizing phenomena can be explained by distributed feedbacks (e.g. [bdt99]) and here, we use a corresponding modeling stance to catalog nature-inspired, inter-agent coordination processes. this catalog aggregates processes that have been discussed in literature. the aim is an (initial) collection of generic processes that can be straightforward reused in mas development. this is reflected by the abstraction level of these templates. templates are described 2 jan sudeikat is doctoral candidate at the distributed systems and information systems (vsis) group, department of informatics, faculty of mathematics, informatics and natural sciences, university of hamburg, vogt–kölln–str. 30, 22527 hamburg, germany, jan.sudeikat@informatik.uni-hamburg.de 3 selforganisation by decentralized coordination in distributed systems 1 / 12 volume 27 (2010) mailto:jan.sudeikat; wolfgang.renz @haw-hamburg.de systemic modeling of agent coaction as generic sets of inter-agent feedbacks. the participants within these feedbacks can be detailed to match application elements. the detailing and embedding of process models is exemplified ([sr09b, sr09c, sr09e], cf. section 2.2) and systematized [sr09d] in earlier works. this paper is structured as follows. in the next section, the conceptual model of a selforganizing application and the hitherto elaborated tool set is outlined. afterwards, in section 3, coordination templates are cataloged. besides the structural and dynamic properties of these templates are contrasted and discussed. finally, we conclude and give prospects for future work. 2 systemic modeling and programming of agent-coaction decentralized, self-organizing processes are caused by the presence of mutual feedback loops among system components, e.g. discussed in [bdt99]. early works focused on the analysis of self-organizing processes to facilitate the purposeful redesign of application to expedite the rise of intended system phenomena [sr08a]. these works lead to a systemic modeling approach to decentralized inter-agent coordination in multi-agent systems (mas) [sr09b, rs08]. this modeling technique transfers system dynamics [ste00] concepts to the description of agent-based software systems. the macroscopic system configuration is denoted by a set of system variables. each variable is represented by a graph node and represents the number of agents that exhibit a certain behavior or the quantitative values of environment properties. different node types can be used to represent behavioral abstractions that are provided by agent-oriented design techniques, e.g. role or group concepts [sr09b]. in addition, interaction rates can be denoted by graph nodes as well. the dynamic relations between these variables are denoted by links, that represent either causal interdependencies or additive/subtractive influences. in, addition, it can be indicated whether an influence is based on an specific interaction mechanism, e.g. mediated by environment models [dh07] (cf. section 2.1). in section 3, the graph-based description level is used to illustrate template coordinating processes. the graphical notation is exemplified in the figures 2, 3, and 4. in the sodekovs project, this modeling approach is transferred to a corresponding programming model that allows to describe decentralized processes, which affect the coordination of entity activities, as structures of influences among agent-behaviors. in [sr09b], a corresponding configuration language is discussed that allows to configure the exhibition of these processes. this language supports two description levels. first, inter-agent interdependencies are descried by directed graphs. these graphs describe application-independent structure of feedback loops among system entities that make up coordinating process. secondly, the process models can be mapped to agent implementations and the dissemination of influences can be configured. an architectural model for the enactment of the configured process instances is outlined in [sbp+09] and a realization is discussed in [sr09a]. this architecture follows a layered design and the enactment of inter-agent coordination is outsourced to a middleware layer that encapsulate the activities that are conceptually related to inter-agent coordination [sr09a]. the systematic utilization of this programming model is instructed by a set of reusable development activities [sr09d] that supplement conventional development, using method engineering [cggs07]. saks 2010 2 / 12 eceasst 2.1 building-in decentralized coordination the operation of autonomic computing systems can be distinguished, between (1) the objective to be achieved by the management, (2) the mechanisms that are actuated to achieve the objective, and (3) strategies that prescribe and order the activations of mechanisms (e.g. in [jpr09]). the design of a self-organizing application follows a comparable structure (cf. figure 1). the design objective is to equip the developed application, here a mas, with an adaptation dynamic, i.e. a behavioral mode that makes the system adapt to external influences. adaptivity is understood as a black-box property [zad63] at the macroscopic system level that makes systems respond to changes in their execution context. following a decentralized approach, the system is adjusted due to collective, concurrent adaptations of the individual system entities. this collective behavior is prescribed by a coordinating process. systemic models (cf. section 2) describe the structure of the inter-agent feedbacks that manifest these processes (systemic process model). the described structures can give rise to a space of process realizations, due to varying parameterizations, e.g. interaction rates, thus the actually exhibited process is a concrete instantiation of the process structure. a successful approach to conceive these processes by resembling the dynamics in natural systems [mmtz06]. the realization of these processes makes use of coordination mechanisms (e.g. reviewed in [sr08a] that provide models to control the information exchange [dh07] and local entity adaptation [sgk06]. the former ones define how information is stochastically disseminated and diluted while the latter ones configure how individual entities respond to the communicated information. the enacted strategies define which mechanisms are to be embedded in the application and instruct their actuation. application adaptation dynamic exhibits coordinating process coordination mechanism(s) structure / instruct realize information exchange local entity adaptation systemic process model (feedback structure) instance of implicated by described by figure 1: the relations between an adaptation dynamic, the prescribing coordination process, and the actuated coordination mechanisms. 2.2 case studies the design approach and the tool set have been evaluated in several case studies. here, we outline two studies that exemplify the minimal-invasive integration of pattern. the systematic conception of feedback loop structures is discussed in [sr09d, sr09c]. for the sake of brevity, 3 / 12 volume 27 (2010) systemic modeling of agent coaction the integration of the pattern, using the outlined programming model is not demonstrated, but the systems objective and the rationale to integrate template processes are discussed. details on the system realizations have been published in [sr09b, sr09c]. 2.2.1 bee-inspired server management in [sr09e], a decentralized management architecture for j2ee application servers is presented. glassfish4 application servers are controlled by jadex-based5 agents via the appserver management extensions6 (amx). this exemplifies agent-based management approaches to the management of computational infrastructures. a bee-inspired mechanism for the dynamic allocation of (web) servers is presented in [nt04]. the design objective is to balance the deployments of services on servers with the fluctuating demands for the individual service types. in [sr09b], this scenario is adopted to exemplify the utilization of the systemic programming model (cf. section 2) and the tool set is used to configure a decentralized process that resembles the dynamics of foraging bee societies. the corresponding template is discussed in section 3.2 (s6). following the inspirational source, the agent society is separated into a population of scouting and foraging agents. scouts metaphorically explore the environment by serving random client requests. when they observe increases in the demand of specific request types, this demand is gradually disseminated to the foraging servers that are allocated to a specific request type and autonomously reconfigure themselves, based on the perceived demands [sr09b]. 2.2.2 information dissemination processes in [sr09c], the embedding of dissemination process [egkm04, st97] in mas is discussed. these processes are integrated in a homogeneous mas and is enacted without modification of the original agent models. the processes are integrated as background processes that modify the knowledge base of their surrounding agent coefficient to the agent execution. the first process concerns the integration of convention emergence [st97]. convention emergence describes phenomena, where agents mutually inform each other about their local configuration (cf. section 3.3). based on the perceived information and their local policy, e.g. a majority rule, agents adjust their configuration. when the communicativeness and the adaptivity of agents are wellmatched, set so agents can agree on a coherent configuration value, solely based on their local interactions. secondly, the epidemic spreading of information [egkm04] (cf. section 3.3) is exemplified. the metaphoric spreading of an infection is used to distribute patches in a set of agents and the competitive spreading of two dissemination processes is studied. 3 a template catalog the design of coordinating processes (cf. figure 1) on the drawing board is a laborious process that requires extensive system simulations to ensure that the conceived processes give rise to 4 https://glassfish.dev.java.net/ 5 http://jadex.informatik.uni-hamburg.de 6 https://glassfish.dev.java.net/javaee5/amx/index.html saks 2010 4 / 12 eceasst the intended system phenomena. in this respect, nature-inspired processes can serve as fieldtested templates. in order to prepare the reuse of these templates in application designs, these are modeled, using the systemic modeling technique from [sr09b]. the here presented catalog extends earlier works on the modeling of feedback loops structures in nature-inspired agent coordination [sr08b]. in alphabetic order, the considered templates are: brood sorting (s1) [mmtz06], convention emergence (s2) [st97], epidemics (s3) [egkm04], flocking (s4) [mmtz06], ant-based foraging (s5) [mmtz06], bee-based foraging (s6) [nt04], molding (s7) [mmtz06], morphogenesis (s8) [mmtz06], nest-building (s9) [mmtz06], quorum (s10) [mmtz06], and web weaving (s11) [mmtz06]. the systemic modeling level expresses the structures of feedback loops that are present in the macroscopic observable system behavior (cf. section 2). these feedbacks result from circular sequences of interdependences and influences. these are either reinforcing (+) as fluctuations of system variables are amplified or balancing (-), due to the attenuation of fluctuations. in the following, processes are distinguished by their regulation polarity (rp) that is given by their prevalent feedbacks. amplifying processes contain a majority of reinforcing feedback while compensating processes contain a majority of balancing feedbacks. in selective processes, both types of feedbacks are evenly featured. this is a purely structural property. decentralized coordination strategy s1 s2 s3 s4 s5 s6 s7 s8 s9 s10 s11 amplifying −/+2 + +2 + rp (i) compensating −2/+ −n −2/+ − selective −/+ −(2)/+ −/+ t configuration x x x x x x x process x x x x a endogenous x x x x extrinsic x x x x x x x differentiation x x x x x s synchronization x x external x x x x c coherence x x x x x x x x partitioned x x x x x table 1: classification of coordination strategies, according to the regulating polarity of loop structures (rp) and the properties of the resulting structures (t,a,s,c). the feedback models are used to describe templates of processes that, show self-organization, i.e. generate and maintain structures. for the selection and comparison of processes an additional set of classification criteria is presented that characterizes the types of structures and their run-time adjustments. first, two principal types (t) of the self-organized structures can be distinguished. decentralized processes can be utilized to either control the configurations of system entities, e.g. establish conventions and coalitions, or establish a collaborative process among the system elements, whereby the collaboration of agents is enforced by structuring the chronology of agent activities. the adjustment of the established structures is another fundamental property and this adaptivity (a) is characterized by the loci of the causes for restructuring. endogenous reconfigurations result from process internal processing and oppose the extrinsic adaptivity 5 / 12 volume 27 (2010) systemic modeling of agent coaction where systems respond to external changes in the context of the software system. furthermore, the subject (s), i.e. the system quality, that are affected by coordinating processes are characterized. the differentiation refers to the partitioning of system elements, i.e. as the homogeneous mas are specialized to distinct castes or segregated into distinct groups. the synchronization describes the creation of timely structures of agent activities and the external refers to the adjustment, i.e. structuring, of the systems environment. finally, processes can be distinguished the the composition (c) of the established and maintained structure. structures either span the whole software system coherence or partition the system into locally coherent structures (partitioned). the attribution of processes to these criteria is summarized in table 1. 3.1 amplifying processes amplifying processes contain a majority of reinforcing feedback loops, thus the adjustments of macroscopic structures are induced by the amplification of system variables that propagate through the system. four examples are illustrated in figure 2. the ant-based foraging (s5) template describes the metaphorical formation of trails between environment locations as found in ant colonies. agents that are not bound to a trail are searching the environment. the agents that transport a resources to their home base communicate their activity via a coordination mechanism [dh07], i.e. digital pheromones. this communications contribute to a globally observable binding rate as searching agents occasionally perceive these communications and get aware of resource locations. aware agents follow pheromone gradient (trailing), encounter a resource location (pickup) and subsequently transport resources to the home base (delivery). these transports are associated with a delay (||). the resource availability given by the environment state, contributes to the serendipitous encounter of resources by agents. the removal of resources in governed by two feedbacks (β ,γ ) that establishes a collaborative process among agents that repeatedly search and transport resources. these activities are controlled by an extrinsic factor, i.e. the availability of resources and the process addresses the coherent modification of the external environment as resources are gradually redeployed. molding (s7) is found in protozoic life forms. these individuals are either part of a larger cluster (aggregation) or are individually foraging resources (autonomous behavior). the rates of clustering and leaving (unclustering) agents are controlled by the availability of resources in the systems environment. the exhibited process is controlled by a single feedback loop that controls the coherent configuration of agents according to the extrinsic resource availability. the changes of agent configurations are synchronized. the nest-building (s9) within termite colonies is a prominent example for distributed assembly processes. agents utilize environment resources to generate building blocks (brick creation). subsequently, individuals carry these bricks and search for locations for their deposit (brick creation). an effective mechanism is the enabling of bricks to communicate their placement, e.g. via digital pheromones (brick communication). transporting agents are attracted and place building block nearby (brick deposit). the supply of building block is controlled by a feedback loop (α ) that balances the generation of building blocks with the available resources. the sites of brick deposits compete for the generated resources and larger congregations of construction elements are enforced as deposits contribute to the communication, respectively attraction, of newly produced artifacts (β ). the agent activities are arranged to show a collaborative process saks 2010 6 / 12 eceasst that modifies the extrinsic system environment by transporting and depositing items. these activities responds to the availability of external resources. the process supports the diversity of structures in the environment partitioned, due to the emerging of differing deposit sites. s5: s9: s11: s7: figure 2: amplifying pattern. web weaving (s11) resembles the network creation by spider species, due to the sequential connecting of ground locations with draglines. the basic activity is the creation of lines (line creation). these lines are used to connect locations that are already reachable in the network (connected draglines) as well as so far unconnected locations (un-connected draglines). since spiders prefer to walk within their already established network of connections (dragline walking), the connection of connected locations is enforced. the web creation is a process that is governed by a single feedback loop. the created graph is an coherent element in the external environment that results from an endogenous stimulus, i.e. the creation activity of agents. 3.2 compensating processes these template processes compensate fluctuations of system variables, thus these template processes are applicable to the maintenance of continuously perturbed structures. the first example is the brood sorting (s1) that is exhibited by insect colonies. agents randomly explore their nest (wandering) and occasionally encounter environment elements, e.g. offspring in different stages (egg, larvae, etc.). isolated elements are picked up and transported (transportation) till similar items are encountered. the deposits reduce the dispersion of environment elements. the agent 7 / 12 volume 27 (2010) systemic modeling of agent coaction activities manifests a balancing feedback (α ) that affects the systems environment. two auxiliary feedbacks control the movement of items. transports are balanced with the amount of available agents (γ ) and are enforced by the deposits of items (β ). transports form a process within the agent population that modifies the extrinsic environment and responds to the perception of the external diversity of elements. the deposit logic can be configured to allow for coherent or partitioned structures. the flocking (s4), a.k.a. schooling or herding, is a prominent self-organizing phenomenon that describes movement pattern of bird and fish swarms. these pattern emerge when individuals maintain sets of highly fluctuating properties. agents mutually observe a properties of their neighboring agents, e.g. their speed and heading, and adjust their local configuration (adjustment) to minimize deviations (disagreement). in addition, certain invariants, e.g. the minimal distance to neighbors is maintained (maintenance) and the corresponding corrections introduce additional deviations ((self.property != destination.property)) and imply delays (||). the system exhibits a number of n feedbacks, one feedback per maintained property (α ) and two feedbacks per maintained invariant (β ,γ ). the subsequent adjustments by agents are synchronized to control the configurations of individuals and responds to extrinsic fluctuations. consequently, the system continuously approaches a coherent configuration. s1: s4: s6: s8: figure 3: compensating pattern. bee-based foraging (s6) resembles the resource gathering by honey-bee colonies. scoutsbees wander the environment and search for resource locations (scouting) while forager-bees are associated to specific resource locations and repeatedly transport resources to the home base (scouting). when resource locations are serendipitously encountered, scouts return to the saks 2010 8 / 12 eceasst nest and communicate their findings via waggle dances to foragers. foraging agents decide autonomously (change resource assignment), e.g. based on communicated quality criteria, if they adjust their association to a depletion site (foraging). the change of an association is modeled as the removal of foragers with other previous associations (self.resource != destination.resource) and the addition of foragers with the updated association (self.resource == destination.resource). the removal or resources is governed by two feedback loops (α,β ). in addition, the allocation of foragers to resource locations are adjusted by a reinforcing feedback (γ ). this template prescribes the differentiation of agent configurations, i.e. the associations of forgers. these associations are updated, due to the extrinsic availability of resources. the process can be configured to exhibit both the convergence to one globally coherent association of foragers, or their segregation to differing locations (partitioned). morphogenesis (s8) is another approach to control the differentiation of agents. an initially homogeneous set of agents is influenced by a subset of agents that distribute messenger substances (morphogen emitting). the emitters maintain a certain density at their position. other agents sense these substance and infer their relative position, based on the gradients of the perceived morphogens. based on this information they configure themselves (configuration adjustment) and convert to specialized agent-instances (specialized agents). this template manifests a feedback loop that controls the density of the morphogens. supporting different types of messenger substances multiplies this feedback. the reconfiguration of agents is a result of the locally perceived substance density. thus the endogenous differentiation of agents is controlled, leading to partitioned structures of agent configurations. 3.3 selective processes these process templates prescribe balanced sets of feedback types, thus the system history decides which system properties are amplified and discriminated. convention emergence (s2) describes the establishment of global consensus on a particular value. the operation of agents (activity) is influenced by their local configuration value. the process template prescribes that a side effect of the triggering of these activities, e..g when these are participate in interactions, is the communication of their local configuration to other agents. the receivers of these values adjust their local configuration (convention adjustment) in order to agree with the majority of agents in their neighborhood. adjustment affect the operations of agents. figure 4 (s2) illustrated the template for two values. one feedback (α ) amplifies the spread of a certain value, while the opposing feedback (β ) discriminates the other values. a wider range of values would introduce additional balancing feedbacks but the theme of the template is that a randomly selected value is enforced. thus a coherent configuration of agents is generated, due to the endogenous process that concerns the differentiation of agents. epidemics (s3) is nature-inspired approach to the dissemination of information in distributed systems. agents are either susceptible or infectious. infections metaphorically describe the transfer of information between agents and a macroscopic infection rate describes spreading within a set of agents. gradually, the susceptible agent configurations are removed (α ) and become infectious (β ). the system tends towards a globally coherent configuration where all agents are infected. the infections are triggered by the endogenous functioning of the process and agents are differentiated. an important variation of this scenario is the introduction of a 9 / 12 volume 27 (2010) systemic modeling of agent coaction recovering process. infectious agents recover after infections and are afterwards insusceptible to infections. the recovery resembles the processing of perceived information (infections). this introduces an additional balancing feedback (γ ). consequently the system tends toward a global configuration where all agents are recovered. the behavioral properties of the process are not effected by this extension. quorum is a phenomenon that can be observed when the activities of individuals stimulate coherent activities of neighboring agents. external perturbations drive agents out of sync (noncoherent). the coherence of activities is reestablished as agents perceive the activities of their neighbors and align themselves (adjustment). a balancing feedback (α ) counter-balanced perturbations. thus the system responds to extrinsic influences by reestablishing a coherent configuration of agents that manifests the synchronization of agent activities. s2: s3: s10: figure 4: selective processes. 3.4 associating template processes with behavioral properties the presented template-processes factor out the details of natural self-organizing systems but provide abstract representations of decentralized processes that developers can embed in distributed applicators to realize decentralized coordination. these templates are associated to behavioral properties to support their comparison and selection. the presented classification criteria justify the adoption of the bee-based foraging template, as outlined in section 2.2.1. the deployments of a web-services changes the local configuration of the system entities, here servers. these differentiate by their local set of services that are offered. since these configurations are to be structured and adjusted, in response to demand changes, process-establishing templates are not applicable. unpredictable fluctuations of demands are an extrinsic influence that the management has to respond to. the redeployments of services are internal to the system and do not affect the systems environment. thus process that concern the modification of external environments, e.g. system resources are not applicable as well. finally, the applied coordination processes has to allow for partitioned structures, since the allocations of different service types are required. the examined information dissemination processes (cf. section 2.2.2) share the same properties of the prescribed structure-establishment. since both processes prescribe an endogenous differentiation of agents, these are appropriate to be embedded as background processes within mas. equipping mas with these processes can be used to ensure the coherent distribution of information, independent from the application-domain and the data that are exchanged. saks 2010 10 / 12 eceasst 4 conclusions in this paper, prominent examples for nature-inspired self-organizing processes are cataloged according to their underlying feedback structure. these templates show the principled structure of the processes and guide their integration, using a systemic modeling approach (outlined in section 2). these processes describe structure-establishing dynamics and phenomenologic criteria for the characterization of the adaptive structuring are presented as well. these criteria facilitate the selection of processes for specific applications. future work, concerns guidelines for the systematic selection and combination of process templates. acknowledgements: we would like to thank the distributed systems and information systems (vsis) group at hamburg university, particularly winfried lamersdorf, lars braubach and alexander pokahr, and ante vilenica for inspiring discussion and encouragement. the project selbstorganisation durch dezentrale koordination in verteilten systemen (sodekovs) is funded by the german research council (deutsche forschungsgemeinschaft, dfg). bibliography [bdt99] e. bonabeau, m. dorigo, g. theraulaz. swarm intelligence: from natural to artificial systems. santa fe institute studies on the sciences of complexity. oxford university press, 1999. [cggs07] m. cossentino, s. gaglio, a. garro, v. seidita. method fragments for agent design methodologies: from standardisation to research. int. j. agent-oriented software engineering 1(1):91–121, 2007. [dh07] t. dewolf, t. holvoet. decentralised coordination mechanisms as design patterns for self-organising emergent systems. in engineering self-organising systems. volume 4335/2007, pp. 28–49. 2007. [egkm04] p. t. eugster, r. guerraoui, a.-m. kermarrec, l. massoulieacute;. epidemic information dissemination in distributed systems. computer 37(5):60–67, 2004. [jpr09] s. jha, m. parashar, o. rana. self-adaptive architectures for autonomic computational science. in proceedings of the workshop on self-organizing architectures. 2009. [mmtz06] m. mamei, r. menezes, r. tolksdorf, f. zambonelli. case studies for selforganization in computer science. j. syst. archit. 52(8):443–460, 2006. [nt04] s. nakrani, c. tovey. on honey bees and dynamic server allocation in internet hosting centers. adaptive behavior 12(3-4):223–240, 2004. [rs08] w. renz, j. sudeikat. modeling feedback within mas: a systemic approach to organizational dynamics. in organised adaptation in multi-agent systems, first 11 / 12 volume 27 (2010) systemic modeling of agent coaction international workshop, oamas 2008, estoril portugal, may 2008 revised and invited papers. lnai 5368, pp. 72–89. 2008. [sbp+09] j. sudeikat, l. braubach, a. pokahr, w. renz, w. lamersdorf. systematically engineering selforganizing systems: the sodekovs approach. electronic communications of the easst 17, 2009. issn 1863-2122. [sgk06] g. d. m. serugendo, m. p. gleizes, a. karageorgos. self-organisation and emergence in mas: an overview. in informatica. volume 30, pp. 45–54. 2006. [sr08a] j. sudeikat, w. renz. applications of complex adaptive systems. chapter building complex adaptive systems: on engineering self–organizing multi–agent systems, pp. 229–256. igi global, 2008. [sr08b] j. sudeikat, w. renz. toward systemic mas development: enforcing decentralized self-organization by composition and refinement of archetype dynamics. in proceedings of engineering environment–mediated multiagent systems. lncs, pp. 39–57. springer, 2008. [sr09a] j. sudeikat, w. renz. decomas: an architecture for supplementing mas with systemic models of decentralized agent coordination. in proc. of the 2009 ieee/wic/acm int. conf. on intelligent agent technology. pp. 104–107. ieee computer society press, 2009. [sr09b] j. sudeikat, w. renz. masdynamics: toward systemic modeling of decentralized agent coordination. in david and geihs (eds.), kommunikation in verteilten systemen. informatik aktuell, pp. 79–90. 2009. [sr09c] j. sudeikat, w. renz. on the modeling, refinement and integration of decentralized agent coordination – a case study on dissemination processes in networks. in proceedings of the workshop on self-organizing architectures. 2009. [sr09d] j. sudeikat, w. renz. programming adaptivity by complementing agent function with agent coordination: a systemic programming model and development methodology integration. communications of siwn 7:91–102, may 2009. issn 1757-4439. [sr09e] j. sudeikat, w. renz. shoaling glassfishes: enabling decentralized web service management. in 3rd international conference in sef-adaptive and self-organizing systems. pp. 291–292. ieee, los alamitos, ca, usa, 2009. (short paper). [st97] y. shoham, m. tennenholtz. on the emergence of social conventions: modeling, analysis, and simulations. artif. intell. 94(1-2):139–166, 1997. [ste00] j. d. sterman. business dynamics systems thinking and modeling for a complex world. mcgraw–hill, 2000. [zad63] l. a. zadeh. on the definition of adaptivity. proceedings of the ieee 51(3):469 – 470, 1963. saks 2010 12 / 12 introduction systemic modeling and programming of agent-coaction building-in decentralized coordination case studies bee-inspired server management information dissemination processes a template catalog amplifying processes compensating processes selective processes associating template processes with behavioral properties conclusions on formalising interactive number entry on infusion pumps electronic communications of the easst volume 45 (2011) proceedings of the fourth international workshop on formal methods for interactive systems (fmis 2011) on formalising interactive number entry on infusion pumps paolo masci, rimvydas rukšėnas, patrick oladimeji, abigail cauchi, andy gimblett, yunqiu li, paul curzon, harold thimbleby 15 pages guest editors: judy bowen, steve reeves managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst on formalising interactive number entry on infusion pumps paolo masci1∗, rimvydas rukšėnas1, patrick oladimeji2, abigail cauchi2, andy gimblett2, yunqiu li2, paul curzon1, harold thimbleby2 1 queen mary university of london school of electronic engineering and computer science 2 future interaction technology lab swansea university, www.fitlab.eu abstract: we define the predictability of a user interface as the property that an idealised user can predict with sufficient certainty the effect of any action in a given state in a system, where state information is inferred from the perceptible output of the system. in our definition, the user is not required to have full knowledge of a history of actions from an initial state to the current state. typically such definitions rely on cognitive and knowledge assumptions; in this paper we explore the notion in the situation where the user is an idealised expert and understands perfectly how the device works. in this situation predictability concerns whether the user can tell what state the device is in and accurately predict the consequences of an action from that state simply by looking at the device; normal human users can certainly do no better. we give a formal definition of predictability in higher order logic and explore how real systems can be verified against the property. we specify two real number entry interfaces in the healthcare domain (drug infusion pumps) as case studies of predictable and unpredictable user interfaces. we analyse the specifications with respect to our formal definition of predictability and thus show how to make unpredictable systems predictable. keywords: higher order logic, sal, interactive system design, predictability 1 introduction and motivation interactive devices have a wide range of application domains, each of which has different requirements and constraints. for instance, interactive systems used for entertainment (e.g., gaming consoles) need interfaces that assist users’ prompt adjustment on actions and decisions, generally aiming for zero-latency response. on the other hand, in safety critical contexts such as healthcare and air traffic control, preventing (or recognising and managing) human errors and avoiding cognitive overload are driving factors in interactive system design. in the present paper, we focus on number entry user interfaces for drug infusion pumps, an example of “simple” systems that need to be carefully designed in order to avoid unnecessary hazards that may lead to harm, in this case possibly to patient harm, even death, potentially following user error. drug infusion pumps are interactively “programmed” to deliver controlled ∗ corresponding author. 1 / 15 volume 45 (2011) on formalising interactive number entry on infusion pumps volumes or rates of drugs for therapy. infusion pumps are used in hospital wards, and some may be used in the patient’s home. an important consideration is that nurses often get interrupted from their work, including when setting up devices. if a nurse makes an error in setting up an infusion, it can cause severe harm to the patient, and potentially death. a typical problem is that a nurse may enter a number ten times to large, for example 50 mg per hour of morphine instead of 5 mg per hour, and this would be hazardous. however, under-dosing is also a problem: if a patient receives too little of a drug, their recovery may be delayed or they may be in unnecessary pain. such errors, unfortunately, are not rare. a recent bulletin from the uk government agency mhra (uk medicines and healthcare products regulatory agency), which is responsible for ensuring that medicines and medical devices work, reports that between the years 2005 and 2010 there were more than one thousand incidents involving infusion pumps alone in the uk, and several errors were due to number entries [med10] (this is likely to be under-reported); examples include setting the wrong rate, confusing primary and secondary rates, and not confirming the set rate or the configuration. nurses are usually interrupted while they carry out their tasks. there is empirical evidence that interruptions have a disruptive impact on people’s performance and reliability [tm07] that must be taken into account when designing interactive systems for safety-critical application contexts, such as emergency rooms and hospitals [ts06]. if nurses are interrupted while setting up an infusion, they need to stop their task, turn their attention to the interrupting task, and then resume the infusion task. if the pump interface does not show enough information to enable nurses to determine the exact device state, then nurses may fail to correctly resume the task, and an incorrect dosage input might be entered — for example, because they think they completed a step, and upon resumption they actually skip that step. also, if nurses are aware of this potential threat, they may try to apply workarounds, such as resetting the number entry system and starting over again. such workarounds considerably slow down the number entry task, but may also result in new issues, for instance, as a side-effect by resetting other parameters of the device, such as the unit of measurement. there are many factors contributing to the low predictability of interactive medical devices. the ever-increasing functionality constrained within the limited physical dimensions tends to push developers to overload the functionality of a single user interface element. for instance, the up button, which is typically used to increase the infusion rate, may also be used to provide other functionality in some device modes. however, though the outcome of this mode-dependent functionality will affect future interaction, its different meanings or the confirmation of its execution might not be readily visible to the user in any way. thus, it makes it difficult for the user to tell what the current state of the system is or to plan future actions. users build mental models of the devices they use, and for expert users these models can be highly accurate; in stable conditions users develop expertise and “normative procedures” over time through an exploratory process in which errors are unavoidable and help delineate “the boundaries of acceptable performance” — but even with such expertise, users frequently make errors and depart from these procedures, particularly when situations change or fail to meet expectations, where reliance on “the usual cues” fails them [ras90]. similarly, expert errors tend to be of the “strong but wrong” type, committed with confidence where, say, an attentional check is omitted or mistimed, or where some aspect of the environment is misinterpreted [rea90]. thus it is clearly of interest to develop systems in which “the usual cues” (whatever they are) are proc. fmis 2011 2 / 15 eceasst accurate: to be systems that are consistently predictable. in this paper, we explain how formal methods helped us to check whether device designs are predictable. specifically, we present a formal definition of predictability, and we discuss how it can be checked on a device specification. to trial our ideas, we formally specify two real infusion pumps, the alaris gp and the b-braun infusomat space (current models, 2011), and we use the symbolic analyser laboratory (sal) model checker to verify the predictability property. the general style of user interface is common to many such devices. we show that predictability, as defined, does not hold for the b-braun pump, and we propose some design modifications that correct the identified problems. we note that failure of predictability is not necessarily in itself a criticism of any design. there are many trade offs in design, and loss of predictability because of the presence of other features may be less important in practice than the value of the other features to the user. indeed there may be better definitions of predictability than we consider in this paper. the point of the paper, however, is to show that plausible safety-critical properties can be defined, that real devices can be very effectively analysed for their compliance to such properties, and that problems can be precisely identified and hence fixed. our definition of predictability is taken from the hci research literature, so it is a meaningful property, and it is clear that loss of predictability as we define it will increase specified hazards in operation. whether those hazards are somehow compensated for by other design features is an important question that lies beyond the scope of the present paper. 2 definitions of predictability predictability is an example of a formalisable user interface design principle that we intend to be generative, that is to capture relevant human factors concerns in such a way that software engineering can implement systems that are effective relative to those concerns [thi85]. the interesting research questions, at their most general, are how to have something that is formally tractable, delivers critical insights to designers and evaluators, and is consistent with human factors priorities. several definitions of predictability have been presented in the literature when considering interactive devices. in this paper, we are concerned with the case of experienced, skilled users with essentially correct mental models of the device. we aim to check that if such users look at the device and see that it is in a particular display state, then they can predict the next display state of the device if a button is pressed. this seems to be a necessary requirement to use a device safely, certainly without experimenting and relying on an undo operation. in particular, the concern with an idealised expert user means that, if predictability fails, any user equal or less experienced than the ideal (that is, any normal human user) will certainly be unable to predict the next state — thus the definition is conservative. our approach is similar to rushby’s work on mode confusion [rus02]: rushby compared a specification of the md-88 aircraft autopilot system with the mental model created by its users for discovering possible sources of mode confusion. in contrast to rushby, we assume that the idealised user has a precise mental model, that is the user has a correct and complete knowledge of the device functionality. in the following, we discuss the relation between our definition of predictability with two other 3 / 15 volume 45 (2011) on formalising interactive number entry on infusion pumps definitions. following [thi84, th85], abowd et al, in [acn92], define predictability in terms of whether the effect of future actions can be determined based on knowledge of the past history of actions: predictability — support for the user to determine the effect of future action based on past interaction history. this is a wider definition than we address here, as we assume no knowledge of the history but complete knowledge of the system model; in contrast abowd et al’s definition is concerned with the learnability of an interface, whereas we are concerned with expert users. also, they draw the distinction between deterministic behaviour and predictability. the former is a system property whereas the latter is a user-centred concept. the restricted version of predictability we consider is not simply deterministic behaviour as we need it also to be a user-centred property. however, abowd et al also link the concept of predictability to that of operation visibility: operation visibility refers to the rendering of operations in a way that expresses their availability in the current state. if an operation can be performed, then there must be some perceivable indication of this to the user. they also discuss the property of observability: observability allows the user to evaluate the internal state of the system from the perceivable representation of that state. state evaluation allows the user to compare the current observed state with the state intended in the action plan, possibly leading to a plan revision. this is a wider property than we consider, consisting of properties of browsability (the system allows the person to explore the interface to work out what is best to do), default-ness (providing default values), reachability and persistence. dix [dix91] also considers related topics formalised within the pie framework and discusses various forms of predictability. his core notion of predictability corresponds closely to the concept we consider here. predictability — can we work out from the current effect what the effect of future commands will be? this can be thought of as the “gone for a cup of tea” problem. when you return and have forgotten exactly what you typed to get where you are, can you work out what to do next? dix makes the distinction that the simplest form of predictability involves being able to tell where you are only from the state of the current persistent output of the device, such as what is on the screen. he suggests that more complex forms of predictability assume the presence of a user, for example to explore the interface. this leads to his definition of observability which essentially corresponds to abowd et al’s notion of observability. observability — although the system is seen as a black box, the user can infer certain attributes of its internal state by external observation. how much can the user infer? proc. fmis 2011 4 / 15 eceasst how should the user go about examining the system? [. . . ] predictability can be viewed as a special case of observability when we are interested in observing the entire state as it affects subsequent interaction. in particular, dix argues that predictability should not be based on the full system state but on the state as (potentially) perceived by the user: a monotone closure of the system state. 3 formal specification of number entry systems we now develop a formal specification of the number entry systems of two real medical devices: the alaris gp [hea06], and the b-braun infusomat space [b-b] infusion pumps. the specification is given in higher-order logic: we model information relevant to the display of the device as device states, and we specify device functionality using transition functions over device states. in our specification, we take into account the real values displayed by the devices, and the real action-effect relation of button presses. the higher-order logic specification language we use is that of the symbolic analysis laboratory sal [mor+04], which is based on typed higher-order logic, and includes, among others, function, tuple, and record type constructors for the definition of new types. the function type with domain type d and range type r is denoted [d -> r]. function, tuple, and record types can be dependent, that is the range of a function, or the type of a component of a tuple or record, may depend on the value of a function argument, or on the value of another component. the specifications below have been obtained by reverse-engineering the real devices based using interaction walkthrough [thi07]. we thus reverse engineered the specifications used below from the user documentation together with careful manual exploration of the actual devices and repeating until we had accurate specifications. we admit that this approach is potentially errorprone, but even so, the design and formal issues raised are real, and the complexity and level of detail of the specifications is certainly equal to real systems even if they have minor errors. even if there are minor errors, since we are professional computer scientists, our specifications will be better than any typical user’s understanding of the systems — our approach models idealised users well. (in principle, formal specifications could have been derived from the actual specifications of the devices if these were available, perhaps as provided by the manufacturers.) in particular, we are showing that our analysis and general approach can handle and provide insights into real systems of this sort of complexity. 3.1 alaris gp the number entry subsystem of the user interface on the alaris gp has four buttons. a pair of buttons is used to increase the value displayed and a second pair is used to decrease the value displayed. in each pair of buttons, one of the buttons causes a change ten times bigger than the change caused by the other button. typically, clicking either single chevron (arrow) key changes the last digit of the value displayed and clicking either double chevron key changes the second to last digit of the value displayed. we developed a detailed specification of the alaris gp number entry system with four functions (see figure 1). each function describes the action-effect of pressing one of the chevron 5 / 15 volume 45 (2011) on formalising interactive number entry on infusion pumps figure 1: alaris gp programmable infusion device. buttons on the device interface: function alaris up models the small step increase button press; function alaris up models the big step increase button press; functions alaris dn and alaris dn model the small step and big step decrease buttons press. in the specification, we use type alaris real for defining the domain of the numbers handled by the device in the rate mode (alaris real: type = {r: nonneg real | r <= max}, where max is a symbolic constant representing the maximum real number handled by the device, and function trim for enforcing that the number resulting from the button presses is within the bounds of alaris real, that is, trim(x) returns x if 0 ≤ x ≤ max, otherwise the function returns either 0 (if x < 0) or max (if x > max). alaris up the function increases the number shown on the display of the device according to the following rules: if the number on the display is below one hundred, then the fractional part of the number is increased to the next decimal (e.g., if the display shows 9.1 and the small increase button is pressed, then the display becomes 9.2); if the number is between one hundred and one thousand, then the unit digit of the number is increased to the next unit digit (e.g., if the display shows 123 and the small increase button is pressed, then the display becomes 124); if the number is above one thousand, then the tens digit of the number is increased to the next tens digit (e.g., if the display shows 1080 and the small increase button is pressed, then the display becomes 1090). the specification of the function follows. alaris_up(val: alaris_real): alaris_real = if val < 100 then trim( (floor(val*10) + 1) / 10 ) elsif val >= 100 and val < 1000 then trim( floor(val) + 1 ) else trim( (floor(val/10) + 1) * 10 ) endif; proc. fmis 2011 6 / 15 eceasst alaris dn the function decreases the number shown on the display of the device according to rules that are almost symmetric to those of the alaris up button: if the number on the display is below one hundred, then the fractional part of the number is decreased to the next decimal (e.g., if the display shows 9.1 and the small decrease button is pressed, then the display becomes 9); if the number is between one hundred and one thousand, then the unit digit of the number is decreased to the next unit digit (e.g., if the display shows 123 and the small decrease button is pressed, then the display becomes 122); if the number is above one thousand, then the tens digit of the number is decreased to the next tens digit (e.g., if the display shows 1080 and the small decrease button is pressed, then the display becomes 1070). the specification of the function follows. alaris_dn(val: alaris_real): alaris_real = if val < 100 then trim( (ceil(val*10) 1) / 10 ) elsif val >= 100 and val < 1000 then trim( ceil(val) 1 ) else trim( (ceil(val/10) 1) * 10 ) endif; alaris up the function increases the number shown on the display of the device according to rules that are similar to those of the alaris up button: if the number on the display is below one hundred, then the number is increased to the next unit digit (e.g., if the display shows 9.1 and the big increase button is pressed, then the display becomes 10); if the number is between one hundred and one thousand, then the tens digit of the number is increased to the next tens digit (e.g., if the display shows 123 and the big increase button is pressed, then the display becomes 130); if the number is above one thousand, then the hundreds digit of the number is increased to the next hundreds digit (e.g., if the display shows 1080 and the big increase button is pressed, then the display becomes 1100). the specification of the function follows. alaris_up(val: alaris_real): alaris_real = if val < 100 then trim( floor(val) + 1 ) elsif val >= 100 and val < 1000 then trim( (floor(val/10) + 1) * 10 ) else trim( (floor(val/100) + 1) * 100 ) endif; alaris dn the function decreases the number shown on the display of the device according to rules that are similar to those of the alaris dn button: if the number on the display is below one hundred, then the fractional part of the number is decreased to the next unit digit (e.g., if the display shows 9.1 and the big decrease button is pressed, then the display becomes 9); if the number is between one hundred and one thousand, then the tens digit of the number is decreased to the next tens digit (e.g., if the display shows 123 and the big decrease button is pressed, then the display becomes 120); if the number is above one thousand, then the hundreds digit of the number is decreased to the next hundreds digit (e.g., if the display shows 1080 and the big decrease button is pressed, then the display becomes 1000). the specification of the function follows. alaris_dn(val: alaris_real): alaris_real = if val < 100 then trim( ceil(val) 1 ) elsif val >= 100 and val < 1000 then trim( (ceil(val/10) 1) * 10 ) else trim( (ceil(val/100) 1) * 100 ) endif; 7 / 15 volume 45 (2011) on formalising interactive number entry on infusion pumps figure 2: b-braun infusomat space programmable infusion device. 3.2 b-braun infusomat space the b-braun infusomat space’s number entry interface has four buttons (see figure 2). the left and right buttons are used to change the cursor position. the left button increases the cursor position and the right button decreases the cursor position. the cursor is at position 0 when it selects the unit value on the number displayed. the up and down buttons increase or decrease the current number by 10cursorposition respectively. the device has an auxiliary memory for restoring the last displayed value when the button presses cause overshooting the maximum or the minimum values handled by the device. in the specification each function describes the action-effect of pressing one of the four arrow buttons on the device interface: functions bbraun up and bbraun dn model the effect of pressing the up and down buttons; functions bbraun lf and bbraun rt model the effect of pressing the left and right navigation button. in the specification, we use type bbraun real for defining the domain of the numbers handled by the device (bbraun real: type = {r: nonneg real | r <= 99999}), and we use the structured type state for defining the minimal information needed for specifying the behaviour of the device. the state includes three fields: current display value (display), current cursor position (cursorposition), and content of the memory (memory). in the specification, we use the constant na for specifying a clear memory. bbraun up the function modifies the value of the number shown on the display of the device according to the following rules: if the value currently displayed by the device plus 10cursorposition overshoots the maximum value, then the display value is stored in memory and the display gets updated with the maximum value, 99999 (e.g., when the display shows 90010 and the cursor is on the ten thousands digit, if the up button is pressed then the value 90010 is stored in memory and the display shows 99999); if the value currently displayed by the device plus 10cursorposition does not overshoot the maximum value, the functionality of the up button depends on the content of the device’s memory — if the memory contains a number, then the up button acts as a recall memory button (e.g., if the memory contains 100, the action of pressing the up button will display 100, regardless of the number shown on the display, otherwise the displayed number is increased by 10cursorposition (e.g., when the display is 10 and the cursor is on the hundreds decimal, if the up button is clicked then the new displayed value is 110). the specification of the function follows. proc. fmis 2011 8 / 15 eceasst bbraun_up(st: state): state = let val:bbraun_real = display(st), i:cursor = position(st), mem:bbraun_real = memory(st) in let new_val:real = val + pow10(i) in if new_val > max then (max, i, val) else % new_val <= max if valid?(mem) then (value(mem), i, na) else (new_val, i, na) endif endif; bbraun dn the function modifies the value of the number shown on the display of the device according to rules that resemble a specular behaviour with respect to those of the up button: if the value currently displayed by the device minus 10cursorposition overshoots the minimum value and the cursor is on a digit of the integer part of the number, then 10cursorposition is stored in memory and the display gets updated with a default minimum value (e.g., when the display shows 10 and the cursor is on the thousands digit, if the down button is pressed then the value 1000 is stored in memory and the display shows 0.1); if the value currently displayed by the device minus 10cursorposition overshoots the minimum value and the cursor is on a digit of the fractional part of the number, then the display becomes 0; if the value currently displayed by the device minus 10cursorposition does not overshoot the minimum value, the functionality of the down button depends on the content of the device’s memory — if the memory contains a number, then the down button acts as a recall memory button (e.g., if the memory contains 910, the action of pressing the down button will display 910, regardless of the number shown on the display1), otherwise the displayed number is decreased by 10cursorposition. the specification of the function follows. bbraun_dn(st: state): state = let val:bbraun_real = display(st), i:cursor = position(st), mem:bbraun_real = memory(st) in if val = 0 then st else let new_val:real = val pow10(i) in if new_val < 0 then if i = 4 or i = 3 then (1, i, pow10(i)) elsif i >= 0 and i < 3 then (0.1, i, pow10(i)) else (0, i, na) endif else % new_val >= 0 if valid?(mem) then (value(mem), i, na) else (new_val, i, na) endif endif endif; bbraun lf the function moves the cursor one position to the left and acts as clear memory button. specifically, if the cursor position is not on the most significant (integer) digit and the left button is pressed, then the cursor moves left one position and the device memory is cleared; otherwise, 1 due to the constraints imposed by the functionalities of the other buttons, the down button may act as recall memory only when the display shows 99999. 9 / 15 volume 45 (2011) on formalising interactive number entry on infusion pumps the left button is disabled (i.e., any left button press does not change the device state in this situation). the specification of the function follows. bbraun_lf(st: state): state = let val:bbraun_real = display(st), i:cursor = position(st), mem:bbraun_real = memory(st) in if i < 4 then (val, i + 1, na) else % i = 4 (val, i, mem) endif; bbraun rt the function has a behaviour which is symmetric to that of the left button. specifically, if the cursor position is not on the least significant (fractional) digit and the right button is pressed, then the cursor moves one position to the right and the device memory is cleared; otherwise, the right button is disabled. the specification of the function follows. bbraun_rt(st: state): state = let val:bbraun_real = display(st), i:cursor = position(st), mem:bbraun_real = memory(st) in if i > -2 then (val, i 1, na) else % i = -2 (val, i , mem) endif; 4 analysis predictability in the sense we are considering concerns whether it is possible to tell the state that the device is in from the interface model. a device is not predictable if from information visible to the user on the interface there is more than one possible state it could move to as a result of some action. to analyse predictability in sal, we specify two models: a device model and a prediction model. the device model is a specification on the interface level of how the device is programmed. the prediction model is a specification of what users might expect, based on the display information and the complete mental model of the device. intuitively, a device is then predictable, if the device and prediction models match, where matching means that the values of the corresponding variables in the device and prediction models are equal in all the reachable states of the device. to illustrate our approach, we describe below the analysis carried out on the b-braun number entry model. we start by specifying in sal the device model of its number entry system. our specification is the following state transition system: device : module = begin input event: event global st: state initialization st = (0, 0, na); proc. fmis 2011 10 / 15 eceasst transition [ event = up --> st’ = bbraun_up(st) [] event = dn --> st’ = bbraun_dn(st) [] event = lf --> st’ = bbraun_lf(st) [] event = rt --> st’ = bbraun_rt(st) ] end the transition system is initialised so that the value displayed is 0, the cursor is in the position 0 and the memory is clear. the input variable event represents button presses (up, dn, lf, rt). each guarded command specifies a state transition that is triggered by the corresponding event (primed variables represent new values). thus, our model device generates all possible sequences of button presses and the associated changes of the device state derived from a specific initial state. the prediction model is a reduced version of the device model. its specification is as follows: prediction : module = begin input event: event input st: state output predicted: bbraun_real initialization predicted = display(st); transition [ event = up --> predicted’ = let new_val:real = display(st) + pow10(position(st)) in if new_val > max then max else new_val endif [] event = dn --> predicted’ = let val:bbraun_real = display(st), i:cursor = position(st) in let new_val:real = val pow10(i) in if val = 0 then 0 elsif new_val >= 0 then new_val elsif i = 4 or i = 3 then 1 elsif i >= 0 and i <= 2 then 0.1 else 0 endif [] else --> predicted’ = display(st) ] end the variable predicted represents a new value that users would expect to be displayed as a result of a button press. the model prediction abstracts away the hidden state (memory) of the device. thus, the calculation of predicted is based solely on what is on display. otherwise, it is done according to the same rules as specified by bbraun up and bbraun dn. this captures our assumption that the user has a complete mental model of the device. now, we can check whether both models match with respect to the number value. if they don’t (i.e., there exists a system state where display(st) and predicted differ), we say that the device is unpredictable. formally, this is specified in sal as follows: system: module = device || prediction; predictable: claim system |g (display(st) = predicted); 11 / 15 volume 45 (2011) on formalising interactive number entry on infusion pumps the model system is a synchronous composition of the device and prediction models, which means that their transition systems are merged so that a transition is performed by both models in each step of the combined system. the ltl property predictable states that the predicate display(st) = predicted is an invariant, that is, it holds in all system states. the verification of this property with sal fails for the b-braun. the counter example generated by the tool shows that, starting from the initial state with display(st) = 0, the sequence of button presses up, lf, dn, up leads to the system state with display(st) = 10, which corresponds to what the real device produces for this input sequence: starting from (0, 0, na), by pressing the up button, the device state changes into (1, 0, na): the number on the display is incremented by 1; then, by pressing the left button, the state changes into (1, 1, na): the cursor highlights the tens digit; by pressing the down button, the device overshoots the minimum value (1−10 < 0), and the new state is (0.1, 1, 10): the display shows the minimum value (0.1) and stores 10 (i.e., pow10(cursorposition)) in memory; finally, by pressing the up button, the state becomes (10, 1, na): the up button recalls and clears the memory. however the value the user would expect is different: predicted = 10.1. indeed, if we calculate the next value by using the information displayed by the pump, we get the following sequence of displayed values. starting from 0, by pressing the up button, the device goes to 1; the left button press moves the cursor to the tens digit. then, the down button press causes an overshoot of the minimum value (1−10 is a negative number), and the device displays a minimum default value, which is 0.1 in this case. at this point, the cursor is still selecting the tens digit; hence, by hitting the up button, the user would expect 10.1 (10 + 0.1). thus, the above example indicates that our formalisation allows the detection of issues related to predictability of interfaces of real-world safety-critical interactive systems. we have checked the same property for the specification of the alaris pump, and such a specification doesn’t have such predictability issues. below, we discuss several candidate solutions to the problem of bbraun, and formally verify whether they indeed solve it. 4.1 possible solutions to the b-braun issues we now propose three possible solutions to overcome the predictability issues of the b-braun infusion pump. for each proposed solution, we checked with sal that the predictability property holds. 1. don’t use memory. this reduces the functionality of the device at the boundary cases where the device becomes unpredictable. as a result a user would always be able to predict with certainty the consequence of an action just by looking at the device. the predictability of the device is confirmed by the formal verification of the property predictable for the modified device model so that it does not include memory. however, this solution means that the possible perception that the up button undoes the action of the down button breaks at these boundary cases. 2. increase the visibility of the system state by showing on the display of the device when a number is stored in memory. this ensures that the display of the device shows sufficient information to understand the current state of the device. in addition, the down button should not be overloaded with undo functionality. instead, a different button proc. fmis 2011 12 / 15 eceasst should be used for that purpose (e.g., the c button). again, we modified the device model so that it displays the memory when the latter is not empty. the prediction model was also modified so that it uses the displayed information to calculate the predicted value. the formal verification confirms that the property predictable holds in this case. 3. avoid overshooting by ignoring the button presses that cause overshooting. this should generally be coupled with audible/visual feedback to signal that the button press has been ignored. this solution implies that setting the max and min values on the interfaces would require more effort from the user but with the possible consequence that they are more aware of setting values at these boundaries. this solution supports the classic user interface design principle of making critical actions more difficult to perform [nor02, nor83]. 5 discussion and conclusions even something as simple as number entry with four up/down/left/right keys is more complex than it appears. it is plausible that the manufacturers write programs to handle button presses and adjust numbers without using formal methods such as this paper demonstrates; whatever software development process is employed, it evidently results in acceptable functionality, as the devices we have examined are widely used. yet when the devices are closely examined, there are many boundary cases where interactive functionality seems awkward; this compromises the predictability of the devices, and hence may lead to unnecessary hazards in use. we have stressed that whether those hazards are balanced by the possible benefits of predictability-compromising features is an essentially empirical question beyond the scope of the present paper. the fact that the present paper’s analysis raises such design questions is an important benefit of the approach. our modelling shows that formal methods can be conveniently used for studying predictability of non-trivial user interfaces: on the one hand, the mere exercise of building a formal specification of the interface gave us useful insights on possible design issues, even before performing the analysis with the model checking tool; on the other hand, the formal tool enabled us to explore all possible behaviours, thus allowing us to explore the validity of the proposed design modifications. the increasing demand for advanced functionality forces single devices to be used for a wide variety tasks, but under the fixed physical constraints of the devices. it is understandable that over time users (or organisations) would require more sophisticated interactive systems that assist their varied tasks. however, the required generality introduces inconsistent behaviour to the user interface, which is sometimes an obstacle to the user’s mental model development. in addition, even if users have a complete and sound mental model of the system, the increasing number of hidden states that are inevitable with general-purpose systems makes it harder for them to predict the consequences of their actions. formal methods provide tools and methodologies for developers to formally analyse interactive systems from a systematic perspective, so as to identify crucial information that should be presented to the user in order to clarify the current state and increase the predictability. however, just like there is trade-off between functionality and predictability, high level clarity of the 13 / 15 volume 45 (2011) on formalising interactive number entry on infusion pumps system state also demand high level information presentation, which could potentially lead to cognitive system overload. in future, we plan to develop use empirical evaluation and hence develop an evidence-based balance between predictability and functionality. acknowledgements: funded as part of the chi+med: multidisciplinary computer-human interaction research for the design and safe use of interactive medical devices project, epsrc grant number ep/g059063/1, formally-based tools for user interface analysis and design, epsrc grant number ep/f020031/1, and extreme reasoning, grant number ep/f02309x/1. bibliography [acn92] g. d. abowd, j. coutaz, l. nigay. structuring the space of interactive system properties. in proceedings of the ifip tc2/wg2.7 working conference on engineering for human-computer interaction. pp. 113–129. north-holland publishing co., amsterdam, the netherlands, the netherlands, 1992. http://portal.acm.org/citation.cfm?id=647103.717569 [b-b] b-braun melsungen ag. infusomat space and accessory: instruction for use. [dix91] a. j. dix. formal methods for interactive systems. computers and people series. academic press, 1991. http://www.hiraeth.com/books/formal/ [hea06] c. health. alaris gp volumetric pump: directions for use. 2006. [med10] medicines and healthcare products regulatory agency (mhra). device bulletin, infusion systems, db2003(02) v2.0. november 2010. http://www.mhra.gov.uk/publications/safetyguidance/devicebulletins/ con007321 [mor+04] l. de moura, s. owre, h. ruess, j. rushby, n. shankar, m. sorea, a. tiwari. sal 2. in alur and peled (eds.), computer aided verification: cav 2004. lecture notes in computer science 3114, pp. 496–500. springer-verlag, july 2004. [nor83] d. a. norman. design rules based on analyses of human error. communications of the acm 26(4):254–258, 1983. doi:http://doi.acm.org/10.1145/2163.358092 [nor02] d. a. norman. the design of everyday things. basic books, new york, reprint paperback edition, 2002. [ras90] j. rasmussen. the role of error in organizing behaviour. ergonomics 33:1185–1199, 1990. [rea90] j. reason. human error. cambridge university press, 1 edition, oct. 1990. proc. fmis 2011 14 / 15 http://portal.acm.org/citation.cfm?id=647103.717569 http://www.hiraeth.com/books/formal/ http://www.mhra.gov.uk/publications/safetyguidance/devicebulletins/con007321 http://www.mhra.gov.uk/publications/safetyguidance/devicebulletins/con007321 http://dx.doi.org/http://doi.acm.org/10.1145/2163.358092 eceasst [rus02] j. rushby. using model checking to help discover mode confusions and other automation surprises. reliability engineering and system safety 75(2):167–177, feb. 2002. available at http://www.csl.sri.com/users/rushby/abstracts/ress02. [th85] h. thimbleby, m. d. harrison. formalising guidelines for the design of interactive systems. in cook and johnson (eds.), proceedings british computer society conference on human computer interaction, hci’85. pp. 161–171. cambridge university press, 1985. [thi84] h. thimbleby. generative user-engineering principles for user interface design. in shackel (ed.), proceedings first ifip conference on human computer interaction, interact’84. volume 2, pp. 102–107. 1984. [thi85] h. thimbleby. in shackel (ed.), human-computer interaction — interact’84. pp. 661–666. north-holland, 1985. [thi07] h. thimbleby. interaction walkthrough: evaluation of safety critical interactive systems. in doherty and blandford (eds.), dsvis 2006, the xiii international workshop on design, specification and verification of interactive systems. lecture notes in computer science 4323, pp. 52–66. springer verlag, 2007. [tm07] g. j. trafton, c. a. monk. task interruptions. reviews of human factors and ergonomics 3:111–126(16), 2007. doi:doi:10.1518/155723408x299852 http://www.ingentaconnect.com/content/hfes/rhfe/2007/00000003/00000001/ art00005 [ts06] a. l. tucker, s. j. spear. operational failures and interruptions in hospital nursing. health services research 41(3p1):643–662, 2006. doi:10.1111/j.1475-6773.2006.00502.x http://dx.doi.org/10.1111/j.1475-6773.2006.00502.x 15 / 15 volume 45 (2011) http://www.csl.sri.com/users/rushby/abstracts/ress02 http://dx.doi.org/doi:10.1518/155723408x299852 http://www.ingentaconnect.com/content/hfes/rhfe/2007/00000003/00000001/art00005 http://www.ingentaconnect.com/content/hfes/rhfe/2007/00000003/00000001/art00005 http://dx.doi.org/10.1111/j.1475-6773.2006.00502.x http://dx.doi.org/10.1111/j.1475-6773.2006.00502.x introduction and motivation definitions of predictability formal specification of number entry systems alaris gp b-braun infusomat space analysis possible solutions to the b-braun issues discussion and conclusions on a graph formalism for ordered edges electronic communications of the easst volume 29 (2010) proceedings of the ninth international workshop on graph transformation and visual modeling techniques (gt-vmt 2010) on a graph formalism for ordered edges maarten de mol and arend rensink 12 pages guest editors: jochen küster, emilio tuosto managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst on a graph formalism for ordered edges maarten de mol∗ and arend rensink http://www.cs.utwente.nl/∼molm, molm@cs.utwente.nl http://www.cs.utwente.nl/∼rensink, rensink@cs.utwente.nl department of computer science, university of twente enschede, the netherlands abstract: though graphs are flexible enough to model any kind of data structure in principle, for some structures this results in a rather large overhead. this is for instance true for lists, i.e., edges that are meant to point to an ordered collection of nodes. such structures are frequently encountered, for instance as ordered associations in uml diagrams. several options exist to model lists using standard graphs, but all of them need auxiliary structure, and even so their manipulation in graph transformation rules is not trivial. in this paper we propose to enrich graphs with special ordered edges, which more naturally represent the intended structure, and define how lists can be manipulated. we show that the resulting category satisfies sufficient hlr properties to apply standard algebraic graph transformation. we believe that in a context where lists are common, the cost of a more complicated graph formalism is outweighed by the benefit of a smaller, more appropriate model and more straightforward manipulation. keywords: graph rewriting, ordered edges 1 introduction the context of the work in this paper is graph transformation. this means that we use graphs, essentially only consisting of nodes and edges, to model different kinds of structures such as real-world systems or software concepts. a rich source of such structures comes from software engineering, in the form of uml models. graph transformation offers a mathematically well-founded method for systematically encoding changes to graphs; this in turn can be used to describe the dynamics of the system being modelled. in principle, appropriate compositions of the basic building blocks of nodes and binary edges can encode arbitrary structures. in many cases the resulting graphs reflect the original structures quite naturally. there are, however, situations in which the encoding is awkward, for instance because it requires auxiliary elements in the graph that do not directly reflect anything from the original structure. this impacts the understandability and complexity of the encoding, and thus decreases the usability of graph transformation. in such cases, one may choose to use a richer graph formalism instead, which more closely reflects the structures at hand. examples of enrichments, introduced exactly for the reason of modelling particular structures more naturally, are: attributed graphs [eept06a], hierarchical graphs [dhp02], and hypergraphs [hab92]. ∗ supported by the eu artemis project charter 1 / 12 volume 29 (2010) http://www.cs.utwente.nl/~molm mailto:molm@cs.utwente.nl http://www.cs.utwente.nl/~rensink mailto:rensink@cs.utwente.nl on a graph formalism for ordered edges there is, however, a price to pay for graph enrichments, in the form of added complexity in their usage and understanding (often called the learning curve), as well as in their manipulation, both on the level of theory and of implementation. enrichments in the graph formalism are only justified if the complexity increase is outweighed by the corresponding advantages in modelling. in this paper we propose an enrichment of the basic graph formalism to cope with the structural concept of ordered lists. such lists occur frequently in practice, for instance in the form of ordered associations in uml diagrams or arrayand list-like structures in software. we will argue that encoding lists using simple graphs introduces spurious elements and thus increases their complexity; also the manipulation of the encodings is non-trivial. in order to justify the cost of a more complex formalism on the level of theory, we show that dpo graph rewriting is well-behaved in the resulting category of list graphs. for a suitably chosen admissible[cl03] subclass of m-morphisms, we prove that pushouts along m-morphisms exist, and that these pushouts are partial vk squares[hei09]. we then make use of [hei09], in which heindel proves that these conditions imply the important hlr properties[pad93]. note that our category is not hlr adhesive [eept06b]; see section 3 for a counter-example. in the next section, we motivate and explain our extension on an intuitive level, using an example inspired by the olympic winter games. after that, section 3 presents the formal definitions and states the main theoretical result. we show the use of list graphs in section 4. finally, section 5 discusses related work and presents conclusions. 2 motivation as a motivating example, we use sporting events taking place in the 2010 olympic winter games. in particular, we concentrate on ice-skating. before the games, every skating event has a list of participants; the order in the list corresponds to their starting order at the event. for instance, figure 1 shows three events (1500 m, 5 km and 10 km for men). the 1500 m event has four participants, in the order from top to bottom; the 5 km event has three participants, namely kramer, tuitert and davis (in that order); and the 10 km has an empty list of participants. intuitively straightforward operations one may want to perform on such a list are: • appending an element when a new participant is enrolled; • removing participants convicted of doping abuse; • after the event, moving the winner to the top of the list. a more complex operation is list reversal. for instance, if we started with a ranking list (in which the seasonal best skater is at the top), then it needs to be reversed to get the starting order. 2.1 plain graph encoding there are several ways to encode such lists using plain graphs, consisting only of nodes and binary edges. we discuss the main issues. • the core problem is to specify the order of the elements. for this purpose, one can either rely on an implicit ordering, for instance using indices, or introduce an explicit ordering proc. gt-vmt 2010 2 / 12 eceasst part kramer event 1500m part davis part fabris event 5000m part tuitert event 10000m • parts • • • • parts • • • parts figure 1: skating events with overlapping lists of participants using special edges. indices require updating whenever elements are added or removed (except at the end of the list). • elements can be shared among lists (as figure 1 shows), or may even occur multiple times in the same list. for this reason, the indices or special edges specifying the ordering cannot be incident to the list elements themselves (this would introduce confusion between the lists); rather, one needs an intermediate layer of “slot” nodes. • it is often convenient, or even necessary, to express that a given element is in a particular list. to encode this information, we need further special edges pointing from the list owner to the elements, or vice versa. • many list operations explicitly refer to the first or last element. to express this, either we need negative application conditions stating that the element has no predecessor, respectively successor; or this information can be captured using special edges — which, however, then have to be maintained while manipulating the list. • the empty list needs to be represented in some special way, as in that case there are no element or slot nodes to attach information to. clearly, such a graph representation is expensive, in the sense of requiring many auxiliary elements; moreover, unless one is careful, the last two issues will require case distinctions in transformation rules. from programming, we know an encoding for lists that copes with most of the issues relatively well (in particular avoiding case distinctions), but is expensive in terms of overhead: namely, a circular linked list consisting of “slot” nodes pointing to the elements and back to the list owner, and a special “head” node without an element, marking the start and the end of the list. figure 2 shows a plain graph encoding of the structure of figure 1. figure 3 shows an example rule that will result in the winner of an event being moved to the start of the list. the figure shows the left hand side and right hand side of the rule; the connecting morphisms are implicit in the positioning of the nodes. the unlabelled nodes are meant to match any node in the graph; in particular, they may match head or slot nodes. a solution that works for properly typed graphs requires inheritance. note that this only works under the assumption that non-injective matches are allowed. an important observation is that the issues discussed above are exactly those one encounters while programming with lists. this goes against the idea that graph transformation provides an 3 / 12 volume 29 (2010) on a graph formalism for ordered edges event 5000m head slot slot slot event 10000m slot part davis slot slot part fabris headhead part tuitert event 1500m part kramer slothead next parts next next elem head elem next elem head elem next elemhead next head next head next parts head head head next elem parts elem head next figure 2: plain graph representation of the structure in figure 1 parthead slot event next next head elem next parts winner head event slot parthead headnext next next head winnerparts elem figure 3: plain graph rule moving the winner of an event to the top of the list. abstract, declarative way of manipulating structures. if the graph model is used for the design of a software system, from which an implementation is to be derived, then the graph representation choices will influence the implementation, possibly in unintended ways. for instance, the encoding in figure 2 makes it unnatural to choose an array-based implementation. 2.2 list edges the proposal in this paper is to enrich graphs with explicit support for lists, avoiding both the overhead and the “programming” nature of the plain graph encoding. we do this by extending the notion of edges: rather than binary edges with a single source node and a single target node, we propose to use list edges of which the target is a sequence of nodes. thus, list edges are somewhat like hyperedges in that they may have different numbers of tentacles: however, hyperedges typically have a fixed number of tentacles (called the arity) determined by their labels, which is not the case for list edge arity. for instance, figure 1 is a straightforward visualisation of a graph with list edges from the event nodes to different sequences of part nodes. the string of “knots” in the edge gives the order of the elements in the list; the arrows from the knots point to the actual elements. proc. gt-vmt 2010 4 / 12 eceasst part event winner parts • • • part event winner parts • • • • • figure 4: list graph rule moving the winner of an event to the top of the list. part kramer event 1500m part davis part fabris event 5000m part tuitert • parts • • • winner winner • parts • • part kramer event 1500m part davis part fabris event 5000m part tuitert • parts • • • winner winner • parts • • figure 5: applying figure 4 twice to the left hand side graph yields the right hand side graph the real innovation, however, does not lie in the graphs but in the rules. for these, we introduce a new type of node, called list nodes, which will only appear in rules and stand for arbitrary sequences of nodes from the host graph. list nodes can only occur as edge targets, never as sources. graph morphisms are extended by matching list nodes either to a sequence of plain nodes, or to a single list node. this is extended to list edges in the natural way. for instance, figure 4 shows the same rule as figure 3, but this time for list graphs. the ‘doubled’ nodes are list nodes. the parts edge in the left hand side matches any list edge in the host graph from an event node, pointing to an arbitrary sequence of nodes (matched by the upper list node of the lhs), followed by the part-node that the winner-edge points to, followed by another arbitrary sequence of nodes (matched by the lower list node of the lhs). the effect of the rule is to delete this list edge and create a new one, in which the part-node and the first sub-sequence are swapped. this has the effect of moving the part-node to the top of the list. an example of the application of this rule is shown in figure 5. the initial state is the same as in figure 1, but now with kramer and tuitert indicated as winners for the 1500m and 5000m respectively. the rule can be applied twice, resulting in the right hand side graph. 3 formalisation in this section, we will show that lists can be incorporated in graph theory in a sound manner. for this purpose, we extend a standard representation of multi-sorted graphs with list nodes and list edges. we define an admissible subclass of m-morphisms, and prove that pushouts along m-morphisms exist and are partial vk squares. using [hei09], this implies that sufficient hlr properties hold. we will use double pushouts (dpo) for the formalisation of graph rules. first, we extend a standard (v, e, src, tgt, lab) representation of multi-sorted graphs, by: (1) splitting v into v̂ (normal nodes) and v (list nodes); and (2) changing the result of tgt from v (a 5 / 12 volume 29 (2010) on a graph formalism for ordered edges single node) to v ? (a sequence of nodes, may be empty). in other words, we add list nodes and replace one-to-one (plain) edges with one-to-many (list) edges: definition 1 (multi-sorted list graphs) let g = (v̂ ,v , e, src, tgt, lab) be a multi-sorted list graph, where: ◦ v̂ and v are the sets of plain nodes and list nodes respectively (let v denote v̂ ∪v ) ◦ e is the set of (list) edges ◦ v̂ , v and e are disjoint ◦ src : e → v̂ is the function that yields the source node of an edge ◦ tgt : e → v ? is the function that yields the sequence of target nodes of an edge ◦ lab : e → l is the labelling function (assuming a fixed set of labels l) as usual, we will use graph homomorphisms as arrows in our category. a homomorphism f : g → h is a structure preserving mapping of nodes and edges. in our category, three cases are distinguished: (1) plain nodes are mapped to plain nodes; (2) list nodes are mapped either to list nodes or to sequences of plain nodes; and (3) list edges are mapped to list edges. the one-to-one mapping of list nodes will be used to restrict our graph rules, and the one-to-many mapping of list nodes will be used for the matching of a rule to a graph. for the sake of convenience, we will combine the mappings of nodes into a single function that always produces a sequence. furthermore, we will often implicitly convert a singleton sequence to its element or vice-versa; it will always be clear from the context when we do this. finally, we will write f ?v for the sequence homomorphism that is generated by fv ; that is, if fv is a function from vg to v ?h , then f ? v is the natural extension that maps v ? g to v ? h . definition 2 (homomorphisms) let g = (v̂g,v g, eg, srcg, tgtg, labg) and h = (v̂h ,v h , eh , srch , tgth , labh ) be multi-sorted list graphs. let f = ( fv , fe) with fv : vg → v ?h and fe : eg → eh map the nodes and edges of g to h. then, f is a homomorphism when the following conditions hold: ◦ for all vg ∈ v̂g there exists a vh ∈ v̂h such that fv (vg) = 〈vh〉 ◦ for all vg ∈v g, there either exists a vh ∈v h such that fv (vg) = 〈vh〉, or fv (vg) ∈ v̂ ?h ◦ labh ◦ fe = labg ◦ srch ◦ fe = fv ◦srcg ◦ tgth ◦ fe = f ?v ◦tgtg the composition of two homomorphisms can now easily be defined by means of a combination of function composition and natural extension to sequences. by construction, it follows that the result is a homomorphism as well, which allows us to define list graphs as a category. definition 3 (composition of homomorphisms) if f = ( fv , fe) : g → h and g = (gv , ge) : h → i are homomorphisms on list graphs, then g◦ f is defined by (g?v ◦ fv , ge ◦ fe). definition 4 (list graphs as a category) the category gl consists of list graphs (definition 1) as objects, homomorphisms (definiproc. gt-vmt 2010 6 / 12 eceasst tion 2) as arrows and composition as in definition 3. the identity arrows are the homomorphisms that are pairs of identity functions. next, we define a suitable subclass of m-morphisms and show that it is admissible [cl03]. in this paper, we present a part of the proof only; the full proof can be found in [mrh10]. definition 5 (m-morphisms in gl) a monomorphism f = ( fv , fe) : g → h in gl belongs to the subclass m if for all vg ∈ v g there exists a vh ∈ v h such that fv (vg) = 〈vh〉. in other words: a m-morphism does not perform matching of list nodes to sequences, but maps them one-to-one to list nodes only. theorem 1 (m is admissible) the subclass m is admissible: m contains the identity morphisms, gl has pullbacks along m-morphisms and the opposing morphism in the pullback diagram is a m-morphism itself. proof (sketch). ◦ identity morphisms always map list nodes to themselves, and are therefore m-morphisms. ◦ pullbacks are constructed as follows. suppose that b −b→ a ←c− c, and that b is a m-morphism. let ab be the subgraph of a that is formed by the image of b. because b is a m-morphism, b is isomorphic to ab. construct the largest subgraph d ⊆c such that c maps all elements of d to elements of ab. then, d is the pullback of b −b→ a ←c− c, with d → c by means of idd and d → b by means of z◦c, where z is the isomorphism between ab and b. ◦ the opposing morphism is idd, which is a m-morphism. next, we show that gl also has pushouts along m-morphisms. again, we we present a part of the proof only; the full proof can be found in [mrh10]. theorem 2 (pushouts) gl has pushouts along m-morphisms. proof (sketch). ◦ pushouts are constructed as follows. suppose that b ←b− a −c→ c, and that b is a m-morphism. assume that b and c are disjoint (if not, find isomorphic graphs that are disjoint). let ba be the subgraph of b that are in the image of b. because b is an m-morphism, a is isomorphic to ba. then, d = c∪(b\ba) is the pushout of b ←b− a −c→ c, with c → d by means idc and b → d by means of idb\ba ∪(c◦z), where z is the isomorphism between ba and a. note that when edges are added by b (i.e. they appear in b\ba), then the sources and targets of these edges have to be transformed by means of idb\ba ∪(c◦z) as well. ◦ note that the opposing morphism is again an identity (idc), and is therefore a m-morphism. the next step is to show that the constructed pushouts form partial vk squares [hei09]. this is a more involved proof, for which we refer to the technical report [mrh10] completely. here, we present the definition of partial vk squares only: definition 6 (partial vk squares) a pushout ad b c is a partial van kampen square if for each commutative cube on top of the pushout as shown in figure 6 on the left, which has pullback as back faces such that both b 7 / 12 volume 29 (2010) on a graph formalism for ordered edges b c a d b′ c′ a′ d′ f m a b c f ′ m′ n′ n d g′ g ⇒   b ca d b′ c′ a′ d′ f m a b c f ′ m′ n′ n d g′ g ⇔ b c a d b′ c′ a′ d′ f m a b c f ′ m′ n′ nd g′ g   figure 6: partial van kampen square property and c are m-morphisms, its top face is a pushout if and only if the front faces are pullback and the morphism d is an m-morphism (as illustrated in figure 6 on the right). theorem 3 (pushouts are partial vk squares) the pushouts in gl are partial vk squares. proof: see technical report [mrh10]. in [hei09], heindel has shown that the important hlr properties hold in a category with admissible m-morphisms, pushouts along m-morphisms and partial vk squares. therefore, the combination of theorems 1, 2 and 3 ensures that graph rewriting is well-behaved in our category gl, using the following standard definition of double pushout (dpo) rewriting: definition 7 (double pushout rewriting) a graph production l ←l− k −r→ r is applied to a host graph g with the following procedure: ◦ find a morphism m that maps l to g, and a morphism k that maps k to d such that the pushout of k −l→ l and k −k→ d is g (with m). ◦ then, build the pushout of k −r→ r and k −k→ d, which is the result of applying the rule. if either of the morphisms m or k does not exist, the rule cannot be applied. the wellbehavedness shown above ensures that k is unique (if it exists). contrary to our earlier beliefs, gl is not hlr adhesive [eept06b]. this is illustrated by the cube on the right, in which v and w are plain nodes and l is a list node (and no edges occur). the arrows are inclusions, except the one that maps l to 〈v, w〉. the bottom face is a pushout, the back faces are pullbacks, but the top face is not a pushout. the cube is therefore an example of a pushout that is not a vk square. ∅ {v} {w} {v, w} ∅ ∅ ∅ {l} unfortunately, the current definitions, although sound, still give rise to some strange behaviour. suppose that p = (l ← k → r) is a production. then: • if r contains list nodes that have no counterpart in k, then the application of p introduces list nodes in the host graph. this is undesirable, because a list node in a normal graph has no meaning; a list node only makes sense in a rule. • conversely, if l contains list nodes that have no counterpart in k, then p can never be applied to graphs that do not contain list nodes. this is due to the pushout construction (see theorem 2), which copies l\k in the host graph. proc. gt-vmt 2010 8 / 12 eceasst event rank event • parts rank copy event part parts • copy • event part copy parts • • event • copy event start build finish figure 7: list graph rules creating a reversed parts list out of a rank list. we will disallow this strange behaviour by demanding that both the morphisms in a production must be surjective with respect to list nodes, which ensures that l and r cannot contain list nodes that do not have a counterpart in k. definition 8 (surjective m-morphisms) a m-morphism f = ( fv , fe) : g → h in gl is surjective if for all vh ∈ v h there exists a vg ∈v g such that fv (vg) = 〈vh〉. definition 9 (productions in gl) for graph rewriting in the category gl, only productions p = (l ←l− k −r→ r) are allowed in which both l and r are surjective m-morphisms. it turns out that l and r being surjective is not only a necessary, but even a sufficient condition for ensuring that rules do not introduce list nodes. a proof of this property can again be found in the technical report [mrh10]. this implies that graph rewriting in our category gl always transforms normal graphs (i.e. without list nodes) to normal graphs. 4 list reversal we show some more applications of list graph transformations, inspired by the setting of section 2. in particular, we show how we can obtain a participants list, parts, from a ranking list, rank, by copying and reversing the list. the entire behaviour is specified by the rules in figure 7. • the start rule copies the rank list into a copy list, and creates an empty parts list. note that this is a “shallow” copy: the elements are not copied but shared among the lists. • the build rule repeatedly removes the last element from the copy list and appends it to the parts list. by applying this rule as long as possible, eventually the copy list will be empty, at which point the parts list contains all the elements of the original copy list, and hence of the rank list, in reverse order. • the finish rule deletes the empty copy list, completing the reversal process. note that this rule is only applicable if the copy list is indeed empty. figure 8 shows a sequence of applications of these rules. 9 / 12 volume 29 (2010) on a graph formalism for ordered edges part kramer part fabris event 5000m part davis rank • • • −start−−→ part kramer part fabris event 5000m part davis parts • copy • • • rank • • • −build−−→ part kramer part fabris event 5000m part davis parts • copy • • rank • • • −build−−→ part kramer part fabris event 5000m part davis parts • • copy • rank • • • −build−−→ part kramer part fabris event 5000m part davis parts • • • copy • rank • • • −finish−−→ part kramer part fabris event 5000m part davis parts • • • rank • • • figure 8: example production sequence for the rules in figure 7. 5 conclusion in this section, we look back on what we have achieved, and list the good and bad points. we also briefly discuss related work and future extensions. 5.1 evaluation we have defined list graphs in order to directly capture ordered structures. we have shown that encoding such structures into plain graphs is awkward and, worse, introduces programming-like structures that break the inherent abstraction of graph-based models. in contrast, the construction and manipulation of list graphs is much more abstract and results in smaller, more intuitive graphs and rules. we have shown that list graphs fit into the theory of algebraic graph rewriting, and so the cost of the more complex graph formalism is low, at least on the level of theory. on the downside, the way lists are manipulated on the theoretical level is not attractive from an implementation point of view. list edges are deleted and created as a whole, which, when taken literally, would mean that entire lists are discarded and constructed every time a single element is added or deleted. an implementation should instead recognise and efficiently deal with frequently occurring patterns of list usage. a first attempt is to identify re-use of list edges with a static analysis of stable nodes and edges, but it is yet unclear how this can be generalised. it may be remarked that our lists break the usual symmetrical treatment of edge sources and targets, since list nodes may only occur at an edge target. in this regard, we have been led by the intended application of the enriched formalism. from the theoretical perspective there is no reason to forbid list nodes at edge sources: our theory smoothly extends to standard hyperedges (keeping our special notion of morphism), which do not have a distinguished source node at all. proc. gt-vmt 2010 10 / 12 eceasst part length=i-1event pos=i new parts • • part length=i-1event pos=i parts • • • figure 9: list graph rule inserting an element at a specified position. 5.2 related work as far as we have been able to determine, there is essentially no prior work on enriching the basic graph formalism with lists. on a more pragmatic level, however, many tools offer ways to deal with ordered structures or associations, if only by suggesting a default encoding or syntactic sugar. for instance, fujaba reflects programming structures such as lists and arrays into the rules, and provide notations to traverse them conveniently (see [mz04]). fujaba’s handling of ordered edges is formalised in [zün01]. for viatra2 it is suggested in [vb07] to use relations over relations to encode ordering. in general it is difficult to find information about such pragmatic solutions. remotely related are extensions to deal with parallel or amalgamated rule applications (e.g., [tae97]), since in this setting the rules also have nodes that can be mapped to more than one graph node (a prime instance are the set nodes of progres, see [sch97]). however, the connection stops there: the purpose and technical contribution of this work is entirely different. 5.3 future work so far, the concepts in this paper only exist in theory. the proof of their usability can only come through an implementation. the natural way to go is to extend our research vehicle groove (see [ren04]) to list graphs. however, this will require a major refactoring to generalise to hyperedges — quite apart from the fact that groove implements spo and not dpo rewriting. instead, we first plan to use these ideas to define a suitable transformation language in the project charter 1, in the context of which this work has been carried out. for this project we will provide a tool that compiles graph transformation systems to java source code which accesses and manipulates the actual graphs through a predefined api. since ordered lists and arrays are a common feature in the graphs we will have to deal with, it is imperative to have a suitable, declarative way to specify their transformation. a theoretical extension that would add quite a bit of power to the formalism, and make it even more generally usable, is indexing. currently there is no way to specify or reason about the position of an element in a list. we conjecture that this requires only a minor extension, namely to add a default unmodifiable length attribute to all list nodes. morphisms then have to respect the length of list nodes, in the following way: if a morphism maps a list node to another list node, then the value of the length attribute should remain unchanged, whereas if the image is a sequence of plain nodes, the value of the length attribute should equal the actual length of the sequence. for instance, figure 9 specifies that a part-node should be inserted at index i. 1 see http://charterproject.ning.com/. 11 / 12 volume 29 (2010) http://charterproject.ning.com/ on a graph formalism for ordered edges bibliography [cl03] j. r. b. cockett, s. lack. restriction categories ii: partial map classification. theoretical computer science 294(1/2):61–102, 2003. [dhp02] f. drewes, b. hoffmann, d. plump. hierarchical graph transformation. j. comput. syst. sci. 64(2):249–283, 2002. [eept06a] h. ehrig, k. ehrig, u. prange, g. taentzer. fundamental theory for typed attributed graphs and graph transformation based on adhesive hlr categories. fundam. inform. 74(1):31–61, 2006. [eept06b] h. ehrig, k. ehrig, u. prange, g. taentzer. fundamentals of algebraic graph transformation. springer, 2006. [hab92] a. habel. hyperedge replacement: grammars and languages. springer-verlag new york, inc., 1992. [hei09] t. heindel. a category theoretical approach to the concurrent semantics of rewriting. phd thesis, universität duisburg-essen, 2009. [mrh10] m. de mol, a. rensink, t. heindel. a graph formalism for ordered edges. 2010. technical report, university of twente, the netherlands. to appear. preliminary version available at http://wwwhome.cs.utwente.nl/∼molm/list techreport.pdf. [mz04] t. maier, a. zündorf. yet another association implementation. in giese et al. (eds.), proceedings 2nd international fujaba days. pp. 67–72. 2004. available at http://www.fujaba.de/fileadmin/informatik/fujaba/resources/publications/ fujaba days/tr-ri-04-253.pdf. [pad93] j. padberg. survey of high-level replacement systems. 1993. technical report, technische universität berlin. see http://citeseer.ist.psu.edu/padberg93survey.html. [ren04] a. rensink. the groove simulator: a tool for state space generation. in pfaltz et al. (eds.), applications of graph transformations with industrial relevance (agtive). lecture notes in computer science 3062, pp. 479–485. springer, 2004. [sch97] a. schürr. programmed graph replacement systems. in rozenberg (ed.), handbook of graph grammars and computing by graph transformations, volume 1: foundations. pp. 479–546. world scientific, 1997. [tae97] g. taentzer. parallel high-level replacement systems. tcs 186(1-2):43–81, 1997. [vb07] d. varró, a. balogh. the model transformation language of the viatra2 framework. sci. comput. program. 68(3):214–234, 2007. [zün01] a. zündorf. rigorous object oriented software development. 2001. habilitation thesis. universität paderborn. proc. gt-vmt 2010 12 / 12 http://wwwhome.cs.utwente.nl/~molm/list_techreport.pdf http://www.fujaba.de/fileadmin/informatik/fujaba/resources/publications/fujaba_days/tr-ri-04-253.pdf http://www.fujaba.de/fileadmin/informatik/fujaba/resources/publications/fujaba_days/tr-ri-04-253.pdf http://citeseer.ist.psu.edu/padberg93survey.html introduction motivation plain graph encoding list edges formalisation list reversal conclusion evaluation related work future work decidable race condition and open coregions in hmsc electronic communications of the easst volume 29 (2010) proceedings of the ninth international workshop on graph transformation and visual modeling techniques (gt-vmt 2010) decidable race condition and open coregions in hmsc vojtěch řehák petr slovák jan strejček loïc hélouët 12 pages guest editors: jochen küster, emilio tuosto managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst decidable race condition and open coregions in hmsc vojtěch řehák1∗ petr slovák1† jan strejček1‡ loïc hélouët2 1faculty of informatics, masaryk university, brno, czech republic 2inria/irisa, rennes, france abstract: message sequence charts (mscs) is a visual formalism for the description of communication behaviour of distributed systems. an msc specifies relations between communication events with partial orders. a situation when two visually ordered events may occur in any order during an execution of an msc is called a race and is usually considered as a design error. while there is a quadratic time algorithm detecting races in a finite communication behaviours called basic message sequence charts (bmscs), the race detection problem is undecidable for high-level message sequence charts (hmscs), an msc formalism describing potentially infinite sets of potentially unbounded behaviours. to improve this negative situation for hmscs, we introduce two new notions: a new concept of race called trace-race and an extension of the hmsc formalism with open coregions, i.e. coregions that can extend over more than one bmsc. we present three arguments showing benefits of our notions over the standard notions of race and hmsc. first, every trace-race-free hmsc is also race-free. second, every race-free hmsc can be equivalently expressed as a trace-race-free hmsc with open coregions. last, the trace-race detection problem for hmsc with open coregions is decidable and pspace-complete. finally, the proposed extension of coregions allows to represent in a visual fashion whether an arbitrary number of racing events in the usual msc formalism are concurrent or not. keywords: hmsc; race condition; trace-race condition; open coregions; 1 introduction message sequence chart (msc) [itu04] is a popular visual formalism for specification of distributed systems behaviours (e.g. communication protocols or multi-process systems). its simplicity and intuitiveness come from the fact that msc describes only exchange of messages between system components, while other aspects of the system (e.g. content of the messages, computation steps) are abstracted away. even such an incomplete model can indicate serious errors in the designed system. this paper focuses on a common error called race condition. mscs are based on composition of simple chronograms called basic message sequence charts (bmscs). a bmsc consists of a finite number of processes and events. processes are represented by vertical lines, and all events executed by some process are located on its lifeline ∗ partially supported by czech science foundation (gačr), grants no. 201/08/p459 and no. p202/10/1469. † partially supported by the research centre “institute for theoretical computer science (iti)”, project no. 1m0545. ‡ partially supported by czech science foundation (gačr), grant no. 201/08/p375, and ministry of education of the czech republic, project no. msm0021622419. 1 / 12 volume 29 (2010) decidable race condition and open coregions in hmsc p q r figure 1: a bmsc containing a race p q r figure 2: a similar bmsc containing a race s1 s2 r2 r1 p q r figure 3: a bmsc containing a race between r1, r2 and ordered from top to bottom. messages are represented by an arrow from a sending event to a receiving event. total orderings of events on lifelines and messages form a visual order <, which provides graphically information on the respective ordering of events. however, the visual order can not always be enforced by the architecture of the modelled system. in addition to the visual order, there exists a causal order �, that is weaker than <. intuitively, events e, f are in causal order e � f , if the bmsc enforces that e always precedes f . there are several definitions of causal order depending on the settings of the modelled system and semantics of the model. for example, if one process sends two messages to another process, the corresponding receive events are causally ordered if and only if the considered message transport protocol has the fifo property: two messages sent from one process to another are always received in the same order. in this paper, we assume that every process has one unbounded buffer for all incoming messages and that the message transport protocol satisfies the fifo property. a bmsc contains a race condition (or simply race) [ahp96] if there are two visually ordered events that are not causally ordered (i.e. they can actually occur in an arbitrary order). for example, figure 1 depicts that the process q receives a message from r followed by a message from p. as processes and communication in bmscs are always asynchronous, the messages can be also received in the opposite order as shown in figure 2. in both figures, the two receive events are in race as they are ordered visually but not causally. races in bmsc description should be considered as a design error, as they exhibit discrepancies between the intended ordering designed in a bmsc, and the ordering that a real implementation of this bmsc would enforce. races in a bmsc can be detected in quadratic time [ahp96]. while a bmsc describes only a single and finite communication scenario, its extension called high-level message sequence chart (hmsc) [rgg96, ahp96] can describe more complex interactions, with iterations and alternatives between several scenarios. an hmsc is a finite state transition system where each state is labelled by a bmsc or a reference to another hmsc. in the sequel, we will only consider hmscs labelled by bmscs. each run (i.e. a path starting in the initial state and ending in a final state) of an hmsc can be understood as a single bmsc, which is a concatenation of the bmscs labelling the states along the run. hence, an hmsc represents a potentially infinite set of bmscs of unbounded size. the definition of race was extended to hmscs in [mp99]. roughly speaking, an hmsc h has a race if some bmsc represented by h contains a race and h does not represent any bmsc where the two racing events are defined with the opposite visual order. unfortunately, the problem whether a given hmsc contains a race is undecidable [mp99, itu04]. in this paper, we propose an alternative definition of race for hmscs called trace-race. intuitively, an hmsc has a trace-race if some bmsc represented by h contains a race. clearly, proc. gt-vmt 2010 2 / 12 eceasst every trace-race-free hmsc is also race-free but not vice versa. to improve the expressive power of trace-race-free hmscs, we extend the hmsc formalism with open coregions. a coregion is a standard part of the msc formalism that allows some events on the same process in a bmsc to be visually unordered. in particular, coregions can be used to visually order only causally related events (hence making concurrency a visual property). while this application of coregions can remove all races in bmscs, it is not sufficient for removing all races in hmscs. an open coregion is basically a coregion spread over several bmscs. we present a transformation of an arbitrary race-free hmsc into an equivalent trace-race-free hmsc with open coregions, where equivalence means that the two hmscs have the same linearizations. finally, we show that the problem whether a given hmsc with open coregions contains a trace-race is decidable and pspace-complete. in fact, our algorithm is polynomial for hmscs with fixed number of processes and gates. for definitions of gates and linearizations see sections 2 and 3, respectively. the rest of the paper is organized as follows. section 2 recalls the definitions of bmscs, hmscs, and race condition for bmscs. the race and trace-race conditions for hmscs are defined and compared in section 3. section 4 is devoted to the translation of race-free hmscs into equivalent trace-race-free hmscs. the decidability and complexity of the trace-race detection problem is discussed in section 5. section 6 briefly summarizes benefits of the presented notions. due to the space limitations, we present only crucial lemmata and theorems accompanied by explanations of basic ideas. proofs with all technical details can be found in [řssh09]. 2 preliminaries the following definitions omit some features of mscs given by the itu standard [itu04], e.g. atomic actions, labelling of messages with names, timers etc. however, these restrictions are quite common, and our results can be extended to mscs with atomic actions and message labelling using the technique of [dgh08]. 2.1 bmscs with (open) coregions, gates, and general ordering the basic concepts of bmscs are described in section 1. in the visual representation of a bmsc, processes are depicted as vertical lines and messages are represented by arrows between these lines. events located on the same process line are visually ordered from top to bottom. a process line may contain segments called coregions delimiting subsets of events. events in a coregion are a priori not in visual order, but they can be visually ordered using a general ordering relation. (this relation need not be a partial order). coregions are visually represented by rectangles and general ordering by dashed arrows between pairs of ordered events (see figure 3). in existing msc formalisms, coregions are limited to finite set of events located in a single bmsc. we extend the definition of bmscs with open coregions and gates. these features allow coregions of arbitrary size, spread over several concatenated bmscs. gates enable events of different bmscs to be generally ordered within the final joined coregion. similar ideas for connecting orders using gates or predicates was already proposed for instance in [pra86, gh07]. a coregion can be open on top (top-open coregion), on bottom (bottom-open coregion), or open on both sides. all processes use a common gate name space g. for each process p, we 3 / 12 volume 29 (2010) decidable race condition and open coregions in hmsc define the sets of top gates p.g ={p.g |g∈g} and bottom gates p.g ={p.g |g∈g} located on process p. given a bmsc with a set of processes p, we set p.g = ⋃ p∈p p.g and p.g = ⋃ p∈p p.g to be the sets of all top and bottom gates in this bmsc, respectively. we also extend the general ordering to range over both events and gates within an open coregion. definition 1 let g be a finite gate name space. a bmsc over g is a tuple m = (p, es, er, p,{ 1 ⇒ currentmonth′ = currentmonth − 1 ∧ currentyear′ = currentyear currentmonth = 1 ⇒ currentmonth′ = 12 ∧ currentyear′ = currentyear − 1 vdates′ = alldates ⊲ (currentmonth′ . . currentmonth′) shownextmonth ∆calendar allevents′ = allevents currentmonth < 12 ⇒ currentmonth′ = currentmonth + 1 ∧ currentyear′ = currentyear currentmonth = 12 ⇒ currentmonth′ = 1 ∧ currentyear′ = currentyear + 1 vdates′ = alldates ⊲ (currentmonth′ . . currentmonth′) a series of designs and prototypes of the ui for simplecalendar were developed following a user-centred design process. at the end of the design iterations the prototypes given in figures 1 and 2 were accepted as the basis for the application’s ui. we create a link between the formal specification of the system and the user interface design by creating presentation models and presentation and interaction models (pims) [br06], proc. fmis 2009 4 / 16 eceasst figure 1: main month view for simple calendar figure 2: subsidiary views for simple calendar 5 / 16 volume 22 (2009) ui-design driven model-based testing [br08a]. the presentation model gives a description of the interface designs based on the interactive elements (widgets) of the design. each widget is described by way of a tuple consisting of a name, a category (which determines the type of interactive behaviour it exhibits) and a collection of behaviours associated with the widget. behaviours either relate to system functionality (i.e. provide a way of interacting with the underlying system functionality) or to interface functionality, e.g. opening new dialogues, and are prefixed by s or i respectively. the ui for the entire system is described by a single presentation model which consists of component models for each of the distinct windows and dialogues. for the simplecalendar designs this is: simplecal is mainview : dayview : addview : editview mainview is (quitbutton, actioncontrol, (quit)) (prevarrow, actioncontrol, (s prevmonth)) (nextarrow, actioncontrol, (s nextmonth)) (daydisplay, actioncontrol, (i dayview)) dayview is (addbutton, actioncontrol, (i addview)) (eventlist, actioncontrol, (s removeevent, i editview)) (backbutton, actioncontrol, (i mainview)) addview is (titleentry, entry, ()) (startentry, entry, ()) (endentry, entry, ()) (cancelbutton, actioncontrol, (i dayview)) (savebutton, actioncontrol, (s addevent, i dayview)) editview is (titleentry, entry, ()) (startentry, entry, ()) (endentry, entry, ()) (cancelbutton, actioncontrol, (i dayview)) (savebutton, actioncontrol, (s updateevent, i dayview)) we link the ui design models and the specification by creating a presentation model relation (pmr) between each s behaviour of the presentation model and operations of the specification, which for our example is simplecal pmr: {s prevmonth 7→ showpreviousmonth, s nextmonth 7→ shownextmonth, s removeevent 7→ deleteevent, s updateevent 7→ editevent, s addevent 7→ addevent} the third model, the pim, denotes the dynamic behaviour of the ui by describing how each individual dialogue or window is reached by way of i behaviours. each component presentation model is associated with a state of the pim, and i behaviours of the relevant model act as labels proc. fmis 2009 6 / 16 eceasst simplecalui mainview i_dayview dayview i_addview i_editview i_monthview i_dayview i_dayview addview editview figure 3: simplecal pim on transitions between states, and hence, as intended, are behaviours which are purely interface behaviours and so move us around the interface. the combination of the system specification and the ui models (presentation models, pim and pmr) provides a formal description of the entire system. we have previously shown how we can use this information as a way of ensuring correctness of the the proposed system [br08a] and also as the basis for refinement [br08b]. in this paper, however, we will use the models to derive tests which can then be run on an implementation of the system. the intention is that the models give a description of how we require the implemented system to behave and by using them to generate tests we hope to find errors where the implementation deviates from this behaviour. in the next section we show how the tests are derived. 3 deriving the tests the presentation models describe the interactive elements of the ui and their required behaviours. that is, they describe the functionality that is accessible to a user who interacts with the ui. the pim extends this to describe which behaviours are available in different states of the ui and how a user can move between these states. the testing approach we are proposing will ensure that both the behaviours, and the availability of the behaviours, are provided by the implementation so that we are sure that it satisfies the models. the pim also describes modality: each independent state of the pim is modal so we include this as a condition which should be tested. ui-based testing is often goal-driven. tasks are defined (or taken from earlier task analysis work) and then sequences of events and user interaction sequences are constructed to satisfy these goals (see for example [bel01, wa00]). in contrast, the tests we derive use the definitions given within the models as their basis. these tests will be abstract (in that they are expressed at the level of, and in the language of, the models) and can then be instantiated in any language or using any testing framework as required. this will often be dependant on the choice of target implementation language. in section 4 we give an example of one way of instantiating the abstract tests for an implementation of simplecalendar in java. we begin by considering the dynamic behaviour of the ui. this is defined by i behaviours in 7 / 16 volume 22 (2009) ui-design driven model-based testing the presentation models on transitions of the pim showing how a user can move between states of the ui. in the pim given in figure 3 there are four states to be considered, with the initial state being mainview (denoted by the double ellipse). for all of the defined behaviours we will test two things: firstly that a widget exists in a given state which provides the required behaviour; and secondly that the behaviour is functionally correct. so, for example, the presentation model for mainview describes an actioncontrol called daydisplay which has a behaviour i dayview. from the pim we determine that this behaviour should cause the ui to change from the state mainview (i.e. a state where all of the defined behaviours of mainview are available) to the state dayview (i.e. a state where all of the defined behaviours of dayview are available). so first we will test that there is a widget available in mainview called daydisplay and then we will ensure that when interaction occurs the ui behaves as required, that is it changes from mainview to dayview. during the testing process, in order to determine that we are in a correct state, we use the defined behaviours for that state. for example, the state dayview is a state of the ui where the behaviours of the dayview presentation model are available (a user has access to widgets with the behaviours i addview, s removeevent, i editview and i monthview). the i behaviours and associated widgets for each of the states in our model are: mainview : {daydisplay 7→ i dayview} dayview : {addbutton 7→ i addview, eventlist 7→ i editview, backbutton 7→ i monthview} addview : {cancelbutton 7→ i dayview, savebutton 7→ i dayview} editview : {cancelbutton 7→ i dayview, savebutton 7→ i dayview} using this information we derive our first set of tests used to ensure that the relevant widgets exist in the appropriate states. to ensure that a widget is available for a user to interact with we must not only test that it exists in the given state, but also that it is visible and active. we describe the tests using first-order logic (which might be replaced by a table to show which predicates hold for which values in each state if that would be more suitable for various audiences) as follows: uistate(mainview) ⇒ widget(daydisplay) ∧ visible(daydisplay) ∧ active(daydisplay) ∧ hasbehaviour(daydisplay, i dayview) uistate(dayview) ⇒ widget(addbutton) ∧ visible(addbutton) ∧ active(addbutton) ∧ hasbehaviour(addbutton, i addview) uistate(dayview) ⇒ widget(eventlist) ∧ visible(eventlist) ∧ active(eventlist) ∧ hasbehaviour(eventlist, i editview) uistate(dayview) ⇒ widget(backbutton) ∧ visible(backbutton) ∧ active(backbutton) ∧ hasbehaviour(backbutton, i mainview) uistate(addview) ⇒ widget(cancelbutton) ∧ visible(cancelbutton) ∧ active(cancelbutton) ∧ hasbehaviour(cancelbutton, i dayview) uistate(addview) ⇒ widget(savebutton) ∧ visible(savebutton) ∧ active(savebutton) ∧ hasbehaviour(savebutton, i dayview) uistate(editview) ⇒ widget(cancelbutton) ∧ visible(cancelbutton) ∧ active(cancelbutton) ∧ hasbehaviour(cancelbutton, i dayview) uistate(editview) ⇒ widget(savebutton) ∧ visible(savebutton) ∧ active(savebutton) ∧ hasbehaviour(savebutton, i dayview) (the predicates here have the obvious (from their names) meaning, for now. they will be given a formal meaning by associating them with computed properties (via pieces of code) later on.) next we ensure the modality of each state of the pim (note that it is not necessary to put a proc. fmis 2009 8 / 16 eceasst modality requirement on the initial state, mainview): uistate(dayview) ⇒ modal(dayview) uistate(addview) ⇒ modal(addview) uistate(editview) ⇒ modal(editview) in order to derive tests for the system functionality we similarly identify the widgets with s behaviours and ensure that each of the widgets exist and that they have the required behaviours. when we come to instantiate the tests we can use the pmr to identify the specified operation which relates to the behaviour and then use the specification to determine the functionality which must be satisfied when the widget is interacted with. the functional tests we derive from the models are, therefore, as follows: uistate(mainview) ⇒ widget(quitbutton) ∧ visible(quitbutton) ∧ active(quitbutton) ∧ hasbehaviour(quitbutton, quit) uistate(mainview) ⇒ widget(prevarrow) ∧ visible(prevarrow) ∧ active(prevarrow) ∧ hasbehaviour(prevarrow, s prevmonth) uistate(mainview) ⇒ widget(nextarrow) ∧ visible(nextarrow) ∧ active(nextarrow) ∧ hasbehaviour(nextarrow, s nextmonth) uistate(dayview) ⇒ widget(eventlist) ∧ visible(eventlist) ∧ active(eventlist) ∧ hasbehaviour(eventlist, s removeevent) uistate(addview) ⇒ widget(savebutton) ∧ visible(savebutton) ∧ active(savebutton) ∧ hasbehaviour(savebutton, s addevent) uistate(editview) ⇒ widget(savebutton) ∧ visible(savebutton) ∧ active(savebutton) ∧ hasbehaviour(savebutton, s updateevent) finally we consider the widgets which do not have associated behaviours. in order for our implementation to satisfy the requirements given in the models we must also ensure that these non-functional widgets exist and can be seen by the user. such widgets are used for a user to provide information to the system by way of inputs or to give information regarding the state of the system back to a user by way of displays. uistate(addview) ⇒ widget(titleentry) ∧ visible(titleentry) ∧ active(titleentry) uistate(addview) ⇒ widget(startentry) ∧ visible(startentry) ∧ active(startentry) uistate(addview) ⇒ widget(endentry) ∧ visible(endentry) ∧ active(endentry) uistate(editview) ⇒ widget(titleentry) ∧ visible(titleentry) ∧ active(titleentry) uistate(editview) ⇒ widget(startentry) ∧ visible(startentry) ∧ active(startentry) uistate(editview) ⇒ widget(endentry) ∧ visible(endentry) ∧ active(endentry) this is the full set of abstract tests we derive from the models for the simplecalendar application. they define all of the conditions on an implementation. the tests provide coverage criteria, we know what we want to test and refer to the fixed properties of the ui which have been given initially within the ui design artefacts (the prototypes of figures 1 and 2 in this example). when we instantiate the tests we will see that we may need to define variables in some instances which are subject to the usual testing considerations of boundaries and choice of values. we discuss this further in the next section and show how we use the current visible state of the ui from a user’s perspective to help with these choices. in the next section we discuss how we instantiated the tests for a java implementation of simplecalendar and give some positive and negative results of the testing process. 9 / 16 volume 22 (2009) ui-design driven model-based testing 4 instantiating and running the tests having shown how we can derive a set of abstract tests from formal models of ui design artefacts we now give an example of instantiating and running these tests. the simple calendar application has been implemented in java and we have used the fest testing framework [fes09], which is based on the principles of testng and abbot [rp07], as a way of instantiating and running the tests. while fest is intended to provide a test-driven development approach to interactive system development, its ability to replicate user interaction (by way of the underlying java robot class) makes it a suitable approach for our work. it enables us to take a user-centred approach to our testing in the manner of replicating user interaction with the system to determine correctness of response to possible interaction with the ui and we can then use the underlying support of junit to determine whether or not the system behaves as described in our abstract tests. due to the requirements of fest classes, which rely on implementation details (such as widget names etc.), we take a white-box approach to testing where we use code inspection to determine the information required for fest (as necessary). depending on how we want to test the system we might choose different ways of instantiating the tests. for example it may be enough to determine that all required behaviours of all ui states can be accessed by a user, or we might be stricter and require that if our model has two separate controls with a particular behaviour then the tests must show that two such distinct widgets exist with the required behaviour. this is the approach we have taken with this example as it adheres to our commitment to using the designs as the basis for implementation. that is, we expect everything described in the final design artefacts to become part of the implementation. just as we did when we began the test derivation process we start by considering the dynamic behaviour of i behaviours. in order to determine correctness of state we will ensure that each named state has the correct set of widgets visible to a user and available for interaction. fest uses a package of classes called fixtures which understand simulation of user events on java swing objects and verify the state of these objects. there are different classes for different types of widgets, for example a jbuttonfixture enables simulation of clicks or double clicks etc. upon an actual jbutton of an implementation (which is passed to the constructor of the fixture object). in order to test correctness of state, therefore, we create fi xtures for each frame or dialogue which instantiates one of the states given in the pim and then interrogate this to determine whether or not required widgets are present and correctly available. the following code is an example of such a test for the mainview state: mv = new framefixture(new mview()); public void mviewstate(){ mv.button("quitbutton").requirevisible(); mv.button("quitbutton").requireenabled(); mv.button("prevarrow").requirevisible(); mv.button("prevarrow").requireenabled(); mv.button("nextarrow").requirevisible(); mv.button("nextarrow").requireenabled(); mv.panel(testdate).requirevisible(); mv.panel(testdate).requireenabled(); } where “mview” is the class in our implemented system which provides the ui elements for the mainview of the application. when we call the “mviewstate()” method from within a junit test proc. fmis 2009 10 / 16 eceasst method the “mview” frame is created and run in exactly the same way as if we had launched the simplecalendar application, and the cursor can be seen moving around the ui over each widget as it identifies it in the same manner as a user moving the mouse to hover over each of the widgets. if any of the tests fail (for example if one of the widgets cannot be found or does not have the required visibility property) we get the standard junit red failure bar along with an explanation of the cause of the test failure. we create similar test methods for dayview, addview and editview and then use these as part of our i behaviour tests. we can either instantiate each abstract test individually, or combine two or more into a single test. for example we combine the modality requirement given in uistate(dayview) ⇒ modal(dayview) with the state test method for dayview by adding “dv.requiremodal();” to the state test. in order to instantiate an abstract test such as: uistate(mainview) ⇒ widget(daydisplay) ∧ visible(daydisplay) ∧ active(daydisplay) ∧ hasbehaviour(daydisplay, i dayview) we determine from the pim that a control called dayview should have the i dayview behaviour which should change the state of the system from mainview to dayview. as part of the preparation for our tests we create a framefixture called mv which allows us to simulate interaction with the ui and take us to any of the other states as required for testing. for example the fest code for the test given above is: public void mvidayviewtest(){ dialogfixture dv = mv.panel(testdate).click().dialog(testdate); dviewstate(dv); } this simulates a user clicking on a daydisplay widget (a jpanel in our implementation) which opens a new dialogue, “dv”, and we then check that this has the defined dayview state. one way of identifying widgets using fest is by using their name, and in simplecalendar we use the current date of each daydisplay panel as the name’s value. “testdate” is a variable containing the current date (as the system always starts up displaying the current month this is a suitable choice for the test variable) and so represents the name of one of the jpanel widgets in mainview. this is an example of a test which requires a variable value (a date). our choice of value for this is made based on what choices are available to a user when the system starts up, so we test based on the dates of the current month and iterate through each of the values that would be visible to the user. the range of the values chosen are then the limits of what a user has access to. we do not randomly test arbitrary dates or seek to test boundary values, such as 01/01/00, 12/12/99 etc. as these do not reflect choices the user can make in the current state. we construct tests as described above for all of the i behaviours, and when we run them one at a time we discover our first error. the dviaddviewtest(), which instantiates the abstract test: uistate(dayview) ⇒ widget(addbutton) ∧ visible(addbutton) ∧ active(addbutton) ∧ hasbehaviour(addbutton, i addview) fails, producing the error: java.lang.assertionerror: .. property’modal’ expected but was 11 / 16 volume 22 (2009) ui-design driven model-based testing when the aviewstate test is called to ensure that the resulting state after clicking the add button is correct, the modality test fails. in the implementation of simplecalendar addview has not been set as a modal dialogue and so the test fails and our error is discovered. once we have corrected this problem all of the i behaviour tests are passed. we next move onto the non-behavioural widgets, which enables us to test that the implemented ui for simplecalendar contains the required widgets for user entry and display. as there are no behaviours associated with these widgets we test them based on their category, so for the abstract test: uistate(addview) ⇒ widget(titleentry) ∧ visible(titleentry) ∧ active(titleentry) we identify the category of titleentry from the presentation model entry and then instantiate the test by checking that the widget allows user entry (we do not need to test that the widget is visible and active in the state as we have already done this as part of our state tests). using fest we simulate the user entering some string into the text field and then test that the value of the text field is the entered string: string tstring = "test text"; av.textbox("titleentry").entertext(tstring); av.textbox("titleentry").requiretext(tstring); it may seem strange to test the value of the “titleentry” text box immediately after setting it, but the “entertext” instruction does not set the value of the text box, it merely attempts to interact with it in the same way a user would, by selecting it with the mouse and then entering the keystrokes required to produce the string. if the ‘editable’ property of the text box was set to false the “entertext” instruction would be carried out (by way of mouse movement and keyboard input) but the textbox would not contain the required string and so the assertion would fail. each of the non-behavioural widgets are tested in this manner and all of the tests are passed. finally we move onto the s behaviour widget tests. in order to create these we need to identify and simulate user action on each of the widgets in each state in the same manner as for the i behaviours, and use the specified behaviour of operations related via the pmr to determine whether or not behaviour is correct. as an example consider the abstract test: uistate(mainview) ⇒ widget(prevarrow) ∧ visible(prevarrow) ∧ active(prevarrow) ∧ hasbehaviour(prevarrow, s prevmonth) just as we have done with the other widgets we need to ensure that the widgets are available and visible in the required ui state and that the behaviour is correct. in the case of the s behaviours the meaning is given by the specified operation, showpreviousmonth (described in section 2) which the s behaviour is related to via the pmr. because the s behaviours enable the user to access the system functionality (and therefore change the system state) as part of our test we should ensure that whenever a user can perform such an operation (i.e when a widget with that behaviour is available for interaction) the pre-condition of the related operation holds. this ensures that we do not expose users to the possibility of putting the system into an unexpected state. secondly we must test that the post-condition given by the invariant in the operation description holds after the interaction, i.e. that the correct operation has occurred and has left the system in the expected state. in the example we present in this paper the specification of proc. fmis 2009 12 / 16 eceasst the system is given in z [iso02] and we use standard conventions for determining preand post-conditions for operations. however, it is not a requirement that z is used, only that related operations can be identified within the given specification and then appropriate methods used to identify the requirements for testing the system state. for the prevarrow widget in the mainview ui state our test then entails the following steps: • ensure the prevarrow widget exists in the mainview state • ensure the prevarrow widget is visible and enabled in the mainview state • ensure that the pre-condition of the showpreviousmonth operation holds in mainview • ensure that the post-condition of the showpreviousmonth operation holds in mainview after interaction with the dayview widget the pre-condition of the operation schema can be calculated using standard z techniques, and can be simplified to currentmonth = 1 ∨ currentmonth ∈ 2 . . 12, which for the ui means testing that the displayed month is either january, or between february and december. the postcondition of the operation requires that we check the value of allevents is unchanged and that the visible dates are correctly determined by the new value of currentmonth which should be the month prior to the original value. for the fest testing we are only interested in the ui elements, and therefore separate the non-ui requirements (in this case the condition on allevents) into a separate test which can be run using junit independently of ui elements. this leads to the following test: public void mvsprevmonthtest(){ int cm = cal.get(calendar.month); int year = cal.get(calendar.year); string yearstring = integer.tostring(year); mv.label("monthlabel").requiretext(makemonth(cm)); int pcm = cm -1; for(int i = 0; i < 12; i++){ if(pcm == 11) yearstring = integer.tostring(year-1); if(pcm == 0) pcm = 12; string prevdate = makemonth(pcm); mv.button("prevarrow").click(); mv.label("monthlabel").requiretext(prevdate); mv.label("yearlabel").requiretext(yearstring); pcm --; } syspostconditionprevmonth(); } the line “mv.label(“monthlabel”).requiretext(makemonth(cm));” checks the pre-condition by ensuring that the value of the month label is one of the values given by the “makemonth()” utility method in the test class (which returns only values in the range january to december). the test runs through a twelve month cycle which ensures coverage of both possible post-condition cases irrespective of the start month. finally the method “syspostconditionprevmonth()” is called which is the unit test for the non-ui parts of the post-condition. as we work our way through the tests for the s behaviours we obtain an unexpected result for one of the tests. when we run the test instantiating the abstract test: 13 / 16 volume 22 (2009) ui-design driven model-based testing uistate(dayview) ⇒ widget(eventlist) ∧ visible(eventlist) ∧ active(eventlist) ∧ hasbehaviour(eventlist, s removeevent) we observe the simulated interaction, and conclude that the test should fail. we have created an event titled “dentist” for a given date, and then test that after s removeevent this event is no longer displayed in dayview or monthview. what we observe upon closure of the dayview dialogue is that the event is still displayed in monthview.the test, however, which checks the value of the label displaying event values in mainview is passed, as is the junit test of the underlying system state which determines that the event has been successfully removed from the collection of events maintained by the system. the error is caused by a lack of graphics refresh by the java virtual machine and so although the event has been correctly removed, and the label text reset to empty, the previous value remains on the screen. given that it is possible to run all of the tests we created in the background and generate a report of any errors that occur it is quite possible that such an error could be missed by this form of testing. it is a reminder of the importance of performing usability testing with people at the conclusion of model-based testing where such an error would be easily detected. 5 conclusions in this paper we have shown how our formal models of ui design artefacts can be used as the basis for model-based testing of interactive systems. we showed how it was possible to derive tests and oracles from the models which cover all of the behaviour captured by the ui designs and system specification. the tests are ui driven (as the models are based on ui designs), which reflects our desire to follow a ucd approach supported by formal methods. we have given an example of how the abstract tests we derive can be instantiated and run against a java implementation using the fest framework in conjunction with junit. this enabled us to program tests for the implementation (in the nature of white-box testing) and run them to both observe the interaction produced as well as obtain the feedback from fest and junit with respect to whether the tests were passed or not. during the testing of our example simplecalendar application we discovered a modality error where the behaviour of the implementation did not match the oracle given by the model. we also discovered an example of an error which could not be caught by either fest or junit. our aim in performing model-based testing in this way is to find as many errors as possible prior to performing human-based usability testing. we want to discover as many functional and interaction errors as possible so that user testing can focus on usability and aesthetic issues. using the models enabled us to produce a range of abstract tests which covered all of the described interactive behaviours of the ui design models. further we have shown one way of turning these abstract tests into an implemented test suite that can produce useful results. we believe that this initial investigation into using design models for this purpose has shown it to be a useful area of research to proceed with. our tool for creating, editing and storing presentation models and pims is currently being extended to support creation and exporting of abstract tests in the manner described in this paper. this will remove the necessity to manually create the abstract tests and may also be able to support partial generation of concrete tests for particular testing strategies. for example we could proc. fmis 2009 14 / 16 eceasst automatically generate test method stubs for java to support the example given in this paper, or use other suitable extensions to the tool depending on how the tests are to be implemented. this seems feasible given the uniform way tests and their predicates are given semantics by code. we are also interested in investigating this testing strategy further and looking at different ways of instantiating the tests. in particular we would be interested to discover whether alternative methods of instantiation lead to better, or worse, results than we obtained using fest and junit. given that fest is intended to be used within a test-driven development (tdd) process we believe it is possible to perform tdd of interactive systems based on the same abstract tests as we have presented here. that is we would use the ui designs as the basis of unit-tests (both for the ui and functionality of the system) and then follow the usual tdd approach of implementing the system with the objective of passing the tests. finally we also plan to investigate the use of the the abstract tests presented here as the basis for usability testing. there are many ad hoc approaches taken to deciding how a system should be tested with users and we are interested to see if these model-driven tests provide a useful basis for such decisions, and what, if any, differences this leads to in terms of results when compared with task-driven approaches to usability testing. bibliography [ace+06] m. alles, d. crosby, c. erickson, b. harleton, m. marsiglia, g. pattison, c. stienstra. presenter first: organizing complex gui applications for test-driven development. agile conference 0:276–288, 2006. [bel01] f. belli. finite-state testing and analysis of graphical user interfaces. in issre ’01: proceedings of the 12th international symposium on software reliability engineering (issre’01). pp. 34–43. ieee computer society, washington, dc, usa, 2001. [bel03] f. belli. a holistic view for finite-state modeling and testing of user interactions. 2003. technical report 2003/1, institute for electrical engineering and information technology, the university of paderborn, april 2003. [bow08] j. bowen. formal models and refinement for graphical user interface design. phd thesis, university of waikato, department of computer science, 2008. [br06] j. bowen, s. reeves. formal models for informal gui designs. in 1st international workshop on formal methods for interactive systems, macau sar china, 31 october 2006. volume 183, pp. 57–72. electronic notes in theoretical computer science, elsevier, 2006. [br08a] j. bowen, s. reeves. formal models for user interface design artefacts. innovations in systems and software engineering 4(2):125–141, 2008. [br08b] j. bowen, s. reeves. refinement for user interface designs. electronic notes theoretical computer science 208:5–22, 2008. 15 / 16 volume 22 (2009) ui-design driven model-based testing [fes09] fest. 2009. fest (fixtures for easy software testing). http://fest.easytesting.org/wiki/pmwiki.php [iso94] iso. iso/iec 9646-1—information technology—open systems interconnection— conformance testing methodology and framework, part 1: general concepts. international standards organisation. iso/iec, first edition, 1994. [iso02] iso. iso/iec 13568— information technology—z formal specification notation— syntax, type system and semantics. prentice-hall international series in computer science. iso/iec, first edition, 2002. [mem07] a. m. memon. an event-flow model of gui-based applications for testing. software testing verification and reliability 17(3):137–157, 2007. [mem09] a. m. memon. using reverse engineering for automated usability evaluation of gui-based applications. in software engineering models, patterns and architectures for hci. springer-verlag london ltd, 2009. [pfv07] a. paiva, j. c. p. faria, r. f. a. m. vidal. towards the integration of visual and formal models for gui testing. electronic notes theoretical computer science 190(2):99–111, 2007. [ptfv05] a. paiva, n. tillmann, j. faria, r. vidal. modeling and testing hierarchical guis. in d. beauquier, e. borger, and a. slissenko, editors, asm05. universite de paris, 2005. [rp07] a. ruiz, y. w. price. test-driven gui development with testng and abbot. ieee software 24(3):51–57, 2007. [spe08] spec. #. 2008. microsoft technical pages for spec #:. http://research.microsoft.com/specsharp/ [ul06] m. utting, b. legeard. practical model-based testing: a tools approach. morgan kaufmann publishers inc., san francisco, ca, usa, 2006. [wa00] l. white, h. almezen. generating test cases for gui responsibilities using complete interaction sequences. in issre ’00: proceedings of the 11th international symposium on software reliability engineering. p. 110. ieee computer society, washington, dc, usa, 2000. [xm06] q. xie, a. m. memon. model-based testing of community-driven open-source gui applications. in icsm ’06: proceedings of the 22nd ieee international conference on software maintenance. pp. 145–154. ieee computer society, washington, dc, usa, 2006. [ycm09] x. yuan, m. b. cohen, a. m. memon. towards dynamic adaptive automated test generation for graphical user interfaces. in icstw ’09: proceedings of the ieee international conference on software testing, verification, and validation workshops. pp. 263–266. ieee computer society, washington, dc, usa, 2009. proc. fmis 2009 16 / 16 http://fest.easytesting.org/wiki/pmwiki.php http://research.microsoft.com/specsharp/ introduction example system deriving the tests instantiating and running the tests conclusions preserving constraints in horizontal model transformations electronic communications of the easst volume 29 (2010) proceedings of the ninth international workshop on graph transformation and visual modeling techniques (gt-vmt 2010) preserving constraints in horizontal model transformations paolo bottoni, andrew fish, francesco parisi presicce 14 pages guest editors: jochen küster, emilio tuosto managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst preserving constraints in horizontal model transformations paolo bottoni1, andrew fish2, francesco parisi presicce1 1 dipartimento di informatica, ”sapienza” università di roma, italy, 2computing, mathematical and information sciences, university of brighton, uk abstract: graph rewriting is gaining credibility in the model transformation field, and tools are increasingly used to specify transformation activities. however, their use is often limited by special features of graph transformation approaches, which might not be familiar to experts in the modeling domain. on the other hand, transformations for specific domains may require special constraints to be enforced on transformation results. preserving such constraints by manual definition of graph transformations can be a cumbersome and error-prone activity. we explore the problem of ensuring that possible violations of constraints following a transformation are repaired in a way coherent with the intended meaning of the transformation. in particular, we consider the use of transformation units within the dpo approach for intra-model transformations, where the modeling language is expressed via a type graph and graph conditions. we derive additional rules in a unit from a declarative rule expressing the principal objective of the transformation, so that the constraints set by the type graph and the graph conditions hold after the application of the unit. the approach is illustrated with reference to a diagrammatic reasoning system. keywords: dpo, automatic generation, model transformation. 1 introduction graph rewriting-based tools are increasingly used in the field of model transformation. however, their use is often limited by the special features of the different graph transformation approaches, which might not be familiar to experts in the modeling domain. on the other hand, transformations for specific domains may require constraints to be enforced on the results of the transformation. in this paper we explore the problem of ensuring that possible violations of constraints are managed in a way coherent with the intended meaning of the transformation. we consider horizontal (or in-place) model transformations which destructively update a model expressed in a given language, for the case where the modeling language is expressed via a type graph and a set of graph conditions. in particular, we study transformations in reasoning processes deriving inferences via logical steps creating or deleting model elements. while modelers are generally clear on what they want to achieve by defining a transformation, the evaluation of all of its consequences may be complex, and the definition of the implied preserving or enforcing actions cumbersome and error-prone. we propose an approach to the automatic construction of transformation units achieving the effect of an intended model transformation while ensuring that all conditions are satisfied at the end of the unit if they held at its start. we consider transformations consisting of the creation or deletion of elements of a specific type, expressed as principal declarative rules. as their appli1 / 14 volume 29 (2010) preserving constraints cation may violate some conditions, they have to be applied in a proper (condition preserving) context, or (condition enforcing) repair actions have to be taken to restore the satisfaction of such conditions. hence, additional rules are defined, derived from the principal one and the conditions to be enforced. the approach is illustrated with reference to a diagrammatic reasoning system. paper organisation. section 2 discusses related work on constraint preservation in graph transformation, and section 3 provides the relevant formal notions. section 4 introduces spider graphs (sgs) as running example, before presenting the approach in section 5 and applying it to sgs in section 6. finally, section 7 draws conclusions and points to future developments. 2 related work rensink and kuperus have exploited the notion of nested graphs to deal with the amalgamated application of rules to all matches of a rule. in [rk09], they define a language to specify nested graph formulae. a match can be found from a nested graph rule to a graph satisfying a formula, according to a given morphism, and the application of a composite rule ensues. their approach is focused on avoiding control expressions when all the matches of a rule have to be applied, while we focus here on preserving constraints with reference to a single match. bottoni et al. have defined methods to extend single declarative rules for model transformation so that they comply with specific patterns defining consistency of interpretation in triple graphs [bgl08]. they define completions of single rules with respect to several patterns, while we are interested here in constructing several rules, navigating along different sets of constraints. taentzer et al. have proposed the management of inconsistencies among different viewpoints of a model in distributed graph rewriting. for example, the resolve strategy requires the definition of the right-hand sides of rules to be applied when the left-hand side identifying the inconsistency is matched [gmt99]. the detection of inconsistencies between rules representing different model transformations has been attacked by static analysis methods in [hht02]. similarly, münch et al. have added repair actions to rules in case some post-conditions are violated by rule application [msw00]. in all these cases, actions were modeled through single rules. habel and pennemann [hp09] unify theories about application conditions from [eehp06] and nested graph conditions from [ren04], lifting them to high-level transformations. they transform rules to make them preserve or enforce both universal and existential conditions. their approach leads to the generation of a single rule incorporating several application conditions derived from different conditions with reference to the possible matches of the rule on host graphs. in his dissertation [pen09], pennemann expands on the topic, also introducing programs with interfaces, analogous to transformation units, but allowing passing of matches. in [oep08], orejas et al. define a logic of graph constraints to allow the use of constraints for language specification, and to provide rules for proving satisfaction of clausal forms. the idea of introducing basic rules derived from entities and associations defined in a metamodel is exploited in [bqv06] to define constraints on the interactive composition of complex rules, by allowing their presence in the rule left or right-hand sides only in accordance with their roles in the meta-model, where only the abstract syntax is taken as a source of constraints. ehrig et al. describe a procedure, exploiting layers, which derives a grammar to generate (rather than transform) instances of the language defined by a meta-model with multipliciproc. gt-vmt 2010 2 / 14 eceasst ties [ektw06]. satisfaction of ocl constraints is checked a posteriori on a generated instance. 3 background for a graph g = (v (g), e(g), s,t), v (g) is the set of nodes, e(g) ⊂ v (g)×v (g) the set of edges and s,t : e →v the source and target functions. in a type graph t g = (vt , et , st ,t t ), vt and et are sets of node and edge types, while st : et →vt and t t : et →vt define source and target node types for each edge type. g is typed on t g via a graph morphism type : g → t g, where typev : v →vt and typee : e → et preserve st and t t , i.e. typev (s(e)) = st (typee (e)) and typev (t(e)) = t t (typee (e)). |v (g) |t is the number of nodes of type t ∈vt in g. a dpo rule [eept06] consists of three graphs: leftand right-hand side (l and r) and interface graph k. two morphisms1 l : k → l and r : k → r model the embedding of k (containing the elements preserved by the rule) in l and r. figure 1 shows a dpo direct derivation diagram. square (1) is a pushout (i.e. g is the union of l and d through their common elements in k), modeling the deletion of the elements of l not in k, while pushout (2) adds the new elements, i.e. those present in r but not in k. figure 1 also illustrates the notion of negative application condition (nac), as the association of a set of morphisms ni : l → ni, also noted nac −→n← l, with a rule. a rule is applicable on g through a match m : l → g if there is no morphism qi : ni → g, with ni in nac, commuting with m (i.e. qi ◦ni = m). we exploit the partial order ≤ induced, up to isomorphisms, by monomorphisms on the set of graphs, i.e. g1 ≤ g2 ⇔∃m : g1 ↪→ g2. nk qk // 6= . . . n1 q1 ,, 6= ln1 oo nktt m �� (1) k (2) loo r // k �� r m∗ �� g dfoo g // h figure 1: dpo direct derivation diagram for rules with nac. graph conditions allow the specification of models by forbidding the appearance of certain subgraphs, or by enforcing others to appear in given contexts. we use here a class of conditions q similar to those in [hp09], where a condition over a graph a is either of the form true or of the form ∃(a, q), with a : a → q a morphism from a to some graph q and q a condition over q. conditions are also obtained by using the boolean connectives ¬ and ∨, and can be written in the form ∀(a, q), equivalent to ¬∃(a,¬q). we assume that all conditions in a set θ ⊂ q differ for the a morphism, so that (a1, q1), (a2, q2) ∈ θ ⇒ (a1 6' a2)∨(q1 6' q2). we will also use the short forms ∃(q) for ∃(a : /0 → q,true) and @(q) for ¬∃(a : /0 → q,true). we restrict here to positive conditions of types ∃(q) or ∀(a : /0 → q, q), noted ∀(q, q) with q = ∨ j∈j q j : q →wj a disjunction of existential conditions. in this case, all the conditions of the form ∃(qi) ∈ θ can be collapsed into a single condition ∃q, with q the colimit of all qi on the diagram constructed with all pairwise maximal common subgraphs. simple negative conditions have the form @(q). definition 1 given a graph g, we say: 1 in this paper, when we speak of morphisms, we will always consider them injective. 3 / 14 volume 29 (2010) preserving constraints • a morphism m : x → g satisfies a condition c, (m |= c), iff one of the following holds: 1. c = true. 2. c = ∃(y ) and y ≤ x . 3. c = ∀(x , ∨ j∈j q j : x →wj) and ∃m j : m(x ) →wj s.t. q j = m j ◦m for some q j. 4. c = @(y ) and y 6≤ x . 5. c = c1 ∨c2 and m |= c1 or m |= c2. • a graph g satisfies c (g |= c), iff one of the following holds: 1. c = true. 2. c = ∃(y ) and there exists m : y → g s.t. m |= c. 3. c = ∀(x , q) and for each m : x → g, m |= c. 4. c = @(y ) and there is no morphism m : y → g. 5. c = c1 ∨c2 and g |= c1 or g |= c2. we say that a graph g typed on t g is a model for θ, noted g |= θ, if for each ci ∈ θ, g |= ci. we assume θ to be a consistent set of conditions, whose models are finite non-empty graphs; in particular, simple graphs, with no two instances of the same edge type between two nodes. transformation units control rule application through control words over rule names [kks97]. given: 1) g the class of typed graphs; 2) r the class of dpo rules with nacs on g ; 3) =⇒ the dpo derivation relation; 4) e a class of graph expressions (here defined by type graphs and graph conditions), where the semantics of an expression e is a subclass sem(e)⊂g ; 5) w a class of control words over identifiers of rules in r exploiting single rules, the sequential construct ‘;’, the iteration construct w∗, with w ∈ w , the alternative choice ‘|’; a transformation unit is a construct t u = (e1, e2, p, imp, w), with e1, e2 ∈ e initial and terminal graph class expressions, p ⊂ r a set of dpo rules, imp a set of references to other, imported, units, whose rules can be used in the current one, and w ∈ w a control word enabling rules from p, and units from imp, to be applied. tus have a transactional behaviour, i.e. a unit succeeds iff it can be executed according to the control condition; it fails otherwise. the semantics of a t u is the set sem(t u ) = {(g1, g2) | g1 ∈ sem(e1), g2 ∈ sem(e2), g1 t u↓ =⇒ g2}, where ↓ indicates successful termination. 4 a running example: spider diagrams and spider graphs spider diagrams are a reasoning system based on euler diagrams. several variants exist, differing in syntax and semantics [hmt+01]. we adopt a simplified version, based on venn, rather than euler, diagrams and omitting shading and strands. we first provide an indication of the concrete syntax of the diagrams and an informal semantics. then we propose a graph-based abstract model for them, called spider graphs, which differs from the usual algebraic abstract models and is in fact slightly closer to the concrete model, even modelling spider’s feet. let c = {c1, . . . ,cn} be a collection of simple closed curves in the plane with finitely many points of intersection between curves. a zone is a region of the form x1 ∩···∩xn, where xi ∈ proc. gt-vmt 2010 4 / 14 eceasst {int(ci), ext(ci)}, the interior of ci or the exterior of ci, for i ∈{1, . . . , n}. if each of the 2n possible zones of c are non-empty and connected then c is a venn diagram (see [rus97] for more details). each zone z defines a unique partition of the set c, according to whether z is inside or outside a curve. two zones are called twins if their inside and outside relations are switched for exactly one curve. in this paper, a spider diagram is a venn diagram whose curves are labelled, together with extra syntax called spiders, which are trees whose vertices (called feet) are placed in unique zones. the set of zones containing a spider’s feet is called its habitat. special arcs, called ties, can be drawn between feet of different spiders in the same zone. intuitively, each curve represents a given set (indicated by the label) and each zone represents some set intersection. a spider indicates the existence of an element within the set determined by its habitat, whilst a tie between a pair of feet of different spiders within a zone indicates equality of elements, if both spiders represent an element in the set represented by the zone. figure 2 (left) shows an example of a spider diagram, with two curves {a, b} and four zones described by {({a},{b}), ( /0,{a, b}), ({b},{a}), ({a, b}, /0)}. here, these zones are the four minimal region of the plane determined by the curves; for example, the zone described by ({a},{b}) is the region int(a)∩ext(b) which is inside a but outside b. the habitat of spider s is the set of zones {({a},{b}), ({a, b}, /0)}, while that of t is the singleton {({a, b}, /0)}. informally, the diagram semantics is: there are two sets a and b, there exists an element named s in a and an element named t in a∩b. moreover, if s is in a∩b then s = t. figure 2: a spider diagram on the left, with the corresponding spider graph on the right. we provide here an abstract graph-based model of a spider diagram, called a spider graph, not taking into account its concrete geometry. since we are interested here only in syntactic aspects, we do not consider the labeling of the curves. we obtain the type graph of figure 3 (left), where nodes represent the diagram elements curve, foot, spider and zone, and edges represent relations between them. a twin edge indicates that two zones are twins w.r.t. some curve and an inside/outside edge indicates whether a curve contains/excludes a zone, respectively. in figure 2 (right) the spider graph associated with the spider diagram on the left is shown. the names of the nodes show the correspondence with the objects in the diagram. we have two curve nodes in each possible relation with four zones2. for ease of reading, the zone nodes are given names consisting of a list of the lower case letters corresponding to the upper case letters used as names of the curves the zones are inside, and we use o for the name of the node corresponding to the zone outside all curves in the diagram. zone node pairs ab and b, and o and a are twinned due to curve a, whilst ab and a, and o and b are twinned due to curve b. we now present the conditions completing the definition of the class of spider graphs. fig2 to keep the graph simple, we have omitted the outside edges, which are complementary to the inside ones. 5 / 14 volume 29 (2010) preserving constraints figure 3: the type graph (left) and negative conditions (right) for spider graphs. ure 3 (right) shows a set of conditions of the form @q, presented as forbidden graphs. they prevent duplication or inconsistency of information and state the uniqueness of relations between zones and curves. moreover, we assume the existence of all negative conditions forcing the graphs to be simple. we omit the direction of edges and their labels, when understood from the type graph, and use the abbreviations i and o for the inside/outside case. the remaining conditions force the existence of a partition of the set of curves for all zones, and require suitable contexts for zones and feet. we present them adopting a visual syntax where a condition ∃(a : a → q, q) is represented by a box, separated into two parts by a horizontal line, with the top part containing a depiction of the morphism a and the bottom part containing a box depicting the condition q on q. an empty bottom box corresponds to true. each condition box has an external tab containing either quantifier information or the boolean connective ∨,∧ or ¬. as we use conditions with a = /0, we only present q and we do not repeat q in the depiction of q. numbers indicate identification in the morphisms, while not numbered nodes indicate a hidden existential quantification, as usual. edges between identified nodes are also assumed to be identified in the morphisms. the class of spider graphs is the intersection of the languages defined by the type graph and the negative conditions of figure 3, and the positive conditions in figures 4 to 6. figure 4: conditions on single elements. reasoning rules are derived on top of the algebraic abstract models for spider diagrams. these are syntactic transformations whose application corresponds to logical deduction, according to the semantics. they are usually specified by complex algorithmic procedures, during which the intermediate diagrams may not be logical consequences of the premise diagram, with pre and post conditions taking into account the stated semantics of the diagram. for instance a rule to add a new curve must split every zone into two zones, one inside and one outside each existing zone, as well as duplicating spider’s feet in zones. whereas the first effect derives from the syntactical conditions, the second is a semantic aspect. proc. gt-vmt 2010 6 / 14 eceasst figure 5: conditions on pairs of elements. figure 6: conditions on existence and uniqueness of twins. 5 condition preserving rules we discuss the derivation of a condition-preserving transformation unit t u tg for the generation of an element of type t. the initial and terminal expressions e1 and e2 for t u tg define the class of graphs typed on t g and satisfying θ. t u tg is associated with the execution of 3 r : /0 ← /0 → t and is constructed so that given a graph g ∈ sem(e1), for g t u tg↓ =⇒ h, (g, h) ∈ sem(t u tg), and g ≤ g + t ≤ h, where + indicates the pushout along the empty subgraph. note that in general g + t 6|= θ, but g + t |= θ′ for some θ′ ⊂ θ. hence, we admit that some conditions may not be satisfied at intermediate steps of the unit application, and define an operational class in which to perform transformations. graphs in this class satisfy a subset of the graph conditions and may be typed on some t g′ with additional types and edges w.r.t. t g. in particular, we use here the subset θ′ containing ∃(q) and all the conditions @(qi) in θ. before presenting the algorithm, we give its rationale. we only have to consider universal and negative existential conditions, as positive existential conditions cannot be violated by adding an element. however, adding t produces a graph g + t which may not satisfy θ in two ways: either it contains a forbidden subgraph, or it provides a new match for the premise of a universal condition, but it fails to satisfy the conclusion. 3 here and in the rest of the paper, t denotes the graph consisting of a single node of type t. 7 / 14 volume 29 (2010) preserving constraints to solve the first problem, given4 a rule r : l → r in t u tg (including r : /0 → t ), for each condition @(x ) ∈ θ, the function gennac(r, x ) adds to r the set of nacs formed according to the construction in figure 7 (left). here m j is a maximal common subgraph of r and x and m′j is a maximal common subgraph to m j and l, s.t. all the squares are pushouts. hence, l → x′j ← x j is the pushout for l ← m′j → x j, with the second morphism given by arrow composition. the set of nacs contains all the morphisms n′j : l → x ′ j preserving the image of l in x j. this prevents the application of r on a match which could create the forbidden subgraph x (see [hht96]). m′j // �� m j �� // x �� l r // ��@ @@ r �� l r // n′j (( qqq qqq qqq 11 r // x j �� mh >>}}}} a aa lh rh b bb x′j x ??~~~ // rh figure 7: constructing nac (left) and incorporating available context (right). to solve the second problem, given a (universal) condition c = ∀(q, ∨ j∈j q j : q → wj), s.t. t ≤ q, the function genu nirules(c) produces the set of rules r(c) where each rule has the form nac(c) −→n← q rc. j→ wj. t u tg will contain an alternative choice among these rules, produced by the function alt(r(c)). in order to prevent these rules from being applied indefinitely in case of iteration on the choice, nac(c) contains a copy of each wj so the same match is not reused twice. intuitively, these rules adjust the relations of the newly added element w.r.t. the contexts defined in their premises. however, several aspects have to be taken into account. for example, consider conditions c2 in figure 4 and suppose we want to add a spider. then, the derived rule will have to create a foot (condition c2), but this will require a zone (condition c3), which will require a curve (condition c4), hence other additional zones (conditions c8 and c9), with several relations to other curves and zones (conditions c10−c12). on the other hand, a zone for a foot is already guaranteed to be present by c1, so that one can reuse existing context to satisfy this. to deal with such situations, given a rule r : l → r and a context x to be reused (more on this later), the function reusecontext(r, x ) produces a collection of rules of the form rh : lh → rh according to the construction in figure 7 (right). here, l → lh ← x is the pushout along a maximal common subgraph mh of l and x and x → rh ← r is the pushout of x ← mh → r. in general, one wants to obtain a t u tg which, after applying r : /0 → t to g, proceeds through the following abstract steps, so that context is progressively constructed for the next step. 1. define all edges between the added node and existing nodes of g as required by conditions; 2. generate new nodes as required by the conditions; 3. generate all edges for the new nodes, as required by the conditions. for example, when adding a curve, one has to: 1) define relations between the new curve and existing zones; 2) create new zones, while defining relations with the new curve; 3a) establish relations between new zones and existing curves; 3b) establish relations between zones. 4 where not needed, we will omit k. proc. gt-vmt 2010 8 / 14 eceasst two things have to be considered. in general, satisfaction of ∀(q, q) requires iterating through all possible matches for q. however, when q consists of just one node, no iteration is necessary, and if q is the graph t , the derived rule has to be applied only to the newly added node, as it is already satisfied for the nodes of type t which were in g originally. hence, we extend t g to admit a special type of loop edge: the first rule is changed to r : /0 → t †, where t † designates a node with a marker loop. for a rule5 r : l → r, the function mark(r) produces a set p†r = {r † h : l † h → r † h | h : t → l} where l † h and r † h are obtained by adding the loop to the images h(l) and r◦h(l), the immersions mh : l ↪→ l†h and m ′ h : r ↪→ r † h preserve such images, and r † h is the unique morphism s.t. l†h r†h→ r†h m′h← r is the pushout of l†h mh← l r→ r. t u tg will apply r or rules from p†r in different situations. the rule delloop : t † → t will conclude t u tg deleting the loop. moreover, as in the examples above, some rules create new nodes if they cannot be provided by the context, and so conditions relative to the new nodes have to be satisfied. this potentially creates a situation in which an infinite recursion might start. to avoid this, we study the relations between types for which conditions are mutually recursive. in our example one such pair consists of curve and zone. indeed, generating a curve implies the generation of a collection of zones, whilst the generation of a zone can imply the generation of a single curve and of the collection of zones related to the new curve: we need to distinguish between situations in which context, enriched with the new node which has started the process, has to be reused, and those in which a new node is needed to provide the correct context. definition 2 provides the needed notation. definition 2 let t ∈ vt be a type and q(t) ⊂ θ the set of conditions of the form op(a : a → q, q), for op∈{∃,∀, @} s.t. t ≤q (i.e. a node of type t appears in q). {q∃(t), q∀(t), q@(t)} is a partition of q(t) into existential6, universal and negative existential conditions for t, respectively. v∃t = {t | t ≤ q} is the set of existentially quantified types. a partial order ≤c is induced on q∀(t) by (c1 2), and ordered or qualified associations. 1 stored procedures are routines (like a subprogram in a regular computing language) that are stored in the database. a stored procedure has a name, may have a parameter list, and an sql statement, which can contain many other sql statements. stored procedures provide a special syntax for local variables, error handling, loop control, if-conditions and cursors, which allow the definition of iterative structures. proc. ocl 2010 2 / 16 eceasst let m be a class diagram and let o be an instance of m. then, • each class a in m is mapped to a table dae, which contains, by default, a column pk of type int as its primary key. then, each object in o of class a is represented by a row in dae and it will be denoted by its key (i.e., the value in pk). • given a class a, each attribute w of a is mapped to a column w ] in dae, the type of w ] being the type of w .2 then, the value of w in an object o in o is represented by the value which the column w ] holds for the row that represents o in dae. • given two classes a and b, each association p between a and b, with association-ends rl a (at the class a) and rl b (at the class b), is mapped to a table dpe, which contains two columns rl a] and rl b], both of type int. then, a p-link between an object o of class a and an object o′ of class b is represented by a row in dpe, where rl a] holds the key denoting o and rl b] holds the key denoting o′. the above mapping rules assumes that the input uml class diagrams satisfy the following (rather) natural constraints: • each class has a unique name. • each attribute within a class has a unique name. • each association is uniquely characterized by its association-ends. also, the associationends in a self-association have different names. 3 mapping non-iterator expressions to mysql queries in this section we define the query codegen(expr) produced by our code generator for the case of expressions expr whose top-operator is a non-iterator operator. examples can be found in appendix a. we proceed by cases, each case being characterized by the expression’s top-operator. due to space constraints, we only consider a subset of the ocl non-iterator operators. also, we assume that the types of these operators are either primitive types, sets or bags of primitive or class types, or class types. for the sake of presentation, we assume that, in all cases, the immediate subexpressions of expr are non-iterator expressions. the remaining cases are dealt with as explained in section 5. primitive operators variables. let var be a variable. then, codegen(var) is: select var as value 2 more specifically, the uml/ocl primitive types boolean, integer, and string, are mapped, respectively, to the mysql types int, int, and char(65). the uml/ocl class types are mapped to the mysql type int (which is the type of the primary keys of the tables representing classes). we have decided to map string to char(65) for efficiency reasons: obviously, a more general solution is to map string to text. 3 / 16 volume 36 (2010) mysql4ocl: a stored procedure-based mysql code generator for ocl literals. let lit be a primitive literal. then, codegen(lit) is: select lit as value operators. let expr be an expression or the form expr1 prim op expr2, where prim op is +, -, x, and, or, implies, or =. then, codegen(expr) is: select (codegen(expr1)) prim op[ (codegen(expr2)) where prim op[ denotes the operation in mysql that corresponds to prim op.3 similarly, for expressions of the form prim op expr1, where prim op is or not. type literals. let class be a class identifier. then, codegen(class) is: select pk as value from dclasse boolean operators isempty/notempty. let expr be an expression of the form expr1->isempty(). then, codegen(expr) is: select count(*)=0 as value from (codegen(expr1)) as codegen(expr1) for the operator notempty, “count(*)>0” replaces “count(*)=0” above. includes/excludes. let expr be an expression of the form expr1->includes(expr2). then, codegen(expr) is: select codegen(expr2) in codegen(expr1) as value for the operator excludes, “not in” replaces “in” above. numeric operators size. let expr be an expression of the form expr1->size(). then, codegen(expr) is: select count(*) as value from (codegen(expr1)) as codegen(expr1) sum. let expr be an expression of the form expr1->sum(). then, codegen(expr) is: select sum(*) as value from (codegen(expr1)) as codegen(expr1) 3 in general, since there are primitive operators in ocl that do not have a direct counterpart in mysql (e.g., implies), some expressions may need to be rewritten into equivalent ones before calling the code generator. proc. ocl 2010 4 / 16 eceasst model specific operators allinstances. let expr be an expression of the form expr1.allinstances(). then, codegen(expr) is: select * from (codegen(expr1)) as codegen(expr1) association-ends. let expr be an expression of the form expr1.rl a (resp. expr1.rl b), where rl a (resp. rl b) is the a-end (resp. b-end) of an association p between two classes a and b. then, codegen(expr) is: select dpe.rl a] as value from (codegen(expr1)) as codegen(expr1) left join dpe on codegen(expr1).value = dpe.rl b where dpe.rl a] is not null attributes. let expr be an expression of the form expr1.attr where attr is an attribute of a class a. then, codegen(expr) is: select dae.attr] as value from (codegen(expr1)) as codegen(expr1) left join dae on codegen(expr1) .value = dae.pk collection operators asset. let expr be an expression of the form expr1->asset(). then, codegen(expr) is the following mysql statement: select distinct * from (codegen(expr1)) as codegen(expr1) asbag. let expr be an expression of the form expr1->asbag(). then, codegen(expr) is: codegen(expr1) union. let expr be an expression of the form expr1->union(expr2), where both expr1 and expr2 are sets. then, codegen(expr) is: codegen(expr2) union codegen(expr1) when expr1 or expr2 are bags, then “union all” will replace “union” above. including. let expr be an expression of the form expr1->including(expr2), where expr1 is a set. then, codegen(expr) is: codegen(expr2) union codegen(expr1) when expr1 is a bag, then “union all” will replace “union” above. 5 / 16 volume 36 (2010) mysql4ocl: a stored procedure-based mysql code generator for ocl excluding. let expr be an expression of the form expr1->excluding(expr2). then, codegen(expr) is: select * from codegen(expr1) as codegen(expr1) where value not in codegen(expr2) 4 mapping iterator expressions to mysql procedures in this section we define the query codegen(expr) produced by our code generator for the case of expressions expr whose top-operator is an iterator. examples can be found in appendix a. here, the basic idea is that, for each iterator expression expr, our code generator produces a mysql stored procedure, denoted by codegenproc(expr), that, when called, it creates a table, denoted by dcodegenproc(expr)e, containing the values corresponding to the evaluation of expr. due to space constraints, we only consider a subset of the iterator operators in ocl: namely, forall, exists, collect, select, and reject. also, we assume that the types of the source-subexpressions are either sets or bags of primitive or class types, and that, in the case of collect-expressions, the types of their body-subexpressions are either primitive or class types, or set or bags of primitive or class types. for the sake of presentation, we assume that, in all cases, the sourceand body-subexpressions of expr are not themselves iterator expressions. the others cases (which include the cases of nested iterators) are dealt with as explained in section 5. let expr be an iterator expression of the form source->iter op(var|body). then, codegen(expr) is: call codegenproc(expr); select * from dcodegenproc(codegen(expr))e; where codegenproc(expr) is a mysql stored procedure. the definition of this procedure, also generated by our code generator, follows the scheme shown in figure 1. basically, the function codegenproc(expr) creates the table dcodegenproc(expr)e and execute, for each element in the source-collection, the body of the iterator expression expr. more concretely, until all elements in the source-collection have been considered, codegenproc(expr) repeats the following process: i) it instantiates the iterator variable var in the body-subexpression, each time with a different element of the source-collection, which it fetches from codegen(source) using a cursor; and ii) using the so called “iterator-specific processing code”, it processes in dcodegenproc(expr)e the result of the query codegen(body), according to the semantics of the iterator iter op. additionally, in the case of the iterators forall and exists, the table dcodegenproc(expr)e is initialized, using the so called “initialization-specific code”. moreover, for the iterators forall and exists, the process described above will also be finished when, for any element in the source-collection, the result of the query codegen(body) contains the value corresponding, in the case of the iterator forall, to false (i.e., 0) or, in the case of the iterator exists, to true (i.e., 1). in the remaining of this section, we specify, for each case of iterator expression, the corresponding “value-specific type”, “initialization-specific code” and “iterator-specific processing code” produced by our code generator when instantiating the general schema. for all cases, the “cursor-specific type” is the mysql type which represents, according to our mapping (see footnote 2), the type of the elements in the source. proc. ocl 2010 6 / 16 eceasst create procedure codegenproc(expr)() begin declare done int default 0; declare var cursor-specific type ; declare crs cursor for codegen(source); declare continue handler for sqlstate ’02000’ set done = 1; drop table if exists dcodegenproc(expr)e; create table dcodegenproc(expr)e (value value-specific type ); initialization-specific code (only for forall and exists) open crs; repeat fetch crs into var; if not done then iterator-specific processing code end if; until done end repeat; close crs; end; figure 1: general schema for mapping iterator expressions as stored procedures. forall-iterator. let expr be an expression of the form source->forall(var|body). then, the “holes” in the scheme shown in figure 1 will be filled as follows: • value-specific type: int. • initialization code: insert into dcodegenproc(expr)e (value) values (1); • iterator-processing code: update dcodegenproc(expr)e set value = 0 where (codegen(body)) = 0; if exists (select 1 from dcodegenproc(expr)e where value = 0) then set done = 1; end if; exists-iterator. let expr be an expression of the form source->exists(var|body). then, the “holes” in the scheme shown in figure 1 will be filled as follows: • value-specific type: int. • initialization code: 7 / 16 volume 36 (2010) mysql4ocl: a stored procedure-based mysql code generator for ocl insert into dcodegenproc(expr)e (value) values (0); • iterator-processing code: update dcodegenproc(expr)e set value = 1 where (codegen(body)) = 1; if exists (select 1 from dcodegenproc(expr)e where value = 1) then set done = 1; end if; collect-iterator. let expr be an expression of the form source->collect(var|body). then, the “holes” in the scheme shown in figure 1 will be filled as follows: • value-specific type: the mysql type which represents, according to our mapping, the type of the body. • iterator-processing code: insert into dcodegenproc(expr)e (value) codegen(body); select-iterator. let expr be an expression of the form source->select(var|body). then, the “holes” in the scheme shown in figure 1 will be filled as follows: • value-specific type: the mysql type which represents, according to our mapping, the type of the elements in the source. • iterator-processing code: if exists (select 1 from (codegen(body)) as codegen(body) where value = 1) then insert into dcodegenproc(expr)e (value) values (var); end if; reject-iterator. let expr be an expression of the form source->reject(var|body). then, the “holes” in the scheme shown in figure 1 will be filled as follows: • value-specific type: the mysql type which represents, according to our mapping, the type of the elements in the source. • iterator-processing code: if exists (select 1 from (codegen(body)) as codegen(body) where value = 0) then insert into dcodegenproc(expr)e (value) values (var); end if; proc. ocl 2010 8 / 16 eceasst 5 dealing with iterator subexpressions the key idea underlying our mapping from ocl to mysql is the use of stored procedures to deal with iterator expressions. however, since stored procedures cannot be called within queries, the recursive definition of our code generator needs to treat the case of immediate subexpressions which are iterator expressions in a special way. more concretely, let expr be an ocl expression with top-operator op and immediate subexpressions expr1, . . . , exprn. now, let expri, 1 ≤ i ≤ n, be an iterator expression. then, except for the case of iterator expressions whose body-subexpressions are themselves iterator expressions (i.e., the case of nested iterator expressions), which we will discuss later, the query codegen(expr) produced by our code generator will be preceded by call codegenproc(expri); and, moreover, any subquery codegen(expri) occurring in the definition of codegen(expr), as given in section 3 and section 4, will be replaced by the following subquery select * from dcodegenproc(expri)e as codegenproc(expr1); example 1 for example, let expr be the ocl expression expr1->notempty(), where expr1 is the non-iterator expression car.allinstances(). our code generator will produce the following query: select count(*)>0 as value from (codegen(expr1)) as codegen(expr1); on the other hand, let expr be the ocl expression expr1->notempty(), where expr1 is the iterator expression car.allinstances()->collect(c|c.model). our code generator will produce the following query: call codegenproc(expr1); select count(*)>0 as value from (select * from dcodegenproc(expr1)e) as codegenproc(expr1); 5.1 nested iterators let expr be an iterator expression of the form source->iter op(var|body). then, if the subexpression source is itself an iterator expression, but not the subexpression body), we simply proceed as explained above. however, when the subexpression body is itself and iterator expression, the general scheme for mapping iterator expressions shown in figure 1 is slightly modified. more concretely, right before the “iterator specific processing code”, our code generator will insert call codegenproc(body)(var); where now the procedure generated for mapping the body-iterator subexpression takes one parameter: namely, the iterator variable var introduced by the enclosing iterator expression.4 moreover, our code generator will replace any subquery codegen(body) occurring in the “iteratorspecific processing code”, as given in section 4, by the following subquery: 4 more generally, in the case of nested iterator expressions, the procedure generated for mapping an inner iterator body-subexpression will take as parameters the iterator variables introduced by all its enclosing iterator expressions, which we assume to have different names. 9 / 16 volume 36 (2010) mysql4ocl: a stored procedure-based mysql code generator for ocl scenario i: 103 persons × 10 non-“black” cars, eos mysql p = car.allinstances().owner.ownedcars 4ocl p->size() 30ms 180ms p->collect(x|x.color)->size() 80ms 8.70s p->collect(x|x.color <> ’black’)->size() 90ms 8.73s p->collect(x|x.owner.ownedcars)->size() 240ms 15.25s p->collect(x|x.owner.ownedcars->includes(x))->size() 221ms 17.24s p->forall(x|x.owner.ownedcars->includes(x)) 251ms 16.20s p->select(x|x.owner.ownedcars->includes(x))->size() 260ms 19.84s p->collect(x|x.owner.ownedcars.color)->size() 290ms 37.78s p->collect(x|x.owner.ownedcars.color->size())->sum() 270ms 36.79s p->forall(x|x.owner.ownedcars.color->excludes(’black’)) 280ms 33.42s table 1: efficiency evaluation. preliminary results. select * from dcodegenproc(body)(var)e 6 a preliminary discussion on efficiency in [ced08] we discussed: i) the need for an efficient implementation of ocl; ii) the aspects to be taken into consideration to improve the efficiency of ocl evaluators on medium-large scenarios; iii) the limits of the current ocl implementations for dealing with really large scenarios. to motivate i), we included a benchmark showing the performance of some ocl tools on mediumlarge scenarios. although the aim of our code generator is not to address i), that is, the efficient implementation of ocl evaluation, but rather to overcome iii), that is, the limits of the current ocl implementations for dealing with really large scenarios, we found interesting to compare the execution of the code produced by our mysql4ocl with eos,5 using for this purpose essentially the same benchmark proposed in [ced08]. all the expressions in the benchmark were evaluated on the same scenario, namely, an instance of the “car-ownership” class diagram which contains 103 persons, each person owning 10 different cars, and each car with a color different from “black”. the results are shown in table 1.6 notice that, for the sake of the experiment, we artificially increased the size of the collections to be iterated upon: more concretely, in table 1, p stands for the expression car.allinstances().owner.ownedcars, which, on the given scenario, evaluates to a collection with 105 cars. as expected, for small-medium size scenarios, it is faster to evaluate ocl expressions using eos than to execute the code generated by mysql4ocl. interestingly, the cost of executing this mysql code seems to depend, as in the case of eos, on two measurements: first, the 5 in the benchmark proposed in [ced08], eos outperformed the other ocl evaluators. we do not have more recent comparison figures. 6 in the case of mysql4ocl, the benchmark was run on a laptop computer with two processors at 2.40ghz, 2gb of ram and default settings for mysql 5.1 community server. in the case of eos, the benchmark was run on a laptop computer, with a single processor at 2ghz, 1gb of ram, and setting jvm parameters -xms and -xmx to 1024m. proc. ocl 2010 10 / 16 eceasst maximum number of times that objects’ properties will be accessed and, second, the maximum size of the collections that will be built. in fact, for the expressions in this benchmark, the extracost of executing the code generated by mysql4ocl is essentially linear with respect to the cost of evaluating the expressions in eos. the advantage of using our code generator comes when evaluating ocl expressions on large scenarios. as reported in [ced08], none of the available ocl evaluators, including eos, were able to finish loading a scenario with 106 cars in less than 20 minutes.7 in contrast, loading this scenario on a mysql server may take less than a minute. however, it remains to be addressed the question of whether executing the code produced by mysql4ocl on large scenarios is sufficiently efficient. for this purpose, we have run again on mysql4ocl the benchmark proposed in [ced08], but this time on a considerably larger scenario: namely, one that contains 105 persons, each person owning 10 different cars, and each car with a color different from “black”. as expected, the execution times scale-up linearly with respect to those shown for mysql4ocl in table 1: basically, they are multiplied by 102, in line with the fact that the number of persons and cars are also multiplied by 102. although these results are encouraging, more experiments and comparisons are still needed in order to extract definite conclusions about the efficiency on large scenarios of the code generated by mysql4ocl. 7 related work the work most directly related with this paper can be found in [dh99, sch98] and provides the foundations of the ocl2sql tool [dhl01, hwd08]. as already discussed in [ced08], the solution offered in [dh99, sch98] is not satisfactory: it only considers a rather restricted subset of the ocl language; it only applies to boolean expressions and not to arbitrary queries; and the “complexity” of the produced code makes impractical its use for evaluating expressions on medium-large scenarios.8 there are many differences between our mapping and the one underlying ocl2sql (along with some commonalities, of course). here we only discuss the two most relevant differences. first, we map navigation expressions using “left join”, while ocl2sql uses “in”. with “left join”, we avoid erroneously removing duplicated elements when dealing with bags in arbitrary ocl queries. second, and more relevant for our present purposes, we give a well-defined mapping of ocl iterator operators using stored procedures. interestingly, this idea was already hinted in [sch98]. however, as it is recognized there, “this work did not succeed in finding a concise and complete formal representation for procedural mapping patterns”, and the idea was not further developed afterwards. the mapping from ocl to mql (the sap metamodel repository query language) proposed in [bur06] is also related with our work. unfortunately, iterator expressions or boolean operators on collections (e.g., isempty() or includes()) are not covered by the proposed mapping, due to the limited expressiveness of the target language. on a more abstract level, 7 in fact, we do not know how long would it take to actually finish this task for the different ocl evaluators, since we decided to stopped, in all cases, the loading process after 20 minutes. in any event, it is clear that, for most applications, loading large scenarios in memory will be rather impractical. 8 as reported in [ced08], the cost of executing the code generated by ocl2sql for a simple forall-expression was the following: 25s for a collection with 104 elements, and 45m for a collection with 105 elements. 11 / 16 volume 36 (2010) mysql4ocl: a stored procedure-based mysql code generator for ocl several methodologies have been recently proposed in [mhs09, an06, an09] to generate code (possibly for specific data storage language) from ocl expressions. it remains to be investigated how our code generator fits in these (yet not fully developed) proposals. also, there have been several interesting proposals for mapping ocl expressions into java code [dbl05, wil09]. however, we envision for the code generated by these mappings the same general limitation reported in [ced08] for ocl evaluators: namely, that for really large scenarios they need first to solve the loading problem within a practical time-frame. finally, it is worthwhile mentioning the work done in [mab08, coo09, gmrs09] on translating other (constraint/query) languages to sql, since they aim to bridge application and databases, which is also part of our motivation. a detailed discussion on the expressiveness and/or practical interest of ocl with respect to the (class of) source languages considered in [mab08, coo09, gmrs09] is, however, out of the scope of this paper. 8 conclusions and future work in this paper, we have introduced a mysql code generator for a significant subset of ocl expressions (including, possibly nested, iterator expressions) which is based on the use of stored procedures for mapping ocl iterators. our code generator has been already implemented in the mysql4ocl tool, which is available at [edc10]. since the features and language constructs that are employed in our mapping from ocl to mysql are supported (leaving aside syntactic differences) by other relational databases such as oracle and postgresql, we expect that our code generator could be adapted for other database management systems. also, we have discussed the efficiency of the code produced by our code generator, and we have compared it with previous known results on evaluating ocl expressions on medium-large scenarios. additional experiments and comparisons are still needed in order to extract more definite conclusions, and we plan to carry them on as part of our future work. in this context, we plan to investigate which transformations between equivalent ocl expressions are useful in order to optimize the code produced by our code generator. among the features of ocl that our code generator, as presented here, does not cover, we briefly discuss how we shall extend our mapping to cover three of them: namely, (i) the possibility of defining collection of collections (e.g., using collectnested); (ii) the possibility of denoting or checking types (e.g., using ocltype, oclistypeof, and ocliskindof); and (iii) the possibility of defining (maybe using recursion) operations. now, to cover (i) and (ii), we have to modify our queries codegen(expr) in order to obtain more “structured” result-sets. more concretely, to cope with expressions denoting or checking types, each element in the result-set of a query produced by our code generator shall not only hold a value, but also its type. then, to cope with expressions defining collection of collections, the result-set returned by executing the query produced by our code generator shall take the form of a left-join, in which all the elements of the same subcollection are joint together. next, to cope with (iii) we will resort to the use of stored procedures. finally, we have also left uncovered the dealing with the special value “undefined”. in principle, we shall treat undefinedness adding conditions in the code produced by our code generator for the different ocl operators. proc. ocl 2010 12 / 16 eceasst acknowledgements: we thank michael schläpfer for his interesting discussions and help during the initial stage of this proposal. bibliography [an06] a. armonas, l. nemuraité. pattern based generation of full-fledge relational schemas from uml/ocl models. information technology and control 35(1), 2006. [an09] a. armonas, l. nemuraité. using attributes and merging algorithms for transforming ocl expressions into code. information technology and control 38(4), 2009. [bur06] e. burger. query infrastructure and ocl within the sap project “modeling infrastructure”studienarbeit. technical report, institut für theoretische informatik technische universität karlsruhe, germany, 2006. [ced08] m. clavel, m. egea, m. g. de dios. building and efficient component for ocl evaluation. in proc. of 8th ocl workshop at the uml/models conference: ocl concepts and tools: from implementation to evaluation and comparison. eceasst 15. tolouse, france, september 2008. [coo09] e. cooper. the script-writer’s dream: how to write great sql in your own language and be sure it will succeed. in gardner and geerts (eds.), proc. of 12th international symposium database programming languages dbpl 2009. lncs 5708, pp. 36–51. springer, 2009. [dbl05] w. dzidek, l. briand, y. labiche. lessons learned from developing a dynamic ocl constraint enforcement tool for java. in proc. of the 4th ocl workshop at models’05 conference: tool support for ocl and related formalisms needs and trends. lncs 3844, pp. 10–19. springer-verlag berlin heidelberg, montego bay, jamaica, october 2005. [dds+10] m. a. g. de dios, c. dania, m. schläpfer, d. a. basin, m. clavel, m. egea. ssg: a model-based development environment for smart, security-aware guis. in kramer et al. (eds.), proc. of the 32nd acm/ieee international conference on software engineering volume 2, icse 2010, cape town, south africa, 1-8 may 2010. pp. 311–312. acm, 2010. http://www.bm1software.com. [dh99] b. demuth, h. hußmann. using uml/ocl constraints for relational database design. in france and rumpe (eds.), proc. of uml’99: the unified modeling language beyond the standard, second international conference, fort collins, co, usa, october 28-30, 1999, proceedings. lncs 1723, pp. 598–613. springer, 1999. [dhl01] b. demuth, h. hußmann, s. loecher. ocl as a specification language for business rules in database applications. in proc. of uml 2001: the unified modeling 13 / 16 volume 36 (2010) http://www.bm1software.com mysql4ocl: a stored procedure-based mysql code generator for ocl language. modeling languages, concepts and tools. lncs 2185, pp. 104–117. springer, toronto, canada, 2001. [edc10] m. egea, c. dania, m. clavel. the mysql-ocl code generator. august 2010. http://www.bm1software.com/mysql-ocl. [gmrs09] t. grust, m. mayr, j. rittinger, t. schreiber. ferry: database-supported program execution. in cetintemel et al. (eds.), proc. of the 35th sigmod international conference on management of data. sigmod ’09, pp. 1063–1066. acm, new york, ny, usa, 2009. [hwd08] f. heidenreich, c. wende, b. demuth. a framework for generating query language code from ocl invariants. in proc. of 7th ocl workshop at the uml/models conference: ocl4all: modelling systems with ocl. eceasst 9. nashville, tennessee, october 2008. [mab08] s. melnik, a. adya, p. a. bernstein. compiling mappings to bridge applications and databases. acm transactions database systems 33:1–50, december 2008. [mhs09] r. moiseev, s. hayashi, m. saeki. generating assertion code from ocl: a transformational approach based on similarities of implementation languages. in a.schürr and selic (eds.), proc. of model driven engineering languages and systems, 12th international conference, models 2009, denver, co, usa, october 4-9, 2009. proceedings. lncs 5795, pp. 650–664. springer, 2009. [sch98] a. schmidt. untersuchungen zur abbildung von ocl-ausdrücken auf sql. master’s thesis, institut für softwaretechnik ii technische universität dresden, germany, 1998. [wil09] c. wilke. java code generation for dresden ocl2 for eclipsegrosser beleg. technical report, fakultät informatik institut für software un multimediatechnik technische universität dresden lehrstuhl softwaretechnolgie, germany, 2009. a examples consider the “car-ownership” uml class diagram in figure 2: it contains two classes, “person” and “car”, which are related by the association “ownership”, which links persons (“owner”) with their cars (“ownedcars”). to illustrate the mapping rules for uml class and object diagrams given in section 2, we show below the mysql statements that create the tables corresponding to “car-ownership”. create table person (pk int auto increment primary key, name char(65), age int, phoneno int); create table car (pk int auto incremente primary key, model char(65), color char(65)); create table ownership (owner int not null, ownedcars int not null, foreign key (owner) references person (pk), foreign key (ownedcars) references car (pk)); proc. ocl 2010 14 / 16 http://www.bm1software.com/mysql-ocl eceasst car + model : stringalaaa + color : stringaaaaal person + name : stringaaallla + phoneno : integerlal + age : integeraaaaall ownedcars owner * * figure 2: the “car-ownership” class diagram 1 : car model = peugeot 307 color = white 2 : car model = peugeot 206 color = blue 3 : car model = peugeot 206 color = grey 2 : person name = teresa age = 25 phoneno = 67641875 1 : person name = ale age = 26 phoneno = 68901037 3 : person name = césar age = 29 phoneno = 63518996 4 : person name = juan age = 26 phoneno = 65148161 figure 3: a “car-ownership” object diagram person pk name age phoneno 1 ale 26 68901037 2 teresa 25 67641875 3 césar 29 63518996 4 juan 26 65148161 car pk model color 1 peugeot 307 white 2 peugeot 206 blue 3 peugeot 206 grey ownership owner ownedcars 1 1 2 1 2 2 3 3 figure 4: mapping a “car-ownership” object diagram. also, consider the instance of “car-ownership” in figure 3. we show in figure 4 the representation of this object diagram in the tables created by our mapping for “car-ownership”. next, to illustrate the recursive definition of our code generator given in section 3 and section 4, we introduce the following examples: example 2 let expr be the ocl expression car.allinstances().model. then, codegen(expr) is the following mysql statement: select car.model as value from (select pk value from car) as temp left join car on temp.value = car.pk; example 3 let expr be the ocl expression car.allinstances().owner. then, codegen(expr) is the following mysql statement: select ownership.owner as value 15 / 16 volume 36 (2010) mysql4ocl: a stored procedure-based mysql code generator for ocl from (select pk value from car) as temp left join ownership on temp.value = ownership.ownedcars where ownership.owner is not null; example 4 let expr be the ocl expression car.allinstances()->forall(c| c.owner.ownedcars->includes(c)). then, codegen(expr) is the following mysql statement: create procedure forall0() begin declare done int default 0; declare result boolean default true; declare var int; declare crs cursor for (select pkcar from car); declare continue handler for sqltate ’02000’ set done = 1; drop table if exists forall0; create table forall0(value int); insert into forall0 (value) values (1); open crs; repeat fetch crs into var; if not done then update forall0 set value = 0 where( select var in ( (select ownership.ownedcars as value from (select ownership.owner as value from (select var as value) as t3 left join ownership on t3.value=ownership.ownedcars where ownership.owner is not null) as t2 left join ownership on t2.value=ownership.owner where ownership.ownedcars is not null) as t1) = 0; if exists (select 1 from forall0 where value = 0) then set done = 1; end if; end if; until done end repeat; close crs; end; call forall0(); select * from forall0; proc. ocl 2010 16 / 16 introduction mapping uml class and object diagrams to mysql mapping non-iterator expressions to mysql queries mapping iterator expressions to mysql procedures dealing with iterator subexpressions nested iterators a preliminary discussion on efficiency related work conclusions and future work examples a coinductive approach to verified exact real number computation electronic communications of the easst volume 23 (2009) proceedings of the ninth international workshop on automated verification of critical systems (avocs 2009) a coinductive approach to verified exact real number computation ulrich berger and sion lloyd 15 pages guest editor: markus roggenbach managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst a coinductive approach to verified exact real number computation ulrich berger and sion lloyd university of wales swansea, swansea, sa2 8pp, wales uk abstract: we present an approach to verified programs for exact real number computation that is based on inductive and coinductive definitions and program extraction from proofs. we informally discuss the theoretical background of this method and give examples of extracted programs implementing the translation between the representation by fast converging rational cauchy sequences and the signed binary digit representations of real numbers. keywords: proof theory, program extraction, exact real number computation, coinduction 1 introduction in current implementations of main stream programming languages real numbers are represented in floating point format, and computation on real numbers is done with respect to this representation. as is well-known, rounding errors in floating point arithmetic may occur, and inevitably do so, due to the limited precision of floating point numbers on the one hand and the infinitary character of the real numbers on the other hand. the problem with this is not so much the fact that these rounding errors occur already in relatively simple computations, but that the user has no control over them. as a simple example consider the function f(x) = 1+x-(xˆ2)*(x+1)*((1/x)-(1/(x+1))) -haskell code and the computations *main> f(10ˆ4) :: float 2.834961 *main> f(10ˆ4) :: double 1.0000000006384653 *main> f(10ˆ9) :: double -149.21128177642822 which of these results can we trust? actually, in all three cases the correct result is 1.0, which can be easily seen by applying elementary school algebra to the expression defining the function f . the situation we encounter here is typical: in order to estimate the accuracy of a floating point computation one needs, in principle, always a mathematical analysis of the numerical stability of the problem which can be arbitrarily difficult. increasing the precision cannot replace such an analysis because one does not know by how much the precision needs to be increased in order to obtain a required number of correct digits. in view of safety critical applications of numeric computation, for example autopilot systems for aircrafts, these problems can no longer be neglected, 1 / 15 volume 23 (2009) a coinductive approach to verified exact real number computation but require alternative approaches that have a sound mathematical and technological basis. such approaches are currently promoted under the slogan “computing with exact real numbers”. in exact real number computation results are not necessarily exact, but they are guaranteed to be correct with any accuracy prescribed by the user. this means the user has full control over errors. of course, it still can happen that a given accuracy cannot be obtained due to limited resources in time and space, but it will never happen that a result is delivered without information about its accuracy. a further essential requirement in exact real number computation is that the correctness of a program has to be proven (in a stringent mathematical sense) in order to justify the user’s trust in it. the generation of provably correct programs in exact real number computation is the focus of this paper. in traditional program verification one takes a program and applies a certain method to prove that it meets a given specification (see the seminal papers [flo67, hoa97, dij75, pnu77, mil80] and systems supporting program verification, e.g. pvs [orss98], isabelle [npw02], coq [coq], kiv [brs+00], acl2 [kmm00], blast [bez07]). another approach is to develop or derive programs according to certain rules that preserve correctness, thus obtaining programs that are correct “by construction” [dij97, gri81, dj78]. the method we are presenting can be seen as a rather radical instance of the latter approach. from a formal constructive proof of a mathematical statement a we extract a program that “realises” a. in general, the statement a does not need to be related to programming, but in specific cases a may be viewed as a specification of a computational problem that is solved by the extracted program. by a constructive proof we mean a proof that does not make use of the law of excluded middle or equivalent principles. constructive reasoning is being adopted in intuitionism [vh67, hey56, tro73], constructive mathematics [bb85] and constructive type theory [ml84], and is implemented in a number of interactive proof systems, for example, nuprl [con86], coq [coq], minlog [bbs+98] and agda [agd]. the logical basis of program extraction via realisability was laid by kleene [kle45] and kreisel [kre59] (for proof-theoretic purposes). it is an instance of what is known in computer science as the “curry-howard correspondence” or “proofs-as-programs” paradigm which is applicable to constructive proofs in a wide range of areas. in this paper we concentrate on constructive real analysis and we illustrate the method by some simple yet non-trivial examples. we want to make the case that it is not only possible in principle, but also feasible in practice to extract interesting programs from proofs (see also [sch09] for related work on program extraction in constructive analysis). an important principle for definitions and proofs we are using is coinduction. a coinductive definition can be viewed set-theoretically as the largest fixed-points of a monotone set operator or category-theoretically as the final coalgebra of a functor. recently, coinductive definitions, coalgebras and coinductive proofs have become very popular for describing concurrent systems and cryptographic protocols [bs07, jr97, mos99, rut00, hw03]. also, much of the recent work on exact real number computation uses coinduction to verify real number algorithms w.r.t. the representation of real numbers by infinite streams of signed digits and similar representations [eh02, me07, gnsw07, cd06, ber07, bh08]. in our paper we go one step further and extract these algorithms from proofs about coinductive characterisations of real numbers. proc. avocs 2009 2 / 15 eceasst 2 induction and coinduction we give a brief introduction to coinduction and the dual principle of induction. we begin with the latter as it is more familiar. consider an operator φ : p(u ) → p(u ), where u is a set and p(u ) is the powerset of u , and assume that φ is monotone, i.e. if x ⊆ y ⊆ u , then φ(x ) ⊆ φ(y ). since p(u ) is a complete lattice w.r.t. set inclusion φ has a least fixed point µ φ, according to the knaster-tarski theorem. in fact, µ φ is the least φ-closed subset of u where a set x ⊆u is called φ-closed if φ(x ) ⊆ x . hence we have the closure principle for µ φ φ(µ φ) ⊆ µ φ as well as the induction principle if φ(x ) ⊆ x then µ φ ⊆ x for all subsets x of u (one often says “induction on µ φ”). in many cases φ has a definition of the form φ(x ) = {u ∈u|a(u)∨b(x , u)} where a(u) does not depend on x . then the inclusion φ(x ) ⊆ x is equivalent to ∀u ∈ u [(a(u) ⇒ x (u))∨(b(x , u) ⇒ x (u))] and the implications a(u) ⇒ x (u) and b(x , u) ⇒ x (u) are called induction base and step respectively, b(x , u) is called induction hypothesis. it is easy to see that µ , considered as an operation on monotone operators, is itself monotone, i.e. if φ(x ) ⊆ ψ(x ) for all x ⊆u , then µ φ ⊆ µ ψ. indeed, by the induction principle it suffices to show φ(µ ψ) ⊆ µ ψ. but φ(µ ψ) ⊆ ψ(µ ψ) ⊆ µ ψ. from the monotonicity of µ one can infer the following strong induction principle if φ(x ∩µ φ) ⊆ x then µ φ ⊆ x for the proof of strong induction we assume φ(x∩µ φ)⊆x which can be rewritten as ψ(x )⊆x where ψ(x ) := φ(x∩µ φ). clearly ψ is a monotone operator. thus µ ψ⊆x . hence it is enough to show µ φ ⊆ µ ψ. we prove this by induction on µ φ. by the monotonicity result above we have the reverse inclusion µ ψ ⊆ µ φ. hence, φ(µ ψ) = φ(µ ψ∩µ φ) = ψ(µ ψ) ⊆ µ ψ. example 1 (natural numbers) let r be the set of real numbers and define φ : p(r) → p(r) by φ(x ) := {0}∪{y + 1|y ∈ x}. then µ φ = n = {0, 1, 2, . . .}. the closure principle for n is equivalent to n(0)∧∀x (n(x) → n(x + 1)) while the induction principle for n is equivalent to (x (0)∧∀x (x (x) → x (x + 1)) →∀x (n(x) → x (x)). the strong induction principle is similar, but with the step formula ∀x (x (x) → x (x + 1)) weakened to ∀x ∈ n (x (x) → x (x + 1)). now we turn our attention to coinduction which is dual to induction. for the same reason a monotone operator φ has a least fixed point it has a greatest fixed point ν φ. it is the largest φ-coclosed subset of u where a set x ⊆ u is called φ-coclosed if x ⊆ φ(x ). consequently, we have coclosure: ν φ ⊆ φ(ν φ), and coinduction: if x ⊆ φ(x ) then x ⊆ ν φ. with a similar argument as for µ one can show that ν is monotone and deduce from that a strong coinduction principle: if x ⊆ φ(x ∪ν φ) then x ⊆ ν φ. we will see examples of coinduction in sect. 3. 3 / 15 volume 23 (2009) a coinductive approach to verified exact real number computation 3 cauchy and signed digit representations of real numbers the primary objects of study in this paper are the real numbers in the compact interval i := [−1, 1] = {x ∈ r | |x|≤ 1} since real numbers are per-se abstract objects, it is not possible to compute with them directly: one has to refer to a specific representation. two common representations of real numbers x ∈ i are (1) cauchy sequences (qn)n∈n where qn ∈ i is rational with |x−qn|≤ 2−n for all n ∈ n, (2) power series x = ∑i∈n di2 −(i+1) where di ∈ sd := {0, 1,−1} (signed digits). we consider the problem of producing a translation between the two representations that is formally proven to be correct. note that in a traditional approach a quite complex formal system is required to deal with this problem: we need sorts for reals, rationals, natural numbers, digits and infinite sequences, and, in addition to the usual arithmetic operations, coercion functions between these sorts. furthermore, the system must be able to express the recursive or iterative definitions of the higher-order functions translating between the two representations. on the other hand, the approach we are proposing and demonstrating here requires only one sort for real numbers with the usual first-order axioms for a real closed fields as well as the possibility to formalise inductive and coinductive definitions that were described in sect. 2. in the following, all individual variables (denoted by lower case letters) range over real numbers. we model the cauchy representation (1) by the formula a(x) := ∀n ∈ n an(x) where n is defined as in example 1 in sect. 2 and an(x) := ∃q ∈ q (|x|≤ 1∧|x−q|≤ 2−n) here q defines the rational numbers as a subset of the real numbers in the usual way with help of the predicate n. e.g. q(x) := ∃m, n, k ∈ n (k > 0∧xk = m−n) 1. the formula a(x) replaces the cauchy representation in the sense that from a constructive proof of it one can extract a program implementing an infinite sequence (qn)n ∈ n satisfying (1). note that this infinite sequence is not present in the formula a(x). details of how this extraction works in general will be given in sect. 4. we model the signed digit representation (2) by a coinductive definition, motivated by the observation that if x = ∑i∈n di2 −(i+1), then |x−d0/2| ≤ 1/2 and 2x−d0 = ∑i∈n di+12−(i+1). therefore, we set id (x) := |x−d0/2|≤ 1/2 and define c as the largest set (of real numbers) such that c(x) ⇒∃d ∈ sd(id (x)∧c(2x−d)) more formally c := νj where the set operator j : p(r) → p(r) is defined by j (x ) := {x|∃d ∈ sd(id (x)∧x (2x−d))}. now, the program extracted from a proof of c(x) will be an infinite stream of digits di ∈ sd such that (2) holds. in order to extract a program that translates between the representations (1) and (2) it will be sufficient to prove constructively the equivalence of the formulas ∀n ∈ n an(x) and c(x). 1 the bounded quantifiers we used are just shorthands: ∀x ∈ x b(x) stands for ∀x (x (x) → b(x)) and ∃x ∈ x b(x) stands for ∃x (x (x)∧b(x)). proc. avocs 2009 4 / 15 eceasst 4 program extraction: theory in this section we briefly describe the program extraction process in general, giving explanations of the main ideas priority over complete and formal definitions and correctness proofs. 4.1 the programming language the programming language that will be the target of the extraction process is a λ -calculus with constructors and pattern matching and (ml-)polymorphic recursive types. we let α range over type variables. type 3 ρ, σ ::= α | 1 | ρ + σ | ρ ×σ | ρ → σ | fix α . ρ in the definition of terms we let x range over term variables and c over constructors. it is always assumed that a constructor is applied to the correct number of arguments as determined by its arity. we will only use the constructors nil (nullary), left, right (unary), pair (binary), and infix α . ρ (unary) for every fixed point type fix α . ρ . term3m, n ::= x |c( ~m) |case m of{c1(~x1)→n1 ; . . . ; cn(~xn)→nn}|λ x.m |(m n) | rec x . m in a pattern ci(~xi) of a case-term all variables in ~xi must be different. the typing relation γ`m : ρ is defined inductively as follows. γ, x : ρ ` x : ρ γ ` nil : 1 γ, x : ρ ` m : ρ γ ` rec x . m : ρ γ, x : ρ ` m : σ γ ` λ x.m : ρ → σ γ ` m : ρ → σ γ ` n : ρ γ ` m n : σ γ ` m : ρ γ ` n : σ γ ` pair(m, n) : ρ ×σ γ ` m : ρ ×σ γ, x1 : ρ, x2 : σ ` k : τ γ ` case m of{pair(x1, x2) → k} : τ γ ` m : ρ γ ` left(m) : ρ + σ γ ` m : σ γ ` right(m) : ρ + σ γ ` m : ρ + σ γ, x1 : ρ ` l : τ γ, x2 : σ ` r : τ γ ` case m of{left(x1) → l ; right(x2) → r} : τ let ρ = ρ(~α) = fix α . ρ0(α,~α): γ ` m : ρ0(ρ(~σ ),~σ ) γ ` inρ (m) : ρ(~σ ) γ ` m : ρ(~σ ) γ, x : ρ0(ρ(~σ ),~σ ) ` k : τ γ ` case m of{inρ (x) → k} : τ equipped with a lazy semantics, which is described in [ber09b], this system can be viewed almost literally as a fragment of haskell. for example, a type fix α . ρ where ρ = ρ(α, β ) has no free type variables other than α and β , can be modelled in haskell by the data declaration data fixrho beta = infixrho (rho fixrho beta) provided rho alpha beta models ρ . a term rec x . m is modelled by let {x = m} in x. in fact, in sect. 5 we will present the extracted programs as haskell code (however, for the general considerations in the remainder of this section the system above is more convenient). it is easy to see that this system is ml-polymorphic: if ` m : ρ(~α), then ` m : ρ(~σ ) for arbitrary types ~σ . 5 / 15 volume 23 (2009) a coinductive approach to verified exact real number computation 4.2 the object language the object language l which is used to formalise the proofs we want to extract programs from is a first-order language extended by predicate variables and the possibility to form least and greatest fixed points of strictly positive (and hence monotone) operators. terms, r, s,t . . ., are built from constants, first-order variables and function symbols as usual. formulas, a, b,c . . ., are s = t, p(~t) where p is a predicate (predicates are defined below), a∧b, a∨b, a → b, ∀x a, ∃x a. a predicate is either a predicate constant p, or a predicate variable x , or a comprehension term {~x | a} where a is a formula and ~x is a vector of first-order variables, or an inductive predicate µ x .p, or a coinductive predicate ν x .p where p is a predicate of the same arity as the predicate variable x and which is strictly positive in x , i.e. x does not occur free in any premise of a subformula of p which is an implication. the application, p(~t), of a predicate p to a list of terms ~t is a primitive syntactic construct, except when p is a comprehension term, p = {~x | a}, in which case p(~t) stands for a[~t/~x]. we will frequently use common abbreviations such as p ⊆ q := ∀~x (p(~x) → q(~x)), {~t | a} := {~x | ∃~y (~x =~t ∧a)} where ~y are the variables occurring free in a or t, f ( ~p) := { f (~x) | p1(x1)∧. . .∧pn(xn)}, and so on. the proof rules for l are the usual ones for intuitionistic predicate calculus with equality [hey56, kle45, tro73], plus the axiom schemes for inductive and coinductive predicates that were discussed in sect. 2. in addition we allow any axioms expressible by non-computational formulas that hold in the intended model. falsity can be defined as ⊥ := µ x .x where x is a 0-ary predicate variable (i.e. a propositional variable). from the induction axiom for ⊥ it follows immediately ⊥→ a for every formula a. for our examples it will be sufficient to have only one sort for real numbers in l (a manysorted language would be possible as well) together with the usual algebraic equations and inequations for the operations on real numbers. 4.3 realisability the first step in program extraction is to assign to every l -formula a a type τ(a), the type of potential realisers of a. if a contains neither predicate variables nor the logical connective ∨ (disjunction), then we call it non-computational (otherwise computational) and set τ(a) = 1 (= () in haskell). otherwise, τ(p(~t)) = τ(p) (for predicates p the type τ(p) is defined below), τ(a∧b) = τ(a)×τ(b), τ(a∨b) = τ(a) + τ(b), τ(a → b) = τ(a) → τ(b), τ(∀x a) = τ(∃x a) = τ(a), for predicates p we define τ(p) by τ(x ) = αx where αx is a type variable assigned in a one-to-one fashion to the predicate variable x , τ({~x | a}) = τ(a), and τ(µ x .p) = τ(ν x .p) = fix αx . τ(p). as one can see, the mapping τ wipes out all first-order content of a formula (first-order terms and quantifiers), hence the type τ(a) can be viewed as the “propositional skeleton” of the formula a. this is necessarily so, since the sorts in our first order language (r in our example in sect. 3) have no counterpart in our programming language. the next step is to define for every formula a and every program term m of type τ(a) what it means for m to realise a, formally m r a. the latter is a formula in the language r(l ) which is obtained by adding to l a sort for program terms and extending all other constructions concerning formulas and proofs mutatis mutandis. the r(l )-formula m r a is in fact shorthand for proc. avocs 2009 6 / 15 eceasst r(a)(m) where the r(l )-predicate r(a) is defined by structural recursion on a, relative to a fixed one-to-one mapping from l -predicate variables x to r(l )-predicate variables x̃ with one extra argument place for program terms. if the formula a has the free predicate variables x1, . . . , xn, then the predicate r(a) has the free predicate variables x̃1, . . . , x̃n. simultaneously with r(a) we define a predicate r(p) for every predicate p, where r(p) has one extra argument place for program terms. if a is non-computational, then r(a) = {() | a}. if p is non-computational, then r(p) = {((),~x) | p(~x)}. in all other cases: for a non-computational formula a we set m r a := m = nil∧a, and r(p(~t)) = {x | r(p)(x,~t)} r(a → b) = { f | f (r(a)) ⊆ r(b)} r(a∨b) = inl(r(a))∪inl(r(b)) r(a∧b) = pair(r(a), r(b)) r(∃y a) = {x | ∃y (r(a)(x))} r(∀y a) = {x | ∀y (r(a)(x))} r(x ) = x̃ r({~y | a}) = {(x,~y) | r(a)(x)} r(µ x .p) = µ x̃ .r(p) r(ν x .p) = ν x̃ .r(p) we see that quantifiers and the quantified variable, although ignored by the program m and its type, of course do play a role in the definition of realisability, i.e. the specification of the program. finally, we sketch how to extract from a proof of a formula a a program term m realising a. assuming the proof is given in a natural deduction system the extraction process is straightforward and follows in most cases the usual pattern of the curry-howard correspondence: any non-computational axiom has the trivial program nil as extracted program. the introduction and elimination rules for conjunction, disjunction and implication correspond to pairing, projection, injections into a disjoint sum, pattern matching, lambda-abstraction, and application, respectively. the ∀-introduction rule, ∀-elimination rule, and the ∃-introduction rule are ignored, i.e. the extracted program of the conclusion is identical to the one of the premise. the ∃-elimination rule corresponds to application, more precisely, if the proofs of the premises ∃x a and ∀x (a → b) (where x is not free in b) have extracted programs m : τ(a) and n : τ(a) → τ(b), respectively, then the extracted program for the conclusion b is simply the application m n : τ(b). the extracted programs of closure, φ(µ φ) ⊆ µ φ, and induction, (φ(x ) ⊆ x ) ⇒ φ(µ φ) ⊆ x , are infix α . ρ := λ x.infix α . ρ (x) and itfix α . ρ := λ s.rec f . λ x.case x of{infix α . ρ (y) → s(mapα,ρ f y)} where it is assumed that τ(φ(x )) = ρ(α). the term mapα,ρ has type (α → β ) → ρ(α) → ρ(β ) and can be defined by induction on ρ(α). for coclosure, ν φ ⊆ φ(ν φ), and coinduction, (x ⊆ φ(x ))⇒x ⊆φ(ν φ), the extracted programs are outfix α . ρ := λ x.case x of{infix α . ρ (y)→y} and coitfix α . ρ := λ s.rec f . λ x.infix α . ρ (mapα,ρ f (s x)) we have the typings ` infix α . ρ : ρ(fix α . ρ) → fix α . ρ ` itfix α . ρ : (ρ(α) → α) → (fix α . ρ) → α ` outfix α . ρ : (fix α . ρ) → ρ(fix α . ρ) ` coitfix α . ρ : (α → ρ(α)) → α → fix α . ρ the soundness theorem, stating that the program extracted from a proof does indeed realise the proven formula, is shown in [ber09b]. soundness theorems for similar systems can be found in [tat98] and miranda-perea [mp05]. 7 / 15 volume 23 (2009) a coinductive approach to verified exact real number computation 5 program extraction: applications in this section we apply the program extraction procedure described in sect. 4 to a proof of the equivalence of the real number representations described in sect. 3. below we give a fairly detailed constructive proof of the equivalence which can be easily formalised in the object system described in sect. 4.2, and from which we then extract the program. before we do that we discuss a simple example that demonstrates the fact that it is indeed crucial for program extraction that proofs are constructive and no axioms other than the axioms for inductive and coinductive definitions and true non-computational axioms are used. the formula ∀x, y (x ≤ y∨y > x), although true in the real numbers, must not be used as an axiom because it is computational. we cannot prove it constructively either, because otherwise we could extract a (closed) program m : boole realising it, where boole := 1 + 1. this would mean that the formula, setting t := left(nil) and f := right(nil), ∀x, y ((m = t∧x ≤ y)∨(m = f∧y > x)) holds. since m is closed, either m = t or m = f. in the first case it would follow ∀x, y (x ≤ y) in the second case ∀x, y (x > y) which are both false statements (similar unprovability results were among kleene’s and kreisel’s original motivations for studying realisability). of course, we can prove constructively the relativised formula ∀x, y ∈ n (x ≤ y∨y > x) (by induction). the extracted program is a decision procedure for the ordering of natural numbers. since nat := τ(n(x)) = fix α . 1 + α the program works with the unary representation of natural numbers, more precisely, its type is nat → nat → boole. similarly, we can prove constructively ∀x, y ∈ q (x ≤ y∨y > x) and extract a program deciding the ordering on rational numbers. a formula which we can safely assume as an axiom is ∀x (a(x) → i(x)). clearly, this formula is true and it has the trivial realiser λ f .nil. 5.1 proofs the following lemma takes care of some simple technicalities in the main proof. lemma 1 (a) sd ⊆ q. (b) ∀q ∈ q∃d ∈ sd [q−1/4, q + 1/4]∩i ⊆ id . (c) ∀p ∈ q∃q ∈ q∩i∀x ∈ i|x−q|≤ |x− p|. proof. part (a) is obvious. for part (b) we do a case analysis on the position of q. for q < −14 choose d = −1, for −14 ≤ q ≤ 1 4 choose d = 0 and for 1 4 < q choose d = 1. it is easy to see that in all cases d is as required. for part (c) let p ∈ q be given. depending on whether p < −1 or |p|≤ 1 or p > 1 we set q := −1 or q := p or q := 1. the required property obviously holds. proposition 1 ∀x (c(x) ⇔ a(x)). proof. for the implication from left to right we prove ∀n ∈ n(c(x) ⇒ an(x)) by induction on n. base n = 0: if c(x), then clearly x ∈ i, i.e. |x|≤ 20. hence we can take q := 0 to satisfy a0(x). proc. avocs 2009 8 / 15 eceasst step: the induction hypothesis is ∀x(c(x) ⇒∃q|x−q|≤ 2−n). we have to show ∀x(c(x) ⇒ ∃q|x−q|≤2−(n+1)). assume c(x). by the coclosure principle for c we have id (x) and c(2x−d) for some d ∈ sd. set x′ := 2x−d. by induction hypothesis, |x′−q|≤ 2−n for some q. hence |x′−q| 2 ≤ 2−(n+1) 2 , i.e. |2x−d−q| 2 ≤ 2 −(n+1), i.e. |x− d2 − q 2|≤ 2 −(n+1), i.e. |x− d+q2 |≤ 2 −(n+1), so we may take q′ := d+q2 using lemma 1 (a). for the implication from right to left we need to show a ⊆ c. by applying coinduction it is sufficient to show a ⊆ j (a), i.e. ∀x(a(x)) ⇒∃d ∈ sd (id (x)∧a(2x−d))) assume a(x). then i(x) by the axiom discussed above. we have to find d ∈ sd such that id (x)∧∀n ∈ n∃q ∈ q∩i|(2x−d)−q|≤ 2−n using the assumption a(x) with n = 2, we obtain a q ∈ q∩i such that |x−q|≤ 14 . according to lemma 1 (b) there is some d ∈ sd such that [q−1/4, q + 1/4]∩i ⊆ id . now let n ∈ n. we have to find q ∈ q∩i such that |(2x−d)−q|≤ 2−n. we use the assumption a(x) with n + 1 and obtain q′ ∈ q∩i such that |x−q′|≤ 2−(n+1). since x ∈ id and because of lemma 1 (c) we may assume without loss of generality that q′ ∈ id . hence q := 2q′−d ∈ i and |(2x−d)−q| = 2|x−q′|≤ 2−n. 5.2 programs we begin our program extraction by declaring the types of the predicates sd and q. we do not bother deriving them pedantically following sect. 4, but define them in haskell in a convenient way. for q it is most convenient to use the build-in type of exact rational numbers. data sd = n | z | p deriving show type rat = rational next we extract programs from lemma 1. again, because the proofs are so simple, we do the extraction in an intuitive and non-pedantic way using build-in operations on the rational numbers. we also apply, here and in the following, some simplifications to types and extracted programs. for example, if b is computational, but a is not, we set τ(a∧b) = τ(a → b) = τ(b) (instead of 1×τ(b) and 1 → τ(b)) and adjust realisability and program extraction accordingly. lema :: sd -> rat lema = \d-> case d of {n -> -1; z -> 0; p -> 1} lemb :: rat -> sd lemb q | q < -1/4 = n | q > 1/4 = p | otherwise = z lemc :: rat -> rat lemc q | q < -1 = -1 | q > 1 = 1 | otherwise = q 9 / 15 volume 23 (2009) a coinductive approach to verified exact real number computation now we declare the data type τ(n): type nat alpha = either () alpha data nat = consnat (nat nat) for later use we define the successor operation and numerals on nat: suc :: nat -> nat suc n = consnat (right n) num :: int -> nat num n = if n <= 0 then consnat (left ()) else suc (num (n-1)) the program suc can be extracted from a proof that n is closed under successor. now we move on to a more interesting part, the extracted programs of the axioms for the inductive predicate n and the coinductive predicate c. below, sds stands for “signed digit stream”. mapnat :: (alpha -> beta) -> nat alpha -> nat beta mapnat = \f-> \z-> case z of {left u -> left () ; right x -> right (f x)} itnat :: (nat alpha -> alpha) -> nat -> alpha itnat = \step-> let {f = \n-> case n of {consnat z -> step (mapnat f z)}} in f type sds alpha = (sd,alpha) data sds = conssds (sds sds) mapsds :: (alpha -> beta) -> sds alpha -> sds beta mapsds = \f-> \z-> case z of {(d,x) -> (d,f x)} coitsds :: (alpha -> sds alpha) -> alpha -> sds coitsds = \f-> \x-> conssds (mapsds (coitsds f) (f x)) the type of the formula a(x) is type approx = nat -> rat finally, the programs extracted from prop. 1 are proplr :: sds -> approx proplr = \a-> \n-> itnat proplrstep n a proplrstep :: nat (sds -> rat) -> sds -> rat proplrstep = \z-> \a-> case z of {left u -> 0; right ih -> case a of {conssds (d,a’) -> (lema d + ih a’)/2}} proc. avocs 2009 10 / 15 eceasst proprl :: approx -> sds proprl = coitsds proprlstep proprlstep :: approx -> sds approx proprlstep = \f-> let d = lemb (f (num 2)) in (d, \n-> lemc (2 * f (suc n) lema d)) 5.3 results as an example, we compute the signed digit representation of 1√e ∈ i. since 1 √ e = e− 1 2 = ∞ ∑ i=0 (−12 ) i i! and the series converges at an exponential rate we define en := n ∑ i=0 (−12 ) i i! ∈ q and obtain an infinite sequence e = (en)n∈n realising the formula a( 1√ e ). feeding e into the program proplr we obtain a realiser of c( 1√e ), i.e. a signed digit representation of 1√ e . in order to display the stream in the usual haskell format we coerce sds into [sd]. e :: approx e n = sum [((-1/2)ˆi) / (fromintegral (product [1..i])) | i <[0..(fromintegral n’)]] where n’ = nat2int n nat2int :: nat -> int nat2int (consnat (left ())) = 0 nat2int (consnat (right n)) = 1 + nat2int n sds2stream :: sds -> [sd] sds2stream (conssds (d,a)) = d : sds2stream a sde :: [sd] sde = sds2stream (proprl e) *main> take 100 sde [p,z,p,z,n,p,z,n,p,n,z,z,p,n,p,z,n,z,p,n,p,z,z,z,z,z,n,z,z,p, z,n,p,z,z,z,z,n,z,p,n,p,z,n,z,z,z,z,p,n,z,p,z,z,z,z,z,z,z,n, z,p,z,z,z,n,p,n,p,z,n,z,p,z,z,n,p,n,p,z,n,p,n,z,z,p,z,n,p,n, p,n,p,n,p,n,z,p,z,n] 11 / 15 volume 23 (2009) a coinductive approach to verified exact real number computation we can check that this stream is correct by computing the corresponding floating point approximation and comparing it with the result obtained by floating point arithmetic (ironically, relying on the correctness of the latter). list2double :: [sd] -> double list2double = foldr av 0 where av d x = ((fromrational (lema d))+x)/2 *main> exp (-0.5) 0.6065306597126334 *main> list2double (take 100 sde) 0.6065306597126334 6 conclusion we presented a method for extracting certified programs from constructive proofs. the method is based on a variant of realizability that strictly separates the (abstract) mathematical model from the data types the extracted program is dealing with. the latter are determined completely by the propositional structure of formulas and proofs. this has the advantage that the abstract mathematical structures do not need to be ‘constructivised’. in addition, formulas that do not contain disjunctions are computationally meaningless and can therefore be taken as axioms as long as they are true. this enormously reduces the burden of formalization and turns in our opinion program extraction into a realistic method for the development of nontrivial certified algorithms. we used the problem of translating between different representations of real numbers as an example to illustrate the method in general, and to show the use of inductive and coinductive definitions in program extraction. currently, we are working on an extension of this work to the situation where not only real numbers, but also real functions are coinductively represented and where the underlying domain is extended to arbitrary separable metric spaces or even more general structures [ber09b, ber09a]. an important aspect of the program extraction method is the ability to import existing certified software. this is partly accounted for by the possibility to add statements as axioms for which programs provably realising them are given. but as least as important is the possibility to include existing trusted data structures (large integers exact rationals, etc.) together with efficient (and certified) implementations of basic operations. it is possible to extend our approach in this respect, for example, using a general theory of realisability based on equilogical spaces and assemblies [bbs04]. the method of program extraction including inductive definitions is implemented for example in the minlog system [bbs+98]. carrying out in minlog case studies involving coinduction as presented here requires an appropriate extension of the system. this is work in progress. proc. avocs 2009 12 / 15 eceasst bibliography [agd] agda. http://wiki.portal.chalmers.se/agda/. [bb85] e. bishop, d. bridges. constructive analysis. grundlehren der mathematischen wissenschaften 279. springer, berlin, heidelberg, newyork, tokyo, 1985. [bbs+98] h. benl, u. berger, h. schwichtenberg, m. seisenberger, w. zuber. proof theory at work: program development in the minlog system. in bibel and schmitt (eds.), automated deduction – a basis for applications. applied logic series ii, pp. 41– 71. kluwer, dordrecht, 1998. [bbs04] a. bauer, l. birkedal, d. s. scott. equilogical spaces. theor. comput. sci. 315(1):35–59, 2004. doi:http://dx.doi.org/10.1016/j.tcs.2003.11.012 [ber07] y. bertot. affine functions and series with co-inductive real numbers. math. struct. comput. sci. 17:37–63, 2007. [ber09a] u. berger. from coinductive proofs to exact real arithmetic. in grädel and kahle (eds.), computer science logic. lncs 5771, pp. 132–146. springer, 2009. [ber09b] u. berger. realisability and adequacy for (co)induction. in bauer et al. (eds.), 6th int’l conf. on computability and complexity in analysis. schloss dagstuhl leibniz-zentrum fuer informatik, germany, dagstuhl, germany, 2009. http://drops.dagstuhl.de/opus/volltexte/2009/2258 [bez07] m. bezem. the software model checker blast. journal on software tools for technology transfer 9(5-6):505–525, 2007. [bh08] u. berger, t. hou. coinduction for exact real number computation. theory of computing systems 43:394–409, 2008. doi:doi: 10.1007/s00224-007-9017-6 [brs+00] m. balser, w. reif, g. schellhorn, k. stenzel, a. programmiermethodik. formal system development with kiv. in fundamental approaches to software engineering, number 1783 in lncs. pp. 363–366. springer, 2000. [bs07] j. bradfield, c. stirling. modal mu-calculi. in blackburn et al. (eds.), handbook of modal logic. studies in logic and practical reasoning 3, pp. 721–756. elsevier, 2007. [cd06] a. ciaffaglione, p. di gianantonio. a certified, corecursive implementation of exact real numbers. theor. comput. sci. 351:39–51, 2006. [con86] r. constable. implementing mathematics with the nuprl proof development system. prentice–hall, new jersey, 1986. [coq] the coq proof assistant. http://coq.inria.fr/. 13 / 15 volume 23 (2009) http://wiki.portal.chalmers.se/agda/ http://dx.doi.org/http://dx.doi.org/10.1016/j.tcs.2003.11.012 http://drops.dagstuhl.de/opus/volltexte/2009/2258 http://dx.doi.org/doi: 10.1007/s00224-007-9017-6 http://coq.inria.fr/ a coinductive approach to verified exact real number computation [dij75] e. dijkstra. guarded commands, nondeterminacy and formal derivation of programs. comm. acm 18:453–457, 1975. [dij97] e. w. dijkstra. a discipline of programming. prentice hall ptr, upper saddle river, nj, usa, 1997. [dj78] b. dines, c. jones. the vienna development method: the meta-language. lncs 61. springer, berlin, heidelberg, new york, 1978. [eh02] a. edalat, r. heckmann. computing with real numbers: i. the lft approach to real number computation; ii. a domain framework for computational geometry. in barthe et al. (eds.), applied semantics lecture notes from the international summer school, caminha, portugal. pp. 193–267. springer, 2002. [flo67] r. floyd. assigning meaning to programs. in mathematical aspects of computer science. pp. 19–32. american mathematical society, 1967. [gnsw07] h. geuvers, m. niqui, b. spitters, f. wiedijk. constructive analysis, types and exact real numbers. math. struct. comput. sci. 17(1):3–36, 2007. [gri81] d. gries. the science of programming. springer, 1981. [vh67] j. van heijenoort (ed.). from frege to gödel. a source book in mathematical logic 1879–1931. harvard university press, cambridge, ma., 1967. reprinted 1970. [hey56] a. heyting. intuitionism: an introduction. north-holland, amsterdam. third revised edition 1971, 1956. [hoa97] t. hoare. an axiomatic basis for computer programming. comm. acm 12:567– 580, 1997. [hw03] j. hughes, m. warnier. the coinductive approach to verifying cryptographic protocols. in wirsing et al. (eds.), recent trends in algebraic development techniques. lncs 2755, pp. 268–283. springer, berlin, 2003. [jr97] b. jacobs, j. rutten. a tutorial on (co)algebras and (co)induction. eatcs bulletin 62:222–259, 1997. [kle45] s. c. kleene. on the interpretation of intuitionistic number theory. jour. symb. logic 10:109–124, 1945. [kmm00] m. kaufmann, p. manolios, j. s. moore. computer-aided reasoning: an approach. kluwer, 2000. [kre59] g. kreisel. interpretation of analysis by means of constructive functionals of finite types. constructivity in mathematics, pp. 101–128, 1959. [ml84] p. martin-löf. intuitionistic type theory. bibliopolis, 1984. proc. avocs 2009 14 / 15 eceasst [me07] j. r. marcial-romero, m. h. escardo. semantics of a sequential language for exact real-number computation. theor. comput. sci. 379(1-2):120–141, 2007. [mil80] r. milner. a calculus of communicating systems. springer, 1980. [mp05] f. miranda-perea. realizability for monotone clausular (co)inductive definitions. electr. notes in theoret. comput. sci. 123:179–193, 2005. [mos99] l. s. moss. coalgebraic logic. annals of pure and applied logic 96, 1999. [npw02] t. nipkow, l. c. paulson, m. wenzel. isabelle/hol — a proof assistant for higher-order logic. lncs 2283. springer, 2002. [orss98] s. owre, j. rushby, n. shankar, d. stringer-calvert. pvs: an experience report. in hutter et al. (eds.), applied formal methods—fm-trends 98. lecture notes in computer science 1641, pp. 338–345. springer-verlag, boppard, germany, oct 1998. http://www.csl.sri.com/papers/fmtrends98/ [pnu77] a. pnueli. the temporal logic of programs. in in proc. 18th ieee symposium on foundation of computer science. lncs 902, pp. 350–364. ieee, 1977. [rut00] j. rutten. universal coalgebra: a theory of systems. theoretical computer science 249(1):3–80, 2000. [sch09] h. schwichtenberg. realizability interpretation of proofs in constructive analysis. theory comput. sys., to appear, 2009. [tat98] m. tatsuta. realizability of monotone coinductive definitions and its application to program synthesis. in parikh (ed.), mathematics of program construction. lecture notes in mathematics 1422, pp. 338–364. springer, 1998. [tro73] a. troelstra. metamathematical investigation of intuitionistic arithmetic and analysis. lecture notes in mathematics 344. springer, 1973. 15 / 15 volume 23 (2009) http://www.csl.sri.com/papers/fmtrends98/ introduction induction and coinduction cauchy and signed digit representations of real numbers program extraction: theory the programming language the object language realisability program extraction: applications proofs programs results conclusion security in open model software with hardware virtualisation – the railway control system perspective electronic communications of the easst volume 33 (2010) proceedings of the fourth international workshop on foundations and techniques for open source software certification (opencert 2010) security in open model software with hardware virtualisation – the railway control system perspective johannes feuser and jan peleska 14 pages guest editors: luis s. barbosa, antonio cerone, siraj a. shaikh managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst security in open model software with hardware virtualisation – the railway control system perspective johannes feuser1 and jan peleska2 1 jfeuser@informatik.uni-bremen.de 2 jp@informatik.uni-bremen.de department of mathematics and computer science university of bremen, germany http://www.informatik.uni-bremen.de/agbs/index e.html abstract: using the openetcs initiative as a starting point, we describe how open software can be applied in combination with platform-specific, potentially closedsource extensions, in the development, verification, validation and certification of safety-critical railway control systems. we analyse the safety and security threats presented by this approach and discuss conventional operating system partitioning mechanisms, as well as virtualisation methods with respect to their potential to overcome these problems. furthermore, we advocate a shift from open source to open models, in order to increase the development efficiency of combined open and proprietary solutions. keywords: openetcs, open source, open model, security, hardware virtualisation 1 introduction 1.1 background by the end of 2009 german railways initiated a discourse on the possible benefits of using free/libre open source software (floss) in railway control systems, with special focus on the european train control system etcs. this initiative was labelled openetcs [has09b, has09a]. reviewing evidence where security threats had been purposefully integrated into closed-source commercial software products, the author argued that open source software could be useful – perhaps even mandatory in the future – to ensure safety and security of railway control systems: even though the standards applicable for safety-critical systems software development in the railway domain [cen01a, cen99] require independent-party verification and validation, the complexity of the source code on the one hand and the limited budget available for v&v on the other hand can only mitigate the threat of safety and security vulnerabilities, but cannot guarantee to uncover all compromising code components inadvertently or purposefully injected into the code. as a consequence, in addition to the v&v efforts required by the standards, the broad peer-review enabled by publicly available software could really increase software safety and security1. german railways indicated that also open proofs might be necessary to complement 1 following [lev95] we agree that safety and also security are emergent properties, that is, they can only be attributed to complete systems, and not to software alone. when we use the terms software safety and software security in this paper, we mean absence of software malfunctions that may lead to safety or security hazards on system level. 1 / 14 volume 33 (2010) mailto:jfeuser@informatik.uni-bremen.de mailto:jp@informatik.uni-bremen.de http://www.informatik.uni-bremen.de/agbs/index_e.html security in open model software with hardware virtualisation the open source code, but they did not comment on the necessity to publish software models, specifications and on the potential of an open certification process. initially, the openetcs position statement stirred considerable interest, but has become somewhat quiet recently, at least on the public level. we suspect that this is due to the fact that railway suppliers are currently evaluating the impact of these requirements on their business models which are still based on closed software and supplier-specific solutions, in order to protect their intellectual property. in parallel german railways will still be investigating the leverage it may already have or will gain in the future on its suppliers in order to enforce the open software idea2. should german railways – potentially supported by research communities investigating the potential of open source software in the safety-critical domain – succeed in promoting openetcs, this would automatically become an international european topic: since etcs is a european effort to provide high-speed railway transport across borders, and since suppliers in many european countries contribute to etcs systems and software development, success or failure of the openetcs initiative will eventually be established on european level, and not just nationally in germany. 1.2 objectives and overview this contribution is a combination of a position paper and an elaboration of solution approaches to the openetcs scenario. we argue in section 2 that the underlying development, v&v and certification approaches enforced by the standards [cen01a, cen99] require that not only software, proofs (or semi-formal verification arguments) and verification tools should be published, but that the open-source paradigm should be lifted to an open-model paradigm, in combination with open code generators and v&v tools. our expectation is that – due to functional extensions, adaptations to specific hardware and national rules with impact on railway control algorithms – the open source software will nearly always have to be modified and/or enhanced by platform-specific code (section 3). these adaptations may still be closed software or – even if made publicly available – not be of sufficient general interest to stimulate a public peer reviewing process. as a consequence we envision a scenario where future railway control systems are developed as enhancements and refinements of open models where a portion of the code has been certified according to the opencert paradigm and will remain unchanged in most applications, but this re-usable core is complemented by less trustworthy additions. analysing the remaining safety and security threats of this scenario, we show that it can be compared to the grey-channel paradigm where safety-critical dependable distributed applications have to communicate over potentially unsafe channels. this situation is nowadays standard practice in distributed railway control applications and the standard [cen01c] defines how to ensure safety and security of the resulting system, at the potential risk of reducing the availability of the system, due to fail-safe blocking of further operation. based on the grey-channel scenario we discuss in section 4 how conventional operating systems mechanisms may help to reduce the safety and security risks presented by this scenario. as a final step (section 5) we advocate the utilisation of virtualisation in order to further reduce 2 needless to say that, due to the possibility to re-use floss, german railways also expect a decrease of software development costs by the openetcs initiative, because suppliers would not need to re-implement major portions of the publicly available railway control algorithms. proc. opencert 2010 2 / 14 eceasst these risks: trusted core software and target-specific adaptations run in different virtual machines, communicating according to the grey channel paradigm as if distributed over a network. we discuss the impact of this approach on the future development of virtual machines, hypervisors and communication interfaces. section 6 contains the conclusion. 1.3 related work our work is motivated by the challenges formulated by german railways and the openetcs initiative [has09b, has09a], and uses the development and railway application scenarios presented there as a starting point. certification issues of safety-critical systems in general are described in [sto96]; the work presented here is specialised on the railway domain where the standards [cen01a, cen03, cen99, cen01b, cen01c] apply. while – as described in [sc09] – quality and certification issues concerning open software in general still leave many open questions to be tackled, the railway control systems scenario described in this paper relies on certification according to the rules defined in the standards listed above. the only differences to today’s standard procedure are that (1) the certified code and its associated documentation are made publicly available and (2) it may be necessary to re-certify the software as soon as adaptations and extensions have been made for a concrete system implementation. the model-driven approach advocated in this paper is based on domain-specific modelling as decribed in [kt08] because it is well-known that the utilisation of domain-specific description formalisms and associated automated code generation and mechanised model-based testing and verification has high potential in the railway domain [hp03, hpk09, mew09]. it has to be emphasised, however, that the open-model approach and the security analyses presented in this paper only rely on the availability of an arbitrary specification formalism that is suitable for formal verification and automated code generation. even conventional uml2 [omg03a, omg03b] (and potential augmentations by means of the profile mechanism) are suitable if a well-defined model-to-text (i. e. code) transformation is used to associate a transformational semantics with the semi-formal uml model [bbhp06]. 2 from open source to open model software the terms open source software (oss) and free/libre open source software (floss) refer to source code. certifiable train control systems software, on the other hand, has to be complemented by a collection of additional artifacts contributing to the safety case, that is, the comprehensive and structured evidence justifying that the resulting system will guarantee safe operation. among others (for details see [cen01a, cen99]), the list of these artifacts comprises software specification and design models and complete records of all v&v measures taken to ensure software code compliance with its applicable specifications, as well as evidence showing how all functional and structural aspects of the software have been throughly tested and verified3. it is well known that for systems of highest assurance level4 the effort for elaboration of the safety 3 the term verification comprises formal mathematical analyses, as well as semi-formal reviews and inspections. 4 the so-called system integrity level sil-4 and the associated software safety assurance level ssas-4. 3 / 14 volume 33 (2010) security in open model software with hardware virtualisation case is frequently higher than the proper software development effort. as a consequence, just source code without the additional artifacts mentioned above would be nearly worthless. additionally, as soon as floss code has to be adapted, this will become quite hard and often invalidate previous v&v results if these adaptations have not been guided by a systematic approach, preferably based on a software model giving indications how to modify the software in an admissible way. due to these considerations we are convinced that oss/floss can only be applied successfully in the railway control systems domain if code is accompanied by or – even better – embedded in free/libre open models. following the principles of object-oriented modelling, the description formalism should be based on a meta-meta model that is publicly available as in the case of the omg meta object facility [omg04] or in the case of the graph, object, property, role and relationship (goprr) meta-meta model introduced in [kt08] for the design of domain-specific languages, so that the model could be unambiguously interpreted and processed by various development and v&v tools. additionally, these models should clearly indicate where platform-specific or application-specific changes are admissible by means of class inheritance, overriding and overloading of operations or by means of adding components with admissible interfaces. as sketched in figure 1 we suggest the terms open meta metamodel, open metamodel, and open model for the higher-level abstractions required “above” the open software. figure 1. model instances open model instances meta metamodel metamodel instantiates model instantiates application instantiates open meta metamodel open metamodel instantiates open model instantiates open source instantiates figure 1: denomination for open domain-specific modelling (dsm). a typical benefit from this approach would be that certification credit for module verification could be re-used for all software methods or functions that have not been changed for the platform-specific adaptation. on the other hand, these adaptations may require extensive new v&v activities and associated re-certification for the complete system, if their impact on the re-usable components is not clearly visible. this problem will be analysed more closely in the proc. opencert 2010 4 / 14 eceasst sections below. re-usable certifiable open model software also requires a specification of the admissible tool chain to be used for model-to-text transformations, compilation and linking and v&v regression activities, because otherwise it could not be guaranteed that the software build process would be performed correctly and the v&v process would lead to trustworthy results. these tool aspects, however, are beyond the scope of this paper. 3 security analysis for the open model software scenario figure 2 shows a very general scenario how a platform-specific adaption of an open model and associated floss could compromise the resulting system. this example has one model implementation which is directly generated from the open model, and therefore gets certification credit by means of re-use for all component-specific v&v artifacts. suppose that sub-models 2 and 3 had to be newly developed for the platform-specific solution, resulting in supplier implementations 1 and 2. it is obvious that component-specific v&v measures have to be performed for these new implementations. we are interested in the question whether some certification credit could be re-used for model implementation 1 on software integration level, for example, the v&v measures previously taken to show that this implementation cooperates correctly with other components directly generated from the open model. unfortunately, this is not true without further restrictions: if implementation 2 is malicious it may compromise both model implementation 1 and supplier implementation 1, either by sending corrupted data through their designated interfaces or through covert channels which were not intended to be utilised according to the model5, or by means of unintended resource usage creating denial of service attacks. as a consequence no certification credit can be re-used for model implementation 1 on software integration level: all corresponding v&v artifacts have to be re-produced in order to justify that none of the platform-specific implementations can compromise the resulting system through any of the other implementations. in the two following sections we will analyse suitable measures to counter the threat presented by such malicious implementations. 4 partitioning as seen in the previous section, the creation of faulty or malicious supplier implementations in an open model scenario cannot be completely avoided, but their impact on other software components should be minimised. modern operating systems offer a number of standard mechanisms to cope with these situations. all of these mechanisms may be summarised under the keyword partitioning, which has to be enforced in the resource domain and in the time domain. in the resource domain partitioning means that faulty or malicious components cannot interfere with the (legal) access of another software component to the resource and cannot access any resource without proper authorisation. typical resources in the embedded systems domain 5 e. g., by writing to illegal memory addresses if all implementations run as operations or threads in the same address space. 5 / 14 volume 33 (2010) security in open model software with hardware virtualisation open model (verified and validated) open source (verified and validated) open meta metamodel open metamodel instantiates model 1 instantiates model 2 instantiates model 3 instantiates model implementation 1 generates supplier implementation 1 instantiates supplier implementation 2 (malicious) instantiates instantiates comunicates comunicates comunicatescompromises compromises figure 2: possible security threats in open model software combined with platform-specific adaptations. proc. opencert 2010 6 / 14 eceasst are cpu cores, memory, hardware and software interfaces and operating system resources like semaphores, message queues and others. the traditional way of implementing resource partitioning is through different privilege levels for application and operating system layer, virtual address spaces supported by memory management units, encapsulation of resource access by means of system calls and kernel access mechanisms and access control mechanisms enforced by the operating system [sta08a, sta08b]. currently, resource partitioning is typically static for safety-critical embedded systems, since the dynamic allocation and de-allocation during system operation is hard to verify, or – as in the case of dynamic memory partitioning with paging – unsuitable for the embedded domain as long as suitable solid-state disks are not available. in the time domain partitioning implies that corrupt components may not access any resource – in particular, the cpu and the communication interfaces – for an undue amount of time, thereby creating denial of service attacks. time partitioning is typically enforced by means of schedulers; prominent examples are partition (process) schedulers complying with the arinc specification 653p1-2 [ari05] defining a distributed operating system as used in modern avionics (e. g. airbus a380)6. on the interface level, the avionics full-duplex switched ethernet network guarantees fixed communication bandwidths for different communication links by means of an on-board scheduler for package transmission [ari09] (also used in the airbus a380 and in modern boeing aircrafts). alternatively, the time triggered protocol (ttp) [ttp10] assigns temporal communication slots to processes. 5 hardware virtualisation with open models para virtualisation. the conventional mechanisms enforcing partitioning described in the previous section have the draw back that they require all software components to run under the regime of a single operating system. at least in the current situation, where several on-board train controllers are required in order to cope with national boundary conditions, this is disadvantageous for openetcs, because of the diversity of supplier hardware and associated operating systems. this problem also has implications on the open model approach: if the code generated from these models relies on the availability of specific operating system mechanisms (for example, a certain scheduling policy), this code may only run on platforms whose operating systems support these mechanisms. this impairs the potential re-use advantages of the open model approach in a considerable way. as a solution to this problem we suggest hardware virtualisation, where – controlled by a hypervisor and a host operating system – several guest operating systems may run simultaneously in so-called virtual machines (vm) on the same hardware [vmw07]. a hypervisor works as a virtual machine monitor (vmm) which either dispatches sensitive instructions issued by a guest operating system that require kernel privileges to the hardware or emulates these instructions by means of interaction with the host operating system. in the latter case the hypervisor may have the capabilities of a micro kernel in its own right and may even render an additional host operating system superfluous. this is the case when so-called para virtualisation is applied: 6 standard [ari05] only requires to assign guaranteed time slices to partitions in round-robin manner. this does not guarantee that applications will meet their deadlines. in [mhg+09], a more sophisticated approach based on earliest deadline first scheduling is described 7 / 14 volume 33 (2010) security in open model software with hardware virtualisation here the sensitive actions of guest operating systems are not dealt with on machine instruction level, but instead the guest utilises a pre-defined hypervisor api providing hardware access on a higher level of abstraction, thereby considerably improving the performance of applications running in virtual machines (see [tan08, pp. 568] for a more detailed overview). the most important micro kernel capabilities that we suggest for hypervisors supporting para virtualisation are • a preemptive round robin scheduler enforcing fixed execution time windows for each virtual machine, similar to the inter-partition scheduling requirements of [ari05], • driver management for hardware interface access with explicit assignment of interface visibility to selected virtual machines, • control of the memory management unit to enforce memory partitioning and assign either fixed memory portions to virtual machines or limit each vm’s amount of dynamically allocated memory, • communication mechanisms supporting message-based inter-vm and remote communication. open model scenario with virtualisation. in this virtualisation scenario, the code portions generated directly from the model without platform-specific adaptations would run in one virtual machine, and platform-specific adaptations would run in separate virtual machines. since each virtual machine mimics a complete computer with its local operating system, platform hardware and peripherals, resource partitioning is easily enforced: hardware interfaces that should not be accessed by a group of software components are simply not visible in their “virtual computer hardware”. the utilisation of main memory could be limited by the hypervisor, and the separation of memory address spaces is already enforced on virtual machine level. communication between virtual machines can be performed, for example, by means of a socket interface. the effect of virtualisation is similar to several distributed application programs cooperating by means of remote communication. the impact of a malicious or otherwise faulty component is reduced to corrupt communication behaviour on the intended interfaces: it is impossible to influence the outside world by other interfaces but the ones configured for the virtual machine. since from the viewpoint of the receiver it cannot be distinguished whether the sender or the communication channel is corrupt, this situation is already well understood in today’s distributed railway control applications communicating over public networks known as grey channels: the safety-relevant components have to be developed on the basis that any type of error may occur on the grey channel, because this is a communication medium whose hardware and software has not been developed with the same assurance level as the safety-critical application itself. as a consequence, the safety-relevant component has to cope with repetition, deletion, insertion, resequence, corruption and delay of messages and guarantee fail-safe behaviour in presence of these faults. the defence mechanisms against these types of faults or attacks have to comply with the standard [cen01c]. applying the concept of hardware virtualisation to the initial open model scenario in figure 2 leads to the revised scenario depicted in figure 3. it also contains the generated model implementation and the two supplier implementations. in contrast to figure 2 all supplier implementations proc. opencert 2010 8 / 14 eceasst open model (verified and validated) open source (verified and validated) virtual machine 1 virtual machine 2 open meta metamodel open metamodel instantiates model 1 instantiates model 2 instantiates model 3 instantiates model implementation 1 generates supplier implementation 1 instantiates supplier implementation 2 (malicious) instantiates instantiates comunicates comunicates comunicates figure 3: hardware virtualisation for open models 9 / 14 volume 33 (2010) security in open model software with hardware virtualisation are now locked in their own virtual machines. this ensures that the malicious implementation cannot compromise any other part of the software through covert channels or abuse of resources, while a communication of legal or corrupted data over the intended channels is possible. the prevention of undue bandwidth consumption on hardware interfaces can be handled by means of scheduled i/o as described in section 4. as a consequence, the need of certified high-integrity hypervisors or host operating systems arises. the effort to develop, verify and certify these is justified as soon as the hardware platform can be re-used in different application scenarios, so that hypervisor or host operating system would be re-used as well. certification issues. we advocate the following development, validation and certification approach in the open-model scenario with virtualisation as described above: • the hardware platforms for railway control systems should be equipped with a hypervisor possessing the micro kernel qualities listed above. • this hypervisor should be open source and fully certified according to the aforementioned standards and according to the highest assurance level ssas-4, because all further assurance considerations depend on the trustworthiness of this component. • the re-usable core of the open-model software should be developed and fully validated with respect to one suitable operating system. in particular, the safe behaviour in presence of corrupt interface data received over a grey channel can be checked once and for all. • platform-specific or other functional adaptations should only be admissible as model derivations that may run in separate virtual machines which do not host the re-usable core software7. • the adaptations are again validated according to the applicable railway standards, running in an operating system possibly differing from the one hosting the re-usable core. • both the re-usable core and the adaptations use a remote communication paradigm to communicate with each other and integrate the required protection mechanisms for grey channel communication. • the admissible operating systems for re-usable core and adaptations have to comply with the hypervisor api according to the para virtualisation paradigm. • for an integrated hw/sw system consisting of several virtual machines with guest operating systems hosting the re-usable core and one or more adaptations, certification credit for the local validation activities8 already performed can be granted. • for certification of the integrated hw/sw system it remains to validate the following structural, functional and non-functional system properties: 7 so, for example, simple overloading of some operations in a class belonging to the re-usable core would not be allowed. 8 such as module tests and sw integration tests, or partitioning properties for different processes that belong to the same adaptation, and will therefore run in the same vm on the target system. proc. opencert 2010 10 / 14 eceasst – correct communication among virtual machines and between vms and interfaces. – correct functional behaviour of the integrated system: to this end, only functional requirements involving two or more virtual machines have to be tested. – performance and robustness in avalanche (stress) situations. proof of concept. we intend to substantiate the advantages of open model openetcs advocated so far by means of a case study. for this purpose the etcs would be particularly well-suited because the existing open standard [etc07] may serve as an informal specification, to be formalised as a model conforming to our domain-specific meta model which is currently under development (see section 2). typically, the model holds objects directly corresponding to hardware elements like sensors or actuators, e.g. a reader device for balises [etc06]. such elements are often subject to supplier-specific implementations. to compare conventional operating system methods like process scheduling and memory management with the usage of hardware virtualisation, effects on the rest of the software have to be measured for both cases, in presence of one or more malicious supplier implementations. therefore we will purposefully generate “supplier” implementations showing the relevant types of malicious behaviours, based on a formal threat model. examples for these threats are: • denial of service attacks on – cpu bandwidth, – network interface bandwidth, – software interfaces of other objects, • injection of false data to software interfaces of other objects, • infinite blocking of calls by other objects. the results of these tests with and without hardware virtualisation could be directly compared and would lead to a conclusion about the efficiency of the virtualisation approach. it is obvious that hardware virtualisation cannot prevent all of the above mentioned attacks from affecting other software components. therefore the fault tolerant behaviour of software implementations is highly relevant. a possible solution would be the utilisation of a standardised interface library, e.g. corba [hv99], providing methods to handle time-outs and other related problems. corba is not needed to be included in the metamodel, but only in the code generator [kt08]. therefore, this approach would not add additional complexity to the metamodel and its model instances. the distribution of the software as open models is another aspect of the concepts proposed here. to attract a community of substantial size and adequate competence it is crucial to provide a comprehensive tool chain with the open models. obviously, the editors and compilers sufficient for open source distribution have now to be complemented with meta-modelling tools, modelling tools and code generators under open source licenses. moreover, the tool set should be extended by a simulation and visualisation platform so that different solutions could be tried out without the availability of real-world railway infrastructure. 11 / 14 volume 33 (2010) security in open model software with hardware virtualisation 6 conclusion we have described an approach for combining open source software and proprietary systemspecific code for the development of certifiable railway control systems. following the certification requirements of applicable standards in the railway control systems domain, this approach requires not only code, but also models and v&v artefacts to be made publicly available. for ensuring the safety of a mixed open/closed source system, we have analysed the support mechanisms offered by today’s operating systems in order to prevent software components of minor trustworthiness to corrupt the behaviour of the trusted safety-critical core. in particular, we advocate virtualisation mechanisms to encapsulate components of different assurance levels for achieving fault containment. virtual machines running components of different assurance levels may communicate according to the grey channel paradigm which is already well understood in today’s distributed railway control applications. our contribution was intended as a position statement and an indication of promising solutions. the justification of these claims is currently elaborated by means of case studies based on the etcs specification [etc07, etc06] and the positive train control (ptc) system concept [ptc10]. to this end, a domain-specific description formalism specialised on the railway control system domain and following the concepts explained in [hp03, hpk09, mew09] will be used. the technical effort for substantiating a proof of concept should be accompanied by an open discussion about how to attract an open source community of sufficient size to the openetcs idea: only if the number of actively contributing members is big enough, the desired effect of quality improvement by peer-review, test or analysis can be expected. we believe that such numbers can be reached because – due to the complexity of control objectives on the one-hand and to their illustrative meaning on the other hand – this application domain has always attracted practitioners and researchers in the safety-critical systems and formal methods domains. though this paper focused on the railway domain, we expect that the approach described here will be valuable for other safety-relevant domains as well, in particular for avionic systems. our work has been influenced by the experience of the second author with validation of safety-critical railway control and avionic systems. acknowledgements. the first author has been supported by siemens ag through a research grant of the graduate school on embedded systems gesy at the university of bremen (http://www.informatik.uni-bremen.de/gesy). references [ari05] avionics application software interface, part 1, required services. aeronautical radio, inc., 2551 riva road, annapolis, maryland 21401-7435, 12 2005. [ari09] aircraft data network, part 7, avionics full-duplex switched ethernet network. aeronautical radio, inc., 2551 riva road, annapolis, maryland 214017435, 09 2009. proc. opencert 2010 12 / 14 eceasst [bbhp06] k. berkenkötter, s. bisanz, u. hannemann, j. peleska. the hybriduml profile for uml 2.0. international journal on software tools for technology transfer (sttt) 8(2):167–176, january 2006. special section on specification and validation of models of real time and embedded systems with uml. [cen99] cenelec. en 50126 railway applications the specification and demonstration of reliability, availability, maintainability and safety (rams). cenelec european committee for electrotechnical standardization, central secretariat: rue de stassart 35, b 1050 brussels, 09 1999. [cen01a] cenelec. en 50128 railway applications communications, signalling and processing systems software for railway control and protection systems. cenelec european committee for electrotechnical standardization, central secretariat: rue de stassart 35, b 1050 brussels, 03 2001. [cen01b] cenelec. en 50159-1. railway applications -communication, signalling and processing systems part 1: safety-related communication in closed transmission systems. 2001. [cen01c] cenelec. en 50159-2. railway applications -communication, signalling and processing systems part 2: safety related communication in open transmission systems. 2001. [cen03] cenelec. en 50129 railway applications communication, signalling and processing systems safety related electronic systems for signalling. cenelec european committee for electrotechnical standardization, central secretariat: rue de stassart 35, b 1050 brussels, 02 2003. [etc06] ertms/etcs class 1 system requirements specification. 24-02 2006. issue 2.3.0. [etc07] ertms/etcs functional requirements specification frs. 21-07 2007. version 5.0. [has09a] k. r. hase. openetcs ein vorschlag zur kostensenkung und beschleunigung der etcs-migration. signal +draht 10, 10 2009. [has09b] k. r. hase. openetcs open source software für etcs-fahrzeugausrüstung. signal +draht 12, 12 2009. [hp03] a. e. haxthausen, j. peleska. generation of executable railway control components from domain-specific descriptions. in proceedings of the symposium on formal methods for railway operation and control systems (forms’2003), budapest/hungary. pp. 83–90. l’harmattan hongrie, may 15-16 2003. [hpk09] a. e. haxthausen, j. peleska, s. kinder. a formal approach for the construction and verification of railway control systems. formal aspects of computing 17, december 2009. doi: 10.1007/s00165-009-0143-6. 13 / 14 volume 33 (2010) security in open model software with hardware virtualisation [hv99] m. henning, s. vinoski. advanced corba programming with c++. addisionwesley publishing company, 1999. [kt08] s. kelly, j.-p. tolvanen. domain-specific modeling. john wiley & sons, inc., 2008. [lev95] n. g. leveson. safeware. addison-wesley, 1995. [mew09] k. mewes. domain-specific modelling of railway control systems with integrated verification and validation. phd thesis, university of bremen, 2009. [mhg+09] a. mancina, j. herder, b. gras, a. tanenbaum, g. lipari. enhancing a dependable multiserver operating system with temporal protection via resource reservation. real-time systems 43:177–210, 2009. [omg03a] omg. uml 2.0 infrastructure specification, omg adopted specification. http://www.omg.org/cgi-bin/apps/doc?ptc/03-09-15.pdf, september 2003. [omg03b] omg. uml 2.0 superstructure specification, omg adopted specification. http://www.omg.org/cgi-bin/apps/doc?ptc/03-08-02.pdf, august 2003. [omg04] omg. meta object facility (mof) 2.0 core specification. http://www.omg.org/cgibin/apps/doc?ptc/04-10-15.pdf, october 2004. [ptc10] positive train control wikipedia. url, http://en.wikipedia.org/wiki/positive train control, 2010. [sc09] s. a. shaikh, a. cerone. towards a metric for open source software quality. in proceedings of the third international workshop on foundations and techniques for open source software certification (opencert 2009). volume 20. 2009. [sta08a] w. stallings. operating systems: internals and design principles. in [sta08b], chapter 7 8, pp. 353 – 453, 2008. [sta08b] w. stallings. operating systems: internals and design principles. prentice hall, 2008. [sto96] n. storey. safety critical computer systems. addison-wesley longman publishing co., inc. boston, ma, usa, 1996. [tan08] a. s. tanenbaum. modern operating systems. pearson, 2008. [ttp10] real-time systems research group: the ttp protocols. url, http://www.vmars. tuwien.ac.at/projects/ttp/ttpmain.html, 06 2010. [vmw07] vmware. understanding full virtualization, paravirtualization, and hardware assist. 08 2007. white paper. proc. opencert 2010 14 / 14 http://en.wikipedia.org/wiki/positive_train_control http://en.wikipedia.org/wiki/positive_train_control http://www.vmars.tuwien.ac.at/projects/ttp/ttpmain.html http://www.vmars.tuwien.ac.at/projects/ttp/ttpmain.html introduction background objectives and overview related work from open source to open model software security analysis for the open model software scenario partitioning hardware virtualisation with open models conclusion towards generalizing visual process patterns electronic communications of the easst volume 25 (2010) proceedings of the workshop visual formalisms for patterns at vl/hcc 2009 towards generalizing visual process patterns christian soltenborn and gregor engels 10 pages guest editors: paolo bottoni, esther guerra, juan de lara managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst towards generalizing visual process patterns christian soltenborn and gregor engels university of paderborn {christian,engels}@uni-paderborn.de abstract: visual process patterns (vpp) is a visual language to describe constraints on the behavior of uml activities. they have been developed for the sake of formulating and verifying requirements on business process models in a visual, intuitive way (with uml activities being one possible description language). in the vpp approach, a visual process pattern is translated into an ltl formula, which can then be verified against a transition system describing the behavior of the activity under consideration. in this paper, we aim at generalizing vpp. we show how to formulate patterns more generally, using an enhanced version of the concrete syntax of the behavioral model under consideration. additionally, we describe how these more general patterns can be verified against a model’s behavior. keywords: pattern, semantics, verification, business process, activity, state machine 1 introduction business processes are a crucial part of many companies’ business, and therefore have to fulfill certain domain specific and quality requirements. such requirements can e.g. be specified by means of so-called process patterns. for instance, such a process pattern can state that “after each production action a quality check has to be performed prior to delivery”. given the complexity of many business processes, it would be desirable to be able to automatically verify such requirements against a particular business process. this implies that the modeler has to somehow formalize the requirements. unfortunately, the semantic gap between a visual, flow-oriented business process model and most formal specification languages (e.g., temporal logic [ces86]) is quite large. therefore, the translation of (informal) requirements into a (formal) specification language is a challenging task, and must be expected to be beyond knowledge of the average business analyst. visual process pattern (vpp) [för08] aim at bridging that semantic gap by allowing the business analyst to model the requirements in basically the same language as the business process itself. in the case of vpp, the underlying modeling language is uml activities [obj09]; its fitness for business process modeling is obvious. see fig. 1 for an example business process from the insurance domain, modeled as a uml activity. consequently, förster et.al. [fess07, fses06, fes05] have suggested an activity based visual language which allows for the specification and verification of requirements like “after each production action, a quality check has to be performed prior to delivery”. figure 2 gives a first impression of a vpp representation of that requirement, which will serve as a running example for the rest of this paper; more details of vpp will be explained in sect. 2. 1 / 10 volume 25 (2010) towards generalizing visual process patterns produce part 2receive order ship send invoice close bill [else] [order accepted] report order report rejected order report payment test quality receive payment fill order produce part 1 figure 1. example business process (adopted from [14, p. 312]) report order test quality ship <> a) process constraint #1 <> produce b) process constraint #2 close order figure 2. process patterns for constraints #1 and #2 can state: process constraint #1: before an order is being closed, records of the received orders have to be made. the constraint implies that the action “report order” is executed at some point before the action “close order” is executed, but it does not require that the action “report order” is executed directly before “close order”. it is an important property of typical process requirements that they frequently contain rather loose or incomplete temporal/logical relationships between actions. in a concrete business process there may be many other actions executed in between “report order” and “close order” without contradicting the pattern. since the original semantics of an activityedge as described in the uml superstructure is that action “close order” is enabled immediately when action “report order” terminates [14], we introduced the stereotype �after� for an activityedge to express that some action has to be executed after another but not necessarily directly following it. stereotyping of model elements is the standard extension mechanism of the uml. using stereotypes, model elements can be given additional or extended semantics. figure 2a shows process constraint #1 modeled in our ppsl. the curly line in fig. 2a is a visualization option of the �after� stereotype. in the remainder, we refer to this sort of stereotyped activityedge as afteredge. being able to express such loose order relationships in process patterns is also a necessary prerequisite to enable flexible application of the process patterns since pattern actions and actions of the original business process usually need to be weaved together. if the pattern designer wants to specify that there may not be other actions being executed in between two actions of a pattern, a regular activityedge without stereotype can be used in the pattern. process constraint #1 could be read in two directions. either “every time an order is closed this has to be preceeded by reporting an order” or “every report of an order must be followed by closing the order”. it is important to have the possibility to distinguish these two cases in the process constraint language. this can be done using the stereotype �all� for actions. it denotes whether the implication given by the afteredge in the constraint refers to all “close order” actions or all “report order” actions. in the remainder, we will refer to an action having an �all� stereotype as allaction. the multi-node in figs. 2 and 3 are a visualization option of the allaction. it is also possible to use allactions on both sides of the afteredge or activityedge denoting that both implications have to be fulfilled. consequently, it is a well-formedness rule for our language that at least one of two actions being connected by an afteredge or activityedge is an allaction. the next process constraint that we want to consider is: process constraint #2: after each production action a quality check has to be performed prior to delivery. process constraints #2 is similar to process constraint #1 but contains precisely spoken two different constraints put together. the first requirement is that after each production action there has to be a quality check and the second requirement is that before shipping a product, the quality has to be checked. this is why the actions “produce” and “ship” in the process pattern are allnodes. the use of a regular activityedge between ”test quality” and ”ship” sets the requirement that shipping has to be directly preceded by the quality test. there may not be other actions executed in between these two actions. if we now compare the process constraints with the example business process in fig. 1, we can see that it does not have an action called “produce” like the pattern in fig. figure 1: example business process, modeled as a uml activity produce part 2receive order ship send invoice close bill [else] [order accepted] report order report rejected order report payment test quality receive payment fill order produce part 1 figure 1. example business process (adopted from [14, p. 312]) report order test quality ship <> a) process constraint #1 <> produce b) process constraint #2 close order figure 2. process patterns for constraints #1 and #2 can state: process constraint #1: before an order is being closed, records of the received orders have to be made. the constraint implies that the action “report order” is executed at some point before the action “close order” is executed, but it does not require that the action “report order” is executed directly before “close order”. it is an important property of typical process requirements that they frequently contain rather loose or incomplete temporal/logical relationships between actions. in a concrete business process there may be many other actions executed in between “report order” and “close order” without contradicting the pattern. since the original semantics of an activityedge as described in the uml superstructure is that action “close order” is enabled immediately when action “report order” terminates [14], we introduced the stereotype �after� for an activityedge to express that some action has to be executed after another but not necessarily directly following it. stereotyping of model elements is the standard extension mechanism of the uml. using stereotypes, model elements can be given additional or extended semantics. figure 2a shows process constraint #1 modeled in our ppsl. the curly line in fig. 2a is a visualization option of the �after� stereotype. in the remainder, we refer to this sort of stereotyped activityedge as afteredge. being able to express such loose order relationships in process patterns is also a necessary prerequisite to enable flexible application of the process patterns since pattern actions and actions of the original business process usually need to be weaved together. if the pattern designer wants to specify that there may not be other actions being executed in between two actions of a pattern, a regular activityedge without stereotype can be used in the pattern. process constraint #1 could be read in two directions. either “every time an order is closed this has to be preceeded by reporting an order” or “every report of an order must be followed by closing the order”. it is important to have the possibility to distinguish these two cases in the process constraint language. this can be done using the stereotype �all� for actions. it denotes whether the implication given by the afteredge in the constraint refers to all “close order” actions or all “report order” actions. in the remainder, we will refer to an action having an �all� stereotype as allaction. the multi-node in figs. 2 and 3 are a visualization option of the allaction. it is also possible to use allactions on both sides of the afteredge or activityedge denoting that both implications have to be fulfilled. consequently, it is a well-formedness rule for our language that at least one of two actions being connected by an afteredge or activityedge is an allaction. the next process constraint that we want to consider is: process constraint #2: after each production action a quality check has to be performed prior to delivery. process constraints #2 is similar to process constraint #1 but contains precisely spoken two different constraints put together. the first requirement is that after each production action there has to be a quality check and the second requirement is that before shipping a product, the quality has to be checked. this is why the actions “produce” and “ship” in the process pattern are allnodes. the use of a regular activityedge between ”test quality” and ”ship” sets the requirement that shipping has to be directly preceded by the quality test. there may not be other actions executed in between these two actions. if we now compare the process constraints with the example business process in fig. 1, we can see that it does not have an action called “produce” like the pattern in fig. figure 2: visual process pattern formalizing the requirement “after each production action a quality check has to be performed prior to delivery” förster’s approach is well-suited for the formulation of requirements put on uml activities and the execution of the contained actions, but it does not allow for the formulation of requirements about other activity constructs (e.g., whether a token has arrived at a finalnode) or even against other languages (e.g., uml state machines). this is due to the fact that förster’s language is dedicated to formulating requirements against uml activities only. as a consequence, uml actions (i.e., the places in an activity where actual work takes place) are an important element of that language. as a result, the language is not able to express requirements against models which do not contain actions (e.g., models which are not uml activities). in this paper, we describe how to generalize the vpp approach to be able to do exactly that. we will show how to formulate and verify requirements on arbitrary languages. for that, we will reuse a part of förster’s language. the basic idea is to replace actions in a vpp with arbitrary states of execution of the underlying model, and to connect these states with the flow elements used in vpps. the states of execution of the underlying behavioral model can be described in concrete syntax. structure of paper: in the next section, we will give more insight into the vpp approach. we will point out some technical details of vpp and demonstrate them using the running example introduced above. based on that, sect. 3 will then show how the vpp approach can be generalized such that requirements can be formulated and verified against arbitrary language constructs. section 4 presents work related to our approach, and the last section concludes and points out the current state and the future of our work. 2 visual process pattern we have mentioned in the introduction that a vpp is expressed as a number of actions, connected by custom flow elements (we have seen an example in fig. 2). in this section, we want to precisely define the example’s semantics, and we want to shed light on the technical background of vpp. proc. vffp 2009 2 / 10 eceasst business process (uml activity) dmmspecification groove generator labeled transition system business process pattern groove model checker true/false, counter example temporal logic formulas bpp translator figure 3: overview of the vpp approach we start with an assumption, though: we expect to receive the semantics of a business process model as a labeled transition system (lts), where the labels contain information about the model’s execution. a trace through such an lts is the sequence of labels we get on one of the possible “ways” through the lts. we will later see how this is actually realized in the vpp approach, and how to use this fact for generalizing the approach. the idea of vpp is to visually describe temporal properties of a model. for instance, one wants to express that “when action a is executed, action b will be executed at some point in the future”. the interested reader will immediately see that the temporal part of the above statement (“when event a, then eventually event b”) can easily be expressed using temporal logic. this is indeed what the vpp approach does: in [fess07], the authors have defined the visual pattern language by mapping the custom flow elements into the temporal logic dialect ltl. for instance, the example vpp depicted as fig. 2 is translated into the two formulas g(produce → f test quality) and g(ship → y test quality). figure 3 shows the whole underlying process. in ltl, expressions about paths g stands for “all future states”, f means “some future state”, and y translates to “the previous state”. it now becomes clear how the formulas are related to our example vpp: the first expression is true for a trace of the lts, if for all the trace’s states it is the case that if label produce occurs, label “test quality” will occur in the future. the second expression is true for traces such that if label “ship” occurs, label “test quality” must have been the previous label. note that an expression is true for an lts iff it is true for all (possibly infinite) traces through that lts. so far, we have seen how to express vpps into according ltl formulas which can then be verified against an appropriately labeled transition system. our next step will be the generation of such an lts. this is where dynamic meta modeling comes into play. 2.1 dynamic meta modeling dynamic meta modeling (dmm) [hau05] is a semantics specification technique targeted at visual behavioral modeling languages whose abstract syntax is defined by means of a metamodel. the idea of dmm is to enhance such a given metamodel with concepts needed to express states of execution of a language’s model, leading to a so-called runtime metamodel. in a second step, operational rules are defined which describe how instances of the runtime metamodel (i.e., models in a certain state of execution) change in time (i.e., which state(s) of execution will be 3 / 10 volume 25 (2010) towards generalizing visual process patterns semantics definition syntax definition transition system states expression model operational rules conforms to semantic metamodeling conforms to metamodel graph transformation rules semantic mapping runtime metamodel language model (instance) conforms to conforms to typed over figure 4: overview of the dmm approach reached from a certain state according to the language’s behavior). such a dmm rule has a precondition which must be fulfilled for the rule to match; if this is the case, the rule is applied, leading to a new state. the dmm approach is depicted as fig. 4. let us illustrate the above using the example language of uml activities: the runtime metamodel of uml activities adds concepts such as an activityexecution class, a token class1 etc., whereas the operational rules describe how tokens flow through an activity during execution. for instance, one of the mentioned dmm rules makes sure that an action is executed if all its incoming edges carry at least one token. if this is the case, the action starts execution. a dmm specification together with an instance of the runtime metamodel give rise to an lts, where states are states of execution of the according model, transitions are applications of operational rules, and labels are names of operational rules. the instance of the runtime metamodel serves as the start state of the lts. the lts can then be analyzed with model checking techniques, e.g. to verify ltl formulas as defined above: the idea is to refer within these formulas to the names of appropriate dmm rules corresponding to the desired states of execution (e.g., the execution of a particular action). technically, dmm is based on graph transformations [eekr99]. the instances of the runtime metamodel are treated as (typed) graphs, and the dmm rules manipulate these graphs. as a result, dmm specifications are not only formal, but also easily understandable due to their visual nature. the execution of dmm specifications as well as the model checking are performed using the groove tool set [ren04, kr06], an excerpt of the resulting lts is depicted as fig. 5. see [hau05, för08] for more details on dmm and the way vpps make use of it. 1 note that since uml 2.0, the semantics of activities is based on token flow. proc. vffp 2009 4 / 10 eceasst and verifying constraints for business processes, it is not intended to be a graphical notation for temporal logic in general. furthermore we show how the example process patterns of sect. 3 are translated into temporal logic and whether the business process of fig. 1 conforms to these patterns. finally in sect. 4.3 we show how the verification process shown in fig. 4 can be embedded in a tool chain, using state-of-the-art model checkers. this tool support supports the business process designer in verifying the application of the process patterns he/she selected. 4.1 generation of the labeled transition system the semantics of a visual language is defined in the dmm framework by a semantic domain meta model and a set of meta operations. the semantic domain meta model describes the semantical concepts of the language. for example, to be able to express the semantics of activity diagrams, the semantic concept actionexecution is defined as a class in the semantic domain meta model. this concept denotes a currently running execution of an action. for each semantic concept that relates to behavior it captures this behavior in a set of meta operations. the meta operations are defined by rules represented as uml communication diagrams. these communication diagrams are given a formal interpretation based on graph transformation rules. given the set of dmm rules for a particular language and a user-defined model expressed in the same language, a labeled transition system (lts) is generated by a dmm interpreter that reflects all possible behaviors to the model. in the dmm approach, the groove (graphical objectoriented verification) tool set [15] has been chosen as dmm interpreter to produce the resulting labeled system. using the groove tool, the set of dmm rules for uml 2.0 activity diagrams, and given a user-defined activity diagram, which is in our case the business process, we can generate a lts that specifies the exact execution paths of the activity diagram. figure 5 shows an excerpt of the resulting lts from the example in fig. 1. each state in the lts represents a state in the execution of the activity diagram. the labels in the states represent the fact that the corresponding action is actually executing. a name of an action in the business process refers to a certain behavior. since the business process and the process pattern may have been devised by different persons using different behavior namespaces, a mapping needs to be defined. this mapping is part of the tool chain described in sect. 4.3. for the formalization, without loss of generality, we assume that the behavior namespaces are synchronized. the dmm approach for uml activity diagrams incorporates the semantics of the uml 2.0 superstructure [14] figure 5. excerpt of the transition system resulting from the example business process in fig. 1b generated using dmm and groove. for model elements of the packages structuredactivities and intermediateactivities. these semantics implemented in dmm include all important issues described in the uml specification like traverse-to-completion, the fact that actions capture all of their input tokens in one atomic step, etc. concurrency in the activity diagram leads to a transition system that contains all possible interleavings between the concurrent actions. in the next section we specify how the process patterns can be translated into temporal logic formulas which can be checked against the transition system. 4.2 formalization of process patterns the formalization of the process patterns is presented in two consecutive steps. first, the notion of pattern graph is defined. secondly, the translation of a process pattern into temporal logic is established. a process pattern is represented by a pattern graph. definition 1. a pattern graph (pg) is a tuple pg = (n, e) where n is the set of nodes and e is the set of edges, i.e., the set of tuples n×n. the notation e(n1, n2) is equivalent with e ∈ e ∧ e = (n1, n2). the set n is divided into different disjoint subsets, n = na ∪ nd ∪ nm ∪ nf ∪ nj where na is the set of actionnodes, nd is the set of decisionnodes, nm is the set of mergenodes, nf is the set of forknodes, and nj is the set of joinnodes. the set of controlnodes, denoted by nc, is defined as nc = nd ∪ nm ∪ nf ∪ nj. the set of edges e is divided into two disjoint sets e = ed ∪ ea, where ed is the set of activityedges, ea is the set of afteredges, and ed ∩ ea = ∅. the set of allactions is denoted by nall ⊆ na. in the remainder of this section, we explain how process patterns can be expressed by linear-time temporal logic figure 5: excerpt of the transition system resulting from the example business process in fig. 1, generated using dmm and groove 3 generalization of vpp in the last section, we have seen how vpps are translated into temporal logic formulas which can then be model checked against the lts derived from the language’s semantics specification and the business process itself (which serves as the start state). we have also seen how vpp uses dmm: for every action of the business process, a corresponding dmm rule exists; the according label in the lts corresponds to the execution of the according rule. however, as mentioned earlier, this approach does not help if we e.g. want to formulate requirements on other language elements than actions, let alone other behavioral languages. this is not possible with vpps since the usage of actions is “hardcoded” into the approach, as we have seen earlier. for instance, we would like to be able to express requirements like “when action a is executed, the activity will always terminate properly”. however, the vpp language does not contain any constructs allowing to express requirements on other elements than actions. one solution could be to directly refer to rules of the semantics specification within a vpp expression. for instance, instead of connecting actions with the vpp flow elements (as seen in fig. 2), we could connect a representation of the rules corresponding to the behavior of interest. however, this has two serious drawbacks: first, the business analyst creating the vpps needs to have knowledge about the rules contained in the semantics specification: which rules do exist, and which situations do they correspond to? second (and even worse), we would also like to be able to express requirements about states of execution of our model for which no corresponding rule exists. for instance, we might want to express that at some point in time, both actions a and b are executed in parallel; however, there is no corresponding rule for that kind of requirement. fortunately, groove offers the concept of so-called property rules. the next section will show how these property rules can be used to formulate requirements about a much broader class of states of execution. 5 / 10 volume 25 (2010) towards generalizing visual process patterns 3.1 property rules property rules are rules which have a precondition, but they do not change the states they are applied to. in other words: if such a rule matches a state, the rule is applied, leading to a self-transition of the according state. technically, a property rule is a graph transformation rule having the same left-hand and right-hand graphs. these property rules can be used for our goal of formulating requirements in a more flexible way: for every state property of interest, an according property rule is defined and added to the dmm ruleset. for instance, if we are interested in the state where actions a and b are executed in parallel, we just need to create a property rule describing exactly that situation: the rule would contain the according actions which would both carry a token, corresponding to the fact that they are both executed. the resulting lts will contain some additional transitions: every state which fulfills the formulated property will have a label with the property rule’s name. this allows for the verification of temporal formulas about those properties as described in sect. 2. note that the new lts will be stuttering equivalent to the original transition system, i.e., if we remove all occurences of property rules from the traces of our new lts, the resulting set of traces is equal to the set of traces of the original lts. to put it differently: adding property rules to an existing ruleset does not significantly change the ruleset’s semantics. note also that using property rules still allows to verify all requirements formulated with “plain” vpps as described by förster. this is done by deriving property rules from the dmm rules used within the verification process in a trivial way. for each dmm rule used in the verification process (i.e., each rule referenced by our original vpps), we introduce a new property rule whose precondition is fulfilled if the according action is executed. if we compute the lts, every state which was labeled with one of the original rules will additionally be labeled with the according property rule. this means that we can still check the requirement by using the same ltl formulas as before; the only difference is that the rules referenced within these formulas have been replaced with the corresponding property rules. 3.2 specification of state properties but how to specify property rules? our assumption is that the business analyst knows the semantics of the modeling language used (otherwise she will probably not be able to come up with a meaningful model). therefore, it seems reasonable to use a concrete syntax of the runtime metamodel for specifying the property rules, since we want their appearance to be as close to the original language as possible. let us illustrate this with a small example in the domain of activities: we have seen above that the semantics of activities is based on token flow, and that the dmm runtime metamodel of uml activities therefore contains a token class. an obvious visualization of the token concept is a black, filled dot which is drawn at the language element the token is located. figure 6 shows an example property rule: the rule matches if a token is sitting at an activityfinalnode. besides being intuitive and easily understandable, the suggested representation of property rules has another advantage: having a concrete syntax for the runtime part of the language allows for the (animated) visualization of the execution of a model, e.g. for using it within a proc. vffp 2009 6 / 10 eceasst figure 6: a property rule as concrete syntax; the rule matches if a token is sitting on a finalnode. figure 7: a vpp expression making use of property rules. visual debugger, which is indeed part of one of our research projects (more on this in sect. 5). 3.3 formulating vpps using property rules it is now straight-forward how to use property rules within a vpp. instead of referring to a concrete action within one of the boxes contained in the vpp, a property rule is used which describes the properties of the state of interest. figure 7 shows such a vpp realizing the requirement “when action a is executed, the activity will always terminate properly”: the left action of the vpp contains action a carrying a token (corresponding to that action being executed), the right part shows a finalnode carrying a token (corresponding to the whole activity being terminated). of course, the boxes can still be connected using the flow elements contained in the vpp language (as we did in fig.7). as a result, the translation to temporal logic nearly remains unchanged. the only difference is that instead of using a reference to an existing dmm rule within a vpp, the according property rule is referenced. finally, it is now easy to see how this approach can be used for formulating requirements against other behavioral languages: for instance, in the case of uml state machines, the runtime metamodel will most likely contain the concept of a “marker” which shows the current state(s) the machine is in. having a concrete syntax for that marker concept, the marker can then be used to formulate requirements like “when the state machine is in state a, it will eventually be in state b”. 4 related work the relatedwork of this paper mainly falls into two categories: workflow and process patterns and the verification of formal properties against workflows and processes. workflow and process patterns van der aalst et.al. [ahkb03] have suggested a number of workflow patterns describing several types of control flow structures in workflow systems. using petri nets, their main focus was to identify typical control flow structures contained in workflows, and to use this knowledge to assess existing workflow management systems and workflow specification languages for expressiveness. ambler [amb96] suggests the application of process patterns to software development processes; however, his approach does not contain a formal underpinning which could be used for automatic verification of such processes. 7 / 10 volume 25 (2010) towards generalizing visual process patterns verification of workflow and process properties kindler and van der aalst [ka99] describe how to verify petri nets for general properties like soundness and liveness, but their approach does not support the verification of user-defined properties raising e.g. from domain-specific requirements. janssen et.al. [jmm+99] suggest an approach for the verification of business processes using model checking techniques which is based on a proprietary process modeling language. the authors formalize different basic constraints; again, the approach does not allow for the verification of custom, user-defined properties. 5 conclusion in this paper, we have shown how to generalize the vpp approach, which deals with the visual specification of formal requirements against business processes. for this, we have briefly introduced the vpp approach, and we have explained how dmm and groove are used to perform the verification of such requirements in sect. 2. based on that, we have shown in sect. 3 how to replace the “hard-coded” action rules of the dmm approach with so-called property rules, i.e., rules which do not change states they are applied to, but are still represented as labels in the resulting lts. we have shown how to formulate the property rules using a concrete syntax of the runtime metamodel which is part of the dmm specification. to demonstrate our approach, we have shown how to reformulate existing vpps using property rules, and we have provided a simple process requirement which could not be formulated using the existing vpp language, but can be formulated with our approach. additionally, we have described how to compose property rules to requirements on the whole lts, borrowing the flow constructs and their mapping to ltl from förster’s vpp approach. future work we are currently working on incorporating the described approach into our dmm tooling. this involves several steps: first, we need to investigate a reasonable way to define a concrete syntax for a runtime metamodel as used in the dmm specification technique (given that the syntax metamodel of the language is already equipped with a concrete syntax). additionally, as mentioned earlier, we plan to reuse the concrete syntax of the runtime metamodel for a visual debugger for languages having a dmm specification. the general idea is to animate the execution of a behavioral model (in the case of uml activities, that animation would basically show the flowing of tokens through the activity to be debugged). a first step in this direction has already been performed as part of a diploma thesis [ban09]. if the verification shows that one of our vpps does not hold for a particular model, the model checker will produce a counter example showing under which circumstances the violation of the vpp occurs. that counter example is expected to be very helpful for the business analyst when fixing the model’s flaws. using the visual debugger as described in the previous paragraph, we want to back-propagate that counter example to the business analyst in an intuitive, easily understandable way. finally, we plan to visually model the soundness requirements against uml activities identified in [esw07]. having shown the general usefulness of our approach that way, we plan to perform a larger case study in the context of dmm and our notion of vpps. acknowledgements: thanks to nils bandener for last-minute technical support. proc. vffp 2009 8 / 10 eceasst bibliography [ahkb03] w. m. p. van der aalst, a. h. m. ter hofstede, b. kiepuszewski, a. p. barros. workflow patterns. distributed and parallel databases 14(1):5–51, 2003. [amb96] s. w. ambler. process patterns building large-scale systems using object technology. sigs books/cambridge university press, cambridge, 1996. [ban09] n. bandener. visual interpreter and debugger for dynamic models based on the eclipse platform. master’s thesis, university of paderborn, 2009. [ces86] e. m. clarke, e. a. emerson, a. p. sistla. automatic verification of finite-state concurrent systems using temporal logic specifications. acm trans. program. lang. syst. 8(2):244–263, 1986. doi:http://doi.acm.org/10.1145/5397.5399 [eekr99] h. ehrig, g. engels, h.-j. kreowski, g. rozenberg (eds.). handbook of graph grammars and computing by graph transformation, vol. 2: applications, languages, and tools. world scientific publishing co., inc., river edge, nj, usa, 1999. [esw07] g. engels, c. soltenborn, h. wehrheim. analysis of uml activities using dynamic meta modeling. in bosangue and johnsen (eds.), proceedings of the fmoods 2007 conference. lncs 4468, pp. 76–90. springer, 2007. [fes05] a. förster, g. engels, t. schattkowsky. activity diagram patterns for modeling quality constraints in business processes. in l. c. briand (ed.), proceedings of the 8th international conference on model driven engineering languages and systems (models 2005), montego bay (jamaica). pp. 2–16. springer, 2005. [fess07] a. förster, g. engels, t. schattkowsky, r. v. d. straeten. verification of business process quality constraints based on visual process patterns. in tase. pp. 197– 208. ieee computer society, 2007. [för08] a. förster. pattern-based business process design and verification. phd thesis, university of paderborn, 2008. [fses06] a. förster, t. schattkowsky, g. engels, r. v. d. straeten. a pattern-driven development process for quality standard-conforming business process models. in ieee symposium on visual languages and human-centric computing (vl/hcc 2006), brighton (uk). pp. 135–142. ieee computer society, 2006. [hau05] j. h. hausmann. dynamic meta modeling. phd thesis, university of paderborn, 2005. [jmm+99] w. janssen, r. mateescu, s. mauw, p. fennema, p. van der stappen. model checking for managers. in dams et al. (eds.), spin. lecture notes in computer science 1680, pp. 92–107. springer, 1999. 9 / 10 volume 25 (2010) http://dx.doi.org/http://doi.acm.org/10.1145/5397.5399 towards generalizing visual process patterns [ka99] e. kindler, w. m. p. van der aalst. liveness, fairness, and recurrence in petri nets. information processing letters 70(6):269–27, 1999. [kr06] h. kastenberg, a. rensink. model checking dynamic states in groove. in valmari (ed.), spin. lecture notes in computer science 3925, pp. 299–305. springer, 2006. [obj09] object management group. omg unified modeling language (omg uml) – superstructure, version 2.2. http://www.omg.org/docs/formal/09-02-02.pdf, 2 2009. [ren04] a. rensink. the groove simulator: a tool for state space generation. in pfaltz et al. (eds.), agtive 2003 – revised selected and invited papers. lncs 3062, pp. 479–485. springer, 2004. proc. vffp 2009 10 / 10 http://www.omg.org/docs/formal/09-02-02.pdf introduction visual process pattern dynamic meta modeling generalization of vpp property rules specification of state properties formulating vpps using property rules related work conclusion gui inspection from source code analysis electronic communications of the easst volume 33 (2010) proceedings of the fourth international workshop on foundations and techniques for open source software certification (opencert 2010) gui inspection from source code analysis joão carlos silva , josé creissac joão saraiva 18 pages guest editors: luis s. barbosa, antonio cerone, siraj a. shaikh managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst gui inspection from source code analysis joão carlos silva 1,2 josé creissac 1 joão saraiva 1 1departamento de informática, universidade do minho, braga, portugal 2departamento de tecnologia, instituto politécnico do cávado e do ave, barcelos, portugal abstract: graphical user interfaces (guis) are critical components of todays software. given their increased relevance, correctness and usability of guis are becoming essential. this paper describes the latest results in the development of our tool to reverse engineer the gui layer of interactive computing systems. we use static analysis techniques to generate models of the user interface behaviour from source code. models help in graphical user interface inspection by allowing designers to concentrate on its more important aspects. one particular type of model that the tool is able to generate is state machines. the paper shows how graph theory can be useful when applied to these models. a number of metrics and algorithms are used in the analysis of aspects of the user interface’s quality. the ultimate goal of the tool is to enable analysis of interactive system through guis source code inspection. keywords: source code, reverse engineering, graphical user interface, metrics, properties 1 introduction typical wimp-style (windows, icon, mouse, and pointer) user interfaces consist of a hierarchy of graphical widgets (buttons, menus, textfields, etc) creating a front-end to software systems. an event-based programming model is used to link the graphical objects to the rest of the system’s implementation. each widget has a fixed set of properties and at any time during the execution of the gui, these properties have discrete values, the set of which constitutes the state of the gui. users interact with the system by performing actions on the graphical user interface widgets. these, in turn, generate events at the software level, which are handled by appropriate listener methods. in brief, and from a user’s perspective, graphical user interfaces accept as input a pre-defined set of user-generated events, and produce graphical output. from the programmers perspective, as user interfaces grow in size and complexity, they become a tangle of object and listener methods, usually all having access to a common global state. considering that the user interface layer of interactive systems is typically the one most prone to suffer changes, due to changed requirements and added features, maintaining the user interface code can become a complex and error prone task. integrated development environments (ides), while helpful in that they enable the graphical definition of the interface, are limited when it comes to the definition of the behavior of the interface a source code analysis tool can minimize the time necessary by a developer to understand and evaluate a system. in this paper we present guisurfer, a static analysis based retargetable framework for gui-based applications analysis from source code. in previous papers [scs06a, 1 / 18 volume 33 (2010) gui inspection from source code analysis a bstract syntax tree parser/grammar gui intermediate r epresentation l anguage dependent l anguage independent gui code slicing source code gui layer b usiness layer d ata layer gui model state m achine event flow graph f ilep arser.hs a sta nalyser.hs g uix .hs s licingx .hs gui analysis g raph.hs figure 1: guisurfer architecture and retargetability scs06b, scs09] we have explored the applicability of slicing techniques [tip95] to our reverse engineering needs, and developed the building blocks for the approach. in this paper we explore the integration of analysis techniques into the approach, in order to reason about the gui models. 2 guisurfer tool guisurfer’s goal is to be able to extract a range of models from source code. in the present context we focus on finite state models that represent gui behaviour. that is, when can a particular gui event occur, which are the related conditions, which system actions are executed, or which gui state is generated next. we choose this type of model in order to be able to reason about and test the dialogue supported by a given gui implementation. figure 1 presents the architecture of the guisurfer tool. guisurfer is composed by three tools: fileparser, astanalyser, and graph. these tools are configurable through command line parameters. below we outline some of the more important parameters for each tool. the fileparser tool is language dependent and is used to parse a particular source code file. for example, the command fileparser login.java allows us to parse a particular login java class. as a result, we obtain its ast. the astanalyser tool is another language dependent tool used to slice an abstract syntax tree, considering only its graphical user interface layer. part of this tool is easily retargetable, however most of the tool needs to be rewritten to consider another particular programming language. the astanalyser tool is composed of a slicing library, containing a generic set of traversal functions that traverse any ast. this tool must be used with three arguments, i.e. the abstract proc. opencert 2010 2 / 18 eceasst syntax tree, the entry point in source code (e.g., the main method for java source code), and a list with all widgets to consider during the gui slicing process. the command astanalyser login.java.ast main jbutton lets us extract the gui layer from login.java’s abstract syntax tree, starting the slice process at the main method, and extracting only jbutton related data. executing the command generates two files initstate.gui and eventsfrominitstate.gui which contain the initial state and possible events from the initial states, respectively. finally, the graph tool is language independent and receives as arguments the initstate.gui and eventsfrominitstate.gui files, and generates several metadata files with events, conditions, actions, and states extracted form source code. each of these types of data is related to a particular fragment from the ast. further important outputs generated by the graph tool are the guimodel.hs and guimodelfull.hs files. these are gui specifications written in the haskell programming language. these specifications define the gui layer mapping events/conditions to actions. finally, this last tool allows us also to generate several visual models through the graphviz tool, such as state machines, behavioral graph, etc. 3 gui inspection from source code the evaluation of an user interface is a multifaceted problem. besides the quality of the code by itself, we have to consider the user reaction to the interface. this involves issues such as satisfaction, learnability, and efficiency. the first item describes the users satisfaction with the systems. learnability refers to the effort users make to learn how to use the application. efficiency refers to how efficient the user can be when performing a task using the application. software metrics aim to measure software aspects, such as source lines of code, functions invocations, etc. by calculating metrics over the behavioral models produced by guisurfer, we aim to acquire relevant knowledge about the dialogue induced by the interface, and, as a consequence, about how users might react to it (c.f. [tg08]). in this section we describe several kinds of inspections making use of metrics. the analysis of source code can provide a mean to guide development and to certificate software. for that purpose adequate metrics must be specified and calculated. metrics can be divided into two groups: internal and external [iso99]. external metrics are defined in relation to running software. in what concerns guis, external metrics can be used as usability indicators. they are often associated with the following attributes [nie93]: • easy to learn: the user can do desired tasks easily without previous knowledge; • efficient to use: the user reaches a high productivity level. • easy to remember: the re-utilization of the system is possible without a high level of effort. • few errors: errors are made hardly by the users and the system permits to recover from them. • pleasant to use: the users are satisfied with the use of the system. 3 / 18 volume 33 (2010) gui inspection from source code analysis however, the values for these metrics are not obtainable from source code analysis, rather through users’ feedback. internal metrics are obtained by source code analysis, and provide information to improve software development. a number of authors has looked at the relation between internal metrics and gui quality. stamelos et al. [saob02] used the logiscope1 tool to calculate values of selected metrics in order to study the quality of open source code. ten different metrics were used. the results enable evaluation of each function against four basic criteria: testability, simplicity, readability and self-descriptiveness. while the gui layer was not specifically targeted in the analysis, the results indicated a negative correlation between component size and user satisfaction with the software. yoon and yoon [yy07] developed quantitative metrics to support decision making during the gui design process. their goal was to quantify the usability attributes of interaction design. three internal metrics were proposed and defined as numerical values: complexity, inefficiency and incongruity. the authors expect that these metrics can be used to reduce the development cost of user interaction. while the above approaches focus on calculating metrics over the code, thimbleby and gow [tg08] calculate them over a model capturing the behavior of the application. using graph theory they analyze metrics related to the users’ ability to use the interface (e.g., strong connectedness ensure no part of the interface ever becomes unreachable), the cost of erroneous actions (e.g., calculating the cost of undoing an action), or the knowledge needed to use the system (e.g., the minimum cut identifies the set of actions that the user must know in order to to be locked out of parts of the interface). in a sense, by calculating the metrics over a model capturing gui relevant information instead of over the code, the knowledge gained becomes closer to the type of knowledge obtained from external metrics. while thimbleby and gow manually develop their models from inspections of the running software/devices, an analogous approach can be carried out analyzing the models generated by guisurfer. indeed, by coupling this type of analysis with guisurfer, we are able to obtain the knowledge directly from source code. 4 an agenda application throughout the paper we will use a java/swing interactive application as a running example. this application consist of an agenda of contacts: it allows users to perform the usual actions of adding, removing and editing contacts. furthermore, it also allows users to find a contact through its name. the interactive application consists of four windows, namely: login, mainform, find and contacteditor, as shown in figure 2. the initial login window (figure 2, top-left) is used to control users’ access to the agenda. thus, a login and password pair has to be introduced by the user. if the user introduces a valid login/password pair, and presses the ok button, then the login window closes and the main window of the application is displayed. on the contrary, if the user introduces an invalid login/password pair, then the input fields are cleared, a warning message is 1 http://www-01.ibm.com/software/awdtools/logiscope/ proc. opencert 2010 4 / 18 eceasst figure 2: a java/swing application produced and the login window continues to be displayed. by pressing the cancel button in the login window, the user exits the application. the java fragment defining the action performed when the ok button is pressed is as follows: private void okactionperformed(...) {if (isvalid(user.gettext(),pass.gettext())) {new mainform().setvisible(true); this.dispose();} else javax.swing.joptionpane.showmessagedialog (this,"user/pass not valid","login",0); } where the method isvalid tests the username/password pair inserted by the user. authorized users can use the main window (figure 2, top-right) to find and edit contacts (c.f., find and edit buttons). by pressing the find button in the main window, the user opens the find window (figure 2, bottom-left). this window is used to search and obtain a particular contact’s data from his name. by pressing the edit button in the main window, the user opens the contacteditor window (figure 2, bottom-right). this last window allows the editing of a contact’s data, such as name, nickname, e-mails, etc. the add and remove buttons enable editing the e-mail addresses’ list of the contact. if there are no e-mails in the list then the remove button is automatically disabled. until now, we have informally described the (behavioral) model of our interactive application. such descriptions, however, can be ambiguous and often lead to different interpretation of what the application should do. in order to unambiguously and rigorously define an application, we can use a formal model. moreover, by using a formal model to define the interactive application, we can use techniques to manipulate and inspect such application. figure 3 shows a formal model to specify the behavior of our running example: a graph. a graph is a mathematical abstraction and consists of a set of vertices, and a set of edges. each edge connects two vertices in the graph. in other words, a graph is a pair (v,e), where v is a finite set and e is a binary relation on v. v is called a vertex set whose elements are called vertices. e is a 5 / 18 volume 33 (2010) gui inspection from source code analysis search/cond1/[]show/cond3/[] cancel/cond2/[1] init/condinit1/[2,3,4,5,6,7,8] close find window add/cond1/[1,2] cancel/cond5/[7] ok/cond6/[8] remove/cond3/[3,4] edit/cond2/[]remove/cond4/[5,6]add/cond1/[1,2] cancel/cond5/[7] ok/cond6/[8] init/condinit2/[18,19,11,12,13,14,15,16,17] init/condinit1/[9,10,11,12,13,14,15,16,17] close contacteditor window open find window open contacteditor window edit/cond2/[2]edit/cond3/[3]find/cond4/[4]find/cond5/[5] exit/cond1/[1] init/condinit1/[6,7,8,9,10,11,12,13,14,15] ok/cond3/[4] cancel/cond1/[1] ok/cond2/[2,3] init/condinit1/[5,6,7,8,9] open mainform window findstate1 findstate0 findclose contacteditorstate1 contacteditorstate2 contacteditorstate0 contacteditorclose mainformstate1 mainformstate0 mainformend loginstate1 loginstate0 loginend loginclose figure 3: agenda’s behavior graph proc. opencert 2010 6 / 18 eceasst collection of edges, where an edge is a pair (u,v) with u,v in v. graphs are directed or undirected. in a directed graph, edges are ordered pairs, connecting a source vertex to a target vertex. in an undirected graph edges are unordered pairs of two vertices. if some edge (u,v) is in graph, then vertex v is said to be adjacent to vertex u. in a directed graph, edge (u,v) is an out-edge of vertex u and an in-edge of vertex v. the number of out-edges of a vertex is its out-degree, and the number of in-edges is its in-degree. a path is a sequence of edges in a graph such that the target vertex of each edge is the source vertex of the next edge in the sequence. if there is a path starting at vertex u and ending at vertex v we say that v is reachable from u. graphs are a commonly used to represent user interfaces. vertices represent the possible gui states, and the transitions between vertices (edges) define the events associated to the gui objects. the model in figure 3 was automatically extracted by guisurfer. associated to each edge there is a triplet representing the event that triggers the transition, a guard on that event (here represented by a label identifying the condition being used), and a list of interactive actions executed when the event is selected (each action is represented by a unique identifier which is related to the respective source code). using this model it becomes possible to reason about characteristics of the interaction between users and the agenda application. 5 gui inspection through graph theory this section describes some examples of analysis performed on the agenda application’s behavioral graph (cf. figure 3) from the previous section. we make use of graph-tool for the manipulation and statistical analysis of the graph. 5.1 graph-tool graph-tool is an efficient python module for manipulation and statistical analysis of graphs (cf. http://projects.forked.de/graph-tool/). it allows for the easy creation and manipulation of both directed or undirected graphs. arbitrary information can be associated to the vertices, edges or even the graph itself, by means of property maps. graph-tool implements all sorts of algorithms, statistics and metrics over graphs, such as degree/property histogram, combined degree/property histogram, vertex-vertex correlations, assortativity, average vertex-vertex shortest distance, isomorphism, minimum spanning tree, connected components, dominator tree, maximum flow, clustering coefficients, motif statistics, communities, centrality measures. now we will consider the graph described in figure 4 (automatically obtained from figure 3) where all vertices and edges are labeled with unique identifiers. 5.2 gui metrics to illustrate the analysis, we will consider three metrics: shortest distance between vertices, pagerank and betweeness. 7 / 18 volume 33 (2010) gui inspection from source code analysis 2 3 1 0 28 6 7 8 13 9 1114 10 12 5 4 29 21 17 16182022 19 15 27 24 25 23 26 0 1 2 3 4 5 6 7 8 9 10 11 12 13 figure 4: agenda’s behavior graph (numbered) 5.2.1 shortest distance the graph-tool enables us to calculate the shortest path between two vertices. as examples the obtained results for the shortest path between vertices 11 and 6 is (cf. figure 4): shortest path vertices: [’11’,’10’,’13’,’8’,’7’,’5’,’4’,’6’] shortest path edges: [’(11,10)’,’(10,13)’,’(13,8)’,’(8,7)’,’(7,5)’,’(5,4)’,’(4,6)’] we obtain the vertices sequence from vertice 11 to vertice 6. and we have also access to the egdes sequence. this is usefull to calculate the number of steps to execute a particular task. now let us consider another inspection. the next result gives us the shortest distance (minimum number of edges) from the login window (vertice 11) to all other vertices. each value proc. opencert 2010 8 / 18 eceasst gives the distance from vertice 11 to a particular target vertice. the index of the value in the sequence correspond to the vertice identifier. as example the first value is the shortest distance from vertice 11 to vertice 0, which is 6 edges long. shortest distance from login [6 5 7 6 6 5 7 4 3 5 1 0 2 2] another example makes use of mainform (vertice 7) as starting point. negative values (-1) indicate that there are no paths from mainform to those vertices. shortest distance from mainform [2 1 3 2 2 1 3 0 -1 1 -1 -1 -1 -1] this metrics are useful to analyse the complexity of an interactive application’s user interface. higher values represent complex tasks while lower values are applications with simple tasks. the example also shows that they can be used to detect parts of the interface that can become unavailable. in this case, there is no way to go back to the login window once the main window is displayed. the application must be quit. this metrics can be used to calculate the center of a graph. the center of a graph is the set of all vertices a where the greatest distance to other vertices b is minimal. the vertices in the center are called central points. thus vertices in the center minimize the maximal distance from other points in the graph. finding the center of a graph is useful in gui applications where the goal is to minimize the steps to execute a particular task (i.e. edges between two points). for example, placing the main window of an interactive system at a central point reduces the number of steps an user has to execute to accomplish tasks. 5.2.2 pagerank pagerank is a distribution used to represent the probability that a person randomly clicking on links will arrive at any particular page [ber05]. a probability is expressed as a numeric value between 0 and 1. a 0.5 probability is commonly expressed as a ”50% chance” of something happening. pagerank is a link analysis algorithm, used by the google internet search engine that assigns a numerical weighting to each element of a hyperlinked set of documents. the main objective is to measure their relative importance. this same algorithm could be applied to our gui’s behavioral graphs. figure 5 gives pagerank for each agenda vertices. the size of a vertex corresponds to its importance within the overall application behavior. this metric is useful, for example, to analyze whether complexity is well distributed along the application behavior. in this case, the main window is clearly a central point in the interaction. 5.2.3 betweenness betweenness is a centrality measure of a vertex or a edge within a graph[sa09]. vertices that occur on many shortest paths between other vertices have higher betweenness than those that do not. similar to vertices betweenness centrality, edge betweenness centrality is related to shortest 9 / 18 volume 33 (2010) gui inspection from source code analysis figure 5: agenda’s pagerank results path between two vertices. edges that occur on many shortest paths between vertices have higher edge betweeness. figure 6 describes betweeness values as a visual form for each agenda vertices and egdes. highest betweeness edges values are related with largest edges. the main window has the highest betweenness, meaning it acts as a hub from where different parts of the interface can be reached. clearly it will be a central point in the interaction. 5.2.4 cyclomatic complexity another important metric is cyclomatic complexity which aims to measures the total number of decision logic in an application [j.76]. it is used to give the number of tests for software and to keep software reliable, testable, and manageable. cyclomatic complexity is based entirely on the structure of software’s control flow graph and is defined as m = e −v + 2p (considering single exit statement) where e is the number of edges, v is the number of vertices and p is the number of connected components. considering the figure 5 where edges represent decision logic in the agenda gui layer, the gui’s overall cyclomatic complexity is 18. in other hand, each agenda’s window has a cyclomatic complexity less or equal than 10. in applications there are many good reasons to limit cyclomatic complexity. complex structures are more prone to error, are harder to analyse, are harder to test, and are harder to maintain. the same reasons could be applied to user interfaces. mccabe proposed a limit of 10 for functions’s code, but limits as high as 15 have been used proc. opencert 2010 10 / 18 eceasst 1.01.0 16.8241758242 18.8021978022 14.8461538462 1.65934065934 5.61538461538 5.61538461538 1.65934065934 1.01.01.0 5.61538461538 5.61538461538 12.2087912088 12.2087912088 17.4835164835 20.7802197802 25.3956043956 1.01.01.01.0 8.91208791209 24.7362637363 1.0 2.31868131868 15.5054945055 9.57142857143 20.7802197802 0.102564102564 0.121794871795 0.0833333333333 0.0448717948718 0.0448717948718 0.166666666667 0.108974358974 0.455128205128 0.173076923077 0.0 0.0769230769231 0.0 0.0 0.128205128205 figure 6: agenda’s betweeness values 11 / 18 volume 33 (2010) gui inspection from source code analysis successfully as well. mccabe suggest limit greater than 10 for projects that have operational advantages over typical projects, for example formal design. user interfaces can apply the same limits of complexity, i.e. each window behavior complexity could be limited to a particular cyclomatic complexity. 5.3 gui test cases generation software testing is very important since it enables to evaluate a system by manual or automatic means and verify that it satisfies specified properties or identify differences between expected and actual results. most approaches to software testing focus on the computational/algorithmic aspects of the systems. in this section we use the models generated by guisurfer like figure 3 in order to follow a model-based testing approach for gui. software testing is usally divided in two phases: test cases generation and properties verification. in this section we present our approach to these two tasks. 5.3.1 related work the need for system reliability is the basis of research into the problem of gui testing. the research aims to validate their correct functioning and to discover aspects of their behavior. having generated representations of gui behavior, we are ready to define the coverage criteria for events and states. considering test cases generation, some user behaviors will be more likely than other. consequently if test cases are generated randomly then there is no guarantee that interesting behaviors will be tested. to address this, several alternatives to generating test cases are proposed in the literature. as example finite state machine (fsm) are used to model system and to generate test cases [sl89, ura92]. test cases are generated from fsm-based specifications through several methods. these methods are: the transition tour (t) method; the distinguishing sequence (d) method; the characterizing set (w) method; the unique input/output sequence (uio) method; the single uio (suio) method; and the multiple uio (muio) method. all these methods need fully specified finite state machines, i.e. for each state and for each event, a unique transition must be defined (in some cases, null transitions). fully specified state machines have the same set of inputs for each state. however, many graphical user interfaces have different set of inputs for their states. one tedious solution is to add transitions that point back to the same state with null output. shehady has defined an alternative solution (vfsm variable finite state machine) which is to have a conversion algorithm automatically add transitions and null outputs when needed to fully specified finite state machine [ss97]. another alternative is the use of graphs. graphs have been widely used to model systems in diverse areas. memon’s approach about coverage criteria for gui testing make use of an event flow graph for gui’s behavioral representation [msp01]. the paper describes a methodology for generating test cases from gui behavior graph-based specifications. coverage criteria are presented to help determine whether a gui has been adequately tested. ping li describes an another approach to testing gui systems in [lhrm07]. in the proposed approach, gui systems are divided into two abstract tiers: the component tier and the system tier. on the component tier, a flow graph is created for each gui component, describing (relationproc. opencert 2010 12 / 18 eceasst ships between the pre-conditions, event sequences and post-conditions). on the system tier, the components are integrated resulting in a view of the entire system. finally, tests on the system tier analyse the interactions between the components. 5.3.2 coverage criteria because our gui’s model representation can be viewed as a graph, we applied the memon approach about coverage criteria for gui testing [msp01]. in this section, we define several coverage criteria for events and their interactions following memon’s approach. we first formally define an event sequence, which is used to describe all the coverage criteria. an event-sequence is a tuple < el, e2, e3, ..., en > where ei is a particular event which can be executed after event ei−1, 2 ≤ i ≤ n. next we present three coverage criterion applied to gui behavior graph-based specifications. • event coverage: the event coverage criterion enables to capture a set of event-sequences considering all possible events. the event coverage criterion is satisfied if and only if for any event e, there is at least one event sequence es such that es contains e. • state coverage: state coverage requires that each state is reached at least once, i.e. for any state s there is at least one event-sequence es such that state s is reached in es. • length-n-event-sequence coverage: within gui systems, the behavior of events may change when executed in different contexts. the length-n-event-sequence coverage criterion define the set of event-sequences which contains all event-sequences of length equal to n. as example the length-n-event-sequence coverage criterion applied to the agenda’s behavioral model in figure 3 returns the following number of test cases: length-n 1 2 3 4 5 6 7 8 9 10 total 1 3 4 10 40 190 940 4690 23440 117190 table 1: total number of event-sequences for n event-sequence length the result of this criterion show that the total number of event sequences grows with increasing length. the large number of event sequences turns difficult to test a gui for all possible event sequences. memon proposes to assign priorities to each event-sequence and first test event-sequences with higher priorities. as example, event-sequences related with the main window could have a higher priority since they may be used more times. a test suite is a set of input sequences starting from the initial state of the machine. intuitively, if a test suite satisfies event coverage, it also satisfy state coverage. in other hand event coverage and state coverage are special case length-n-event-sequence coverage. in some cases, it can be usefull to consider the overall behavior of the gui. this perspective can be achieved trough a unique path reaching all possible states (or all possible events) between a start state and a final state. these particular test cases can be generated through chinese postman tour and travelling salesman problem algorithms, described in next two sections. 13 / 18 volume 33 (2010) gui inspection from source code analysis 5.3.3 chinese postman tour the background of the chinese postman problem is about a chinese postman who wishes to travel along every road in a city in order to deliver letters, while traveling the least possible distance. solving the problem corresponds to finding the shortest route in a graph in which each edge is traversed at least once [thi03, pc05]. if the path must get back to the starting point, the problem is said to be closed. if it does not need to go back, it is called an open problem. the algorithm to solve the open problem can be used to generate minimal sequences of user actions between pairs of states, each sequence including all possible users actions in the interface. these sequences can then be used as test cases for testing the interface against defined properties. the length of the optimal path for the closed problem acts as a measure of the user interface’s complexity [thi03]. if we consider weighted graphs, and assign weights to the transitions that correspond to the time users are expected to take performing the corresponding actions, then the optimal path for closed problem might be used to calculate how long a user takes to explore an entire application. 5.3.4 travelling salesman problem the travelling salesman problem (tsp) considers a salesman whose task is to find a shortest possible tour that visits each city in a region exactly once. even though the problem is computationally difficult, a large number of exact methods and heuristics have been proposed, making it possible to solve instances with tens of thousands of cities. while in the chinese postman problem the goal is to traverse every edge at least once, in the travelling salesman problem the goal is to visit every node. there is no need to use all edges in the graph. paths produced as a solution to this problem will guarantee that all window states will be visited by the user, while keeping user actions to a minimum. 5.3.5 properties verification the reverse engineering approach described in this paper allows us to extract gui behaviour model as graphs. using these graphs, we are able to test gui properties [bel01, bum96, pat95]. previous sections define alternatives to generate particular test cases. this section describes a study enabling us to validate random gui test cases. to test gui properties, we make use of the quickcheck haskell library tool. quickcheck [ch00] is a tool for testing programs automatically. the programmer provides a specification of the program and properties to satisfy. then quickcheck tests the properties in a large number of randomly generated cases. specifications are expressed in haskell, using combinators defined in the quickcheck library. quickcheck provides combinators to define properties, observe the distribution of test data, and define test data generators. considering the agenda application above, and its gui behavior graph expressed as a haskell specification, we could now generate test cases now and write some properties and test them through the quickcheck tool. test cases could be obtained through algorithms described in above subsections 5.3.2, 5.3.3 and 5.3.4. each algorithm defines a particular view of the user interaction with the analysed interactive system. proc. opencert 2010 14 / 18 eceasst as example, through the agenda’s test cases, we can define a property to check that from all states its possible to reach the central state with biggest pagerank value, i.e. state number 7 in figure 4. the respective quickcheck property could be defined as follows: rule1 (n (a,b)) = classify ((length b)<=10) "events sequence length: <=10" $ classify ((length b)>10) "events sequence length: >10" $ (intersect [15,16,18,20,22,28,29] b) /= [] parameters a and b defines a particular test case. the first parameter contains an events’s identifiers sequence. the second parameter contains respective conditions’s identifier for each event. values 15, 16, 18, 20, 22, 28 and 29 refer to edges identifiers from figure 4 which have central state number 7 as target. the property enables to check if all test cases contains at least one of these edges. the number of randomly generated test cases and events length are specified by the guisurfer user. each random case is a sequence of valid events associated with their conditions. 6 discussion guisurfer makes possible high-level graphical representation of thousand of lines of code. the process is almost automatic and enables reasoning over the interactive layer of computing systems. a particular emphasis is being placed on developing tools that are, as much as possible, language independent. through the use of generic programming techniques, the developed tool aims at being retargetable to different user interface programming toolkits and languages. at this time, the tool supports (to varying degrees) the reverse-engineering of java code, either with the swing or the gwt (google web toolkit) toolkits, and of haskell code, using the wxhaskell gui library. originally the tool was developed for java/swing. the wxhaskell and gwt retargets have highlighted successes and problems with the initial approach. the amount adaptation and the time it took to code are distinct. the adaptation to gwt was easier because it exploits the same parser. the adaptation to wxhaskell was more complex as the programming paradigm is different, i.e. functional. results show the reverse engineering approach adopted is useful but there are still some limitations. one relates to the focus on event listeners for discrete events. this means the approach is not able to deal with continuous media and synchronization/timing constraints among objects. another has to due with layout management issues. guisurfer cannot extract, for example, information about overlapping windows since this must be determined at run time. thus, we cannot find out in a static way whether important information for the user might be obscured by other parts of the interface. a third issue relates to the fact that generated models reflect what was programmed as opposed to what was designed. hence, if the source code does the wrong thing, static analysis alone is unlikely to help because it is unable to know what the intended outcome was. for example, if an action is intended to insert a result into a text box, but input is sent to another instead. however, if the design model is available, guisurfer can be used to extract a model of the implemented system, and a comparison between the two can be carried out. 15 / 18 volume 33 (2010) gui inspection from source code analysis using guisurfer, programmers are able to reason about the interaction between users and a given system at a higher level of abstraction than that of code. the generated graphs are amenable to analysis via model checking (c.f. [ch09]). here however, we have explored alternative, lighter weight approaches. considering that the graphs generated by the reverse engineering process are representations of the interaction between users and system, we have explored how metrics defined over those graphs can be used to obtain relevant information about the interaction. this means that we are able to analyze the quality of the user interface, from the users perspective, without having to resort to external metrics which would imply testing the system with real users, with all the costs that process carries. additionally, we are exploring the possibility of analyzing the graphs via a testing approach, and how best to generate test cases. it must be noted that, while the approach enables us to analyze aspects of user interface quality without resorting to human test subjects, the goal is not to replace user testing. ultimately, only user testing will provide factual evidence of the usability of an user interface. the possibility of performing the type of analysis we are describing, however, will help in gaining a deeper understanding of a given user interface. this will promote the identification of potential problems in the interface, and support the comparison of different interfaces, complementing and minimizing the need to resort to user testing. similarly, while the proposed metrics and analysis relate to the user interface that can be inferred from the code, the approach is not proposed as an alternative to actual code analysis. metrics related to the quality of the code are relevant, and indeed guisurfer is also able to generate models that capture information about the code itself. again, we see the proposed approach as complementary to that style of analysis. 7 conclusion in what concerns user interface development, two perspectives on quality can be considered. users, on the one hand, are typically interested on what can be called external quality: the quality of the interaction between users and system. programmers, on the other hand, are typically more focused on the quality attributes of the code being produced. this work is an approach to bridging this gap by allowing us to reason about gui models from source code. we described gui models extracted automatically from the code, and presented a methodology to reason about the user interface model. a number of metrics over the graphs representing the user interface were investigated. some initial thoughts on testing the graph against desirable properties of the interface were also put forward. a number of issues still needs addressing. in the example used throughout the paper, only one windows could be active at any given time (i.e., windows were modal). when non-modal windows are considered (i.e., when users are able to freely move between open application windows), nodes in the graph come to represents sets of open windows instead of a single active window. this creates problems with the interpretation of metrics that need further consideration. the problem is exacerbated when multiple windows of a given type are allowed (e.g., multiple editing windows). coverage criteria provide an objective measure of test quality. we plan to include coverage proc. opencert 2010 16 / 18 eceasst criteria to help determine whether a gui has been adequately tested. these coverage criteria use events and event sequences to specify a measure of test adequacy. since the total number of permutations of event and condition sequences in any gui is extremely large, the gui’s hierarchical structure must be exploited to identify the important event sequences to be tested. this work presents an approach to the reverse engineering of gui applications. models enable us to reason about both metrics of the design, and the quality of the implementation of that design. our objective has been to investigate the feasibility of the approach. we believe this style of approach can feel a gap between the analysis of code quality via the use of metrics or other techniques, and usability analysis performed on a running system with actual users. acknowledgements: this work is supported by the portuguese research foundation (fct) under contracts: ptdc/eia-cco/108995/2008, ptdc/eia-cco/108613/2008, and sfrh/ bsad/782/2008. bibliography [bel01] f. belli. finite state testing and analysis of graphical user interfaces. in proceedings.of the 12th international symposium on software reliability engineering, issre 2001. pp. 34–42. ieee, november 2001. [ber05] p. berkhin. a survey on pagerank computing. internet mathematics 2:73–120, 2005. [bum96] p. bumbulis. combining formal techniques and prototyping in user interface construction and verification. phd thesis, university of waterloo, 1996. [ch00] k. claessen, j. hughes. quickcheck: a lightweight tool for random testing of haskell programs. in proceedings of international conference on functional programming (icfp), acm sigplan, 2000. 2000. [ch09] j. c. campos, m. d. harrison. interaction engineering using the ivy tool. in acm symposium on engineering interactive computing systems (eics 2009). pp. 35–44. acm, new york, ny, usa, 2009. [iso99] iso/iec. software products evaluation. 1999. dis 14598-1. [j.76] m. t. j. a complexity measure. intern. j. syst. sci. 2(4):308, 1976. [lhrm07] p. li, t. huynh, m. reformat, j. miller. a practical approach to testing gui systems. empirical softw. engg. 12(4):331–357, 2007. [msp01] a. m. memon, m. l. soffa, m. e. pollack. coverage criteria for gui testing. in esec/fse-9: proceedings of the 8th european software engineering conference held jointly with 9th acm sigsoft international symposium on foundations of software engineering. pp. 256–267. acm press, new york, ny, usa, 2001. [nie93] j. nielsen. usability engineering. academic press, san diego, ca, 1993. 17 / 18 volume 33 (2010) gui inspection from source code analysis [pat95] f. d. paternò. a method for formal specification and verification of interactive systems. phd thesis, department of computer science, university of york, 1995. available as technical report ycst 96/03. [pc05] w. l. pearn, w. c. chiu. approximate solutions for the maximum benefit chinese postman problem. intern. j. syst. sci. 36(13):815–822, 2005. [sa09] s. y. shan, et al. fast centrality approximation in modular networks. 2009. [saob02] i. stamelos, l. angelis, a. oikonomou, g. l. bleris. code quality analysis in open source software development. information systems journal 12:43–60, 2002. [scs06a] j. silva, j. c. campos, j. saraiva. combining formal methods and functional strategies regarding the reverse engineering of interactive applications. in interactive systems, design, specifications and verification, lecture notes in computer science. dsv-is 2006, the xiii international workshop on design, specification and verification of interactive system, dublin, ireland. pp. 137–150. springer berlin / heidelberg, july 2006. [scs06b] j. silva, j. c. campos, j. saraiva. models for the reverse engineering of java/swing applications. atem 2006, 3rd international workshop on metamodels, schemas, grammars and ontologies for reverse engineering, genova, italy, october 2006. [scs09] j. silva, j. c. campos, j. saraiva. a generic library for gui reasoning and testing. in in acm symposium on applied computing. pp. 121–128. march 2009. [sl89] d. p. sidhu, t.-k. leung. formal methods for protocol testing: a detailed study. ieee trans. softw. eng. 15(4):413–426, 1989. [ss97] r. k. shehady, d. p. siewiorek. a method to automate user interface testing using variable finite state machines. in ftcs ’97: proceedings of the 27th international symposium on fault-tolerant computing (ftcs ’97). p. 80. ieee computer society, washington, dc, usa, 1997. [tg08] h. thimbleby, j. gow. applying graph theory to interaction design. pp. 501–519, 2008. [thi03] h. thimbleby. the directed chinese postman problem. in journal of software practice and experience, 2003. [tip95] f. tip. a survey of program slicing techniques. journal of programming languages, september 1995. [ura92] h. ural. formal methods for test sequence generation. in computer comm. pp. 311–325. 1992. [yy07] y. s. yoon, w. c. yoon. development of quantitative metrics to support ui designer decision-making in the design process. in human-computer interaction. interaction design and usability. pp. 316–324. springer berlin / heidelberg, 2007. proc. opencert 2010 18 / 18 introduction guisurfer tool gui inspection from source code an agenda application gui inspection through graph theory graph-tool gui metrics shortest distance pagerank betweenness cyclomatic complexity gui test cases generation related work coverage criteria chinese postman tour travelling salesman problem properties verification discussion conclusion transforming collaborative service specifications into efficiently executable state machines electronic communications of the easst volume 7 (2007) proceedings of the sixth international workshop on graph transformation and visual modeling techniques (gt-vmt 2007) transforming collaborative service specifications into efficiently executable state machines frank alexander kraemer and peter herrmann 15 pages guest editors: karsten ehrig, holger giese managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst transforming collaborative service specifications into efficiently executable state machines frank alexander kraemer and peter herrmann norwegian university of science and technology (ntnu), department of telematics, n-7491 trondheim, norway abstract: we describe an algorithm to transform uml 2.0 activities into state machines. the implementation of this algorithm is an integral part of our toolsupported engineering approach for the design of interactive services, in which we compose services from reusable building blocks. in contrast to traditional approaches, these building blocks are not only components, but also collaborations involving several participants. for the description of their behavior, we use uml 2.0 activities, which are convenient for composition. to generate code running on existing service execution platforms, however, we need a behavioral description for each individual component, for which we use a special form of uml 2.0 state machines. the algorithm presented here transforms the activities directly into state machines, so that the step from collaborative service specifications to efficiently executable code is completely automated. each activity partition is transformed into a separate state machine that communicates with other state machines by means of signals, so that the system can easily be distributed. the algorithm creates a state machine by reachability analysis on the states modeled by a single activity partition. it is implemented in java and works directly on an eclipse uml2 repository. keywords: model transformation, uml 2.0, activities, state machines 1 introduction in a highly competitive market for modern networked services, it is important to deliver new services with short development times, in order to react on new customer demands quickly and to keep development costs low. these efforts are hampered by the typically high complexity of such services, which arises mainly from the fact that a service needs the coordinated effort of several participating components (cf. [1]). hence, if we want to understand what a service does, we have to look at the behavior of all its participating components. moreover, when services need to be adjusted or composed from other services, we must consider the descriptions of all participating components again and make sure that they interact correctly. literature (e.g., [2]) as well as experience from our own work [3, 4, 5] stated that there are two dominant perspectives on a system delivering services: • in the component-oriented perspective, systems are decomposed into physically distributed components, which are modelled separately. services are specified indirectly by the composed behavior of the components. this perspective is well supported by traditional standards like sdl and its descriptions are typically easily transformable into executable code. 1 / 15 volume 7 (2007) transforming collaborative service specifications into executable state machines code generationmodeltransformation collaboration-oriented: uml 2.0 collaborations + activities component-oriented: uml 2.0 state machines executable system service composition libraries of reusable service building blocks figure 1: engineering approach for interactive services • in the collaboration-oriented perspective, services are modeled by a number of collaborations as the main structuring elements. a collaboration specifies the interactions between the components involved in it, as well as the corresponding local behavior of the components to accomplish the service. collaborations describe services in a self-contained form and may be composed from other ones. within an application domain, collaborations contributing to a service are often similar which makes them ideal elements of reuse. these two perspectives are the shaping forces behind our approach for the rapid engineering of interactive services, outlined in fig. 1. services are composed from collaborations that identify the interactions as well as the local behavior of a set of components that are necessary to fulfill a certain task. to express the structural aspects of collaborations as well as their composition (e.g., the participants and which roles they play in a service), we use the conforming concept of uml 2.0 collaborations. for the behavioral aspect (e.g., what a collaboration does as well as how collaborations are coupled together), we use uml 2.0 activities. as an example, we consider an access control system (acs) [6, 7]. it controls the opening mechanism of a door and lets pass only authorized people that can prove their identity by presenting a security card and a secret number at an input panel. the opening mechanism and input panel are connected to a local station installed close to the door. once a user draws the card and enters the pin, the resulting data (called pid) is transferred to a central station that authenticates the user and checks authorization right by querying two servers. if both, the authentication and authorization are successful, ok is sent back to the local station that opens the door. in [4] we introduced how the acs can be easily composed from reusable collaboration elements expressed by a combination of uml 2.0 collaborations for the structure (fig. 2) and activities for the behavior (fig. 3). these diagrams describe the system from a collaboration oriented perspective. to execute the system, however, we need a description of the behavior of the individual components, i.e., a description from a component-oriented perspective, as outlined above. in our approach, we use for this purpose so-called executable uml 2.0 state machines and composite structures, that are a suitable input for our code generators. to automate the step from the collaboration-oriented specifications in form of activities to the component-oriented design in form of state machines, we use a model transformation performed by the algorithm described in this article. evidently, the introduction of such an automated transformation step accelerates the development of services drastically. in addition to the omission of manual labor for constructing the state machines, no new errors are introduced. whenever a service specification needs to be updated, the state machines are simply generated again to ensure consistency. the algorithm creates the state machines without any intermediate representation and is therefore quite efficient concerning memory usage. before we describe the principles of the transformation in sect. 4 and the detailed algorithm in sect. 5, we outline in the next two sections the two proc. gt-vmt 2007 2 / 15 eceasst local station :door control door panel :panel control authorization server :authenticate :authorize authentication server central station :transfer figure 2: collaboration to compose the sub-services of the access control system transfer door control authenticate authorize local station access control system central station authorization server authentication server unlock lock nok pid ok nok pid prep1 [ok1] [nok2] val1 retrieve prep2 val2 retrieve [ok2] [nok1] ok w1 w2 w3 w4 d1 d2 f1 j1 j2 j3 j4 m1 panel control res1 res2 figure 3: activity diagram modeling the detailed behavior of the system development perspectives outlined above. sect. 6 sketches then a proof of the correctness of the transformation in temporal logic. we close with a discussion of related approaches and some concluding remarks. 2 collaborations and activities for service composition while the collaboration in fig. 2 shows how the system is composed structurally from elementary collaborations that were taken from a library, the activity diagram in fig. 3 states how their behavior is coordinated. for each collaboration use of fig. 2 (e.g., authenticate), we find a structured node (in dashed lines) in the activity that specifies the behavior contributed by the collaboration use. each collaboration role of fig. 2 (e.g., central station) is a location of computation and represented by an activity partition in fig. 3. the door and the panel are part of the environment, and, hence, do not have their own activity partition. instead, they communicate with the local station by explicit signal send and receive actions. the local station receives a pid from the panel control and forwards it via the transfer collaboration to the central station. depending on the result received from the central station (ok or nok), the local station will either cause the panel to display nok and leave the door locked, or it will cause the panel display to show ok and unlock the shutter of the door. in this case, a timer will be started which locks the 3 / 15 volume 7 (2007) transforming collaborative service specifications into executable state machines central station 0 2 res1 / d nok1 nok nok2 0 nok ok2 0 prep1 req1 req2 prep2 * 0 local station 0 res1 0 retrieve 0 res2 0 retrieve authentication s. authorization s. 4 res1 / d ok1 val1 val2 val2 nok nok2 0 ok ok2 0 val2 8 res2 / d nok2 nok nok1 0 nok ok1 0 16 res1 / d ok2 val1 nok nok1 0 ok ok1 0 val1 res1 res2 res2 pid req1 req2 res2 res1 res1 ok unlock 1 set timer lock 0 ok timer * nok nok * pid pid * figure 4: executable state machines for the system components door shutter again after a while. as activities have a petri net like semantics [8], we can use tokens and places to understand the behavior of the diagram in fig. 3. once a token representing a pid arrives at the central station, it is prepared (described by the operations prep1 and prep2) and sent to the authentication respective the authorization server. for that, the token is duplicated at the fork node f1, so that the subsequent behaviors may happen in parallel. both servers evaluate the pid and send their results back to the central station. the results may arrive in any order. for example, if the result of the authorization server arrives first, it is evaluated by the central station (operation val2) which branches in decision d2 depending on the validity of the authorization. if the result was valid, a token is placed in w4. this node is an extension of a decision node (cf. [4]) as tokens can rest in it. it is represented by a filled diamond. the central station waits now for the arrival of the authentication result, which is evaluated in val1, and a token is placed either on w1 or w2. when the other result arrives, two waiting decisions hold one token, so that exactly one of the join nodes j1..j4 can fire. obviously, j4 fires in the case that both results were ok and causes the central station to send an ok to the local station. in the other three cases (when at least one result is nok) one of the other join nodes j1..j3 fires. these cases are combined by merge node m1 and a nok is sent to the local station. we assume that the panel control only sends a new pid after it received an ok or a nok. 3 state machines for service execution fig. 4 presents the executable uml state machines generated by our algorithm from the activity in fig. 3. the state machines interact with each other by transmitting signals which are buffered in event queues. similar to sdl, uml allows for the use of send signal actions and signal triggers to describe the transmission and reception of signals. each state machine has an initial state and a number of transitions that are triggered by either signal receptions or by timeouts. transitions may include choices guarded by constraints (like ok1). as an effect, a transition may execute actions such as the sending of signals, the call of an operation (like val1) or the control of a timer. states can declare an event to be deferred by listing it in their body followed by the keyword “/defer” (abridged here to “/d”). this event is left in the queue until a state is entered that does not defer it anymore but declares a transition for its consumption. for compactness, we proc. gt-vmt 2007 4 / 15 eceasst presented a transition that can be executed from any control state by referring to a state called “*”. after it executes, the state machine returns into its originating state, denoted by “-”. as these executable state machines are the input for our code generators [9], they must fulfill some constraints to achieve efficient code. in particular, they are event-driven, which means that each transition is only executed as the reaction to either the creation of the state machine itself, the reception of a signal, or the expiration of an internal timer. in consequence, transitions are enabled based purely on their source state and trigger, so that guards may only be declared on branches following choices. moreover, for each pair of control state and trigger, merely one transition may be declared to prevent fairness conflicts between competing transitions. these executable state machines have a long tradition in the telecommunication area (see for example [10]) and facilitate the efficient implementation on a range of different platforms and architectures, including j2ee. we defined in [5] their execution semantics in terms of temporal logic and described, how they can be efficiently implemented using a scheduler as virtual machine layer. of course, the constraints on the executable state machines needed to generate efficient code highly influence the layout of our algorithm which we discuss in the following. 4 transformation from activities to state machines in our approach, an activity partition corresponds to one physical point of execution. we therefore generate one state machine for each activity partition. this also makes it possible to consider the activity partitions separately and not the entire activity, as discussed later. to separate the partitions from each other, we have to cut those edges which cross partition borders. these edges model the control flows between different system components. as communication between the state machines is done entirely by means of signals, a flow crossing the boundaries of activity partitions must be implemented as a signal transmission. in activities, flows between actions occur instantaneously, i.e., a token leaves an action and enters a subsequent one without resting in the flow. the transmission between state machines, however, is buffered. introducing signal transmissions in flows between partitions therefore implies virtual places that may hold tokens. we add these places where flows enter a partition, as illustrated in fig. 5 by the circles with the queue symbols inside. these so-called queue places simulate the input queue of the state machines implementing an activity partition. in the model, these input queues are of unlimited capacity1. thus, the virtual places are unbounded (i.e., can hold any number of tokens). as described above, the state machines execute a transition as a reaction to the arrival of a signal. this event corresponds to the emission of a token from the virtual queue places. hence, when we construct a transition, we simulate the emission of one token from a queue place. the token passes along the flows and nodes of the activity diagram until it reaches a control node where it has to wait for further events to happen. these are three kinds of nodes: (1) join nodes synchronize different flows, that may arrive in any order. an incoming token may have to wait for the other incoming flows to arrive. (2) waiting decisions synchronize competing join nodes (see sect. 2). a token has to rest inside a waiting decision if none of the succeeding joins can fire. (3) timer nodes may contain tokens describing that the timers are active. fig. 5 (a) illustrates also the inner places of the central station in which tokens rest to wait for 1 of course, in an implementation, buffer capacity is limited, which can be addressed the means described in [5]. 5 / 15 volume 7 (2007) transforming collaborative service specifications into executable state machines access control system central station nok pid prep1 [ok1] [nok2] val1 prep2 val2 [ok2] [nok1] ok w 1 w3 w4 d1 d2 f1 j1 j2 j3 j4 m1 w2 scenario before i) join input arrives ii) join fires after iv) waiting decision fires join iii) waiting decision is loaded res1 res2 a) b) figure 5: (a) places for the nodes (b) rules for token transitions further input events. in contrast to the queue places, these inner places will constitute the control states of the state machine. for instance, the token in the waiting decision w2 of fig. 5 (a) means that a valid authentication result arrived and that the central node waits for the result of the authorization. (the join nodes do not have own places, as all their incoming flow originate from waiting decisions, which hold the token instead.) for the number of control states to be finite, the number of tokens in an inner place must be bounded. moreover, to keep the state space small, we allow only one token in each inner place. this is not a limitation since tokens that would fill an inner place are stored in the unlimited queue places as discussed later. the set of control states for one state machine is then the powerset of the inner places. we can construct a state machine transition by following the passing of the tokens between two stable token markings. the marking of the inner places before passing the tokens define the source state of the transition and the next stable marking refer to the target state. the token taken from a queue place models the input signal consumed by the transition. the activity nodes passed by the token are transformed in the following way: call operation actions and send signal actions are simply copied into the effect of a transition. decision nodes with guards are added to the transition and lead to different branches. a flow leaving the current activity partition is translated to a send signal action. fork nodes duplicate tokens, to that the subsequent flows are executed in parallel. in the transition, this is mapped by executing their actions interleaved. for instance, the transition triggered by pid in central station in fig. 4 simply executes first the action prep1 and then prep2. initial nodes emit tokens once the activity is started and are treated by the initial transition of a state machine. a problem is the handling of joins. the passing of a token after all incoming flows arrived would result in a transition without a trigger event, violating constraints of our event-driven state machines. therefore we use the token passing rules illustrated in fig. 5 (b). when a token arrives at a join and there are other incoming edges that do not yet offer a token (since their flow did not arrive yet), the token is stored and a new stable control state is reached (i), awaiting the next event. if, however, the arriving token completes the join (ii), the transition continues with its outgoing edge, and all tokens of the incoming edges are removed. waiting decisions work similarly, but consider a set of subsequent join nodes. if none of these joins is ready, the decision proc. gt-vmt 2007 6 / 15 eceasst is filled with a token (iii), and a new stable state is reached. if one of the joins is ready, the transition continues at its outgoing edge, consuming the token from the decision node (iv). in addition to the events of signal reception resulting from the split control flows, explicit signal receptions contribute to the set of unbounded queue places. furthermore, timers are sources of events. when a timeout occurs, a token is emitted on the timer’s outgoing edge. the transition is then constructed in the same way as for signal receptions. some events may lead to states describing that an inner place contains more than one token. for example, if the central station is connected to several local stations, a pid could arrive while another pid is under evaluation. in this case it might happen, that, after the central station received a valid res1 and waits for res2, another valid res1 is coming, which requires node w2 to hold two tokens. to prevent this, we do not create a transition for flows leading to a marking with several tokens in an inner place, but defer the incoming event, which may proceed after the inner place is emptied. 5 the transformation algorithm to realize the transformation from activities to state machines introduced above, we can proceed in quite different ways. for instance, one could perform a complete reachability analysis over all allowed token allocations in the previously introduced inner and queue places of an activity and create a transition for every step. the disadvantage is that, especially in highly concurrent systems, the number of reachable states is very large, rendering the approach not scalable. another possibility would be to perform a purely syntactical analysis of an activity. here, for each edge between places, a set of transitions is generated. thereby, a separate transition is created for all states in which tokens are contained in the corresponding places. this algorithm is quite efficient since every inner place of the activity is checked only once, but will lead to a large number of transitions leaving unreachable states. to prevent these disadvantages, we follow an intermediate approach. reflecting that for every activity partition a separate state machine is created, we perform a reachability analysis over the states of an activity partition only, which are constituted by its inner places. thus, the number of reachable states is kept small. starting from the initial state, for each reached state and every possible input signal a separate transition is created. as we handle each incoming signal in all control states, some of these transitions may be never fired (if their input signal cannot occur in the state). however, an unnecessary transition would simply result in a code fragment that is never executed. while this is not a real problem, nevertheless, we plan to eliminate these transitions using interface descriptions of the other partitions. these interface descriptions may be offered as part of the collaboration building blocks of a library. in the following, we explain our algorithm in detail. fig. 6 depicts the main loop (lines 7 to 27 ). as in most reachability analysis algorithms, this loop guarantees that all reachable markings of an activity partition are analyzed. the markings yet to be checked are listed in the variable reachable while visited contains all markings which were already analyzed. in the initial part of the algorithm (1..6), a new and empty state machine is created. thereafter, the first marking to be checked, the initial transition of the state machine and the set of events to be received by the state machine are computed. as our algorithm creates a state machine transition for each pair of reachable marking and event (see sect. 4), the loop contains a nested for-loop (10..26) cycling through all events. the for-loop contains two nested if-statements. the first one (11..25) is used 7 / 15 volume 7 (2007) transforming collaborative service specifications into executable state machines transform(activitypartition a) : statemachine 1 var stm: statemachine = new statemachine() 2 var firststate: state = computefirststate(a) 3 createinitialtransition(firststate, stm) 4 var events: set of event = computeevents(a) 5 var visited: set of state = /0 6 var reachable: set of state = {firststate} 7 while reachable 6= /0 do 8 var current: state = reachable.removefirst(); 9 visited = visited ∪ {current} 10 for all e ∈ events do 11 if ¬(e is timeout ∧ timeractive(current)) then 12 if harmsboundedness(current, e) then 13 current.deferevent(e) 14 else 15 var t: transition = new transition(stm); 16 t.setsource(current) 17 t.settrigger(e) 18 var marking: long = getmarking(current) 19 if e is timeout then marking = unsettimer(e,marking) 20 var edge edge = retrieveedge(e) 21 var targets: set of state 22 = buildtransition(edge,marking,t,a,stm) 23 reachable = reachable ∪ (targets / visited) 24 end if 25 end if 26 end for 27 end while 28 return stm. � figure 6: main control to ignore events triggered by a timer which is not active in the current state. the second ifstatement enables us to handle violations of the desired 1-boundedness property correctly. if the traversal of an edge in the checked activity would lead to two or more tokens in any inner place, the algorithm does not create a transition but defers the event in the current state (13). otherwise, a new transition is built in the else-statement (15..23). the transitions of a state machine are created by means of the recursive method buildtransition (20), listed in fig. 7. it considers the traversal of a token from one stable marking to another. for each edge part of the flow triggered by the event it is called recursively and builds the corresponding transition along the way. the method returns the set of stable states reached by the transition. it is a set, as a flow may lead to several distinct reachable states after a decision node. the returned states are used by the main loop to determine the reachable markings of the partition yet to be checked. the method contains an order of nested if-statements describing the behavior for each possible node in the analyzed activity edge. it returns if the edge leaves the partition (2), reaches a join which cannot be fired in the current activity marking (12), starts a timer (17), arrives at a waiting decision in which none of the corresponding joins can be fired in the current marking (50), or reaches a flow final resp. activity final node (58, 62). in all these cases a new stable state is reached and the created transition can be completed. when another edge is reached, the transition is not yet complete and its building process has to be continued by a recursive call of buildtransition. these cases are a join which can be executed after being reached by a token on the analyzed edge (10), a send action (27), an operation call (30), a merge (32), a decision (40), a waiting decision from which a corresponding join can be fired after being reached by a token (48), and a fork (57). while most steps in creating a transition follow directly the ideas presented in sect. 4, we will look now on the decisions and forks which are a little subtle. a decision leads to the addition of a choice pseudo state to the transition behind which more than one continuing transition fragments are added. this is done by the for-loop (36..42) which calls buildtransition for each of the choice’s branches. arriving at a fork (55) means that tokens are emitted at each outgoing edge and actions of different flows are carried out in parallel. as one state machine executes only one action at a time, we map parallel executing flows inside one activity partition to an interleaved execution, which is a correct refinement. this execution is computed by the method collecteffects which is not listed here for the sake of brevity. proc. gt-vmt 2007 8 / 15 eceasst buildtransition(edge edge, long c, transition t, activitypartition a, statemachine stm) : set of state 1 var node: node = edge.gettarget() 2 if leavespartition(edge,a) then 3 addsendsignalaction(t,edge) 4 var target: state = getstate(c) 5 t.settarget(target) 6 return {target} 7 else if node is join then 8 if canfire(join,c) then 9 var n: long = markingafterjoinfired(c) 10 return buildtransition(outgoing(edge),n,t,a,stm) 11 else 12 var n: long = markingafterjoininputarrived(c) 13 var target: state = getstate(n) 14 t.settarget(target) 15 return {target} 16 end if 17 else if node is timer then 18 addsettimeraction(t,node) 19 var n : long = markingaftertimerset(c) 20 var target: state = getstate(n) 21 t.settarget(target) 22 return {target} 23 else if node is send action then 24 addsendsignalaction(t,node) 25 var target: state = getstate(c) 26 t.settarget(target) 27 return buildtransition(outgoing(node),c,t,a,stm) 28 else if node is call operation action then 29 t.addeffect(node) 30 return buildtransition(outgoing(node),c,t,a,stm) 31 else if node is merge then 32 return buildtransition(outgoing(node),c,t,a,stm) 33 else if node is decision then 34 var p: pseudostate = new pseudostate(stm,choice) 35 var reachable: set of state 36 for all o ∈ node.outgoings() do 37 var t = new transition(stm) 38 t.setsource(p) 39 t.setguard(o.getguard()) 40 var r: set of state = buildtransition(o,c,t,a,stm) 41 reachable = reachable ∪ r 42 end for 43 return reachable 44 else if node is waiting decision then 45 for all o ∈ node.outgoings() do 46 var join: node = o.target; 47 if canfire(join, marking) then 48 return buildtransition(o,c,t,a,stm) 49 end if 50 end for //no join could fire 51 var n : long = markingafterdecisionset(c) 52 var target: state = getstate(n) 53 t.settarget(target) 54 return {target} 55 else if node is fork then 56 collecteffects(outgoings(node),t) 57 return computeforkedstate(outgoings(node)) 58 else if node is flow final then 59 var target: state = getstate(c) 60 t.settarget(target) 61 return {target} 62 else if node is activity final then 63 t.settarget(new finalstate(stm)) 64 return {} 65 end if � figure 7: method to build a transition 6 correctness of the transformation to verify that the algorithm carries out transformations in a correctness-preserving manner, we use the linear-time temporal logic ctla [12] as a formalism which is based on leslie lamport’s tla [13]. ctla enables the description of resources and constraints in a process-like notion and provides a coupling structure based on conjoining actions (i.e., predicates on pairs of states describing sets of transitions). refinement verifications are carried out as temporal logic implication proofs (cf. [13]). as the semantics of activities is based on petri-nets [8], uml 2.0 activities can easily be expressed by ctla processes as pointed out in [14]. an activity, basically, is a ctla system description consisting of processes each describing a single activity partition. the variables of a process model its inner places while each queue place of a partition is described by a separate input queue. for the state machines forming the input of our code generators, we defined a special dialect ctla/e [5] which describes the coupling between components by assigning a single input queue to each component. a state machine transition is specified by a ctla action which 9 / 15 volume 7 (2007) transforming collaborative service specifications into executable state machines reflects that the transition depends only on the current state and the first signal in the input queue. moreover, each component contains an extra queue to handle deferred events. the refinement of specifications modeling activities to ctla/e-based descriptions is carried out by a sequence of correctness-preserving refinement steps accompanied by ctla/tla implication proofs (cf. [13]). for the sake of brevity, we do not give a thorough introduction to ctla here and sketch the proof steps only briefly. to verify formally that a state machine s derived from an activity partition a keeps all the functional properties state by a, we must perform by temporal logic deductions that the implication s ⇒ a holds. according to abadi and lamport [15], this can be achieved by finding a so-called refinement mapping from the states of s to those of a. a refinement mapping takes into account that ctla enables the modeling of state transition systems. a system formula consists of an initial condition describing the set of initial states, ctla actions which are predicates on a pair of a current state and a next state and model a set of state transitions each, and liveness properties expressed by fairness assumptions on actions which enforce that actions are eventually executed when they are consistently enabled. a refinement mapping has to keep the following properties: • an initial state of s is mapped to an initial state of a. • each ctla action of s is either mapped to an action of a or to a so-called stuttering step in which the mapped current and next states of a are identical. • each fairness assumption of a is provided by the fairness assumptions of s (i.e., if an action ψ of a is consistently enabled, the fairness actions of s enforce a state sequence in which eventually an action is carried out which is mapped to ψ ). in sec. 4 we stated that the state space of an activity partition a is partly defined by its inner places which are situated before joins, at decision nodes, at initial nodes, and at timers. moreover, it contains queue places which are situated at points where an incoming flow passes the partition border and on receive actions. the state space of a state machine is defined in [5] and consists of the literal states of the state machine, an input queue, a defer queue, output queues for all connected state machines, and flags for each timer. furthermore, activities may contain auxiliary variables which our algorithm directly maps to auxiliary variables of the corresponding state machines. to outline the correctness of the algorithm, we will, in the following, list a mapping of the state space from s to that of a and sketch thereafter that it keeps the refinement mapping properties: • to find a mapping from s to the queue places of a, we have also to consider the linked state machines as the queue places mainly describe the interaction between different system elements. at an activity partition, we have a separate queue place for every signal type st while in the corresponding state machine, we have central queues for all signals. moreover, in the activity we do not distinguish if a signal is still at the side of the outgoing partition, already in the incoming partition, or deferred. reflecting these properties, we map all signals s of type st, which are either in the output queue of a neighboring state machine sn, in the input queue of s, or in its defer queue, to the queue place qpst for st in a: ∀st : qpst = {s|s.type = st ∧s ∈ inputqs ∪de f erqs ∪ ⋃ sn∈neighborss sn.out putqs} proc. gt-vmt 2007 10 / 15 eceasst • a mapping of s to the inner places of a located at joins, decision nodes, and initial nodes has to consider that we use 1-boundedness in the inner places ip and that the algorithm creates the states of s as a string of flags f lip each being set to 0 if the corresponding inner place ip is empty and to 1 if ip contains a token to: ∀ip : ip = if f lip = 1 then {to} else {} • to find a mapping from s to the inner places of a describing a timer is a little more complex. indeed, the algorithm adds also a flag ft for each timer t in a to the state representation in s. nevertheless, to find a decent mapping one has to consider the handling of timers in state machines. when a timer expires, it creates a signal which is attached to the local input queue. thus, we must map both the states of s in which the flag f lt of timer t is enabled and in which a signal st caused by t is in the input or defer queue to a setting in a where a token to is on the inner place ipt of t. that is expressed by the mapping listed below: ∀ipt : ipt = if f lt = 1∨st ∈ inputqs ∪de f erqs then {to} else {} • the mapping from the auxiliary variables from s to those of a is the identity function. in the first step of the proof that the function listed above fulfills the refinement mapping properties, we have to verify that the initial state of s is mapped to that of a. initially, the queue places in a are empty while the input, output, and defer queues of s do not contain elements as well. thus, the mapping of the queue places fulfills the property trivially. the inner places of a are empty except those located at an initial node. as discussed in sec. 5, the algorithm maps the token placement of an initial state of s in which just the flags representing the inner places of the initial nodes are set to 1. since the auxiliary variables of s and a contain the same initial settings, therefore, the initial state of s is mapped to the initial state of a. next, we prove that every ctla action in the model of the state machine s is mapped either to a ctla action of the activity partition a or to a stuttering step. as introduced in [5], the model of s contains different kinds of actions. one type describes the transitions of s and for each transition tr f , a ctla action φtr f is defined. the algorithm creates tr f only if a flow f exists modifying the token setting of a. in the following, we state a number of properties preserved by the algorithm in the creation of the corresponding transition tr f which are used for the refinement proof: 1. a transition tr f is only created if in its source state all flags f lip representing those inner places ip of f are set to 1 which have to contain tokens in order to execute f . 2. the algorithm creates tr f only for a flow f if the execution of f does not violate the inboundedness property of the inner places in a. 3. if the queue place in f , from which a token is removed, has the type st, tr f is only triggered if st is at the front of the input queue. 4. by executing a transition tr f which does not leave an initial state, the signal at the front of the input queue is consumed. 5. a transition tr f consuming a signal from the input queue which was created by a timer is generated if the corresponding flow f starts at an inner place describing a timer node. 11 / 15 volume 7 (2007) transforming collaborative service specifications into executable state machines 6. the target states of tr f are generated by starting with the source state and resetting the flags representing inner places, from which tokens were removed, to 0 while those with a new token are set to 12. 7. if in f a token is heading to the partition border with a partition an or to a send action with destination an, tr f puts a send signal into the output queue devoted to the state machine sn realizing an. 8. a call operation action passed in f is reflected by adding its code to tr f . here, we demand that an auxiliary variable may be modified only once in f and, in consequence, in tr f . assuming that φtr f is the ctla action modeling tr f and ψ f those of the flow f , these properties are sufficient to prove the implication φtr f ⇒ ψ f . by the first three properties, we can assure that the enabling condition of φtr f implies that o ψ f since according to the mapping all necessary tokens are set (1), the 1-boundedness after carrying out f is preserved (2), and the queue place from which f leaves contains an element (3). the other properties are used to verify that the effects of φtr f are correctly mapped to those of ψ f . the elimination of a signal of type st from the input queue is mapped to the removal of a token from the queue place st (4). in addition, if tr f consumes a signal st created by a timer from the input queue, st is mapped to a flow f removing a token from the corresponding timer node (5). we can further verify that tr is a correct realization of the token flow between the inner places in f (6). the delivery of a signal s to an adjacent state machine sn does not spoil the corresponding mapping of sn to a neighboring activity partition an as s is added to an incoming queue place of an if s puts it to its output queue devoted to sn (7). finally, it is guaranteed that the auxiliary variables are correctly mapped (8). it is not difficult to verify that these properties imply that the mapping listed above maps φtr f to ψ f which is omitted, however, for brevity. other ctla actions in s specify the execution of timers and the addition of timer signals to the input queue, model the deferral of a signal by transferring it from the input to the defer queue, and describe the transfer of signals from the neighbor’s output queue to the own input queue. it can be easily shown that these actions lead to stuttering steps in a. in the third step, we have to verify that the fairness assumptions of the actions ψ f describing the flows in a are kept. the algorithm guarantees that for every token placement in the inner nodes of a enabling a flow f , a transition tr f is generated implementing f . thus, with respect to the first two properties listed above, an action tr f is enabled whenever f can fire. the only impeding condition is the third property since tr f may only be executed if the signal s consumed by it is at the first place of the input queue. according to the mapping, however, the ctla action ψ f specifying f can be enabled if s is either in the output queue of the neighboring state machine sn or in any place on the input or defer queues of s. thus, we must verify that s is eventually being moved to the front of the input queue where it will remain consistently until an action φtr f is executed. if s is still in the output buffer of sn, it will be moved to the end of the input buffer of s by the fair3 action modeling the transmission from sn to s. since signals before s in the input resp. defer queue are either continuously being deferred4 or eventually being consumed. thus, 2 if a token is both removed from and added to an inner place in the same flow, its flag remains set to 1. 3 in [12] we established that liveness can only be guaranteed in a distributed system if transmitted messages are eventually being delivered. this property is expressed by the fairness assumption on the action specifying the transmission. 4 in that case, the transitions consuming them are never enabled. proc. gt-vmt 2007 12 / 15 eceasst s will be eventually at the front of the input queue. if f is not enabled, s may be deferred itself but is brought back to the front of the input queue by other transitions. as there is only a finite number of transitions tr f modeling f , in consequence, one of those will be consistently being enabled if f can be triggered as well. due to the fairness assumption of the corresponding ctla action φtr f it will be eventually fired which, because of the mapping, causes also the triggering of f . thus, we could verify that the mapping listed above is a refine mapping. according to [15], we could thereby prove that the state machine s together with its neighboring state machines sn produced by the algorithm is a correct implementation of the activity partition a. since this prove can be carried out for all partitions of the activity, we established that the algorithm transforms activities to state machines in a correct way. 7 related work to our best knowledge, the algorithm presented here is the first one that directly transforms uml 2.0 activity diagrams into the executable state machines described above. our work is related to that of eshuis on model checking of activity diagrams [11], in which activity diagrams are transformed into the input language of nusmv, a symbolic model verifier [16]. we could not adapt this algorithm for our work, since, as discussed in sect. 5, syntactical algorithms cause in our field of application a high number of considered unreachable states. to execute activity graphs, eshuis and wieringa [17] describe an algorithm for an event router to coordinate the behavior of components. aiming at workflow systems, their execution differs from ours as it assumes a centralized architecture and the activity is considered as a whole, rather than splitting up the activity into its partitions and creating distributed state machines as we do. there is a number of approaches that take scenario descriptions based on sequence diagrams (like mscs or uml sequence diagrams) to synthesize state machines [18, 19, 20, 21]. while the resulting state machines are similarly executable as the ones we described, the input of these synthesizers in form of sequence diagrams differs from activity diagrams. sequence diagrams often specify only a set of scenarios rather than a complete behavior, which may lead to behaviors that are not expressed explicitly. they focus on the interactions and identify signals. in contrast, activities focus on the operations and decisions that have to be performed by its participants, and our algorithm generates the necessary interactions in form of signal transmissions automatically. use case maps (ucm, [22]) offer a notation that is close to that of uml activities, as they also allow the specification of behavior in terms of causal paths that may involve several components. yong he et al. conducted an experiment [23] in which a specification expressed by use case maps was transformed into message sequence charts. these, in turn, were transformed into executable sdl specifications using the tool msc2sdl [18]. similar to that, castejón [24] outlines an algorithm that takes specifications in ucm and uml 2.0 collaborations to generate state machines from sequence diagram fragments contained in the collaborations. 13 / 15 volume 7 (2007) transforming collaborative service specifications into executable state machines 8 concluding remarks we described an algorithm that transforms uml 2.0 activities into a uml 2.0 state machines, from which we can easily generate efficiently executable code. the algorithm is implemented in java and integrated into our eclipse-based tool suite, so that we now have a complete automated development process from collaborative specifications based on activities to implementations on various platforms. as input and output we use models stored in the java uml 2.0 repository from the eclipse uml2 project. the algorithm does not construct an intermediate graph, but only uml model elements that are part of the desired output state machines, so that it is efficient with respect to the memory needed. the time for the transformation of the presented example is negligible; the state machines appear practically instantly. moreover, we expect the algorithm to scale well also for more complex systems, as the increased complexity of a system leads more to a higher number of partitions than to more complex ones causing only a linear increase. this work describes a step of a more comprehensive engineering approach for the creation of interactive services by correctness-preserving design steps. initially, a service specification is composed from various abstract collaborations that, to a large extent, can be obtained from domain-specific libraries. such abstract collaborations are often quite simple and can also be understood by customers, who are not experts in software technology but want to focus on their actual business. in succeeding steps, such abstract specifications are incrementally refined until the specification has a degree of detail that enables direct translation to software. due to the algorithm, we are now able to perform these refining design steps entirely in the collaborationoriented perspective. as pointed out in [4], for this purpose we can use the activities with their convenient properties as reusable building blocks. bibliography [1] floch, j., bræk, r.: towards dynamic composition of hybrid communication services. 6th int. conf. on intelligence in networks (smartnet), deventer, kluwer, (2000) [2] rößler, f., geppert, b., gotzhein, r.: collaboration-based design of sdl systems. 10th int. sdl forum on meeting uml, springer-verlag (2001) 72–89 [3] sanders, r.t., castejón, h.n., kraemer, f.a., bræk, r.: using uml 2.0 collaborations for compositional service specification. in: acm / ieee 8th int. conf. on model driven engineering languages and systems. (2005) [4] kraemer, f.a., herrmann, p.: service specification by composition of collaborations — an example. 2nd int. workshop on service composition (sercomp), hong kong (2006) [5] kraemer, f.a., herrmann, p., bræk, r.: aligning uml 2.0 state machines and temporal logic for the efficient execution of services. int. conf. on distributed objects and applications (doa), 2006, montpellier, lncs 4276, springer (2006) 1613–1632 [6] bræk, r., haugen, ø.: engineering real time systems: an object-oriented methodology using sdl. the bcs practitioner series. prentice hall (1993) proc. gt-vmt 2007 14 / 15 eceasst [7] broy, m., stølen, k.: specification and development of interactive systems: focus on streams, interfaces, and refinement. springer (2001) [8] object management group: unified modeling language: superstructure (2006) [9] kraemer, f.a.: rapid service development for service frame. master’s thesis, university of stuttgart (2003) [10] bræk, r.: unified system modelling and implementation. int. switching symposium, paris, france (1979) 1180–1187 [11] eshuis, r.: symbolic model checking of uml activity diagrams. acm transactions on software engineering and methodology 15(1) (2006) 1–38 [12] herrmann, p., krumm, h.: a framework for modeling transfer protocols. computer networks 34(2) (2000) 317–337 [13] lamport, l.: specifying systems. addison-wesley (2002) [14] graw, g., herrmann, p.: transformation and verification of executable uml models. electronic notes on theoretical computer science, elsevier science 101 (2004) 3–24 [15] abadi, m., lamport l.: the existence of refinement mappings. theoretical computer science 82 (2) (1991) 253–284 [16] cimatti, a., clarke, e.m., giunchiglia, e., giunchiglia, f., pistore, m., roveri, m., sebastiani, r., tacchella, a.: nusmv 2: an opensource tool for symbolic model checking. 14th int. conf. on computer aided verification (cav), lncs 2404, springer (2002) [17] eshuis, r., wieringa, r.: an execution algorithm for uml activity graphs. 4th int. conf. on the unified modeling language, modeling languages, concepts, and tools (uml), london, springer (2001) 47–61 [18] mansurov, n., zhukov, d.: automatic synthesis of sdl models in use case methodology. in dssouli, r., von bochmann, g., lahav, y., eds.: sdl forum, elsevier (1999) 225–240 [19] whittle, j., schumann, j.: generating statechart designs from scenarios. 22nd int. conf. on software engineering (icse), new york, acm press (2000) 314–323 [20] krüger, i., grosu, r., scholz, p., broy, m.: from mscs to statecharts (1999) [21] uchitel, s., kramer, j., magee, j.: synthesis of behavioral models from scenarios. ieee trans. softw. eng. 29(2) (2003) 99–115 [22] buhr, r.j.a., casselman, r.s.: use case maps for object-oriented systems. (1996) [23] he, y., amyot, d., williams, a.w.: synthesizing sdl from use case maps: an experiment. 11th sdl forum, stuttgart. lncs 2708, springer (2003) 117–136 [24] castejón, h.n.: synthesizing state-machine behaviour from uml collaborations and use case maps. 12th int. sdl forum, grimstad. lncs 3530, springer (2005) 15 / 15 volume 7 (2007) introduction collaborations and activities for service composition state machines for service execution transformation from activities to state machines the transformation algorithm correctness of the transformation related work concluding remarks a logical framework for trust-related emotions electronic communications of the easst volume 22 (2009) proceedings of the third international workshop on formal methods for interactive systems (fmis 2009) a logical framework for trust-related emotions jean-françois bonnefon, dominique longin and manh-hung nguyen 15 pages guest editors: michael harrison, mieke massink managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst a logical framework for trust-related emotions jean-françois bonnefon1, dominique longin2 and manh-hung nguyen3 1 bonnefon@univ-tlse2.fr university of toulouse, cnrs, clle, france 2 dominique.longin@irit.fr university of toulouse, cnrs, irit, france 3 manh-hung.nguyen@irit.fr university of toulouse, ups, irit, france abstract: emotion and trust are two important concerns for the elaboration of interaction systems that would be closer and more attractive to their users, in particular by endowing machines with the ability to predict, understand, and process emotions and trust. this paper attempts to construct a common logical framework for the representation of emotion and trust. this logical framework combines a logic of belief and choice, a logic of time, and a dynamic logic. using this common framework, we identify formal relations between trust and emotions, for which we also provide behavioral validation. keywords: modal logic, emotions, trust, distrust 1 introduction the rapidly growing field of affective computing aims at developing interaction systems that are closer and more attractive to their users, in particular by endowing machines with the ability to predict, understand, and process emotions (on the one hand), and trust (on the other hand). in this article, we introduce a unified logical approach to represent the cognitive structure of some emotions, of trust/distrust, and their relations at a formal level. we formalize the concepts of emotions as well as trust/distrust based on cognitive models proposed by cognitive psychologists. regarding emotions, we draw on cognitive theories (for more detail, see [ssj01]) which assume that emotions are closely tied to changes in beliefs and desires. we capitalize on psychological models that allow to recognize and distinguish emotions based on their decomposition in cognitive factors particularly the cognitive structure of emotion of ortony et al. [occ88], the cognitive patterns of emotion of lazarus [laz91] and the beliefdesire theory of emotion (bdte) [rei09, dre95]. similarly, we attempt to adhere closely to cognitive definition of trust [cf01] and distrust [cfl08]. although there are tight conceptual connections between emotion and trust [lah01], and although there ware some separated formalization of the concepts of trust as the works of herzig et al. [hlh+08], and the concepts of emotions such as the works of adam et al. [ahl09] and steunebrink et al. [sdm07b, sdm07a], there is not yet a common logic to represent them both. our work aims at filling that gap by formally representing trust and emotions in a common logic; 1 / 15 volume 22 (2009) mailto:bonnefon@univ-tlse2.fr mailto:dominique.longin@irit.fr mailto:manh-hung.nguyen@irit.fr a logical framework for trust-related emotions this common logic will enable us to lay bare the formal relations between trust and emotion. the logic we offer is a combination of the logic of beliefs and choices as the one of herzig and longin [hl04] (a refinement from cohen and levesque [cl90]), the logic of time (introduced by arthur prior [pri57]), and dynamic logic introduced by fischer and ladner [fl79] and harel et al. [hkt00]. this paper is organized as follows: part 2 introduces the logical framework. part 3 formalizes the cognitive structure of some emotions, part 4 formalizes the cognitive structure of trust and distrust. part 5 shows some formal relations in the effect of trust/distrust on the emotions, and provides behavioral validation for these relations. 2 logical framework syntax. the syntactic primitives of our logic are as follows: a nonempty finite set of agents agt = {i1, i2, . . . , in}, a nonempty finite set of atomic events evt = {e1, e2, . . . , ep}, and a nonempty set of atomic propositions atm = {p1, p2, . . .}. the variables i, j, k. . . denote agents. the expression i1:e1 ∈ agt × evt denotes an event e1 intentionally caused by agent i1 and e1 is thus called an “action”. the variables α , β . . . denote such actions. the language of our logic is defined by the following bnf : ϕ :=p | i:α -happens | ¬ϕ | ϕ ∨ ϕ | xϕ | x−1ϕ | gϕ | beli ϕ | choicei ϕ | grdi ϕ where p ranges over atm, i:α ranges over agt × evt , i:α -happens ranges over atm for each i:α ∈ agt ×evt , and i ⊆ agt . the classical boolean connectives ∧ (conjunction), → (material implication), ↔ (material equivalence), > (tautology) and ⊥ (contradiction) are defined from ¬ (negation) and ∨ (disjunction). i:α -happens reads “agent i is just about to perform the action α ”; xϕ reads “ϕ will be true next instant”; x−1ϕ reads “ϕ was true at the previous instant”; gϕ reads “henceforth, ϕ is true”; beli ϕ reads “agent i believes that ϕ is true”; choicei ϕ reads “agent i prefers that ϕ be true”; grdi ϕ reads “ϕ is publicly grounded between the agents in group i” (it is nothing else than a standard common belief operator). we define the following abbreviations: i:α -done def = x−1i:α -happens (defi:α -done) happensi:α ϕ def = i:α -happens ∧xϕ (defhappensi:α ) afteri:α ϕ def = i:α -happens → xϕ (defafteri:α ) donei:α ϕ def = i:α -done ∧x−1ϕ (defdonei:α ) proc. fmis 2009 2 / 15 eceasst fϕ def = ¬g¬ϕ (deff) goali ϕ def = choicei fbeli ϕ (defgoali ) intendi α def = choicei fi:α -happens (defintendi ) capableiα def = ¬afteri:α⊥ (defcapablei ) possibleiϕ def = ¬beli ¬ϕ (defpossiblei ) awarenessiϕ def = x−1¬beli ϕ ∧beli ϕ (defawarenessi ) i:α -done reads “agent i has done action α ”; happensi:α ϕ reads “agent i is doing action α and ϕ will be true next instant”; afteri:α ϕ reads “ϕ is true after any execution of α by i”; donei:α ϕ reads “agent i has done action α and ϕ was true at previous instant”; fϕ reads “ϕ will be true in some future instants”; goali ϕ reads “agent i has the goal (chosen preference) that ϕ be true”; intendi α reads “agent i intends to do α ”; capableiα reads “agent i is capable to do α ”; possibleiϕ reads “agent i believes that it is possible ϕ ”; awarenessiϕ reads “agent i has just experienced that ϕ is true”. semantics. for temporal operators, we use a semantics based on linear time described by a sequence (or story) of time points. (this semantics is very close to ctl* [ces86]) a frame f is a 4-tuples 〈h, b, c , g 〉 where: h is a set of stories that are represented as sequences of time points, where each time point is identified by an integer z ∈ z, a time point z in a story h is called a situation < h, z >; b is the set of all bi such that bi(h, z) denotes the set of stories believed as being possible by the agent i in the situation < h, z >; c is the set of all ci such that ci(h, z) denotes the set of stories chosen by the agent i in the situation < h, z >; g is the set of all gi such that gi (h, z) denotes the set of stories which are publicly grounded in the group i of agents, in the situation < h, z >. all the accessibility relations bi are serial1, transitive2 and euclidean3. this semantic is completely standard in epistemic logic (see [hin62, gg06]) all the accessibility relations gi are serial, transitive and euclidean (this is similar to the operator group grounding introduced by gaudou et al. [ghl06]). all the accessibility ci are serial. moreover, we impose for every z ∈ z that: if h′ ∈ bi(h, z) then ci(h, z) = ci(h′, z). it means that if an agent believes that the world h’ is possible from the world h, then the set of his/her preference worlds from h and h’ are the same. in other terms, the worlds an agent prefers and the ones that agent believes that s/he prefers are the same (briefly, the agent is conscious about his/her preferences, and s/he prefers what s/he believes that s/he prefers). a model m is a couple 〈f , v 〉 where f is a frame and v is a function associating each atomic proposition p with the set v (p) of couple (h, z) where p is true. truth conditions are 1 for every w1 ∈ m , there is w2 such that w1biw2 2 if w1biw2 and w2biw3, then w1biw3 3 if w1biw2 and w1biw3, then w2biw3 3 / 15 volume 22 (2009) a logical framework for trust-related emotions defined as follows: m , h, z |= p iff (h, z) ∈ v (p) m , h, z |= xϕ iff m , h, z + 1 |= ϕ m , h, z |= x−1ϕ iff m , h, z − 1 |= ϕ m , h, z |= gϕ iff m , h, z′ |= ϕ for every z′ ≥ z m , h, z |= beli ϕ iff m , h′, z |= ϕ for every (h′, z) ∈ bi(h, z) m , h, z |= choicei ϕ iff m , h′, z |= ϕ for every (h′, z) ∈ ci(h, z) m , h, z |= grdi ϕ iff m , h′, z |= ϕ for every (h′, z) ∈ gi (h, z) other truth conditions are defined as usual. axiomatics. due to our linear time semantics, the temporal operators satisfy the following principles: i:α -happens ↔xi:α -done (1) xϕ ↔¬x¬ϕ (2) ϕ ↔xx−1ϕ (3) ϕ ↔x−1xϕ (4) gϕ ↔ϕ ∧xgϕ (5) g(ϕ → xϕ) →(ϕ → gϕ) (6) beli and choicei operators are defined in a normal modal logic plus (d) axioms. thus, if � represents a beli operator or choicei operator: ϕ �ϕ (rn�) �(ϕ → ψ) →(�ϕ → �ψ) (k�) �ϕ →¬�¬ϕ (d�) for example, axiom d� applied to operator beli is dbeli , which is described as: beli ϕ → ¬beli ¬ϕ . (rn�) means that all theorems are believed (respectively: chosen) by every agent i; (k�) means that beliefs (respectively: choices) are closed under material implication for every agent i; (d�) means that beliefs (respectively: choices) of every agent i are rational: they cannot be contradictory. the beli operators satisfy the following principles of introspection: beli ϕ ↔beli beli ϕ (4beli ) ¬beli ϕ ↔beli ¬beli ϕ (5beli ) that means that agent i is conscious of its beliefs and of its disbeliefs. the following principle follows from the semantical constraint between belief accessibility relation and choice accessibility relation, and from axiom (d�) for beli : proc. fmis 2009 4 / 15 eceasst choicei ϕ ↔beli choicei ϕ (4bc) ¬choicei ϕ ↔beli ¬choicei ϕ (5bc) that means that agent i is conscious of its choices and of its dischoices. the sound and complete axiomatization of grdi operator is defined as the one of common belief operator (also called mutual belief), which is closed to the operator described in walton and krabbe [wk95], also introduced by gaudou et al. [ghl06]: ϕ grdi ϕ (rngrdi ) grdi (ϕ → ψ) →(grdi ϕ → grdi ψ) (kgrdi ) grdi ϕ →¬grdi¬ϕ (dgrdi ) grdi ϕ →grdigrdi ϕ (4grdi ) ¬grdi ϕ →grdi¬grdi ϕ (5grdi ) axiom (rngrdi ) means that every tautology is public ground. axiom (kgrdi ) means that if ϕ is publicly grounded in i and that ϕ implies ψ then ψ is also publicly grounded in i. axiom (dgrdi ) means that the set of grounded informations is consistent: it can not be the case that both ϕ and ¬ϕ are simultaneously grounded. the positive introspection axiom (4grdi ) and negative introspection axiom (5grdi ) account for the public character of grdi . from these collective awareness results: if ϕ has (resp. has not) been grounded then it is established that ϕ has (resp. has not) been grounded. linear time semantics entail the following principles: gϕ →afteri:α ϕ (7) happensi:α ϕ →after j:β ϕ (8) afteri:α ϕ ↔¬happensi:α¬ϕ (9) axiom (7) describe the relationship between time and action: if henceforth ϕ is true then after every action α of every agent i, ϕ will be true. (note that the converse is not valid: it is possible that ϕ be true after every action α of every agent i performed in a situation < h, z >, and that ϕ be false at time z′ > z.) as time is linear, actions are deterministic on a given history. thus, axiom (8) reads: if agent i is just about to perform α after what ϕ will be true, then after every performance of every action β by every agent j, ϕ will be true. in other words, if action α leads to a time point where ϕ is true, then every action performed by every agent leads to this time point. finally, axiom (9) means that afteri:α and happensi:α operators are dual operators. this property is fair with respect to dynamic logic [hkt00]. 3 formalization of the cognitive structure of emotion in this section, we present the formalization of emotions, based on their cognitive structure as proposed by ortony et al. [occ88], frijda [fri86] as well as those of reisenzei [rei09] and scherer et al. [sch01]. 5 / 15 volume 22 (2009) a logical framework for trust-related emotions joy/distress. the cognitive structure of joy consists of two main factors: (i) a proposition ϕ is desirable for agent i, and (ii) agent i just experienced that ϕ is the case. to formalize the first factor, we consider that agent i desiring ϕ means that i wants ϕ to be the case. so we formalize desire as a goal (chosen preference). therefore, the first factor is potentially formalized as goali ϕ , the second factor may be formalized as beli ϕ . however, we assume that emotion is triggered at the moment when all its factors are fulfilled, and that its intensity then decreases with time [ds01, fri86]. accordingly, we include a time factor into most emotional formulas. thus, the first factor of joy in particular means that agent i now recalls that at the previous instant, s/he desired ϕ , until experiencing that ϕ was in fact true: beli x−1goali ϕ . it means that in order to be joyful, agent i must keep in mind his desire in the previous instant. hereafter, we add this analysis for almost emotional formulas. the second factor means that agent i has just experienced that ϕ is true and did not previously know it: awarenessiϕ . the same analysis applies to distress, except that in the first factor of distress, ϕ is undesirable for agent i, which we assume to mean that agent i desired ¬ϕ : beli x−1goali ¬ϕ . we accordingly formalize the concept of joy and distress: definition 1 (joy/distress) joyi ϕ def =beli x −1goali ϕ ∧awarenessiϕ distressi ϕ def =beli x −1goali ¬ϕ ∧awarenessiϕ to illustrate the definition of joy, we can say that an individual is joyful when he has just realized that he won the lottery (awarenessman(win lottery)) with the trivial assumption that he had been desiring to win the lottery (belman x−1goalman (win lottery)). in contrast, to illustrate the definition of distress, we can say that an individual feels distress when she learns she has lost her job (awarenesswoman(lost job)) assuming that she had the goal not to lose her job (belwoman x−1goalwoman ¬(lost job)). hope/fear. the cognitive structure of hope consists of two factors: (i) a proposition ϕ is desirable for agent i, and (ii) agent i believes that ϕ may be true in the future. to formalize the first factor, we consider that ϕ is not true at the moment when i hopes for it: goali ϕ . we interpret the second factor, as meaning that among all of possible future worlds, agent i believes that there is at least one world in which ϕ will be the case. in other terms, agent i does not believe that ϕ will be false in all of possible future worlds: possibleifϕ . if i believes that ϕ can never be the case in all of possible future worlds, then i has no ground for hope. the same analysis applies to fear, except that ϕ is now undesirable for agent i: goali ¬ϕ . we accordingly formalize the concept of hope and fear: definition 2 (hope/fear) hopei ϕ def =goali ϕ ∧possibleifϕ feari ϕ def =goali ¬ϕ ∧possibleifϕ proc. fmis 2009 6 / 15 eceasst for example, a debutante is hopeful about being asked to dance, for she thinks it is possible (possiblegirlf(being asked to dance)) and this is what she wants (goalgirl (being asked to dance)). in contrast, an employee fears to be fired when he does not wish to be fired (goalemployee ¬( f ired)) but believes it is a possibility possibleemployeef(to be fired)). satisfaction/disappointment. the cognitive structure of satisfaction consists of three factors: (i) agent i desired a proposition ϕ , (ii) agent i used to believe that ϕ might be true in the near future, and (iii) agent i now experiences that ϕ is really the case. the first two factors mean that now, agent keeps in mind that at the previous instant, s/he desired ϕ and believed that ϕ could be true in the future (beli x−1(goali ϕ ∧possibleifϕ)) (cf. the analysis of the second factor of hope). the last factor means that i now experiences that ϕ is true, but did not know it the previous instant (awarenessiϕ ). the difference in the case of disappointment is agent recalls that, in the previous instant, s/he desired ¬ϕ instead of ϕ , and s/he believed that ¬ϕ was possibly true in the future (beli x−1(goali ¬ϕ ∧possibleif¬ϕ)). we formalize satisfaction and disappointment as definition 3 (satisfaction/disappointment) satisfactioni ϕ def =beli x −1(goali ϕ ∧possibleifϕ)∧awarenessiϕ disappointmenti ϕ def =beli x −1(goali ¬ϕ ∧possibleif¬ϕ)∧awarenessiϕ for example, when the debutante realizes that she is indeed asked to dance (awarenessgirl (asked to dance)) she is satisfied. were she not to be asked to dance (awarenessgirl (not asked to dance)), she would feel disappointed. we can point out the relations between satisfaction, disappointment and hope: satisfactioni ϕ ↔beli x−1hopei ϕ ∧awarenessiϕ (10) disappointmenti ϕ ↔beli x −1hopei ¬ϕ ∧awarenessiϕ (11) the relation between satisfaction and joy can be formalized as proposition 1: if we feel satisfaction about something, then we will also feel joy about it. proposition 1 (satisfaction implies joy) satisfactioni ϕ →joyi ϕ fear-confirmed/relief. the cognitive structure of fear-confirmed consists of three factors: (i) a proposition ϕ was undesirable for agent i, (ii) agent i believed that ϕ might be true in the near future, and (iii) agent i now experiences that ϕ is really true. we use the same analysis as for satisfaction, except agent recalls that in the previous instant, ¬ϕ was desirable for agent i (beli x−1goali ¬ϕ ). the difference in the case of relief is agent recalls that, in the previous instant, s/he desired ϕ (beli x−1goali ϕ ), and believed that ¬ϕ might be true in the near future (beli x−1(goali ϕ ∧ possibleif¬ϕ)). we formalize fear-confirmed and relief as: 7 / 15 volume 22 (2009) a logical framework for trust-related emotions definition 4 (fear-confirmed/relief) fearconfirmedi ϕ def =beli x −1(goali ¬ϕ ∧possibleifϕ)∧awarenessiϕ reliefi ϕ def =beli x −1(goali ϕ ∧possibleif¬ϕ)∧awarenessiϕ for example, the employee’s fear of being fired is confirmed when he learns that he is indeed about to be fired (awarenessemployee( f ired)) which he had been afraid of (belemployee x−1(goalemployee ¬( f ired) ∧ possibleemployeef( f ired))). in contrast, were he to learn that he is not going to be fired (awarenessemployee(not fired)), he would feel relief. we can also point out the relations between fear-confirmed, relief and fear: fearconfirmedi ϕ ↔beli x−1feari ϕ ∧awarenessiϕ (12) reliefi ϕ ↔beli x−1feari ¬ϕ ∧awarenessiϕ (13) the relation between fear-confirmed and distress is stated in proposition 2: if our fears about something are confirmed, then we feel distressed. proposition 2 (fear-confirmed implies distress) fearconfirmedi ϕ → distressi ϕ 4 formalization of trust we now present the formalization of trust and distrust based on the cognitive definition of castelfranchi and colleagues [cf01, cfl08]. trust. we formalize the concept of trust based on castelfranchi and falcone’s definition [cf01] of trust in action which says that agent i trusts agent j to ensure ϕ by performing action α if and only if agent i desires to achieve ϕ (goali ϕ ), and agent i expects that: (i) ϕ can be achieved by doing action α (beli after j:α ϕ ); (ii) agent j is able to perform action α (beli capable jα ); and (iii) agent j has the intention to do such an action (beli intend j α ). however, these three factors are only necessary conditions, but not sufficient ones. for example, imagine that a robber wants to steal something located on the second floor of a mansion. there is a nurse on the first floor. the robber desires that the nurse stays where she is, because it makes his robbery possible. he also believes that it is possible that the nurse will stay where she is, and that it is actually her intention. thus, the three conditions are satisfied, but we are reluctant nonetheless to say that the robber trusts the nurse to stay where she is in order to allow for his stealing, because there is no agreement between the nurse (trustee) and the robber (trustor). so here we need to add another condition for trust: an agreement between trustor and trustee that the trustee will perform such an action (grditrustee : α -happens), where i = {trustor,trustee}. we accordingly formalize the concept of trust as: proc. fmis 2009 8 / 15 eceasst definition 5 (trust) trusti, j(α, ϕ) def =goali ϕ ∧beli after j:α ϕ ∧beli capable jα∧ beli intend j α ∧grd{i, j} j:α -happens for example, a boss trusts his secretary to prepare a report in order to present it at a company meeting because the boss desires the report (goalboss (report)), and in his opinion, the report can be possibly ready after the secretary prepares it (belboss a f tersecretary:prepare(report)), the secretary has the ability and intention to prepare the report (belboss capablesecretary(prepare)∧ belboss intendsecretary (prepare))). it is clear that in the relation between the boss and his secretary, there is an agreement that the secretary will prepare the report in time (grdboss,secretarysecretary : prepare-happens). distrust. we also adopt the definition of distrust given by castelfranchi et al. [cfl08] which says that agent i distrusts agent j to ensure ϕ by performing action α if and only if agent i desires to achieve ϕ (goali ϕ ), and agent i believes that at least one of these conditions is fulfilled: (i) agent j is not in the capacity to do action α : beli ¬after j:α ϕ , or (ii) agent j is able to do α but he has not intention to do α : possibleiafter j:α ϕ ∧beli ¬intend j α . we accordingly formalize this concept as: definition 6 (distrust) distrusti, j(α, ϕ) def = goali ϕ ∧(beli ¬after j:α ϕ∨ (possibleiafter j:α ϕ ∧beli ¬intend j α)) for example, in spite of desiring the report (goalboss (report)), the boss does not trust a new employee to prepare it because he believes the new employee is unable to perform that task(belboss ¬afteremployee:prepare(report)). from this definition, we can decompose the concept of distrust based only on the ability of trustee: definition 7 (distrust based on ability) c-distrusti, j(α, ϕ) def =goali ϕ ∧beli ¬after j:α ϕ 5 trust-related emotions 5.1 formal relations trust and hope. trust and hope have an important relation because they both feature a positive expectation [cf01]. when i trusts j, i has a positive expectation about j’s power and performance. hope also implies some positive expectation. the greater the expectations, the deeper the trust; and, conversely, the deeper the disappointment when expectations are unrealized [bry07]. we formalize the former relation as proposition 3, the latter as proposition 5. 9 / 15 volume 22 (2009) a logical framework for trust-related emotions proposition 3 (trust implies hope) trusti, j(α, ϕ) →hopeiϕ this means that when we trust someone about an action that will bring some results, we are hopeful that the results will be obtained. for example, in a commercial transaction, when the buyer trusts his seller to send him a product after payment (trustbuyer,seller(send, receipt)), he will be hopeful that he will receive the product (hopebuyer receive product). this proposition will be proved by applying lemma 1: if we believe that ϕ is true after every execution of action α , and that someone is able to do α , then we believe that there is at least a future world in which ϕ is true. lemma 1 beli after j:α ϕ ∧beli capable jα →possibleifϕ once we trust someone to do an action to bring us something, we hope for the positive result of the action. in case of success, we feel satisfaction (formalized as proposition 4). conversely, in case of failure, we feel disappointment (formalized as proposition 5). proposition 4 (successful trust implies satisfaction) beli done j:α trusti, j(α, ϕ)∧awarenessiϕ →satisfactioniϕ this means that when we believe that what we trusted has now occurred, we are satisfied about it. for example, when the boss trusted his secretary to prepare the report (donesecretary: preparetrustboss,secretary(prepare, having report)), and on the morning of the day after, he has received the report (belboss having report), then he is satisfied (satisfactionbosshaving report). this proposition has a corollary which is deduced from proposition 1 and 4: when we experience that what we trusted has really occurred, we will also feel joy about it. corollary 1 beli done j:α trusti, j(α, ϕ)∧awarenessiϕ →joyiϕ proposition 5 (unsuccessful trust implies disappointment) beli done j:α trusti, j(α, ϕ)∧awarenessi¬ϕ →disappointmenti¬ϕ this means that we feel disappointed if what we trusted does not in fact occur. for example, a businessman trusted his partner to arrive on time to negotiate a contract. the businessman feels disappointed if the partner has not yet arrived at the scheduled time. distrust and fear. distrust features a negative expectation, involving fear of the other [lw00, aacs08]. we state the relation between distrust based on ability and fear as proposition 6. proc. fmis 2009 10 / 15 eceasst proposition 6 (distrust implies fear) c-distrusti, j(α, ϕ) →feari¬ϕ this means that if we distrust someone to do an action to bring us something then we fear that our desire might not be fulfilled. for example, the boss might distrust his assistant with the preparation of a report he needs, and more specifically distrusts him to finish the report by the next morning (distrustboss,assistant ( f inish, report)). therefore, he is fearful that he might miss the report the next morning (fearboss¬report). this proposition will be proved by applying lemma 2: if we believe that someone is unable to do an action to bring about something, then we believe that there is at least a future world without the expected result of this action. lemma 2 beli ¬after j:α ϕ →possibleif¬ϕ once we distrust someone to do an action to bring about something, we experience fear. if the results are indeed negative, we feel fear-confirmed (formalized as proposition 7). if, however the action is in fact successfully performed, we feel relief (formalized as proposition 8). proposition 7 (confirmation of distrust implies fear-confirmed) beli done j:α c-distrusti, j(α, ϕ)∧awarenessi¬ϕ →fearconfirmedi¬ϕ if the boss realizes that his assistant really did not finish the report (belboss ¬report), he feels fear-confirmed (fearconfirmedboss¬report). combining the two propositions 2 and 7, we arrive at a corollary: when we experience that what we distrusted has now happened, we feel distressed about it. corollary 2 beli done j:α c-distrusti, j(α, ϕ)∧awarenessi¬ϕ →distressi¬ϕ proposition 8 (non-confirmation of distrust implies relief) beli done j:α c-distrusti, j(α, ϕ)∧awarenessiϕ →reliefiϕ if the boss discovers that his assistant did in fact finish the report (belboss report), he feels relieved (reliefbossreport). 5.2 behavioral validation although the propositions that we proved in the previous section are intuitively plausible, some of them have not yet received behavioral validation from the field of experimental psychology. we decided to collect empirical data concerning three propositions in this article, related to the emotions that follow trust when it is confirmed (proposition 4), and when it is unconfirmed (proposition 5); and the emotions that follow distrust, when it is unconfirmed (proposition 8) 4. 4 we could not test proposition 7 for a linguistic reason: neither in french nor in vietnamese (the two languages used in our experiment) could we find an everyday term equivalent to ‘fear confirmed’. 11 / 15 volume 22 (2009) a logical framework for trust-related emotions satisfaction relief disappointment trust distrust trust distrust trust distrust success 4.9 (1.5) 4.6 (1.6) 2.8 (1.9) 3.6 (1.9) 1.1 (0.6) 1.3 (0.8) failure 1.1 (0.5) 1.4 (1.0) 1.3 (1.0) 1.3 (0.9) 4.6 (1.7) 3.2 (1.4) table 1: mean and standard deviations of affective ratings, as a function of trust and outcome. following the analysis in (section 4) which argues that trust is the conjunction of the intention, the capacity, and the agreement of trustee, the presence of agreement is intentionally fixed for the future test. we therefore operationalize trust as the conjunction of intention and capacity, and distrust as the three remaining cases. participants to the survey read 8 different stories, following a 2×2×2 within-subject design. the variables manipulated in the stories were intention (yes/no), capacity (yes/no), and outcome (success/failure). as an example, here is the story corresponding to intention = yes, capacity = yes, and outcome = success. mr. boss is the marketing director of a big company. he needs an important financial report before a meeting tomorrow morning, but he has no time to write it because of other priorities. he asks mr. support to prepare it and put it on his desk before tomorrow morning. • mr. boss believes that mr. support has the intention to prepare the report in time. • mr. boss believes that mr. support is able to prepare the report in time. the morning after, mr. boss finds the report on his desk when he arrives. in your opinion, what does he feel? in the condition intention = no, “mr. boss believes that mr. support has the intention to prepare the report in time” was replaced with “mr. boss believes that mr. support has no intention to prepare the report in time.” in the condition capacity = no, “mr. boss believes that mr. support is able to prepare the report in time” was replaced with “mr. boss believes that mr. support is unable to prepare the report in time.” finally, in the condition outcome = failure, “mr. boss finds the report on his desk when he arrives” was replaced with “mr. boss does not find the report on his desk when he arrives.” after reading each story, participants rated the extent to which the main character would feel each of 7 emotions, which included our target emotions, satisfaction, disappointment, and relief; but also some emotions that we included for exploratory purposes, such as anger or thankfulness. ratings used a 6-point scale anchored at not at all and totally. a total of 100 participants took part in an online survey. the survey was offered in two languages, french (30% of the final sample) and vietnamese (70%). language was entered as a control variable in all statistical analyses, but added only a small overall main effect on participants’ responses, and will not be discussed any further. descriptive statistics are displayed in table 1. participants’ responses were analyzed by means of a repeated-measure analysis of variance, aimed at detecting statistically reliable effects of trust and outcome on our emotions of interest. satisfaction. unsurprisingly, the analysis of variance detected a huge effect of outcome, f(1, 98) = 597, p < .001, accounting for most of the observed variance, η 2p = .86. in other terms, proc. fmis 2009 12 / 15 eceasst satisfaction is almost perfectly predicted by outcome alone. the analysis, however, also detects a comparatively small interaction effect outcome × trust, f(1, 98) = 8.8, p < .01, η 2p = .08, reflecting the fact that success is even more pleasant in case of trust. table 1 shows that the biggest score of satisfaction is in the case of trust follows a success: m = 4.9, sd < 1.5. the data are in line with what was expected from proposition 4. relief. the analysis detected main effects of trust, f(1, 98) = 19.1, p < .001, η 2p = .23; and outcome, f(1, 98) = 127, p < .001, η 2p = .80. however, these main effects were qualified by an interaction effect trust × outcome, f(1, 98) = 12.3, p < .001, η 2p = .31. table 1 shows that the score of relief is especially high in the case of success is obtained despite of distrust: m = 3.6, sd < 1.9. this interaction reflects our expectation (proposition 8). disappointment. the analysis detected main effects of trust, f(1, 98) = 28.4, p < .001, η 2 p = .16; and outcome, f(1, 98) = 389, p < .001, η 2 p = .56. however, these main effects were qualified by an interaction effect trust × outcome, f(1, 98) = 44.7, p < .001, η 2p = .11. table 1 shows that the score of disappointment is especially high in the case of failure is obtained despite of trust: m = 4.6, sd < 1.7. this interaction reflects our expectation (proposition 5). 6 conclusion this paper introduced a logical framework that can represent the cognitive structure of emotions, trust, and the formal relations between them. in other terms, it enables to represent the effect of trust (and distrust) on emotions. furthermore, this logical framework respects the instantaneity of emotions that previous logics of emotions did not fulfill. finally, the formal relations between emotion and trust laid bare by the logical framework were subjected to a behavioral validation following the methods of experimental psychology. the success of this behavioral validation gives strong support to our approach, which is shown to capture lay users’ intuitions about trustrelated emotion. although we have added time factor into almost emotional formulas, which enables to eliminate rightly emotion when the relevant event has passed a long time, but it have not yet helped us to represent the nature of continuous intensity of emotions. additionally, this paper has formalized only the effect of trust/distrust on emotions but not yet the effect of emotions on trust/distrust. these current limitations are also the potential perspective for our future research. acknowledgements: this work has been supported by the agence nationale de la recherche (anr), contract no. anr-08-cord-005-1, and by a doctoral scholarship awarded by the university of toulouse, contract no. 26977-2007. bibliography [aacs08] p. aghion, y. algan, p. cahuc, a. shleifer. regulation and distrust. sus.div– cepr–pseconference of models of cultural dynamics and diversity, 2008. 13 / 15 volume 22 (2009) a logical framework for trust-related emotions [ahl09] c. adam, a. herzig, d. longin. a logical formalization of the occ theory of emotions. synthese 168(2):201–248, 2009. [bry07] h. j. bryce. formalizing civic engagement: ngos and the concepts of trust, structure, and order in the public policy process. workshop on building trust through civic engagement and for the international political science association, section on governance, conference on government crisis in comparative perspective, seoul, korea, 2007. [ces86] e. m. clarke, e. a. emerson, a. p. sistla. automatic verification of finite-state concurrent systems using temporal logic specifications. acm transactions on programming languages and systems 8(2):244–263, 1986. [cf01] c. castelfranchi, r. falcone. social trust: a cognitive approach. in castelfranchi and tan (eds.), trust and deception in virtual societies. pp. 55–90. kluwer academic publishers, dordrecht, 2001. [cfl08] c. castelfranchi, r. falcone, e. lorini. a non-reductionist approach to trust. in goldbeck (ed.), computing with social trust. pp. 45–72. springer, berlin, 2008. [cl90] p. r. cohen, h. j. levesque. intention is choice with commitment. artificial intelligence 42:213–261, 1990. [dre95] f. dretske. naturalizing the mind. mit press, cambridge, 1995. [fl79] m. fischer, r. ladner. propositional dynamic logic of regular programs. journal of computer and system sciences 18(2):194–211, 1979. [fri86] n. h. frijda. the emotions: studies in emotion & social interaction. edition de la maison des sciences de l’homme. cambridge university press, paris, 1986. [gg06] p. gochet, p. gribomont. epistemic logic. in gabbay and woods (eds.), twentieth century modalities. handbook of the history of logic 7, pp. 99–195. elsevier, amsterdam edition, 2006. [ghl06] b. gaudou, a. herzig, d. longin. a logical framework for grounding-based dialogue analysis. in hoek et al. (eds.), international workshop on logic and communication in multi-agent systems (lcmas), edinburgh, scotland, uk, 01/08/2005. electronic notes in theoretical computer science (entcs) 157(4), pp. 117–137. elsevier, http://www.elsevier.com/, 2006. [hin62] j. hintikka. knowledge and belief: an introduction to the logic of the two notions. cornell university press, ithaca, 1962. [hkt00] d. harel, d. kozen, j. tiuryn. dynamic logic. mit press, 2000. [hl04] a. herzig, d. longin. c&l intention revisited. in proceedings of int. conf. of knowledge representation and reasoning kr’04. pp. 527–535. morgan kaufmann, 2004. proc. fmis 2009 14 / 15 eceasst [hlh+08] a. herzig, e. lorini, j. f. hübner, j. ben-naim, o. boissier, c. castelfranchi, r. demolombe, d. longin, l. perrussel, l. vercouter. prolegomena for a logic of trust and reputation. in proceedings of 3rd international workshop on normative multiagent systems (normas). luxembourg, july 2008. [lah01] b. lahno. on the emotional character of trust. journal of ethical theory and moral practice 4:171–189, 2001. [laz91] r. s. lazarus. emotion & adaptation. oxford university press, 1991. [lw00] r. lewicki, c. wiethoff. trust, trust development, and trust repair. in deutsch and coleman (eds.), the handbook of conflict resolution: theory and practice. pp. 86–107. jossey-bass, san francisco, ca, 2000. [occ88] a. ortony, g. l. clore, a. collins. the congnitive structure of emotions. the cambridge university press, 1988. [pri57] a. n. prior. time and modality. clarendon press, oxford, 1957. [rei09] r. reisenzein. emotions as metarepresentational states of mind: naturalizing the belief-desire theory of emotion. cognitive systems research 10(1):6–20, 2009. [sch01] k. r. scherer. appraisal processes in emotion : theory, methods, research. chapter appraisal considered as a process of multilevel sequential checking, pp. 92– 120. oxford university press, new york, 2001. [sdm07a] b. r. steunebrink, m. dastani, j.-j. c. meyer. a logic of emotions for intelligent agents. in proceedings of the twenty-second aaai conference on artificial intelligence, july 22-26, 2007, vancouver, british columbia, canada. pp. 142–147. aaai press, 2007. [sdm07b] b. r. steunebrink, m. dastani, j.-j. c. meyer. towards a quantitative model of emotions for intelligent agents. in reichardt and levi (eds.), proceedings of the 2nd workshop on emotion and computing current research and future impact. osnabrück, germany, 2007. [ds01] r. de sousa. the rationality of emotion. mit press, 6 edition, 2001. [ssj01] k. r. scherer, a. schorr, t. johnstone. appraisal processes in emotion: theory, methode, research. series in affective science. oxford university press, 2001. [wk95] d. n. walton, e. c. krabbe. commitment in dialogue: basic concepts of interpersonal reasoning. state university of new-york press, ny, 1995. 15 / 15 volume 22 (2009) introduction logical framework formalization of the cognitive structure of emotion formalization of trust trust-related emotions formal relations behavioral validation conclusion graph modelling and transformation: theory meets practice electronic communications of the easst volume 30 (2010) international colloquium on graph and model transformation on the occasion of the 65th birthday of hartmut ehrig (gramot 2010) graph modelling and transformation: theory meets practice karsten ehrig and claudia ermel 21 pages guest editors: claudia ermel, hartmut ehrig, fernando orejas, gabriele taentzer managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst graph modelling and transformation: theory meets practice karsten ehrig1 and claudia ermel2 1 bam bundesanstalt für materialforschung und -prüfung, berlin, germany karsten.ehrig@bam.de 2 institut für softwaretechnik und theoretische informatik technische universität berlin, germany claudia.ermel@tu-berlin.de abstract: in this paper, we focus on the role of graphs and graph transformation for four practical application areas from software system development. we present the typical problems in these areas and investigate how the respective systems are modelled by graphs and graph transformation. in particular, we are interested in the usefulness of theoretical graph transformation results and graph transformation tools in order to solve these problems. finally, we characterize concepts and tool features which are still missing in practice to solve the presented and related problems even better. keywords: graph modelling, graph transformation, graph transformation tools 1 introduction graphs are one of the key concepts for modelling. since the early days of mankind, graphs are used to depict the relationship between two or more entities as abstractions of real world systems and processes. the visual nature of graphs makes them an intuitive language for human beings to think and discuss about partitioning systems into different components, and about processes of running systems which can be drawn as related but changing system state graphs. throughout the history of software engineering, graph models have been used for software system design, such as entity-relationship diagrams for databases, class diagrams for static software structure, and the diagram types offered by the unified modeling language (uml) [omg07] to model different static and dynamic system aspects. yet, when it came to programming, often enough a yawning gap opened between what the modellers meant when designing their graph models and what the programmers encoded using standard textual programming languages, where the graph models played the role of a rough guideline for programmers. ambitious programming projects resulted in failure, went over their budgets or proved to be unstable over time. hence, the objective of model-driven development (mdd) is creating models closer to domain concepts rather than computing concepts [béz05]. this means that for software developers the abstraction level is now raised. no longer do they need to worry about technical details and features of programming languages but can concentrate on more creative parts of software engineering: analysis, design and validation, all based on models. sometimes, models are refined to a certain level of detail, and the code is written by hand in a separate step. sometimes, code can be generated from models, ranging from system skeletons to complete, deployable products. 1 / 21 volume 30 (2010) mailto:karsten.ehrig@bam.de mailto:claudia.ermel@tu-berlin.de graph modelling and transformation: theory meets practice in all cases, the mdd perspective raises the importance of graph models and calls for rigorous methods to capture the semantics of graph models and their evolution over time [eng00]. the fundamental notions behind graph models have been captured long ago by mathematical terms, thus allowing for rigorous reasoning at model level. yet, experience shows that many problems in using formal methods in software development arise because the formal model and the problem domain are too far apart. since any software system is situated in a particular social context, this context (domain) should be represented also in models based on formal notations. here, again, graph models with their visual nature are a good candidate for uniting the domain-specific and the formal aspects of real-world problems. domain specific languages based on graphs may use a graphical concrete syntax with adequate intuitive symbols which are manipulated adequately to model dynamic system aspects. thus, the system behaviour may be animated in a domain-specific visualization to validate system properties by domain experts. since real world systems evolve, their models need to model evolution as well. algebraic graph transformation is a formally defined calculus based on graphs and graph transformation rules [eept06]. for ages, rules have proven to be extremely useful for describing computations by local transformations. areas like language definition, logic, functional programming, algebraic specification, term rewriting and expert systems have rules as key concepts. graph transformation, also known as graph rewriting or graph reduction, combines the potential and advantages of both graphs and rules into a single computational paradigm. in this paper, we summarize a few selected case studies from recent literature which have been modelled by graphs and algebraic graph transformation (reviewed in section 2). in particular, we focus on four case studies from different application areas: a medical information system (section 3), a model transformation between two different modelling notations (section 4), a metabolic pathway analysis (section 5), and a self-healing system (section 6). for each application area, we ask the following questions: 1. what are typical problems in this area? 2. how can they be modelled by graphs or graph transformation? 3. what kind of graph transformation results can be applied to solve these problems? 4. what are missing graph modelling and transformation concepts and results? in the evaluation (section 7), we summarize the experiences gained from the case studies and state what kinds of concepts and results we find still missing. 2 algebraic graph transformation: background for nearly 40 years, graph transformation has been studied in a variety of approaches, motivated by application domains such as pattern recognition, semantics of programming and visual modelling languages, specification of distributed systems etc. [eekr99, ekmr99, btms99]. a detailed presentation of different graph transformation approaches, is given in volume 1 of the handbook of graph grammars and computing by graph transformation [roz97]. the algebraic approach is based on pushout constructions, where pushouts are used to model the proc. gramot 2010 2 / 21 eceasst gluing of graphs. in fact, there are two main variants of the algebraic approach, the double and the single pushout approach. the double pushout (dpo) approach [eept06], is the formal basis for visual modelling of behavioural models and model transformations considered in this article. the dpo approach is based on category theory: a graph transformation rule is a pair of morphisms in the category of graphs with total graph morphisms as arrows: r = (l ← k → r) where k → l is injective. graph k is called gluing graph. another graph morphism m : l → g models an occurrence of l in g and is called a match. intuitively, this means that l is a subgraph that is matched to g, and after a match is found, the rule can be applied. a direct transformation or application of rule r to graph g is defined by two pushout diagrams (see the diagram to the right). applying the rule, m(l) is replaced with m∗(r) in graph g, leading to the transformed graph h. a graph transformation, or, more precisely, a graph transformation sequence, consists of zero or l (1)m �� k (2) loo r // �� r m∗ �� g doo // h more direct transformations, written g0 ∗ =⇒ gn. a set of graph rules is called graph transformation system. a type graph defines a set of types which can be used to assign a type to the nodes and edges of a graph. the typing itself is done by a graph morphism from the graph to the type graph. a typed graph transformation system gt s = (t g,p) consists of a type graph tg and a set p of typed graph rules. a (typed) graph grammar gg = (gt s,s) consists of a (typed) graph transformation system gt s and a (typed) start graph s. the (typed) graph language l of gg is defined by l = {g | ∃ (typed) graph transformation s ∗=⇒ g}. the key idea of attributed graph transformation is to model graphs with node and edge attributes, i.e. an attributed graph is a pair ag = (g,a) of a graph g and a data type algebra a. typed attributed graph transformation, combining process and data modelling proved to be well-suited to define and analyse visual models and model transformations [eept06, mvvk05]. a variety of tools for graph transformation exist [teg+05] to be used as transformation engine and for analysis purposes, to reason about issues such as conflicts and dependencies of actions as well as consistency of object structures. 3 case study 1: medical information system problem information systems are very common nowadays in almost all common application areas of software systems. in health care, data from different domains like admission, physical examination, medical record archive, etc. have to be coordinated and presented to the employees. data manipulations, like the admission of a new patient, have to be supported intuitively. aim of the model an interactive visual application with a suitable graphical user interface shall be generated from a suitable model. instead of complex textual data, visual symbols shall be used to support the necessary information system operations. the operations shall be modelled in a precise, unambiguous way. 3 / 21 volume 30 (2010) graph modelling and transformation: theory meets practice technique to solve the problem / realize the aim we use typed, attributed graphs to model the abstract syntax of the information systems, and graph transformation rules on the abstract syntax model to define the operations to be performed by the clinical staff. moreover, we combine the abstract syntax elements with concrete syntax symbols to visualize graphs in an adequate, domain-specific way. constraints and application conditions are used to check the consistency of the model and the operations to be performed. from this model, the interface and operation code allowing the users to operate on the information system visually is generated automatically. overview of the model figure 1 shows icons for patients, beds, rooms, admission and discharge (from left to right) used in our information system. figure 1: graphical symbols for medical information system in figure 2, the current ward patient allocation diagram shows bed icons inside the room icons to represent the number of available beds in the ward rooms. figure 2: sample user interface diagram for medical information system a patient icon is connected with a bed if occupied, otherwise the bed is left empty. patients currently not associated with a bed are shown next to the admission symbol. this requires a user action. dragging an female patient symbol onto a free bed symbol evokes rule admission (figure 3). applying this rule, the user of the information system assigns a female patient to a bed and a room, unless there are male patients in the same room (modelled by a nac). with a visual rule editor, the information system designer may define new rules and user policies according to the needs and standards of the hospital. proc. gramot 2010 4 / 21 eceasst figure 3: sample rule admission tool support tiger 2 [beeh09] is an generator of modeling tool environments for visual domain specific languages. in the modelling environment, a set of graph transformation rules called editing rules define the editing commands of the generated visual editor, i.e. the model syntax; on the other hand, a set of simulation rules may describe a model’s operational semantics. figure 4: abstract syntax definition in tiger 2 figure 4 shows the (simplified) abstract syntax of the case study modelled in tiger 2. a patient is associated with a bed located in a room of the ward numbered with the attribute number of data type string to allow for combinations of letters and numbers (e.g. ’room a15’). node patient is an abstract node, specialized to nodes female patient and male patient. the patient attribute health record id of is used for unique identification of the current health record in the system database. one patient may acquire more than one health record ids for different admissions. the attributes x, y, width, and height are used for icon visualization. related work starting with an emf domain model, the graphical modeling framework (gmf) [gmf07] provides a code generation facility for a graphical editor with basic editor operations for inserting graphical objects and links between them. apart from gmf [gmf07], also the topcased modeler generator of the openembedd [ope09] mde platform provides graphical patterns for common parts of user specific emf domain models and thus allows to easily create a basic graphical editor, visualizing mainly the abstract model syntax as graph-like diagrams with nodes 5 / 21 volume 30 (2010) graph modelling and transformation: theory meets practice and edges. more sophisticated tools generating graph-based modelling environments that can be customized to various domains are e.g. metaedit+ [tr03], the generic modeling environment gme [akl03] and diagen [min07], a diagram editor generator based on graph transformation. unsolved problems graph-based modelling environments need to integrate various domain specific editors and views for defining e.g. simulations and model transformations. all views have to be interconnected and customized to the domain. up to now, such multi-view editors cannot be generated automatically from domain models by generators like gmf. we are convinced that a combination of emfbased modeling tools [emf09] and graph transformation tools [tae06] provide a solid basis to define complex operations for editing, simulation, and model transformation of domain specific languages based on a well-defined theoretical background [bet08]. up to now, a comprehensive generation framework combining graph transformation, emf-based meta-modeling and for the generation of customized visual modelling environments has not yet been implemented. 4 case study 2: business process model transformation problem the business process modelling notation (bpmn) [whi04] is a graph-oriented language in which control and action nodes can be connected almost arbitrarily. it defines a business process diagram (bpd), which is a kind of flowchart incorporating constructs tailored to business process modelling, such as and-split, and-join, xor-split, xor-join. it is supported by various modelling tools but so far no systems can directly execute bpmn models. the business process execution language for web services (bpel) [ibm03], on the other hand, is a mainly block-structured language. bpel is emerging as a de-facto standard for implementing business processes on top of web services technology. numerous platforms support the execution of bpel processes. aim of the model the aim of this case study is to define the bpmn2bpel model transformation at an adequate abstraction level. a challenge in formalizing the particular model transformation is the translation of bpmn and and xor constructs to the corresponding bpel language elements flow and switch. translating those constructs with ordinary graph transformation rules requires a complex control structure for guidance. we aim for an intuitive, visual description of the model transformation where arbitrary many branches of and and xor constructs can be treated in parallel. technique to solve the problem / realize the aim we use typed, attributed graph transformation based on an integrated type graph t gi . this type graph consists of the type graphs for the source and target language, and, additionally, reference nodes with arcs mapping source elements to target elements. we express model transformations directly by t gi -typed graph transformation rules l←k →r where l basically represents source model elements, and r represents the corresponding generated target model elements. the model proc. gramot 2010 6 / 21 eceasst transformation starts with graph gs typed over t gs. as t gs is a subgraph of t gi , gs is also typed over t gi . during the model transformation process, the intermediate graphs gs = g1,..,gn are all typed over t gi . to delete all items in gn which are not t gs � � incs // t gi t gt? _inctoo gs typegs oo r1 +3 ... rn +3 gn typegn oo gt typegt oo oo typed over t gt , we can construct a restriction (a pullback in the category graphs), which deletes all those items in one step. in addition to normal graph transformation rules, we also use rule schemes to express parallel transformation of arbitrary many similar model element patterns. the application of rule schemes is defined by the concept of amalgamated graph transformation [bfh87]. overview of the model transformation the complete model transformation case study is described in [bee+10]. the type graph integrating the bpmn source model (left-hand part), the reference part connecting source and target model (the node type f2aref and its adjacent edge types bpmn and bpel), and the bpel target model (right-hand part) is shown in figure 5. figure 5: bpmn2bpel type graph as an example we consider a bpmn diagram which models a person’s interaction with an atm (see figure 6 where the concrete and abstract syntax of the diagram are depicted). in the upper part, the atm machine accepts and holds the card of the person while simultaneously contacting the bank for the account information. (the language elements andsplit and andjoin are used to model parallel actions.) afterwards, the display prompts the user for the pin. depending on the user’s input there are three alternative actions possible: (1) the user enters the correct pin and can withdraw money, (2) a wrong pin is entered – a message is displayed, (3) the operation is aborted – an alarm signal is given. we give one example for a model transformation rule scheme (in abstract syntax) to translate xor constructs. all other rules and rule schemes can be found in [bee+10]. an xor construct (a number of branches surrounded by an xorsplit and xorjoin element) is translated to a switch container node which contains a child for each branch emerging from the xorsplit. since the number of branches can be arbitrary, a normal graph transformation rule or any finite number 7 / 21 volume 30 (2010) graph modelling and transformation: theory meets practice figure 6: atm machine in bpmn in concrete syntax (a) and abstract syntax (b) of rules would not be sufficient to express this situation. therefore, we here use amalgamated graph transformation, a technique to specify forall-operations on recurring model patterns (e.g. for each branch in an and construct). a multi-rule scheme contains a fixed kernel rule part and the recurring model pattern (called multi-rule ). the kernel rule part defines the elements in the graph which are common to all recurring model patterns (e.g. the xorsplit and xorjoin nodes that surround all branches). an amalgamated rule, induced by such a scheme, is a kind of parallel rule operating on all recurring model patterns in parallel but synchronized by the kernel rule part. applying the amalgamated rule to a graph, it modifies all recurring matches of the model pattern, which overlap in the match of the kernel rule in one step. we model a multi-rule scheme as a rule embedding of the kernel rule part into the multi-rule, which contains in addition to the kernel rule part the recurring model pattern. the upper part of figure 7 shows the kernel rule part, where one branch surrounded by an xorsplit and xorjoin is translated to a bpel switch node with one case branch where the condition in the next node is translated to a case distinction. the multi-rule for processing and constructs is shown in the bottom part of figure 7. it extends the kernel rule by one more branch, which comprises the recurring model pattern, and translates it accordingly. the rule embedding from the kernel rule to the multi rule is indicated in figure 7 by corresponding numbers of some of the graph objects. for applying a multi-rule scheme, first, a match of the kernel rule is selected. then, copies of the multi-rule are constructed, one for each new match of a multi-rule in the current host graph that overlaps with the match of the kernel rule. at last, all multi rule copies are glued at their corresponding kernel rule objects which leads to a new rule, the amalgamated rule. the application of the amalgamated rule is called amalgamated graph transformation. the application of the multi-rule scheme createswitch in figure 7 to the atm graph in figure 6 yields the amalgamated rule in figure 8 where the kernel rule is glued with two multi-rule copies proc. gramot 2010 8 / 21 eceasst figure 7: multi-rule scheme createswitch (since we have three branches in figure 6 between the xorsplit and the xorjoin). the amalgamated rule in figure 8 is then used to translate the three branches in one step by applying it to the atm graph in figure 6. figure 8: amalgamated rule of scheme createswitch constructed for the atm model in figure 6 for this case study, a theoretical result [geh10] is applied which allows us to show parallel independence of amalgamated graph transformations by analyzing the underlying multi-rules. hence, we may translate the and construct and the xor construct using amalgamated graph transformation in arbitrary order. after applying our transformation rules and schemes starting with the atm model in figure 6, we get the resulting integrated graph shown in figure 9 (b). the abstract syntax of the bpel expression is the red tree with root node sequence. the concrete syntax of the bpel model corresponding to this tree is shown in figure 9 (a). 9 / 21 volume 30 (2010) graph modelling and transformation: theory meets practice figure 9: atm machine after transformation: (a) in concrete bpel syntax, (b) in abstract syntax tool support we implemented the case study in our tool agg [agg09, bel+10], supporting the definition of type graphs, typed attributed graph rules and constraints. agg has been extended recently by support for defining and applying amalgamated graph transformation. all screenshots in this section are taken from the agg editors for rules and interaction schemes. moreover, agg supports verification of model transformations w.r.t. termination and confluence (functional behaviour). related work a related model transformation approach based on graph transformation are triple graph grammars (tggs) [sch94] which transform pairs of related models simultaneously while maintaining their consistency. tggs generate languages of triple graphs, consisting of a source graph gs and a target graph gt , together with a correspondence graph gc “between” them. a triple graph is typed by a meta-model triple which contains the source and target meta-models, and declares the types of mappings between the elements of both languages. a triple rule tr consists of triple graphs l = (sl ←cl → t l) and r = (sr ←cr → t r), and an injective triple graph morphism tr = (s,c,t) : l → r, representing a non-deleting rule which adds target elements. further graph transformation tools tuned for domain-specific model transformations are viatra2 [bns+05] and the graph rewriting and transformation language (great) [sal+03]. a tool that also supports amalgamated graph transformation is atom3 [lva04] where the technique is used for model simulation [lete04]. unsolved problems an open problem is the semantical correctness of model transformations. in order to be semantically correct, a model transformation should lead to target models which behave equivalently w.r.t. the corresponding source models. this is an important property of e.g. code generators for behavioural models. in the case that a model is more abstract than the code, semantical properties are defined explicitly, and it has to be shown that these properties are fulfilled by the respective pairs of source and target models. proc. gramot 2010 10 / 21 eceasst 5 case study 3: metabolic pathway analysis problem metabolic pathway analysis is one of the tools in biology and medicine in order to understand chemical reaction cycles in living cells. the problem is that often, reactions are analysed at the level of structural formulae only, thus summarising the number of atoms of certain types in a compound without keeping track of their identity. aim of the model this case study [ehl06] aims at understanding chemical reactions at the level of individual atoms or component molecules. in particular, we are interested in the analysis of causal dependencies between biochemical reactions. given a metabolic pathway (a sequence of reactions) we would like to be able to trace the history of particular atoms or molecules. this is relevant, for example, when trying to anticipate the outcome of experiments using radioactive isotopes of such atoms. such questions have been crucial to the detailed understanding of the nature of reactions like the citric acid cycle. techniques used to solve the problem / realize the aim biological systems and chemical reactions are characterized by their inherent concurrency, allowing reactions to take place simultaneously as long as they involve different resources and to keep track of causal dependencies and conflicts between them. graph transformation systems provide concurrency concepts which are suitable to be applied in this area. for modeling the metabolic pathway, we propose a new hypergraph model for chemical compounds which refines the classical representation in terms of structural formulae in two different ways. • our representation keeps track of the identity of atoms or molecular components by means of the identities of hyperedges. in contrast, when writing down chemical reactions with structural formulae, the identities of the reacting atoms are not explicitly represented in the notation. in situations where several atoms of the same element are involved, this lack of information leads to ambiguity as to where a new atom is placed in the resulting molecule. our graph transformation-based model allows to track atom identities by graph homomorphisms between the graphs representing the compounds before and after the reaction. • modelling atoms as hyperedges, each connected to an ordered sequence of nodes, the relative spatial orientation of different molecular components is recorded through the ordering of the nodes connected to a hyperedge. using this model we are able to trace the dependencies between different steps in the reaction based on individual atoms and their spatial arrangement. formally, given a ranked set of labels a = (an)n∈n, an a -labelled hypergraph (v,e,s,l) consists of a set v of vertices, a set e of edges, a function s : e → v∗ assigning each edge a sequence of vertices in v , and an edge-labelling function l : e →a such that, if length(s(e)) = n then l(e) = a for a ∈ an, i.e., the rank of the labels determines the number of nodes the edge is attached to. a morphism of hypergraphs is a pair of functions φv : v1 →v2 and φe : e1 → e2 that 11 / 21 volume 30 (2010) graph modelling and transformation: theory meets practice preserve labels and assignments of nodes, that is, l2 ◦φe = l1 and φ∗v ◦s1 = s2 ◦φe . a morphism thus has to respect the atom represented by an edge and also its chemical valence (number of bonds). labelled hypergraphs can be considered as hierarchical graph structures. as shown by löwe [löw93], pushouts can be computed elementwise for all hierarchical graph structures and therefore the standard graph transformation approaches can be applied. overview of the model we consider as an example the citric acid cycle, a classical, but non-trivial reaction for energy utilisation in living cells [zpv95]. our approach supports a molecular analysis of the cycle, tracing the flow of individual carbon atoms based on a simulation. this cycle is a series of chemical reactions of central importance in all living cells that utilise oxygen as part of cellular respiration. starting with acetyl-coa, one of the resulting products of the chemical conversion of carbohydrates, fats and proteins, the citric acid cycle produces fast usable energy in the form of nadh, gtp, and fadh2 which are precursors of the well known adenosine-tri-phosphate (atp). the diagram to the right shows reaction 2 of the citric acid cycle. the input agent of reaction 2, citrate, has two ch2coo− groups, one on the top and one on the bottom. to fit into the enzyme aconitase catalysing reaction 2, only the ch2coo− group marked with 3 is able to fit into the enzyme due to 3-dimensional spatial relations. coo coo ch2 isocitrate ch cooch 11 22 33 44 coo coo ch2 citrate ch2 coocho 11 22 33 44 ho in our hypergraph model, we interpret the hyperedges as atoms and the nodes as bonds between them. the string s(e) of vertices incident to an edge e ∈ e gives the specific order of the bonds to other atoms, coding also their spatial configuration, as we will see. as ranked set of labels, we use a1 ={h, ch3,oh,...}, a2 ={o, ch2,s,...}, a3 ={ch, n,...}, a4 = {c, s,...},... to denote elements of the periodic system or entire chemical groups. the rank of a label models the valence of an atom. for instance, a carbon atom with l(e) = c always has s(e) = v1v2v3v4, a word of length 4. hence, we define c as a label of rank 4. for elements with more than one possible valence (e.g. sulphur), the corresponding label can belong to several of the sets an. given an organic molecule, we represent the 3-dimensional configuration of the ligands of a c atom as a hypergraph by relating it to d-glyceraldehyde, one of the simplest chiral organic compounds. we impose a numbering on the ligands of a carbon atom such that a substitution of ligand 1 by oh, ligand 2 by cho, ligand 3 by ch2oh, and ligand 4 by h would result in d-glyceraldehyde. this convention defines the spatial arrangement of the ligands unambiguously. substitution of ligands may change the angles between the ligands, and they often differ from the regular tetrahedral angle of 109◦28′, but the so called angle strain [mos96] does not affect the uniqueness of the molecule represented by our notation. proc. gramot 2010 12 / 21 eceasst as example, figure 10 shows the representation of the prochiral molecule citrate as a hypergraph, where v ={v1,v2,...,v6},e ={e1,e2,...,e7}, s(e1) = v1,s(e2) = v1v2,s(e3) = v3,s(e4) = v2v3v4v5,s(e5) = v4,s(e6) = v5v6,s(e7) = v6 l(e1) = coo −,l(e2) = ch2,l(e3) = oh,l(e4) = c,l(e5) = coo −,l(e6) = ch2,l(e7) = coo − figure 10: structural formula (left) and hypergraph representation (right) of citrate. tool support we provide an encoding of the model in terms of attributed bipartite graphs that can be implemented in the agg system for simulation and analysis [tae04, agg09]. figure 11 shows reaction 2 of the citric acid cycle modelled in agg. the enzyme aconitase accepts only the source agent citrate with the indicated o edge attribute order of the 1:c atom in the left-hand side of figure 11. in this reaction the oh group of the 1:c atom is exchanged with the oh group of the 3:c atom. this leads to the new agent isocitrate. figure 11: reaction 2 of the citric acid cycle in agg. 13 / 21 volume 30 (2010) graph modelling and transformation: theory meets practice related work the use of graph transformation for biological systems has a long history (see [rv05]), but early applications were mostly devoted to the field of morphogenesis. our approach focuses on biochemistry, a field which gained much importance in the last decades because of the growth of biotechnology. providing automated assistance for analyzing biochemical reactions can help in understanding the principles which govern the processes in living cells. unsolved problems the citric acid cycle is a very common cycle for energy utilization in living cells. however, biological systems are very complex and hard to understand, so most of the biological pathways are still not completely understood. for analyzing more complex pathways, big computer clusters are needed. modelling with graph transformations might produce an overhead of data structures for the internal representation and computation with graphs. in general, the graph transformation problem is np-complete. putting several reactions together, the system might be unsolvable in a usable time frame. recently, more focus has been given to the comparison of graph transformation tools with respect to performance (memory usage and efficiency). starting with varró’s benchmark study [vsv05], a transformation tool contest1 is held regularly nowadays where scalability and performance of graph-based transformation tools are important issues (see also [rv10]). 6 case study 4: self-healing automated traffic-light problem self-healing (sh-)systems are characterized by an automatic discovery of system failures, and techniques how to recover from these situations. the problem is that failures can occur at any time during system operation. it is very important for such systems that recovery actions can always be applied after a failure has occurred and that they always lead to a system that works as expected. aim of the model the aim of our model is to verify that sh-systems have certain self-healing properties. for an sh-system, we distinguish reachable, failure and normal states (depending on which sets of constraints they fulfill), where reachable states split into normal and failure states. in particular, we call an sh-system is self-healing if each system state considered as failure state can be repaired, i.e. the system state after the repair action is considered as normal state. furthermore, we want to ensure certain liveness properties of sh-systems. we call an sh-system deadlockfree if no reachable system state is a deadlock. a stronger liveness property is strong cyclicity, meaning that each pair of reachable states can be reached from each other. technique to solve the problem / realize the aim in this case study, we model sh-systems by typed attributed graph transformation systems en1 case studies and solutions of the last three years’ contests are available at http://www.planet-research20.org/ttc2010/ proc. gramot 2010 14 / 21 http://www.planet-research20.org/ttc2010/ eceasst riched with graph constraints expressing their operational properties. we make use of theoretical results, i.e. sufficient static conditions for self-healing properties, deadlock-freeness and liveness of sh-systems. overview of the model the complete case study is given in [eer+10]. we model an automated traffic light system (tls). the traffic light technology is based upon electromagnetic sensors buried some centimeters underneath the asphalt of car lanes. the sensors register traffic data and send them to other system components. the tls is connected to cameras which record videos of the violations and automatically send them to the center of operations. in addition to the normal behavior, we may have failures caused by a loss of signals between a traffic light or a camera and the supervisor component. for each of the failures there are corresponding repair actions which can be applied after monitoring the failures during run-time. we define the traffic light sh-system tls by a type graph t g, an initial state, a set of normal rules rnorm (modelling the ideal behaviour), a set of failure rules r f ail modelling failures, a set of repair rules rrepair, which are the inverse repair rules, and sets of constraints that characterize properties of states being either consistent or failure states. in our example, we model a single traffic crossing with two traffic lights in directions northsouth and east-west. in the initial state (see figure 12), both traffic lights are red and there are no cars at the crossing. the tl nodes represent the traffic lights, connected to a crossing supervisor component, and to cameras which are currently not in use (oncamera=false). the infraction attribute becomes true in the case that a car runs a red light. figure 12: tls initial state ginit normal rules rnorm model the behaviour of cars arriving at the crossing and leaving it, as well as cars running a red light and being filmed by a camera. failure rules renv (applied from the environment) model the loss of a signal of either a traffic light (in this case the signal attribute of a tlsup edge changes to false), or of a camera (here, the signal attribute of a camsup becomes false). repair rules rr pr model the recovery from the respective signal loss. in [eer+10], we formalize operational properties, including self-healing and deadlock-freeness and provide static conditions for them based on rule set analysis. an sh-system shs is called self-healing, if each failure state can be repaired, i.e. ∀ginit ⇒∗ g via (rnorm ∪renv) with g ∈ fail(shs) ∃ g ⇒+ g′ via rr pr with g′ ∈ norm(shs). shs is called deadlock-free, if no reachable state is a deadlock, i.e. ∀g0 ∈ reach(shs) ∃ g0 p =⇒ g1 via p ∈ rnorm ∪renv ∪rr pr. in particular, shs is normally deadlock-free, if no state reachable via normal rules is a (normal) deadlock, i.e. ∀ginit ⇒∗ g0 via rnorm ∃ g0 p =⇒ g1 via p ∈ rnorm. 15 / 21 volume 30 (2010) graph modelling and transformation: theory meets practice shs is strongly cyclic, if each pair of reachable states can be reached from each other, i.e. ∀g0,g1 ∈ reach(shs) ∃ g0 ⇒∗ g1 via rnorm ∪renv ∪rr pr. for the analysis of sh-systems, we have the following results concerning self-healing properties and deadlock-freeness: an sh-system is self-healing, if it has the following three properties: 1) the initial state is normal and all normal rules preserve normal states, 2) each pair (p,q)∈ renv × rnorm is sequentially independent, and 3) the effect of each environment rule can be repaired up to normal transformations. furthermore, an sh-system is deadlock-free, if it is normally deadlock-free, and each pair (p,q) ∈ (renv ∪rr pr) × rnorm is sequentially and parallel independent. for the proof of these analysis results and further self-healing and liveness properties see [eer+10]. tool support for the automatic analysis of the static conditions ensuring the self-healing properties we use agg, in particular to check on sequential and parallel independence of pairs of rules. agg computes dependencies and conflicts of rules and visualizes their reasons. all properties are verified for our traffic light system. related work different related approaches exist, either based on graph transformation [6,14,15,16,17,18,19] or on temporal logics and model checking [20,21,22]. in many cases, though, the state space of behavioral system models becomes too large or even infinite, and in this case model checking techniques have their limitations. unsolved problems a helpful extension of the formal approach would be the analysis and verification of consistency properties using the theory of graph constraints and nested application conditions in [ehl10b]. moreover, we will investigate how far the techniques for sh-systems can be used and extended for more general self-adaptive systems. 7 evaluation and conclusion the table in figure 13 summarizes the problem domains and modelling features and results for our four case studies. in the last line, we state concepts which, from our point of view, are missing not only for the particular case study presented in this paper but rather in general for the respective application domain. in the area of visual language modelling, e.g. for case study (1), the concept of typed attributed graph transformation, which is close to meta-modelling, proved to be suitable for defining syntax and semantics of domain-specific languages. but to be useful in the context of larger systems, these principles should be integrated in tools that are used in practical applications. in our case study, a suitable user interface should hide the formal representation of abstract graph and rule syntax, and the underlying model needs to be linked to the clinic information system. here, advanced tool support integrating graph transformation tools to existing tools used in practice is one aim for graph transformation technology transfer. proc. gramot 2010 16 / 21 eceasst (1) medical information system (2) business process model transformation (3) metabolic pathway analysis (4) self-healing automated traffic light problem adequate visualization of clinical processes source-to-target model transformation molecular analysis of chemical reactions system modelling with failures and recovery gratra model visual language modelling by typed attributed gratra gratra based on source-target type graph inclusion tgs → tgi ← tgt hypergraph transformations with simulation gratra with different rule sets rnormal, rfailure, rrepair and constraints gratra results graph constraint satisfaction after transformation parallel independence of amalgamated gratra simulation, embedding and extension static analysis of self-healing properties missing concepts advanced tool support for visual user interfaces semantical correctness of model trafos scalability of graph representation critical pair analysis for general conditions figure 13: comparison of case studies model transformations from domain-specific models to more machine-centric formats like case study (2) have become a necessary step towards unified and standards-based development environments. here, important results have been achieved in recent years concerning the syntactical correctness of model transformations and their functional behaviour, i.e. termination and uniqueness. also, for triple graph grammars, properties concerning the consistency of source and target models w.r.t. triple rules can be shown formally. an open problem for model transformations remains the semantical correctness, i.e. how can be shown in general that the behaviour of the source and the target model are equivalent (see also [erm09]). often, a validation by simulation is helpful to provide new insights on behavioural system properties. case study (3) showed that a simulation by graph transformation, supported by tools, can help to find a suitable abstraction level and visualize model features (like molecule identities) which are not easily seen using standard techniques and tools. here, the problem arises that in contrast to standard tools, a graph representation might lead to a larger memory consumption than e.g. the standard format for chemical formulae. morover, scalability, i.e. effieciency of the rewriting in large models is a general problem. these problems have been tackled already by comparing and improving the performance of existing graph transformation engines and by experimenting with different data formats for graphs and rules and by optimizing the pattern matching process which is the bottleneck of graph transformation. here, more future work will be necessary for further optimizations. many verification results for graph transformation systems are based on critical pair analysis. this kernel technique is also used in case study (4), where we analyze conflicts and dependencies of rules to show self-healing properties. recently, general (nested) conditions on graphs have been defined by habel and pennemann [hp09]. these conditions allow for a very flexible modelling of graph rules. in this context, it remains to provide a suitable theory for critical 17 / 21 volume 30 (2010) graph modelling and transformation: theory meets practice pair analysis of rules with nested application conditions while a formal background is presented already in [ehl+10a]. . some of the “missing concepts” are topics of ongoing research projects2. we are confident that the visibility of graph transformation technology in practice will be further enhanced and that meetings between theory and practice, aided by good tool support, will be the rule rather than the exception. bibliography [agg09] tfs-group, tu berlin. agg. 2009. http://tfs.cs.tu-berlin.de/agg. [akl03] a. agrawal, g. karsai, a. ledeczi. an end-to-end domain-driven software development framework. in proc. conf. on object-oriented programming, systems, languages and applications. acm sigplan, usa, 2003. [bee+10] e. biermann, h. ehrig, c. ermel, u. golas, g. taentzer. parallel independence of amalgamated graph transformations applied to model transformation. in graph transformations and model-driven engineering. essays dedicated to manfred nagl. lncs 5765. springer, 2010. to appear. http://tfs.cs.tu-berlin.de/publikationen/papers10/bee+10.pdf [beeh09] e. biermann, k. ehrig, c. ermel, j. hurrelmann. generation of simulation views for domain specific modeling languages based on the eclipse modeling framework. in taentzer and heimdahl (eds.), automated software engineering (ase’09). pp. 625 – 629. ieee press, 2009. [bel+10] e. biermann, c. ermel, l. lambers, u. prange, g. taentzer. introduction to agg and emf tiger by modeling a conference scheduling system. int. journal on software tools for technology transfer 12(3-4):245–261, juli 2010. doi:10.1007/s10009-010-0154-x http://www.springerlink.com/content/p4n1g45627852743/ [bet08] e. biermann, c. ermel, g. taentzer. precise semantics of emf model transformations by graph transformation. in czarnecki (ed.), proc. int. conf. on model driven engineering languages and systems (models’08). lncs 5301, pp. 53– 67. springer, 2008. http://tfs.cs.tu-berlin.de/publikationen/papers08/bet08.pdf [béz05] j. bézivin. on the unification power of models. software and system modeling 4(2):171–188, 2005. [bfh87] p. böhm, h.-r. fonio, a. habel. amalgamation of graph transformations: a synchronization mechanism. computer and system sciences (jcss) 34:377–408, 1987. 2 see e.g. our project behaviour simulation and equivalence of systems modelled by graph transformation (supported by the german research council) at http://www.tfs.tu-berlin.de/menue/forschung/#behaviourgt. proc. gramot 2010 18 / 21 http://tfs.cs.tu-berlin.de/agg http://tfs.cs.tu-berlin.de/publikationen/papers10/bee+10.pdf http://dx.doi.org/10.1007/s10009-010-0154-x http://www.springerlink.com/content/p4n1g45627852743/ http://tfs.cs.tu-berlin.de/publikationen/papers08/bet08.pdf http://www.tfs.tu-berlin.de/menue/forschung/#behaviourgt eceasst [bns+05] a. balogh, a. németh, a. schmidt, i. rath, d. vágó, d. varró, a. pataricza. the viatra2 model transformation framework. in proc. european conference on model driven architecture (ecmda’05). 2005. [btms99] r. bardohl, g. taentzer, m. minas, a. schürr. application of graph transformation to visual languages. in ehrig et al. (eds.), handbook of graph grammars and computing by graph transformation, volume 2: applications, languages and tools. world scientific, 1999. [eekr99] h. ehrig, g. engels, h.-j. kreowski, g. rozenberg (eds.). handbook of graph grammars and computing by graph transformation, volume 2: applications, languages and tools. world scientific, 1999. [eept06] h. ehrig, k. ehrig, u. prange, g. taentzer. fundamentals of algebraic graph transformation. eatcs monographs in theor. comp. science. springer, 2006. [eer+10] h. ehrig, c. ermel, o. runge, a. bucchiarone, p. pelliccione. formal analysis and verification of self-healing systems. in proc. int. conf. on fundamental aspects of software engineering (fase’10). lncs 6013, pp. 139–153. springer, 2010. http://www.springerlink.com/content/hv51032524v38321/ [ehl06] k. ehrig, r. heckel, g. lajios. molecular analysis of metabolic pathway with graph transformation. in proc. int. conf. on graph transformation (icgt’06). lncs 4178, pp. 107–121. springer, 2006. [ehl+10a] h. ehrig, a. habel, l. lambers, f. orejas, u. golas. local confluence for rules with nested application conditions. in proc. int. conf. on graph transformation (icgt’10). 2010. to appear. http://tfs.cs.tu-berlin.de/publikationen/papers10/ehl+10.pdf [ehl10b] h. ehrig, a. habel, l. lambers. parallelism and concurrency theorems for rules with nested application conditions. electr. comm. of the easst 26, 2010. http://journal.ub.tu-berlin.de/index.php/eceasst/issue/view/36 [ekmr99] h. ehrig, h.-j. kreowski, u. montanari, g. rozenberg (eds.). handbook of graph grammars and computing by graph transformation. vol 3: concurrency, parallelism and distribution. world scientific, 1999. [emf09] eclipse consortium. eclipse modeling framework technology. 2009. http://www.eclipse.org/modeling/emft. [eng00] g. engels. graph changes are everywhere: the role of graph transformations in software engineering. in proc. joint appligraph and getgrats workshop on graph transformation systems. pp. 12-13. tu berlin, 2000. [erm09] c. ermel. visual modelling and analysis of model transformations based on graph transformation. bulletin of the eatcs 99:135 – 152, 2009. 19 / 21 volume 30 (2010) http://www.springerlink.com/content/hv51032524v38321/ http://tfs.cs.tu-berlin.de/publikationen/papers10/ehl+10.pdf http://journal.ub.tu-berlin.de/index.php/eceasst/issue/view/36 http://www.eclipse.org/modeling/emft graph modelling and transformation: theory meets practice [geh10] u. golas, h. ehrig, a. habel. multi-amalgamation in adhesive categories. in proc. int. conf. on graph transformation (icgt’10). 2010. to appear. http://tfs.cs.tu-berlin.de/publikationen/papers10/geh10.pdf [gmf07] eclipse consortium. eclipse graphical modeling framework (gmf). 2007. http://www.eclipse.org/gmf. [hp09] a. habel, k.-h. pennemann. correctness of high-level transformation systems relative to nested conditions. mathematical structures in comp. science 19:1–52, 2009. [ibm03] ibm, bea systems, microsoft, sap ag, siebel systems. business process execution language for web services version 1.1. may 2003. http://www.ibm.com/developerworks/library/ws-bpel/. [lete04] j. de lara, c. ermel, g. taentzer, k. ehrig. parallel graph transformation for model simulation applied to timed transition petri nets. entcs 109:17–29, 2004. http://tfs.cs.tu-berlin.de/publikationen/papers04/lete04.pdf [löw93] m. löwe. algebraic approach to single-pushout graph transformation. tcs 109:181–224, 1993. [lva04] j. de lara, h. vangheluwe, m. alfonseca. meta-modelling and graph grammars for multi-paradigm modelling in atom3. software and system modeling: special section on graph transformations and visual modeling techniques 3(3):194–209, 2004. [min07] m. minas. diagen / diameta – the diagram editor generator. 2007. http://www.unibw.de/inf2/diagen/. [mos96] g. moss (ed.). iupac basic terminology of stereochemistry. volume 68(12). pure & applied chemistry, 1996. [mvvk05] t. mens, p. van gorp, d. varrò, g. karsai. applying a model transformation taxonomy to graph transformation technology . in proc. int. workshop on graph and model transformation (gramot’05). entcs 152, pp. 143–159. elsevier science, 2005. [omg07] object management group. unified modeling language: superstructure – version 2.1.1. 2007. http://www.omg.org/technology/documents/formal/uml.htm. [ope09] openembedd: model driven engineering open-source platform for real-time & embedded systems. 2009. http://openembedd.org. [roz97] g. rozenberg. handbook of graph grammars and computing by graph transformations, volume 1: foundations. world scientific, 1997. [rv05] f. rosselló, g. valiente. graph transformation in molecular biology. in formal methods in software and system modeling, lncs 3393, pp. 116–133. springer, 2005. proc. gramot 2010 20 / 21 http://tfs.cs.tu-berlin.de/publikationen/papers10/geh10.pdf http://www.eclipse.org/gmf http://www.ibm.com/developerworks/library/ws-bpel/ http://tfs.cs.tu-berlin.de/publikationen/papers04/lete04.pdf http://www.unibw.de/inf2/diagen/ http://www.omg.org/technology/documents/formal/uml.htm http://openembedd.org eceasst [rv10] a. rensink, p. van gorp (eds.). international journal on software tools for technology transfer (sttt), special section on graph transformation tool contest 2008. volume 12(3-4). springer, 2010. http://www.springerlink.com/content/p4n1g45627852743/ [sal+03] j. sprinkle, a. agrawal, t. levendovszky, f. shi, g. karsai. domain model translation using graph transformations. in int. conf. on engineering of computer-based systems. pp. 159–168. 2003. [sch94] a. schürr. specification of graph translators with triple graph grammars. in wg94 20th int. workshop on graph-theoretic concepts in computer science. lncs 903, pp. 151–163. springer, 1994. [tae04] g. taentzer. agg: a graph transformation environment for modeling and validation of software. in application of graph transformations with industrial relevance (agtive’03). lncs 3062, pp. 446 – 456. springer, 2004. [tae06] g. taentzer. characterizing tools for visual modeling techniques. in ehrig et al. (eds.), lecture notes of segravis advanced school on visual modelling techniques. univ. of leicester, 2006. http://tfs.cs.tu-berlin.de/publikationen/papers06/tae06a.pdf [teg+05] g. taentzer, k. ehrig, e. guerra, j. de lara, l. lengyel, t. levendovsky, u. prange, d. varro, s. varro-gyapay. model transformation by graph transformation: a comparative study. in proc. workshop model transformation in practice. 2005. http://tfs.cs.tu-berlin.de/publikationen/papers05/teg+05.pdf [tr03] j. tolvanen, m. rossi. metaedit+: defining and using domain-specific modeling languages and code generators. in proc. conf. on object-oriented programming, systems, languages, and applications (oopsla ’03). pp. 92–93. acm press, 2003. [vsv05] g. varró, a. schürr, d. varró. benchmarking for graph transformation. in proc. ieee symposium on visual languages and human-centric computing (vl/hcc 05). pp. 79–88. ieee press, 2005. [whi04] s. white. business process modeling notation (bpmn) version 1.0. bpmi.org, 2004. [zpv95] g. zubay, w. parson, d. vance. principles of biochemisty. volume 2. mcgraw-hill college, 1995. 21 / 21 volume 30 (2010) http://www.springerlink.com/content/p4n1g45627852743/ http://tfs.cs.tu-berlin.de/publikationen/papers06/tae06a.pdf http://tfs.cs.tu-berlin.de/publikationen/papers05/teg+05.pdf introduction algebraic graph transformation: background case study 1: medical information system case study 2: business process model transformation case study 3: metabolic pathway analysis case study 4: self-healing automated traffic-light evaluation and conclusion towards guided trajectory explorationof graph transformation systemsthis work was partially supported by the securechange (ict-fet-231101) project and the janos bolyai scholarship. electronic communications of the easst volume 40 (2011) proceedings of the 4th international workshop on petri nets and graph transformation (pngt 2010) towards guided trajectory exploration of graph transformation systems ábel hegedüs, ákos horváth and dániel varró 20 pages guest editors: claudia ermel, kathrin hoffmann managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst towards guided trajectory exploration of graph transformation systems∗ ábel hegedüs1, ákos horváth2 and dániel varró3 1 hegedusa@mit.bme.hu, 2 ahorvath@mit.bme.hu 3 varro@mit.bme.hu http://inf.mit.bme.hu/en department of measurement and information systems (mit) budapest university of technology and economics (bme), budapest, hungary abstract: graph transformation systems (gts) are often used for modeling the behavior of complex systems. a common gts analysis scenario is the exploration of its state space from an initial state to a state adhering to given goals through a proper trajectory. guided trajectory exploration uses information from some more abstract analysis of the system as hints to reduce the traversed state space. these hints are used to order possible further transitions from a given state (selection) and detect violations early (cut-off), thus pruning unpromising trajectories from the state space. in the current paper, we define cut-off and selection criteria for guiding the trajectory exploration, and use petri net analysis results and the dependency relations between rules as hints in our criteria calculation algorithm. the criteria definitions include navigation along dependency relations, various types of ordering for selection and quantifiers for cut-off criteria. our approach is exemplified on a cloud infrastructure configuration problem. keywords: graph transformation; trajectory exploration; petri nets 1 introduction model transformation is a common technique in model driven engineering to design, analyze and simulate various kinds of models. in case of model analysis, forward transformations usually carry out an abstraction (and create an abstraction gap) to enable efficient formal verification and validation. increasing the level of abstraction usually increases the efficiency of formal analysis but decreases its preciseness. as a result, mapping the information gathered from validation back to the original models (i.e. back-annotation) is also a challenge due to the abstraction gap between the source and target languages. therefore analysis results in the target model may only serve as a hint for the source model, and further processing steps are needed to complete the analysis. for example a hint can provide only the number of operations instead of their original sequence and further steps can obtain the sequence itself. when analyzing graph transformation systems (gts), a highly relevant technique in many application areas for modeling the behavior of systems, petri nets (pn) are often used as an ∗ this work was partially supported by the securechange (ict-fet-231101) project and the janos bolyai scholarship. 1 / 20 volume 40 (2011) mailto:hegedusa@mit.bme.hu mailto:ahorvath@mit.bme.hu mailto:varro@mit.bme.hu http://inf.mit.bme.hu/en towards guided trajectory exploration of gts abstraction to perform verification [kk06, bs06, ren04], optimization [vv06] or find errors in the implementation (debugging) [wks+09]. however, the results in certain kinds of analysis methods are not always execution paths (ordered sequences of rule applications or transition firings) for the gts, but more abstract information such as an occurrence vector containing only the number of transition executions (instead of their exact order). this occurrence vector may serve as a hint for calculating an execution path in the gts. in order to successfully retrieve the rule application sequences (execution paths or trajectories) on the gts-level, we have to explore the states reachable from an initial state by applying available rules. this approach is called state space exploration and is often used in verification of graph transformation systems [kk06]. guided trajectory exploration differs from state space exploration in making use of a hint (obtained, for instance, from some more abstract analysis result) that can reduce the number of states, which are explored to find an adequate trajectory by guiding exploration in the state space. the challenges of a guided trajectory exploration are two-fold: (1) at every state during the exploration, the hint can be used to decide if the current state is part of an infeasible path, thus we can terminate the exploration along this path (i.e. it is a dead-end in the search of a final state). this decision is made by evaluating a cut-off criteria. (2) the hint can be used to select which alternative exploration direction should be explored first (e.g. prioritize the alternate transitions to a next state by their likelihood of leading to the final state). this ordering is made by evaluating a selection criteria. in our paper, we define cut-off and selection criteria for guiding the trajectory exploration, and use the pn analysis results and the dependency relations between rules as hints in our criteria calculation algorithm. the cut-off criteria are defined to exploit the dependencies between graph transformation rules in order to make the decision based on information about the effects of future rule applications thus allowing early termination of infeasible paths. similarly, selection criteria use the dependencies to be able to calculate how alternative rules can affect the applicability of future rules and prioritize them accordingly. the criteria definitions include navigation along dependency relations, numerical operations on an occurrence vector, various types of ordering for selection and quantifiers for cut-off criteria. the rest of the paper is structured as follows. first, we give a high-level overview of the complete trajectory calculation approach in section 2. section 3 introduces the cloud configuration example, graph transformation systems and their abstraction as petri nets. we introduce the dependency graph, and explain how it correlates to the state of the gts during trajectory calculation in section 4. section 5 defines selection and cut-off criteria and specifies their calculation algorithm, which is illustrated by the case study. finally, related work is discussed in section 6 and section 7 concludes our paper. 2 overview of the approach the guided trajectory exploration problem appears in many scenarios, such as configuring infrastructures or other autonomic software systems. in our paper we deal with scenarios where the states are represented with graphs and operations are defined as gt rules. the rules and the initial graph are represented together as a gts in figure 1, which illustrates the overview of our proc. pngt 2010 2 / 20 eceasst trajectory exploration approach. apart from the gts, the state space exploration contains a goal, which describes properties of the final state (such as the number of elements of a given type), and constraints that each state must satisfy along the trajectory we seek (e.g. minimum number of elements of a given type). in our approach, both goals and constraints are defined as graph patterns. finally, the exploration strategy (including cut-off and selection criteria) is used to decide between multiple possible operations at a given state. the overall objective of the approach is to find a trajectory from the initial state to the final state. in our approach the strategy uses hints retrieved from analysis of the abstracted gts as described in the following: figure 1: overview of the solution occurrence vector-based search strategy approach in [vv06], the computation of an optimal rule application sequence is performed by encoding the petri net abstraction (detailed in [vve+06]) of the gts into an integer linear programming (ilp) problem. the solution of this problem (solved using cplex1 in our implementation) is a candidate transition occurrence vector. since the abstraction does not guarantee that this vector corresponds to an executable execution, its feasibility should be checked on the gts-level. however, in the original approach, the occurrence vector was used in the gts state space exploration by only allowing occurrence vector compliant execution paths to be explored. therefore, it did not help in selecting the most promising execution path or cutting the search on infeasible paths. selection and cut-off criteria for search strategy in this paper, we propose additional techniques, which also use the occurrence vector as a hint, to guide the state space exploration (implemented as an extension to the viatra2 model transformation framework [v2]) to further increase the performance of the algorithm. the main features of these new techniques are (a) using the rule (or transition) dependency graph (gd ) computed from the gts (using the condor [con] 1 http://www.ibm.com/software/integration/optimization/cplex-optimizer/ 3 / 20 volume 40 (2011) http://www.ibm.com/software/integration/optimization/cplex-optimizer/ towards guided trajectory exploration of gts dependency analyzer tool) to have a global view on the effects of rule applications [mkr06]; (b) defining selection criteria crsel on the applicable rules (transitions) at a given state (for deciding between alternative upcoming operations); and (c) defining cut-off criteria crcut on the paths (for deciding about the feasibility of further exploration). criteria defined in both (b) and (c) depend on gd and the application numbers for the rules (transitions) in the occurrence vector. 3 definitions in this section the basics of graph transformation, gtss and their pn-based abstraction are shortly discussed. before the definition, we introduce our demonstrating case study. 3.1 example we consider services built on top of a cloud middleware (cm) using components as building blocks. servers (s) and high-availability clusters (cl) can be deployed on the cm, while databases (db) are installed on servers and applications (app) are executed over databases. finally, servers can also be deployed on clusters and storage (st) subsystems can only operate over clustered servers. note that the configuration is not a tree structure (e.g. a database is deployed on multiple services, which in turn are deployed on a cloud or cluster), but a directed graph. in order to provide an appropriate infrastructure for clients, the configuration of the cloud infrastructure must meet certain requirements, e.g. an application and a storage subsystem is required for a cloud-based web service. such an infrastructure is shown in figure 2. figure 2: an example system providing reliable service to satisfy this constraint the cloud configuration has to be designed in an appropriate way. we assume that regular change management commands are issued by some middleware service broker. if the current infrastructure of the cloud implies that the required parameters cannot be satisfied by the actual cloud configuration, reconfiguration operations are to be initiated, which lead the system into a state where all constraints are met. the reconfiguration actions of cloud components will be captured by a graph transformation system that is defined subsequently. an overview on using graph transformations for software architecture reconfigurations can be found in [bhtv06]. 3.2 graph transformation a graph g = (n,e,src,trg) is a 4-tuple with a set n of nodes, a set e of edges, a source and a target function src,trg : e → n. a type graph t g is an ordinary graph. an instance graph g is proc. pngt 2010 4 / 20 eceasst typed over t g by a typing morphism type : g → t g. let card(g,x) denote the cardinality (i.e. the number of graph objects) of type x ∈ t g in graph g. figure 3: type graph an example type graph is shown in figure 3. the type graph contains only one cloud component node designated graphically as a rectangle. the edges cm, cl, s, db, app and st are used to denote the type of the component such that the source and the target node of this edge is the same node (so means socket and represents a cm or cl ). edge onr connect two different components denoting that the source node is deployed on the target node of this edge. graph transformation (gt) [cmr+97] provides a rule-based manipulation of graph models. a graph transformation (gt) rule typed over a type graph t g is given by r = (l l←− k r−→ r) where l (left-hand side), k (context) and r (right-hand side) graphs are typed over t g and graph morphisms l,r are injective. the negative application conditions (nac) of a gt rule are given by a (potentially empty) set of pairs (n,n) with n being a graph also typed over t g and n : l → n an injective graph morphism. application of a rule r to a host graph g alters the model graph by replacing the pattern defined by l with the pattern of r. this is performed by (i) finding a match of pattern l in model g (ii) checking the negative application conditions n, which may prohibit rule application, i.e. if there is a match of n in g (as an extension of the match of l in g), then the rule is not applicable (iii) removing a part of the model m that can be mapped to pattern l but not pattern r yielding an intermediate graph d and (iiii) adding new elements to the intermediate graph d, which exist in r but not in l yielding the derived graph h. a graph transformation sequence (gt sequence) is a sequence of gt steps (application of a rule on a given match), i.e., a sequence of rule applications. a gt sequence starting from graph g yields g′ and more than one gt step may belong to it. in the paper, we follow the double pushout approach [cmr+97]. example 1 the ongoing example is captured by a set of graph transformation rules in figure 4. in order to simplify the graphical presentation, we simply write the type cm, s, cl, db, app, st of the component on the node (which is denoted by a rectangle) instead of self-loop edges. this way, only onr edges remain, which we also omit by representing the hierarchy of deployment using vertical stacking of components. the addcm rule adds a new cm to the configuration, adds creates a new s deploying it on top of a cm or cl, however, a cl cannot have more than two s deployed on it. rule addcl produces a new cl deploying it on top of a cm, adddb adds a new db deploying it on top of two s that have no other node deployed on them, addapp creates a new app deploying it on top of two db that have no other node deployed on them. finally, addst adds a new st deploying it on top of two s that are deployed on the same cl and have no other node deployed on them. graph transition system a graph transformation system gt s = (r,t g) consists of a type graph t g and a finite set of graph transformation rules typed over t g. a graph transition system 5 / 20 volume 40 (2011) towards guided trajectory exploration of gts figure 4: graph transformation rules gs is defined as a graph where nodes are instance graphs, and edges are graph transformation steps such that the source and target nodes of the edge are graphs.starting from g0 (initial state) the state space (i.e. the reachable instance graphs) of gs is represented taking into account all applicable rules from a given host graph. the different matches of applicable rules may lead to different edges in gs. a path in the graph transition system is a gt sequence also called a trajectory between two graphs. then we say that a graph is reachable from g0 iff there is a path in the gs. example 2 in figure 5 an extract of the graph transition system of our running example is shown. on the left the root of the graph transition system is the start graph g0 where the system configuration contains a cm, three s, and one db components. rules adds, addcl, and addcm are applicable to g0, here we follow only the application of the first two rules. figure 5: a part of the graph transition system proc. pngt 2010 6 / 20 eceasst 3.3 petri net abstraction for gts our guided trajectory exploration approach is based on a petri net abstraction technique introduced for gts in [vve+06]. the motivation behind such an abstraction was that solving the reachability problem on the pn level is of much lower complexity than solving the problem directly on the gts-level using algorithmic exploration techniques. the essence of this abstraction technique is to derive a cardinality pn, which simulates the original gts by abstracting from the structure of instance graphs and only counting the number of elements (nodes or edges) of a certain type by placing tokens to a corresponding place. these tokens are circulated by transitions derived from each gt rule, which simulate the effect of the rule on the number of typed elements by adding and removing tokens from corresponding places. example 3 in figure 6 rule addcl of our example in section 3 is shown with the corresponding type graph on the left. the pn abstraction is shown on the right. according to the type graph of the example, the corresponding cardinality pn has a place for all node types, namely for type node, and edge types, namely cm, s, cl, db, app, st, and onr. figure 6: rule addcl and the corresponding cardinality petri net for instance, the left–hand side l of rule addcl contains a node and the edge cm. thus the corresponding transition with the same name has two incoming arcs starting from the corresponding places. similarly, the right–hand side of the rule consists of two nodes and edges cm, cl, and onr thus there are four outgoing arcs to node, cm, cl, and onr with weights 2,1,1,1, respectively. in this way whenever rule addcl is applied the number of the tokens at the involved places changes according to the cardinality of the graph types. the incidence matrix of the pn abstraction of the example gts is in figure 7. the places (columns) refer to the type places corresponding to the type graph of figure 6, while transitions (rows) refer to corresponding rules of figure 4. figure 7: incidence matrix of the petri net abstraction 7 / 20 volume 40 (2011) towards guided trajectory exploration of gts the coverability problem over pn can be encoded into an ilp problem, and the solution of the resulting ilp problem is a transition occurrence vector (σ ). the transition occurrence vector prescribes how many times a gt rule needs to be applied in order to reach the derived submarking of a solution state. for example, to get from an initial graph containing only one cm to a state with four s and two db, the shortest solution vector would be σ ={0,4,0,2,0,0}. further details about the encoding and solving can be found in [vv06]. note that [vve+06] proves that the mapping is a proper abstraction in the sense that the derived pn simulates the original gts, and it also discusses a possible abstraction of nacs into cardinality petri nets. however, that abstraction would deliver an integer non-linear programming problem for the trajectory finding problem for which solution techniques have greater complexity than solution techniques for an (i)lp problem. thus we ignore the abstraction of nacs in the current paper, but it is important to note that this is not a conceptual restriction since nacs only result in the generation of additional infeasible paths. 4 definition and usage of the dependency graph in this section we first describe the notion of graph transformation rule dependency and define the dependency graph that is constructed for gts (subsection 4.1). next, we demonstrate how the dependency graph relates to the state of the gts during trajectory exploration (subsection 4.2). 4.1 graph transformation rule dependency the application of a gt rule r can alter the graph in a way that other rules, which were disabled before, become enabled (or were enabled and become disabled), thus the application of these rules depend on the application of r. the dependencies between rules are independent of the graph they are applied on, and can be derived from their definition. the analysis can be carried out using various techniques, such as graph matching and graph equivalence (critical pair analysis [hkt02]) or unification and backtracking (conditional transformation-based dependency analysis [con]), and results in a matrix of dependencies between rules. figure 8: dependency graph example the result of the analysis is used to create a dependency graph (gd , illustrated in figure 8) of the rules, where each ri is a node (ni) and there is a directed arc from ni to n j if r j has sequential dependency on ri (i.e. the application of ri may affect the match set of r j). note that dependencies introduced by nacs are taken into account as well. finally, there may be arcs in both directions between two nodes. in this paper, ni i denotes the set of nodes, which have sequential dependency on ni, while j ni denotes nodes on which ni has sequential dependency (both sets illustrated for nadds in figure 8). finally, we have a candidate transition occurrence vector (σ ) as a solution of the analysis of the pn, where σ (i) is the number of times that ri is applied during the execution. during the proc. pngt 2010 8 / 20 eceasst trajectory calculation, the number of times ri has been applied in a given path is stored in the application vector (va) as va(i). an execution path of the state space exploration is compliant with σ if va ≤ σ (the number of applications is less or equal for each rule). throughout the paper we use the difference between σ (i) and va(i) (σ(i)−va(i)) as the remaining application number of ri (#i). this number is stored as an attribute for ni in gd together with the state of ri that is either enabled or disabled in a given gts state. figure 9: gt rule application and its effects on the dependency graph 4.2 using the dependency graph for trajectory exploration the state of the gts and the dependency graph are tightly connected for a given initial graph and occurrence vector. figure 9 illustrates how the application of a gt rule affects the current graph and the dependency graph. first, the current state is depicted as the graph m (representing the current cloud configuration) and dependency graph gd . the color of the nodes (e.g. nadds) of gd represent the state of the corresponding gt rules (radds), green background for enabled, grey for disabled. the number near each node is the remaining application number (#adds = 3). in the course of trajectory exploration, the next gt rule, which is applied (radds in the example) is selected from the set of enabled rules. the application has the following effects on the graphs: (a) graph m changes according to the rule definition (here, a new s is added to cm), the new graph is illustrated as m′ (b) the #adds is modified to represent that the rule is applied (it decreases from 3 to 2) (c) gd is also changed to g′d , as #adds decreased and the applicability of gt rules may change (here radddb becomes enabled). the trajectory exploration then continues from m′ by selecting a rule based on g′d . 5 definition and calculation of cut-off and selection criteria the main novelty in our approach is taking advantage of the dependency relations between graph transformation rules using selection and cut-off criteria, which enhance the trajectory exploration 9 / 20 volume 40 (2011) towards guided trajectory exploration of gts strategy. in this section we first give an overview of the criteria types (subsection 5.1), followed by the definition of the criteria constructing building blocks (subsection 5.2). finally, we specify an algorithm for calculating arbitrary criteria over dependency graphs (subsection 5.3) and illustrate its use on the cloud configuration case study (subsection 5.4). 5.1 overview of cut-off and selection criteria our guided exploration approach uses the dependency graph as additional information to decide in which order the states of the gts are explored. in a certain state, two decisions are made regarding the next step, (a) whether the current branch is promising and should be further explored, if yes (b) which enabled gt rule should be executed to reach the next state. we define formal criteria over the current dependency graph, which are evaluated in order to support decisions: • cut-off criteria (crcut ) inspect the current state of the dependency graph and return a boolean result, which is true if further exploration of the current branch cannot lead to a goal state with a compliant trajectory. in this case, the exploration continues from another state instead of executing a gt rule in the current state. • selection criteria (crsel ) take the dependency graph and define an ordering of the enabled gt rules. a given gt rule ri is placed before another rule r j, if the execution of ri is more promising, based on the criteria and the current state, than the execution of r j. the ordering is used instead of selecting the most promising rule since the exploration may lead to a cut-off on the most promising branch. in this case the next rule in the ordering is executed. • soft cut-off criteria (crso f t ) differ from regular cut-off criteria by marking a given branch only unpromising, instead of incompatible. in this case the exploration continues from an other branch, but may return to the unpromising branch if a trajectory to a goal state is not found on other branches. 5.2 criteria building blocks in our approach, the criteria are constructed using starting point identifiers and a well-defined set of operators (i.e. building blocks), which can represent navigation over the graph edges, numerical and logical functions between subcriteria, ordering of results and quantifiers. starting points behave as operands and create a criteria together with an operator. the resulting criteria (called a subcriteria) can be also an operand to create more complex criteria. throughout the paper we refer to an operator as enclosing for the operands which it is combined with. for the definition of the criteria grammar, see appendix a. the criteria building blocks are defined in the following: starting points identify rules on which a given criteria is interpreted. trivially, selection criteria are evaluated for rules, which are enabled in the given state and their #i is greater than zero. however, cutoff criteria may be defined on rules with different properties (e.g. disabled rules or all enabled rules, regardless of #i). apart from simple starting points such as enabled rules (e), disabled rules (d), we define numerical constants (c) as starting points as well to separate them from operators. constants are proc. pngt 2010 10 / 20 eceasst used in logical and numerical functions when one of the operands is a predefined number. finally, custom starting points ([cr]) are defined when only rules with specific properties are evaluated. navigation operators describe which other nodes of graph gd should be evaluated when starting from a given node. navigation is defined over the edges between the graph nodes, and can be limited to paths of one or multiple connected edges. during evaluation, the # j for each r j reached by the navigation is summed up, except if navigation occurs in the criterion of a custom starting point, where # j is not incorporated in the total. for a given rule ri, forward navigation (ri i) returns the set of nodes to which ri has outgoing edges, while backward navigation (j ri) returns the set of nodes from which ri has incoming edges. furthermore, a given navigation operator can be used iteratively on a set of rules either for a given amount of time (limited iteration), e.g. navigating forward twice (ri i i) can be defined as ri i2. finally, a given operator can be used iteratively for as long as it is applicable (transitive iteration, ri i+). numerical functions are used when the partial evaluation results of subcriteria are combined. among the numerical operators, the addition operator (cr1 +cr2, where cri are subcriteria) is used most often for summing partial results, but subtraction (cr1−cr2), multiplication (cr1∗cr2) and division (cr1/cr2) are also usable. logical functions are also defined between two subcriteria and result in boolean values, where the result depends on the actual operator type and the subcriteria operands. for subcriteria, which have numerical results, the available operators are equals (cr1 = cr2), differs (cr1 6= cr2), more (cr1 > cr2) and less (cr1 < cr2). similarly, for subcriteria, which have boolean results (e.g. ones that use one of the operators above), the available operators are conjunction (cr1 ∧cr2), inclusive disjunction (cr1 ∨cr2), exclusive disjunction (cr1 ⊕cr2) and negation (¬cr). ordering and quantifiers are top-level binary operators for selection and cut-off criteria, respectively. ordering operators define how the numerical results from the subcriteria are returned, with either the highest result being the first (maximal operator, maxcr) or the lowest (minimal operator, mincr). for cut-off criteria, we define quantifiers to describe when the subcriteria must be true for at least one rule (existential quantifier, ∃r cr) or for every rule (universal quantifier, ∀r cr) among the rules defined by the starting point. example 4 here, we show the usage of the building blocks using several examples, both for cutoff and selection criteria, which are meaningful when dealing with guided state space exploration. in the rest of the paper, we will illustrate the evaluation of criteria using these examples and the dependency graph from our case study. non-compliant path (look-ahead) cut-off criterion when the application of any gt rule would make the current execution path non-compliant with the occurrence vector of its corresponding pn, it can be cut. this criterion does not depend on the dependency graph, and 11 / 20 volume 40 (2011) towards guided trajectory exploration of gts can be seen as the only one applied when the guidance is based on the occurrence vector. equation 1 defines the criterion using the notation introduced in this section. crcutncp : ∀r e(r) = c(0) (1) permanently disabled rule cut-off criterion the current path can be cut if there is a disabled rule, which still has to be applied based on the transition occurrence vector, but the application of any rule, which it depends on would lead to a non-compliant path. equation 2 gives the criterion with custom starting points and equally with regular navigation operators. crcutpdr :∃r j [d(r) > c(0)] = c(0) or equally ∃r (d(r) > c(0))∧(j d(r) = c(0)) (2) maximal forward-dependant application path selection criterion among the applicable gt rules at any given state of the exploration, the one with the most (transitively) dependant rule applications should be executed first (equation 3). the selection is based on calculating the effect of each applicable rule using the dependency graph and on the idea that a rule, which affects more applications should be applied earlier in the trajectory. crselm f d : max e(r) i + (3) minimal backward-dependant application path selection criterion in order to guide the exploration towards a state where one of the cut-off criteria may be applicable, the rule selection is based on calculating the remaining rule applications for backward-dependant rules (equation 4). in this case, the calculation starts from rules, which depend on the evaluated rule, therefore the result can informally described as the sum of the remaining application number for rules, which affect the same rules as the current rule. crselmbd : min j +[e(r) i] (4) 5.3 calculation algorithm for criteria in subsection 5.1, we defined selection and cut-off criteria as means to help the decision whether to explore reachable states on a given branch and which gt rules to execute if we do. these criteria are constructed from the building blocks introduced in subsection 5.2. in this section we specify the algorithm for calculating arbitrary criteria. algorithm overview first, we describe the steps of the calculation for arbitrary criteria (cr) defined using the building blocks. let us assume that at the beginning of the algorithm we have a dependency graph (gd ) where the status of the nodes (ni) is updated based on the applicability of the corresponding rule (ri) and the remaining execution number (#i) is set based on σ (i) and va(i). the overview of the algorithm (described as a function over a criterion and a dependency graph) is given in pseudocode here, while a more detailed version of the criteria evaluation algorithm can be found in appendix b: proc. pngt 2010 12 / 20 eceasst function evaluate(cr,gd ) initialize variables ln,sst,s check inconsistency of starting points in sst if starting points consistent then initialize sn with nodes satisfying s let o ← enclosing(s) . list of nodes or cut-off for all n ∈ sn do . iterate through eligible nodes initialize nc,nv,rp,rb . current and visited nodes, partial results while o 6= cr do . evaluation terminates when the applied operator is the criteria applyoperator(o,gd ,nc,nv,rp,rb,ln) . apply operator let o ← enclosing(o) . get enclosing operator end while update list or cut-off result end for return result end if end function 1. check the set of starting points (sst ) in cr to ensure that there is no apparent inconsistency (e.g. both e(r) and d(r) is used). 2. select starting point s from sst , this selection may use the first simple or custom starting point from the criteria or choose randomly. the selection method does not affect the calculation algorithm, however the selected starting point can greatly affect the required calculation steps for specific criteria (e.g. if a custom starting point would rule out the large majority of rules, the rest of the criteria is not evaluated). 3. acquire the set of nodes (sn) from gd which satisfy s (e.g. nodes for enabled rules for e(r)). if s is a custom starting point, it can be calculated with the same algorithm (starting from step 1, where s := cr) to find satisfying nodes. 4. select the next node (n) from sn and the enclosing operator (o) of s. initialize the set of current nodes (nc) including only n. 5. apply o on nc, where application is based on the type of the operator as follows: navigation operators take the current nodes and return nodes, which are reachable in the graph (in the direction defined by the operator) and are not included in the already visited nodes (nv). these nodes (nr) are added to the nv and will serve as nc in the next step (nc := nr). the #i of each ni is summed and added to the partial result (rp). numerical and logical operators are applied as implied by their definition and result in rp and boolean values (rb), respectively. ordering operators place ns in the appropriate position in the list of calculated nodes (ln). in case of maximal operator, ns is placed before the first node, which has a lower rp, and before first node, which has higher in case of minimal. 13 / 20 volume 40 (2011) towards guided trajectory exploration of gts quantifier operators decide whether crcut is satisfied based on rb. if rb is true and the quantifier is existential, the current branch is cut and other nodes are not calculated. similarly, if rb is false and the quantifier is universal, the branch is not cut. in both cases, skip to step 8. 6. if there is an enclosing operator oe for o (if o is transitive and nc 6= /0, oe := o), apply oe (continue from step 5) on nc, rp and rb (whichever exists). 7. if there is a next node (nn) in sn, continue from step 4 (i.e. calculate criteria on next node). 8. return ln for selection criteria and rb for cut-off criteria (the branch is cut if true). calculation of multiple criteria for more efficient trajectory calculation, several cut-off and selection criteria are defined as the search strategy. the combination of cut-off criteria can be seen as inclusive disjunction (if any of them are true, the branch is cut), while the combination of selection criteria is non-trivial and requires a method for merging different lists. 5.4 step-by-step criteria calculation example we illustrate the execution of the algorithm using the permanently disabled rule cut-off and maximal forward-dependant application path selection criteria using the cloud configuration case study. throughout the description of the example we refer back to the steps of the algorithm in parentheses (e.g. s4 means step 4). permanently disabled rule the calculation of crcutpdr is illustrated in figure 10 using the dependency graph of the example with selected #i for the rules and the current cloud configuration. disabled rules are depicted with light gray background (here addst and addapp), while enabled rules are drawn with green background. the formal definition of the criteria is also included below the graph with partial result rp in the bottom right corner. the definition has two starting points, which are consistent (both d, s1), thus the algorithm chooses the first one as s (depicted with bold circle, s2) then acquires sn :={addst; addapp} (s3) and selects addst as n and > as o (s4, 1. in figure 10). figure 10: example evaluation of cut-off proc. pngt 2010 14 / 20 eceasst the application of o returns true (s5) therefore the enclosing operator ∧ is applied next (s6), which means that the second operand has to be evaluated as well. the evaluation of the backward navigation operator (j ) is illustrated in 2. of figure 10, where the current nodes reached by navigation are depicted with dashed circles (addcl and addst , s5). since both #addcl and #adds is zero, the = operator evaluates to true (s6 and s5), the original ∧ operator returns true as well (s5). finally, the evaluation of the existential quantifier operator (s5) means that the rest of the nodes are skipped and the branch is cut (s8). maximal forward-dependant application path the calculation of crselm f d is illustrated in figure 11 similarly to the first example. the configuration of the cloud and the dependency graph are depicted in a different state, and the formal definition of the criteria is below the graph. as before, the first steps of the calculation algorithm select a starting point (e) from the criteria, the first evaluated node (addcl) and the enclosing operator i (s1-4, 1. in figure 11). figure 11: example evaluation of selection the nodes reached by the application of the i operator are nc := {addst; adds} (2. in figure 11), and the partial result rp is updated to 4 (s5). since the enclosing operator is the transitive navigation (s6), the i operator is used in consecutive steps on nodes in nc. first, adddb is reached and rp is updated to 5 (s5, 3. in figure 11), since addst is already in nv and no new nodes are reachable from it. next, addapp is reached from adddb and rp is updated to 6 (s5, 4. in figure 11). in the following iteration, nc is empty (no new reachable nodes), therefore the enclosing operation max is selected (s6). the application of this ordering operator puts addcl in ln (s5), then adds is selected as the next node (s7). once all the nodes are evaluated the ordered list (ln ={addcl, adds}) is returned as the final result of the algorithm (s8). it is important to note that this result circumvents a problem when the exploration would apply adds as long as possible without applying addcl first, which trajectory would not lead to a goal 15 / 20 volume 40 (2011) towards guided trajectory exploration of gts state if at least a st is required in the configuration (or in any configuration where servers have to be deployed on clusters). additional notes on criteria calculation the applicability of these criteria highly depends on the structural properties of the dependency graph. first, if most dependencies between rules are bidirectional or if the graph is almost strongly connected, the selection criteria will be less effective. furthermore, we suggest using transitive closure for path computation as a first approximation, but we believe that more sophisticated algorithms may be defined by handling cycles in the graph differently from simple paths. 6 related work the guiding of trajectory exploration based on rule dependency in graph transformation systems is quite novel idea in the field, but similar approaches are not unprecedented in a broader research scope, as described below. our trajectory exploration approach can be regarded as an extension of the constraint satisfaction problems over models (abbreviated as csp(m)) [hv10], which takes gt rules, constraints and goals and searches for solutions that are reachable from an initial model. the criteria calculation defined in our paper serves as a special solver for csp(m) by substituting regular solvers using simple breadth first search. note that our approach is explicitly designed for trajectory exploration and criteria using transformation rule dependency are introduced to increase the efficiency of the state space exploration. the approach in [eglt11] is similar to our approach as it also exploits the dependencies between gt rules with critical pairs analysis. here, graph transformation systems are enhanced with control flow as well and the dependency information helps in discovering problems, which could occur in runtime. model checking approaches to analyze graph transformation systems are similar to our approach as they also perform state space exploration. one can categorize them as interpreted approaches like [bk02, ren04, kk06], which store system states as graphs and directly apply transformation rules to explore the state space, and compiled approaches such as [sdr04, sv03, ejl06, brrs08, bs06], which translate graphs and graph transformation rules into off-the-shelf model checkers to carry out verification. groove [ren04] is a model checker over graph transformation systems. its main benefit is the ability to verify model transformation and dynamic semantics through applying ctl model checking on the generated state space of the gts. it is mainly used for modeling and verifying the design-time, compile-time, and run-time structure of object-oriented systems. augur2 [kk06] is a gts model checker that tackles the complexity associated with independent rules by condensing the entire state space into a single graph with unfolding semantics. it also provides some approximative techniques to deal with infinitely large state spaces, and counterexample-guided refinement of this abstraction. in [ke10] petri net abstraction is used for verifying graph transformation systems and investigating the reachability problem of forbidden graphs using context-free graph grammars. an important application of the method is deadlock analysis. proc. pngt 2010 16 / 20 eceasst the complete approach presented in our paper can also be regarded as a directed model checking approach as categorized by [ejl06]. they use (an ad hoc) spin encoding and heuristic search for the analysis of graph transition systems. baresi et al. [brrs08] present a model checking solution for graph transformation systems by translating gts into bogor models, which can be used for checking linear temporal logic expressions or special-purpose gt rules similar to groove and checkvml. in [bs06] graph transformation systems are analyzed using alloy and its tools, which support property checking and finding trajectories to given final states. it is common in these solutions that they store system states as graphs and directly apply transformation rules to explore the state space similar to our approach. their main difference is that they use an exhaustive state space exploration to verify certain conditions in the graph transformation system, while our approach relies on guided traversals. 7 conclusion and future work guided trajectory exploration, which is a relevant problem when analyzing graph transformation systems, uses hints to reduce the amount of states traversed when looking for trajectories. the hint is used (i) to decide whether a state is a dead-end (cut-off) and (ii) to order alternative directions to increase the efficiency of the traversal (selection). in the current paper, we defined selection and cut-off criteria for guided trajectory exploration of gts, and introduced the dependency graph, which combines gt rule dependencies and occurrence vectors. we also described an algorithm for calculating criteria consisting of navigation and computation over the dependency graph. our approach was exemplified using the cloud configuration problem. future work. we plan to specify and develop the complete guided trajectory exploration technique for arbitrary gts and evaluate its quality against exhaustive exploration techniques. we aim to support guided trajectory exploration in the viatra2 model transformation framework. we are also working on defining more sophisticated (problem-specific) criteria and specialized algorithms to increase the efficiency of the approach. bibliography [bhtv06] l. baresi, r. heckel, s. thöne, d. varró. style-based modeling and refinement of serviceoriented architectures. journal of software and systems modelling 5, 2006. [bk02] p. baldan, b. könig. approximating the behaviour of graph transformation systems. in corradini et al. (eds.), proc. icgt 2002: first international conference on graph transformation. lncs 2505, pp. 14–29. springer, barcelona, spain, 2002. [brrs08] l. baresi, v. rafe, a. t. rahmani, p. spoletini. an efficient solution for model checking graph transformation systems. entcs 213, 2008. [bs06] l. baresi, p. spoletini. on the use of alloy to analyze graph transformation systems. in corradini et al. (eds.), graph transformations. lecture notes in computer science 4178, pp. 306–320. springer berlin / heidelberg, 2006. 17 / 20 volume 40 (2011) towards guided trajectory exploration of gts [cmr+97] a. corradini, u. montanari, f. rossi, h. ehrig, r. heckel, m. löwe. in [roz97]. chapter algebraic approaches to graph transformation — part i: basic concepts and double pushout approach, pp. 163–245. world scientific, 1997. [con] condor, ct-based dependency analyzer. http://roots.iai.uni-bonn.de/research/condor/. [eglt11] c. ermel, j. gall, l. lambers, g. taentzer. modeling with plausibility checking: inspecting favorable and critical signs for consistency between control flow and functional behavior. in fundamental approaches to software engineering. lecture notes in computer science. springer-verlag, 2011. accepted. [ejl06] s. edelkamp, s. jabbar, a. lluch-lafuente. heuristic search for the analysis of graph transition systems. in proc. third international conference on graph transformation. lncs 4178, pp. 414–429. springer, natal, brazil, 2006. [hkt02] r. heckel, j. m. küster, g. taentzer. confluence of typed attributed graph transformation systems. in in: proc. icgt 2002. lncs. springer, 2002. [hv10] á. horváth, d. varró. dynamic constraint satisfaction problems over models. software and systems modeling, 2010. [ke10] b. könig, j. esparza. verification of graph transformation systems with context-free specifications. in ehrig et al. (eds.), graph transformations. lecture notes in computer science 6372, pp. 107–122. springer berlin / heidelberg, 2010. [kk06] b. könig, v. kozioura. counterexample-guided abstraction refinement for the analysis of graph transformation systems. in tacas. pp. 197–211. 2006. [mkr06] t. mens, g. kniesel, o. runge. transformation dependency analysis a comparison of two approaches. in rousseau et al. (eds.), lmo. hermès lavoisier, 2006. [ren04] a. rensink. the groove simulator: a tool for state space generation. in nagl et al. (eds.), applications of graph transformations with industrial relevance (agtive). lncs 3063. springer-verlag, 2004. [roz97] g. rozenberg (ed.). handbook of graph grammars and computing by graph transformations: foundations. world scientific, 1997. [sdr04] o. m. dos santos, f. l. dotti, l. ribeiro. verifying object-based graph grammars. electr. notes theor. comput. sci. 109:125–136, 2004. [sv03] á. schmidt, d. varró. checkvml: a tool for model checking visual modeling languages. in stevens et al. (eds.), proc. uml 2003: 6th international conference on the unified modeling language. lncs 2863, pp. 92–95. springer, san francisco, ca, usa, october 20-24 2003. [v2] viatra2 model transformation framework, an eclipse gmt subproject. http://www.eclipse. org/gmt/viatra2/. [vv06] s. varró-gyapay, d. varró. optimization in graph transformation systems using petri net based techniques. electronic communications of the easst (eceasst) 2, 2006. selected papers of workshop on petri nets and graph transformations. [vve+06] d. varró, s. varró-gyapay, h. ehrig, u. prange, g. taentzer. termination analysis of model transformations by petri nets. in proc. third international conference on graph transformation (icgt 2006). lncs 4178. springer, brazil, 2006. [wks+09] m. wimmer, g. kappel, j. schoenboeck, a. kusel, w. retschitzegger, w. schwinger. a petri net based debugging environment for qvt relations. in automated software engineering, 2009. ase ’09. 2009. proc. pngt 2010 18 / 20 http://roots.iai.uni-bonn.de/research/condor/ http://www.eclipse.org/gmt/viatra2/ http://www.eclipse.org/gmt/viatra2/ eceasst a criteria grammar definition the following is the bnf grammar used for defining arbitrary criteria: 〈criterion〉→〈cut-off〉〈selection〉〈cut-off〉→〈quantifier〉〈logical〉〈selection〉→〈ordering〉〈navigation〉〈quantifier〉→ ‘∃’ 〈rule〉 ‘∀’ 〈rule〉〈ordering〉→ ‘min’ | ‘max’ 〈rule〉→ ‘r’[a-z]* 〈startingpoint〉→〈enabled〉〈disabled〉〈constant〉〈custom〉〈logical〉→ [〈numerical〉 | 〈startingpoint〉] 〈lognumop〉 [〈numerical〉 | 〈startingpoint〉] 〈logical〉〈logbinop〉〈logical〉 | 〈logunop〉〈logical〉〈navigation〉→〈navop〉 [〈startingpoint〉 | 〈navigation〉] 〈numerical〉→ [〈navigation〉 | 〈numercal〉] 〈numop〉 [〈navigation〉 | 〈numercal〉] 〈enabled〉→ ‘e(’〈rule〉‘)’ 〈disabled〉→ ‘d(’〈rule〉‘)’ 〈custom〉→ ‘[’ [〈navigation〉 | 〈logical〉] ‘]’ 〈constant〉→ ‘c(’〈number〉‘)’ 〈number〉→ [0-9]+ 〈lognumop〉→ ‘=’ | ‘6=’ | ‘<’ | ‘>’ | ‘≤’ | ‘≥’ 〈logbinop〉→ ‘∧’ | ‘∨’ | ‘⊕’ 〈logunop〉→ ‘¬’ 〈navop〉→ [‘j ’ | ‘ i’] [‘+’ | 〈constant〉]? 〈numop〉→ ‘+’ | ‘-’ | ‘*’ | ‘/’ b evaluation algorithm the following is the pseudocode for the criteria evaluation algorithm: function evaluate(cr ,gd ) . evaluation of criteria let ln ← φ . ordered list of nodes let sst ← s : startingpoints ∈cr . gather starting points let s ← sst [1] . select first starting point for i ← 2,size(sst ) do . check all other starting points if s 6= sst [i] then . two starting point is equal, if they are of the same type let inconsistent ← true . inconsistent criteria cannot be evaluated end if end for if ¬inconsistent then let sn ← n ∈ gd|s(n)← true . gather nodes satisfying starting point let o ← enclosing(s) . get enclosing operator for all n ∈ sn do . iterate through gathered nodes let nc ← n,nv ← φ . initialize set of current and visited nodes let rp ← 0,rb ← f alse,limit ←−1,break ← f alse . initialize partial results, navigation limit and loop break signal while o 6= cr do . exit loop as the criteria on the given node is evaluated if o = limited ∧limit =−1 then 19 / 20 volume 40 (2011) towards guided trajectory exploration of gts limit ← limit(o) . set limit for limited operators end if applyoperator(o,gd ,nc,nv,rp,rb,ln) . apply operator if rp = true∧cr = cut-off ∧quanti f ier(cr) = existential then . check cut-off condition for existential return rb . terminate evaluation with cut-off else if cr = cut-off ∧quanti f ier(cr) = universal then . check cut-off condition for universal return rb . terminate evaluation without cut-off else break ← true o ←cr . force exit from loop at next check end if end if if o = limited ∧nc 6= φ ∧limit > 1 then . if further iterations are required limit ← limit −1 . decrease limit else if o 6= transitive∨nc 6= φ then . not transitive navigation or no new reached nodes o ← enclosing(o) . get enclosing operator limit ←−1 . reset limit end if . otherwise continue transitive navigation, if new nodes were reached end while if cr = selection∧break = f alse then . if the criterion is completely evaluated ln ← ln ∩(rp,n) . add result and node to list rb ← f alse end if end for if rb = f alse then if cr = selection then if ordering(cr) = min then ln ← reverse(ln) . reverse order for min end if return ln . return result list for selection else return rp . return without cut-off end if else return rb . return with cut-off end if else error . starting points inconsistent end if end function function applyoperator(o,gd ,nc,nv,rp,rb,ln) . application of an operator if o ∈ navop then . navigation functions let nr ← reach(o,nc,gd)\nv . gather reachable states from dependency graph, excluding already visited nodes for all n ∈ nr do rp ← rp + #n . update partial result with remaining executions end for nv ← nv ∩nr . update set of visited nodes nc ← nr . update set of current nodes else if o ∈ logu nop then . unary logical functions rb ← op(o) rb else let right ← evaluate(right(o),gd) . evaluate right side of criteria if o ∈ lognumop then . logical functions on numbers rb ← rp op(o) right . update boolean result with evaluated value else if o ∈ logbinop then . binary logical functions rb ← rb op(o) right else if o ∈ numop then . numerical functions rp ← rp op(o) right . update partial result with evaluated value end if end if end function proc. pngt 2010 20 / 20 introduction overview of the approach definitions example graph transformation petri net abstraction for gts definition and usage of the dependency graph graph transformation rule dependency using the dependency graph for trajectory exploration definition and calculation of cut-off and selection criteria overview of cut-off and selection criteria criteria building blocks calculation algorithm for criteria step-by-step criteria calculation example related work conclusion and future work criteria grammar definition evaluation algorithm modelling emergency scenarios using algebraic high level net transformation systems with net patterns electronic communications of the easst volume 40 (2011) proceedings of the 4th international workshop on petri nets and graph transformation (pngt 2010) modelling emergency scenarios using algebraic high level net transformation systems with net patterns frank trollmann, maximilian kern and sahin albayrak 35 pages guest editors: claudia ermel, kathrin hoffmann managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst modelling emergency scenarios using algebraic high level net transformation systems with net patterns frank trollmann, maximilian kern and sahin albayrak dai-labor, tu berlin faculty of electrical engineering and computer science frank.trollmann@dai-labor.de, maximilian.kern@dai-labor.de, sahin.albayrak@dai-labor.de abstract: emergency operations are a good case study for dynamic systems. their size and high dynamicity make modelling them a challenging task. algebraic high level net transformation systems are a well suited technique for modelling such dynamic systems. they consist of an algebraic high level net and a set of graph transformation rules. the net reflects the initial state of the operation and the transformation rules can be used to adapt this state to reflect the dynamicity of the operation. the applicability of graph transformation rules depends on the existence of a match morphism. while designing the algebraic high level net transformation system the designer has to ensure the existence of the right match morphisms for all reachable runtime states. this can be a tedious and error prone task for the designer. this paper uses a case study for modelling emergency operations with algebraic high level net transformation systems to show how the notion of net patterns can help the designer to cope with rule applicability. keywords: graph transformation, algebraic high level nets, design patterns 1 introduction it is a challenging task to model emergency operations. their complexity and the fact that the plan of the operation changes frequently at runtime can cause serious problems to the designer. algebraic high level nets (ahl-nets) are similar to petri nets but are able to handle and process data. for this reason they are a well-suited technique to model such complex workflows. an ahl-net transformation system additionally contains a set of graph transformation rules. these transformation rules can be used to adapt the ahl-net structure in order to reflect a change in the plan of the emergency operation. the applicability of graph transformation rules to an ahl-net depends on the existence of a morphism between the left hand side of the transformation rule and the net, called match morphism. while modelling the ahl-net transformation system the designer has to ensure the existence of the correct match morphisms. for this task she has to model the ahl-net and the left hand sides of the transformation rules in a way that allows for these morphisms to exist. this task can be tedious and error prone. the reason for this is the fact that the design of transformation rules and net structure are interrelated. the designer has to assure correct applicability of the graph transformation rules to all possible runtime structures. starting from an 1 / 35 volume 40 (2011) mailto:frank.trollmann@dai-labor.de, maximilian.kern@dai-labor.de, sahin.albayrak@dai-labor.de modelling emergency scnenarios using ahl-net transformations with net patterns initial net structure at start-up of the application the possible runtime structures can be reached by incrementally applying transformation rules. in this paper, we use pipeline emergency operations of the fire brigade as a case study to illustrate these problems and show how the application of design patterns for rule application, called net patterns, can be used to ease them. we first model the emergency operation without regard to rule application and show problems stemming from this approach. afterwards, we introduce and apply a net pattern to show how this technique can be used to avoid these problems. the paper is structured as follows. first, in section 2 the language of algebraic high level net transformation systems is introduced. afterwards the emergency scenario that serves as a case study for this paper is introduced in section 3. this section also describes an approach to model these scenarios without regards to rule application and the resulting problems. a description of the approach of applying net patterns is then given in section 4. section 5 illustrates how such a pattern can be applied to the case study. this approach is then compared to the first approach in section 6. section 7 concludes this paper and hints at future work. 2 algebraic high level net transformation systems this section introduces ahl-nets and ahl-net transformation systems as a foundation for the case study. for a detailed description of algebraic high level nets the reader may refer to [per95]. a detailed overview on graph transformation and related concepts can be found in [eept06]. the definitions in this section are also based on the definitions in these two references. algebraic high level nets are an extension of petri nets. they also contain places, transitions and edges between them. the main difference to petri nets is that ahl-nets are able to process data. the types of data and operations used in the net are given by an algebraic specification. the actual data and implementation of the operations is contained in an algebra over this specification. in an ahl-net tokens are identified with data elements. each place is associated with a sort of the specification and can only hold tokens of this type. transitions can be used to process these data elements. each edge is annotated with a term over the signature. this term specifies which kind of data is used and produced by the transition. a transition can additionally contain a set of equations that further constrain in which situations the transition can be fired. algebraic high level nets are formally described in definition 1. an example for an algebraic high level net is given in example 1. definition 1 (algebraic high level net ) an algebraic high level net is consists of an eight-tuple (sp,p,t, pre, post,cond,type,a), where sp = (s,op,e,x) is an algebraic specification, a is an (s,op,e,x)-algebra, p is a set of places, t is a set of transitions, pre, post : t → (top(x)⊗p)⊕ are functions denoting the set of places, connected to a transition via incoming and outgoing edges and the terms inscribed in these edges, type : p → s defines the type of each place and cond : t → p f in(eqns(s,op,x)) defines the equations for each transition. example 1 an example for an algebraic high level net is depicted on the left hand side of figure 1. this net consists of one transition compute and four places p1 to p4. the purpose proc. pngt 2010 2 / 35 eceasst figure 1: example ahl-net(left), signature (middle) and algebra (right). of the net is to do some calculations on natural numbers. for this reason the net is typed over the signature of natural numbers, containing types for natural numbers and boolean values and several operations. this signature is depicted in the center of figure 1. the signature does not contain any equations or variables. the right hand side of this figure shows the algebra that is used in the ahl-net. all places in the ahl-net are typed with nat. p1 and p2 are already marked with the numbers one and two. the terms are inscribed on each arc. according to these terms the transition compute consumes two numbers from p1 and p2 and places their product on p3 and their sum on p4. the equations associated with compute state that this transition can only fire if the number taken from p1 is odd and the number taken from p2 is even. the firing behavior of ahl-nets is similar to that of place/transition nets. in addition to requiring the correct number of tokens on the pre condition places, a transition in an ahl-net also requires the correct data elements to be available on these places. an ahl-net transition fires in combination with an assignment of the variables used in its terms and equations. based on this assignment, the terms on the pre condition edges are evaluated in order to determine the data elements required for this transition to fire. the terms in the post condition edges describe which data elements are produced by the transition. the transition can only fire if its equations are fulfilled under the assignment. a morphism between two algebraic high level nets consists of mappings between their places and transitions. these two mappings have to be consistent with the functions pre and post, the arc inscriptions, the types of the places and the equations in each transition. an exact definition of ahl-net morphisms is given in definition 2. definition 2 (algebraic high level net morphism ) an algebraic high level net morphism between two ahl-nets ni = (sp,pi,ti, prei, posti,condi,typei,a), i∈{1,2} with sp = (s,op,e,x) is defined as a tuple of morphisms f = ( fp : p1 → p2, ft : t1 → t2) : n1 → n2 such that the diagram shown in figure 2 commutes. morphisms between ahl-nets are an important concept for graph transformation on ahl3 / 35 volume 40 (2011) modelling emergency scnenarios using ahl-net transformations with net patterns figure 2: condition for ahl-net morphisms. nets. an ahl-net transformation rule is described as a span of injective ahl-net morphisms as defined in definition 3. the application of a transformation rule requires the existence of a morphim between the left hand side of the transformation rule and the ahl-net the rule is applied to. as a foundation for our transformation rules we use graph transformation in the double pushout approach. figure 3: application of an ahl-net transformation rule. definition 3 (algebraic high level net transformation rule and transformation ) an algebraic high level net transformation rule p = (l l←− k r−→ r) consists of ahl-nets l, k and r, called left-hand side, gluing graph and righ-hand side and two injective ahl-net morphisms l and r. the application of an ahl-net transformation rule p to an ahl-net g requires a morphism m : l → g. the transformation is given by two pushouts (1) and (2) as depicted in figure 3. the ahl-net h is the result of the transformation. an ahl-net transformation system consists of an initial ahl-net and a set of ahl-net transformation rules. such a transformation system is a way of describing the set of ahl nets that can be derived from applying the transformation rules to the initial ahl-net. a formal definition can be found in definition 4. definition 4 (algebraic high level net transformation system ) an algebraic high level net transformation system t s = (n,rules) consists of an algebraic high level net n and a set of ahl-net transformation rules rules. proc. pngt 2010 4 / 35 eceasst these formalisms are used in order to model the case study in the next section. 3 case study 1 : emergency scenarios the applicability of transformation rules to ahl-nets depends on the existence of match morphisms. while modelling an ahl-net transformation system the designer has to ensure the existence of the correct match morphisms between the transformation rules and all possible runtime structures of the transformation system. the complexity of this task depends on the number of transformation rules and possible runtime structures. in this section we follow a modelling approach that a designer who is not explicitly considering the applicability of transformation rules might take. after modelling the emergency scenario with this approach we concentrate on two occasions that require a transformation of the net and use them to showcase the problems in rule applicability. as a case study we use pipeline emergency scenarios. as an inspiration and source of information for these scenarios the website www.pipelineemergencies.com has been used. in these case studies, the workflow of a set of firefighters during a gas-leak operation is modelled. such a workflow consists of a set of team members executing tasks in a certain order. during these tasks, additional data can be used or produced. the large size and high number of possible runtime changes make such scenarios challenging and thus a good case study. in fact, pipeline emergencies have already been used as a case study in other publications. in [hep08] they are used as a case study for modelling with reconfigurable petri nets. [tro09] contains our previous work on this case study. in this paper, we modelled this case study using algebraic high level nets. during the modelling process, it became obvious that some kind of general structure or pattern in the ahl-nets is required in order to keep an overview in the complexity of all possible scenarios and runtime changes. the patterns, used as an example for net patterns in this paper are actually taken from the notions first presented in [tro09] and slightly altered. however, in [tro09] the focus is not on the patterns but on how emergency scenarios in general can be modelled with reconfigurable ahl-nets and how the reconfiguration can be controlled in a higher order net. higher order nets are ahl-nets that contain ahl-nets as tokens and are able to control their firing behavior and apply transformation rules. the purpose of this paper is to explicitly show problems that occurred during the design process for [tro09] and how net patterns can be used to solve these problems. for reasons of space we use a simplified version of the case study in our elaborations. we focus on a limited subset of tasks, team members and data. we distinguish between three types of team members: a firefighter, the specially trained medical personal and the team leader who leads the operation. our set of tasks contains four elements: repair gas leak, treat injured person, call reinforcements and take gas reading. we only use one type of data which is called gas reading and represents the results of a gas reading. the case study in [tro09] contains more elements. especially the set of task types is way larger. not all tasks can be executed by every team member type. the task treat injured person requires medical knowledge and can therefore only be executed by a team member of the type medical personal. a table on which of our tasks can be executed by which team member types can be found in figure 4. data types are also restricted to be available only in certain tasks. the 5 / 35 volume 40 (2011) modelling emergency scnenarios using ahl-net transformations with net patterns figure 4: compatibility of tasks with team member and data types gas reading can only be handled by the task take gas reading. tasks can be adapted to the current situation. for instance the task repair gas leak can involve an arbitrary number of firefighters and the task take gas reading may take into account a previous gas reading if available. an intuitive way to model the workflow of these emergency operations is to model each team member and data element as a token and each task as a transition. this is similar to the way this case study is modelled in [hep08] with the addition that we use ahl-nets instead of petri nets. each place of the ahl-net is typed over the team member type or data type it may hold. in our example, the set of sorts of the algebraic specification of the ahl-net contains firefighter, medical personal, team leader and gas reading. tasks may involve different numbers and types of team members and data. the corresponding transition has one input place for each team member and each used data element and one output place for each team member and each produced data element. figure 5: possible transition structures for the tasks in the running example proc. pngt 2010 6 / 35 eceasst the possible structures of transitions for our four example tasks are depicted in figure 5. the structure of the task repair gas leak of a firefighter depends on the number of firefighters that participate in this task. in order to avoid problems that may stem from an infinite number of possible structures, we assume that no more than five firefighters can participate in this task. treat injured person is only executed by the team member type medical personal and thus only has one possible structure. call reinforcements can be executed by a firefighter or team leader. for this reason two versions of this task do exist. take gas reading is executed by a firefighter and produces a gas reading. it may or may not take into account a previous reading. for this reason a second possible runtime structure exists where a gas reading is consumed and a new and updated version of the reading is produced. depending on the newly determined gas values the new reading may differ from the old reading. this is expressed by using different variables in the arcs for the produced and consumed gas reading. the restricted set of four tasks yields nine different transition structures. five for the task repair gas leak with different numbers of firefighters, one for the task treat injured person, one for the task call reinforcements (the version of this task for a firefighter actually has the same structure as repair gas leak for one firefighter) and two possible structures for the task take gas readings. one key feature of emergency operations is their dynamic nature. the plan of an emergency operation changes frequently during its execution. causes for such changes are reassessments of the situation. possible changes are changes in the overall task order like the introduction, deletion or relocation of tasks or a change in the structure of an existing task. figure 6: a model of the initial state of the application for this reason the emergency scenario is modelled as an algebraic high level net transformation system rather than just as an ahl-net. at startup the initial state of the transformation system is used as a model. this initial structure can be seen in figure 6. it contains the transitions team arrives and team leaves. these transitions represent the team of firefighters arriving at the scene and leaving after the operation is finished. the team consists of one team leader, two firefighters and one medical personal. after the scenario is started the transformation rules are used to adapt the initial net to fit the current situation. this can happen while the net is executed. figure 7 shows the net at a later state of the operation. the initial net has been extended by adding several new tasks. the team leader has already set up the command post and assessed the situation. her next task is to call for reinforcements. one firefighter has taken a gas reading 7 / 35 volume 40 (2011) modelling emergency scnenarios using ahl-net transformations with net patterns figure 7: a model of a later state of the operation while the other one evacuated the surrounding area with a medical personal. both firefighters still need to repair the pipeline leak while the medical personal has to treat an injured person she encountered during the evacuation. in order to illustrate the complexity of emergency operations this example uses more than our four example tasks. however, this example is still considered one of the smallest emergency operations. realistic scenarios involve a larger number of team members and tasks. the steps for transforming the initial net into this one and the used transformation rules can be found in appendix a. the firing of the ahl-net and the execution of transformation rules represent different dimensions of runtime dynamics. firing the ahl-net represents an execution of the operation. whenever a task is finished its transition is fired and leads to a new runtime state. the application of transformation rules represents a change in the operation. whenever the team leader requires the plan of the operation to change she triggers the execution of one or more transformation rules. their purpose is to introduce the required changes into the net. until now the intuitive approach of modelling the ahl-net has worked. the workflow of the team of firefighters can be represented. the actions of each team member can be executed and tracked. this model is a well-suited way to model a fixed operation. however, it is far from optimal for rule applicability. the remainder of this chapter serves to show the problems that occur in this area. for this task we focus on two occasions that require the transformation of the ahl-net and analyse how these changes can be achieved in this approach. the first occasion is the introduction of a new task into the workflow of a firefighter. as proc. pngt 2010 8 / 35 eceasst an example, we aim to insert the task repair gas leak into the workflow of a firefighter at an arbitrary position (after any other task). figure 8: a transformation rule for inserting the task repair gas leak after the task take gas reading a transformation rule for inserting this task after the task take gas reading is depicted in figure 8. this rule targets the task take gas reading on its left hand side, temporarily removes it and reinserts it together with the new task. this rule can only be applied where the structure of take gas reading occurs. it cannot be used to insert the task after a differently structured task. for this purpose additional transformation rules are required. in order to be able to insert this task anywhere into the workflow of a firefighter a total number of seven transformation rules is required (one for each possible task structure of a firefighter), even in our limited set of four tasks. the case study in [tro09] contains a much larger set of tasks. this shows that the designer has to define a large set of transformation rules only for the purpose of inserting one task. figure 9: a transformation rule for adding a firefighter to the task repair gas leak a second occasion for a transformation is the requirement to change the existing task repair 9 / 35 volume 40 (2011) modelling emergency scnenarios using ahl-net transformations with net patterns gas leak in order to add an additional firefighter. this is required if the leak is dangerous and an additional firefighter is needed for security reasons. this occasion also proves problematic. a rule for inserting a second firefighter into the task done by one firefighter can be seen in figure 9. this rule can only be applied if currently one firefighter is doing the task and the other firefighter is doing the task call reinforcements or a similarly structured task before he joins the task repair gas leak. again, in order to insert an additional firefighter in any situation several transformation rules are required; one for every combination of number of firefighters already in the task and previous task of the added firefighter. however, there is another problem in this transformation rule. it is also applicable to the task call reinforcements of a firefighter. the structures and place types of this task and the task repair gas leak for one firefighter are identical. ahl-net morphisms do not have to preserve the name of transitions. for this reason this transformation rule is applicable to the wrong task. these two problems can be avoided if the designer considers rule application while modelling the ahl-net. however, this also makes the modelling process much more complicated as she has to find a way to enable both correct rule application and correct execution logic of her net. the next section proposes to provide net patterns to the designer in order to ease these problems. 4 net patterns while designing an algebraic high level net transformation system the design of the initial model and the design of the transformation rules are interwoven. if the model has not been designed for easy rule application, designing rules can become a difficult task and may even involve a revision of the original model structure. however, designing an ahl-net for easy rule application is no trivial task. the fact that ahl-nets are executable and thus every change in the net also changes its execution behaviour adds to this complexity. in order to take these problems out of the hands of the designer we propose to provide her with structures she may use during the modelling process. this saves her the effort of having to come up with solutions for enabling easy rule application on her own. we call such structures net patterns. a net pattern is a subnet that has to be inserted by the designer in order to model a certain situation. this subnet may not be complete i.e. there may be parts of the net pattern where the designer is able to fill in a custom structure or define the types of certain places. this is similar to the idea of design patterns originating in the work of christopher alexander [ais77]. such patterns are available for programming languages as guidelines for modelling certain reoccurring tasks such as making a class singleton. these patterns consist of a problem specification and a description on how it can be solved in a certain programming language. we can see net patterns as design patterns on ahl-nets where the problem description is that the designer wants to model a certain situation and the solution is a description of the subnet the designer may use. net patterns can be used for several purposes. in this paper we propose to use them to ease the problems in rule application. the basic idea is to use net patterns in the ahl-net to guarantee the existence of certain structures. these structures can be targeted by the transformation rules. a good design in the patterns can ease the tasks of rule application considerably. the problems in the first case study can be solved by such patterns. this case study has two proc. pngt 2010 10 / 35 eceasst main problems. the first problem stems from the large variety of different structures of tasks in the case study. this variety leads to the problem that targeting an arbitrary task, for example in order to add another task after it, requires an impracticable large set of transformation rules. in general, this problem occurs whenever a transformation rule should be general and applicable in a large variety of places inside the ahl-net. in order to write such a general transformation rule one has to rely on the structural commonalities of the possible applications. if no such commonalities exist multiple versions of the transformation rule are required. the second problem in the case study stems from the fact that a transformation rule can be applied for any match morphism that can be found. some of these possible applications might not have been intended by the designer and thus are possible misapplication. in the first case study, a transformation rule that was intended to change the structure of one task can be applied to a different task it has not been intended for because this task has the same structure. one technique for achieving such a restriction is the use of application conditions for graph transformation rules [eh85, eehp06, hp09]. application conditions restrict the applicability of a transformation rule by restricting the surrounding context of the application. by using such conditions, additional structural requirements to the application context of the rule can be made. in normal application conditions the designer can specify which additional structures should exists in order to apply the transformation rule. there are also negative application conditions [hht95] that can be used to forbid the existence of certain structures. these application conditions have been generalized to the more expressive nested application conditions [hp05]. such application conditions also rely on the existence or non-existence of morphisms. although these application conditions considerably increase the possibilities of the designer to constrain where her transformation rule can be applied, there are still some problems that cannot be solved with these techniques. these are the cases where two alternate applications, one correct and one incorrect, are completely identical in their structure. in our example from the case study the structures of the tasks call reinforcements and repair gas leak are identical. this means even with additional application conditions they cannot be distinguished from each other on a structural basis. these tasks can only be distinguished by actively modelling them with a different structure. on the one hand, the different properties of tasks lead to so many different task structures that being able to target an arbitrary task requires an impracticable large set of transformation rules. on the other hand, the representations of some tasks have the same structure. this leads to possible misapplications of transformation rules that where meant to be applicable only for one task. these problems can be solved by introducing a net pattern for tasks. in this approach each task consists of a subnet of the ahl-net. the pattern then prescribes parts of the structure of this subnet. it contains parts that are identical for every task and parts that are specific to one task type only. this way transformation rules for generic purposes, such as the insertion, deletion or relocation of an arbitrary task, can target the parts of the pattern that are the same for all tasks while specific rules, e.g. a change that can only be applied to one task type, can target the parts that only occur in this task. in section 5 the emergency scenario is modelled with the help of such a net pattern. 11 / 35 volume 40 (2011) modelling emergency scnenarios using ahl-net transformations with net patterns 5 case study 2: modelling emergency scenarios with net patterns as stated in section 4 the modelling process of the case study can be considerably eased for the designer by the introduction of net patterns. we use a pattern that prescribes a structure for tasks done by certain team members. this pattern has to be applied on the nets algebraic specification and its ahl-net structure. the specification needs to contain all sorts and operations used in the net structure. the pattern on the specification level is based on the description of which team member type can execute which task types, defined in the case study. if this information is known the specification can be generated. the generated signature contains: • team members and data: for each team member and data type 〈tm〉 the sorts 〈tm〉, preprocessing 〈tm〉, post processing 〈tm〉 and constructing operations preprocessing 〈tm〉 : 〈tm〉→ preprocessing 〈tm〉 and post processing 〈tm〉 : 〈tm〉→ post processing 〈tm〉. • task types: for each task type 〈task〉 and all team members and data types 〈tm〉 that are allowed to execute this task the sort doing 〈task〉〈tm〉 and the constructing operation doing 〈task〉〈tm〉 : 〈tm〉→ doing 〈task〉〈tm〉. figure 10: excerpt from the induced specification of the example. part of the induced specification for the team member type firefighter and the task repair gas leak is depicted in figure 10. the specification does not require any equations and variables. based on the types and operations in this specification the net pattern for a task is defined. in addition, an algebra for the induced specification can be generated. this can be done based on an implementation for the team members and data types. for a data type of the sort tm, the implementation of preprocessing tm, post processing tm and doing task tm are exactly the same as tm for all tasks task. the operations for constructing these sorts out of the normal tm simply generate an identical piece of data. the implementations for the sorts for each team members could for example consist of the name of the team member and a set of additional attributes the left hand side of figure 11 shows the scheme for the net pattern for a task done by one team member. in order to be able to distinguish a general and a task-specific part of a task, the pattern introduces a preprocessing and postprocessing phase before and after the task. the preprocessing phase consists of the net around the transitions start preprocessing and finish proc. pngt 2010 12 / 35 eceasst figure 11: left: the pattern of places and transitions used to represent a task. right: a visual abbreviation for the pattern. preprocessing. this sub-pattern represents one team member preparing and then starting the task. similarly, the task pattern ends with a postprocessing pattern that represents the ending of the task. this pattern consists of the net around the transitions start postprocessing and finish postprocessing. a task may have multiple preprocessing and postprocessing patterns; one for each team member and piece of data participating in this task. in our general version, the core of the task is indicated by a dashed arrow. this is where the implementation of the task is inserted. here, the designer is free to model the actual implementation of the task. since the pattern contains several places and can get quite big in complex nets, figure 11 also contains a visual abbreviation for the pattern. in this abbreviation pre represents the preprocessing phase, post represents the postprocessing phase and task represents the inner implementation of a task. this abbreviation is be used in several figures to save space. the types of the places are also part of the pattern. in figure 11, diamond brackets are used as a placeholder for a certain type. for instance, the type doing 〈task〉〈teammember〉 has to be instantiated with a task name and a team member type. for the task treat injured person of the team member medical personal, the type of the places used in the inner implementation of a task is doing treatin jured person medical personal. for the net pattern all placeholders of the same name have to be instantiated with the same type. two dependent types are contained in this pattern. one represents the executing team member and the other one the executed task. the types that are used in the pattern are all part of the induced specification. these types are used to accomplish the general and task-dependent parts of a task. the general parts of the task pattern are the ones whose place-types do not contain the task name. these are the transitions start preprocessing and finish postprocessing and the places connected to them. from the point of view of one team member each task starts with a preprocessing phase and ends 13 / 35 volume 40 (2011) modelling emergency scnenarios using ahl-net transformations with net patterns with a postprocessing phase which contains these structures. they can be targeted by general transformation rules. the types of the places on the inner task structure contain the name of the task. this means that for any two different tasks the types of this part of the net pattern are different. specific transformation rules can make use of this fact. the tasks in case study 1 depicted in figure 5 can now be translated to tasks using the pattern. for each incoming arc in the transition representing the task, the pattern contains one preprocessing pattern typed over the type of the place connected to the incoming arc. for example, if the arc is typed with firefighter and the task is take gas reading the types of the places in the preprocessing pattern from start to end are firefighter, preprocessing f ire f ighter and doing take gas reading firefighter. analogous, each outgoing arc of the transition in case study 1 is modelled as a postprocessing pattern containing the according types. the core of the task can be implemented by using the task structure from case study 1, substituting the types of the places with the correct type inside of the task (for instance firefighter is substituted with doing take gas reading firefighter inside the task take gas reading) and connecting each place to the corresponding preprocessing pattern. if required, the inner structure of a task can also be modelled in a more sophisticated way by substituting this one transition with a subnet. this allows to model subtasks for each task. an example of a conversion of a task and transformation rule can be found in appendix b. figure 12: general insertion rule for the task repair gas leak. the net pattern enables a more comfortable formulation of transformation rules. figure 12 proc. pngt 2010 14 / 35 eceasst shows how the task repair gas leak can be inserted with net patterns. on its left hand side the transformation rule contains the transition finish postprocessing from our task pattern for the team member type firefighter. on the right hand side of the transformation rule the task repair gas leak is inserted after this transition. since the transition finish postprocessing is contained in the general part of our net pattern it is contained in every task of the team member firefighter. thus, this transformation rule can be used to insert the task repair gas leak anywhere in the workflow of a firefighter. this is the insertion rule that proved problematic in section 3. insertion rules can always be formulated similar to this example. the left hand side contains the transition finish postprocessing for all participating team members and used data elements. the right hand side inserts the task in its initial structure conforming to the pattern after these transitions. figure 13: a transformation rule for adding a firefighter to the task repair gas leak. the second problem in the first case study occurs when trying to add a new firefighter to the task repair gas leak. in addition to the problem of not being general enough, it is not possible to formulate the rule in a way that forbids misapplications to other tasks in the first case study. using the net patterns this transformation rule can be formulated as depicted in figure 13. the transformation rule targets one transition inside of the task repair gas leak and the finish postprocessing transition of the second firefighter. from the point of view of this second firefighter the rule works like any other insertion rule. for the first firefighter the transformation rule adds the subtask of waiting for the second firefighter to arrive before executing the already existing subtask. the transformation rule uses places of the type doing repair gas leak firefighter. according to our net pattern this type can only occur inside of the task repair gas leak of the team member type fire f ighter. for this reason the transformation rule cannot be applied to any other 15 / 35 volume 40 (2011) modelling emergency scnenarios using ahl-net transformations with net patterns task. this transformation rule solves the problems that occurred in the first case study. these two transformation rules show that the introduced patterns enable the designer to formulate more efficient and safe transformation rules. the results from both case studies are compared in the next section. 6 evaluation and related work this paper shows two ways of modelling emergency operations with algebraic high level net transformation systems. the case study in section 3 shows that an intuitive way of modelling the ahl-net can lead to problems in rule application. the second case study in section 5 uses a net pattern to model the same operations. although the net pattern leads to a larger ahl-net structure it enables efficient definitions of transformation rules. one problem that occurs in the first case study is the number of transformation rules required to insert a task anywhere in the workflow of a team member. the different structures require a specialized insertion rule for each possible task structure. even the restricted set of four tasks requires seven transformation rules in order to insert one task anywhere in the workflow of its corresponding team member. in a realistic set of tasks this number is much higher. the application of net patterns in the second case study solves this problem. in this case study only one rule is able to insert a task anywhere in the workflow for a team member type. this number is independent of the number of structures of the available tasks as long as they are modelled with the net patterns. this specific problem can be seen as an example for a class of problems where the designer wants to create a general reconfiguration rule that should be applicable in several places throughout the net. in order to do this she can rely on a net pattern in order to restrict the targeted places of application in the net to the same structure. this way this structure can be targeted in a generic rule. in order for this to work the modelled system under study should be decomposable in logical units or parts, like our tasks. the second problem in the first case study stems from the fact that some tasks have identical structures. this leads to a possible misapplication of transformation rules that should only be applicable within the scope of one specific task. again, the net patterns are able to eliminate this problem. in these patterns each task contains a unique type for its inner places. if a transformation rule uses this unique type it can only be applied to the according task. again, this problem is an example for a larger class of similar problems where the same structure in the net occurs multiple times and not all of these occurrences are considered correct applications of the transformation rule. this problem can be eased by using application conditions and restricting the possible places of application. a net pattern can explicitly force the designer to choose different structures in order to distinguish between the right and wrong places of application. in our case study we used the typing of the places in order to enforce this difference. this shows that the introduced net pattern has successfully eased the problems of the designer. if this net pattern is provided to the designer, either as a part of the modelling environment or in a descriptive way as a design pattern, this can save her a lot of time since she does not have to come up with possible solutions and validate them herself. emergency scenarios are a popular case study for showing the capabilities of modelling lanproc. pngt 2010 16 / 35 eceasst guages. their large complexity and frequent changes make them a good example to show the capabilities or problems of modelling languages. for instance, in [hep08] the application of reconfigurable systems for modelling the dynamic aspects of such scenarios is proposed and illustrated on petri nets. this work also is the foundation for [tro09] from where our net patterns originate. a different approach to modelling dynamic emergency scenarios is presented in [rm08]. in this approach the process is modelled as a questionnaire that contains decision points. this questionnaire contains all possible courses of actions in the scenario. this is another view on modelling these dynamics. instead of modelling the workflow of the team only the decisions that change this workflow are modelled. this model could, for example, be used to decide when a transformation rule is applied. basically our case study models the workflow of a team of firefighters with the special property that this workflow may change at runtime. [aww03] focuses on workflow modelling and the required perspectives on the workflow. this publication also introduces several approaches towards workflow modelling and compares them regarding their capability to model these five perspectives. in [tro09] we show that our modelling of an algebraic high level net transformation system not only covers these perspectives but also is able to cope with the changes in these perspectives that can occur during the execution of the operation. net patterns on modelling languages are an obvious extension. several authors have considered this approach in order to convey solutions to various problems. for example in [jn98] several reusable design patterns for petri nets are proposed. [ma05] proposes design patterns on colored petri nets. this work is part of the results from the workflow patterns initiative that researches patterns in process aware information systems. a collection of the patterns required in this context can be found in [vtkb03]. these references concentrate on the use of patterns for structural or behavioural properties of certain modelling languages. the use of patterns for graph transformation has also been researched. one promising approach is introduced in [avk+05]. however, this approach focuses on the use of design patterns for the formulation of graph transformation units to accomplish a certain task while we propose to also use design patterns in the targeted models for controlling the applicability of the transformation rules. 7 conclusion and future work the two case studies in this paper show the advantage of the use of net patterns. in fact, the patterns in the second case study are the result of multiple cycles of trial and error by the author of [tro09] while modelling the emergency scenarios. in order to support other designers with similar problems it makes sense to formulate the patterns as design patterns that can be reused in a similar situation. algebraic high level nets are not the only modelling language that may encounter certain problems in connection with the applicability of graph transformation rules. since this applicability is mainly determined by pattern matching it makes sense to use structural patterns to ease these problems. thus, we think the approach of design patterns for rule applicability may be of use in other modelling languages as well. 17 / 35 volume 40 (2011) modelling emergency scnenarios using ahl-net transformations with net patterns one property of morphisms that is of special use to the case study is the requirement to preserve types. the types of the places have proven to be useful in restricting where a transformation rule can be applied. on the other hand, one could argue that our patterns misuse a typing concept that has been introduced for restricting which kinds of data a place may hold. in fact, we use the types mainly for restricting where a graph transformation rule can be applied. for future work it is interesting to look into whether both concepts can be decoupled. a special kind of typing could be introduced that is only relevant for morphisms and thus can be used to restrict the applicability of graph transformation rules without influencing the structure of the model. bibliography [ais77] c. alexander, s. ishikawa, m. silverstein. a pattern language: towns, buildings, construction. oxford university press, new york, 1977. [avk+05] a. agrawal, a. vizhanyo, z. kalmar, f. shi, a. narayanan, g. karsai. reusable idioms and patterns in graph transformation languages. electronic notes in theoretical computer science 127(1):181–192, march 2005. [aww03] w. m. p. van der aalst, m. weske, g. wirtz. advanced topics in workflow management: issues, requirements, and solutions. j. integr. des. process sci. 7:49–77, august 2003. [eehp06] h. ehrig, k. ehrig, a. habel, k.-h. pennemann. theory of constraints and application conditions: from graphs to high-level structures . fundamenta informaticae 74(1):135–166, 2006. http://fi.mimuw.edu.pl/vol74.html [eept06] h. ehrig, k. ehrig, u. prange, g. taentzer. fundamentals of algebraic graph transformation. eatcs monographs in theor. comp. science. 2006. [eh85] h. ehrig, a. habel. graph grammars with application conditions. in rozenberg and salomaa (eds.), the book of l. pp. 87–100. 1985. [hep08] k. hoffmann, h. ehrig, j. padberg. flexible modeling of emergency scenarios using reconfigurable systems. formal modeling of adaptive and mobile processes. electronic communications of the easst 12, 2008. [hht95] a. habel, r. heckel, g. taentzer. graph grammars with negative application conditions. fundamenta informaticae 26:287–313, 1995. [hp05] a. habel, k.-h. pennemann. nested constraints and application conditions for high-level structures. in formal methods in software and system modeling. lncs 3393. p. 293308. internationales begegnungsund forschungszentrum fuer informatik, 2005. proc. pngt 2010 18 / 35 http://fi.mimuw.edu.pl/vol74.html eceasst [hp09] a. habel, k.-h. pennemann. correctness of high-level transformation systems relative to nested conditions†. mathematical. structures in comp. sci. 19:245– 296, april 2009. doi:10.1017/s0960129508007202 http://portal.acm.org/citation.cfm?id=1552068.1552070 [jn98] j. w. janneck, m. naedele. introducing design patterns for petri nets. 1998. tikreport no. 39, february 1998. [ma05] n. mulyar, w. m. van der aalst. towards a pattern language for colored petri nets. 2005. [per95] j. padberg, h. ehrig, l. ribeiro. algebraic high-level net transformation systems. mathematical structures in computer science 5:217–256, 1995. [rm08] m. l. rosa, j. mendling. domain-driven process adaptation in emergency scenarios. in business process management workshops. pp. 290–297. 2008. [tro09] f. trollmann. modeling emergency scenarios using algebraic higher order nets. master’s thesis, technische universität berlin, 2009. http://tfs.cs.tu-berlin.de/diplomarbeiten/tfsdipl/09-franktrollmann.pdf [vtkb03] w. m. p. van der aalst, a. h. m. ter hofstede, b. kiepuszewski, a. p. barros. workflow patterns. distrib. parallel databases 14:5–51, july 2003. a transformation of the initial net for szenario 1 the transformation from the initial net in figure 6 to the net given in figure 7 in section 3 is accomplished by using a set of graph transformation rules. this section exemplifies this transformation by showing these rules. in order to transform the initial net the three tasks set up command post, take gas reading and evacuate surrounding area are inserted after the task team arrives. the respective insertion rules are shown in figure 14, figure 15 and figure 16. each of these rules uses the task team arrives on its left hand side and inserts the structure of the respective task on its right hand side. the task set up command post is added to the workflow of the team leader whereas the task take gas reading is added to the workflow of a firefighter. the task evacuate surrounding area is added to the workflow of the second firefighter and the medical personal. this rule could actually also be applied in a second way, adding this task to the workflow of the other firefighter before the task evacuate surrounding area. the state of the net after the application of these three transformation rules is depicted in figure 17. note that this is already a valid operation. the team leader establishes a base while one firefighter has the task of determining whether there is any dangerous substance by taking a gas reading while the second firefighter and a medical personal are evacuating the area as a precaution. after taking the gas reading by firing the transition take gas reading it is determined that there is in fact a critical amount of gas in the air. according to this new information the team 19 / 35 volume 40 (2011) http://dx.doi.org/10.1017/s0960129508007202 http://portal.acm.org/citation.cfm?id=1552068.1552070 http://tfs.cs.tu-berlin.de/diplomarbeiten/tfsdipl/09-franktrollmann.pdf modelling emergency scnenarios using ahl-net transformations with net patterns figure 14: insertion rule for the task set up command post. leader has two new tasks. one task is to assess the situation by evaluating the previously taken gas reading. this task is inserted by using the transformation rule in figure 18. this transformation rule has the structure of the task set up command post on its left hand side and can therefore only be used to insert the new task after this task. in addition, the team leader has to make a call and inform the responsible authorities so they may send reinforcements if required. this task in inserted after the previous task using the transformation rule in figure 19. during the evacuation an injured person has been found. thus, the medical personal has the additional task to treat this injured person. this task is added to the operation using the insertion rule in figure 20. after adding these tasks to the operations plan the net is in a new state. figure 21 shows this new state. the previously inserted tasks have been executed thus the marking of the net has changed. in accordance with the new information gained by executing these tasks the nets structure has been changed by adding the tasks as described above. finally, it is determined that the pipeline is save enough to be repaired by one of the firefighters. however, in case of an emergency another firefighter should stand by during the repair process. this task is inserted in two steps. first, the task repair gas leak is inserted into the workflow of one firefighter using the insertion rule already given in figure 8. a second rule, depicted in figure 22 is used in order to add the second firefighter. this rule contains the previously inserted task repair gas leak and the task evacuate surrounding area of the participating firefighter on its left hand side. during the execution both tasks are deleted and reinserted. the task evacuate surrounding area is reinserted as it is while the reinserted version of the task repair gas leak now involves both firefighters. the result of the transformations is the net given in figure 7. proc. pngt 2010 20 / 35 eceasst figure 15: insertion rule for the task take gas reading. b conversion between tasks and rules from case study 1 and case study 2 since the net patterns in this example provide a structure for tasks it is possible to transform the tasks from case study 1 into tasks using these patterns. this has already been explained in section 5. this appendix serves to give an example of such a conversion and also show how a transformation rule from case study 1 can be converted into a transformation rule for case study 2. as an example for a task conversion we use the task take gas reading in the version that uses an additional gas reading as input. the structure of this task in both case studies can be seen in figure 23. during the conversion the structure of the transition take gas reading is kept. however, its two incoming arcs and connected places are substituted by a preprocessing pattern typed over the respective team member / data and task. for instance the incoming arc, connected to the place typed with firefighter is substituted by a preprocessing pattern as indicated by the encircled areas in the figure. this pattern contains the transitions start preprocessing and finish preprocessing as specified in our pattern. these transitions are connected to places of the types firefighter (outer place), preprocessing f ire f ighter (place between the transitions) and doing takegasreading f ire f ighter (the inner place connected to the transition take gas reading). similarly each outgoing edge is substituted by a postprocessing pattern. the inner structure of our task in case study 2 is the same as the task structure of case study one. this inner structure could also be redefined in order to model subtasks. for instance, the task take gas reading could be divided into the subtasks of finding the gas leak, evaluating the previous reading and taking the new reading. figure 24 shows an example for a conversion from a transformation rule from case study 1 to a transformation rule in case study 2. both rules insert the task repair gas leak in the respective case studies. in order to derive the transformation rule for the second case study from one for the 21 / 35 volume 40 (2011) modelling emergency scnenarios using ahl-net transformations with net patterns figure 16: insertion rule for the task evacuate surrounding area. first case study two things have to be done. on the left hand side the transformation rule from the first case study has the structure of the task take gas reading after which this task should be inserted. this structure is substituted in the second case study by a transition finish postprocessig from the postprocessing pattern as indicated by the encircled areas in the left hand sides of the transformation rules. the required transition is contained in the net pattern and thus is contained in the net at the end of any task of the team member firefighter. thus, the transformation rule from case study 2 is more general than the example from case study 1 since it is able to insert the task anywhere in the net. if the designer explicitly wants the transformation rule to be applied only after the task take gas reading she has to use more context in the transformation rule. for instance, she could also use the transition start preprocessing from the pattern. this transition is connected to one place typed over doing take gas reading firefighter. thus, it ensures that the transformation rule can only target this specific task. in accordance with the substitution of the left hand side the preserved places in the gluing graph and the reinserted structure in the right hand side change. in addition, the inserted task repair gas leak on the right hand side changes. while the transformation rule from the first case study inserts the task as one transition the rule from the second case study uses the task pattern. the first example in this section already showed how the structure of a task in the first case study can be converted into the patterns from the second case study. c complete signature of the second case study in the second case study the signature has been indicated as generated from the information about the task and team member relations. this appendix serves to give a complete signature for the tasks used in the case study. this signature is depicted in figure 25. proc. pngt 2010 22 / 35 eceasst figure 17: the net after the insertion of the tasks set up command post, take gas reading and evacuate surrounding area. d detailed modelling of the second case study this section shows how the models from section 3 are modelled with the patterns introduced in section 5. the initial net that is used on startup of the application is depicted in figure 26. this net corresponds to the initial net in the first case study. the task team arrives and team leaves have been modelled using the net pattern. team arrives has no preprocessing pattern and four postprocessing patterns representing the fact that during this task the four team members arrive and are available for the operation. analogous, team leaves has four preprocessing and no postprocessing pattern, reflecting the fact that the four team members leave the operation. following the same situation as in the first case study in appendix a, the three tasks set up command post, take gas reading and evacuate surrounding area are inserted. the corresponding insertion rules are depicted in figure 27, figure 28 and figure 29. each of these insertion rules uses the postprocessing pattern on its left hand side. this means that they can actually be applied after any task of the correct team member. this is different from the corresponding rules in the first case study. these rules can only be used to insert the three tasks after the tasks they use in their left hand side. this means in order to generate another execution order of tasks, more rules are required in case study 1 whereas the rules in case study 2 can be reused for this purpose. the result of the application of all three rules is depicted in figure 30. the transformation rules for the insertion of the tasks assess situation, call reinforcements and treat injured person are given in figure 31, figure 32 and figure 33. again, these insertion rules can easily be reused in order to generate other operations where the tasks are in different order while the transformation rules from case study 1 cannot. the net after the insertion of these three tasks is depicted in figure 34. the transformation rules for inserting and then altering the task repair gas leak are depicted in section 5 in figure 12 and figure 13. the first rule is a normal insertion rule. the second rule 23 / 35 volume 40 (2011) modelling emergency scnenarios using ahl-net transformations with net patterns figure 18: insertion rule for the task assess situation. figure 19: insertion rule for the task call reinforcements. actually targets the inner transition repair pipeline as well as a finish postprocessing transition of the second team member. from the point of view of the already existing team member the task is altered. a new transition that represents the arrival of the reinforcement and a transition that represents the new team member who is giving help are added. from the point of view of the added team member the rule works like a normal insertion rule, targeting the postprocessing pattern and inserting a new task. since the transformation rule targets an inner transition of the task repair gas leak it cannot be misapplied to change the structure of any other task. this transition is connected to places typed over doing repair gas leak firefighter which only occur in this task. thus it cannot be misapplied to another task. such a misapplication is possible for the corresponding rule in case study one, given in figure 22 which is also applicable for the task call reinforcements of a firefighter. the final net after the insertion and alteration of this task is depicted in figure 35. proc. pngt 2010 24 / 35 eceasst figure 20: insertion rule for the task treat injured person the generic nature of the transformation rules using the net patterns enables them to generate the set of all possible scenarios that contain the inserted tasks. 25 / 35 volume 40 (2011) modelling emergency scnenarios using ahl-net transformations with net patterns figure 21: the net after the insertion of the tasks assess situation, call reinforcements and treat injured person. figure 22: rule for adding a firefighter to the task repair pipeline proc. pngt 2010 26 / 35 eceasst figure 23: conversion of a task from case study 1 (left) to a task using the patterns from case study 2 (right). 27 / 35 volume 40 (2011) modelling emergency scnenarios using ahl-net transformations with net patterns figure 24: conversion of a transformation rule from case study 1 (top) to a task using the patterns from case study 2 (bottom). proc. pngt 2010 28 / 35 eceasst figure 25: the complete signature for case study 2 29 / 35 volume 40 (2011) modelling emergency scnenarios using ahl-net transformations with net patterns figure 26: the initial net for the second case study figure 27: insertion rule for the task set up command post. proc. pngt 2010 30 / 35 eceasst figure 28: insertion rule for the task take gas reading. figure 29: insertion rule for the task evacuate surrounding area. 31 / 35 volume 40 (2011) modelling emergency scnenarios using ahl-net transformations with net patterns figure 30: the net after the insertion of the tasks set up command post, take gas reading and evacuate surrounding area. figure 31: insertion rule for the task assess situation. proc. pngt 2010 32 / 35 eceasst figure 32: insertion rule for the task call reinforcements. figure 33: insertion rule for the task treat injured person 33 / 35 volume 40 (2011) modelling emergency scnenarios using ahl-net transformations with net patterns figure 34: the net after the insertion of the tasks assess situation, call reinforcements and treat injured person. proc. pngt 2010 34 / 35 eceasst figure 35: the transformed net in the second case study 35 / 35 volume 40 (2011) introduction algebraic high level net transformation systems case study 1 : emergency scenarios net patterns case study 2: modelling emergency scenarios with net patterns evaluation and related work conclusion and future work transformation of the initial net for szenario 1 conversion between tasks and rules from case study 1 and case study 2 complete signature of the second case study detailed modelling of the second case study using free/libre open source software projects as e-learning tools electronic communications of the easst volume 33 (2010) proceedings of the fourth international workshop on foundations and techniques for open source software certification (opencert 2010) using free/libre open source software projects as e-learning tools antonio cerone and sulayman k. sowe 17 pages guest editors: luis s. barbosa, antonio cerone, siraj a. shaikh managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst using free/libre open source software projects as e-learning tools antonio cerone1∗ and sulayman k. sowe2 1 antonio@iist.unu.edu unu-iist, macau sar china. 2 sowe@ias.unu.edu, unu-ias, yokohama, japan. abstract: free/libre open source software (floss) projects can be considered as learning environments in which heterogeneous communities get together to exchange knowledge through discussion and put it into practice through actual contributions to software development, revision and testing. this has encouraged tertiary educators to attempt the inclusion of participation in floss projects as part of the requirements of software engineering courses, and pilot studies have been conducted to test the effectiveness of such an attempt. this paper discusses two pilot studies with reference to several studies concerning the role of learning in floss projects and shows how using floss projects as e-learning tools has a potential to increase the quality of the software product. keywords: oss development; education; pilot studies; knowledge exchange; elearning; software quality 1 introduction over the last years free/libre open source software (floss) communities have proven themselves to be able to deliver high-quality system and application software. although floss communities consist of heterogeneous groups of independent volunteers, who interact but are driven by different interests and motivations, and may appear to an external observer chaotic or even anarchic, they actually have specific organisational characteristic [muf06]. these characteristics have been identified and analysed through empirical studies, which highlighted the implications of the floss phenomenon throughout the information, knowledge, and culture economy, in a multidisciplinary context that goes well beyond software development [muf06, ben02]. benkler [ben02] goes even further and suggests reasons to think that peer-production may outperform market-based production in some information production activities in which a pervasively networked environment plays a major facilitating role. the generality of benkler hypothesis makes it suitable to be applied to an educational context [fut06] education has been showing during the last years multifaceted signs of crisis which affect all levels from primary to tertiary: diminishing academic achievements, increasing number of dropouts, teacher shortages and collapse of education reforms. a workshop held at bagnols, ∗ correspondence author: antonio cerone. email:{antonio@iist.unu.edu}. address: unu-iist, p.o. box 3058, macau sar china. tel: +853 2871-2930, fax: +853 2871-2940 1 / 17 volume 33 (2010) mailto:antonio@iist.unu.edu mailto:sowe@ias.unu.edu floss project as e-learning tools france, attended by educational practitioners, technologists, brain scientists and cognitive psychologists has identified factors in the current crisis in education and examined the potential uses of innovative technologies to support education [ts03]. two important conclusions of the bagnols workshop are that education must be learner-centred and that learning must be social and fun [ts03]. learners are no longer comfortable with traditional modes of education, in which information is presented linearly, mostly in a text-based way, with almost no activities aiming to put acquired knowledge into real-life practise. this has created a mismatch between modes of education adopted by schools and universities and modern living style. in fact, nowadays information is presented to the public in daily life throughout multiple streams and multiple modalities simultaneously. the internet provides a richer, much more frequently updated and more appealing source of information than printed newspapers, magazines and books. moreover, information on the internet is multi-modal and is organised in a tree-like or even graph-like structure rather than linearly. this allows learners to quickly navigate towards the targeted information in a way that appears to them more similar to pure entertainment than to academic work. social relationships have been also heavily affected by the internet: social networks, such as facebook, allow individuals geographically distributed and with different cultural backgrounds to become friends, participate in online activities and games, join discussion fora and even establish romantic relationships. floss communities seem to have many characteristics that match the way information is best received by nowadays learners. they provide that sort of virtual world in which we often carry out our social and free-time activities. moreover, floss communities are natural instantiations of commons-based peer-production [ben02, ben07], the model of economic production in which the creative energy of large numbers of individuals is remotely coordinated, usually through the internet, into large, meaningful projects mostly without traditional hierarchical organisation. individuals participate in peer-production communities not just because of extrinsic motivations, such as solve problems, improve technical knowledge base, increase reputation and peer recognition and pass examinations, but also, and probably mainly, for a wide range of intrinsic reasons: they feel passionate about their particular area of expertise and enjoy self-satisfaction from sharing their knowledge and skills; they revel in creating something new or better; they have a personal sense of accomplishment and contribution and a sense of belonging to a community [muf06, tw06, cs08]. floss communities are therefore an ideal platform to implement learner-centred education in a social and fun manner, as envisaged by the bagnols workshop, using the peer-production model, which has recently been taken as the basis on which to build new approaches to education [fut06]. although this approach can be potentially applied to any level [fut06] and field of education [mgs09], this paper focuses on software engineering (se) undergraduate and postgraduate courses [kho09, ssd06, jø07]. application of floss learning approaches to software engineering education is also a way of implementing the suggestion of the joint ieee/acm cs undergraduate curriculum guidelines [iee04] that cs curricula should have significant real-world basis necessary to enable effective learning of software engineering skills and concepts. all previous work in analysing learning aspects of floss communities emphasises the benefits that the exploitation of such aspects may have on the educational process. in our work we also aim to identify the benefits that the explicit linkage of a floss project to a formal education proc. opencert 2010 2 / 17 eceasst programme, such as a software engineering course or postgraduate research activity, brings to the floss community itself and, in the end, to the quality of the floss product. in section 2 we consider recent work that explores the link between floss approaches and education [fut06]. floss communities are analysed as collaborative networks and communities of practice to extrapolate the learning process that facilitates the emergence and evolution of community members’ knowledge [mgs09]. challenges in adapting and transferring such a learning process to an educational setting are discussed. section 3 considers two research frameworks and corresponding pilot studies conducted to empirically analyse the use of floss communities for formal education in software engineering at undergraduate [sow08, sta09, sgg, ssl06] and postgraduate [jø07] levels. the two approaches are discussed with respect to the student’s degrees of freedom (section 3.3) and topical focus (section 3.4). the proposal of a third pilot study [cs08] more ambitiously aims to operate changes into the structure and organisation of the floss community to facilitate the use of innovative methodologies, such as formal methods, in which to involve students. in section 4 we show, with respect to shaikh and cerone’s framework for evaluating quality of open source software (oss) [sc09], that the usage of floss projects as e-learning tools has the potential to increase the quality of the floss product. 2 the role of learning in floss communities one important attempt to identify a general link between floss approaches and educational agendas is a 2006 report [fut06] that looks at floss as a cultural phenomenon and aims to extrapolate new approaches to teaching and learning and to define new models of innovation and software development in education. drawing on benkler’s work on commons-based peerproduction [ben02] the report discusses strengths and weaknesses of floss approaches which might apply to educational settings. then it focuses on two ways in which peer-production floss-like approaches may be used in teaching and learning: collaborative network that is network that consists of a variety of entities that are largely autonomous, geographically distributed and heterogeneous in terms of their operating environment, culture, social capital and goals, but nevertheless collaborate to better achieve common or compatible goals and whose interactions are supported by computer network [ca06]; community of practice that is a group of people who share an interest, a craft, and/or a profession, which can evolve naturally because of the members’ common interest in a particular domain or area or can be created specifically with the goal of gaining knowledge related to their field [lw91]. distributed collaborative networks provide a powerful platform in which, due to the mediation of digital technology in a virtual environment, the duality teacher-learner fades out, and the two roles of teacher and learner merge together into the generic role of actor within the participatory culture of the network and its informal learning spaces [fut06, mgs09]. from the learner’s perspective, this enables the full range of potential intrinsic reasons mentioned in section 1 to become actual motivations and to urge learners to play, alongside with teachers, their common 3 / 17 volume 33 (2010) floss project as e-learning tools role as actors in the community’s activities. in addition, floss communities are characterised by the freedom with which actors choose projects as well as the total control that actors have on the degrees of their own contribution to the project. freedom and equality of participants constitute a “democratic” basis for analysing floss communities as communities of practice. novices are always welcome by floss communities, in which they undergo through a gradual process of social integration and skill development that allows them to earn a reputation as reliable developers and then move towards the leading positions in the community [tuo05]. floss communities are in this sense open participatory ecosystems [mgs08, mgs09], in which actors create not only source code but a large variety of resources that include the implicit and explicit definitions of learning processes and the establishment and maintenance of communication and support systems. furthermore these resources are made visible and available to other actors. therefore development (source code), support (tools) and learning (knowledge) emerge as the product of a continuous socialisation process in a virtual environment. development of source code is enabled by building up knowledge about already produced code, through direct observation, review, modification as well as discussion with other actors, and about support tools, through direct interaction as well as access to documentation and discussion with other actors. as suggested by sowe and stamelos [ss08a] the learning process of individual actors can be divided in four phases through which knowledge evolves. we give our slightly different characterisation of such phases as follows: socialise by implicitly sharing knowledge; externalise tacit knowledge by making it explicit to the community; combine community explicit knowledge and organise it as abstract knowledge; internalise abstract knowledge by absorbing it and combining it with own knowledge and experiences to produce new tacit knowledge. the four phases are not fully sequential but overlap in a certain measure, as shown in figure 1. in particular, socialisation, after playing the role to initiate the learning process, is still active during the other phases for which it is actually the enabling factor. if we want to transfer the learning process occurring within floss communities to an educational setting, we need to better understand the cognitive aspects of the four phases above and interpret and implement them in a context driven by educational goals rather than just by software development. socialisation does not require an education-oriented interpretation and is probably the easiest phase to implement in an educational setting. in fact, socialising in a virtual environment, specifically through the internet, already permeates our daily life and specific mechanisms and tools used by floss communities, such as discussion fora, are general enough to be used for educational purposes; moreover, there are already several specific, and even more sophisticated (i.e. supporting multi-modal interation) e-learning tools and environments [imm] that implement socialisation, such as moodle [moo] and second life [sec]. externalisation naturally occurs in an implicit way through socialisation tools such as discussion fora, but needs to be addressed by knowledge-management tools, such as repositories, to be effectively implemented in an explicit way. tools used to manage and organise knowledge proc. opencert 2010 4 / 17 eceasst phase 1 socialise � � � � phase 2 externalise ? phase 3 combine @ @ @ @r phase 4 internalise 6 figure 1: learning process of individual actors in floss communities within floss communities are often a challenge for the novice and actually require the user to go through a learning process before using them. although this may be acceptable in a context purely driven by software development, in which skill in quickly acquiring familiarity with new tools may be considered a reasonable pre-requisite to enter the community, and may be even seen as a parameter to naturally select skilled contributors, the situation is totally different in an education-driven context. in such a context going through an heavy learning process to be able to use learning tools is definitely unacceptable. therefore, existing tools have to be made more usable while more appropriate tools have to be developed to effectively implement externalisation in an educational setting. externalisation is also intimately related to the intrinsic motivations of the user in joining the community and contributing to it. intrinsic motivations, such as • feel passionate about particular area of expertise, • enjoy self-satisfaction from sharing knowledge and skills, • have a sense of belonging to a community, are all strong drivers for externalisation. there are also a number of extrinsic motivations that contribute to externalisation, which include • solve particular technical problems/needs by exploiting linus’ law: “given enough eyeballs, all the bugs are shallow” (from linus torvalds); • public visibility to increase reputation and and peer recognition. combination of knowledge is incremental and consists of two main activities: • multiple interactions with knowledge-management tools as well as with other members of the community to identify and extract relevant bits of explicit knowledge; • combination and organisation of such bits of explicit knowledge to produce meaningful abstract knowledge. 5 / 17 volume 33 (2010) floss project as e-learning tools the interaction with knowledge-management tools presents the same challenges as discussed for the externalisation phase. organisation of explicit knowledge and production of meaningful abstract knowledge are cognitive activities within the ambit of knowledge representation. several alternative theories have been proposed in cognitive psychology to explain knowledge representation within the human mind, but it is beyond the scope of this paper to deals with such theoretical aspects. from a pragmatic point of view we can say that the way individuals combine explicit knowledge is affected by the accessibility, structure and presentation of the contents of such knowledge and by own personal learning attitudes. knowledge-management tools have therefore to address this issues as well as to enable individuals to have more control and responsibility for their learning [gfr+05]. internalisation of knowledge is a cognitive activity which is driven by both intrinsic and extrinsic motivations. intrinsic motivations for internalisation are: • revel in creating something new or better; • have a personal sense of accomplishment and contribution. extrinsic motivations for internalisation are: • improve technical knowledge base; • pass examinations; • develop the solution to a technical problem. we will discuss in section 3.4 how the grading approach utilised by the lecturer affects these extrinsic motivations and may create conflicts with intrinsic motivations, thus leading to a partial inhibition of internalisation. internalisation is also facilitated by the efficacy and usability of code analysis tools such as bug trackers. we will also discuss in section 3.3 that limiting the degrees of freedom of students in participating in floss projects may produce community members with little extrinsic motivations, with negative consequences for both the externalisation and internalisation phases of their learning process. 3 frameworks and pilot studies in se education the joint ieee/acm cs undergraduate curriculum guidelines [iee04] suggest that cs curricula should have significant real-world basis necessary to enable effective learning of software engineering skills and concepts and should incorporate capstone projects. although many efforts have been made to involve students in software projects in local companies, most companies are not willing to sacrify their products to students who are constrained to complete the assigned work in one semester [alz05]. in this scenario the bazaar of learning offered by floss projects represents a meaningful alternative learning context to expose students to real-world software development activities [ssd06]. characteristics and evolution modalities of floss communities have been largely studied empirically by extracting data from repositories and performing statistical analysis on such data proc. opencert 2010 6 / 17 eceasst [sii07]. however, learning aspects cannot be easily captured using this research methodology due to the absence of related information inside repositories. in this section, we focus on software engineering education and survey studies aimed to explore the use of floss projects as e-learning tools. during the last decade the floss development model has deeply changed the way we develop and commercialise software, affecting traditional software development methodologies and posing serious challenges to commercial software industry. students are strongly attracted by this new software development paradigm and enthusiastically join floss projects. at the same time software industry is more and more including oss skills and knowledge among their hiring selection criteria [lon08]. this new scenario, in addition to the fact that floss projects are actually software engineering practice, has made software engineering the most appropriate teaching subject to test the educational capabilities of floss projects and has encouraged tertiary educators to attempt the inclusion of participation in floss projects as part of the requirements of software engineering courses. several pilot studies have been conducted to test the effectiveness of such an attempt and to assess the feasibility of full-scale studies. 3.1 undergraduate education pilot study a pilot study conducted by sowe and stamelos [ss08b] addressed the open question as to whether the floss methodology can be used to teach software engineering courses within a formally structured curriculum. the study was based on a pilot programme to teach software testing [ssd06] and aimed to develop and test a research method [ss08b] and to develop an approach to evaluate student participation [ssl06]. within a pool of 150 undergraduate students enrolled in a course of “introduction to software engineering” at aristotle university, greece, 15 joined the programme and 13 of them completed it. the study consisted of three phases in which students: 1. received lectures on floss-related topics, browsed projects and selected one of them; 2. participated in the selected project with the aim to find and report bugs, and possibly fix them; 3. were evaluated and graded by the lecturers. the study made use of two surveys in which students showed their interest in continuing their participation in the project after graduating. student were actually forwarding responses from their projects to the lecturers after the pilot programme was ended and student grades published. this is a clear evidence that floss projects can involve students in a long-term participation, which is in line with the need for life-long learning experiences, typical of a discipline in exponentially rapid evolution as is software engineering. 3.2 postgraduate education pilot study jaccheri and østerlie [jø07] use an approach for teaching master level students in which students are given assignments for which they have to 7 / 17 volume 33 (2010) floss project as e-learning tools • survey literature on oss development and formulate one or more research question(s) that could be addressed by participating in a project; • select an oss project which is appropriate for the assignment and the formulated research questions; • act as developers in the selected project; • act as researchers in the selected project by addressing the formulated research questions. this approach has been used since 2002 by the software engineering group (su) [con] of the department of computer and information science (idi) at the norwegian university of science and technology (ntnu). jaccheri and østerlie report on a concrete study based on this approach, in which one master student was requested to participate in a commercially controlled oss project, the netbean open source project, to understand how firms can benefit from using oss [jø07]. more specifically, the student was asked to determine how the use of software engineering techniques, such as explicit planning, ownership, inspection and testing, affects the oss project. within the scope of the assignment, the only constraint was to use action research (ar) [dmk04] as the methodology for the study. this study raises important considerations about the degrees of freedom given to the student. while students appreciate freedom in assignments as a positive learning experience, the authors recognise, as a result of the evaluation of their work by industrial professionals as well as discussions with other researchers, that it would have been more effective from a research perspective to provide students with predefined research questions. in the particular case study that they reported research questions were about the interaction between professionals and volunteers; this required the selection of a project in which commercial actors actively play significant roles. in an alternative research framework the project could have been selected before formulating the research questions. in an even more constraining framework the selection of the project could even been made by the lecturer. 3.3 student’s degrees of freedom the degrees of freedom given to students is an important issue in both studies. in the first study [ss08b] undergraduate students joined the programme on a volunteer basis and had full freedom in selecting the project; given that the course was specifically about software testing, the assignment generically asked to find and report bugs, and possibly fix them. in the second study [jø07] postgraduate students had full freedom in formulating research questions, but were constrained in selecting the project by their own choice of research questions. one of the main reasons for the success of floss projects is to be based on communities of volunteers who are totally free in choosing the way of contributing both in terms of tasks and time commitment. intrinsic reasons are fundamental in motivating active and effective participation in a floss project. forcing the injection of actors who partly or entirely lack intrinsic motivations but are requested to play an active role in the community would not produce effective learning in those actors and may even be detrimental to the whole floss project community. we have seen in section 2 that the phases of learning that are heavily dependent on intrinsic motivations are externalisation and internalisation. these two phases include important cognitive activities proc. opencert 2010 8 / 17 eceasst and their incomplete actuation, as in case of lack of intrinsic motivations, severely inhibits the whole learning process. it is therefore essential to preserve the volunteer-based approach while using participation in floss projects for educational purposes, as it was done in the pilot study conducted at aristotle university. in general, for undergraduate courses, we would suggest not to include participation in a floss project as a course requirement unless the course is a very focussed elective. for postgraduate students, participation in a floss project may be either related to a course or to a final thesis or project work. in general, it is expected that postgraduate students have more focussed interests and a higher degree of maturity than undergraduate students. in this perspective, a postgraduate student who has chosen an elective course or a thesis topic which requires participation in a floss project is supposed to have sufficient intrinsic motivations to succeed in the task. the issue of the project selection is a very subtle one. in both pilot studies described above the project selection is left to the student, although some general selection criteria are provided. however, in the pilot study conducted at the norwegian university of science and technology the selection of the project strongly depends on the research questions previously formulated by the student. the fact that the student has chosen a specific research question does not exclude that such research question may rule out all projects in which the student is likely to be enthusiastically interested. in this sense a research framework in which the project is selected before formulating the research questions is more sensible. in general, in designing the study research framework it is essential to ensure that there are no requirements for the student that may explicitly or implicitly reduce the student’s degrees of freedom in choosing the project. 3.4 student’s topical focus in the two pilot studies described in sections 3.1 and 3.2 the student’s topical focus in participating in the project was dictated by the assignment. in the pilot study conducted at aristotle university the student had to find and report bugs, and possibly fix them. the grading system included marks for email exchange with the lecturer concerning the project, proper use of bug tracking system or bug database and testing activity measured by the number of bugs found, reported and fixed, and by the number of replies to the reports. this restricted focus has probably worked as an extrinsic motivation that prevented students from contributing to the project in terms of software development, for which there was no mark. as a result students probably felt that the effort needed to fix bug was not sufficiently rewarded in terms of marks. this hypothesis is confirmed by one outcome of the study: although students performed well in finding and reporting bugs, they did not well in fixing bugs [ssl06]. it is inevitable that the grading and evaluation approach strongly affects student’s extrinsic motivations: the more transparent and explicit the grading approach the stronger the effect on extrinsic motivations. a grading approach that has a strong effect on extrinsic motivations does not allow students to achieve a complete involvement in the project and often causes a conflict with intrinsic motivations, which are an essential driver in floss project. such a conflict may result in an incomplete actuation of the internalisation phase of the learning process, which depends on both intrinsic and extrinsic motivations, and may inhibit potential learning capabilities of the student. 9 / 17 volume 33 (2010) floss project as e-learning tools however, avoiding such a strong effect is not easy in a formal education context. quantifying the evaluation of the participation in the project as a whole with no further details would not be a feasible solution. such a solution would be clearly against usual university policies that require lecturers to make the grading approach public by quantifying each contribution in terms of percentage of the final grade. moreover, limiting the information about the assessment procedure that is provided to students would be inherently unfair and might promote suspicion among students. and in the end, this would actually reduce extrinsic motivations of students. possible solutions to the problem could be that lecturers • evaluate the participation in the project indirectly by assessing a written report and publish details of the grading of such report; • discuss beforehand the grading approach with the students and agree on the details with them; • provide alternative assessment and/or grading approaches among which the students may choose; • develop an appropriate peer assessment approach. these proposed solutions are neither exhaustive nor mutually exclusive. in the pilot study conducted at the norwegian university of science and technology, which involved postgraduate students, the student’s task was not only to actively participate in the project, but also to use such participation to address research questions previously formulated. this is an interesting attempt to involve learners in studying and possibly improving the floss development process, that is, studying and possibly improving the learning tool (i.e. the floss project) they are using. in the norwegian study the student’s focus was on management and organisational aspects of software engineering. there are other aspects of software engineering in which students, especially postgraduate students, may contribute, through their participation in a floss project, to provide new insight in relation to the floss approach. one of these aspects is quality assurance. the lack of central management in floss projects makes it difficult to define a standard that could suggest indicators of the technical rigour used by a distributed community of volunteers and identify the human processes involved in the project [mic05, mhp05]. without precise indicators of this sort we cannot produce an effective quality assurance methodology for the released software. zhao and elbaum [ze00] conducted a survey to examine the factors underlying quality assurance methods used within floss communities and found out that their general attitude and practices towards quality and realising quality assurance practices are somewhat different to those prevalent in traditional software development. this situation opens a lot of research questions which could be addressed in studies conducted by postgraduate students through their involvement in floss projects. in section 4 we will further discuss the impact that such involvement could have on the quality of floss products. postgraduate students are often exposed during their study to innovative software design and analysis technologies that enjoy little appreciation outside the academic world, either because such technologies are not mature enough to be applied to practical projects or because, in an industrial perspective, their cost prevail on the actual benefit they bring. formal methods are proc. opencert 2010 10 / 17 eceasst one of such innovative technologies. postgraduate students could bring new insights in floss communities through the application of new specification and verification technologies such as formal modelling, model-checking and theorem-proving. this would require students to reverse engineer floss code into a formal model and apply formal techniques to analyse the model. unfortunately most floss developers are unlikely to be familiar with formal methods and probably view them with a similar reluctance as does the industrial world. feeding results of formal analysis back to the floss project would be therefore a big challenge for the students. here a soft approach would be needed: outcomes of formal analysis should be mapped back to code and test cases before been presented to the community. to this purpose, formal modelling techniques that provide counterexamples when a required system property is proven not to hold, such as model-checking, are the most appropriate. besides the soft approach, it would be important to include in bug reports some information about the formal results that led to the bug identification. in this way, students would play the role of educators in their interaction with floss developers, so fostering a gradual acceptance of new technologies by the floss communities. an alternative approach to promote the use of formal methods in the floss community is a pilot project proposed by cerone and shaikh [cs08] as an attempt to explicitly introduce formal methods in the floss development process. the most difficult task in this attempt is to preserve the intrinsic freedom that characterises contributions by the volunteers who join floss projects. in fact, it would not be acceptable, and neither would it be accepted by the floss community, to explicitly enforce the use of a specific formal modelling framework to be adopted by all project participants. in order to support open participation and, consequently, bottom-up organisation and parallel development, the project should therefore introduce and present formal methods only as a possible but not mandatory option available to the contributors. this approach would require an additional effort by the project leader team in facilitating the integration of those contributions that do not make any use of formal methods into the new development model. an important role would be played here, once again, by postgraduate students called to reverse engineer code, produced by other actors in a traditional floss way, into changes and extensions to the formal model. 4 impact on the quality of floss products we have seen in section 3 that students can successfully use floss projects as e-learning tools and gain effective learning of software engineering skills and concepts from participating in floss project. we have also seen that students, and in particular postgraduate students, can produce important contributions to the evolution of the floss development model. in this section we investigate how such contribution can actually have impact on the quality of floss products. shaikh and cerone [sc09] have identified some factors that are unique to the floss development process and influence the entire software development process and, consequently, the quality of the final software product. in their work, shaikh and cerone also define an initial framework in which such factors can be related to each other and to the quality. in particular, they distinguish three main notions of quality in the context of floss development quality by access which aims to measure the degrees of availability, accessibility and readabil11 / 17 volume 33 (2010) floss project as e-learning tools ity of source code in relation to the media and tools used to directly access source code and all supporting materials such as the documentation, review reports, testing outcomes, as well as the format and structural organisation of both source code and supporting materials. quality by development which aims to measure the efficiency of all development and communication processes involved in the production, evolution and release of source code, its execution, testing and review, as well as bug reporting and fixing; quality by design which corresponds to the traditional notion of software quality [iee99, pre00]: the end quality is judged by the design and implementation of the actual software and the code that underlies it. quality by access would greatly benefit from the use of formal methodologies by postgraduate students participating in the project. the reverse engineering of floss code into formal models improves understanding the system architecture and the structure of code and leads to the production of better documentation. a by-product of the reverse engineering process is also the identification of inconsistencies and redundancies in the code and, as a consequence, its improvement with an increase in readability. formal verification techniques produce results that are more general and understandable than the ones obtained using traditional testing techniques. moreover, these results can be tracked back to the model, facilitating the fixing of bugs. we have seen in section 2 that availability and usability of knowledge-management tools is essential to enable the externalisation phase of the learning process. the development of new tools and the improvement of usability in existing tools with the aim to address the learning process in floss communities is therefore likely to increase quality by access. quality by development is an attempt to measure the efficiency of all processes aiming to produce and review code and the interaction between them. shaikh and cerone [sc09] identifies five factors on which this notion of quality depends: • precise and explicit understanding of software goals and requirements; • choice of methodologies for testing, debugging and error and bug reporting; • choice of programming languages and development environments; • tools to provide effective communication, coordination and overall management of the project; • facilitation of rapid frequency of beta releases. we observe that the usage of floss projects as e-learning tools has the potential to affect these factors in a way that increases quality by development. first we observe that an additional effect of reverse engineering floss code into formal models is the explicit definition of software requirements. second, we believe that if methodologies, programming languages and tools are chosen having in mind not only their usage in software development but also their educational values, then there is a positive impact on the entire project community and, as a result, an additional benefit for the development process. third, the frequent injection of students with short proc. opencert 2010 12 / 17 eceasst deadlines to complete their assignments may facilitate rapid frequency of beta releases. finally, empirical studies such the one presented in section 3.2 can produce a better insight in how these factors interact with each other and affect each other in the global context of the project management and organisation. quality by design, the traditional notation of quality, can be seen in the floss context as a specific measure of • the use of recognised software design notations, formal notations and analysis techniques to provide correctness with respect to explicitly desired safety, security and non-functional properties, and • the production and frequent update of appropriate and explicit documentation that helps both the users and future developers. we have seen in section 3.3 that student participation can bring innovative software design and analysis technologies, such as formal methods, into floss projects, thus increasing the community knowledge and, on the long term, increasing the acceptance of these technologies within floss communities. moreover, pilot projects aiming to explicitly incorporate these technologies in the floss development process [cs08] could show whether or not there is an effective increase in quality by design. as for documentation, it is likely that student participation would increase its production, since written reports to document code production and performed analysis are a common form of assignment. finally, as we have anticipated in section 3.3, postgraduate students may contribute, through research-driven participation in a floss project, to identify quality indicators and define quality metrics appropriate for the floss development model. 5 conclusion and future work in this paper we have considered recent work that explores the link between floss approaches and education and described the dynamics of the learning process that facilitates the emergence and evolution of community members’ knowledge. we have then considered two pilot studies conducted to empirically analyse the use of floss communities for formal education in software engineering, discussed choices made in designing the research frameworks for the two studies and proposed suggestions to improve the frameworks to better match the student’s learning process. finally, we have shown that the use of floss projects as e-learning tools has a potential to increase the quality of the software product. this research has been conducted as a preliminary analysis towards the objective of building a worldwide university network, coordinated by the united nations university (unu), to implement the use of floss projects as e-learning tools in software engineering postgraduate education. a first step in our future work is to design a framework, which incorporates the recommendations we presented in section 3, for geographically distributed pilot studies in which students • are totally free in the choice of the floss project; 13 / 17 volume 33 (2010) floss project as e-learning tools • are evaluated using a grading approach that is not likely to weaken their intrinsic motivations and that possibly strengthen their extrinsic motivations; • are requested to participate in the project they have chosen but are totally free in choosing the form of participation; • may have various levels of time commitment, which correspond to distinct numbers of credits; • may choose, on a volunteer basis, a focus for their participation in the project among different topical areas such as code development, review, testing, reverse engineering, formal analysis; • may choose, on a volunteer basis, a research topic concerning the investigation of the floss phenomenon, which may include learning, project management, communication, social aspects, software quality, etc. a second step is the creation of pilot projects in line with cerone and shaikh proposal [cs08], with academics and former students who have taken part in the pilot studies of the first step, being part of the leader team. the final objective is to build a postgraduate e-learning programme in oss approaches to software engineering as part of the new unu postgraduate programmes, and utilise some of the most successful pilot projects as e-learning tools within such a programme. bibliography [alz05] z. alzamil. towards an effective software engineering course project. in proceedings of the 27th international conference on software engineering. pp. 631–632. acm press, 2005. [ben02] y. benkler. coase’s penguin, or, linux and the nature of the firm. the yale law journal 212:369–446, 2002. url: http://www.yalelawjournal.org/images/pdfs/354.pdf. [ben07] y. benkler. the wealth of networks: how social production transforms markets and freedom. yale university press, 2007. [btd05] j. m. barahona, c. tebb, v. dimitrova. transferring libre software develoment practises to the production of educational resources: the edukalibre project. in proceedings of the 1st international conference on open source systems (oss2005). genova, italy, 11–15 july 2005. [ca06] l. m. camarinha-matos, h. afsarmanesh. collaborative networks: a new scientific discipline. journal of intelligent manufacturing439452, 16:439–452, 2006. [con] r. conradi et al. software engineering group homepage. norwegian university of science and technology (ntnu). url: http://www.idi.ntnu.no/grupper/su/. proc. opencert 2010 14 / 17 http://www.yalelawjournal.org/images/pdfs/354.pdf http://www.idi.ntnu.no/grupper/su/ eceasst [cs08] a. cerone, s. a. shaikh. incorporating formal methods in the open source software development process. in proceedings of the opencert and floss-fm 2008 joint workshop. unu-iist research report 398. 2008. [dmk04] r. m. davison, m. g. martinsons, n. kock. principles of canonical action research. information systems journal (isj) 14(2):65–86, 2004. [fut06] futurelab. the potential of open source approaches for education. opening education report. published online, 2006. url: http://www.futurelab.org.uk/resources/publications-reports-articles/. [gfr+05] h. green, k. facer, t. rudd, p. dillon, p. humphreys. personalisation and digital technologies. opening education report. published online, 2005. url: http://www.futurelab.org.uk/resources/publications-reports-articles/. [iee99] ieee std 610.12-1990 ieee standard glossary of software engineering terminology. february 1999. [iee04] ieee/acm joint task force on computing curricula. software engineering 2004 curriculum guidelines for undergraduate degree programs in software engineering. 2004. url: http://sites.computer.org/ccse/se2004volume.pdf . [imm] immersive education. url: http://immersiveeducation.org/ . [jø07] l. jaccheri, t. østerlie. open source software: a source of possibilities for software engineering education and empirical software engineering”. in proceedings of the workshop on emerging trends in floss research and development, colocated at icse’07. minneapolis, us, 21 may 2007. [kho09] a. khoroshilov. open source certification and educational process. in proceedings of the 3rd international workshop on foundations and techniques for open source software certification (opencert 2009). electronic communications of the easst 20. 2009. [lon08] j. long. open source software development experiences on the students’ resumes: do they count? insights from the employers’ perspectives. the journal of information technology education (jite) 8:229–242, 2008. [lw91] j. lave, e. wenger. situated learning: legitimate peripheral participation. cambridge university press, 1991. [mgs08] a. meiszner, r. glott, s. k. sowe. free/libre open source software (floss) communities as an example of successful open participatory learning ecosystems. the european journal for the informatics professional, upgrade ix(3):62–68, 2008. [mgs09] a. meiszner, r. glott, s. k. sowe. preparing the ne(x)t generation: lessons learnt from free/libre open source software — why free and open are pre-conditions and not options for higher education! in proceedings of the 4th international barcelona 15 / 17 volume 33 (2010) http://www.futurelab.org.uk/resources/publications-reports-articles/ http://www.futurelab.org.uk/resources/publications-reports-articles/ http://sites.computer.org/ccse/se2004volume.pdf http://immersiveeducation.org/ floss project as e-learning tools conference on higher education. volume 2. knowledge technologies for social transformation. barcelona, spain, 15–19 july 2009. [mhp05] m. michlmayr, f. hunt, d. probert. quality practices and problems in free software projects. in scotto and succi (eds.), proceedings of the first international conference on open source systems. pp. 24–28. genova, italy, 2005. [mic05] m. michlmayr. quality improvement in volunteer free software projects: exploring the impact of release management. in scotto and succi (eds.), proceedings of the first international conference on open source systems. pp. 309–310. genova, italy, 2005. [moo] moodle. url: http://moodle.org/. [muf06] m. muffatto. open source — a multidisciplinary approach. imperial college press, 2006. [pre00] s. r. pressman. software engineering a practitioner’s approach. mcgraw-hill international, london, 2000. [sc09] s. a. shaikh, a. cerone. towards a metric for open source software quality. in proceedings of the 3rd international workshop on foundations and techniques for open source software certification (opencert 2009). electronic communications of the easst 20. 2009. [sec] seconf life. url: http//secondlife.com/. [sgg] s. k. sowe, r. a. ghosh, r. glott. a model for teaching and learning in open source software projects: constructivist approach. submitted for publication. [sii07] s. k. sowe, g. s. ioannis, m. s. ioannis (eds.). emerging free and open source software practices. igi global, 2007. [sow08] s. k. sowe. pilot studies relevant to learning in floss. in proceedings of the 1st international conference on free knowledge, free technology (fkft). education for free society, barcelona, spain, 15–18 july 2008. url: http://www.slideshare.net/andreasmeiszner/pilot-studies-relevant-to-learning-in-floss. [ss08a] s. k. sowe, i. stamelos. reflection on knowledge sharing in f/oss projects. in open source development, communities and quality. ifip international federation for information processing 275, p. 351358. 2008. [ss08b] s. k. sowe, i. g. stamelos. involving software engineering students in open source software projects: experiences from a pilot study. journal of information systems education (jise) 18(4):425–435, 2008. [ssd06] s. k. sowe, i. stamelos, i. deligiannis. a framework for teaching software testing using f/oss methodology. in proceedings of the 2nd international conference on open source systems (oss2006). como, italy, 8–10 june 2006. proc. opencert 2010 16 / 17 http://moodle.org/ http//secondlife.com/ http://www.slideshare.net/andreasmeiszner/pilot-studies-relevant-to-learning-in-floss eceasst [ssl06] s. k. sowe, i. g. stamelos, a. lefteris. an empirical approach to evaluate students participation in open source software projects. in proceedings of the the iadis celda conference. barcelona, spain, 8–10 december 2006. [sta09] i. stamelos. involving software engineering students in open source software projects: experiences from a pilot study. international journal of open source software & processes (ijossp) 1(1):72–90, 2009. [ts03] m. tokoro, l. steels. the future of learning. ios press, 2003. [tuo05] i. tuomi. the future of open source: trends and prospects. in wynants and cornelis (eds.), how open is the future? economic, social and cultural scenarios inspired by free and open source software. pp. 429–459. vrjie universiteit press, 2005. [tw06] d. tapscott, a. d. williams. wikinomics: how mass collaboration changes everything. portfolio books, 2006. [ze00] l. zhao, s. elbaum. a survey on quality related activities in open source. acm sigsoft software engineering notes 25(3):53–57, may 2000. acm press new york, ny, usa. 17 / 17 volume 33 (2010) introduction the role of learning in floss communities frameworks and pilot studies in se education undergraduate education pilot study postgraduate education pilot study student's degrees of freedom student's topical focus impact on the quality of floss products conclusion and future work construction of pushout complements in the category of hypergraphs electronic communications of the easst volume 39 (2011) graph computation models selected revised papers from the third international workshop on graph computation models (gcm 2010) construction of pushout complements in the category of hypergraphs marvin heumüller, salil joshi, barbara könig, jan stückrath 20 pages guest editors: rachid echahed, annegret habel, mohamed mosbah managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst construction of pushout complements in the category of hypergraphs marvin heumüller1, salil joshi2, barbara könig1, jan stückrath1 1 abteilung für informatik und angewandte kognitionswissenschaft, universität duisburg-essen, germany 2 carnegie mellon university, usa abstract: we describe a concrete construction of all pushout complements for two given morphisms f : a → b, m : b → d in the category of hypergraphs, valid also for the case where f ,m are non-injective. it is based on the generation of suitable equivalence relations. we also give a combinatorial interpretation and show how well-known coefficients from combinatorics, such as the bell numbers, can be recovered. furthermore we present a formula that can be used to compute the number of pushout complements for two given morphisms.1 keywords: graph transformation, pushout complements, combinatorics 1 introduction pushout complements are an integral part of double-pushout rewriting [2, 4, 5]: they implement the deletion of elements, whereas the creation of new elements is implemented via a pushout. hence the construction of pushout complements is needed for many tools based on doublepushout graph rewriting. most of the time the left leg of a rule is considered to be injective and thus the construction of pushout complements is greatly simplified compared to the general case, where both morphisms might be non-injective. a thorough study of the expressiveness of injective and non-injective rules and matches can be found in [6]. in [7] we considered a backwards analysis technique for graph transformation systems where rewriting steps have to be applied backwards. that is we are interested in all predecessors of a given graph, which is a common scenario in verification techniques. in this setting pushout complements have to be constructed for the right leg of a rule and in many applications this morphism is not injective, especially in cases where graph nodes and edges are fused by rewriting. in [7] we considered in fact single-pushout rewriting [3] with pushouts in the category of partial morphisms. the problem of computing such pushout complements can be reduced to the construction of pushout complements for total morphisms, hence the construction given in this paper can also be adapted to the scenario in [7]. taking pushout complements for morphisms which are non-injective means—intuitively—to “unmerge” or split nodes in all possible ways, which can lead to a combinatorial explosion and serious efficiency problems. 1 research supported by the dfg project garev. 1 / 20 volume 39 (2011) construction of pushout complements in the category of hypergraphs in the literature the general case has so far received little attention. in the 70s the papers introducing and studying the notion of pushout complement [4, 5, 9] restricted themselves to cases where either a vertical or a horizontal morphism is injective. furthermore there are some investigations into taking pushout complements in more general categories [1, 8], but they usually assume that the first morphism is a mono or consider only the minimal pushout complement. since a construction of general pushout complements does not seem to be available in the literature, we specified this construction ourselves and found it surprisingly complex. hence we believe that it is of general interest. we will in the following define the construction which computes all pushout complements for two given morphisms f : a → b, m : b → d. this is done by defining an auxiliary graph a⊕d̃ which is the disjoint union of a and a disjoint collection of all nodes and edges of d, which are not in the image of m. then we enumerate all equivalences on a⊕d̃ satisfying certain conditions and factor through these equivalences. in this way we obtain all pushout complements and our main theorem proves this fact. furthermore—since the enumeration of all equivalences on a⊕d̃ is very costly and there are serious issues with efficiency—we consider optimizations. we show how some coefficients from combinatorics, such as bell numbers or stirling numbers of the second kind arise as the number of pushout complements for certain pairs of arrows. this also shows that there can be a combinatorial explosion in the number of constructed pushout complements. finally we present a general formula that can be used to compute the number of pushout complements for two given morphisms. 2 preliminaries we first define the usual notions of hypergraph and hypergraph morphism. definition 1 (hypergraph) let λ be a finite set of labels and a function ar : λ→n0 that assigns an arity to each label. a (λ-)hypergraph is a tuple (vg,eg,cg,lg) where vg is a finite set of nodes, eg is a finite set of edges, cg : eg →v∗g is a connection function and lg : eg → λ is the labelling function for edges. we require that |cg(e)|= ar(lg(e)) for each edge e ∈ eg. definition 2 (hypergraph morphism) let g, g′ be (λ-)hypergraphs. a hypergraph morphism (or simply morphism) ϕ : g → g′ consists of a pair of functions (ϕv : vg →vg′,ϕe : eg → eg′) such that for every e ∈ eg it holds that lg(e) = lg′(ϕe(e)) and ϕv (cg(e)) = cg′(ϕe(e)). in the following, we will simply use graph to denote a hypergraph. we will work extensively with equivalence relations and one required operation is equivalence closure that turns an arbitrary relation into an equivalence. definition 3 (equivalence closure) let a be a set and r be a relation r ⊆ a×a. the equivalence closure r of r is the smallest equivalence containing r. in the following, equivalence closure is mainly used if r is the union of two equivalences ≡1,≡2 on a, i.e., r = ≡1 ∪≡2. in this case r is simply the transitive closure of ≡1 ∪≡2 and gcm 2010 2 / 20 eceasst can be written as r = {(x,y)∈ a×a | ∃x1,y1,...,xn,yn ∈ a : x = x1 ≡1 y1 ≡2 x2 ≡1 ···≡1 yn−1 ≡2 xn ≡1 yn = y} definition 4 (pushout) let a,b,c be graphs with graph morphisms f : a → b and n : a →c. a n �� f // b m �� m �� c g // g ++ d h d′ the graph d together with g : c → d and m : b → d is a pushout of f ,n if the following conditions are satisfied: (1) m◦ f = g◦n. (2) for all m : b → d′, g : c → d′ satisfying m◦ f = g◦n there exists a unique morphism h : d → d′ such that h◦m = m and h◦g = g. there is a well-known construction of pushouts [5] in the category of hypergraphs, where pushouts are obtained by taking the disjoint union of b and c and factoring through an equivalence obtained from the morphisms f ,n. proposition 1 (pushout via equivalence classes) let a,b,c be graphs with graph morphisms f : a → b, n : a →c. we also assume that all node and edge sets are disjoint.2 let ≡ be the equivalence closure of the relation ≡̃ on vb ∪eb ∪vc ∪ec which is defined as f (x)≡̃n(x) for all x ∈va ∪ea. the gluing of b,c over a (written as d = (b⊕c)/≡) is defined as d = (vd,ed,cd,ld) with: • vd = (vb ∪vc)/≡, • ed = (eb ∪ec)/≡, • cd : e →v∗ where cd([e]≡) = [v1]≡ ...[vk]≡ and v1 ...vk = { cb(e) if e ∈ eb cc(e) if e ∈ ec • ld : e → λ where ld([e]≡) = { lb(e) if e ∈ eb lc(e) if e ∈ ec the resulting morphisms are m : b → d, g : c → d with: g(x) = [x]≡ m(x) = [x]≡ then d together with the morphisms g,m is the pushout of f ,n. 2 disjointness can be achieved easily by renaming. 3 / 20 volume 39 (2011) construction of pushout complements in the category of hypergraphs note that the functions cd and ld in proposition 1 are well-defined due to the morphism properties of definition 2. definition 5 (pushout complement) given morphisms f : a → b, m : b → d a pushout complement of f ,m is a graph c and a pair of morphisms n : a → c, g : c → d such that g,m form the pushout of f ,n. we say that two pushout complements ci with ni : a → ci, gi : ci → d for i = 1,2 are isomorphic if there exists an isomorphism j : c1 →c2 with j◦n1 = n2 and g2◦ j = g1. there is a well-known characterization of the existence of pushout complements (see for instance proposition 3.3.4 of [2]). proposition 2 (existence of pushout complements) a pushout complement of f ,m exists if and only if the following two conditions are satisfied: • identification condition: for all x,y ∈vb ∪eb with m(x) = m(y) there exist x′,y′ ∈va ∪ea with f (x′) = x, f (y′) = y. • dangling condition: for every node v ∈vb where m(v) is attached to an edge e ∈ ed which is not in the range of m, there exists a node v′ ∈va with f (v′) = v. 3 construction of pushout complements in this section we will give a concrete construction for pushout complements, i.e., given morphisms f : a → b and m : b → d, we construct all pairs of morphisms n : a →c, g : c → d and graphs c (up to isomorphism) such that the resulting square is a pushout. a f // n �� b m �� c g // d we use the following abbreviations: since it is often not necessary to distinguish between edges and nodes of a graph, we will use x ∈ a as shorthand for (x ∈ ea or x ∈ va) and f (x) as shorthand for fv (x) if x ∈va and fe(x) if x ∈ ea respectively. construction 1 (pushout complements) (1) construct a graph d̃ as follows: • for every node v ∈vd that is not in the range of m, add a copy of v to d̃. the copy of v will be denoted by v′. • for every edge e ∈ ed that is not in the range of m, add a copy of e with the same arity, attached to fresh nodes, to d̃. (this is done also if some of the nodes attached to e are in the range of m.) the copy of e will be denoted by e′ and the fresh nodes by (e′,i), i ∈{1,...,ar(ld(e))}. gcm 2010 4 / 20 eceasst this means that d̃ is a collection of disjoint nodes and edges. (2) now construct a⊕ d̃, the disjoint union of a and d̃, with morphisms n′ : a → a⊕ d̃, g′ : a⊕d̃ → d as follows: • n′ is the canonical embedding of a into a⊕d̃. • for an item x of a⊕d̃ we define g′(x) = m( f (x)) if x is contained in a. if x = y′ for some item y of d we define g′(x) = y. finally if x = (e′,i) for some edge e of d we have g′((e′,i)) = [cd(e)]i.3 (see step (1) of this construction where items of the form y′ were created.) clearly g′◦n′ = m◦ f . (3) define two equivalences on the items of a⊕d̃: • x ≡g′ y if and only if g′(x) = g′(y). • x ≡ f y if either x = y or x,y are both items of a and f (x) = f (y). it can easily be seen that ≡ f is a refinement of ≡g′, i.e., x ≡ f y implies x ≡g′ y. (4) now consider all equivalences ≡ on a⊕ d̃ such that ≡g′ is the equivalence closure of ≡ f ∪≡. furthermore whenever e1 ≡ e2 for two edges e1,e2, we require that [ca⊕d̃(e1)]i ≡ [ca⊕d̃(e2)]i for all 1 ≤ i ≤ ar(lg(e1)) = ar(lg(e2)). for each such equivalence ≡ construct the graph c = (a⊕d̃)/≡ with morphisms n : a →c, g : c → d as specified below: n(x) = [n′(x)]≡ g([x]≡) = g ′(x) note that g is well-defined since ≡ refines ≡g′. example 1 consider for instance the situation on the left below. we have a single binary edge, which is unlabeled (labels do not play a role for this example). the identities of nodes and edges are illustrated by the letters next to them. a b d f m b a c d a,b c,d f e a b a⊕d̃ d f n′ m g′ b a c d a,b c,d b a c d (e′,1) (e′,2) e′ f e 3 for a sequence s we denote by [s]i the i-th element of s. 5 / 20 volume 39 (2011) construction of pushout complements in the category of hypergraphs on nodes we have the equivalences ≡g′, ≡ f , represented by their equivalence classes: • ≡g′: {a,b,c,d,(e′,1),(e′,2)} • ≡ f : {a,b}, {c,d}, {(e′,1)}, {(e′,2)} now there are many possible equivalences ≡. first, we have to relate at least one node from {a,b} to one node from {c,d}. furthermore we have to relate each of the two nodes (e′,1), (e′,2) to an equivalences class containing one of a,b,c,d. for instance the following three equivalences ≡ are all permissible: • {a,c},{b,(e′,1)},{d,(e′,2),} • {a,c,(e′,1),(e′,2)},{b},{d} • {a,b,c,d,(e′,1),(e′,2)} this results in the following three graphs: e′ a,c b,(e′,1) d,(e′,2) a,c,(e′,1),(e′,2) e′ b d e′a,b,c,d,(e′,1),(e′,2) but there are many more possibilities. in order to enumerate them more systematically we consider all 15 equivalences on the set {a,b,c,d}, given by equivalence classes (a better way of enumeration is describes in section 4.2). the ones that do not satisfy the requirement above are crossed out. {a,b,c,d} {a},{b,c,d} {b},{a,c,d} {c},{a,b,d} {d},{a,b,c} {a,b},{c,d} {a,c},{b,d} {a,d},{b,c} {a,b},{c},{d} {a,c},{b},{d} {a,d},{b},{c} {b,c},{a},{d} {b,d},{a},{c} {c,d},{a},{b} {a},{b},{c},{d} now for k equivalence classes there are k2 possibilities to associate (e′,1) and (e′,2) to these equivalence classes. hence in total there are 1 + 6 ·22 + 4 ·32 = 61 equivalences. some of them result in isomorphic graphs, however they are all non-isomorphic in the sense of definition 5 (see also proposition 4). how the equivalences can be counted in the arbitrary case is further discussed in section 5. we now show that every graph c constructed as specified in construction 1 is a pushout complement and that all pushout complements can be obtained in this way. proposition 3 assume that f : a → b, m : b → d are given and that the conditions of proposition 2 are satisfied. then every equivalence relation ≡ created by construction 1 generates a pushout complement. gcm 2010 6 / 20 eceasst proof. assume that ≡ is one of the equivalences of construction 1 and that c and n,g have been obtained by factoring a⊕d̃ through this equivalence. as a first step we show that m◦ f = g◦n, i.e., the resulting square commutes: because n′ is the canonical embedding of a into a⊕d̃ (and therefore injective) and g′(x) is defined as m( f (x)) if x ∈ a, m( f (x)) = g′(n′(x)) holds. furthermore by definition of n,g we have: m( f (x)) = g′(n′(x)) = g([n′(x)]≡) = g(n(x)) now we show that c is indeed a pushout complement by verifying that the second condition of definition 4 are satisfied: we have to prove that for every other commuting pair of morphisms g : c → d′, m : b → d′ there is a unique morphism h : d → d′ such that h◦g = g and h◦m = m. a n �� f // b m �� m �� c g // g ++ d h d′ we define the required morphism h as follows: h(x) = { g(x̃) if ∃x̃ ∈c : g(x̃) = x m(x̃) if ∃x̃ ∈ b : m(x̃) = x by definition of g every element of d has a preimage either under g or m. it remains to be shown that h is a well-defined morphism, and that it is the unique morphism such that the triangles commute. commutativity. by definition h(m(x)) = m(x) and h(g(x)) = g(x) hold. uniqueness. let h′ be another morphism with h′◦g = g and h′◦m = m. each element of d has a preimage either under g or m: (1) if x = g(x′) then h′(x) = h′(g(x′)) = g(x′) = h(g(x′)) = h(x) (2) if x = m(x′) then h′(x) = h′(m(x′)) = m(x′) = h(m(x′)) = h(x) well-definedness. as seen before h is defined for all elements of d. to show well-definedness it is therefore only necessary to prove that different x̃ having the same image under g or m also have the same image under g or m. every element of c is an equivalence class of ≡. therefore, let x = [x′]≡ and y = [y′]≡. in the following we do not strictly distinguish between an element of a and its image under n′ because n′ is a canonical embedding. hence for x′ ∈ a⊕d̃ the property x′ ∈ a holds if and only if x′ has a preimage under n′. the first property we show is that g(x) = g(y) ⇒ g(x) = g(y) holds for all x,y ∈c. for x 6= y there are two cases which have to be considered: 7 / 20 volume 39 (2011) construction of pushout complements in the category of hypergraphs (1) x′,y′∈ a, i.e., we assume that the equivalence classes x,y have representatives in a (which also implies n(x′) = x and n(y′) = y). x′ ≡g′ y′ holds because of g′(x′) = g([x′]≡) = g(x) = g(y) = g([y′]≡) = g′(y′). due to this equivalence there are x1,y1,...,xn,yn ∈a such that x′≡ f x1, xi ≡yi, yi ≡ f xi+1 and yn ≡ f y′ for 1 ≤ i < n. using the definition of n and the fact that xi and yi are elements of a it can be shown that the equivalence xi ≡ yi implies n(xi) = [n′(xi)]≡ = [n′(yi)]≡ = n(yi). these properties lead to the following equality m( f (xi)) = g(n(xi)) = g(n(yi)) = m( f (yi)) = m( f (xi+1)) for every i. together with the equalities g(n(x′)) = m( f (x′)) = m( f (x1)) and g(n(yn)) = m( f (yn)) = m( f (y′)) = g(n(y′)) it follows that g(x) = g(y). (2) x contains no elements of a (implying x′ /∈ a) because x contains no elements of a, it also has no preimage under n. as already shown g([x′]≡) = g([y′]≡) implies x′≡g′ y′. because of this equivalence there are x1,y1,...,xn,yn ∈ a satisfying x′≡ f x1, xi ≡ yi, yi ≡ f xi+1, yn ≡ f y′ for 1 ≤ i < n. due to the definition of ≡ f it holds that x′ = x1 because x′ is not in a. also y1 can not be an item of a because otherwise [x′]≡ would contain items of a. this property can be extended to yi = xi+1 and yn = y′, which leads to xi ≡ xi+1. because of x′ = x1 and xn ≡ y′, x′ and y′ are equivalent according to ≡ and hence x and y must be equal. this clearly implies g(x) = g(y)⇒ g(x) = g(y). the second property needed for well-definedness is m(x) = m(y) ⇒ m(x) = m(y). the identification condition (see proposition 2) states that because of m(x) = m(y) there are x′,y′ ∈ a such that f (x′) = x and f (y′) = y. using this and the first property the desired equality can easily be shown by: m(x) = m(y) ⇒ m( f (x′)) = m( f (y′)) ⇒ g(n(x′)) = g(n(y′)) ⇒ g(n(x′)) = g(n(y′)) ⇒ m( f (x′)) = m( f (y′)) ⇒ m(x) = m(y) the last property to show is g(x) = m(y)⇒ g(x) = m(y). we first show that g(x) = m(y) implies that there is a y′ with f (y′) = y: the only items of d which are in the range of both g and m are the images of elements of a and nodes in the range of m which are attached to edges which are not in the range of m. however, due to the dangling condition (see proposition 2) such nodes must have a preimage in a. together with the first property this implies: g(x) = m(y) ⇒ g(x) = m( f (y′)) ⇒ g(x) = g(n(y′)) ⇒ g(x) = g(n(y′)) ⇒ g(x) = m( f (y′)) ⇒ g(x) = m(y) morphism. finally it is straightforward to prove that h satisfies indeed the morphism properties. for instance in order to show that h(cd(e)) = cd′(h(e)) for an edge e ∈ d we have to distinguish two cases: if there exists an edge ẽ ∈c with g(ẽ) = e, then—since g is a morphism— we have g(cc(ẽ)) = cd(e). hence h(cd(e)) = h(g(cc(ẽ))) = g(cc(ẽ)) = cd′(g(ẽ)) = cd′(h(e)) by definition of h. the case ẽ ∈ b with m(ẽ) = e is analogous. this proves that every diagram formed by an equivalence generated in the given construction is a pushout diagram. gcm 2010 8 / 20 eceasst proposition 4 assume that f : a → b, m : b → d are given. then every pushout complement n : a → c, g : c → d of f ,m can be obtained via construction 1. furthermore two isomorphic pushout complements give rise to the same equivalence ≡. proof. assume that c with morphisms n,g is a pushout complement of f ,m. we will show that there is an equivalence ≡, as specified by construction 1, such that c is obtained by factoring a⊕d̃ through this equivalence. a n �� f // n′ b m �� c g // d a⊕d̃ k << g′ ;; for the given pushout of f ,n we will define a surjective morphism k : a⊕d̃ → c (see diagram above). our next step is then to define an equivalence relation ≡ where x,y∈a⊕d̃ are equivalent if and only if k(x) = k(y). the factorization of a⊕d̃ through ≡ then results in c and it has to be shown that the equivalence relation ≡ is one of the equivalence relations obtained by the presented construction. let ≡∗ be the equivalence closure of the relation ≡̃ where f (a)≡̃n(a) for all a ∈ a. due to the construction of pushouts using equivalence classes we can assume without loss of generality that d = (b⊕c)/≡∗ (see proposition 1). furthermore for b ∈ b we have m(b) = [b]≡∗ and for c ∈c we have g(c) = [c]≡∗. we define k as follows: if x ∈ a, then k(x) = n(x). if x is of the form y′ for some item y of d, then — since y is not in the image of m — there must be a c ∈c with g(c) = y. in this case we define k(x) = c. if x is of the form (e′,i) for some edge e of d, then k(x) = [cc(k(e))]i. well-definedness. problems with well-definedness may arise only in the second case of the definition of k, where x is of the form y′ for some item y of d. in this case y is not in the range of m due to the construction of a⊕d̃. therefore y as an equivalence class does not contain elements of b. because of the definition of ≡∗ every equivalence class containing elements of either b or c (but not both) only contains one element, hence y contains exactly one element c of c. because g(c) = [c]≡∗ = y the preimage of y under g is unique and therefore k(x) is well-defined in this case. morphism. note that k is obviously a morphism on the elements of a. furthermore d̃ is a disjoint collection of nodes and edges and the third case in the definition of k ensures that it is indeed a valid morphism. surjectivity. we now show that k is surjective. let therefore c ∈ c be any element of c and we distinguish the following two cases: (1) ∃y ∈ a : n(y) = c: by definition k(y) = n(y) = c. 9 / 20 volume 39 (2011) construction of pushout complements in the category of hypergraphs (2) @y ∈ a : n(y) = c: without a preimage under n the equivalence class [c]≡∗ contains only c because c is not equivalent to any element of b according to ≡∗. therefore [c]≡∗ is not in the range of m since otherwise the equivalence class would contain elements of b. because of the definition of k there is a y′ ∈ d̃ with g′(y′) = y = [c]≡∗ = g(c), hence k(x) = c. commutativity. we have to show that both triangles commute: (1) we first check that k(n′(x)) = n(x) for any x ∈ a: as already seen n′(x) = x if x ∈ a. using the definition of k we obtain k(n′(x)) = k(x) = n(x). (2) now we show that g(k(x)) = g′(x) for any x ∈ a⊕d̃. there are two cases: (a) x ∈ a: using k(x) = n(x) if x ∈ a and m◦ f = g′◦n′ due to the definition of g′ and n′ it can be shown that: g(k(x)) = g(n(x)) = m( f (x)) = g′(n′(x)) = g′(x) (b) x ∈ d̃: in this case k(x) = c and g(c) = g′(x), therefore g(k(x)) = g(c) = g′(x). the equivalence ≡ is generated. we will now show that the equivalence ≡, where two elements x,y∈a⊕d̃ are equivalent if and only if k(x) = k(y), is generated by the given construction. hence we have to show that the equivalence closure of ≡∪≡ f is ≡g′, i.e., that ≡∪≡ f = ≡g′. • ≡∪≡ f ⊆≡g′: as already mentioned in construction 1, ≡ f implies ≡g′, i.e. ≡ f is clearly a subset of ≡g′. the equivalence ≡ is also a subset of ≡g′ because of: x ≡ y ⇒ k(x) = k(y)⇒ g′(x) = g(k(x)) = g(k(y)) = g′(y) • ≡∪≡ f ⊇≡g′: let x,y be elements of a ⊕ d̃ with x ≡g′ y, hence g′(x) = g′(y). as shown above the equivalence classes g′(x) and g′(y) of ≡∗ contain k(x) and k(y) respectively, therefore k(x) ≡∗ k(y). hence there are c0,b1,c1,...bm,cm such that bi≡̃ci for 1 ≤ i ≤ m and b j+1≡̃c j for 0 ≤ j < m with k(x) = c0 and k(y) = cm. using the definition of ≡̃ leads to the following properties: bi≡̃ci ⇒ ∃ai ∈ a : f (ai) = bi ∧n(ai) = ci bi+1≡̃ci ⇒ ∃a′i ∈ a : f (a ′ i) = bi+1 ∧n(a ′ i) = ci this implies that ai+1 and a′i have the same image under f , hence ai+1 ≡ f a ′ i, and that ai and a′i have the same image under n, hence ai ≡ a ′ i. this leads to x ≡ a ′ 0 ≡ f a1 ≡ a ′ 1 ≡ f ···≡ a′m−1 ≡ f am ≡ y, hence x ≡∪≡ f y. this proves that every pushout complement can be obtained by using the given construction. gcm 2010 10 / 20 eceasst isomorphism of pushout complements. it is left to show that, given two isomorphic pushout complements ni : a →ci, gi : ci → d with i = 1,2 and an isomorphism j : c1 →c2 with j◦n1 = n2, g2 ◦ j = g1, the corresponding equivalences ≡ are the same. for this it is sufficient to show that j commutes with the morphisms k1,k2, where ki : a⊕d̃ → ci and k1,k2 are constructed analogously to the morphism k above. that is, we have to show that j◦k1 = k2. then k1,k2 give rise to the same equivalence ≡. we distinguish the following cases (as in the definition of k): if x ∈ a, then j(k1(x)) = j(n1(x)) = n2(x) = k2(x). if x is of the form y′ for some item y of d, then we define ki(x) = ci for ci with gi(ci) = y. since g2( j(c1)) = g1(c1) = y we obtain c2 = j(c1). hence j(k1(x)) = j(c1) = c2 = k2(x). finally, if x is of the form (e′,`) for some edge e of d, then ki(x) = [cc(ki(e))]` and so j(k1(x)) = j([cc(k1(e))]`) = [cc( j(k1(e)))]` = [cc(k2(e))]` = k2(x). this completes the proof. the fact that two isomorphic pushout complements give rise to the same equivalence means that the number of generated (valid) equivalences is exactly the number of different pushout complements. however, if we consider only isomorphisms on c—without requiring commutativity of the triangles consisting of morphisms j,n1,n2 and j,g1,g2 (in the terminology of definition 5)—there will usually be fewer different pushout complements. the examples in sections 5.1 and 5.2 are chosen in such a way that both interpretations give rise to the same number. 4 optimizations in the given construction there exist several possibilities for optimization. these lie in the construction of a⊕d̃ and in the method used to enumerate all possible equivalences ≡. 4.1 possible simplifications in step (1) of construction 1 the graph d̃ is constructed by inserting all nodes and edges of d which are not in the range of m. additionally for every edge e of d for every node connected with e a new node is inserted. this ensures that every node attached to e is also in d̃. however, if e is connected to a node x not in the range of m, another copy of this node has been added earlier to d̃. both are equivalent with respect to ≡g′ but not with respect to ≡ f since they do not have a preimage under n′. therefore these two copies have to be equivalent according to every possible equivalence ≡. hence the first copy was superfluous and it was unnecessary to create it in the first place. d̃ d alternative d̃ n′ n′′ w1 w2 v2 v3 v1 e e′ w v e e′ w1 w2 v′ e e′ the previous diagram shows an example graph d̃ generated by the given construction if the middle graph is d and only w is in the range of m. in the left graph v1, v2 and v3 are all copies of 11 / 20 volume 39 (2011) construction of pushout complements in the category of hypergraphs v in the middle graph and all have to be in the same ≡-class. the construction would therefore still be correct if the right graph is generated instead of the left graph. in general it is only necessary to add one node to a⊕d̃ for every node not in the range of m and for every node in the range of m as many nodes as there are edges not in the range of m connected with the node (it depends on f whether the latter copies are really needed). this improvement can help to manage the combinatorial explosion when determining all possible equivalences ≡. 4.2 enumerating equivalences a problem not addressed earlier is how to generate all permissible equivalences ≡. the straightforward way would be to enumerate all possible equivalences over a⊕ d̃ and to store every equivalence satisfying ≡∪≡ f = ≡g′. this method is however not recommended because of combinatorial explosion and in addition many of these equivalences will not satisfy the required conditions. in the following we explain how the generation of equivalences could be handled more efficiently. if f is injective there is only one permissible equivalence ≡. this is true since in this case g must necessarily also be injective and hence ≡ equals ≡g′ (also x ≡ f y ⇔ x = y holds). it is already known that in this case the pushout complement is unique, if it exists [5]. a non-injective morphism f produces several permissible equivalences ≡. in this case it is sufficient to look at each equivalence class of ≡g′ separately. we further distinguish between equivalence classes which contain elements of a and those which do not. in either case every equivalence class of ≡ f is entirely contained in exactly one equivalence class of ≡g′ due to the definition of g′. if an equivalence class c of ≡g′ contains no elements of a, every equivalence class of ≡ f contained in c only contains one element. therefore c must also be an equivalence class of ≡, i.e., all elements of c must be merged. ≡ f ≡ f ∈ a 6∈ a ≡ f ≡g′ ≡ f ≡ f ≡ f if an equivalence class c of ≡g′ contains elements of a, the equivalence classes of ≡ f in c contain either only elements of a or no elements of a (see figure above). only equivalence classes of ≡ f containing elements of a can consist of more than one element. elements already equivalent according to ≡ f do not have to be equated via ≡ because they will anyway be equivalent after the equivalence closure. it is however necessary to add relations between elements in such a way that the resulting structure connects all equivalence classes to each other, possibly indirectly. (one such possibility connecting the three leftmost equivalence classes is indicated by the dashed ovals in the figure above.) therefore, in order to calculate all permissible equivalences ≡ for all elements of c, we first enumerate all equivalences over elements contained in equivalence classes of ≡ f with at least two elements, but keep only those that induce connectivity. we then distribute gcm 2010 12 / 20 eceasst the remaining elements (contained in equivalence classes of ≡ f with only one element) to the resulting equivalence classes in every possible way. the results are all equivalences ≡ restricted to elements of c. if we perform these steps for all other equivalence classes of ≡g′, a complete equivalence ≡ can be obtained by taking arbitrary combinations of such (restricted) equivalences ≡ for each class c. 5 combinatorial interpretation some coefficients from combinatorics arise naturally as the number of pushout complements for a (parameterized) pair of arrows. we first present some examples, all of them for hypergraphs with unary edges only, and later give a formula for calculating the number of pushout complements arising from given graphs and morphisms. 5.1 bell numbers the n-th bell number bn is the number of equivalence relations on the set {1,...,n}. the first bell numbers (starting with b1) are: 1, 2, 5, 15, 52, 203, 877, 4140, . . . (see the on-line encyclopedia of integer sequences4). now take λx = {x1,...,xn} as a label set. assume that xλx is the graph with n nodes, where to each node we attach a unary hyperedge and each hyperedge has a different label. furthermore zλx is the graph with one node to which n hyperedges are attached, where each hyperedge has a different label. we consider the unique morphism f : xλx → zλx and the identity m = idzλx : zλx → zλx . then—if we apply our construction—the graph a ⊕ d̃ will consist only of a = xλx and all equivalences ≡ on the nodes of xλx are admissible (for the edges each edge must be in a separate equivalence class). hence there are bn different pushout complements up to isomorphism. xλx f // zλx m �� zλx . . . x1 xn f // xn x1 . . . m �� xn x1 . . . 5.2 stirling numbers of the second kind the stirling number of the second kind sn,k is the number of equivalence relations with k equivalence classes on the set {1,...,n}. it holds that bn = ∑nk=1 sn,k. the stirling numbers satisfy the following recursive equation: sn,k = sn−1,k−1 + k ·sn−1,k, which is based on a case distinction according to the element n: either n is in an 4 http://www.research.att.com/˜njas/sequences/ 13 / 20 volume 39 (2011) construction of pushout complements in the category of hypergraphs equivalence class of its own and the remaining n−1 elements have to be grouped in k−1 equivalence classes; or the remaining n−1 elements have to be grouped in k equivalence classes and there are k possibilities to assign n to one of these classes. our implemented method for enumerating equivalences follows the same pattern. now we set λx = {x1,...,xn}, λy = {y1,...,ym} and λ = λx ∪λy. we take the unique morphism f : xλx → zλx and the unique morphism m : zλx → zλ. xλx f // zλx m �� zλ . . . x1 xn f // xn x1 . . . m �� xn x1 . . . . . .y1 ym then a⊕d̃ is the disjoint union of xλx and separate copies of m edges which are labelled y1,...,ym. now we take all permissible equivalences on the nodes of the copy of xλx . assume that we have k equivalence classes. then there are km possibilities to distribute the m nodes of the separate edges over the equivalence classes. hence the total number of pushout complements is n ∑ k=1 sn,k ·km note that for the special case of m = 0 we obtain again the bell numbers. 5.3 counting pushout complements with only node fusions with the examples above we have shown the worst cases for the number of pushout complements by looking at only one equivalence class of ≡g′. we now present a more accurate formula for calculating this number, still looking at the classes of ≡g′ individually. we will give this formula for the general case – independent of our construction – where an equivalence on an arbitrary set is given and a second, coarser, equivalence is searched for. we will in the following exploit the fact that the equivalences on a given set x coincide with the partitions on a set and we will switch between both representations. let pall (x)⊂p(p(x)) be the set of all partitions of the given set x . we also define cnt (y,z) as the number of partitions on a set z, such that the closure of the union of that partition and y , a partition on z, results in a partition where everything is in the same equivalence class (see also section 4.2, the notion of closure is here straightforwardly extended to partitions). if y contains only one element (i.e. z), any partition on z will result in {z} when forming the closure with y , hence cnt (y,z) = b|z|. the bell number b|z| is thereby also a natural upper bound for cnt (y,z) regardless of the cardinality of y . we can group these partitions according to which elements gcm 2010 14 / 20 eceasst of y they connect, i.e. which partition they induce on y . for any induced partition i on y we can calculate the number of partitions on z inducing i by calculating the possibilities for each element of i individually and forming the product of the results. these possibilities can in turn be calculated by cnt. for any partition y of a set z we obtain the following formula: b|z| = ∑ x∈pall(y ) ∏ n∈x cnt ( n, ⋃ m∈n m ) example 2 let y = {{1,2},{3,4},{5}} be a partition on z = {1,2,3,4,5}. all partitions on z will induce one of the partitions (or equivalences) on y displayed below. for instance the top right case (where {3,4} and {5} are connected) represents six equivalences: 5 can either be equivalent to 3, to 4 or to both. in all three cases 1 and 2 can be equivalent or not, but can not be equivalent to 3, 4 or 5, because this would induce another equivalence. in the end, we want to count the number of equivalences inducing the top left partition by counting the rest and subtracting it from the number of all equivalences (given by the bell numbers). 21 3 4 5 21 3 4 5 21 3 4 5 21 3 4 5 21 3 4 5 if cnt (y,z) is the number of partitions to be counted, we obtain the following proposition by reorganizing the formula above to obtain a recursive formula. we obtain cnt (y,z) by subtracting the partitions not resulting in {z} when constructing the closure from the upper bound b|z|. proposition 5 for any set z and any partition y on z the number of partitions on z which result in {z} when constructing the closure with y , can be computed by the following recursive formula: cnt ({z},z) = b|z| cnt (y,z) = b|z|− ∑ x∈pall(y )\{{y}} ∏ c∈x cnt ( c, ⋃ c′∈c c′ ) with |y|≥ 2 the evaluation of the formula above will always terminate because every c has at most |y|−1 elements. we now extend the formula to the case where two equivalences ≡′f and ≡ ′ g′ are given. the prime indicates that these equivalences are two “normal” equivalences and not a pair of equivalences such as ≡ f , which in our setting consists of ≡vf and ≡ e f . we introduce the following auxiliary notation: 15 / 20 volume 39 (2011) construction of pushout complements in the category of hypergraphs • we define part (≡) as the partition consisting of the equivalence classes of a given equivalence ≡. • let eqcoll ( ≡′f ,≡ ′ g′ ) be the set of all equivalences such that the equivalence closure of that equivalence and ≡′f results in ≡ ′ g′. note that the subscript coll stands for “collapsing”, i.e., we want to collapse ≡′f in order to obtain ≡′g′. the connection to the earlier notation is the following. for an arbitrary equivalence ≡ on a set x we have that |eqcoll (≡,x ×x)|= cnt (part (≡),x). • given an equivalence ≡ on a set x and y ⊆ x , we define [≡]x as the equivalence which results when we restrict ≡ to elements of x , i.e., [≡]x = ≡∩(x ×x). regardless of ≡′f , only elements in the same class according to ≡ ′ g′ may and must be merged. hence we split the calculation and apply the previous formula to the classes of ≡vg′ individually. the total number of possibilities is the product of the individual results, resulting in the following proposition. proposition 6 for any pair of equivalences ≡′f and ≡ ′ g′, where ≡ ′ f is a refinement of ≡ ′ g′, the number of equivalences ≡′ with ≡′ ∪≡′f = ≡ ′ g′ can be computed as:∣∣eqcoll (≡′f ,≡′g′)∣∣ = ∏ y∈part ( ≡′ g′ ) ∣∣∣pcoll (part ([≡′f ]y))∣∣∣ with |pcoll (z)|= cnt ( z, ⋃ z′∈z z′ ) note that this formula can be used to calculate the equivalences on nodes and on edges. using ≡vf and ≡ v g′ as initial values will result in the number of equivalences on nodes, whereas ≡ e f and ≡eg′ will result in the number of equivalences on edges. when calculating the number of equivalences on nodes this formula does not take equivalences on edges into account, and vice versa. fusion of edges would imply fusion of the connected nodes because of the properties of morphisms. hence the number of equivalences on nodes is only equal to the number of equivalences on nodes and edges, and thus to the correct number of pushout complements, if no edges are merged. in the next section we will extend this formula to the general case. 5.4 counting pushout complements with node and edge fusions edges can only be merged if also the connected nodes with equal indices are merged. on the one hand merging edges can increase the number of possibilities (compared to no merging of edges) if merging is optional, because every pushout complement, where these edges are not merged, results in an additional pushout complement, where the edges are merged. this is demonstrated in figure 1a, where both graphs are correct pushout complements. on the other hand merging edges can decrease the possibilities if it is mandatory, because this reduces the possible equivalences on the nodes. in figure 1b m merges e1 and e2, therefore this fusion is gcm 2010 16 / 20 eceasst a b c d f n1,n2 m g1,g2 1 2 3 4 e1 e2 1,2 3,4 e1,2 1,2,3,4 1,2,3,4 e1 e2 e1,2 1,2,3,4 e1,2 (a) optional edge fusion a b c d f n1,n2 m g1,g2 1 2 3 4 e1 e2 1,3 2,4 e1 e2 1,2 3,4 1,2,3,4 e1,2 e1,2 1,2,3,4 e1,2 (b) mandatory edge fusion figure 1: examples of edge fusions mandatory for any possible morphism n resulting in only two possible pushout complements. to compute the number of possibilities in the general case we first have to consider any possible equivalences on edges and then the problem can be solved using the results of section 5.3. let v be the node set and e the edge set of the graph on which ≡ f and ≡g′ are defined. note that both equivalences are pairs consisting of one equivalence on nodes and one on edges. taking into account the connection between these equivalences, we define ind (≡) as an equivalence on the node set v for an equivalence ≡ on the edge set e as the induced equivalence on the nodes, i.e. two nodes are equivalent if and only if there are equivalent edges connected to the two nodes at the same index. any equivalence we want to consider is coarser than this equivalence. the computation of all possibilities can be divided into the sum of all possibilities assuming a valid equivalence on edges. although each summand corresponds to a different equivalence on edges, the equivalence on nodes can be the same. for each such equivalence ≡e we have to take into account the induced equivalence on nodes ind ( ≡e ) before calculating the actual equivalences. using part ( ind ( ≡e )) instead of the node set is equivalent to requiring that any possible equivalence must be coarser than ind ( ≡e ) . for this ≡vf has to be extended to part ( ind ( ≡e )) such that two elements of part ( ind ( ≡e )) are equivalent iff they contain some equivalent nodes. we combine these ideas in the following proposition. proposition 7 the number of equivalences on a graph such that the equivalence closure with ≡ f (on nodes and edges) results in ≡g′, which corresponds to the number of pushout complements for given morphisms f ,m, can be computed by the following formula: ∑ ≡e∈eqcoll ( ≡ef ,≡ e g′ ) ∣∣∣eqcoll (≡p(≡e )f ,≡p(≡e )g′ )∣∣∣ where ≡p(≡ e ) h for h ∈ { f ,g ′} is the equivalence ≡vh lifted to the induced partition p(≡ e) = part ( ind ( ≡e )) on nodes, i.e.: x1 ≡ p(≡e ) h x2 ⇔∃z ∈ part ( ind (≡e)∪≡vh ) : x1 ⊆ z ∧x2 ⊆ z for x1,x2 ∈ part ( ind ( ≡e )) . 17 / 20 volume 39 (2011) construction of pushout complements in the category of hypergraphs example 3 in the following we apply the above formula to the graphs and morphisms shown below. a b d f m 1 2 3 4 5 e1 e2 e3 1,2 3 4,5 e1,2 e3 1,2,3 4,5 e1,2,3 all edges are equivalent according to ≡g′ and only e1 and e2 are equivalent according to ≡ f resulting in three possible equivalences on the edges. these equivalences are listed below together with their induced equivalence on the nodes and their lifting of ≡ f and ≡g′. we denote the set containing the nodes 1 and 2 by s1,2 to indicate that these sets are no longer seen as sets but as objects (i.e. nodes) for later calculation. part ( ≡vf ) ={{1,2},{3},{4,5}} part ( ≡vg′ ) ={{1,2,3},{4,5}} • case 1: part ( ≡e1 ) ={{e1,e2,e3}} part ( ≡p(≡ e 1 ) f ) ={{s1,2,3},{s4,5}} p(≡e1 ) ={s1,2,3,s4,5} part ( ≡p(≡ e 1 ) g′ ) ={{s1,2,3},{s4,5}} in this case every equivalence class of ≡p(≡ e 1 ) g′ contains only one element, hence nothing can be merged and only one equivalence is possible, because the edge fusions force the nodes to be merged as well. the resulting pushout complement is then identical to d, where n = m◦ f and g is the identity. • case 2: part ( ≡e2 ) ={{e1,e3},{e2}} part ( ≡p(≡ e 2 ) f ) ={{s1,3,s2},{s4,5}} p(≡e2 ) ={s1,3,s2,s4,5} part ( ≡p(≡ e 2 ) g′ ) ={{s1,3,s2},{s4,5}} any valid equivalence can relate s1,3 and s2 but need not because they are already related by ≡p(≡ e 2 ) f . nothing can be merged in the second class of ≡ p(≡e2 ) g′ , hence there are two possibilities in this case resulting in the pushout complements below: gcm 2010 18 / 20 eceasst c1 1,3 2 4,5 e1,3 e2 c2 1,2,3 4,5 e1,3 e2 • case 3: part ( ≡e3 ) ={{e1},{e2,e3}} part ( ≡p(≡ e 3 ) f ) ={{s1,s2,3},{s4,s5}} p(≡e3 ) ={s1,s2,3,s4,s5} part ( ≡p(≡ e 3 ) g′ ) ={{s1,s2,3},{s4,s5}} for {s1,s2,3} equivalence is similar to that of case two. additionally s4 and s5 can either be merged or not merged resulting in four different equivalences. all in all we get seven possible equivalences on nodes and edges resulting in seven different pushout complements. 6 conclusion we have shown how to construct pushout complements when both given morphisms might be non-injective. such a construction is necessary for performing backwards analysis and computing the set of predecessors of a given graph. we have implemented this construction (in a tool that performs backwards search in well-structured transition systems, based on [7]) and we presented the optimizations that we used in the implementation. we gave some result on combinatorics that illustrate the potential combinatorial explosion in the number of pushout complements for an arbitrary pair f ,m of morphisms. the computations needed to compute this number are quite involved and we tried to simplify the formulas as much as possible. it is unclear whether any further simplification or an easier theory is feasible. furthermore it is an open question whether the construction could be transferred to a more categorical setting, similar to [1]. acknowledgements: we would like to thank benjamin braatz for our discussions on this topic. bibliography [1] benjamin braatz, ulrike golas, and thomas soboll. how to delete categorically two pushout complement constructions. journal of symbolic computation, 46(3):246–271, march 2011. [2] a. corradini, u. montanari, f. rossi, h. ehrig, r. heckel, and m. löwe. algebraic approaches to graph transformation—part i: basic concepts and double pushout approach. in g. rozenberg, editor, handbook of graph grammars and computing by graph transformation, vol. 1: foundations, chapter 3. world scientific, 1997. 19 / 20 volume 39 (2011) construction of pushout complements in the category of hypergraphs [3] h. ehrig, r. heckel, m. korff, m. löwe, l. ribeiro, a. wagner, and a. corradini. algebraic approaches to graph transformation—part ii: single pushout approach and comparison with double pushout approach. in g. rozenberg, editor, handbook of graph grammars and computing by graph transformation, vol.1: foundations, chapter 4. world scientific, 1997. [4] h. ehrig, m. pfender, and h. schneider. graph grammars: an algebraic approach. in proc. 14th ieee symp. on switching and automata theory, pages 167–180, 1973. [5] hartmut ehrig. introduction to the algebraic theory of graph grammars. in proc. 1st international workshop on graph grammars, pages 1–69. springer-verlag, 1979. lncs 73. [6] annegret habel, jürgen müller, and detlef plump. double-pushout graph transformation revisited. mathematical structures in computer science, 11(5):637–688, 2001. [7] salil joshi and barbara könig. applying the graph minor theorem to the verification of graph transformation systems. in proc. of cav ’08, pages 214–226. springer, 2008. lncs 5123. [8] yasuo kawahara. pushout-complements and basic concepts of grammars in toposes. theoretical computer science, 77:267–289, 1990. [9] barry k. rosen. deriving graphs from graphs by applying a production. acta informatica, 4:337–357, 1975. gcm 2010 20 / 20 introduction preliminaries construction of pushout complements optimizations possible simplifications enumerating equivalences combinatorial interpretation bell numbers stirling numbers of the second kind counting pushout complements with only node fusions counting pushout complements with node and edge fusions conclusion categorical framework for the transformation of object-oriented systems: operations and methods electronic communications of the easst volume 26 (2010) manipulation of graphs, algebras and pictures essays dedicated to hans-jörg kreowski on the occasion of his 60th birthday categorical framework for the transformation of object-oriented systems: operations and methods christoph schulz, michael löwe, and harald könig 21 pages guest editors: frank drewes, annegret habel, berthold hoffmann, detlef plump managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst categorical framework for the transformation of object-oriented systems: operations and methods christoph schulz1, michael löwe1, and harald könig1 1 fachhochschule für die wirtschaft (fhdw), hannover freundallee 15, 30173 hannover, deutschland abstract: refactoring of information systems is hard, for two reasons. on the one hand, large databases exist which have to be adjusted. on the other hand, many programs access that data. these programs all have to be migrated in a consistent manner such that their semantics does not change. it cannot be relied upon, however, that no running processes exist during such a migration. consequently, a refactoring of an information system needs to take care of the migration of data, programs, and processes. this paper extends the model described in [slk10] by operations, messages, and methods, which allows to model complete object-oriented systems.1 methods are expressed by special double-pushout graph transformations. homomorphisms are used for the typing of the instance level as well as for the description of refactorings which specify the addition, folding, and unfolding of schema elements. finally, a categorical framework is presented which allows to derive instance migrations from schema transformations in such a way that programs and processes to the old schema are correctly migrated into programs and processes to the new schema. keywords: refactoring, evolution, transformation, migration, software 1 introduction during the engineering and use of information systems, data and software undergo many modifications. these modifications can be divided into two categories. the first category contains all modifications that have a direct and externally visible impact on the functionality of the software or on the information content of the database. the second category consists of modifications which only prepare modifications of the first category and which, by themselves, do not lead to changes in the behaviour of the software or in the meaning of the data under transformation. modifications of the second category are called “refactorings” [fow99]. they provide a major method to quickly adapt software to constantly changing requirements. refactorings are expected to be applied multiple times in different but similar situations. this is comparable to design patterns in software engineering which have emerged in the last twenty years [ghjv95, fow02]. consequently, a suitably general specification of a refactoring is necessary. this, however, requires a certain level of abstraction for the software and the data to be transformed. such an abstraction is often called schema or model and describes important structural aspects of the data and software, which are instances of, or typed in, this schema. today, 1we call an object-oriented system complete if it consists of data, programs, and processes. 1 / 21 volume 26 (2010) categorical framework for the transformation of object-oriented systems sub (a) before sub super (b) after figure 1: refactoring “introduce a new superclass” sub super target association (a) before sub super target association (b) after figure 2: refactoring “move the origin of an association from a subclass to a superclass” the “object-oriented view of life” dominates the field of software engineering. therefore, models are typically object-oriented and try to capture the structure by grouping similar objects into classes and describing relations between them by various types of associations. two typical object-oriented refactorings are “introduce a new superclass” (fig. 1) and “move the origin of an association from a subclass to a superclass”, as shown in fig. 2. a combined application of these two refactorings on the schema in fig. 3a could be used to prepare the model for an extension by an additional subclass of customer, e. g. corporatecustomer (fig. 3b and 3c).2 it is important to consider the consequences of a refactoring. obviously, the more general the structures are which are about to be transformed, the more instances are likely to be affected. changing a data schema may not only require the data typed in this schema to be adjusted, but may also affect the software which uses the schema structures to access and manipulate the data. changing a software model may have no consequences on the data but will probably influence programs (which can be considered implementations of the software model) and processes (which are programs under execution). we call the instance changes that follow from a model refactoring the migration induced by that refactoring. for the time being, little has been written about how refactoring data models results in migrations of dependent programs, and even less has been written about refactoring and induced migration of whole systems, which we define to consist of data, programs, and processes, all typed in the same schema.3 this paper contributes to this topic by providing a graph-like mathematical model which allows to specify object-oriented systems as well as schema refactorings. to describe data together with their schema, graph structures conforming to the model are used. nodes of such graph structures represent classes (schema) or objects (instance), edges represent associations (schema) or links (instance). homomorphisms between such graph structures express typings, (parts of) 2all class diagrams are specified in the uml [fs03]. 3see [mt04] and especially the bibliography contained therein for a general overview on software refactoring. festschrift h.-j. kreowski 2 / 21 eceasst privatecustomer stringname (a) before refactoring privatecustomer customer string name (b) after refactoring corporatecustomer privatecustomer customer string name (c) final aim figure 3: refactoring an exemplary object-oriented model refactorings, and migrations. this data model is described in more detail in [slk10]. these graph structures can be used to describe software models and processes, as well: an operation is simply a special node within the graph structure representing the schema, and edges originating from an operation constitute parameters. analogously, at the instance level, messages and arguments are special nodes and edges, which are typed in operations and parameters at the schema level by an appropriate homomorphism. in the mathematical description of the model, the data and software constructs are separated through the use of special predicates. programs are somewhat different, as they do not specify a single state but rather a state transition which is performed when the program is executed. in this paper, programs are considered to consist of a (possibly large) set of methods, where each method describes a single state transition. each such transition speficies how a message of a certain type is processed when all necessary preconditions are met; examples are assignments, method calls, or evaluation of expressions. as program states are described by (parts of) graph structures at the instance level, it follows that state transitions can be adequately specified by the use of graph structure transformations. this paper chooses the dpo approach for describing and applying graph structure transformations4. consequently, a method is represented by a span of homomorphisms, and applying a method to a given program state is computed by two pushout diagrams. results of category theory are used to compute induced migrations from schema refactorings. it will be shown, however, that certain restrictions must be obeyed in order to guarantee reasonable results. fortunately, these restrictions are met by the practical examples. the paper is organized as follows. section 3 introduces a graph structure specification mp with positive horn formulas which constitutes the foundation of the mathematical description of data and software. the category alg(mp) of all mp-systems and mp-homomorphisms, as well as the (sub-)categories alg(mp)↓s and sys(s) with a fixed schema s, represent the universe of discourse for the following sections. section 4 explains how methods are represented as dpo rules and introduces requirements that are necessary to use dpo graph structure transformations 4dpo stands for “double pushout”; the approach is presented in e. g. [eept06]. 3 / 21 volume 26 (2010) categorical framework for the transformation of object-oriented systems successfully in the categories mentioned above. section 5 addresses the migration of data and processes. section 6 discusses the migration of programs and contains the main result of this paper, namely that the migration of methods preserves their semantics for new processes as well as for old processes reviewed under the transformed schema. section 7 outlines three main directions for future research. 2 related work there exist approaches for modelling programs as algebraic graph transformation rules [cdfr04, kkr06a, kkr06b].5 however, they fail in various ways to be suitable for our purposes. the approach in [cdfr04] does not support inheritance. furthermore, program execution is “destructive”, i. e., repetitive control flow constructs as loops cannot be modelled directly but have to be simulated through recursion, a work-around which is not necessary in our approach as the control flow structures are not modified by program execution. the approach presented in [kkr06a, kkr06b] does not have a notion of a schema in which programs and processes are typed. this missing link makes it hard if not impossible to compute induced migrations for programs and processes when the data schema is changed. finally, both approaches consider objects to be opaque, whereas in our approach, each object is decomposed into parts called “particles” which reflect the class hierarchy. this rich object structure makes it possible to type the instance level in a schema without resorting to special typing morphisms or type graph flattening as proposed in [bel+03, eept06, lbe+07]. finally, our approach is unique in the respect that it combines a program and process model with a model for schema transformations and induced migrations. 3 models and instances the schema and the instance level of object-oriented systems are modelled by systems wrt. an extended specification.6 an extended specification spec = (σ, h(x)) is an extended signature together with a set of positive horn formulas h(x) over a set of variables x, called axioms. an extended signature σ = (s, op, p) consists of a set of sorts s, a family of operation symbols op = (opw,s)w∈s∗,s∈s, and a family of predicates p = (pw)w∈s∗ such that =s ∈ ps s for each sort s ∈ s. a system a wrt. an extended signature σ = (s, op, p), short σ-system, consists of a family of carrier sets (as)s∈s, a family of operations (opa : aw → as)w∈s∗,s∈s,op∈opw,s , and a family of relations (pa ⊆ aw)w∈s∗,p∈pw such that = a s ⊆ as ×as is the diagonal relation for each sort s.7 a system a wrt. an extended specification spec = (σ, h(x)) is a σ-system such that all axioms in h(x) are valid in a. a σ-homomorphism h : a → b between two σ-systems a and b wrt. an extended signature σ = (s, op, p) is a family of mappings (hs : as → bs)s∈s, such that the mappings are compatible with the operations and relations, i. e., hs ◦opa = opb ◦hw for all operation symbols op : w → s and hw(pa) ⊆ pb for all predicates p : w where w = s1s2 . . . sn ∈ 5[kkr06b] is the technical report [kkr06a] is based on and goes into much more detail about the presented programming language taal . 6see [mal73] for the special case when signatures consist of one sort only. 7given w = s1s2 . . . sn, aw is a short-hand notation for the product set as1 ×as2 ×···×asn . festschrift h.-j. kreowski 4 / 21 eceasst privatecustomer customer string name (a) schema c:privatecustomer c:customer n:string :name (b) instance figure 4: example of a schema together with a typed instance s∗.8 each σ-homomorphism h : a → b between two spec-systems a and b wrt. an extended specification spec = (σ, h(x)) is called a spec-homomorphism. in the following we shortly summarise the underlying model for classes and associated data as described in [slk10]. we use a graph-like signature enriched by axioms to describe both schemas and schema instances. classes are represented as graph nodes of the sort n. associations and links are represented as graph edges of the sort e. class inheritance is modelled by a binary predicate under: if, in a system s, a class a is “under” a class b, i. e., if it is a subclass of b, then the relation unders contains the pair (a, b).9 the binary predicate rel represents the equivalence closure of under. on the instance level, the predicates under and rel are used to model objects as collections of related particles. each particle is represented by a node of the sort n and is typed in a specific class in the schema. the advantage of this approach is that the structure of an object is made visible and resembles the object’s type hierarchy at the schema level allowing proper typing of links.10 figure 4 shows an exemplary schema together with one possible typed instance.11 this model is capable of representing object-oriented data typed in a schema. however, we need software constructs, namely operations, parameters, messages, arguments, and methods, as well. in order to model operations and messages, the specification is extended by a unary predicate called software which distinguishes between class nodes and operation nodes in schemas and between object nodes and message nodes in instances. the distinction between association edges and parameter edges on the one hand and between link edges and argument edges on the other hand is deduced from the context: if an edge starts at a class/object it is considered an association/link, otherwise it constitutes a parameter/argument.12 this yields the following specification: mp = sorts n (nodes) e (edges) 8given w = s1s2 . . . sn, hw(x1, x2, . . . , xn) is a short-hand notation for the tuple (hs1 (x1), hs2 (x2), . . . , hsn (xn)). 9it follows from the properties of subclassing that the predicate under is a partial order. 10for the purpose of typing, simple homomorphisms are sufficient; there is no need to introduce homomorphisms “up to inheritance”. 11note that the instance graphs do not constitute proper uml diagrams: instead we use the schema inheritance notion to depict explicit object decompositions into particles. 12the model allows parameters to point to operations; this is reasonable as it enables to model basic statements like if-then-else as operations. 5 / 21 volume 26 (2010) categorical framework for the transformation of object-oriented systems customer string getname name this result (a) operation with parameters c:customer n:string 1:getname :name :this :result (b) message with arguments figure 5: software constructs opns s : e → n (source node of an edge) t : e → n (target node of an edge) prds under : n n (subnode of) rel : n n (related to) software : n (software part vs. data part) axms inheritance x ∈ n : under(x, x) (reflexivity) (mp.1) x, y ∈ n : under(x, y)∧under(y, x) ⇒ x = y (antisymmetry) (mp.2) x, y, z ∈ n : under(x, y)∧under(y, z) ⇒ under(x, z) (transitivity) (mp.3) components x, y ∈ n : rel(x, y) ⇒ rel(y, x) (symmetry) (mp.4) x, y, z ∈ n : rel(x, y)∧rel(y, z) ⇒ rel(x, z) (transitivity) (mp.5) x, y ∈ n : under(x, y) ⇒ rel(x, y) (components) (mp.6) an example of an operation is displayed in fig. 5a, a message for this operation is shown in fig. 5b. the modelling of methods builds upon the mapping of messages and arguments into the model and is described in the next section. in [slk10], the model is further extended by two constraints. first, for each object there can only exist at most one particle of a given type. second, associations are many-to-one, such that we are able to deterministically access links by methods (see next section). as these constraints depend on both the instance and the schema, we have to combine these two parts in order to be able to formulate the constraints as implications. for this, we internalise the typing homomorphism type: definition 1 (specification m) the specification m consists of • two copies of mp, one for the schema part where the sorts, operation symbols, and predicates are suffixed by “s”, and one for the instance part, where the sorts, operation symbols, and predicates are suffixed by “i”; festschrift h.-j. kreowski 6 / 21 eceasst • two operation symbols typen and typee representing the typing; • the typing axioms modelling unique particles within objects and many-to-one associations; and • the homomorphism axioms ensuring that (typen, typee) behave like a homomorphism in every m-system. m = sorts ns (schema nodes) ni (instance nodes) es (schema edges) ei (instance edges) opns typen : ni → ns (node typing) typee : ei → es (edge typing) ss : es → ns (source node of a schema edge) si : ei → ni (source node of an instance edge) ts : es → ns (target node of a schema edge) ti : ei → ni (target node of an instance edge) prds unders : ns ns (subclass of) underi : ni ni (subparticle of) rels : ns ns (in class hierarchy of) rel : ni ni (in object of) softwares : ns (class vs. operation) softwarei : ni (object vs. message) axms homomorphism axioms x ∈ ei : typen(si(x)) = ss(typee(x)) (m.1) x ∈ ei : typen(ti(x)) = ts(typee(x)) (m.2) x, y ∈ ni : underi(x, y) ⇒ unders(typen(x), typen(y)) (m.3) x, y ∈ ni : reli(x, y) ⇒ rels(typen(x), typen(y)) (m.4) x ∈ ni : softwarei(x) ⇒ softwares(typen(x)) (m.5) inheritance axioms x ∈ ns : unders(x, x) (reflexivity) (m.6) x, y ∈ ns : unders(x, y)∧unders(y, x) ⇒ x = y (antisymmetry) (m.7) 7 / 21 volume 26 (2010) categorical framework for the transformation of object-oriented systems x, y, z ∈ ns : unders(x, y)∧unders(y, z) ⇒ unders(x, z) (transitivity) (m.8) x ∈ ni : underi(x, x) (reflexivity) (m.9) x, y ∈ ni : underi(x, y)∧underi(y, x) ⇒ x = y (antisymmetry) (m.10) x, y, z ∈ ni : underi(x, y)∧underi(y, z) ⇒ under(x, z) (transitivity) (m.11) component axioms x, y ∈ ns : rels(x, y) ⇒ rels(y, x) (symmetry) (m.12) x, y, z ∈ ns : rels(x, y)∧rels(y, z) ⇒ rel(x, z) (transitivity) (m.13) x, y ∈ ns : unders(x, y) ⇒ rels(x, y) (components) (m.14) x, y ∈ ni : reli(x, y) ⇒ reli(y, x) (symmetry) (m.15) x, y, z ∈ ni : reli(x, y)∧reli(y, z) ⇒ rel(x, z) (transitivity) (m.16) x, y ∈ ni : underi(x, y) ⇒ reli(x, y) (components) (m.17) typing axioms x, y ∈ ni : rel(x, y)∧typen(x) = typen(y) ⇒ x = y (unique particles) (m.18) x, y ∈ ei : si(x) = si(y)∧typee(x) = typee(y) ⇒ x = y (at most one target) (m.19) we use the following notation: alg(mp) denotes the category of all mp-systems and mphomomorphisms; equivalently, alg(m) denotes the category of all m-systems and m-homomorphisms. the objects of the arrow category alg(mp)2 are alg(mp)-arrows i typei−−→ s, which do not necessarily fulfil the typing requirements (m.18) and (m.19).13 the full subcategory sys ⊆ alg(mp)2 restricts the arrow category to those arrows conforming to these requirements.14 given a fixed schema system s, the slice category alg(mp)↓s expresses the category of all alg(mp)-arrows into the system s, and the category sys(s) denotes the full subcategory of alg(mp)↓s whose objects fulfil (m.18) and (m.19).15 we are now able to express properly typed instances in two ways, either as an m-system or as an alg(mp)-arrow in sys. formally, these categories are isomorphic. in order to prove that, we first show that alg(mp)2 is isomorphic to alg(m’) where m’ is defined as below. definition 2 (specification m’) the specification m’ is m without the typing axioms (m.18) and (m.19). lemma 1 alg(m’) and alg(mp)2 are isomorphic. 13let s be the mp-model a � ,2 b // c . then typing the mp-model 1 :a � ,2 2 :b 3 :a�lr in s contradicts requirement (m.18), and typing the mp-model 2 :c 1 :boo // 3 :c in s contradicts requirement (m.19). 14a subcategory d ⊆ c is full if for each pair (a, b) of d-objects, the sets of morphisms between a and b in d and c are identical. 15obviously, sys(s) is also a subcategory of sys. festschrift h.-j. kreowski 8 / 21 eceasst proof. see [slk10, lemma 4]. lemma 2 alg(m) and sys are isomorphic. proof. this follows directly from lemma 1. for horn clause specifications spec = (σ, hς(x)) where the signature only contains sorts and operation symbols, it is a well-known fact in universal algebra that the resulting category alg(spec) is closed under the formation of products and extremal subobjects (see e. g. [wec92, theorem 14] for the single-sorted case).16 this result has been extended to signatures including predicates in [sch09a]. from [ahs04, theorem 16.8], it follows that alg(m) is a full and isomorphism-closed epireflective subcategory of alg(m’).17 “reflective” means that for each alg(m’)-object a, there exists an m’-morphism u : a → f a into an alg(m)-object f a which constitutes some sort of a “best approximation” of a in alg(m), i. e., a is changed as little as possible in order to conform to the axioms in m. this is important as we do not want to change a system more than necessary in order to make it conformant to a set of axioms. (in fact, deleting all but one element from each set (and adjusting the mappings accordingly) always results in a conformant system with regard to any specification with positive horn formulas, but is surely not desirable in our context.) the morphism u is called an alg(m)-reflection of a and is an epimorphism if the subcategory is epireflective (as in our case). this reflection property can be extended to a functor, called (epi)reflector for (epi)reflective subcategories.18 so we obtain the following proposition: proposition 1 (epireflector f ) there exists an epireflector f : alg(mp)2 → sys. proof. this follows immediately from lemma 1 and lemma 2. summarising our results so far, an object-oriented schema is modelled as an mp-system s. an instance of this schema consists of an mp-system i and a typing mp-homomorphism type : i → s such that i type −−→ s is an object of the category sys(s). every schema instance type : i → s in alg(mp)↓s can uniquely be transformed into an object of the category sys by the epireflector f . 4 methods a method is part of a program and specifies how the program reacts on a message for a certain operation. it constitutes an implementation of an operation. here, the set of operations consists not only of “user-defined” operations but also of operations for evaluating expressions and for 16given a horn clause specification spec and two models a, b ∈ alg(spec), a is an extremal subobject of b if it is a subobject of b and if every predicate over elements in the a-part of b that is true in b is also true in a. in other words, an extremal subobject is “as true as possible”. 17a subcategory d ⊆ c is isomorphism-closed if for each a ∈ obd and each c-isomorphism i : a → a′, it follows that a′ ∈ obd. 18see [ahs04, pp. 52] fore more information about reflective subcategories and reflectors. 9 / 21 volume 26 (2010) categorical framework for the transformation of object-oriented systems representing statements.19 in other words, for each construct which influences the behaviour of a process, there exists a corresponding operation. a program is then a collection of methods such that all operations for which messages exist are implemented. each method is implemented by a single dpo rule [eept06] which is properly typed in the schema s. a typed dpo rule is a span l l←− k r−→ r together with the typings l typel−−−→ s, k typek−−−→ s, and r typer−−−→ s, where l, k, r, and s are graphs and l and r are injective graph morphisms such that typel ◦ l = typek = typer ◦r. the left part of the rule describes the required process state necessary for executing this method and contains at least a message typed in the operation this method implements. the remainder of the rule consists of the gluing part and the right part and specifies how this state is changed by method execution. generally, the gluing part is the common subgraph of both the left and the right part of the rule. note that a method’s dpo rule represents the change in program state when calling the method, which does not include the computation of the method’s result and side effects. those are coded by separate messages which are executed later on (see the description of next edges below). only very simple methods consisting of one statement or expression only can be encoded into a single dpo rule. in order to be able to determine which message is ready to be processed, a special “marker” object called processor is used. a message referenced by a processor through a special current link is called active. methods are formulated such that their left part requires an active message. additionally, each method moves the processor object to the next message according to the flow of control. this next message is determined by a special argument called next.20 multiple processor objects can be used to model multi-threaded processing. figure 6 displays the dpo rule for a method changing the target of a link. note that analogously to classes, operations can also be specialised, and like objects, messages also possess a particle structure. this allows processor objects to refer to any message as well as to connect arbitrary messages via next. a method is executed by applying the underlying dpo rule along a match to the graph structure describing the instance world, i. e., objects, links, messages, and arguments. according to the dpo model, in the first step a pushout complement has to be computed to complete the left side [eept06]. in the second step, the right side is built by a pushout. however we cannot do this in our category sys(s) as neither do pushout complements exist nor are pushouts along monomorphisms van-kampen squares [eept06] in all cases. therefore, we perform dpo transformations which are typed in a schema s in the slice category alg(mp*)↓s, where mp* is the signature obtained by removing all axioms from mp, and provide sufficient conditions that guarantee the fulfilment of the axioms after transformation. these conditions are necessary as not all dpo transformations yield typed instances which fulfil all the axioms. the following figures demonstrate two such counter examples: adding a link violates axiom (m.19) (fig. 7), and eliminating inheritance violates axiom (mp.3) (fig. 8). in the figures, the element-wise mapping of the homomorphisms is indicated by equally named nodes and edges, and frames are used to group the elements belonging to a single graph. in order to rule out situations as depicted in fig. 7 we need dpo rules that pull back edges. such rules only add an edge at the right side if no other edge exists which starts at the same node. 19for example, integer addition or the if-then-else statement are both represented by suitable operations. 20only very few messages do not have a next argument. this includes the end message which terminates process execution and the if-then-else message which contains a then and an else argument instead. festschrift h.-j. kreowski 10 / 21 eceasst opbase setbirthday processor datecustomer this date current next birthday (a) schema c:customer d1:date d2:date p:processor 1:setbirthday 1:opbase 2:...2:opbase :next :date :this :current :birthday (b) left part c:customer d1:date d2:date p:processor 1:setbirthday 1:opbase 2:...2:opbase :next :date :this (c) gluing part c:customer d1:date d2:date p:processor 1:setbirthday 1:opbase 2:...2:opbase :next :date :this :current :birthday (d) right part figure 6: example method “change target of birthday link” definition 3 (dpo rules pulling back edges) let σ = (s, op, p) be an extended signature, and let l l←− k r−→ r be a dpo rule. then the dpo rule pulls back edges if for each edge er ∈ re there is a node k ∈ kn and an edge el ∈ le, such that the equations sourcel(el) = ln (k) sourcer(er) = rn (k) typel,e(el) = typer,e(er) hold. in order to rule out situations as depicted in fig. 8, we restrict dpo rules to completing homomorphisms which “pull back” relations. completing homomorphisms are an extension of strictly full homomorphisms:21 while a strictly full homomorphism h only “pulls back” a relation if all related elements are known to be in the range of h, a completing homomorphism h “pulls back” relations even if only a part of the related elements is known to be reached. this is illustrated in fig. 9 by referring to the predicate under. on the left side, the homomorphism f is not completing as the under predicate is not pulled back completely: there is no preimage for y′ which is “under” x. on the right side, f has been made completing by adding the missing preimage y for y′ such that y is “under” x. this leads to the following definition: definition 4 (completing homomorphism) let σ = (s, op, p) be an extended signature, let h : a → b be a σ-homomorphism between the σ-systems a and b, and let p ∈ pw be a predicate 21a homomorphism h : a → b is strictly full if hw(x) ∈ pb ⇒ x ∈ pa for all x ∈ aw and all predicates p ∈ pw. 11 / 21 volume 26 (2010) categorical framework for the transformation of object-oriented systems a x // b (a) schema 1 :a _ _ _ _ _ _� � � � _ _ _ _ _ _2 :b 1 :a _ _ _ _ _ _� � � � _ _ _ _ _ _2 :b 1 :a _ _ _ _ _ _� � � � _ _ _ _ _ _ 3 :x // 2 :b loo r // (b) rule 1 :a _ _ _ _ _ _ _� � � � _ _ _ _ _ _ _2 :b 1 :a _ _ _ _ _ _ _� � � � _ _ _ _ _ _ _2 :b 1 :a _ _ _ _ _ _ _� � � � _ _ _ _ _ _ _ 3 :x // 2 :b 1 :a _ _ _ _ _ _ _� � � � � � � � _ _ _ _ _ _ _ 5 :x %% lll lll 2 :b 1 :a _ _ _ _ _ _ _� � � � � � � � _ _ _ _ _ _ _ 5 :x %% lll lll 2 :b 1 :a _ _ _ _ _ _ _� � � � � � � � _ _ _ _ _ _ _ 3 :x // 5 :x %% lll lll 2 :b 4 :b 4 :b 4 :b loo r // foo g // m �� k �� n �� (c) induced transformation figure 7: adding a link violates axiom (m.19) on page 8 over a sort word w ∈ s∗. then h is completing on p if for every non-empty sort word w′ resulting from eliminating arbitrary sorts from w and for each two tuples x ∈ bw and x′∈ aw′ the implication hw′(x ′) = 〈x〉w′∧x ∈ pb ⇒∃y ∈ aw : 〈y〉w′ = x′∧hw(y) = x∧y ∈ pa holds, where the notation 〈x〉w′ stands for the projection of the tuple x onto the elements of the sorts in w′. h is completing if h is completing on all predicates. now we are able to define valid dpo rules: definition 5 (valid rule) a dpo rule l l←− k r−→ r is valid iff it pulls back edges and l and r are completing homomorphisms. these restrictions do not have much impact on the expressiveness of methods. the first restriction requiring completing homomorphisms disallows changing the inner structure of objects by adding or removing particles. however, this is an unusual way of dealing with objects at runtime at best. the second restriction allows to add a link on the right side of a rule only if a similar link has previously been removed on the left side of the same rule. this is unproblematic if it can be ensured that there always exists a link for each (object, association) pair, which, for example, can initially point to a “null” object to indicate an uninitialised link.22 now we can state the main theorem of this section: theorem 1 (transformation preserves axioms [sch09b, theorem 14.29]) let s be an mpsystem. let l l←− k r−→ r be a valid rule in sys(s), g a sys(s)-object, and m : l → g a match in sys(s), such that the rule is applicable according to the dpo model. let g f ←− d g −→ h be the resulting transformation after applying the rule in alg(mp*)↓s. then d and h fulfil all axioms and are, therefore, sys(s)-objects. 22[sch09b] shows in full detail how this can be done. festschrift h.-j. kreowski 12 / 21 eceasst a � ,2 � �& b � ,2c (a) schema 1 :a _ _ _ _ _ _� � � � _ _ _ _ _ _ � ,23 :c 1 :a _ _ _ _ _ _� � � � _ _ _ _ _ _3 :c 1 :a _ _ _ _ _ _� � � � _ _ _ _ _ _3 :c loo r // (b) rule 1 :a _ _ _ _ _ _ _ _ _� � � � _ _ _ _ _ _ _ _ _ � ,23 :c 1 :a _ _ _ _ _ _ _ _ _� � � � _ _ _ _ _ _ _ _ _3 :c 1 :a _ _ _ _ _ _ _ _ _� � � � _ _ _ _ _ _ _ _ _3 :c 1 :a _ _ _ _ _ _ _ _ _� � � � � � � � _ _ _ _ _ _ _ _ _ � ,2 � �& cc cc 3 :c 1 :a _ _ _ _ _ _ _ _ _� � � � � � � � _ _ _ _ _ _ _ _ _ � �& cc cc 3 :c 1 :a _ _ _ _ _ _ _ _ _� � � � � � � � _ _ _ _ _ _ _ _ _ � �& cc cc 3 :c 2 :b : 8b zzzz 2 :b : 8b zzzz 2 :b : 8b zzzz loo r // foo g // m �� k �� n �� (c) induced transformation figure 8: eliminating inheritance violates axiom (mp.3) on page 6 proof sketch. the pushout complement d on the left side of a dpo transformation is a sys(s)object because it is a subobject of g by construction, and implicational classes are closed under the formation of subobjects [ahs04, cor. 16.19]. on the right side, we have to show for each m-axiom separately that its validity is retained by pushouts in alg(mp*)↓s. the validity of the homomorphism axioms and all schema-related axioms in h follows directly from the fact that h is an object in alg(mp*)↓s and that s is an mp-system. axiom (m.9) is valid in h because the pushout construction does not add any new elements to h as the underlying signature of mp* consists of unary operation symbols only [eept06, fact 8.12]. axiom (m.17) is valid in h because for any pair of nodes (x, y) ∈ underih , there is a pair of preimages (x′, y′) related by underi in either r or g, due to the pushout morphisms being jointly surjective [ahs04, prop. 11.29]. as both of these systems are mp-systems, they are related by rel due to axiom (m.17), and so are x and y, as all homomorphisms and especially the pushout morphisms preserve relations. a similar argumentation is used to prove that the axioms (m.15) and (m.18) are valid in h. the proof of the validity of the axioms (m.10), (m.11), and (m.16) needs more work. here it is necessary to assume the second property of valid rules, namely that the rule’s morphisms are completing. this ensures that in all cases, any node constellation in h that fulfils the premise of one of the three x f //_________ x′ y′ _lr (a) not completing x f //_________ x′ y _lr f //_________ y′ _lr (b) completing figure 9: example of a non-completing and a completing homomorphism 13 / 21 volume 26 (2010) categorical framework for the transformation of object-oriented systems axioms can be reflected to either r or g (or both), such that the same argumentation as above can be used to show the validity of the axioms in h. last but not least, the proof of the validity of axiom (m.19) in h needs the first property of valid rules, namely that the span pulls back edges. this ensures that if one assumes two edges in h with the same source, both edges have preimages under the same pushout morphism. the rest of the proof follows similarly. 5 model transformation and data migration so far we can describe object-oriented systems, consisting of typed data, programs, and processes. in this section we introduce schema transformations that can be uniquely extended to migrations of corresponding data and processes (the migration of programs is handled in the next section).23 definition 6 (transformation, refactoring) a transformation t : s s # s′ in the category alg(mp) is a span s lt←− s# r t −→ s′. such a transformation is called a refactoring iff lt is surjective. a general transformation allows reduction and unfolding as well as extension and folding through the use of non-surjective homomorphisms (reduction and extension) and non-injective homomorphisms (unfolding and folding) on the left and right side of the span, respectively (see fig. 11 on page 16 for an example of folding and unfolding). refactorings are special transformations which are constrained to surjective homomorphisms on the left side of the span. this constraint stems from the fact that refactorings are not allowed to delete schema objects because such a deletion almost always causes loss of information at the instance level, which contradicts the intuitive requirement that a refactoring should preserve information. in the following we use the term schema transformation if the span consists of schema objects, and migration if the span consists of typed instances.24 first, we need a technical lemma which ensures that the epireflector f from proposition 1 never changes the schema: lemma 3 (epireflector f does not change schema) let i typei−−→ s ∈ obalg(mp) 2 be given, and let fob(i typei−−→ s) be the typed instance i′ typei′−−−→ s′. then s = s′ holds. proof. see [slk10, lemma 9]. given a typed instance i typei−−→ s and a schema transformation t : s s # s′, the migration is performed according to [slk10] as follows (visualised in fig. 10): (1) p l t , the pullback functor along lt, is applied to i typei−−→ s, resulting in the typed instance i# typei#−−−→ s#. this part of the transformation is responsible for unfolding instance elements if lt is not injective, and for deleting elements if lt is not surjective. 23see [lksp06a, lksp06b, kls07] for precursor material on data migration induced by schema transformations. 24schema transformations such as deletion of classes without instances are not considered to be refactorings since our classification is purely schema-based. we never look at the instance level in order to classify a schema transformation as information-preserving or (possibly) information-destroying. festschrift h.-j. kreowski 14 / 21 eceasst s p.b. s#l t oo r t // s′ i typei oo i# typei# oo l′t oo idi# // i# rt◦typei# oo [ ]≡ // i′ typei′ ^^>>>>>>>> figure 10: schema transformation and instance migration (2) f r t , the composition functor along rt, is applied to i# typei#−−−→ s#, resulting in the typed instance i# rt◦typei#−−−−−→ s′. this part of the transformation is used to retype instance elements and to add new types without any instances. (3) i# rt◦typei#−−−−−→ s′ may violate the typing axioms. in order to fix this, we apply the epireflector f : alg(mp)2 → sys to it, obtaining the typed instance i′ typei′−−−→ s′ in the subcategory sys(s′). this part of the transformation is responsible for identifying instance elements due to retyping. note that due to lemma 3, the schema is left unchanged, so the epireflector can be restricted to the slice category for a given schema s, yielding the functor f s : alg(mp)↓s → sys(s). the composition of the three functors above results in the migration functor defined below: definition 7 (migration functor) let t : s s # s′ be a transformation. the migration functor m t : sys(s) → sys(s′) is defined as: m t := f s ′ ◦f r t ◦p l t , where the functor p l t : sys(s) → alg(mp)↓s# is the pullback functor along lt, the functor f r t : alg(mp)↓s# → alg(mp)↓s′ is the composition functor along rt, and f s ′ : alg(mp)↓s′→ sys(s′) is the epireflector f : alg(mp)2 → sys restricted to the slice category alg(mp)↓s′. the example in fig. 11 shows a transformation which moves the origin of an association one level upwards the inheritance hierarchy and the induced migration of an exemplary instance. on the left side the class b is unfolded, yielding the two classes b and x in the middle, and the origin of the association is moved to the temporary class x. on the right side the class x is folded with the class a, such that the association starts at the class a after the transformation. the modification of objects and links by the induced migration is performed analogously. note that the unfolding on the left is due to the pullback construction, and the folding on the right side is due to the epireflector which takes care that axiom (m.18) is satisfied.25 similar transformations which manipulate the schema graph by moving the source or the target of an association, an attribute, or an inheritance edge can be formulated and induce corresponding migrations on the instance level. 25note that the effect shown cannot be simulated by deleting the association on the left and re-adding it on the right because the induced migration leads to data loss: the middle instance graph will have all links to the deleted association removed, and the right instance graph will be identical to the middle one as the schema addition will have no effects on the instance level. 15 / 21 volume 26 (2010) categorical framework for the transformation of object-oriented systems a bc a b cx a b c b xx a (a) schema transformation 1:a 1:b2:c 1:a 1:b 2:c1:x 1:a 1:b 2:c 1:b 1:x1:x 1:a (b) induced migration figure 11: moving the origin of an association upwards the inheritance hierachy another type of transformations based on unfolding and folding is introducing a class. this is illustrated in fig. 12. note that this transformation can easily be adapted to the situation where b has no existing superclasses (thereby introducing a new root class c) by removing the classes a and a’, making the folding on the right side the identity operation. 6 method migration the migration of methods is performed in the same way as the migration of data and processes. but as methods are valid dpo rules according to def. 5, it has to be ensured that their properties are preserved by a migration. additionally, methods already executed which are represented by two pushout diagrams shall be transformed so that the resulting diagrams are again pushouts. this ensures that processes that have already been executed are compatible to the new schema after migration. however, this does not hold for arbitrary transformations. in fig. 13, two classes b and c of a schema s are merged, resulting in the class bc in the schema s′. at the instance level, the right pushout of a method adding a link is presented. the migrated diagram is a pushout in the subcategory sys(s′) of all typed instances conforming to the typing axioms, but not a pushout in the category alg(mp*)↓s′ in which the migration is computed. this can be deduced from the elementary properties of pushouts (see e. g. [eept06]). in order to migrate dpo rules and dpo diagrams properly we need to restrict the allowed transformations. we can show that if transformations are disallowed to fold associations on the right side, dpo rules can be migrated correctly in all cases. this results in the following definition of a proper transformation: festschrift h.-j. kreowski 16 / 21 eceasst a b a a’ c b a c b a’ c b a a’ (a) schema transformation 1:a 1:b 1:a 1:a’ 1:c 1:b 1:a 1:c 1:b 1:a’ 1:c 1:b 1:a 1:a’ (b) induced migration figure 12: introducing a class definition 8 (proper transformation) a transformation s l t ←− s∗ r t −→ s′ in alg(mp) is proper if rt is injective on associations, i. e., if rte(x) = r t e(y) ⇒ x = y holds for all x, y ∈ s ∗ e. the correct migration of valid dpo rules is guaranteed by the following proposition: proposition 2 (migration preserves valid dpo rules [sch09b, proposition 15.23]) given a proper transformation t : s s∗ s′, let (i1 typei1−−−→ s) l←− (i2 typei2−−−→ s) r−→ (i3 typei3−−−→ s) be a valid dpo rule. then m t(i1 typei1−−−→ s) m t(l) ←−−− m t(i2 typei2−−−→ s) m t(r) −−−→ m t(i3 typei3−−−→ s) is a valid dpo rule as well. proof sketch. it has to be shown that the pullback functor and the epireflector both preserve valid dpo rules, i. e. completing homomorphisms and spans pulling back edges. for the pullback functor, the preservation of both properties is proven easily by using the pullback properties that pullback morphisms are jointly monic and that certain unique preimages exist in the pullback object.26 to show that the epireflector preserves spans pulling back edges is done by a sort 26if (f ′ : p → b, g′ : p → a) is pullback of (f : a → c, g : b → c), and if f (x) = g(y) for some x and y, then there 17 / 21 volume 26 (2010) categorical framework for the transformation of object-oriented systems a // && b c (a) schema s a // bc (b) schema s′ :a _ _ _ _ _� � � � _ _ _ _ _ :a _ _ _ _ _� � � � _ _ _ _ _ // :b _ _ _ _ _� � � � � � _ _ _ _ _ _ _ _ _ _� � � � � � _ _ _ _ _ :b :a // :c :a 99ssss // :c r // k �� n �� g // (c) right side of an applied dpo rule before the migration :a _ _ _ _ _ _� � � � _ _ _ _ _ _ :a _ _ _ _ _ _� � � � _ _ _ _ _ _ // :bc :a _ _ _ _ _ _� � � � _ _ _ _ _ _ // :bc :a _ _ _ _ _ _� � � � _ _ _ _ _ _ // :bc r // k �� n ��g // (d) right side of an applied dpo rule after the migration figure 13: pushout in alg(mp*)↓s is not preserved by a migration of “triple pull-back”: first, the edge under consideration is pulled back along the surjective reflection arrow, then it is pulled back along the valid dpo rule, and finally it is transferred to the epireflective subcategory again by applying the epireflector on it. the remaining case that the epireflector preserves completing homomorphisms is proven similarly, but has to be extended as simply pulling back along the surjective reflection arrow may not suffice due to predicates being made true by the epireflector.27 so for each predicate and each axiom that may render this predicate true, the triple pull-back approach described above has to be proven separately, taking the axiom’s conclusion into consideration. the migration of dpo diagrams is ensured by the following proposition: proposition 3 (migration preserves pushouts [sch09b, proposition 15.35]) let t : s s ∗ s′ =̂ s lt←− s∗ r t −→ s′ be a proper transformation and (l typel−−−→ s) l←− (k typek−−−→ s) r−→ (r typer−−−→ s) be a valid dpo rule. let (d typed−−−→ s) g −→ (h typeh−−−→ s) n←− (r typer−−−→ s) be a pushout of (d typed−−−→ s) k←− (k typek−−−→ s) r−→ (r typer−−−→ s) in alg(mp∗)↓s, where all typed instances are in sys(s). then m t(d typed−−−→ s) m t(g) −−−→ m t(h typeh−−−→ s) m t(n) ←−−− m t(r typer−−−→ s) is a pushout of m t(d typed−−−→ s) m t(k) ←−−− m t(k typek−−−→ s) m t(r) −−−→ m t(r typer−−−→ s) in alg(mp∗)↓s′, where all typed instances are in sys(s′). exists a unique z in the pullback object p with g′(z) = x and f ′(z) = y. this follows directly from the limit property of pullbacks by comparing the pullback square with the terminal object. 27this includes the identification of elements, as for each sort, there is a corresponding equality predicate. festschrift h.-j. kreowski 18 / 21 eceasst proof sketch. first it is proven that the pullback functor preserves dpo pushouts. first note that dpo pushouts are pullbacks in our categories as the dpo rule morphisms are completing and, as such, injective [eept06, remark 2.25]. so applying the pullback functor to a dpo pushout yields a pullback in the target category, as the pullback functor preserves limits due to being right-adjoint to the composition functor along the same morphism [gol84, section 15.3]. it remains to show that the resulting pullback diagram is also a pushout. this is done by proving that the morphisms in the target diagram meet certain conditions; in particular, if (f ′ : p → b, g′ : p → a) is pullback of (f : a → c, g : b → c), then this square is a pushout if f and f ′ are injective, if f and g are jointly surjective, and if g is injective up to f ′28 (compare again [eept06, remark 2.25]). for the second part of the proof, note that applying the epireflector to a pushout diagram necessarily yields a pushout diagram in the target category because the epireflector is left-adjoint to the inclusion functor. however, we have to show that this pushout diagram in the subcategory sys(s′) is also a pushout diagram in the category alg(mp∗)↓s′, as this is the category where dpo transformations take place. to show this, we first prove that this is true if the following compatibility condition is met. let (f ′ : b → p, g′ : a → p) be pushout of (f : c → a, g : c → b) in alg(mp∗)↓s′. then applying the epireflector to this diagram yields again a pushout in the same category if for each predicate p ∈ pw and each tuple x ∈ keru p p we have some y ∈ keru a p with g′w(y) = x or some z ∈ keru b p with f ′ w(z) = x, i. e. if the kernel of the reflection arrow u p can be separately described by the kernels of the reflection arrows ua and ub (without any interactions between these kernels). having proven this, we show for each predicate that this property is fulfilled by the epireflector into sys(s′). both propositions can be combined, yielding the following theorem: theorem 2 (correctness of the migration of programs [sch09b, theorem 15.36]) let t : s s ∗ s′ be a proper transformation. then the migration functor m t transfers the validity of non-applied methods (dpo rules) and applied methods (dpo transformations) from the category alg(mp)↓s into the category alg(mp)↓s′. proof. direct consequence of proposition 2 and proposition 3. 7 outlook with the framework presented above, a major step towards migration of complete object-oriented systems is proposed. certainly, the framework is not universal as it is subject to some (reasonable) constraints. migrations are considered to be instances of transformations. the innovative part of the theory described consists of the automatic transformation of a migration source, computing the target with the help of a functor on slice categories. this functor is composed of three factors: generally, the pullback functor p l t is right-adjoint where the second factor—the composition functor f r t —is its left-adjoint. but the third factor—the construction f s into the subcategory sys(s)—yields an adjunction as well. thus, the whole migration enjoys well-understood universal properties which can further be pursued into three different directions. 28this means that g(x) = g(y) with x 6= y implies x, y ∈ im f ′. 19 / 21 volume 26 (2010) categorical framework for the transformation of object-oriented systems the first direction for future research will be the development of tools that support migration induced by refactoring rules. if transformation rules can be captured ergonomically in an appropriate application, migrations can automatically and uniquely be computed. thus, content migration of databases is possible as well as migration of running processes in a software system. these tools should discover potential for composition, as well: bigger refactorings should be decomposable into elementary changes, atomic steps must be proved to combine to more comprehensive procedures. this is another facet for future research. theorem 2 states that dynamical semantics is preserved by refactorings where semantics is based on valid dpo rules. hence the second direction is to find a comparable correctness criterion for data. this must include a formal specification of “information” to distinguish between semantics-preserving refactorings and information-distorting transformations. the third direction consists of abstracting away from pure graph structures. it has to be investigated to what extent the results can be generalised to elementary topoi or even to adhesive categories [gol84, eept06]. an approach can be found in [kls07] which covers data migration only. hence, an extension to method migration is desirable. references [ahs04] j. adámek, h. herrlich, g. e. strecker. abstract and concrete categories: the joy of cats. free software foundation, 2004. http://katmat.math.uni-bremen.de/acc/acc.pdf [bel+03] r. bardohl, h. ehrig, j. de lara, o. runge, g. taentzer, i. weinhold. node type inheritance concept for typed graph transformation. technical report 2003-19, technical university, berlin, 2003. http://user.cs.tu-berlin.de/~rosi/publications/belrtw03_tr03-19.ps.gz [cdfr04] a. corradini, f. l. dotti, l. foss, l. ribeiro. translating java code to graph transformation systems. in proceedings of the 2nd international conference on graph transformation (icgt 2004). pp. 383–398. 2004. [eept06] h. ehrig, k. ehrig, u. prange, g. taentzer. fundamentals of algebraic graph transformation. springer-verlag, 2006. [fow99] m. fowler. refactoring: improving the design of existing code. addison-wesley, 1999. [fow02] m. fowler. patterns of enterprise application architecture. addison-wesley, 2002. [fs03] m. fowler, k. scott. uml distilled: a brief guide to the standard object modeling language. addison-wesley, 2003. [ghjv95] e. gamma, r. helm, r. johnson, j. vlissides. design patterns. addison-wesley professional, 1995. [gol84] r. goldblatt. topoi: the categorical analysis of logic. dover publications, 1984. festschrift h.-j. kreowski 20 / 21 http://katmat.math.uni-bremen.de/acc/acc.pdf http://user.cs.tu-berlin.de/~rosi/publications/belrtw03_tr03-19.ps.gz eceasst [kkr06a] h. kastenberg, a. g. kleppe, a. rensink. defining object-oriented execution semantics using graph transformations. in gorrieri and wehrheim (eds.), proceedings of the 8th ifip international conference on formal methods for open-object based distributed systems (fmoods 2006). lecture notes in computer science 4037, pp. 186–201. springer-verlag, june 2006. [kkr06b] h. kastenberg, a. g. kleppe, a. rensink. engineering object-oriented semantics using graph transformations. technical report tr-ctit-06-12, university of twente, department of computer science, 2006. http://www.cs.utwente.nl/~kastenbe/papers/taal.pdf [kls07] h. könig, m. löwe, c. schulz. functor semantics for refactoring-induced data migration. technical report 02007/01, fachhochschule für die wirtschaft hannover, 2007. http://fhdwdev.ha.bib.de/docmgr/index.php?module=fileview&objectid=95 [lbe+07] j. de lara, r. bardohl, h. ehrig, k. ehrig, u. prange, g. taentzer. attributed graph transformation with node type inheritance. theoretical computer science 376(3):139–163, 2007. [lksp06a] m. löwe, h. könig, c. schulz, m. peters. refactoring information systems – a formal framework. in proceedings of the 10th world multi-conference on systemics, cybernetics and informatics (wmsci 2006). volume 1, pp. 75–80. 2006. also appeared in: journal on systemics, cybernetics and informatics, 5(2):66–71, 2007. [lksp06b] m. löwe, h. könig, c. schulz, m. peters. refactoring information systems – handling partial composition. electronic communications of the easst 3, 2006. [mal73] a. i. mal’cev. algebraic systems. springer-verlag, 1973. [mt04] t. mens, t. tourwé. a survey of software refactoring. ieee transactions on software engineering 30(2):126–139, 2004. [sch09a] c. schulz. mehrsortige algebraische systeme. technical report 02009/06, fachhochschule für die wirtschaft hannover, 2009. http://fhdwdev.ha.bib.de/docmgr/index.php?module=fileview&objectid=429 [sch09b] c. schulz. refactoring objektorientierter systeme. technical report 02009/02, fachhochschule für die wirtschaft hannover, 2009. http://fhdwdev.ha.bib.de/docmgr/index.php?module=fileview&objectid=282 [slk10] c. schulz, m. löwe, h. könig. categorical framework for the transformation of object-oriented systems: models and data. technical report 02010/01, fachhochschule für die wirtschaft hannover, 2010. submitted for publication in: journal of symbolic computation. http://fhdwdev.ha.bib.de/docmgr/index.php?module=fileview&objectid=525 [wec92] w. wechler. universal algebra for computer scientists. springer-verlag, 1992. 21 / 21 volume 26 (2010) http://www.cs.utwente.nl/~kastenbe/papers/taal.pdf http://fhdwdev.ha.bib.de/docmgr/index.php?module=fileview&objectid=95 http://fhdwdev.ha.bib.de/docmgr/index.php?module=fileview&objectid=429 http://fhdwdev.ha.bib.de/docmgr/index.php?module=fileview&objectid=282 http://fhdwdev.ha.bib.de/docmgr/index.php?module=fileview&objectid=525 introduction related work models and instances methods model transformation and data migration method migration outlook from petri nets to graph transformation systemsresearch partially supported by the miur prin 2008 sister.[2mm] electronic communications of the easst volume 26 (2010) manipulation of graphs, algebras and pictures essays dedicated to hans-jörg kreowski on the occasion of his 60th birthday from petri nets to graph transformation systems paolo baldan, andrea corradini, fabio gadducci and ugo montanari 18 pages guest editors: frank drewes, annegret habel, berthold hoffmann, detlef plump managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst from petri nets to graph transformation systems∗ paolo baldan1, andrea corradini2, fabio gadducci2 and ugo montanari2 1 baldan@math.unipd.it dipartimento di matematica pura e applicata, università di padova, italy 2 [andrea,fabio,ugo]@di.unipi.it dipartimento di informatica, università di pisa, italy abstract: hans-jörg kreowski was among the first researchers to point out that place/transition petri nets can be interpreted as instances of graph transformation systems, a fact now considered folklore. we elaborate on this observation, discussing how several different models of petri nets can be encoded faithfully into graph transformation systems. the key idea we pursue is that the net encoding is uniquely determined, and distinct net models are mapped to alternative approaches to graph transformation. keywords: petri nets, graph transformation, single and double pushout approach. 1 introduction the success of petri nets as specification formalism for concurrent or distributed systems is due (among other things) to the fact that they can describe in a natural way the evolution of systems whose states have a distributed nature. for example, in a place/transition net like the one depicted in fig. 1, a state of the system is represented by a marking, i.e., a set of tokens distributed among a set of places. hence the state is intrinsically distributed, thus allowing for an easy explicit representation of phenomena like mutual exclusion, concurrency, causality, and non-determinism. a b c t 1 2 2 1 [t > a b c t 1 2 2 1 (a) (b) figure 1: (a) a marked p/t net. (b) the marking after the firing of transition t. nets and their semantics are therefore a reference point for any formalism intended to describe concurrent and distributed systems, and thus also for graph transformation systems (gtss). ∗ research partially supported by the miur prin 2008 sister. 1 / 18 volume 26 (2010) mailto:baldan@math.unipd.it mailto:[andrea,fabio,ugo]@di.unipi.it from petri nets to graph transformation systems kr(t) = a b c t a b c t a b c t a b c t a b c t a b c t kr(m0) kr(m1) figure 2: encoding of nets as grammars according to kreowski. indeed, it belongs to the folklore that graph transformation systems can be seen as a generalisation of petri nets. the first formalization of this intuition, to our knowledge, was proposed by hans-jörg kreowski in [kre81] using the double-pushout (dpo) approach, and it is illustrated in fig. 2. the marked net of fig. 1 (a) is represented in fig. 2 by the graph kr(m0) having three kinds of nodes (for transitions, places, and tokens, respectively) and where edges connect either places and transitions (modelling the causal dependency relation) or tokens and places (determining the place where a token lies). transition t is represented by rule kr(t) (the top row of the figure): the rule does not modify the topological structure of the net (nodes and edges corresponding to places, transitions and causal dependency relation are also in the interface), but only deletes and creates the nodes representing tokens together with the edges connecting them to places. it is easy to check that the rule is applicable to graph kr(m0) (the gluing conditions are satisfied), and since the two squares in the figure are pushouts, that kr(m0) kr(t) =⇒ kr(m1); moreover, the derived graph kr(m1) represents the marking m1, such that m0 [t〉m1. several encodings of petri nets as gtss have been proposed since then, and it is impossible even to summarize them here: for some of the earliest, see [cor96] and the references therein. in this paper we elaborate on this idea, starting from the observation that p/t nets are only one (a noticeable one) among the alternative models of petri nets which have been proposed along the years. sticking to “low level” petri nets, other models of nets may allow at most one token at a time in a place, as for condition/event (c/e) nets [bc92] or elementary net systems (ens) [re96], and correspondingly a transition can fire only if the post-conditions are empty. in the so-called consume-produce-read (cpr) nets [bbcg08], more permissively, the transition can fire anyhow, but the token produced on a place is “coalesced” with a possibly pre-existing token. orthogonally, nets of all kinds can be equipped with read or inhibitor arcs, specifying that the presence or the absence of a token on a place is necessary for firing, but it does not affect the result [ch93, mr95, jk95, vog97, af73]. another type of arcs, called reset arcs [ak77], allows to specify that the firing of a transition deletes all the tokens, if any, from a given place. what about representing these models of nets as gtss? in principle, all of them can be festschrift h.-j. kreowski 2 / 18 eceasst encoded using dpo rewriting, because the latter is turing complete [hp01]. we prefer to follow a different approach, which on the one hand allows us to keep the encoding very simple for all the models of nets mentioned above, and on the other hand exploits the fact that also for gtss alternative formalisms have been proposed. from the gts side we shall stick to the family of algebraic approaches, among which we consider the classical singleand double-pushout approaches [löw93, eps73], and the less known subobject transformation systems [chs08]. the latter basically consists of rewriting in the lattice of subgraphs of a given graph, and it turns out to be the natural framework for encoding net models which allow at most one token on a place (where a state is a subset of places). we encode nets using a very simple kind of graphs, containing nodes and unary edges only. a marking of a net is represented by a set of edges, one for each token, each attached to a node representing a place. it is thus reminiscent of the encoding by kreowski discussed above, even if the transitions are not represented explicitly in the states: they are encoded only as rules of the gts. interestingly, inhibitor and reset arcs can be encoded exactly in the same way: the different behaviour is determined by the choice of the gts approach. the following table summarizes the results we shall present. for each of the three basic net models, we indicate the gts approach that can be used to encode it in presence of read, inhibitor and/or reset arcs: note that we do not allow for nets which include both inhibitor and reset arcs. read arcs read + inhibitor read + reset p/t nets dpo or spo dpo spo ens sts or sts⊆ sts sts⊆ cpr nets stsm or sts ⊆ m stsm sts ⊆ m table 1: summary of the proposed encodings. the few variants of the sts approach referred to in the table will be introduced later on. the encodings of p/t petri nets with read, inhibitor and reset arcs as gtss were originally discussed in [bcm05]. the present paper provides a systematic view of such encodings, viewing them in a much more general framework which recomprises elementary net systems and cpr nets. the paper is structured as follows. section 2 presents the three gts approaches we deal with in our work, and it is complemented in section 3 by the kinds of nets for which we present an encoding. section 4 discusses these encodings, and the correspondence between alternative net models and gts approaches. section 5 draws some conclusions and offers pointers to future work. 2 algebraic approaches to graph transformation this section introduces some basic notions concerning the algebraic formalisms for graph rewriting considered in the paper. we concentrate on typed graph transformations systems (gtss), both in the single-pushout (spo) [löw93, ehk+97] and the double-pushout (dpo) [eps73, cmr+97] approach, and on subobject transformation systems (stss) [chs08]. typed rewrit3 / 18 volume 26 (2010) from petri nets to graph transformation systems ing is a well-established variant of the classical proposals where rewriting takes place on socalled typed graphs, i.e., graphs labelled over a structure which is itself a graph [cmr96, lkw93]. 2.1 graphs and graph morphisms we introduce here the basic concepts concerning graphs and their morphisms. for the sake of simplicity, our introduction to gtss will deal with unary hyper-graphs only, since they are just what is needed for the encoding of petri nets that we are going to present. indeed, all the remarks in this section could be generalized to any kind of (hyper-)graphs or, albeit with some additional care, to any adhesive category [ls05]. similarly, the encodings presented later would work in standard categories of (hyper-)graphs. given a partial function f : a ֌ b we denote by dom( f ) its domain, i.e., the set {a ∈ a | f (a) is defined}. let f , g : a ֌ b be two partial functions. we write f ≤ g when dom( f ) ⊆ dom(g) and f (x) = g(x) for all x ∈ dom( f ). definition 1 (graph and graph morphism) a (unary) graph g is a triple g = (vg, eg, cg), where vg is a set of nodes, eg is a set of edges and cg : eg → vg is a function mapping each edge to the node it is connected to. a partial graph morphism f : g ֌ h is a pair of partial functions f = 〈 fn : ng ֌ nh , fe : eg ֌ eh〉 such that ch ◦ fe ≤ fn ◦cg (see fig. 3.(a)) we denote by pgraph the category of (unlabelled) graphs and partial graph morphisms. a morphism is called total if both components are total, and the corresponding subcategory of pgraph is denoted by graph. notice that if a partial graph morphism f is defined over an edge, then it must be defined on the node the edge is connected to: this ensures that the domain of f is a well-formed graph. definition 2 (subgraph lattice) a graph g is a subgraph of h , written g ⊆ h , if ng ⊆ nh , eg ⊆ eh , and the inclusions form a graph morphism. the subgraphs of h ordered by inclusion form a distributive lattice, denoted sub(h), where the meet ∩ and the join ∪ are defined as component-wise intersection and union, respectively. given graphs h and g ⊆ h , we will write, a bit informally, h \g to denote the set of items (nodes and edges) of h which do not belong to g. eg cg �� fe // ≥ eh ch �� ng fn // nh |g1| tg1 �� 33 33 33 f // ≥ |g2| tg2 �� t (a) (b) figure 3: diagrams for partial graph and typed graph morphisms. festschrift h.-j. kreowski 4 / 18 eceasst given a graph t , a typed graph g over t is a graph |g|, together with a total morphism tg : |g|→ t . a partial morphism between t -typed graphs f : g1 ֌ g2 is a partial graph morphism f : |g1| ֌ |g2| consistent with the typing, i.e., such that tg1 ≥ tg2 ◦ f (see fig. 3.(b)). a typed graph g is called injective if the typing morphism tg is injective. the category of t typed graphs and partial typed graph morphisms is denoted by t -pgraph. given a partial typed graph morphism f : g1 ֌ g2, we denote by dom( f ) the domain of f typed in the obvious way. given a subgraph g of t , i.e., an element of sub(t ), we often consider it as a graph typed over t by the inclusion. since we work only with typed notions, we usually omit the qualification “typed”. 2.2 double-pushout rewriting chosen a type graph t , a (t -typed) dpo rule q = (l l ←֓ k r →֒ r) is a pair of injective (total, t -typed) graph morphisms l : k →֒ l and r : k →֒ r, where |l|, |k| and |r| are finite graphs. the graphs l, k and r are called the left-hand side, the interface, and the right-hand side of the rule, respectively. definition 3 (dpo direct derivation) given a graph g, a dpo rule q, and a match (i.e., a total graph morphism) g : l → g, a dpo direct derivation from g to h using q (based on g) exists, written g ⇒dp oq h , if the diagram lq : g �� k? _loo � � r // k �� r h �� g d b oo d // h can be constructed, where both squares are pushouts in t -graph. given an injective morphism l : k →֒ l and a match g : l → g as in the above diagram, their pushout complement (i.e., a graph d with morphisms k and b such that the left square is a pushout) exists if and only if the gluing condition is satisfied. this consists of two parts: • the identification condition, requiring that if two distinct nodes or edges of l are mapped by g to the same image, then both are in the image of l; • the dangling condition, stating that no edge in g\g(l) should be connected to a node in g(l \ l(k)) (because otherwise the application of the rule would leave such an edge “dangling”). 2.3 single-pushout rewriting chosen a type graph t , a (t -typed) spo rule q = (l r ֌ r) is an injective partial typed graph morphism r : l ֌ r. the graphs l and r are called the left-hand side and the right-hand side of the rule, respectively. definition 4 (spo direct derivation) given a graph g, an spo rule r, and a match (i.e., a total graph morphism) g : l → g, we say that there is an spo direct derivation from g to h using r 5 / 18 volume 26 (2010) from petri nets to graph transformation systems (based on g), written g ⇒s p or h , if the following is a pushout square in t -pgraph. l g �� // r // r �� h �� g // d // h roughly speaking, the rewriting step removes from the graph g the image of the items of the left-hand side which are not in the domain of r, namely g(l\dom(r)), adding the items of the right-hand side which are not in the image of r, namely r\r(dom(r)). the items in the image of dom(r) are “preserved” by the rewriting step (intuitively, they are accessed in a “read-only” manner). a relevant difference with respect to the dpo approach is that here there is no dangling condition preventing a rule to be applied whenever its application would leave dangling edges. in fact, as a consequence of the way pushouts are constructed in t -pgraph, when a node is deleted by the application of a rule also all the edges connected to such node are deleted by the rewriting step, as a kind of side-effect. for instance, rule q in the top row of fig. 4, which consumes node b, can be applied to the graph g in the same figure. as a result both node b and edge l are removed. b q g l b figure 4: side-effects in spo rewriting. even if the category pgraph has all pushouts, still we will consider a condition which corresponds to the identification condition of the dpo approach. definition 5 (valid match) let r : l → r be a rule. a match g : l → g of r is called valid when for any x, y ∈|l|, if g(x) = g(y) then x, y ∈ dom(r). conceptually, a match is not valid if it requires a single resource to be consumed twice, or to be consumed and preserved at the same time. in the paper we consider derivations where all matches are valid: this is needed to have a resource-conscious interpretation for derivations, i.e., where each resource is consumed at most once. we close this section noting that for each dpo rule we can easily construct an spo rule, which behaves like the original one when the dangling condition is satisfied. clearly, the converse construction is possible as well. definition 6 (from dpo to spo rules, and vice versa) let q = (l l ←֓ k r →֒ r) be a t -typed dpo festschrift h.-j. kreowski 6 / 18 eceasst rule. then, the associated t -typed spo rule, denoted by s (q), is given by the partial graph morphism r◦l∗ : l ֌ r, where l∗ : l ֌ k is the partial inverse of l, defined in the obvious way. vice versa, for a t -typed spo rule q = (l r ֌ r), the associated dpo rule is defined as d(q) = (l ←֓ dom(r) r →֒ r). 2.4 subgraph transformation systems in the typed approaches to graph transformation, the type graph plays a role analogous to the set of places in petri nets. in particular, the constraint that a place can contain at most one token can be translated into the requirement that the typing morphism is injective. this condition is built-in in the instance of the subobject transformation system approach [chs08] that we present here. in the original formulation, the framework where rewriting is defined is the distributive lattice of subobjects of a fixed object of an adhesive category. such generality is unnecessary here, and we instantiate the definitions to the case where the category of concern is graph, which is indeed adhesive. as a consequence, in the following we read “sts” as subgraph transformation systems. chosen a type graph t , a (t -typed) sts rule q is a triple q =〈l, k, r〉, where l, k, r∈sub(t ), k ⊆ l and k ⊆ r. the graphs l, k and r are called the left-hand side, the interface and the righthand side of the rule, respectively. definition 7 (sts direct derivation) given a graph g in sub(t ) and an sts rule q = 〈l, k, r〉, there is a sts direct derivation from g to h using q, written g ⇒s tsq h , if h ∈ sub(t ) and there exists d ∈ sub(t ) such that (i) l∪d = g; (iii) d∪r = h ; (ii) l∩d = k; (iv) d∩r = k. if such a graph d exists, we shall refer to it as the context of the direct derivation g ⇒s tsq h . it is instructive to consider the relationship between an sts direct derivation and a dpo direct derivation as introduced above. first observe that sub(t ) can be seen as a category where the arrows are the inclusions, and a rule 〈l, k, r〉 can be seen as a span q = (l ⊇ k ⊆ r), i.e., a pair of arrows in sub(t ). next, we shall say that there is a contact situation for a rule 〈l, k, r〉 at a subgraph g ⊇ l ∈ sub(t ) if g∩ r 6⊆ l. intuitively, this means that some items of the subgraph g are created but not deleted by the rule: if we were allowed to apply the rule at this match via a dpo direct derivation, the resulting object would contain the common part twice and consequently the resulting morphism to t would not be injective; i.e., the result would not be a subgraph of t . the next result, presented in [chs08], shows that an sts direct derivation is also a dpo direct derivation if no contact occurs. proposition 1 (sts derivations are contact-free double pushouts) let g and h be graphs in sub(t ) and q = 〈l, k, r〉 be an sts rule. then g ⇒s tsq h if and only if l ⊆ g, g∩r ⊆ l, and g ⇒dp oq h , i.e., if there is a graph d ∈ t -graph such that the diagram below forms two pushouts in t -graph. 7 / 18 volume 26 (2010) from petri nets to graph transformation systems l ⊆ �� (1) k ⊇ oo ⊆ // �� (2) r �� g doo // h in the last result we used the fact that an sts rule can be considered as a t -typed dpo rule, considering the inclusions as arrows in graph. conversely, a t -typed dpo rule q = (l l ←֓ k r →֒ r) induces an sts rule i (q) obtained by considering the images of |l|, |k| and |r| in the type graph, i.e., i (q) = 〈tl(|l|),tk (|k|),tr(|r|)〉. 2.5 other kinds of stss we introduce here three variations of the definition of sts direct derivation, obtained by slightly changing the properties satisfied by the context graph d. the first definition is reminiscent of the sesqui-pushout approach [chhk06], and it leads to an spo-like approach for sts, where rules can be applied regardless of the dangling condition, removing, as a side-effect, those edges which would remain dangling. definition 8 (sts⊆ direct derivation) given a graph g in sub(t ) and an sts rule q =〈l, k, r〉, there is an sts⊆ direct derivation from g to h using q, written g ⇒s ts ⊆ q h , if h ∈ sub(t ) and there exists d ∈ sub(t ) such that (i)′ l∪d ⊆ g; (ii)′ d is the largest subgraph of g such that l∩d = k; (iii) d∪r = h ; (iv) d∩r = k. weakening the first condition of definition 7 and imposing the “largest subgraph” requirement in (ii)′ implies that some items of g\l may not occur in d, like when deleting a node forces the deletion of incident edges in the spo approach. the superscript in sts⊆ reminds the weakening of the first condition. the next variants drop the requirement d∩r = k. this allows for some overlap between the items preserved in the context d and those newly introduced by r: the injectivity of the typing forces these items to be coalesced, similarly to what happens in cpr nets. this is done for stss in both dpo and spo style. definition 9 (stsm and sts⊆m direct derivations) given a graph g in sub(t ) and an sts rule q = 〈l, k, r〉, there is an stsm direct derivation from g to h using q, written g ⇒ s tsm q h , if h ∈ sub(t ) and there exists d ∈ sub(t ) such that (i) l∪d = g; (ii) l∩d = k; (iii) d∪r = h. analogously, there is an sts⊆m direct derivation from g to h using q, written g ⇒ s ts⊆m q h , if h ∈ sub(t ) and there exists d ∈ sub(t ) (i)′ l∪d ⊆ g; festschrift h.-j. kreowski 8 / 18 eceasst (ii)′ d is the largest subgraph of g such that l∩d = k; (iii) d∪r = h. the figure to the right shows the differences among the various kinds of sts direct derivations introduced in definitions 7, 8 and 9. the type graph t on the top contains two nodes, ◦ and •, and one edge connected to ◦. the lattice of subgraphs of t is depicted under t , with dashed lines representing inclusions. the arrows show all the possible direct derivations among elements of sub(t ) using the sts rule q = 〈{◦}, /0,{•}〉 and the following approaches introduced in definitions 7, 8 and 9: 1 = sts, 2 = sts⊆, 3 = stsm, 4 = sts ⊆ m . 1, 2, 3, 4 4 2, 4 t 3, 4 2.6 graph grammars in the previous sections we presented six different definitions of direct derivation, each of which determines a different algebraic approach to graph transformation. for each one of those approaches, a graph grammar contains a type graph, a start graph, a set of rule names, and a mapping from rule names to corresponding rules. clearly, the precise definition of start graph and of rule depends on the chosen approach. definition 10 (graph grammar) a kind graph grammar, where kind ∈{dpo, spo, sts, sts⊆, stsm, sts ⊆ m}, is a tuple g = 〈t, gs, p, π〉, where t ∈ graph is the type graph, p is a set of rule names, π is a function which associates a kind rule1 to each rule name in p, and gs is the start graph, which has to be consistent with kind. that is, gs is a t -typed graph if kind ∈{dpo, spo}, and gs ∈ sub(t ) in all other cases. a derivation over a kind grammar g is a sequence of kind direct derivations using rules in p, starting from the start graph, namely ρ = {gi−1 ⇒ki ndpi−1 gi}i∈{1,...,n}, with g0 = gs. 3 enriched petri nets in this section we introduce some basic extensions of petri nets, namely, nets with read, inhibitor and reset arcs. a study of the expressiveness of these kinds of arcs, along with a comparison with other extensions proposed in the literature, like priorities, exclusive-or transitions and switches, is carried out in [pet81, lc94]. to give the formal definition of these generalised nets we need some notation for sets and multisets. given a set x we write 2x for the powerset of x and x⊕ for the free commutative monoid over x , with monoidal operation ⊕, whose elements will be referred to as multisets 1 to be precise, for kind ∈{sts⊆, stsm, sts ⊆ m}, a kind rule is an sts rule. 9 / 18 volume 26 (2010) from petri nets to graph transformation systems over x . given a multiset m ∈ x⊕, with m = ⊕ x∈x mx ·x, for x ∈ x we will write m(x) to denote the coefficient mx. moreover, we denote by [[m]] the underlying subset of x , defined as [[m]] ={x ∈ x | m(x) > 0}. with little abuse of notation, we will write x ∈ m instead of x ∈ [[m]]. given m, m′∈ x⊕ we write m ≤ m′ when m(x)≤ m′(x) for all x ∈x . in this case the multiset difference m′⊖m is the multiset m′′ such that m⊕m′′ = m′. for y ⊆ x and m ∈ x⊕, we denote by m[y ] the restriction of m to y , i.e., m[y ](x) = m(x) if x ∈ y , and m[y ](x) = 0 otherwise. finally, the symbol /0 denotes the empty multiset. 3.1 place/transition nets we are now ready to define the enriched p/t nets considered in the paper. besides ordinary flow arcs and read arcs, the nets are endowed with so-called “distinguished arcs” (represented by the �(.) function below), which will be interpreted either as inhibitor or reset arcs in the token game. definition 11 (enriched p/t nets) an enriched (marked) place/transition (p/t) petri net is a tuple n = 〈s, tr, •(.), (.)•, (.), �(.), m〉, where • s is a set of places; • tr is a set of transitions; • •(.), (.)• : tr → s⊕ are functions mapping each transition to its pre-set and post-set, respectively; • (.) : tr → 2s is a function mapping each transition to its context; • �(.) : tr → 2s is a function mapping each transition to its distinguished set of places, such that for all t ∈ tr, ( •t ⊕t ⊕t•)[ �t] = /0 (i.e., no token in �t can be either read, consumed or produced by t); • m ∈ s⊕ is a multiset called the initial marking. we assume, as usual, that s ∩tr = /0. we shall denote with •(.), (.)•, (.) and �(.) also the functions from s to 2t r defined as, for s ∈ s, •s = {t ∈ tr | s ∈ t•}, s• = {t ∈ tr | s ∈ •t}, s = {t ∈ tr | s ∈ t}, and �s = {t ∈ tr | s ∈ �t}. a state of a p/t net is defined as a marking, that is, a set of tokens distributed over the places. formally, a marking m is a multiset of places, i.e., m ∈ s⊕. the token game determines when a transition t is enabled at a given marking, and, if enabled, what marking is reached after firing the transition. for a transition t to be enabled at a marking m, it is necessary for m to contain the pre-set of t and an additional set of tokens which covers the context of t. additional conditions for enabledness, as well as the result of firing, depend on the interpretation given to the distinguished arcs: as anticipated, we interpret them either as inhibitor arcs or as reset arcs, obtaining the classes of nets below. definition 12 (inhibitor and reset p/t nets) an inhibitor place/transition net is an enriched p/t net 〈s, tr, •(.), (.)•, (.), �(.), m〉 where the distinguished arcs are interpreted as inhibitor arcs. festschrift h.-j. kreowski 10 / 18 eceasst given a marking m ∈ s⊕ and a transition t ∈ tr, t is i-enabled if •t ⊕t ≤ m and m[ �t] = /0 (i.e., m contains no token in any place of �t). the inhibitor transition relation between markings is defined as m [t〉i m ′ if t is i-enabled at m and m′ = (m⊖ •t)⊕t•. a reset p/t net is an enriched p/t net where the distinguished arcs are interpreted as reset arcs. given m ∈ s⊕ and t ∈ tr, t is r-enabled if •t ⊕t ≤ m. the reset transition relation is defined as m [t〉r m ′ if t is r-enabled at m and m′ = ((m ⊖ •t)⊕t•)⊖m[ �t] (i.e., the firing of t deletes all the tokens from places in �t: such places are certainly empty after the firing, because they cannot belong to the post-set of t). for a transition t, if the distinguished set �t is empty the two alternative enabling conditions coincide, as well as the induced transition relations on markings. in the following, we call contextual petri nets the class of nets such that all its transitions have the distinguished set empty. firing sequences and reachable markings are defined in the usual way. example 1 an example of an enriched p/t net n can be found in the left part of fig. 5. graphically, transitions are connected to context places by undirected arcs and to distinguished places by dotted undirected arcs. starting from the initial marking s0⊕s1⊕s2 ⊕s4, a possible firing sequence for all interpretations is t1; t2 leading to the marking s2 ⊕s3 ⊕2s4 ⊕s. if we first fire t2, the net reaches the marking s0 ⊕s2 ⊕s4⊕s. now, if n is seen as an inhibitor p/t net, the presence of a token in s inhibits t1 which cannot fire. if, instead, n is seen as a reset p/t net, transition t1 can fire and, as a consequence, place s is emptied, producing the marking s2 ⊕s3 ⊕2s4. 3.2 elementary nets let us call elementary a net where the states are defined as (sub)sets of places, rather than multisets of places as for p/t nets. thus elementary nets comprise several net models proposed in the literature, including c/e nets [bc92], elementary net systems [re96], consume-produce-read nets [bbcg08] and others. an enriched elementary (marked) net 〈s, tr, •(.), (.)•, (.), �(.), m〉 is defined as an enriched p/t net in definition 11, requiring •(.), (.)• : tr → 2s and m ∈ 2s (i.e., •t and t• for all t ∈ tr, as well as the initial marking m, are sets rather than multisets). furthermore, besides the disjointness condition on the distinguished places, that is formulated as ( •t ∪t ∪t•)∩ �t = /0, it is required that no token in t is consumed or produced, i.e., (•t ∪t•)∩t = /0 for all t ∈ tr. both inhibitor and reset elementary nets are easily defined, interpreting the distinguished arcs as expected. however, since the states are subsets of places, the enabling condition and the transition relation must ensure that the marking reached by firing a transition is a set. this is obtained in a different way by the two models of nets that we introduce: enss require a stronger enabling condition with respect to p/t nets, while cpr nets, intuitively, change the transition relation by allowing to merge tokens of the marking with those produced by the transition. 11 / 18 volume 26 (2010) from petri nets to graph transformation systems definition 13 (inhibitor and reset elementary net systems) an inhibitor ens is an enriched elementary net 〈s, tr, •(.), (.)•, (.), �(.), m〉 where the distinguished arcs are interpreted as inhibitor arcs. given a marking m ⊆ s and a transition t ∈ tr, t is ie-enabled if •t ∪ t ⊆ m, m∩ �t = /0, and (m\ •t)∩t• = /0. the ie-transition relation between markings is defined as m [t〉ie m ′ if t is ie-enabled at m and m′ = (m\ •t)∪t•. a reset ens is an enriched elementary net where the distinguished arcs are interpreted as reset arcs. given m ⊆s and t ∈tr, t is re-enabled if •t∪t ⊆m and (m\ •t)∩t• = /0. the re-transition relation is defined as m [t〉re m ′ if t is re-enabled at m and m′ = ((m \ •t)∪t•)\ �t. the condition (m \ •t)∩t• = /0 ensures that there is “no contact”, i.e., t can produce a token only if it is not in m, or if it is deleted by t itself. as a consequence the ∪ operator in the definition of m′ is actually a disjoint union. this is the main difference with respect to cpr nets, where the “no contact” condition is omitted, and the arguments of ∪ in the definition of the successor marking might not be disjoint. definition 14 (inhibitor and reset cpr nets) an inhibitor cpr net is an enriched elementary net where for a marking m ⊆ s and a transition t ∈ tr, t is ic-enabled if •t ∪t ⊆ m and m∩ �t = /0; the ic-transition relation is defined as m [t〉ic m ′ if t is ic-enabled at m and m′ = (m\ •t)∪t•. a reset cpr net is an enriched elementary net where for m ⊆ s and t ∈ tr, t is rc-enabled if •t ∪t ⊆ m; the rc-transition relation is defined as m [t〉rc m ′ if t is rc-enabled at m and m′ = ((m \ •t)∪t•)\ �t. example 2 observe that the net n in fig. 5 can be seen as an ens. in this case, starting from the initial marking {s0, s1, s2, s4} the transition t1 cannot fire due to a contact situation in s4, hence the only possible firing sequence is t2. if we interpret n as a cpr net, then t1 can fire and the reached marking is {s1, s2, s3, s4}, where, intuitively, the token generated in s4 is “merged” with the pre-existing one. in this state, t2 can fire producing the marking {s2, s3, s4, s}. if we start by firing t2, as in the p/t case, t1 is blocked or can fire (emptying place s), depending on whether we interpret n as an inhibitor or a reset cpr net. 4 from enriched nets to graph transformation systems this section shows how enriched petri nets can be encoded as graph grammars. interestingly, the encoding is essentially the same for all kinds of nets: the different token game flavours are obtained by changing the approach to rewriting. festschrift h.-j. kreowski 12 / 18 eceasst 4.1 encoding petri nets as graph grammars it is part of the folklore (see e.g. the discussion in [cor96] and the references therein) that (ordinary) petri nets can be seen as a special kind of graph grammars. the simplest idea is that the marking of a net is represented as a graph with no edges, typed over the places: a token in place s is a node typed over s. then transitions are seen as rules which consume and produce nodes, as prescribed by their preand post-set. in this way, petri nets exactly correspond to graph grammars acting over graphs containing only nodes, where rules preserve no item. to make the encoding parametric with respect to the chosen class of petri nets, here we consider a slightly different encoding, where edges, rather than nodes, play the role of tokens. roughly, the idea of the encoding is the following: • a place is represented as a node; • tokens in a place are represented as unary edges connected to the corresponding node; • a transition becomes a rule, which deletes the tokens in its pre-set, produces the post-set and preserves the tokens in its context; for any place in the distinguished set of t, the corresponding node is deleted and created again. note the chosen encoding for the distinguished set of t: in the dpo approach this will prevent the application of the rule if there is at least one token (edge) in the place, thus causing an inhibitor effect. in the spo approach, the application of the rule will delete as a side-effect any edge possibly attached to the node, thus giving raise to a reset effect. as a first step, we show how the set of places underlying an enriched net (either p/t or elementary) gives raise to a type graph. in all cases there will be a node s in the type graph for each place s in the net, and the number of edges incident on the node typed over s will represent the number of tokens in that place. also the way in which markings are encoded as graphs does not depend on the specific kind of nets we are considering. definition 15 (type graph, markings) let s be a set of places. then, the associated type graph ts is (s, s, c), where c(s) = s for all s ∈ s. given a subset of places s′ ⊆ s and a marking m ∈ s′⊕, we define the graph gs(s′, m) as (s′, e(m), c), typed in the obvious way over ts, such that e(m) = {〈s, i〉 | s ∈ [[m]]∧0 < i ≤ m(s)} and c(〈s, i〉) = s for all 〈s, i〉∈ e(m). we write simply gs(m) for gs(s, m). so, each place contributes a node and an edge in the type graph ts, and a marking can be regarded as a multiset of edges of the type graph. next we introduce the encoding of net transitions into grammar rules. as mentioned above, the encoding is essentially independent of the kind of nets we are considering: the different firing behaviour will be obtained by changing the considered rewriting approach. indeed, next we define the encoding of a transition as a dpo rule, but changing the rewriting approach (to spo or sts) will just require a syntactical change in the presentation of the rule. definition 16 (net transitions as dpo rules) let t be a transition of an enriched p/t net with place set s. then t is encoded as a ts-typed dpo transition 13 / 18 volume 26 (2010) from petri nets to graph transformation systems inhibitor reset p/t nets dpo spo gs(t) s (gs(t)) ens sts sts⊆ i (gs(t)) i (gs(t)) cpr nets stsm sts ⊆ m i (gs(t)) i (gs(t)) table 2: encoding petri nets as graph grammars. gs(t) = gs(x ∪ �t,t ⊕ •t) ← gs(x ,t) → gs(x ∪ �t,t ⊕t•) where x = [[•t ⊕t ⊕t•]] and the left and right morphisms are inclusions. the dpo rule gs(t) corresponding to a transition t deletes the edges in its pre-set, preserves the edges in its context and produces the edges in its post-set. the nodes attached to edges in the pre-set, context and post-set (i.e., the set x ) are preserved. finally, the nodes corresponding to the places s ∈ �t in the distinguished set of t are deleted and produced again. it is now immediate to provide the encoding for the different kinds of petri nets into graph grammars of the appropriate approach. definition 17 an enriched petri net n = 〈s, tr, f,c, d, m〉 of one of the six types of nets presented in definitions 12, 13 and 14 is encoded as a kind graph grammar g (n) = 〈t, gs, p, π〉 where • t = ts • p = tr • gs = gs(m) moreover kind and the kind rule π(t) associated to t ∈ p are defined, according to the type of the net, as shown in table 2. obviously, the encoding also works for contextual nets (see the first column of table 1 in the introduction). it can be shown that the encoding preserves the firing relation and reachability, in the sense specified by the next theorem. theorem 1 let n be an enriched petri net of one of the types introduced in section 3, let kind be the type of grammar corresponding to the type of n according to table 2, and let m be a marking of n. if m [t〉m′ in n then gs(m) ⇒ki ndt gs(m ′) in the kind graph grammar g (n); vice versa, if gs(m)⇒ki ndt g ′ in the kind graph grammar g (n) then m [t〉m′′ in n with gs(m′′) = g′. festschrift h.-j. kreowski 14 / 18 eceasst 76540123•s0 1 �� 76540123•s1 1 �� t2 1 �� 76540123• s2 t1 1 �� 22 22 2 1 �� 76540123 s 76540123s3 76540123• s4 s0 s2 ss4s3 s2s0 s1 s3 s4 s ss1 s1 s ss1 ss4s0 s3s2 s1 s3 s4 ss0 s2 s0 s4s3s2 t2 t1 t = gs = figure 5: an enriched petri net n and the corresponding dpo grammar. 4.2 examples in order to provide some more intuition, we briefly discuss the encoding for the various classes of petri nets. 4.2.1 p/t petri nets. as shown in table 2, the behaviour of p/t petri nets is faithfully captured by standard dpo or spo graph grammars. inhibitor nets. when n is a p/t inhibitor net, g (n) is a dpo graph grammar, where the effects of the dangling condition are used to encode inhibitor arcs. as an example, the net in fig. 5, seen as an inhibitor p/t net, is encoded by the grammar in the same figure, interpreted as a dpo grammar. observe that since place s ∈ �t1, i.e., s inhibits transition t1, the rule associated with t1 deletes and produces again the node corresponding to s. in this way the presence of tokens in place s, represented by edges connected to such node, will inhibit the rule because of the dangling condition. reset nets. in the case of a p/t reset net n, the encoding g (n) is an spo grammar and the side-effects related to node deletion turn out to capture precisely the behaviour of reset arcs. as an example the net in fig. 5, seen as a reset p/t net, is encoded by the grammar in the same figure, seen as an spo grammar (by transforming the rule using the function s (.)). the fact that rule t1 deletes and produces again the node s determines, as side effect, the deletion of all edges connected to such node, representing tokens in place s. contextual nets. for contextual p/t nets, i.e., p/t nets where �t = /0 for all t, the rules of the corresponding grammar never delete nodes. hence, the spo and the dpo approaches are interchangeable. in particular, ordinary p/t net transitions t, such that t = �t = /0, are represented by rules with an interface containing only nodes (see the rule corresponding to t2 in fig. 5). 15 / 18 volume 26 (2010) from petri nets to graph transformation systems ss4s0 s3s2 s4 ss2s1 s3s0 s0 s4s3s2 s0 ss4s1 s2 s3 s0 s2 ss4s3 s0 s1 s3 s4s2 t1 figure 6: an stsm derivation which is not a legal sts derivation. 4.2.2 elementary nets. as shown in table 2, enss are encoded as stss. as an example, let us consider again the net n in fig. 5, which can be interpreted as an ens interpreting, correspondingly, the grammar on the right as an sts. observe that, even though there is a match of the rule t1 in the start graph gs, i.e., the lefthand side of the rule is a subgraph of gs, the rule cannot be applied, because there is a contact situation. more precisely, referring to fig. 6, condition (iv) of definition 7 (namely, d∩r = k) is not satisfied, as the intersection between the right-hand side of t1 and the context graph d contains the edge connected to s4 which is not in k. if we interpret n as a cpr net and correspondingly the grammar as an stsm , then the diagram in fig. 6 is a legal derivation: in fact conditions (i − iii) of definition 8 are satisfied, while condition (iv) is not required anymore. 5 concluding remarks and future work in this paper we discussed the encoding of different petri net models into graph transformation systems. our aim was of a methodological nature, and its accomplishments are summarized by the taxonomy proposed in tables 1 and 2. intuitively, the results can be synthesized by the slogan “encode the net once”, that is, a petri net is always encoded essentially in the same way, while different net models correspond to alternative approaches to graph transformation. a relevant issue, which has been neglected in the present paper, concerns the study of concurrency in petri nets and in their graph grammar counterparts. admittedly, there is a shortcoming as far as inhibitor nets are considered (already noted in [bcm05]): if two transitions are inhibited by the same place s, their encodings as dpo rules cannot be executed in parallel, since both rules delete and produce again the node corresponding to s. 76540123•s1 �� 76540123• s2 �� t1 �� 76540123 s t2 �� 76540123s′1 76540123 s′2 for instance, in the inhibitor net ni above the two transitions t1 and t2 can fire concurrently. however, in the corresponding dpo grammar g (ni) the rules associated to t1 and t2 delete and festschrift h.-j. kreowski 16 / 18 eceasst generate again the same node s and thus they are forced to be executed sequentially. the development of a theory encompassing the concurrent behaviour of the involved models represents a stimulating direction of future investigation. we believe that, as it happened in the past, this can lead to a fruitful technology transfer between the petri net and gts worlds. acknowledgements: we acknowledge the anonymous referees for the detailed and constructive comments which allowed us to improve the presentation. bibliography [af73] t. agerwala, m. flynn. comments on capabilities, limitations and “correctness” of petri nets. computer architecture news 4(2):81–86, 1973. [ak77] t. araki, t. kasami. some decision problems related to the reachability problem for petri nets. theoretical computer science 3:85–104, 1977. [bbcg08] f. bonchi, a. brogi, s. corfini, f. gadducci. on the use of behavioural equivalences for web services’ development. fundamenta informaticae 89(4):479–510, 2008. [bc92] l. bernardinello, f. de cindio. a survey of basic net models and modular net classes. in rozenberg (ed.), advances in petri nets: the demon project. lncs 609, pp. 304–351. springer verlag, 1992. [bcm05] p. baldan, a. corradini, u. montanari. relating spo and dpo graph rewriting with petri nets having read, inhibitor and reset arcs. in ehrig et al. (eds.), proceedings of pngt’04. entcs 127(2), pp. 5–28. elsevier, 2005. [ch93] s. christensen, n. d. hansen. coloured petri nets extended with place capacities, test arcs and inhibitor arcs. in ajmone-marsan (ed.), proceedings of icaptn’93. lncs 691, pp. 186–205. springer verlag, 1993. [chhk06] a. corradini, t. heindel, f. hermann, b. könig. sesqui-pushout rewriting. in corradini et al. (eds.), proceedings of icgt’06. lncs 4187, pp. 30–45. springer verlag, 2006. [chs08] a. corradini, f. hermann, p. sobociński. subobject transformation systems. applied categorical structures 16(3):389–419, 2008. [cmr96] a. corradini, u. montanari, f. rossi. graph processes. fundamenta informaticae 26:241–265, 1996. [cmr+97] a. corradini, u. montanari, f. rossi, h. ehrig, r. heckel, m. löwe. algebraic approaches to graph transformation i: basic concepts and double pushout approach. in rozenberg (ed.), handbook of graph grammars and computing by graph transformation. volume 1: foundations. pp. 163–245. world scientific, 1997. 17 / 18 volume 26 (2010) from petri nets to graph transformation systems [cor96] a. corradini. concurrent graph and term graph rewriting. in montanari and sassone (eds.), proceedings of concur’96. lncs 1119, pp. 438–464. springer verlag, 1996. [ehk+97] h. ehrig, r. heckel, m. korff, m. löwe, l. ribeiro, a. wagner, a. corradini. algebraic approaches to graph transformation ii: single pushout approach and comparison with double pushout approach. in rozenberg (ed.), handbook of graph grammars and computing by graph transformation. volume 1: foundations. pp. 247– 312. world scientific, 1997. [eps73] h. ehrig, m. pfender, h. schneider. graph-grammars: an algebraic approach. in book (ed.), switching and automata theory. pp. 167–180. ieee computer society press, 1973. [hp01] a. habel, d. plump. computational completeness of programming languages based on graph transformation. in honsell and miculan (eds.), proceedings of fossacs’01. lncs 2030, pp. 230–245. springer verlag, 2001. [jk95] r. janicki, m. koutny. semantics of inhibitor nets. information and computation 123:1–16, 1995. [kre81] h.-j. kreowski. a comparison between petri nets and graph grammars. in noltemeier (ed.), proceedings of the workshop on graphtheoretic concepts in computer science. lncs 100, pp. 306–317. springer verlag, 1981. [lc94] c. lakos, s. christensen. a general systematic approach to arc extensions for coloured petri nets. in valette (ed.), proceedings of icaptn’94. lncs 815, pp. 338–357. springer verlag, 1994. [lkw93] m. löwe, m. korff, a. wagner. an algebraic framework for the transformation of attributed graphs. in sleep et al. (eds.), term graph rewriting: theory and practice. pp. 185–199. wiley, 1993. [löw93] m. löwe. algebraic approach to single-pushout graph transformation. theoretical computer science 109:181–224, 1993. [ls05] s. lack, p. sobociński. adhesive and quasiadhesive categories. theoretical informatics and applications 39(2):511–546, 2005. [mr95] u. montanari, f. rossi. contextual nets. acta informatica 32(6):545–596, 1995. [pet81] j. peterson. petri net theory and the modelling of systems. prentice-hall, 1981. [re96] g. rozenberg, j. engelfriet. elementary net systems. in reisig and rozenberg (eds.), lectures on petri nets i: basic models. lncs 1491, pp. 12–121. springer verlag, 1996. [vog97] w. vogler. efficiency of asynchronous systems and read arcs in petri nets. in proceedings of icalp’97. lncs 1256, pp. 538–548. springer verlag, 1997. festschrift h.-j. kreowski 18 / 18 introduction algebraic approaches to graph transformation graphs and graph morphisms double-pushout rewriting single-pushout rewriting subgraph transformation systems other kinds of stss graph grammars enriched petri nets place/transition nets elementary nets from enriched nets to graph transformation systems encoding petri nets as graph grammars examples p/t petri nets. elementary nets. concluding remarks and future work lifting parallel graph transformation concepts to model transformation based on the eclipse modeling framework electronic communications of the easst volume 26 (2010) manipulation of graphs, algebras and pictures essays dedicated to hans-jörg kreowski on the occasion of his 60th birthday lifting parallel graph transformation concepts to model transformation based on the eclipse modeling framework enrico biermann, claudia ermel and gabriele taentzer 19 pages guest editors: frank drewes, annegret habel, berthold hoffmann, detlef plump managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst lifting parallel graph transformation concepts to model transformation based on the eclipse modeling framework enrico biermann1, claudia ermel1 and gabriele taentzer2 1 institut für softwaretechnik und theoretische informatik technische universität berlin, germany enrico@cs.tu-berlin.de, claudia.ermel@tu-berlin.de 2 fachbereich mathematik und informatik philipps-universität marburg, germany taentzer@mathematik.uni-marburg.de abstract: model transformation is one of the key concepts in model-driven software development. an increasingly popular technology to define modeling languages is provided by the eclipse modeling framework (emf). several emf model transformation approaches have been developed, focusing on different transformation aspects. this paper proposes parallel graph transformation introduced by ehrig and kreowski as a suitable framework for modeling emf model transformations with multi-object structures. multi-object structures at transformation rule level provide a convenient way to describe the transformation of structures with a variable number of recurring structures, dependent on concrete model instances. parallel graph transformation means the simultaneous application of a set of transformation rules synchronized at the application of a kernel rule. we apply our extended emf model transformation technique to model the simulation of statecharts with andstates. keywords: graph transformation, model transformation, eclipse, emf 1 introduction model-driven software development is considered as a promising paradigm in software engineering. models are ideal means for abstraction and enable developers to master the increasing complexity of software systems. model transformation, e.g. for behavior simulation or for performing model refactoring [1] is a key concept for model-driven software development. the eclipse modelling framework (emf) [2] has evolved to one of the standard technologies to define modeling languages. emf provides a modelling and code generation framework for eclipse applications based on structured data models. the modelling approach is similar to that of mof, actually emf supports essential mof (emof) as part of the omg mof 2.0 specification [3]. emf models can be manipulated by several approaches to rule-based model transformations. a transformation framework for emf models which follows the concepts of algebraic graph transformation [4] as far as possible, is presented in [5, 6]. although graph transformation is an expressive, graphical and formal means to describe computations on graphs, it has limitations. 1 / 19 volume 26 (2010) mailto:enrico@cs.tu-berlin.de, claudia.ermel@tu-berlin.de mailto:taentzer@mathematik.uni-marburg.de lifting parallel graph transformation concepts to emf model transformation for example, when describing the operational semantics of behavioral models, one often has the problem of modeling a variable number of parallel actions at different places in the same model. a simple example are transformations of some object structures occurring multiple times with the same properties (e.g. being contained in the same container, or referencing the same objects). we call such an object structure multi-object structure in this paper. one way to transform multiobject structures is the sequential application of rules such that we have to explicitly encode an iteration over all the actions to be performed. usually, this is not the most natural nor efficient way to express the semantics. thus, it is necessary to have a more powerful means to express parallel actions. as main contribution of this paper, we propose the use of amalgamated graph transformation concepts, based on parallel graph transformation, originally proposed by ehrig and kreowski in [7] and extended to synchronized, overlapping rules in [8], to define emf model transformations with multi-object structures. the essence of amalgamated graph transformation is that (possibly infinite) sets of rules which have a certain regularity, so-called rule schemes, can be described by a finite set of multi-rules modeling the elementary actions. for the description of such rule schemes the concept of amalgamating rules [9] is used in this paper to describe the application of multi-rules in an unknown context. the synchronization of rule applications is done along kernel rule applications which leads to a transformation step being maximally parallel in the following sense: an amalgamated rule, induced by a scheme, is constructed by a number of multi-rules being synchronized at the kernel rule. the number of multi-rules is determined by the number of different matches found such that they overlap in the match of the kernel rule. hence, the transformation of multi-object structures can be described in a general way though the number of actually occurring objects in the instance model is variable. since emf models are graphs with an additional containment hierarchy on object nodes, we lift the concept of amalgamated graph transformation to amalgamated emf model transformations. in our previous paper [5] we showed that a restricted form of emf model transformations can be well described by algebraic graph transformations being based on consistent transformation rules. this opens up the possibility to verify emf model transformations using analysis techniques for graph transformation. in this paper, we prove that this consistency result can be lifted to amalgamated emf model transformation. we show the usefulness of amalgamated emf model transformation by simulating the behavior of statecharts with and-states which may have an arbitrary number of orthogonal components (called regions in uml state machines). for example, when the system enters an andstate, it actually goes to the initial simple state in each region in parallel. the paper is organized as follows. in section 2, we introduce emf models as typed, attributed graphs and present our running example, an emf model for a simplified variant of statecharts with and-states. section 3 reviews the concepts of parallel graph transformation and lifts them to emf transformations with multi-object structures. this section contains our main result on consistency of amalgamated emf model transformations. using emf transformations with multi-object structures, we model a general simulator for statecharts with and-states. section 4 presents related research, and section 5 ends with the conclusions and future work. festschrift h.-j. kreowski 2 / 19 eceasst 2 emf models as typed, attributed graphs with containment the eclipse modeling framework (emf) [2] has evolved to one of the standard technologies to define modeling languages. emf provides a modeling and code generation framework for eclipse applications based on structured data models. the modeling approach is similar to that of mof, actually emf supports essential mof (emof) as part of the omg mof 2.0 specification. containment relations, i.e. aggregations, define an ownership relation between objects. thereby, they induce a tree structure in model instantiations. in [5], we consider emf instance models1 as typed graphs with special containment edges. typing is expressed by a type graph. it has some similarities to a meta-model, but does not contain multiplicities and other constraints. for simplicity, we consider type graphs without inheritance in this paper. for a complete definition of emf model transformation based on type graphs with inheritance, see [5]. since the containment concept plays a special role in emf models, we distinguish a special kind of edge types defining containments in the type graph. definition 1 (graph and graph morphism) a graph g = (gn,ge,sg,tg) consists of a set gn of nodes, a set ge of edges, as well as source and target functions sg,tg : ge → gn . given two graphs g and h, a pair of functions ( fn, fe) with fn : gn → hn and fe : ge → he forms a graph morphism f : g → h, if it has the following properties: 1. ∀e ∈ ge : fn ◦sg(e) = sh ◦ fe(e), with sg(e)∈ gn , and 2. ∀e ∈ ge : fn ◦tg(e) = th ◦ fe(e), with tg(e)∈ gn . if fn and fe are inclusions, then g is called a subgraph of h, denoted by g ⊆ h. definition 2 (type graph tg, containment relation containstg) a type graph tg = (n,e,s,t) is a graph together with a set c ⊆ e of containment edges. we define a containment relation2 containstg ={(n,m)∈ n ×n | ∃c ∈c : s(c) = n∧t(c) = m}∪ {(x,y)∈ n ×n | ∃z ∈ n : (x containst g z∧z containstg y)} based on containstg we create a relation containing cyclic containments only: cyclet g ={(x,y)∈ containstg|(y,x) ∈ containstg}. then a subset of containment edges, called cycle-capable containment edges, is defined whose instances might be part of containment cycles: ccycle = {c ∈ c | (s(c),t(c))∈ cyclet g}. example 1 (emf model for statecharts with and-states) fig. 1 shows the emf model for statecharts with and-states, where an arbitrary number of states may be grouped in orthogonal regions of the same and-state. a state may contains regions, each of them containing states again. we attribute states by boolean flags denoting whether they are initial or final states. states are connected by transitions which are triggered by events. for simulation, a current object is needed which is linked to the currently active states. the current object receives an event, the first element of a queue 1 note that the emf community uses the terms “emf model” for meta-model and “emf instance model” for a model conforming to a meta-model. 2 if there is no confusion, we use infix notation for containstg, e.g. (x containstg y) instead of (x,y)∈ containstg. 3 / 19 volume 26 (2010) lifting parallel graph transformation concepts to emf model transformation figure 1: emf model for statecharts with and-states ( events linked by next links). the type graph with containment corresponding to the emf model in fig. 1 looks like the emf model but has no multiplicities. we have six containment edge types (three of them have type statechart as source, type states starts from type region and type reg starts from type state). types states and reg could lead to cycles in emf instance models (corresponding to graphs typed over the type graph), because there could be theoretically a region r which contains a state which transitively contains region r again. hence, ccycle = {states, reg} is the set of cycle-capable containment edge types in this example. in consistent emf instance graphs, each object node has at most one container and no containment cycles do occur. graphs fulfilling these requirements are called graphs with containment. c-graphs can be related to each other by so-called c-graph morphisms. they are graph morphisms which preserve containment edges. moreover, they have to be compatible with typing morphisms. although emf instance models do not need to be rooted in general, this property is important for storing them, or more general, to define the model’s extent. definition 3 (graph with containment (c-graph)) a graph with containment, short c-graph, is a graph g = (gn,ge,sg,tg) with a distinguished set of containment edges gc ⊆ ge . the containment edges induce the following binary relation containsg (the transitive closure of gc): • containsg ={(x,y)∈ gn ×gn | ∃e ∈ gc : (sg(e) = x∧tg(e) = y)}∪ {(x,y)∈ gn ×gn | ∃z ∈ gn : (x containsg z∧z containsg y)} all containment edges must fulfill the following properties (containment constraints): • e1,e2 ∈ gc : tg(e1) = tg(e2) ⇒ e1 = e2 (at most one container). • (x,x) /∈ containsg for all x ∈ gn (no containment cycles). if g is typed over a type graph t g, there is a graph morphism type : g → t g, called typing morphism which is consistent with containment, i.e. ∀e ∈ gc : typege (e)∈ t gc. festschrift h.-j. kreowski 4 / 19 eceasst please note that a type graph t g is not a c-graph in general (see e.g. our type graph for statecharts in fig. 1 which has a containment cycle). definition 4 (rooted graph) a c-graph g is called rooted, if there is a node r ∈ gn , called root node, such that ∀x ∈ gn with x 6= r : r containsg x. example 2 (consistent emf instance graph) fig. 2 shows a statechart with an and-state. we model an atm (automated teller machine) where the user can insert a bank card and, after the input of the correct pin, can draw a specified amount of cash from her or his bank account. the display region of the and-state shows what is being displayed on screen, and, simultaneously, the card-slot component models whether the card slot is holding a bank card or not. the enter event triggers the transition before the and-state to enter the and-state. the card-sensed event happens if the sensor has sensed a user’s bank card being put into the card slot. this event triggers two transitions in parallel. the next events (pin-input, pin-ok and amount-input) are local to the display region. the end event again triggers two transitions if the current state is any but the welcome state for the display region and holding for the card-slot region. then, the final states are reached and the and-state can be left if the leave event happens. figure 2: emf instance graph: a statechart modelling an atm fig. 3 shows the abstract syntax of the emf instance graph corresponding to the atm statechart in fig. 2. this instance graph is typed over the type graph in fig. 1. the initial state where we want to start the simulation is the start state before the and-state atm is entered. the current object points to the start state and is linked to an initial event queue consisting so far of the single event enter (the event needed to enter the and-state) followed by the special event denoting the queue end. during the simulation, events may be added to the event queue such that the queue holds the events that should be processed during the simulation. for better readability, we write names which are not empty in quotation marks and put the name of a boolean attribute type (initial or final) if its value is true. furthermore, we omitted the containment edges in fig. 3 from the statechart object named atm-sc to all current and event objects, and from the re5 / 19 volume 26 (2010) lifting parallel graph transformation concepts to emf model transformation gion objects to the corresponding transition objects for better readability. links being instances of containments are represented as containments for distinction from usual links. figure 3: abstract syntax of the atm statechart in fig. 2 with current pointer the emf instance graph in fig. 3 is a c-graph since each object is contained in at most one container and there are no containment cycles. the c-graph is rooted, as the root node is the statechart object named atm-sc which contains all objects transitively. festschrift h.-j. kreowski 6 / 19 eceasst 3 emf model transformations with multi-object structures emf models can be manipulated by several approaches to rule-based model transformations. a transformation framework for emf models which follows the concepts of algebraic graph transformation [4] as far as possible, is presented in [6]. but emf model transformations do not always behave like algebraic graph transformation. the main reason is the difficulty to always satisfy the containment constraints of emf. hence, in our previous paper [5], we identify a kind of model transformation rules which lead to consistent emf model graphs (i.e. fulfilling the containment constraints), if applied as normal graph transformation rules to consistent emf model graphs. thus, we identify a kind of emf model transformations which behave like algebraic graph transformations. the advantage of this approach is that we provide a basis to apply the rich theory of algebraic graph transformation [4, 11, 12, 13] to emf model transformations. in section 3.1, we shortly review the basic notions from [5]. then in section 3.2, we introduce amalgamated transformation, i.e. emf model transformation with multi-object structures based on parallel graph transformation concepts and expand the capability of consistent emf transformations by showing that the application of an amalgamated transformation rule to a consistent emf model graph results in a consistent transformed emf model graph again. 3.1 consistent emf model transformation based on graph transformation in the following, we define consistent transformation rules which restrict transformation rules such that their application to a consistent c-graph yields a c-graph again. if the c-graph is rooted in addition, the transformation result is also rooted. definition 5 (transformation rule) a transformation rule, shortly rule, typed over a type graph t g is given by r = (l ⊇ k ⊆ r, type, nac), where l,k and r are c-graphs, type is a triple of typing morphisms type = (typel : l → t g, typek : k → t g, typer : r → t g), and nac is a set of pairs naci = (ni,typeni),i∈ i with l⊆ni (and i being an index set), and typeni : ni →t g a typing morphism, such that typeni ⊇ typel ⊇ typek ⊆ typer for all i ∈ i. as a drawing convention, we omit k. all objects with equal numbers in l and r are also in k and are preserved when the rule is applied. a rule r can contain one or more negative application conditions (nacs) denoting situations which must not exist for the rule to be applicable. a nac may be denoted partially not containing the whole left-hand side of its rule. it can be uniquely completed. definition 6 (matching and application of transformation rules) let r = (l⊇k ⊆r, type, nac) be a transformation rule typed over t g, (g,typeg) a typed c-graph with typeg : g → t g being a typing morphism, and m : l → g a graph morphism. then m is a match with respect to r and (g,typeg), if 1. m fulfills the so-called dangling condition, i.e. ∀n ∈ ln −kn : 6 ∃e ∈ ge −mg(le) with sg(e) = mn(n)∨tg(e) = mn(n) 2. m fulfills the identification condition for nodes, i.e. ∀x1,x2 ∈ ln with mn(x1) = mn(x2) : x1,x2 ∈ kn (analogously for edges) 7 / 19 volume 26 (2010) lifting parallel graph transformation concepts to emf model transformation 3. m satisfies nac, i.e. for each naci = (ni,typeni)∈ nac,i ∈ i there does not exist a graph morphism oi : ni → g such that oi|l = m. given a match m, rule r can be applied to g which means to replace the matched part m(l) by the corresponding right-hand side r of the rule. by g r,m =⇒ h, we denote the direct graph transformation where rule r is applied to g at match m leading to the result graph h. the formal construction of a direct transformation is a double-pushout (dpo) which is shown in the diagram to the right with pushouts (po1) and (po2) in the category of (typed) graphs. graph d is the intermediated graph after removing m(l), and h is constructed as gluing of d and r along k (see [4]). l k r g d h l r m (po1) (po2) example 3 (transformation rule) rule addevent(e), shown in fig. 4, allows to add a new event of name e into the event queue. in this way, the events that should be processed during a simulation run, can be defined in the beginning of the simulation. moreover, events can be inserted also while a simulation is running. figure 4: rule addevent(e) to insert event e into the event queue the application of rule r to c-graph g yields graph h which is not necessarily a c-graph. in the following we present sufficient conditions for rules such that their application to c-graphs result in c-graphs again. for that purpose, the form of allowed transformation rules has to be restricted such that nodes without container (except the root node) and containment cycles do not occur. consistent transformation rules allow the following kinds of actions which change containments: 1. (node creation ) create a new object node and connect it immediately to its container, if there is one. 2. (containment edge deletion ) delete a containment edge together with its target object node or change the container of a preserved object node. 3. (containment edge creation ) create a containment edge with the target object node or change the container of an existing object node. 4. (creation of cycle-capable containment edges ) for an object node contained via a cyclecapable containment edge, change its container only, if the old and the new container of the object node were already transitively related by containment. this pretty restrictively looking condition guarantees that containment cycles are not constructed. festschrift h.-j. kreowski 8 / 19 eceasst please note that an object node is always deleted with its containment relation, due to the dangling condition. thus, we do not need an additional restriction for node deletion. in the following definition, we formalize all actions that preserve consistent containment relations which have been described above. definition 7 (consistent transformation rule) let l′c := lc −kc, r ′ c := rc −kc, l ′ n := ln − kn and r′n := rn −kn . a transformation rule p = (l ⊇ k ⊆ r, type, nac) typed over t g is consistent wrt. containment if for each rule all the following constraints are satisfied: 1. (node creation) ∀n∈r′n with typer(n) = tt g(c) for some c∈t gc: ∃e∈r ′ c with tr(e) = n, 2. (containment edge deletion) ∀e ∈ l′c with tl(e) = n: n ∈ l′n ∨ (n ∈ kn ∧∃e ′ ∈ r′c with tr(e ′) = n) 3. (containment edge creation) ∀e ∈ r′c with tr(e) = n: n ∈ r′n ∨ (n ∈ kn ∧∃e ′ ∈ l′c with tl(e ′) = n) 4. (creation of cycle-capable containment edges) ∀e ∈ r′c which are cycle-capable and n,m ∈ kn with sr(e) = n∧tr(e) = m : ∃e′ ∈ l′c with sl(e ′) = o∧tl(e′) = m : ((o,n)∈ containsl ∧(m,n) /∈ containsl) ∨ (n,o)∈ containsl please note that all conditions in def. 7 have to be fulfilled to call transformation rules consistent. while conditions (1) (3) have to be fulfilled for any kind of containment edges, condition (4) has to hold especially for cycle-capable containment edges. note further that for condition (4), it is sufficient to inspect the containment in the rule’s left-hand side. there cannot be a containment edge from the matched node m to n in c-graph g, because n would have two containers m and o then, and hence g would not be a c-graph. example 4 (inconsistent transformation rule) consider the rule in the upper half of fig. 5. here, a state shall be moved from one region to another region. all rule graphs are c-graphs. the containment types are cycle-capable. figure 5: application of an inconsistent rule leading to a containment cycle the rule is not consistent because it violates condition (4): its application can lead to a cycle as it is shown in the bottom of fig. 5. when applied to g (which is a c-graph), the result is 9 / 19 volume 26 (2010) lifting parallel graph transformation concepts to emf model transformation graph h which is not a c-graph since it has a containment cycle. the reason for condition (4) is to prevent the introduction of cycles in the graph. however, a state still can be moved to another region (not being one of its own regions) using consistent rules without violating condition (4) by defining two rules: a first rule to move the state up the containment hierarchy, and a second rule to move it downwards into the destination superstate (see fig. 6). figure 6: consistent rules for moving states between regions example 5 (consistent transformation rules) rule addevent(e) presented in example 3 is consistent, since for each created object its containment edge is created as well. two further rules are depicted in fig. 7 processing sequential transitions outside of and-states. figure 7: rules sequentialtransition and skipevent rule sequentialtransition processes a transition in the current state which is triggered by the current event. this rule is consistent since the removed event node is deleted together with its containment edge. rule skipevent models the situation that no transition is triggered by festschrift h.-j. kreowski 10 / 19 eceasst the current event. in this case, the event is removed from the event queue, together with its containment edge. in our main theorems in [5], we show that the application of a consistent transformation rule to a consistent (rooted) emf instance graph always results again in a consistent (rooted) emf instance graph. theorem 1 (consistent graph transformation step) let r = (l⊇k ⊆r,type,nac) be a consistent transformation rule and m : l →g be a match to a c-graph g which is typed by typeg : g→ t g. then, the result graph (h,typeh) of direct transformation (g,typeg) r,m =⇒ (h,typeh) is a c-graph. proof. see [5]. theorem 2 (rooted graph transformation step) a consistent graph transformation step (g, typeg) r,m =⇒ (h,typeh) leads to a rooted result graph h if graph g is rooted. proof. see [5]. 3.2 consistent emf model transformations with multi-object structures in this section, we lift the essential concepts of parallel graph transformation [8] to emf model transformation and also lift the consistency result for emf model transformations from section 3.1 to transformations with multi-object structures which we also call amalgamated emf transformations. using parallel graph transformation, a system state modeled by a graph can be changed by several actions executed in parallel. since graph transformation is rule-based without restrictive execution prescription, parallel graph transformation offers the possibility for massively parallel execution. the synchronization of parallel rule applications is described by common subrules, called kernel rules. the simplest type of parallel actions is that of independent actions. if they operate on different objects they can clearly be executed in parallel. if they overlap just in reading actions on common objects, the situation does not change essentially. in graph transformation, this is reflected by a parallel rule which is a disjoint union of rules. the overlapping part, i.e. the objects which occur in the match of more than one rule, is handled implicitly by the match of the parallel rule. as the application of a parallel rule can model the parallel execution of independent actions only, it is equivalent to the application of the original rules in either order [7]. if actions are not independent of each other, they can still be applied in parallel if they can be synchronized by subactions. if two actions contain the deletion or the creation of the same node, this operation can be encapsulated in a separate action which is a common subaction of the original ones. a common subaction is modelled by the application of a kernel rule of all additional actions (modelled by multi-rules). the application of rules synchronized by kernel rules is then performed by gluing multi-rule instances at their kernel rules which leads to the corresponding amalgamated rule. the application of an amalgamated rule is called amalgamated graph transformation. 11 / 19 volume 26 (2010) lifting parallel graph transformation concepts to emf model transformation formally, the synchronization possibilities of actions (multi-rule applications) are defined by an interaction scheme. for consistent amalgamated emf model transformations (also called emf model transformations with multi-object structures), we need consistent interaction schemes where all rules are consistent. definition 8 (interaction scheme) an interaction scheme is = (rk,m) consists of rule rk called kernel rule and a set m ={ri|1 ≤ i ≤ n} of rules called multi-rules with rk ⊆ ri for all 1 ≤ i ≤ n.3 all rules are typed over the same type graph. is is consistent, if all rules are consistent. in addition to the specification of multi-rules as well as their synchronization at a kernel rule, we must specify where and how often a set of multi-rules should be applied. the basic way to synchronize complex parallel operations is to specify a match of the kernel rule and to require that all multi-rules should be applied at all possible matches they have while overlapping with the kernel match (expressing massively parallel execution synchronized at one place). please note that multi-rule matches may overlap in more than the kernel match. for further covering constructions see [8]. definition 9 (amalgamated transformation rule and its application) given an interaction scheme is = (rk,{ri|i ∈ i}) and match mk for the kernel rule rk to c-graph g, is is applied at mk by constructing another interaction scheme is′ = (rk,{r j|1 ≤ j ≤ n}) called interaction scheme instance of is, with each r j being a copy (a rule instance, i.e. a new rule with li ∩l j = lk,ki ∩k j = kk, and ri ∩r j = rk) of some ri for i ∈ i. each copy r j of rule ri is constructed by a different match mi j : li → g, i.e. for each two rule instances r j,rl for all 1 ≤ j < l ≤ n which are copies of the same ri, we have that m j(l j) 6= ml(ll). there are maximal many rule instances r j in the sense that each multi-rule match mi(li),i ∈ i corresponds to the match of one of its rule instances r j: ∀mi : li → g ∃m j : l j → g s.t. mi(li) = m j(l j). an amalgamated transformation rule ra = (la ⊇ ka ⊆ ra,type,nac), shortly amalgamated rule, is a rule where the left-hand sides of all multi-rule instances in is′ are glued over the kernel left-hand side lk yielding la. similarly, ka and ra are constructed. nac is the union of all nac j and nack. type is glued from the typing morphisms of all rule instances. morphism ma, called amalgamated match of ra to g, is constructed by gluing all m j which overlap at mk. example 6 (interaction scheme and amalgamated rule) in fig. 8, a sample interaction scheme is = {rk,{r1}} is shown in the upper left corner. the common sub-action (adding a loop to a object 1) is modeled by kernel rule rk. we have only one multi-rule r1 modeling that at each possible match object 2 shall be deleted together with its containment edge, and a new object shall be inserted such that it is contained in object 1. both the kernel rule and the multi-rule are consistent and the kernel rule is part of the multi-rule. given graph g, we have obviously three different matches from the multi-rule r1 to g which overlap in the match of the kernel rule to g only. hence, we have three multi-rule instances, each of them with a different match to g, and there are no more matches from r1 to g. gluing the multi-rule instances at their common kernel rule, we get the amalgamated rule ra with respect to g, together with match ma : la → g. 3 rk ⊆ ri is valid if lk ⊆ li, kk ⊆ ki, and rk ⊆ ri. festschrift h.-j. kreowski 12 / 19 eceasst figure 8: construction of an amalgamated rule we call a transformation amalgamated (or, alternatively, transformation with multi-object structures) if an amalgamated rule is applied. as with simple rules, an amalgamated rule can only be applied, if the amalgamated match satisfies the gluing condition. note that a special interaction scheme consists of only one rule, i.e. a kernel rule, such that the interaction scheme is applied like a usual sequential rule. theorem 3 the construction in def. 9 yields a unique amalgamated rule up to isomorphism. proof. let is = (rk,{ri|i ∈ i}) be an interaction scheme and mk a match for the kernel rule rk to c-graph g. first, we have to show that there is a unique interaction scheme instance is′ = (rk,{r j|1 ≤ j ≤ n}) of is, with r j being a copy of some ri with i ∈ i such that rk ⊆ r j for all 1 ≤ j ≤ n. since is′ is as large as we find matches of multi-rules, we know that the maximal interaction scheme instance comprises at least all rules of is′ since there is a match m j : l j → g with m j|lk = mk for each rule r j with 1 ≤ j ≤ n, according to def. 9. is ′ does not contain further rules, since there is not a further match m′ of some rule ri with i ∈ i which is different from all matches m j of its copies. hence, is′ is the unique interaction scheme instance for is and mk. the second part of the amalgamated rule construction is the gluing of all multi-rule instances along rk. this gluing construction is unique and does not depend on copy constructions, since multi-rule instances overlap in kernel rules only, i.e. l j ∩ll = lk, k j ∩kl = kk, and r j ∩rl = rk for all 1 ≤ j < l ≤ n. in order to show that emf instance graphs resulting from amalgamated transformation are consistent (theorem 4), we construct the amalgamated rule from a given consistent interaction scheme and show that this amalgamated rule is a consistent transformation rule. afterwards, we can apply theorem 1. 13 / 19 volume 26 (2010) lifting parallel graph transformation concepts to emf model transformation theorem 4 let is = (rk,{r j|1 ≤ j ≤ n}) be a consistent interaction scheme instance and mk : lk →g a match from rk to a c-graph g. then, the amalgamated transformation rule ra resulting from the construction acc. to def. 9 is consistent. proof. case n = 0: there is no match of any multi-rule. the amalgamated rule ra is equal to the kernel rule rk, which is consistent by assumption, since is is consistent. case n = 1: there is one multi-rule instance of a multi-rule ri. the amalgamated rule ra is equal to ri, thus it is consistent by assumption. case n > 1: we have to show that the amalgamated rule ra satisfies all four consistency constraints for transformation rules according to def. 7: 1. (node creation) to show: ∀n ∈ r′an with typer(n) = tt g(c) for some c ∈ t gc: ∃e ∈ r ′ ac with tra(e) = n. w.l.o.g. n ∈ r′jn : then, there is a unique e ∈ r ′ jc with tr′jc (e) = n, since r j is consistent. there cannot be another e∈r′ac with tra(e) = n, since the construction of the amalgamated rule instances results in an overlap of multi-rules in the kernel rule only. (note that the amalgamated match may glue multi-rule matches outside of kernel match.) 2. (containment edge deletion) to show: ∀e ∈ l′ac with tla(e) = n: n ∈ l′an ∨ (n ∈ kan ∧∃e ′ ∈ r′ac with tra(e ′) = n). w.l.o.g. e ∈ l′jc with tl j (e) = n. then, n ∈ l ′ jn ∨(n ∈ k jn ∧∃e ′ ∈ r′jc with tr j (e ′) = n), since r j is consistent. 3. (containment edge creation) to show: ∀e ∈ r′ac with tra(e) = n: n ∈ r′an ∨ (n ∈ kan ∧∃e ′ ∈ l′ac with tla(e ′) = n) w.l.o.g. ∀e ∈ r′jc with tr j (e) = n. then, n ∈ r ′ jn ∨(n ∈ k jn ∧∃e ′ ∈ l′jc with tl j (e ′) = n), since r j is consistent. 4. (creation of cycle-capable containment edges) to show: ∀e ∈ r′accycle with sra(e) = n∧tra(e) = m : ∃e ′∈ l′ac with sla(e ′) = o∧tla(e ′) = m : ((o,n)∈ containsla ∧(m,n) /∈ containsla) ∨ (n,o)∈ containsla . w.l.o.g. e ∈ r′jccycle with sr j (e) = n∧tr j (e) = m. then, there is e′ ∈ l′jc with sl j (e ′) = o∧tl j (e ′) = m : ((o,n)∈ containsl j ∧(m,n) /∈ containsl j ) ∨ (n,o)∈ containsl j . in addition, we have to show that there is no (m,n) ∈ containsl j for some l 6= j. since r j and rl overlap in rk only, m,n ∈ l′kn ⊆ l ′ jn and (m,n) /∈ containsl j =⇒ (m,n) /∈ containsll . festschrift h.-j. kreowski 14 / 19 eceasst corollary 1 given a consistent interaction scheme is = (rk,{ri|1 ≤ i ≤ n}) and matches mk and mi to g for all 1 ≤ i ≤ n. then, if g is a c-graph, the result graph h after applying interaction scheme is to g is a c-graph as well. proof. due to theorem 4, the amalgamated rule constructed from is is consistent. by theorem 1, consistent rules preserve c-graphs. hence, the result graph h is again a c-graph. corollary 2 given a consistent interaction scheme is like in corollary 1. then, if g is a rooted c-graph, the result graph h after applying the interaction scheme is to g is a rooted c-graph as well. proof. due to theorem 4, the amalgamated rule constructed from is is consistent. by theorems 1 and 2, we know that consistent rules preserve c-graphs and the rootedness of c-graphs. hence, the result graph h is a rooted c-graph. example 7 (simulator for statecharts with and-states) in our statecharts variant, every region belonging to an and-state has exactly one initial state and at least one final state. the intended semantics for our statecharts requires that if an and-state is reached, the active states become the initial ones of each region. a transition is processed if its pre-state is active and its triggering event is the same as the event which is received by the current object (the first event in the queue). afterwards, the state(s) following the transition become(s) active, the event of the processed transition is removed from the queue, and the previously active state(s) (the pre-state(s) of the transition) is/are not active anymore. more than one transition are processed simultaneously if they belong to different regions of the same and-state, if their pre-states are all active and if they are all triggered by the same event which is received by the current object. all regions belonging to the same and-state must have reached a final state before the and-state can be left and the transition from the and-state to the next state can be processed. for our simulator we use the current object not only as object which receives the next event (and is linked to the event queue) but also as pointer to the current active states. thus, our simulation rules model the relinking of the current object to the next active states and the updating of the event queue. note that in the following screenshots of interaction schemes we use an integrated notation, where we define the kernel rule and one multi-rule within one rule picture. this is possible since each of our interaction schemes consists of a kernel rule and one multi-rule only. we distinguish objects belonging to the multi-rule by drawing them as multi-objects (with indicated multiple boxes instead of simple rectangles). the kernel rule consists of all simple objects which are not drawn as multiple boxes. all arcs adjacent to multi-objects belong to the multi-rule only, but not to the kernel rule. all multi-objects together with their adjacent arcs in one multi-rule form a multi-object structure. the upper part of fig. 9 shows the interaction scheme enterregion which moves the current pointer along a transition that connects a state to an and-state. in this case, the current pointer has not only to point to the and-state afterwards but also to all initial states of all regions of the and-state. hence, the amalgamated rule consists of as many copies of the multi-rule as there are regions in the and-state (provided that each component has exactly one initial state which has to be ensured by a suitable syntax grammar). 15 / 19 volume 26 (2010) lifting parallel graph transformation concepts to emf model transformation figure 9: interaction schemes enterregion and leaveregion vice versa, when an and-state is left, the current pointer has to be removed from all of its regions. this step is realized by the interaction scheme leaveregion at the bottom of fig. 9. the fact that the active states of all regions have to be final is modelled by the nac. the multi-rule models how all inner links from the current pointer to the regions’ final states are removed. a simultaneous transition is modelled by interaction scheme simultantrans in fig. 10. here, an arbitrary number of transitions in different regions of an and-state are processed if triggered by the same event. in our atm example this happens at different points of the simulation: when the and-state is entered and the event card-sensed is happening, then the two first transitions of the two regions are processed simultaneously. similarly, at any state of the display the user can abort the transaction: the end event triggers the return of the display region to state welcome and the return of the card-slot region to state empty. figure 10: interaction scheme simultantrans the simultantrans interaction scheme is a good example for a concise way to model simultaneous transitions which are triggered by a single event. this would be quite difficult to model festschrift h.-j. kreowski 16 / 19 eceasst using simple rules. note that this scheme is applicable also for sequential transition processing within an and-state. then there is only one copy of the multi-rule, similar to rule sequentialtrans. in the case that no transition leaving an active state is triggered by the current event, we have the situation that there is no copy of the multi-rule of simultantrans, but the kernel rule can be applied anyway. this means that an event which does not trigger any transition inside of an and-state simply is removed from the event queue. again, this is similar to applying rule skipevent with the difference that regions are used here. 4 related work there are two tool-based approaches known to us which also realize parallel graph transformation: atom3 and groove, where atom3 supports the explicit definition of interaction schemes in different rule editors [14] and groove implements rule amalgamation based on nested graph predicates [15]. a related conceptual approach aiming at transforming collections of similar subgraphs is presented in [16]. the main conceptual difference is that we amalgamate rule instances whereas the authors of [16] replace all collection operators (multi-object structures) in a rule by the mapped number of collection match copies. similarly, a cloning operator is defined in [17] where cloned nodes correspond to multi-objects, but complete multi-object structures cannot be described. moreover, the graph transformation tools progres [18] and fujaba [19] feature so-called set nodes which are duplicated as often as necessary, but are not based on amalgamated graph transformation. none of the related approaches support the transformation of emf models. 5 conclusions and future work this paper presented amalgamated emf transformation as a valuable means for modelling and simulation. they extend the capabilities of emf transformation based on simple graph transformation [5] by allowing parallel execution of synchronized emf transformation rules. this is useful for e.g. specifying simulators for formalisms in which parallel actions can be performed. a concrete example of such a formalism are statecharts with and states. it has been shown in the paper that an amalgamated transformation always leads to a consistent emf instance model which satisfy the containment constraints of emf. in the future, we plan to apply the approach to other kinds of emf model transformations, such as model refactorings where multi-object structures can be found frequently. amalgamated transformations of emf models are currently implemented in the tool emf henshin (formerly called emf tiger [6]), a recently developed eclipse plug-in supporting the specification and interpretation of emf model transformations, based on graph transformation concepts. the goal of emf henshin is to provide the means to graphically define rule-based transformations on emf models. rule applications change emf model instances in-place, i.e. an emf instance model is modified directly, without being copied before. moreover, control of rule applications by transformation units [20] is supported, as well as pre-definition of (parts of) the match. emf henshin currently consists of a graphical editor for visually defining emf model transformation rules and an interpreter which executes emf model transformation. in the 17 / 19 volume 26 (2010) lifting parallel graph transformation concepts to emf model transformation near future, the translation of emf transformation rules to agg shall be supported to open up the possibility for verification of transformations. bibliography [1] mens, t., tourwé, t.: a survey of software refactoring. transactions on software engineering 30(2) (february 2004) 126–139 [2] eclipse consortium: eclipse modeling framework (emf) – version 2.4. (2008) http: //www.eclipse.org/emf. [3] object management group: meta object facility (mof) core specification version 2.0. http://www.omg.org/technology/documents/modeling spec catalog.htm#mof (2008) [4] ehrig, h., ehrig, k., prange, u., taentzer, g.: fundamentals of algebraic graph transformation. eatcs monographs in theor. comp. science. springer (2006) [5] biermann, e., ermel, c., taentzer, g.: precise semantics of emf model transformations by graph transformation. in proc. conf. on model driven engineering languages and systems (models’08). vol. 5301 of lncs., springer (2008) 53–67 [6] biermann, e., ehrig, k., köhler, c., kuhns, g., taentzer, g., weiss, e.: graphical definition of in-place transformations in the eclipse modeling framework. in proc. conf. on model driven engineering languages and systems (models’06). vol. 4199 of lncs. springer (2006) 425–439 [7] ehrig, h., kreowski, h.j.: parallel graph grammars. in lindenmayer, a., rozenberg, g., eds.: automata, languages, development. north holland (1976) 425–447 [8] taentzer, g.: parallel and distributed graph transformation: formal description and application to communication-based systems. phd thesis, tu berlin (1996) [9] böhm, p., fonio, h.r., habel, a.: amalgamation of graph transformations: a synchronization mechanism. journal of computer and system science 34 (1987) 377–408 [10] tiger project team, technische universität berlin: emf tiger (2009) http://tfs.cs. tu-berlin.de/emftrans. [11] ehrig, h., kreowski, h.j., montanari, u., rozenberg, g., eds.: handbook of graph grammars and computing by graph transformation. vol 3: concurrency, parallelism and distribution. world scientific (1999) [12] ehrig, h., engels, g., kreowski, h.j., rozenberg, g., eds.: handbook of graph grammars and computing by graph transformation, vol. 2: applications, languages and tools. world scientific (1999) [13] rozenberg, g.: handbook of graph grammars and computing by graph transformations, vol. 1: foundations. world scientific (1997) festschrift h.-j. kreowski 18 / 19 http://www.eclipse.org/emf http://www.eclipse.org/emf http://www.omg.org/technology/documents/modeling_spec_catalog.htm#mof http://tfs.cs.tu-berlin.de/emftrans http://tfs.cs.tu-berlin.de/emftrans eceasst [14] de lara, j., ermel, c., taentzer, g., ehrig, k.: parallel graph transformation for model simulation applied to timed transition petri nets. in: proc. graph transformation and visual modelling techniques (gtvmt) 2004. (2004) [15] rensink, a., kuperus, j.h.: repotting the geraniums: on nested graph transformation rules. in: int. workshop of graph transformation and visual modelling techniques (gtvmt’09). (2009) [16] grønmo, r., krogdahl, s., møller-pedersen, b.: a collection operator for graph transformation. in: int. conf. on model transformation (icmt’09). (2009) [17] hoffmann, b., janssens, d., van eetvelde, n.: cloning and expanding graph transformation rules for refactoring. in: int. workshop on graph and model transformation (gramot’05). vol. 152 of entcs, elsevier (2006) 53–67 [18] schürr, a., winter, a., zündorf, a.: the progres-approach: language and environment. in [12]. [19] fischer, t., niere, j., torunski, l., zündorf, a.: story diagrams: a new graph rewrite language based on the uml. in proc. workshop on theory and application of graph transformation. vol. 1764 of lncs, springer (2000) 296–309 [20] kreowski, h.-j. and kuske, s.: graph transformation units with interleaving semantics. formal aspects of computing. vol. 11, no. 6 (1999) 690–723 19 / 19 volume 26 (2010) introduction emf models as typed, attributed graphs with containment emf model transformations with multi-object structures consistent emf model transformation based on graph transformation consistent emf model transformations with multi-object structures related work conclusions and future work abstract models and cognitive mismatch in formal verification electronic communications of the easst volume 45 (2011) proceedings of the fourth international workshop on formal methods for interactive systems (fmis 2011) abstract models and cognitive mismatch in formal verification rimvydas rukšėnas and paul curzon 5 pages guest editors: judy bowen, steve reeves managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst abstract models and cognitive mismatch in formal verification rimvydas rukšėnas and paul curzon r.ruksenas@eecs.qmul.ac.uk, paul.curzon@eecs.qmul.ac.uk school of electronic engineering and computer science queen mary university of london, united kingdom abstract: we present ongoing work to accommodate fine-grained analysis of interactive systems via model checking. we argue that this can be achieved by combining a basic abstract model of user behaviour and a separate constraint on the acceptable degree of cognitive mismatch. to explain the problem and illustrate our approach, we present a simple scenario related to number entry in infusion pumps. keywords: user models, cognitive mismatch, model checking, number entry 1 introduction in hci, models of human cognition are used in different ways and for various purposes. one approach, computational cognitive models [ry01], draws from cognitive science and is applied to test and improve usability of interfaces, e.g., by predicting behaviour, time [jk96] and error [gra00]. the analysis of system properties is based on individual simulation runs, meaning that the essentially deterministic models predict likely user behaviours and their properties. an alternative approach (e.g., [rus01]), drawn from formal methods, focuses on safety-critical aspects of interactive behaviour. compared to simulation-based approaches, the models are abstract and highly non-deterministic. this generates a wide range of behaviours and allows exhaustive exploration of the consequences of all possible model behaviours using automatic tools such as model checkers. models of cognition usually include consideration of the capabilities and limitations of the user. one aspect to consider is the human capability to create mental models of the device and interaction, and then to rely on those models to a certain extent while interacting with the device. such mental models can be based on device manuals, training or simply previous experience with similar devices. they lead to certain expectations and assumptions about the device behaviour. depending on situation, these expectations and assumptions may or may not be justified. this potentially leads to cognitive mismatches between the mental model and the actual state of the system, which can result in erroneous user actions [rus01]. there are at least two ways of dealing with cognitive mismatches in interactive systems. the most obvious way is akin to the safety view of the reliability of computer systems. it tries to detect cognitive mismatches and fix them by modifying interfaces (e.g., rushby’s work on mode confusions [rus02]). though this is an essential and useful thing to do, in general, one cannot assume that users will form correct mental models, even when all the required information is present on the device interface or within the interactive system more generally. this might be due to high cognitive load, interruptions or other facets of the system being more salient, for 1 / 5 volume 45 (2011) mailto:r.ruksenas@eecs.qmul.ac.uk mailto:paul.curzon@eecs.qmul.ac.uk abstract models and cognitive mismatch in formal verification example. consequently, the alternate resilience view to system safety accepts that cognitive mismatches are unavoidable and tries to safeguard against them. we have developed a generic model of cognitively plausible behaviour based on empirical findings [rbcb09]. the model was applied, e.g., to perform goms-style analysis of timing [rcbb08] using the sal model checker. in all our earlier work, the formalisations of cognitively plausible behaviour include built-in assumptions about how cognitive mismatches are handled. consequently, the outcomes of our analyses were relative to those assumptions. a problem with this is agreeing on what assumptions are generally plausible, since usually cognitive plausibility is situated, i.e., dependent on the task, its context and on behavioural strategies. including such assumptions into user models also makes their inspection and validation less tractable. here we consider an approach where assumptions on cognitive mismatch are split from the user model and illustrate the approach on a simple scenario related to number entry in infusion pumps. infusion pumps require number input giving the rate of infusion and the volume to be infused. they use different styles of number entry. we focus on one incremental style using chevron buttons, though similar issues could arise when modelling interaction with pumps relying on other styles of number entry. 2 motivation plausible behaviours here we sketch how to develop a basic abstract model of plausible user interactions with an infusion pump. we focus on user beliefs related to number entry. consider the subtask of setting the required rate of infusion. let us assume, our infusion pump has four chevron buttons to perform this task (similarly as the alaris family of pumps). pressing the ’up’ single chevron increases the number entered by a certain amount, say delta in our model, whereas pressing the ’up’ double chevron increases it in larger jumps, say delta. the ’down’ chevrons operate in the opposite way. the users of the pump will have their own beliefs about these delta values. let us denote them mdelta and mdelta, respectively. though these beliefs might be right in most cases, there is no reason to assume that a cognitive mismatch is impossible, especially, since the interface does not show the actual delta values. furthermore, they are not constant: when the number increases, the delta values are increased at certain points too. the infusion rate, rate, is displayed on the pump screen as the number is incrementally entered using the chevrons. though the user can check it on the display, there is no guarantee of them doing so on each button press. hence, we have another variable, mrate, to represent the user’s belief about the current rate. to increase the rate value, the users can perform either the ’small rate increase’ or ’big rate increase’ action. let us consider the latter, associated with pressing the ’up’ double chevron, and specify state transitions related to the relevant belief updates. here, the relevant beliefs are represented by variables mrate and mdelta. for mdelta, there are two plausible alternatives. the user model may assume that the delta value is unchanged (mdelta′ = mdelta), or it may correct a wrong belief by updating mdelta with the actual delta value (mdelta′ = delta). likewise, two alternatives associated with the ’big rate increase’ action are plausible for the user’s beliefs about the infusion rate. the model may proc. fmis 2011 2 / 5 eceasst check the current rate value on the display and update their belief, increasing it by the assumed delta value (mrate′ = rate + mdelta). alternatively, it may rely on the rate believed to be current and increase it similarly (mrate′ = mrate + mdelta). similar specifications could be given for the ’small rate increase’ action and the corresponding rate decrease actions, as well as for the actions associated with the volume to be infused. note that, at this level of abstraction, we do not postulate how and when such an update may occur, for which there could be many triggers. next, we discuss issues that may arise when such abstract model is used for the formal analysis of user interaction with the infusion pump. issues being underspecified, the above model can generate extremely large numbers of behaviours: the ’big rate increase’ action as specified above can lead to 4 alternative transitions in each step (2 for mdelta multiplied by 2 for mrate). the number of such steps can be large if anything close to the actual range of numbers in infusion pumps (e.g., 0 – 9999) is used in the model. furthermore, the model would include other plausible number changing actions that could occur at the same time. each will in turn generate a similar number of different transitions. the automatic checking of liveness properties (”something useful is eventually done”), is complicated by having huge numbers of behaviours. the following example liveness property is relevant to our scenario: ”the user model combined with the pump model, in all possible scenarios, eventually sets the target rate of infusion within the specified time bound.” formally, this can be specified in ltl (linear temporal logic) using the temporal operator until as follows: (t < tmax) until (rate = target) where tmax is a time bound, and target is a target rate. model checking properties of this kind in a practically useful time is problematic for abstract models as above. furthermore, the above property will most likely be falsified for any reasonable bound tmax because of the model generating behaviours that, though plausible in principle, are unlikely. for example, as long as the beliefs represented by mrate and mdelta remain wrong, the user model can keep performing the ’big rate increase’ action, even though the actual rate value may already have been higher than the target rate for many steps. obviously, such behaviour is unrealistic; even more so, when the pump user is a nurse trained to use infusion pumps. 3 cognitive mismatches and formal analysis the above model is simple and, therefore, easy to inspect and reason about. it assumes little about pump users, which means that a very wide range of plausible behaviours are generated by it. as such, it is appropriate for the analysis of safety properties (”something bad never happens”) related to user interaction. an example of such a property for our scenario is the following one: ”the user model never confirms a wrong rate of infusion.” setting parameters and starting infusion quickly may be critical in, e.g., operating theatres. as discussed above, our abstract model is less feasible for analysing liveness properties such as timing. although performance of interactive systems can be analysed by other means [jk96], formal timing verification could provide stronger guarantees that critical interactions are sufficiently efficient by exploring a range of plausible but not necessarily optimal behaviours. 3 / 5 volume 45 (2011) abstract models and cognitive mismatch in formal verification in the above model, a major source of the many behaviours is cognitive mismatch. realistically, cognitive mismatches are unavoidable, temporarily at least. therefore, a formal model should not rule them out completely. when analysing liveness properties such as timing, however, it is reasonable to impose certain constraints on the degree of cognitive mismatch assumed by the model. for our scenario, an example of such a constraint could be as follows: ”if the belief maintained by the model about the rate value is correct (mrate = rate), then the belief about the delta value is correct too (mdelta = delta).” one can also postulate that the difference between the actual rate value and user belief is maintained within a certain limit, e.g.: rate−mrate < k×delta intuitively, this states that the user model corrects a wrong belief about the rate no later than performing the ’big rate increase’ action for the k-th time in succession. while constraints as above are plausible for the analysis of efficiency, they are an instance of situated assumptions. for example, it would be generally impossible to justify any specific (and not unreasonably large) k value in the above constraint. therefore, incorporating such situated constraints into the user model could compromise the verification of safety properties, when the same model is used for that. a formal model of plausible behaviour explicitly represents assumptions that must be consistent with actual users for the properties proved to be useful and meaningful in assessment of an interactive system. at the same time, for keeping track of the assumptions made and their inspection and validation, it is advantageous to work with the same set of assumptions (user model) when checking all the relevant properties. we tackle the dichotomy between generality and situatedness by combining two ingredients: a basic abstract model of user behaviour and a separate constraint on the acceptable degree of cognitive mismatch. to specify this constraint, we define a measure of cognitive mismatch. for example, in our scenario, this measure, say d, could be defined as |rate−mrate| div delta the user model is fixed and captures generic assumptions about the users of a specific device. constraints on cognitive mismatch are part of the properties analysed and can vary between properties. for example, the earlier property for timing analysis could be restated as follows: (t < tmax) until (rate = target ∨ ¬(d < k)) where d < k is the constraint on mismatch just defined. intuitively, behaviours that violate this constraint are pruned during model checking when the modified property is used. 4 conclusions the separation of the user model and the constraint on cognitive mismatches offers several advantages. a fixed user model supports consistency throughout the analysis of different aspects of a system. constraints on cognitive mismatch, on the other hand, provide flexibility: they can vary depending on the properties explored. furthermore, the correlation between the assumptions made and the property verified remains explicit, thus easier to analyse. in this way, one can proc. fmis 2011 4 / 5 eceasst explore, for example, the effect that different degrees of the allowed cognitive mismatch make on timing, or the ability of the user model to achieve a task goal. acknowledgements: funded by two epsrc research grants: chi+med (computer–human interaction for medical devices), ep/g059063/1, and extreme reasoning, ep/f02309x/1. bibliography [gra00] w. gray. the nature and processing of errors in interactive behavior. cognitive science 24(2):205–248, 2000. doi:10.1016/s0364-0213(00)00022-7 [jk96] b. e. john, d. e. kieras. using goms for user interface design and evaluation: which technique? acm trans. comput.-hum. interact. 3:287–319, 1996. doi:10.1145/235833.236050 [rbcb09] r. rukšėnas, j. back, p. curzon, a. blandford. verification-guided modelling of salience and cognitive load. formal aspects of computing 21:541–569, 2009. doi:10.1007/s00165-008-0102-7 [rcbb08] r. rukšėnas, p. curzon, a. blandford, j. back. combining human error verification and timing analysis. in gulliksen et al. (eds.), engineering interactive systems. lecture notes in computer science 4940, pp. 18–35. springer berlin / heidelberg, 2008. doi:10.1007/978-3-540-92698-6 2 [rus01] j. rushby. analyzing cockpit interfaces using formal methods. electronic notes in theoretical computer science 43, 2001. doi:10.1016/s1571-0661(04)80891-0 [rus02] j. rushby. using model checking to help discover mode confusions and other automation surprises. reliability engineering and system safety 75(2):167–177, 2002. doi:10.1016/s0951-8320(01)00092-8 [ry01] f. e. ritter, r. m. young. embodied models as simulated users: introduction to this special issue on using cognitive models to improve interface design. int. j. humancomputer studies 55:1–14, 2001. doi:10.1145/320719.322590 5 / 5 volume 45 (2011) http://dx.doi.org/10.1016/s0364-0213(00)00022-7 http://dx.doi.org/10.1145/235833.236050 http://dx.doi.org/10.1007/s00165-008-0102-7 http://dx.doi.org/10.1007/978-3-540-92698-6_2 http://dx.doi.org/10.1016/s1571-0661(04)80891-0 http://dx.doi.org/10.1016/s0951-8320(01)00092-8 http://dx.doi.org/10.1145/320719.322590 introduction motivation cognitive mismatches and formal analysis conclusions electronic communications of the easst volume 43 (2011) proceedings of the 4th international discotec workshop on context-aware adaption mechanisms for pervasive and ubiquitous services (campus 2011) preface 4 pages guest editors: gabriel hermosillo, russell nzekwa, michael wagner managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst preface nowadays, there is a global exponential increase in the use of portable smart devices, such as tablets, smart phones, gps, etc. these small devices have a huge impact on the everyday life of its users, either for work or leisure. as a consequence to this, the availability and behavior of the services that can be used with such devices has become a big concern. moreover, the existing tools still have some limitations to face these concerns properly, given the heterogeneity and the unstable presence of devices and platforms, and the great variability of situations that users might encounter. to overcome these difficulties, and promote the development and widespread deployment of innovative mobile applications, more and more projects are addressing the development of context-aware adaptation mechanisms for leveraging the development of mobile applications. these projects aim at providing simple but powerful integrated approaches to support the development of applications interacting in pervasive and ubiquitous environments. thus, these projects, as well as other projects, tackle the growing complexity of building large and dynamic distributed systems. with regards to this challenge, the campus workshop will focus on the promising approaches in the domain of context-aware adaptation mechanisms supporting the dynamic evolution of the execution context (e.g., network/device/service failures). this volume contains the proceedings of the fourth workshop on context-aware adaptation mechanisms for pervasive and ubiquitous services, held in reykjavik, iceland, on june 9, 2011. the campus workshop is jointly organized by the music, connect, and diva ist projects. it provides a forum for scientists and engineers in academia and industry to present and discuss their latest research. the focus of the conference is the design, implementation, deployment, and evaluation of adaptive platforms and architectures for context-aware environments. this year, the workshop intends to encourage submissions related adaptation issues addressed by some emerging themes in the service computing community: sensor as a service, ambient social services and green it. we had 4 submissions from 4 different countries, among which only 3 papers were selected for inclusion in the program of the workshop. all papers were evaluated by at least four reviewers with respect to their originality, technical merit, presentation quality, and relevance to the workshop themes. the selected papers present the latest results and breakthroughs on middleware research in areas of automotive systems, ubiquitous environments, pervasive environments, ambient computing and multimedia computing. we would like to express our deepest appreciation to the authors of the submitted papers, to all program committee members for their diligence in the paper review and selection process, and to all external reviewers for their help in evaluating submissions. june, 2011 gabriel hermosillo russel nzekwa michael wagner 1 / 4 volume 43 (2011) preface organization steering committee sonia ben mokhtar cnrs, france frank eliassen university of oslo, norway kurt geihs university of kassel, germany svein hallsteinsen sintef ict, norway geir horn sintef ict, norway valérie issarny inria, france romain rouvoy university lille 1, france lionel seinturier university lille 1, france organisation committee program chair gabriel hermosillo inria lille nord europe, france publicity chair russel nzekwa inria lille nord europe, france publication chair michael wagner university of kassel, germany proc. campus 2011 2 / 4 eceasst program committee olivier barais university de rennes 1, france sonia ben mokhtar cnrs, france yolande berbers k.u.leuven, belgium gordon blair lancaster university, uk johann bourcier irisa – univ. rennes 1 & inria, france franck chauvel peking university, china ruzanna chitchyan lancaster university, uk diana comes university of kassel, germany denis conan institut telecom, france geoff coulson lancaster university, uk wolfgang de meuter vrije universiteit brussel, belgium schahram dustdar vienna university of technology, austria frank eliassen university of oslo, norway gabriel hermosillo inria – nord europe, france geir horn sintef ict, norway joseph loyall bbn technologies, massachusetts ilaria matteucci istituto di informatica e telematica, italy rené meier trinty college dublin, ireland nearchos paspallis university of cyprus, cyprus pascal poizat university of evry, france hongyang qu oxford university, uk romain rouvoy university lille 1, france rachid saadi inria, france antonino sabetta sap research sophia–antipolis, france lionel seinturier university lille 1, france sotirios terzis university of strathclyde, uk massimo tivoli university of l’aquila, italy guido urdaneta vrije universiteit, netherlands michael wagner university of kassel, germany external referees kevin pinte vrije universiteit brussel, belgium 3 / 4 volume 43 (2011) preface contents volatile sets: event-driven collections for mobile ad-hoc applications dries harnie, elisa gonzalez boix, andoni lombide carreton, christophe scholliers and wolfgang de meuter context awareness: challenges and opportunities in modern smartphone use nearchos paspallis and gabriel panis towards a flexible and evolvable framework for self-adaptation lucas l. provensi and frank eliassen proc. campus 2011 4 / 4 proofs-as-programs in computable analysis (extended abstract) electronic communications of the easst volume 23 (2009) proceedings of the ninth international workshop on automated verification of critical systems (avocs 2009) proofs-as-programs in computable analysis (extended abstract) ulrich berger 5 pages guest editor: markus roggenbach managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst proofs-as-programs in computable analysis (extended abstract) ulrich berger u.berger@swansea.ac.uk, http://cs.swan.ac.uk/∼csulrich/ university of wales swansea, swansea, sa2 8pp, wales uk abstract: since the work of brouwer, kolmogorov, goedel, kleene and many others we know that constructive proofs have computational meaning. in computer science this idea is known as the ”proofs-as-programs paradigm” or ”curry-howard correspondence”. we present examples from computable analysis showing that this paradigm not only works in principle, but can be used to automatically synthesise practically relevant certified programs. keywords: proof theory, program extraction, exact real number computation, coinduction besides the contributions to its intrinsic domains such as philosophy and the foundations of mathematics there are many applications of logic in areas outside logic. they mainly come from logical disciplines such as set theory, model theory, computability theory and modal logic and include, for example, in mathematics, proofs of the existence of certain algebraic structures, and, in computer science, methods for specifying and verifying computing systems and classifying the complexity of algorithmic problems. these applications are widely known and form a wellestablished part of theoretical and practical research, in particular in computer science. less known are extra-logical applications from proof theory, a branch of logic that has formal proofs as its main object of study. classic results here are bounding informations about functions whose totality (i.e. termination) is proven in a certain formal system. for example, in the case of peano arithmetic the growth of the function is bounded by a transfinite extension of the ackermann function below the ordinal ε0 (the limit of towers of ω exponentials) [gen43, wai72]. if one further restricts the induction scheme to purely existential formulas, then the function is even primitive recursive [par72, göd58]. still, this is of little practical interest since primitive recursion goes far beyond feasible computability. the extraction of (from a computer science point of view) more relevant information, for example polynomial time or lower complexity, can be achieved by further restricting the proof system [bus86, cu93, lei95, bns00, ow05, abhs04]. other kinds of bounding information relevant in approximation theory, functional analysis and similar areas have been obtained rather recently on the basis of kohlenbach’s monotone variant of gödel’s functional interpretation [koh08]. a further large class of applications of proof theory in computer science can be summarised under the so called “proofs-as-programs paradigm” a.k.a. “curry-howard correspondence” which is the observation that –under certain conditions– formal proofs can be viewed and executed as programs. this correspondence is most direct for intuitionistic natural deduction (or hilbertstyle) systems that can immediately be viewed as dependently typed lambda-calculi (or combinatory logics) [hls72, tro73, vd80, glt89] and hence as functional programming languages. 1 / 5 volume 23 (2009) mailto:u.berger@swansea.ac.uk http://cs.swan.ac.uk/~csulrich/ proofs-as-programs in computable analysis (extended abstract) extensions of this correspondence to systems with classical logic have led to interesting techniques such as programming with continuations and control operators [ff87] and extensions of the lambda-calculus such as the lambda-mu-calculus [par92]. in this note we want to draw the reader’s attention to a very direct (and some may say bold) application of the proofs-as-program paradigm namely the extraction of practically useful programs from formal proofs. since proofs are often very long and consist to a large part of purely logical information, it is necessary to remove these purely logical parts and retain only the computationally relevant components. this is achieved by a proof-theoretic technique known as realisability that goes back to kleene and kreisel [kle59, kre59]. the realisability interpretation not only extracts an executable program, but also a specification of that program and a formal proof that the specification is fulfilled. it would be an exaggeration to claim that program extraction is already being applied in practice. however, some substantial case studies have been carried out indicating that the method is feasible and has the potential to become a viable method for safe software engineering in the future. we mention three such case studies: a fast higher-order algorithm for normalising simply typed lambda-terms has been extracted from tait’s normalisation proof [tai67, ber93]. the algorithm is known as “normalisation-by-evaluation” and had been discovered earlier by schwichtenberg [bs91]. this case study was carried out independently in the proof assistants coq, isabelle and minlog [bbls06]. the extracted program is unusual because it utilises higher types of any level to perform a purely syntactic task. the second example is concerned with dickson’s lemma a result in infinitary combinatorics that is used e.g. in gröbner base theory. dickson’s lemma states that for fixed n the set of n-tuples of natural numbers is well-quasiordered (famous generalisations of this are higman’s lemma, kruskal’s theorem and the graph minor theorem). the extracted program computes for every infinite sequence of n-tuples a pair of indices i < j such that the i-th tuple is pointwise ≤ the j-th [bss01]. the interesting aspect of this example is that the program is extracted from the classical i.e. non-constructive proof by nashwilliams [nw63] using a version of friedman’s a-translation [fri78] that translates classical into constructive proofs. finally, we mention the extraction of programs from the intermediate value theorem and the inverse function theorem for continuous real functions with a positive lower bound on the slope [sch06]. these are probable the first non-trivial examples of program extraction in computable analysis. the last of the three case studies above is concerned with problems in constructive analysis, and it uses a constructive representation of real numbers by cauchy sequences. our recent work in program extraction is situated in constructive analysis as well, but is based on a signed digit representation [bh08, ber09a, bl09]. more precisely, we use inductive and coinductive definitions to characterise uniformly continuous functions in such a way that one can extract an implementation of such functions by non-wellfounded trees that act as transformers of signed digit streams. a suitable adaptation of realisability to this setting is described in [ber09b]. we have extracted from constructive proofs programs that compute high iterations of the logistic map, integrals of continuous functions, the constant π , and functions defined power series. the latter two examples make use of a more general setting where the set of signed digits sd := {0, 1,−1}, which is to be thought of as the set of representations of the contractions avd (x) := (d + x)/2 (d ∈ sd), is replaced by an arbitrary set d of endomaps on a set x . large parts of our theory can be developed for arbitrary such structures (x , d) which we call digit proc. avocs 2009 2 / 5 eceasst spaces. this greater generality not only leads to clearer proofs but also to new algorithms, the last two case studies mentioned above being examples. the programs in the latter case study have been extracted “by hand” from proofs in the theory of digit spaces which are “nearly formal”. the implementation of the theory of digit spaces using a suitable proof assistant (for example, minlog or coq) is a matter of future work. the method of program extraction from proofs can be viewed as a consistent and rather radical continuation of methods of program development, advocated by dijkstra and others [dij97, gri81, dj78] where programs are correct “by construction”. whether or not these methods will eventually be accepted and used in practice remains to be seen. the experimental results obtained so far are encouraging, however. bibliography [abhs04] k. aehlig, u. berger, m. hofmann, h. schwichtenberg. an arithmetic for non-sizeincreasing polynomial-time computation. theor. comput. sci. 318:3–27, 2004. [bbls06] u. berger, s. berghofer, p. letouzey, h. schwichtenberg. program extraction from normalization proofs. studia logica 82:25–49, 2006. [ber93] u. berger. total sets and objects in domain theory. ann. pure appl. logic 60:91– 117, 1993. [ber09a] u. berger. from coinductive proofs to exact real arithmetic. in grädel and kahle (eds.), computer science logic. lncs 5771, pp. 132–146. springer, 2009. [ber09b] u. berger. realisability and adequacy for (co)induction. in bauer et al. (eds.), 6th int’l conf. on computability and complexity in analysis. schloss dagstuhl leibniz-zentrum fuer informatik, germany, dagstuhl, germany, 2009. http://drops.dagstuhl.de/opus/volltexte/2009/2258 [bh08] u. berger, t. hou. coinduction for exact real number computation. theory of computing systems 43:394–409, 2008. doi:doi: 10.1007/s00224-007-9017-6 [bl09] u. berger, s. lloyd. a coinductive approach to verified exact real number computation. 2009. to appear: proceedings of automated verification of critical systems (avocs), gregynog, 23-25 september. [bns00] s. bellantoni, k.-h. niggl, h. schwichtenberg. higher type recursion, ramification and polynomial time. ann. pure appl. logic 104:17–30, 2000. [bs91] u. berger, h. schwichtenberg. an inverse of the evaluation functional for typed λ –calculus. in vemuri (ed.), proceedings of the sixth annual ieee symposium on logic in computer science. pp. 203–211. ieee computer society press, los alamitos, 1991. 3 / 5 volume 23 (2009) http://drops.dagstuhl.de/opus/volltexte/2009/2258 http://dx.doi.org/doi: 10.1007/s00224-007-9017-6 proofs-as-programs in computable analysis (extended abstract) [bss01] u. berger, h. schwichtenberg, m. seisenberger. the warshall algorithm and dickson’s lemma: two examples of realistic program extraction. j. autom. reasoning 26(2):205–221, 2001. [bus86] s. buss. bounded arithmetic. studies in proof theory, lecture notes. bibliopolis, napoli, 1986. [cu93] s. cook, a. urquhart. functional interpretations of feasibly constructive arithmetic. ann. pure appl. logic 63:103–200, 1993. [vd80] d. van dalen. logic and structure. springer–verlag, berlin, 1980. [dij97] e. w. dijkstra. a discipline of programming. prentice hall ptr, upper saddle river, nj, usa, 1997. [dj78] b. dines, c. jones. the vienna development method: the meta-language. lncs 61. springer, berlin, heidelberg, new york, 1978. [ff87] m. felleisen, d. p. friedman. control operators, the secd–machine, and the λ – calculus. in wirsing (ed.), formal description of programming concepts — iii. pp. 193–219. elsevier (north–holland), amsterdam, 1987. [fri78] h. friedman. classically and intuitionistically provably recursive functions. in scott and müller (eds.), higher set theory, lecture notes in mathematics. volume 669, pp. 21–28. springer, 1978. [gen43] g. gentzen. beweisbarkeit und unbeweisbarkeit von anfangsfällen der transfiniten induktion in der reinen zahlentheorie. mathematische annalen 119:140–161, 1943. [glt89] j.-y. girard, y. lafont, p. taylor. proofs and types. cambridge university press, 1989. [göd58] k. gödel. über eine bisher noch nicht benützte erweiterung des finiten standpunktes. dialectica 12:280–287, 1958. [gri81] d. gries. the science of programming. springer, 1981. [hls72] j. hindley, b. lercher, j. seldin. introduction to combinatory logic. london mathematical society lecture notes series 7. cambridge university press, 1972. [kle59] s. c. kleene. countable functionals. in heyting (ed.), constructivity in mathematics. pp. 81–100. north–holland, 1959. [koh08] u. kohlenbach. proof interpretations and their use in mathematics. springer monographs in mathematics. springer, 2008. [kre59] g. kreisel. interpretation of analysis by means of constructive functionals of finite types. constructivity in mathematics, pp. 101–128, 1959. proc. avocs 2009 4 / 5 eceasst [lei95] d. leivant. ramified recurrence and computational complexity i: word recurrence and poly–time. in clote and remmel (eds.), feasible mathematics ii. pp. 320– 343. birkhäuser, boston, 1995. [nw63] c. nash-williams. on well-quasi-ordering finite trees. proc. cambridge phil. soc. 59:833–835, 1963. [ow05] g. ostrin, s. wainer. elementary arithmetic. ann. pure appl. logic 133:275–292, 2005. [par72] c. parsons. on n-quantifier induction. jour. symb. logic 37:466–482, 1972. [par92] m. parigot. λ µ –calculus: an algorithmic interpretation of classical natural deduction. in proceedings of logic programming and automatic reasoning, st. petersburg. lncs 624, pp. 190–201. springer, 1992. [sch06] h. schwichtenberg. inverting monotone functions in constructive analysis. in beckmann et al. (eds.), cie 2006: logical approaches to computational barriers. lncs 3988, pp. 490–504. springer, 2006. [tai67] w. tait. intensional interpretations of functionals of finite type i. the journal of symbolic logic 32(2):198–212, 1967. [tro73] a. troelstra. metamathematical investigation of intuitionistic arithmetic and analysis. lecture notes in mathematics 344. springer, 1973. [wai72] s. s. wainer. ordinal recursion, and a refinement of the extended grzegorcyk hierarchy. jour. symb. logic 37:281–292, 1972. 5 / 5 volume 23 (2009) electronic communications of the easst volume 26 (2010) manipulation of graphs, algebras and pictures essays dedicated to hans-jörg kreowski on the occasion of his 60th birthday preface 2 pages guest editors: frank drewes, annegret habel, berthold hoffmann, detlef plump managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst preface this volume of the electronic communications of the easst is dedicated to hans-jörg kreowski on the occasion of his 60th birthday on august 10, 2009. its contributions reflect hansjörg’s main research interests: graph transformation, algebraic specification, and syntactic picture generation. in fact, as hans-jörg’s professional and private engagement spans a considerably wider range of interests and activities, thus exceeding the scope of easst, the present volume was preceded by a collection of essays, personal greetings, and artwork that was presented to hans-jörg on september 5, 2009 at a one-day colloquium in bremen.1 after the colloquium, the authors of contributions within the scope of easst were invited to submit revised versions of their papers for publication in this festschrift. these submissions underwent a second peer reviewing process, and the accepted contributions are presented in this volume. let us mention only a few of the many facets of hans-jörg’s academic career. after graduating in mathematics, he became a research associate at technische universität berlin in 1974. his first papers addressed the application of category theory to automata, but soon his interests moved towards the emerging fields of graph grammars and algebraic specification. graph grammars, in particular, have fascinated hans-jörg ever since, and he has made numerous important contributions to the field which nowadays is called graph transformation. in berlin, he and hartmut ehrig developed the basic theory of the double-pushout approach, the most successful theoretical foundation for graph transformation. lines of research associated with hans-jörg’s name include canonical derivation sequences, the relation between petri nets and graph grammars, and context-free graph languages generated by edgeand hyperedge replacement grammars. most of the work in the latter area was done at universität bremen, where hans-jörg has been a professor since 1982. more recently, hans-jörg and sabine kuske developed graph transformation units as a structuring concept for graph transformation systems and general rule-based systems. another research area started by hans-jörg in bremen are collage grammars for generating pretty pictures—unsurprisingly, given his inclination for the arts. beyond research and teaching in theoretical computer science, hans-jörg has been committing himself to critically analyse how computer applications affect society and to warn of their potential harm—especially in a military context. he has been an active member of the german forum of computer professionals for peace and social responsibility (fiff) since its foundation in 1984, and was its chairman from 2003 to 2009. more information on this branch of hans-jörg’s activities can be found in the collection of essays mentioned above. 1 see http://www.informatik.uni-bremen.de/theorie/hjk60/hjk60/index.html. 1 / 2 volume 26 (2010) http://www.informatik.uni-bremen.de/theorie/hjk60/hjk60/index.html. preface we are very happy that we can honour hans-jörg with this issue of the communications of the easst and thank all the authors for following our invitation to contribute to it. their articles reflect nicely the diversity and importance of hans-jörg’s achievements in theoretical computer science. special thanks go to the referees who did a great job in helping us to evaluate the submissions. collectively we conclude once more by: congratulations, hans-jörg! april 2010 frank drewes annegret habel berthold hoffmann detlef plump festschrift h.-j. kreowski 2 / 2 a generic in-place transformation-based approach to structured model co-evolution electronic communications of the easst volume 42 (2011) proceedings of the 4th international workshop on multi-paradigm modeling (mpm 2010) a generic in-place transformation-based approach to structured model co-evolution bart meyers, manuel wimmer, antonio cicchetti, and jonathan sprinkle 13 pages guest editors: vasco amaral, hans vangheluwe, cécile hardebolle, lazlo lengyel managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst a generic in-place transformation-based approach to structured model co-evolution bart meyers1, manuel wimmer2, antonio cicchetti3, and jonathan sprinkle4 1 university of antwerp, belgium bart.meyers@ua.ac.be 2 vienna university of technology, austria wimmer@big.tuwien.ac.at 3 mälardalen university, mrtc, västerås, sweden antonio.cicchetti@mdh.se 4 university of arizona, united states sprinkle@ece.arizona.edu abstract: in mde not only models but also metamodels are subject to evolution. more specifically, they need to be adapted to correct errors, support new and/or update language features. the direct consequence of such evolutionary steps comprises the problem of managing the co-evolution of existing model instances, which may no longer conform to the new metamodel version. this model migration is intrinsically complex and results in a time-consuming and error-prone process if no adequate support is provided. for tackling this problem, we introduce a new technique to guide the user in solving migration issues in a step-wise manner. the aims are manifold, notably the simplification of the migration specification, the reduction of the effort for the evolver, the control of user intervention, and the optimization of the migration execution itself by allowing in-place adaptation of the existing instances. keywords: metamodel evolution, model co-evolution, in-place transformations 1 introduction in model-driven engineering (mde) not only models but also metamodels are subject to evolution. especially, when domain-specific modeling languages are employed, the necessity of language adaptations arise to reflect changes in the modeling domain as well as in technologies without losing existing models. in multi-paradigm modeling, a necessary consideration is the transformation of models from one paradigm (e.g., modeling language, or semantics) into another, requiring further consideration of the impact of multi-paradigm use if one modeling language must be updated for some reason. figure 1 illustrates the context of this paper at a glance. full arrows are transformations, dashed arrows indicate conformance (i.e., that a model conforms to the language constraints). after evolution ∆ of a metamodel mml, the goal is to migrate models m, which conform to mml, to m′, which conform to mml′, by creating a suitable migration m. thus, (i) dedicated co-evolution languages, like cope [hbj09] and (ii) the usage of model-to-model (m2m) transformation languages [cdep08] have been proposed to migrate models. however, in the first case 1 / 13 volume 42 (2011) mailto:bart.meyers@ua.ac.be mailto:wimmer@big.tuwien.ac.at mailto:antonio.cicchetti@mdh.se mailto:sprinkle@ece.arizona.edu a generic in-place transformation-based approach to structured model co-evolution a new language must be learned, and in the second case, a heavyweight technique is used. currently, there is no approach for step-wise migration of models in combination with systematically modeling the evolution (ensuring that the migrated models conform to the new metamodel). mml mml' m m' δ figure 1: models m have to be migrated when mml evolves. in this paper, we introduce a new approach to guide the user in solving co-evolution issues in a structured, step-wise manner. first, we employ existing in-place transformation languages. as opposed to m2m transformations, in-place transformations are transformations that change the input model instead of creating an output model from scratch [kms+09]. second, we distinguish between syntactic and semantic migration. for syntactic migration, the goal is to make model instance syntactically conform to the new version of the metamodel. semantic migration requires manual adaptation from the evolver, as language constructs’ meaning may have changed. third, for dividingand-conquering the co-evolution process, we formalize metamodel evolution as a difference model consisting of a sequence of simple difference operations. for each difference operation or meaningful group of difference operations (defined by the evolver), a migration is either automatically generated or adapted by the user. fourth, in computing a specific merged metamodel (at each step) to allow in-place transformations, we can ensure that each mi conforms to mmi, thus after all steps each migrated model m′ always conforms to the mml′. the benefits of this technique are manifold, notably: the simplification of the migration specification by reusing the well-known graph transformation formalism of in-place transformations; the ability to express every possible evolution and migration by allowing graph transformation techniques; the reduction of the effort for the user by reusing generically applicable migration rules; the control of user intervention by automated preventive and corrective mechanisms to validate that models conform to the language in each migration step; and the optimization of the migration execution itself by allowing in-place adaptation of the existing instances. 2 example in order to illustrate our approach, we first introduce an evolution scenario on the railroad domain-specific language. a railroad model is shown in figure 2. the model can be used to analyze the behavior of trains riding on the modeled railtrack. figure 2: an example railroad model. a railroad model consists of track elements, on which trains can ride. these elements can be either rails, which point to one other element on the track, or junctions, which point to two different elements on the track. in this example, two trains are riding on a track with one junction, and one train is not located on the track. the syntax of the railroad language is captured in its metamodel, shown in figure 3a. a train can be located on a trainplace, which can be a rail or a split. rails have one link to another trainplace, splits have two. these links are obligatory, so a railroad circuit is always closed. proc. mpm 2010 2 / 13 eceasst splitlink <> link <> trainplace <> on <> train <> split <> rail <> src 0..1 dst 0..1 dst 0..* dst 0..* src 1 src 2 (a) existing metamodel. leftlink <> rail <> railstation <> on <> train <> junction <> rightlink <> link <> length <> value : field trainplace <>src 1 src 1 dst 0..* dst 0..1 dst 0..* dst 0..* src 1 1 src 1 (b) evolved metamodel. figure 3: (a) the existing metamodel, and (b) the evolved metamodel, both modelled in gme. class stereotypes indicate the type of model that will be instantiated in the language. suppose that over time, some changes have been applied to the metamodel. five requirements are implemented. for each requirement it is stated how existing models should be migrated: • split has been renamed to the more intuitive “junction.” in the instance models, each existing split has to become a junction; • trains must be on a trainplace now. in the instance models, trains that are not located on a trainplace have to be removed; • a notion of direction is added: instead of two outgoing splitlinks, a junction now has a leftlink and rightlink direction. in the instance models, the two outgoing links to trainplaces must be replaced with a leftlink and rightlink link. the choice of left and right is made randomly; • a notion of track length has been added to a rail. in the instance models, rails have a length of 1, the default length; • a railstation is introduced as a new kind of rail. in the instance models, rails with more than one incoming link or splitlink are interesting places to build a railstation. the resulting metamodel is shown in figure 3b1. in the remainder of this paper, this evolution scenario will be used to illustrate our structured migration approach. 3 approach whenever a change ∆ is operated on a metamodel, a corresponding migration m should be operated on the existing instances. the creation of migration transformation is closely related to the changes on the metamodel however. therefore, this section starts off with an elaboration on 1 the field attribute for length is a type-safe integer, though this is not shown in the diagram due to the concrete syntax choices of the gme (generic modeling environment) metamodeling paradigm 3 / 13 volume 42 (2011) a generic in-place transformation-based approach to structured model co-evolution the difference model, which is a structured representation of the changes. next, the creation of the migration transformation is presented. 3.1 difference model a number of works proposed the classification of metamodel changes with respect to the effects observable for migration [gkp07, cdep08]; in particular, the changes could require either no migrations of the instances (non-breaking operations), or simple migration adaptations (breaking and resolvable operations), or complex migrations which possibly require user input (breaking and unresolvable operations). if no user input is required, then the operation is resolvable; if a user must specify details of the operation, then it is unresolvable. as migration is directly linked to the metamodel changes, the migration transformation can be created from a difference model representing the evolution of the metamodel. in turn, the difference model is a sequence of difference operations, each of which mapping onto a corresponding migration operation, as summarized in table 1. difference operation migration operation non-breaking operations generalize metaproperty none add non-obligatory metaclass none add non-obligatory metaproperty none extract superclass none breaking and resolvable operations eliminate metaclass eliminate instances eliminate metaproperty eliminate instances push metaproperty eliminate properties from superclass instances flatten hierarchy eliminate superclass instances rename metaclass change instances rename metaproperty change instances breaking and unresolvable operations add obligatory metaclass add default instances add obligatory metaproperty add default instances pull metaproperty add default properties for superclass instances restrict metaproperty remove instance if non-compliant table 1: difference operations based on [cdep08], with their migration operations. the evolutions listed in table 1 represent manipulations that typically occur on a given metamodel, like the addition of a new metaclass (add non-obligatory metaclass), the deletion of an existing metaattribute (eliminate metaproperty), the rename of an element (rename metaclass/metaproperty), and so forth. beside such primitive operations, the table also lists complex evolutions like flatten hierarchy (eliminating a superclass and adding all its properties to the subclasses) or generalize metaproperty (relaxing the cardinality of a property); in those cases, the evolution could also be seen as the composition of simple changes, but it reaches its full meaning when considered as a single adaptation step. for instance, flatten hierarchy flattens the metaclasses involved in a generalization relationship by moving all the existing metaattributes in a selected surviving metaclass and by eliminating all the remaining metaclasses and generalization relationships. analogously, pull metaproperty moves a metaproperty from a set of proc. mpm 2010 4 / 13 eceasst subclasses to their corresponding superclass. it is important to note that all possible changes to a metamodel can be represented by the difference operations of table 1. if the metamodel contains static semantics, in the form of e.g., ocl constraints [obj10], similar operations can be contrived; however, this is left for future work, and is outside the scope of this paper. the classification proposed above highlights the criticality of the metamodel evolution detection and representation in order to achieve a profitable migration of the existing instances. currently, (meta-)model comparison is an active field of research; it is an intrinsically complex task since it has to deal with graph isomorphisms, i.e., with the problem of finding correspondences between two given graphs. in this paper we assume that the metamodel evolution, i.e., ∆ in figure 1, is given, as reflecting the developer intentions, in terms of the operations classified in table 1: it could be obtained as directly traced from a tool, or encoded by hand. for our approach, both techniques are applicable. when the difference operations of table 1 are used for the change ∆ of the railroad example, this results in the difference model in table 2, which is a sequence of method calls. the difference operations are instantiated as method calls, based on the operations of [hbj09], which are predefined migration operations that take some parameters as input. when such a method is executed on the metamodel, the change is applied. note that operations δ3, δ4 and δ5 represent the replacement of splitlink to splitleft and splitright. other representations, such as proper difference languages [cdp07], can be used as well in our approach. nr. operation δ1 renamemetaelement(split, “junction”) δ2 restrictmetaproperty(train.on, 1, 1) δ3 eliminatemetaproperty(junction.splitlink) δ4 addnonobligatorymetaproperty(junction, trainplace, “leftlink”, 1, 1, 0, -1, false) δ5 addnonobligatorymetaproperty(junction, trainplace, “rightlink”, 1, 1, 0, -1, false) δ6 addobligatorymetaproperty(rail, “length”, integer, 1, 1, 1) δ7 addnonobligatorymetaclass(”railstation”, [rail], false) table 2: the difference model ∆ of the railroad evolution. 3.2 migration of instance models in this section it is explained how the instance models are migrated. with our approach, we aim at a high degree of automation, a high degree of control, and high execution performance. automation will reduce the effort for the modeller, thus increase productivity. control will increase correctness of the migration process as well as facilitate the migration process for the evolver. performance will affect scalability, or the time to migrate a number of instance models (out of the scope of this paper, but still a function of the automation and control). the migration process consists of three phases: automated synthesis, manual adaptation and execution. 3.2.1 synthesis in the first phase, we synthesize migration transformations from difference operations. this is done automatically, by generating an instance of the default migration transformation for each difference operation corresponding to table 1. note that the default migration transformation can 5 / 13 volume 42 (2011) a generic in-place transformation-based approach to structured model co-evolution be none, i.e., the identity transformation. moreover, despite a metamodel manipulation could entail multiple migration policies, in general the default one is fixed once for all due to coherence purposes. the left part of figure 4 shows the evolution ∆ of the railroad example, split up into the seven δi, as shown in table 2. in this step-wise approach, the metamodel mml evolves to mml′, over intermediate metamodels mmi. for each δi, a µi is synthesized by applying the transformation g. technically, g is a higher order transformation, because it takes transformation models instead of instance models as input or output [tjf+09]. the instance model m is migrated accordingly to m′. in this case, mm7 = mml′ and m7 = m′. the right side shows one generic migration step, where a metamodel mmi−1 evolves to mmi by applying one difference operation. mi−1 is migrated accordingly. mml mml' δ1 δ2 δ3 δ4 δ5 δ6 m m' μ1 μ2 μ3 μ4 μ5 μ6 δ μ g g g g g g mm1 m1 mm2 m2 mm3 m3 mm4 m4 mm5 m5 δ7 μ7 g mm6 m6 (a) transformation synthesis mmi-1 mmi δi m m μi g i i-1 i (b) single-step figure 4: (a) synthesis of migration transformation µi. (b) a generic migration step. a common transformation g generates each µi based on the properties of mmi, mmi+1. mm_1-2::train o g δ : restrictmetaproperty(train.on, 1, 1) amount = size(obj.) return amount > or amount < amount = size(obj.on) return amount > 1 or amount < 1 2 mm_::i-1 i obj obj template restrictmetaproperty μ2 figure 5: creating a migration transformation µ2 from difference operation δ2 and a transformation template using merged metamodel mm1,2. figure 5 shows an example of the synthesis of the migration operation µ2. the migration operation is created from difference operation δ2 (shown on top) and the template (shown on the left). the template for the migration operation for the “restrict metaproperty” difference operation is shown. the template specifies the default migration behavior: instances that do not conform to the evolved, more restricted, metamodel are removed. removal is denoted by the “x” symbol on the element. the generic template of the migration transformation rule on the left side is completed with the information provided by the parameters of the difference operation on the top side. the resulting migration transformation rule on the right side deletes trains that do not have exactly one on link. note that the resulting rule is an in-place transformation rule, and no model-to-model transformation. the in-place transformation captures only the essence proc. mpm 2010 6 / 13 eceasst of the migration problem, lowering the degree of accidental complexity. length <> value : field rightlink <> leftlink <> link <> on <> junction <> rail <> trainplace <> train <> 0..1 src 1 dst 0..* dst 0..1 src 1 dst 0..* src 1 dst 0..* src 1 figure 6: the merged metamodel mm5,6 used for µ6. in order to allow in-place transformation, the metamodels of the sourceand target models must be the same. in our case, the metamodels mmi−1 and mmi are very similar but not the same. therefore, we merge both metamodels into one metamodel mmi−1,i, to which models mi−1 as well as models mi conform. mmi−1,i can be automatically generated from mmi−1 and δi, so that mmi−1,i = merge(mmi−1,δi): initially, mmi−1,i = mmi−1. if δi is additive, the change is applied to mmi−1,i. if δi is subtractive, the to be deleted element is kept in mmi−1,i. if δi is updative, the updated version is added to mmi−1,i without removing the old version. no matter what kind of change, the metamodel is “relaxed” so that all possible mi−1 and mi conform to mmi−1,i. this is in particular important for obligatory changes, which are made non-obligatory in the merged metamodel by relaxing the cardinality of the involved associations. figure 6 shows the merged metamodel mm5,6 that is used for the migration transformation µ6 that implements the introduction of the length attribute. notice that all changes δ1 to δ5 are already carried through, as migration step 6 is reached. δ7 is disregarded for now, as this step is not reached yet. δ6 is an additive change, so the new element, i.e., the length feature, is added to the merged metamodel. additionally, the cardinality is relaxed so that the length feature is not obligatory. once the default migration operation is synthesized for each δi, the instance models m can be migrated by executing the sequence of in-place transformations m = µi ◦ µi−1 ◦ ...◦ µ2 ◦ µ1 of figure 4a. by construction, the resulting m′ = m(m) will syntactically conform to mml′. 3.2.2 manual adaptation technically, the first phase fulfills the requirement for co-evolution, namely ensuring that the new models conform to the new language. syntactic migration is thereby accomplished. in the railroad evolution, however, there are also cases of semantic migration. examples are the introduction of the notion of direction and the introduction of the railstation. semantic migration is done during the manual adaptation phase. in this phase, each δi and corresponding default µi are one by one presented by the evolver. for each µi, the evolver can choose from four possible actions: • keep the default µi. if the evolver is satisfied with the default µi, nothing has to be done for this step. this action is typically applied for non-breaking or breaking and resolvable changes; • edit the default µi. the evolver might be satisfied with the structure of the default µi, but might wish to alter µi slightly to µ ′ i . this action is typically applied for breaking and resolvable changes or breaking and unresolvable changes; • group the current µi with following µi+1. in some cases, a number of difference operations can be grouped as one conceptual change, requiring one µ ′ s (with s a sequence of consecutive indices) for two or more difference operations; 7 / 13 volume 42 (2011) a generic in-place transformation-based approach to structured model co-evolution mml mml' δ1 δ2 δ3 δ4 δ5 δ7 m m' μ1 μ2 μ'3,4,5 μ'7 δ μ mm1 mm2 mm5 m1 m2 m5 g δ6 μ6 mm6 m6 gg figure 7: the step-wise migration after the manual adaptation phase. • create a tailored migration for the corresponding difference operation. if the evolver has a migration transformation in mind that is completely different than the default one, he/she can create his/her own. the action is typically applied for non-breaking (if the evolver actually wants to migrate instead of doing nothing) or breaking and unresolvable changes. note that by first grouping and next creating, the original µi and µi+1 are replaced by one µ ′ i,i+1 that covers both the migration of δi and δi+1. also note that so-called model specific migration can be introduced here, requiring user input at migration time [hbj09]. figure 7 shows the result of the railroad migration after the manual adaptation phase. µ1, µ2 and µ6 are kept, µ ′ 7 is created manually and δ3, δ4 and δ5 have been grouped (introducing the notion of direction) and µ ′ 3,4,5 is created manually. figure 8 shows the custom migration transformation µ ′ 3,4,5. two splitlinks are replaced by a leftlink and a rightlink, which covers the migration of the three changes δ3, δ4 and δ5. sl1 railroad-original::splitlink left railroad-evolved::leftlink split railroad-original::split tp2 railroad-original::trainplace sl2 railroad-original::splitlink right railroad-evolved::rightlink tp1 railroad-original::trainplace srcleftlink 0..* dstsplitlink 0..* dstleftlink 0..* dstrightlink 0..* dstsplitlink 0..* srcrightlink 0..* srcsplitlink 0..* srcsplitlink 0..* figure 8: the customized migration transformation µ ′ 3,4,5 introducing the notion of direction. in this transform, items with a check are created, and items with an x are removed from the models. a new problem arises when allowing the evolver to manually create migration operations. after this phase, it cannot be guaranteed anymore that m′ conforms to mm′, as the evolver is allowed to implement anything he/she wants in the customized migration transformations. in our framework, we offer a solution to uphold this guarantee by providing maximal control over the creation of the migration operation, while still offering full expressiveness. this control is provided by two mechanisms, a preventive mechanism and a corrective mechanism: restricted metamodel: as a preventive mechanism, it is only allowed to use language constructs of the corresponding difference operation(s) when editing or creating a µ ′ s (with s a sequence of one or more consecutive indices, though in many cases this is just one index x, as suggested in figure 7). this means that we consider only a part of the total evolution for this migration, particularly proc. mpm 2010 8 / 13 eceasst mmmin(s)−1 to mmmax(s) (in the case of |s| = 1 this would be mmx−1 to mmx), as intended by the step-wise migration. again, changes of a previous evolution step δi with i < min(s) are considered carried through, and changes any future evolution step δ j with j > max(s) are not yet considered at all. for example when creating µ ′ 3,4,5 in figure 7, the changes δ1 and δ2 are carried through, and changes δ6 and δ7 are disregarded for now. only for changes δ3, δ4 and δ5, will a migration transformation be created, aiding transformation modularity. technically, this degree of control is achieved by merging the metamodels mmmin(s)−1 and mmmax(s) into a merged metamodel mmmin(s)−1,max(s). this way, an in-place transformation can be created. since in this context it is possible that a µ ′ is created for more than one δ , the merged metamodel can include more than one δ . the merging algorithm described above can be used recursively. for example if s = (3,4,5) then mm2,3,4,5 = merge(merge(merge(mm1,δ2),δ3),δ4) is the metamodel used in the µ ′ 3,4,5 in-place transformation. mm2,3,4,5 is shown in figure 9. notice the cardinality relaxation of splitlink, leftlink and rightlink; checkout transformation: as a corrective mechanism, full model conformance is ensured of the partly migrated instance model to the partly evolved metamodel in the checkout transformation γ . this step is automatically achieved in our approach by applying the default migration transformations of the difference operations immediately after the customized migration step, i.e., γi ◦µ ′ i . after all, the default migration transformation is constructed so that its output models are syntactically correct. this way, e.g., instances of deleted metaclasses that are by accident not deleted by the customized migration transformation, are deleted by the checkout transformation, thereby ensuring conformance to the partly evolved metamodel. typically however, the evolver has designed his/her customized migration transformation so that model conformance is already ensured. the checkout transformation merely validates conformance in the general case. m is composed of usual transformation models, is stored as any other transformation model. thus, future instance models conforming to the old version can be migrated later. 3.2.3 execution junction <> splitlink <> rightlink <> leftlink <> rail <> on <> link <> train <> trainplace <> src 1 src 0..2 src 0..1 dst 0..1 src 0..1 dst 0..* dst 0..* dst 0..* src 1 dst 0..* figure 9: the merged metamodel mm2,3,4,5 used for µ ′ 3,4,5. at first glance, the execution of the migration suite m is straightforward. on all instance models m, m is applied. more specifically a sequence of in-place transformations, like µi, µ ′ j and γ j, are applied in the given order. the ad hoc execution is not optimal however: in order for each of the in-place transformations to be executed, the instance model must be converted to that particular merged metamodel of the step. after execution, the result must be converted to the partly evolved metamodel. for example, a model m5 conforming to mm5, must be converted first to mm5,6. then, the in-place transformation µ6 can be applied, and the resulting model must be converted to metamodel mm6. these conversions are trivial: a simple search/replace script on the data file of the instance model or a trivial transformation that implements a one-to-one mapping of elements can be automat9 / 13 volume 42 (2011) a generic in-place transformation-based approach to structured model co-evolution ically generated. however, this can cripple the execution performance of the migration. in figure 10, a conversion is needed every time a different metamodel is used (i.e., a grey vertical line is crossed) throughout the execution of m. the top of figure 10 represents the naive execution, requiring many conversions. as a solution, after creation of migration transformation m, the different metamodels used in the in-place transformations are relaxed to the merged metamodel that spans all δi in ∆. all possible instance models throughout all migration steps can be expressed in the resulting metamodel mm∆. every in-place transformation’s used metamodel is changed to mm∆. of course, this has to be done only once for m instead of for all instance models. with this optimized approach, an m that needs to be migrated only has to be converted twice: before applying the in-place transformations of m, and after applying the in-place transformations of m. in between, all artefacts use the same metamodel mm∆, and only in-place transformations are applied. the bottom of figure 10 represents the optimized execution. the absence of model-to-model transformations adds to the execution performance of the migration because after evolution, it is probable that models only change slightly, if at all. if the evolver is confident in his/her customized migration transformation, he/she has the option to disable the execution of the checkout transformations, further improving the execution time of m. m m' μ1 μ2 μ'3,4,5 μ'7 m1 m2 m5 μ6 m6 γ3 γ4 γ5 γ7 m m 1 m m l m m 0 ,1 m m 1 ,2 m m 2 m m 2 ,3 ,4 ,5 m m 5 m m 5 ,6 m m 6 m m 6 ,7 m m l ' m m' μ1 μ2 μ'3,4,5 μ'7 m1 m2 m5 μ6 m6 γ3 γ4 γ5 γ7 m m l m m δ m m l ' figure 10: the naive execution needing a lot of conversions (top) and the optimized execution needing only two conversions (bottom). 4 related work co-evolution has been subject for research since the introduction of object-oriented database systems [bkkk87], consequently a significant body of knowledge exists (cf. [rod92] for a survey) how to migrate data with the goal of preserving as much information as possible. however, in modeling language evolution, the changes to model semantics adds a new “twist” to problems faced in database schema evolution. in this section we focus on most closely related approaches dedicated to reflecting changes of metamodels on models. sprinkle et al. [sk04] considered co-evolution of models by using changed semantics to design co-evolution transformations. this differs from a syntactically driven approach that uses proc. mpm 2010 10 / 13 eceasst the metamodel deltas. in that work as well as in [sgm09], the authors proposed that syntactical co-evolution (where the importance is only to load, but not interpret, the models) is feasible automatically, but it seems to be impractical for semantic evolution. in the general case of semantic evolution concerns, semantics-preserving transformations must be developed by language engineers manually, based on their understanding of the semantic intent of the original models. however, for specific cases, semantically-preserving co-evolution transformations are possible. in this work, we are following this distinction by proposing an approach based on in-place graph transformations (1) for providing predefined transformations for syntactical migration and (2) for developing specific transformations for semantical migration. there are several approaches for co-evolution which are based on m2m transformations. garces et al. [gjcb09] proposed a set of heuristics to automatically compute differences between two metamodel versions in order to adapt models. the computed differences are stored in a so-called matching model, acting as input for a higher-order transformation (hot), producing a migration transformation. cicchetti et al. [cdep08] presented a similar approach, i.e., the approach is again based on a metamodel differences acting as input for a hot. in [wac07], wachsmuth proposed to combine ideas from object-oriented refactoring and grammar adaptation to provide the basis for automatic (meta)model evolution. in this respect, metamodel relations are defined based on m2m transformations, building the basis for the definition of semantics preservation and instance preservation. gruschko et al. [gkp07] tackled co-evolution of models by using m2m transformations by following a conservative copying algorithm. conservative copying means that for initial model elements for which no transformation rule is found a default copy transformation rule is applied. this algorithm is implemented in model migration framework flock [rkpp10]. in [nlbk09] the model change language (mcl) is introduced. mcl is declarative and graphical language supporting a set of co-evolution idioms and conservative copying. co-evolution rules going beyond the supported idioms have to be defined in terms of c++ code. most of the mentioned m2m-based approaches intend to shield a user from creating standard copy rules by providing matching techniques or conservative copying techniques. however, the non-automatically derivable parts have to be manually defined which seems to be more challenging for the user compared to using in-place transformations. this is due to the fact that the user has to reason on how elements look like in the source model, how elements are represented in the target model, and how they are transformed by analyzing the trace information enforcing the user to work with three models. in contrast, in our approach, only one model is necessary for defining the co-evolution rules by using our unified metamodel in combination with in-place transformations. herrmannsdoerfer et al. proposed cope [hbj09] for specifying the coupled evolution of metamodels and models. the co-evolution of metamodels and corresponding models is realized by a set of so-called coupled transactions, composing a whole co-evolution problem of modular in-place transformations. although the main goal of cope is similar to ours, there are several differences in the realization. we tackle co-evolution of models by employing well-known graph transformation languages, rather than using a model evolution language. like cope, we utilize an incremental evolution approach, refraining from a single evolution process. however, our incremental process is supported by computing intermediate merged metamodels, thus we allow to model the migration of models by ensuring all metamodel constraints. although the automated synthesis of the intermediate metamodels gives up some control, it provides an ability to verify 11 / 13 volume 42 (2011) a generic in-place transformation-based approach to structured model co-evolution well-formedness, and differs from the metamodel-independent representation of models used in cope, which lacks the possibility for intermediate validation. 5 conclusion this paper presented a technique to deal with metamodel evolution and model co-evolution; despite the problem is an active field of research and a number of solutions have been proposed, several difficulties still demand for being alleviated. in particular, it has been illustrated a mechanism based on in-place migrations to reduce the accidental complexity of transformation design by shifting the focus on single co-evolutionary scenarios, in a step-by-step fashion. the evolver acts in a controlled environment which is narrowed down by the metamodel merging operation, which constraints her/his operative power and ensures syntactic consistency. moreover, thanks to the in-place co-evolution unaffected instances are left untouched allowing, for example, the propagation of external links that would be lost after a re-creation of the same model element. the approach enjoys a high degree of modularity, as relying on small co-evolution steps, which also results in an enhancement of re-use chances of the developed migration transformations. in fact, the technique permits us to store both the manipulation a metamodel has been subject to and the corresponding countermeasures to re-establish the well-formedness of existing models. future investigations will be devoted to the analysis of the metamodel evolution representation and default migration transformations in order to further improve the degree of automation and re-use. additional work will also consider the performance characteristics of the approach. moreover, the approach will be extended to support the co-evolution of not only instance models, but also transformation models. acknowledgments this work was supported by the austrian science fund (fwf) under grant p21374-n13, and the us national science foundation cns-0915010 and cns-0930919. bibliography [bkkk87] j. banerjee, w. kim, h.-j. kim, h. f. korth. semantics and implementation of schema evolution in object-oriented databases. sigmod record 16(3):311–322, 1987. [cdep08] a. cicchetti, d. di ruscio, r. eramo, a. pierantonio. automating co-evolution in model-driven engineering. in 12th int. edoc conf. pp. 222–231. 2008. [cdp07] a. cicchetti, d. di ruscio, a. pierantonio. a metamodel independent approach to difference representation. journal of object technology 6(9):165–185, 2007. [gjcb09] k. garcés, f. jouault, p. cointe, j. bézivin. managing model adaptation by precise detection of metamodel changes. in 5th european conf. on model driven architecture foundations and applications. pp. 34–49. springer, 2009. proc. mpm 2010 12 / 13 eceasst [gkp07] b. gruschko, d. kolovos, r. paige. towards synchronizing models with evolving metamodels. in int. workshop on model-driven software evolution. 2007. [hbj09] m. herrmannsdoerfer, s. benz, e. juergens. cope automating coupled evolution of metamodels and models. in 23rd ecoop conf. pp. 52–76. springer, 2009. [kms+09] t. kühne, g. mezei, e. syriani, h. vangheluwe, m. wimmer. explicit transformation modeling. in models in software engineering. pp. 240–255. springer, 2009. [nlbk09] a. narayanan, t. levendovszky, d. balasubramanian, g. karsai. automatic domain model migration to manage metamodel evolution. in model driven engineering languages and systems. pp. 706–711. springer, 2009. [obj10] object management group. object constraint language version 2.2. 2010. [rkpp10] l. m. rose, d. s. kolovos, r. f. paige, f. a. c. polack. model migration with epsilon flock. in 3rd int. conf. on theory and practice of model transformations. pp. 184–198. springer, 2010. [rod92] j. f. roddick. schema evolution in database systems an annotated bibliography. sigmod record 21(4):35–40, 1992. [sgm09] j. sprinkle, j. gray, m. mernik. fundamental limitations in domain-specific language evolution. technical report tr-090831, university of arizona, 2009. [sk04] j. sprinkle, g. karsai. a domain-specific visual language for domain model evolution. journal of visual languages and computing 15(3-4):291–307, 2004. [tjf+09] m. tisi, f. jouault, p. fraternali, s. ceri, j. bézivin. on the use of higher-order model transformations. in 5th european conf. on model driven architecture foundations and applications. pp. 18–33. springer, 2009. [wac07] g. wachsmuth. metamodel adaptation and model co-adaptation. in 21st european conf. on object-oriented programming. pp. 600–624. springer, 2007. 13 / 13 volume 42 (2011) introduction example approach difference model migration of instance models synthesis manual adaptation execution related work conclusion teaching model driven language handling electronic communications of the easst volume 34 (2010) proceedings of the 6th educators’ symposium: software modeling in education at models 2010 (edusymp 2010) teaching model driven language handling terje gjøsæter, andreas prinz 10 pages guest editors: peter j. clarke, martina seidl managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst teaching model driven language handling terje gjøsæter1, andreas prinz2 1 terje.gjosater@uia.no 2 andreas.prinz@uia.no http://www.uia.no/ faculty of engineering and science university of agder, grimstad, norway abstract: many universities teach computer language handling by mainly focussing on compiler theory, although mdd (model-driven development) and meta-modelling are increasingly important in the software industry as well as in computer science. in this article, we share some experiences from teaching a course in computer language handling where the focus is on mdd principles. we discuss the choice of tools and technologies used in demonstrations and exercises, and also give a brief glimpse of a prototype for a simple meta-model-based language handling tool that is currently being designed and considered for future use in teaching. keywords: mdd, meta-modelling, language specification, teaching 1 introduction mdd (model-driven development) and meta-modelling is increasingly important in the software industry as well as in computer science. however, many universities still teach language handling with the main focus on compiler theory. for example, in the norwegian universities, there is a strong emphasis on compiler theory and little or no focus on meta-modelling in most of the available computer language handling courses [gp11]. the focus among language designers is shifting towards creating small domain specific languages (dsls) [kt08]. these languages may have a graphical or textual presentation (concrete syntax), and they are often based on existing languages and may be preprocessed / embedded / transformed into other languages for execution, instead of being compiled with a traditional compiler. mdd may have some advantages when it comes to defining these types of languages. an important aspect of mdd is to provide the language designer with support for rapid development and automatic prototyping of language support tools, and allow for working on a high level of abstraction. this approach allows the language designer to focus on the language being developed, while still being able to use the definition for generating tools such as editors, validators and code generators. it may therefore be beneficial to modify university courses in computer language handling to focus not only on compiler development, but also on meta-model-based language design and definition. the main purpose of this article, is to share experiences from teaching meta-model-based language description, and to discuss which tools and technologies are suitable for covering the 1 / 10 volume 34 (2010) mailto:terje.gjosater@uia.no mailto:andreas.prinz@uia.no http://www.uia.no/ teaching model driven language handling different aspects of a language definition when teaching computer language handling. the article is based on literature study, language specifications, and the authors’ own experiences with tools, language descriptions as well as teaching of both compiler theory and metamodelling. the rest of the article is organised as follows: section 2 gives an overview of the different aspects of a meta-model-based language specification and outlines a course teaching these principles. section 3 discusses issues related to choice of tools and technologies for use in teaching the different language aspects. finally, we summarise our findings in section 4. 2 teaching meta-model-based language handling 2.1 overview when a course in compiler theory was modified to also cover meta-modelling, it became clear that we needed to get a common understanding between the two paradigms; which parts of a compiler description correspond to which parts of a meta-model-based language description. in [npt06], a language definition is said to consist of the following aspects: structure, constraints, presentation and behaviour (see figure 1). figure 1: aspects of a computer language description structure defines the constructs of a language and how they are related. constraints bring additional constraints on the structure of the language, beyond what is feasible to express in the structure itself. presentation defines how instances of the language are represented. this can be the definition of a graphical or textual concrete language syntax. behaviour explains the semantics of the language. this can be a transformation into another language (denotational or translational semantics), or it defines the execution of language instances (operational semantics). another type of semantics is axiomatic semantics, that proc. edusymp 2010 2 / 10 eceasst gives meaning to phrases of a language by describing the logical axioms that apply to them. these aspects are not always as strictly separated as they seem in the illustration; constraints are shown as overlapping with structure, since constraints interact closely with the structurerelated technologies in building up (and restricting) the structure of the language. however, constraints can also be used for defining restrictions for presentation as well as behaviour. the structure is the core of the language; it contains the concepts that should be part of the language, and the relations between them. a meta-model-based approach to language design facilitates a focus on the structure. starting from a well-defined language structure, it is convenient to define one or more textual and/or graphical presentations for the language, as well as to define code generation into executable target languages such as java. meta-models define the structure and constraints of a language. for a complete language definition, it is also necessary to define the presentation and behaviour, and relate these definitions to the meta-model, as explained in [kle07]. 2.2 a computer language handling course as described in more detail in [gp11], we have investigated how a course that primarily focused on compiler theory could be updated to include meta-model-based approaches to language definition, and a special focus on determining the optimal abstraction level for each language aspect. based on this, we have defined the following course outline that covers both meta-model-based as well as compiler-based approach to language definition: level: msc. prerequisites: object oriented programming, uml modelling. credits: 5 ects literature: aho, lam, sethi, ullman: compilers (2nd ed.)[alsu07]; clark, sammut, willans et. al.: applied metamodeling (2nd ed.) [csw08] form: 8 parts; each part with lectures, practical and theoretical exercises, and an obligatory hand-in. part 1 introduction: compilers, languages, language aspects, grammars, nfa and dfa automata, t-diagrams. part 2 structure: models, meta-models, mda, meta-models, abstract syntax, attribute grammars. part 3 constraints: semantic analysis, type systems, static and dynamic checks, type safety, logical constraints. part 4 textual presentation: syntax analysis, top-down and bottom-up parsing, lexical analysis, mapping, symbol tables, error handling, textual presentation for meta-models. part 5 graphical presentation: graphical languages, graph grammars, graphical presentation for meta-models. 3 / 10 volume 34 (2010) teaching model driven language handling part 6 transformation behaviour: transformation, code generation, intermediate code, optimisation, handling of generated code, model-to-model and model-to-text transformations. part 7 execution behaviour: semantics, interpreters, runtime environments, storage allocation, activation records, parameter passing, dynamic binding, operational semantics for meta-model-based languages. part 8 summary: repetition of the most important topics of the course. the course has been implemented at the university of agder in the spring term of 2010. in a related project course, the students have a choice of different projects building on this course. after running the language handling course, the following experiences were gathered: • it is good to use a running example where aspects are added to complete a simple example language. it is also beneficial to cover all language aspects within one platform. however, students can easily be demotivated by immature tools. • we should not try to cover too many different tools in the practical exercises, but rather concentrate on the most important ones and give the students more time to try them out for themselves by modifying and extending provided examples. • the understanding should be strengthened by giving different perspectives on the same issues in a lecture covering both compiler theory and meta-modelling. however, the connection between the two paradigms were sometimes difficult for the students to see. • the choice of tools and technologies for use in the course, is of big significance. we will therefore discuss some of the available tools and technologies and their suitability for use in teaching in section3. 2.3 finding the correct abstraction level an important part of this course concerns finding a good abstraction level in order to facilitate code generation from models. in this respect, tools for language description are used as an example. however, it is a challenge to find tools and technologies that work on a high abstraction level for each language aspect. if the abstraction level is too low, there are too many seemingly irrelevant details, that create complications and complexities that will make it more difficult for the students to get started with the tools. on the other hand, if the abstraction level is too high, it may not be possible to generate working tools from the language specification. for structure and textual presentation, there are tools that operate on a suitable level of abstraction, while it is more difficult to find good abstractions for the other language aspects. we will cover some of the available tools and technologies and their suitability for use in teaching in the following section. proc. edusymp 2010 4 / 10 eceasst 3 choice of tools and technologies for teaching 3.1 overview immature or overly complex tools and technologies can demotivate students and in some cases even make them avoid meta-model-based projects. a former master student has described experiences from implementing a dsl in both eclipse with suitable plugins, and in visual studio with dsl tools, and concluded that visual studio is good on integration, documentation and ease of use, while eclipse allows the developer to operate on a more suitable high level of abstraction and has a good selection of plug-ins to extend its functionality. however, both platforms have weaknesses when it comes to stability and user-friendliness [igp08]. 3.2 choice of platform we prefer free multi-platform tools and technologies to lower cost and to enable students to install the software on their home computers. we also wish to have a collection of tools that can co-exist in one platform, such as for example eclipse. we have also seen that the stability and user-friendliness has increased for eclipse over the last couple of years, so we have ended up using that as our preferred platform, and testing various plug-ins to cover the different aspects of a language specification. in the following, we will give a brief overview of our choices of tools and technologies for each of the language aspects listed in section 2. 3.3 tools and technologies for teaching structure the structure of a language specifies what the instances of the language are; it identifies the meaningful components of each language construct [set96] and relates them to each other. there are several ways to express structure; grammars, meta-models, database schema descriptions, rdf schemata, and xml schemata are all examples of different ways to express structure. there are different standards and recommendations for defining meta-models with different complexity and expressiveness. the most famous dialects are mof 1.x[omg02], emf/ecore[sbpm08], and cmof[omg03]. emf/ecore or emof is a simplified version of mof 1.x; among other simplifications, it removes associations and replaces them with pairs of class references. it seems reasonable to start a course in meta-model-based language design with an introduction to structure definition, using for example eclipse with emf/ecore (preferably with a graphical ecore editor) for demonstrating relevant examples. 3.4 tools and technologies for teaching constraints constraints on a language can put limitations on the structure of a well-formed instance of the language. this aspect of a language definition mostly concerns logical rules or constraints on the structure that are difficult to express directly in the structure itself. neither meta-models nor grammars provide all the expressiveness that is needed to define the set of wanted language instances. the constraints could for example be first-order logical constraints or multiplicity constraints for elements of the structure [pst07]. 5 / 10 volume 34 (2010) teaching model driven language handling in meta-modelling, the most common way to express constraints is the object constraint language, ocl, which has the expressiveness of predicate logic, in a programming-languagelike syntax. a lecture on constraints can be illustrated by creating and adding ocl constraints to a sample meta-model, and using an ocl toolkit such as mdt ocl or the emf validation framework. 3.5 tools and technologies for teaching presentation the presentation of a language describes the possible forms of a statement of the language. in the case of a textual language, it describes what words are allowed to use in the language, what words have special meaning and are reserved, and what words are possible to use for variable names. it may also describe what sequence the elements of the language may occur in; the syntactic features of the language. this is expressed in a grammar for textual languages. we have two main approaches to creating tools for handling presentation of a language; parsers that have to support a one-way connection from the presentation to the corresponding structure. editors that have to support a two-way connection between the presentation and the corresponding structure, providing feedback from the syntax analysis in form of syntax highlighting, error messages, code completion suggestions etc. in addition to the presentation definition, an explicit or implicit mapping is needed to connect it to the structure. one popular framework for defining graphical notations is gmf [gmf08]. it features a language to define graphical notations, and generates eclipse and gef-based [gef08] editors from these definitions. it allows for defining possible diagram elements and tool palettes, as well as explicit mapping to structure. frameworks for textual notations can be divided into tools like xtext [efh+08], which provides editors based on language definitions consisting of grammars, and frameworks like tcs[jbk06], tef [sch08] and emftext [hjk+09], which combine meta-models and grammars. an advantage of emftext, is that it can generate a hutn-based (human-usable textual notation) parser and editor from an ecore meta-model, that can be used as a starting point for developing a textual notation. if a running meta-model-based example is used, it may be fruitful to show the students how an emf-based example structure (with constraints) can be extended with both graphical and textual presentations, using editor generation frameworks like for example gmf for graphical editor generation and emftext for textual editor generation. 3.6 tools and technologies for teaching behaviour the behaviour of a language describes what is the actual meaning of a statement of the language. two main types of formal ways of defining semantics are called operational and denotational semantics [set96]: proc. edusymp 2010 6 / 10 eceasst denotational semantics in the strict sense, is a mapping of a source expression to an inputoutput function working on some mathematical entities. if we wish to include model transformations and language-to-language translations in our behaviour descriptions, we can include them in this category by applying a more broad definition of denotational semantics; namely a transformation of each phrase of the language into a phrase in some other language, often a mathematical formalism. to execute or interpret the behaviour of a statement, semantics for the target language is then needed. a denotational semantics describes an “abstract” compiler. operational semantics describes the execution of the language as a sequence of computational steps. you will then need to know the semantics of the interpreter. operational semantics may be described by state transitions for an abstract machine. in [pst07], it is described how semantics for sdl are handled by abstract state machines (asm). with operational semantics, a runtime environment is needed. an operational semantics describes an “abstract” interpreter. a third type of semantics, axiomatic semantics, gives meaning to phrases of a language by describing the logical axioms that apply to them. experience shows that axiomatic semantics are extremely complex and rarely used for computer languages. for this paper we only focus on denotational and operational semantics. we have noted that it may be challenging to teach this language aspect since most of the tools available for supporting the theory of this aspect are relatively immature and/or hard to use, particularly for execution behaviour. transformation languages like qvt [omg05] or atl [bdj+03] can be used to create example transformations on the structure of the running emf-based example, and for the latter, jet [jet04], acceleo [mjl08] or xpand [efh+08] can be used to generate textual code. the eclipse plugin eprovide, provides support for developing visual debuggers and interpreters based on operational semantics defined in asm, qvt/relations, java, prolog or scheme. for illustrating the theory in this lecture, we may want to apply model-to-model transformations using qvt or atl, and model-to-text with for example jet or xpand. we may also demonstrate operational semantics with asm-based semantics in eprovide. 3.7 an alternative platform based on experiences from teaching, we have concluded that it may be useful to develop a very simple meta-model-based language definition platform, that attempts to remove some of the complexity of the more popular existing tools, in order to better allow the students to grasp the basic principles of meta-modelling. it should let the student operate on a suitable level of abstraction on each relevant language aspect, and facilitate making and modifying small example languages. in order to achieve this, we have started designing and prototyping a new platform named languagelab. it is planned to be a complete environment for experiments with modular language specification, particularly intended for use in teaching. the following use cases will be supported: • edit/select language elements and put them together into a complete language (with tools) 7 / 10 volume 34 (2010) teaching model driven language handling • create a language specification in a modular way. • based on an existing/predefined structure, the user can modify it to fit his needs, and a new language (with tools) is created. • combining pre-defined modules to create a language (with tools) supporting some required features (supported/implemented by those modules) • a language module can cover a complete, or parts of a, language aspect. parts can be for example: inheritance, loops, composite objects. • a language module uses and provides interfaces for other modules that the language developer can use. • create a structure and connect it to a predefined execution model. • create an interface for a language module in order to promote it to a meta-language module that can be used for defining other language modules. a language will consist of one or more modules that have structured elements that can be instantiated into a runtime model representing the language instance, via an interface. each module supplies create, get, and set operations for each type element that is accessible from the interface. if the created runtime model is intended to be used as a language module, it is possible to create an interface from the runtime model by promoting runtime model type instances to types via an optional operation in the module. a simple prototype has been developed based on eclipse/emf. it supports some basic functionality, allowing us to test it by creating a state machine runtime model from a simple state machine language module (only the structure aspect is supported in the initial prototype), as shown in figure 2. 4 conclusions one of the main challenges of teaching meta-model-based language handling is finding tools that are simple, on a high abstraction level, and that work well together with other tools for other language aspects. it is our impression that some of the perceived complexity of meta-modelling comes from complex tools and technologies, rather than from the principles behind them. it is possible to build a series of lectures in meta-model-based computer language handling supported by running examples based on eclipse/emf and other eclipse-based plug-ins and frameworks, to cover all aspects of a language definition. however, we think that it may also be interesting and fruitful to develop and introduce a very simple meta-model-based language definition platform, that attempts to remove some of the complexity of the more popular existing tools, in order to better allow the student to grasp the basic principles of meta-modelling. it should let the student operate on a suitable level of abstraction on each relevant language aspect, and facilitate making and modifying small example languages. proc. edusymp 2010 8 / 10 eceasst figure 2: languagelab prototype bibliography [alsu07] a. v. aho, m. s. lam, r. sethi, j. d. ullman. compilers: principles, techniques, and tools, 2nd ed. addison-wesley, 2007. [bdj+03] j. bézivin, g. dupé, f. jouault, g. pitette, j. rougui. first experiments with the atl model transformation language: transforming xslt into xquery. in oopsla 2003 workshop, anaheim, california. 2003. [csw08] t. clark, p. sammut, j. willans. applied metamodeling – a foundation for language driven development. second edition. ceteva, 2008. [efh+08] s. efftinge, p. friese, a. haase, d. hübner, c. kadura, b. kolb, j. köhnlein, d. moroff, k. thoms, m. völter, p. schönbach, m. eysholdt. openarchitectureware user guide. see also http://www.eclipse.org/gmt/oaw/doc/4.3/html/contents/index.html, 2008. [gef08] gef developers. gef documentation. see also http://www.eclipse.org/gef/reference/documentation.php, 2008. [gmf08] gmf developers. eclipse graphical modeling framework. 2008. see also http://www.eclipse.org/gmf. [gp11] t. gjøsæter, a. prinz. teaching computer language handling from compiler theory to meta-modelling. in gttse 2009. lncs 6491, pp. 446–460. springer, 2011. 9 / 10 volume 34 (2010) teaching model driven language handling [hjk+09] f. heidenreich, j. johannes, s. karol, m. seifert, c. wende. derivation and refinement of textual syntax for models. in model driven architecture foundations and applications. lecture notes in computer science 5562/2009, pp. 114–129. 2009. [igp08] i. f. isfeldt, t. gjøsæter, a. prinz. meta-model-based implementation of sudoku: eclipse vs. visual studio. in norsk informatikkonferanse : nik 2008. pp. 51–62. 2008. [jbk06] f. jouault, j. bézivin, i. kurtev. tcs: a dsl for the specification of textual concrete syntaxes in model engineering. in gpce’06: proceedings of the fifth international conference on generative programming and component engineering. pp. 249–254. 2006. [jet04] jet developers. jet tutorial part 1. see also http://www.eclipse.org/articles/articlejet/jet_tutorial1.html, 2004. [kle07] a language is more than a metamodel. 2007. available at http://megaplanet.org/atem2007/atem2007-18.pdf. [kt08] s. kelly, j.-p. tolvanen. domain-specific modeling. wiley-interscience, 2008. [mjl08] j. musset, é. juliot, s. lacrampe. acceleo user guide. see also http://acceleo.org/doc/obeo/en/acceleo-2.6-user-guide.pdf, 2.6 edition, 2008. [npt06] j. p. nytun, a. prinz, m. s. tveit. automatic generation of modelling tools. in rensink and warmer (eds.), ecmda-fa. lecture notes in computer science 4066, pp. 268–283. springer, 2006. [omg02] omg editor. meta object facility (mof) specification. technical report, object management group, 2002. [omg03] omg editor. revised submission to omg rfp ad/2003-04-07: meta object facility (mof) 2.0 core proposal. technical report, object management group, april 2003. [omg05] omg. meta object facility (mof) 2.0 query/view/transformation specification final adopted specification ptc/05-11-01. omg document, object management group, 2005. [pst07] a. prinz, m. scheidgen, m. s. tveit. a model-based standard for sdl. in sdl 2007: design for dependable systems. lecture notes in computer science 4745, pp. 1–18. springer berlin / heidelberg, 2007. [sbpm08] d. steinberg, f. budinsky, m. paternostro, e. merks. emf: eclipse modeling framework. eclipse series. addison-wesley professional, second edition, 2008. [sch08] m. scheidgen. textual editing framework. see also http://www2.informatik.huberlin.de/sam/meta-tools/tef/documentation.html, 2008. [set96] r. sethi. programming languages concepts and constructs. addison-wesley, 1996. proc. edusymp 2010 10 / 10 introduction teaching meta-model-based language handling overview a computer language handling course finding the correct abstraction level choice of tools and technologies for teaching overview choice of platform tools and technologies for teaching structure tools and technologies for teaching constraints tools and technologies for teaching presentation tools and technologies for teaching behaviour an alternative platform conclusions electronic communications of the easst volume 27 (2010) guest editors: klaus david, michael zapf managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 workshop über selbstorganisierende, adaptive, kontextsensitive verteilte systeme (saks 2010) self organized swarms for cluster preserving projections of high-dimensional data alfred ultsch and lutz herrmann datenbionik, universität marburg 10 pages eceasst 2 / 14 volume 27 (2010) self organized swarms for cluster preserving projections of high-dimensional data alfred ultsch and lutz herrmann databionics research group, university of marburg, germany hans meerwein str. 22 35032 marburg ultsch@informatik.uni-marburg.de abstract: a new approach for topographic mapping, called swarm-organized projection (sop) is presented. sop has been inspired by swarm intelligence methods for clustering and is similar to curvilinear component analysis (cca) and som. in contrast to the latter the choice of critical parameters is substituted by selforganization. on several crucial benchmark data sets it is demonstrated that sop outperforms many other projection methods. sop produces coherent clusters even for complex entangled high dimensional cluster structures. for a nontrivial dataset on protein dna sequence multi dimensional scaling (mds) and cca fail to represent the clusters in the data, although the clusters are clearly defined. with sop the correct clusters in the data could be easily detected. keywords: swarm organization, projection, visualization, clustering, self organized feature maps, esom 1 introduction in order to grasp cluster structures in high dimensional data, it is a common approach to project the data onto a low dimensional space such that it can be visualized [izenman 08]. ideally such a projection produces a map in the sense of a (geo-) graphical representation of an unknown landscape. essential requirements for these projections are that cluster structures in the high dimensional space are not hidden nor clusters mixed, and that structures are not artificially added by the projection method. cluster structures that are very clearly defined by a strong similarity between the cluster members and large dissimilarities between different clusters may be entangled in high dimensional space. to preserve all topological relations is, however, in principle impossible, if the dimension of the map space is strictly lower than the dimension the data’s space [bauer et al 99]. linear projections, such as principal or indepenent component analysis (pca/ica), are in principle unable to preserve cluster structures on linear non-separable manifolds. non-linear projection methods like multi dimensional scaling (mds) and sammons mapping are also unable to unfold such clusters. self organizing maps (som) [kohonen 97] and curvilinear component analysis (cca) [demartines/hérault 97] are projection methods that have demonstrated to disentangle clusters and deliver coherent cluster representations. both algorithms try to learn topographical correct mappings by the preservation of distance relations self organized swarm projections saks 2010 3 / 14 within a certain neighborhood. this neighborhood is usually parameterized by a neighborhood radius. during the iterative construction of the mapping, i.e. unsupervised learning, this neighborhood radius is reduced. an improper choice of an annealing scheme for this radius, however, leads to a faulty representation of topology and cluster structures in cca and som. in this paper we present a new approach for topographic mapping, called swarm-organized projection (sop). sop has been inspired by swarm intelligence methods for clustering. sop combines ideas from the databot approach [ultsch 00] with schelling’s model of racial segregation in urban neighborhoods [schelling 69]. in classical ant based clustering algorithms swarm agents pick up and drop data. see [bonabeau 99 et al] for an overview. in contrast to this, databots are identified with and characterized by a particular data point [ultsch 00]. the biological equivalent would be an individual scent or pheromone. databots are able to move on a two-dimensional discrete grid which is finite but unbound, i.e. toroid. the dynamics of a databot swarm is controlled by programs for walking and the appreciation (sensing) of other databots. cluster formation in this model depends critically on a suitable annealing scheme for the range of sensors and/or the movement distances of databots [ultsch 00]. in schelling's segregation model [schelling 69] there are two types of agents (inhabitants), blacks and whites, which reside on a two dimensional grid. inhabitants have a more or less pronounced tolerance towards neighbors of the opposite color. an agent with an inacceptable number of opposite-color neighbours, is allowed to jump randomly to a free grid space. shelling and others were able to demonstrate that even the smallest preferences in neighborhoods leads to a fixpoint, which is the complete demixing of the two populations (segregation) [schelling 69], [vinkovic/kirman 06]. the problem of finding an annealing scheme that matches the data’s structures during the construction process of the projection is addressed in sop by a schelling like self adaptation and demixing of clusters until a sufficient level of topograhic ordering is reached. therefore no crucial parameterization for the construction of sops is necessary. on critical benchmark data it is demonstrated that sop significantly outperforms som and cca. for a nontrivial dataset of bioinformatics, it is shown that mds and cca fail to represent the clearly defined cluster structure. with sop the correct classes in the data could be easily found. 2 swarm organized projection (sop) a new algorithm for the projection of high-dimensional data onto two dimensional maps grids is defined. it is called swarm-organized projection (sop). as in the databots model [ultsch 00], swarm-organized projection agents are identified with input samples. each agent resides on a large but finite two dimensional discrete map space grid o ⊂ n2 embedded on the surface of a torus [ultsch 03]. let d = {x1,..., xn} denote the dataset with ||.||d as distances between the data in d and ||.||0 ∈ denote the distances between position on the map space. the position of an agent representing data set x is called m(x). at each position i o an agent carrying a data point x can calculate its stress φ(x, i): d x o -> r0 ( )( ) ( )∑ ∑ ∈ ∈ − −⋅− =θ dy o dy do iymh yxiymh ix )( )( ),( σ σ + eceasst 4 / 14 volume 27 (2010) the stress φ(x, i) depends on a neighborhood function h σ. this neighbourhood function h σ: r -> [0, 1] is a symmetric and monotonic decreasing function of the map space distance from position i having it’s maximum value at distance zero, i.e. at position i. an example of such a neighbourhood function is a two dimensional gaussian bell with variance σ2. the neighbourhood radius σ is adjusted (reduced, annealed) during the construction of a sop mapping. an agent may move from a node i to a different node j, if by this move the stress at φ(x, j) is decreased. candidates for the target position j of a move are randomly drawn from the set of all positions such that the probability of the drawing follows a two dimensional iid normal distribution n2(i, s) centered at i with variance s2 1: function learning of m = sop(d) . a sop mapping m is constructed by the movement of the agents until convergence is reached at a certain radius σ, then the radius is reduced. the construction of a sop mapping can be formulated in pseudo-code as follows: 2: for all x in d: assign an initial random position m(x) on the grid o 3: for σ = { smax , smax 4: repeat -1,..., 1} do 5: for all x in d: m(x) := arg minj φ(x, j) with j drawn by n2 6: until m fix (i, σ) 7: return m 8: end function sop s max first, the agents are randomly located on the grid (line 2). then, for each radius σ a fixed point iteration with respect to mapping m is performed (lines 3 to 6). agents move simultaneously, iff they can decrease their personal amount of topographic stress (line 5). at each level of a neighbourhood radius the learning proceeds until no agents wants to move (line 6). i.e. no agent is able to find a position, where its stress is lower than at the current position. denotes the maximal distance between any two positions on the output grid o. the number of agents moving at a radius σ may vary, depending on the structure of the particular dataset. this adaptive mechanism discards the need for a pre-defined annealing scheme for σ. this means a self adaptation of the number of iterations for each value of σ. self organized swarm projections saks 2010 5 / 14 figure 1: neighbourhood radius as a function of iterations, sop maps chainlink onto a 50 x 82 grid figure 1 shows the number of iterations that sop used for each σ on the chainlink data (see below). initially (0-a), when the mapping is random, many iterations are necessary to reach convergence. so neighborhood radius σ is kept constant. when a raw topographic mapping is achieved (a), convergence is reached much faster and the radius decreases fast (a-b). this depends on the scaling of the structural features of the data. when the global (cluster-specific) features are represented a fine grained optimization within the clusters takes place (c-d). in this phase all the map space is covered by the sop agents. as can be seen the distance structure of the data set itself determines the annealing of the radius σ. for sop no prior knowledge of the structural features of the data is necessary to determine a suiting annealing scheme for the neighborhood radius σ. note that sop does not require the data as high dimensional points in a vector space. sop’s input is only the distances ||.||d 3 benchmarking swarm organized projections between the data in d. so sop may also be used in cases where only distances are known. below a real world situation of this type is presented, where only distances between genetic codes are given. sop is tested here on a number of datasets that are published in order to assess the performance of clustering algorithms (http://www.uni-marburg.de/fb12/datenbionik). this repository, called fundamental clustering problems suite (fcps) contains a set of benchmark problems that test the limits of clustering algorithms. all data sets from fcps with a dimension greater than two are used. the datasets used are as depicted in figure 2. eceasst 6 / 14 volume 27 (2010) figure 2 the benchmark data sets from fcps (http://www.uni-marburg.de/fb12/datenbionik) the clusters in atom and chainlink are not separable by a linear manifold. in atom one of the two clusters (core) is much more dense than the other (hull). the golfball data does not contain any identifiable clusters. all points sit on a sphere like the dimples on a golf ball. tetra and hepta have compact clusters which are linear separable from each other. in tetra the clusters almost touch, i.e. the minimal inter cluster distance is small compared to the inner cluster distances. in hepta one of the clusters is very dense. iris data is used to show the effects of different principal axes in the clusters. the performance of sop is tested in comparison to other projection algorithms form data spaces onto a two dimensional output. the tested projections are principal component analysis (pca), independent compontent analysis (ica), multidimensional scaling (mds), emergent som (esom) and curvilinear component analysis (cca). we assume the reader to be familiar with pca, ica and mds. for more information on these projections see, for example, [duda et al 2003] or [izenman 08]. the self-organizing map (som) is a unsupervised learning artificial neural network [kohonen 97]. soms use low-dimensional regular and finite grids as map space. elements of map space (grid nodes) are called neurons or units. each neuron i is associated with a so-called codebook vector wi di oi wxxmxbmu −== ∈ minarg)()( in d. input samples are projected onto the bestmatching unit (bmu), i.e. .som is very similar to k-means clustering, if the number of neurons is small [ultsch 03]. here, we use the som as a topographic projection. therefore, we assume that the map space is sufficiently large, such that each input data can in principle be self organized swarm projections saks 2010 7 / 14 mapped onto a separate neuron and there is some empty space between the bmus, i.e. there exist neurons that are not bmus of input samples. using u-matrix methods ([ultsch 03]) on this type of som leads to the emergence of structural features in the data [ultsch 07]. therefore, this type of som is called emergent som (esom) as opposed to k-means-som. output map grids of size 50x80 = 4000 neurons on a toroid grid were used for the experiments reported here. curvilinear component analysis (cca) is loosely inspired by mds and som [demartines/hérault 97]. a cca is learned by performing for all data x, y a stochastic gradient descend on e(x,y): ( )( ) ( ) ood ymxmhymxmyxyxe )()()()(),( 2 −⋅−−−= σ the user has to specify a suiting annealing scheme for σ . during construction of a cca mapping the projected position of a datapoint m(x) is temporarily fixed, and all other m(y) move in order to adjust the pairwise distances. convergence in cca is enforced through a decreasing learning rate applied during the gradient descent [demartines/hérault 97]. a central claim for a mapping used for the visualization of high dimensional data is the preservation of cluster structures in the data. therefore we use an assessment measure which measures cluster preservation. this measure is called dispersion [herrmann/ultsch 10]. dispersion quantifies the (dis-) connectedness of cluster-wise delaunay graphs on the map space with respect to input distances. a cluster c ⊂ d is cohesively mapped onto map space iff the smallest subgraph of md containing the pictures of the points in c is connected. a topographic mapping is called cohesive iff all cluster c1,...,ck are cohesively mapped onto the map space. for all non cohesive mappings of a cluster, the dispersion of a cluster c is measured as the sum of the input distances added up along a minimal path in output space. let wc cxx otherwise if xx xxw d c ⊆    − = }',{ ' 0 )',( (x,x’) be class-sensitive weight function defined as follows: the dispersion disp(c) of class c is quantified using the minimum spanning tree (mst) on md with edge weights wc →(x,x’). let c ⊂ d x d denote the parental relation on mst with x → c → x' iff x is parental node to x' in mst. an ancestor relation c * → is then obtained by x c * ∃ x' iff n ∈ n and there are x1, ..., xn → with x c x1 → c ... xn → c    →→∈∃∈ = otherwise yxandxxcyxcxforifxxw cdisp ccc **':,' 0 )',( )( x'. the dispersion of cluster c is then defined as: dispersion disp(d) of a mapping is the sum of cluster dispersions divided by the median of inter cluster distances mid: ∑ = = k i icdispmid ddisp 1 )( 1 )( the normalization of disp by mid accounts for the data-dependent levels of scaling, different cardinalities and data manifold structures. dispersion disp(d) adds path lengths, measured by eceasst 8 / 14 volume 27 (2010) input space distances. inner-cluster distances of a coherent projected cluster are not accounted for. a mapping which preserves the cluster structures (cohesive topographic mapping) gives a disp(d) value of zero. 4 results of the benchmark dispersion of the projection of the data sets are given in the following table. dataset pca ica mds sammon cca som sop atom 0.72 2.07 0.62 0.00 0.00 1.91 0.00 chainlink 92.44 25.08 51.60 58.76 72.38 0.00 0.00 tetra 48.35 30.69 36.16 0.00 0.00 0.00 0.00 golfball 0.00 0.00 0.00 0.00 0.00 0.00 0.00 hepta 0.00 0.00 0.00 0.00 0.00 0.00 0.00 iris 0.00 7.16 0.00 0.00 0.00 1.14 0.00 table 1: dispersion of the projections on the benchmark data cca and som seem to have abilities to disentangle the data som is able to unfold chainlink, makes, however small errors on atom and iris. to our experience the errors in som grow considerably, if bordered output grids (planar grids) are used. sop is the only projection method that consistently projects all cluster structures in the data sets. 5 sop for bioinformatics data in this chapter sop is applied to a dataset from bioinformatics containing protein data with a well defined cluster structure. the data set, called gpd194, was published by popescu et al. in [popescu 06]. it contains 194 proteins, which belong to three distinct classes of proteins: myotubularins (mtm), receptor precursors (ret) and collagen alpha chains (col). the data set is given as pairwise dissimilarities. these dissimilarities are calculated from the output of the blast algorithm [altschul 97] as the similarity of the genetic code of the proteins. for details on this calculation see [popescu 06]. the gpd194 data set offers quite a variety of dissimilarities between members of a protein class: the myotubularins (mtm), are very similar, the receptor precursors have many isoforms. the collagen alpha chains (col) are, however, quite diverse. a silhouette plot [kaufman/rousseeuw 90] of the gpd194 data is shown in figure 3. self organized swarm projections saks 2010 9 / 14 figure 3: silhouette plot for gpd194 data indicating three clearly separated cluster positive silhouette values indicate a unique and distinctive membership of an input sample to its class. the collagens (col) cluster contains a number of proteins with silhouette values of zero. this indicates almost equal distances of these proteins towards all clusters. as can be concluded from the silhouette plot in figure 3, the protein clusters are well-separated and a cohesive topographic mapping should be possible. the gpd194 data set is non-vectorial: only distances are given. an embedding in euclidean vector space produces considerable and nonvanishing errors. therefore, som, ica and pca could not be used on this data. so only mds and cca could be used for a comparison with sop. mds maps proteins onto a circle in map space. see figure 4. well-separated clusters in the input space are not indicated by mds. for example, mtms do not appear isolated from receptors and collagens, despite mtms consists of a distinct set of proteins. faithful representation of the cluster structure of gpd194 data is therefore not possible with mds. eceasst 10 / 14 volume 27 (2010) figure 4: mds projection of gpd194 protein data set. cca depicts the proteins of gpd194 as a nearly uniform point cloud. interand inner-cluster distances are not preserved, e.g. receptors and collagens do not appear as well-separated clusters with large inter-cluster distances and smaller inner-cluster distances. for illustration see figure 5 thus, cluster structures of gpd194 data can not be faithfully retrieved with cca. figure 5: cca projection of gpd194 self organized swarm projections saks 2010 11 / 14 figure 6 sop projection of gpd194 protein distances figure 6 shows that sop correctly projects the three a priori classes of proteins. in contrast to mds and cca, sop depicts each class of proteins as a well-separated heap. the protein classes are easily retrieved from map space. as it was expected from the silhouette plot, the collagens (col) are more scattered on the grid and show some outliers. 6 discussion linearly non separable data sets, of which chainlink, atom, and golfball are canonical examples, demand of a projection to unfold the structures and project the clusters in a coherent way on the output map. the coherent representation of nontrivial entangled cluster is in principle impossible for projections like pca, ica, mds and sammons mapping. this paper demonstrates that only such projection methods that exclude more and more pairwise relations during their construction are able to visualize nontrivial cluster structures topologically correct and cluster preserving. such projections belong to a class, called focussing projections. cca, som and sop belong to this class of projections. pca, ica and mds are non-focussing projections. focussing algorithms first capture global (inter-cluster) proximities, later more local (intra-cluster) data structures are represented. this is an effect of the shrinking neighborhood hσit can be proven that the learning algorithm of sop is sound, complete and terminating [herrmann/ultsch 10] the right choice of an annealing scheme for the neighborhood radius σ is crucial for focussing projections [nybo et al 07]. an annealing which is not well suited to the intricacies of the data’s structures leads to topographical incorrect representation of clusters. the choice of the annealing scheme is, however, in practice left to some default strategy of a particular  eceasst 12 / 14 volume 27 (2010) implementation. an optimal annealing scheme depends both on the structure of the map space (e.g. bordered vs unbound, etc.) and the manifold containing the input samples. the latter is, however, an unknown quantity. in sop the annealing adapts itself to the data’s structure by a fixed point iteration. this is not to be confused with fixed points in mathematics. with regard to probabilistic agents, fixed point refers to the state where no agent has moved. let p ∈[0,1] denote the upper bound of the probability that an agent moves. the probability p(t) that for t ∈ n iterations at least one agent moved follows as p(t) = (1-(1-p)n)t 0)(lim → ∞>− tp t . since the iteration is likely to stop after a sufficient number of iterations. therefore, sop's learning algorithm terminates. furthermore it can be proven that sop's learning algorithm is sound and complete (see [herrmann/ultsch 10]. som’s leaning is neither sound nor complete. for cca it can be shown that learning is complete and sound. yet, cca fails to capture the non-linear manifold of the chainlink benchmark data (see ). dispersion is a raw measure in comparison with other topographic quality functions, e.g. topographic function [bauer et al 99]. dispersion does not account for the inner-class topography. however, the evaluation of inner-class topography preservation contributes error terms of its own which may easily blur more severe errors of non-cohesive the performance on the benchmark data demonstrates the superiority of the focussing algorithms over the non focussing algorithms. among the first, sop has the advantages of a self adaptation of the annealing scheme, a provable sound, complete and terminating leaning algorithm. on first nontrivial examples sop has demonstrated superior performance with regard to the coherent representation of clusters. 7 summary a novel method to project high dimensional data onto two dimensional map spaces, called swarm organized projection (sop), is presented. sop is derived from concepts of swarm intelligence and from emergent som (esom). it can be proven that the learning algorithm of sop is sound, complete and terminating. in many similar algorithms like esom and cca the choice of an annealing scheme for neigborhoods is crucial for a coherent representation of nontrivial high-dimensional cluster structures. sop solves this problem trough self adaptation to the data’s structures using a swarm intelligence technique. on crucial benchmark data it is shown that sop outperforms classical projections and other focussing projection methods. it is also demonstrated that sop is able to represent clusters in a high-dimensional real world data set, where other projection methods fail. self organized swarm projections saks 2010 13 / 14 8 references [altschul 97] altschul, s.f. gapped blast and psi-blast: a new generation of protein database search programs. nucleic acids research, 25:3389– 3402, 1997. [bauer et al 99] bauer, h.-u., herrmann, m., villmann, t. neural maps and topographic vector quantization. neural networks, 12(4-5),p 659– 676, 1999. [bonabeau 99 et al] bonabeau, e., dorigo, m., theraulaz, g. swarm intelligence: from natural to artificial systems. oxford university press, inc., new york, ny, usa, 1999. [demartines/hérault 97] demartines,p., hérault,j. curvilinear component analysis: a selforganizing neural network for nonlinear mapping of data sets. ieee transactions on neural networks, 8, p 148–154, 1997. [duda et al 2003] duda, r.o., hart, p.e., stork, d.g. pattern classification, wiley, 2003 [herrmann/ultsch 10]  [izenman 08] izenman, a.j. modern multivariate statistical techniques, springer, 2008 herrmann,l., ultsch, a. swarm-organized projection for topographic mapping, submitted to neurocompting, sept 2009 [kaufman/rousseeuw 90] kaufman, l., rousseeuw, p. j. finding groups in data, an introduction to cluster analysis. applied probability and statistics, new york: wiley, 1990. [kohonen 97] kohonen,t. self-organizing maps, 2nd edition, springer-verlag, berlin, 1997. [nybo et al 07] nybo, k., venna, j., kaski, s. the self-organizing map as a visual neighbor retrieval method. in proc. 6th international workshop on self-organizing maps (wsom), bielefeld, 2007. [popescu 06] popescu, m., keller, j., mitchell, j. fuzzy measures on the gene ontology for gene product similarity, ieee trans computational biology and bioinformatics, 3(3), 2006. [schelling 69] schelling,t.c. models of segregation. the american economic review, 59(2):488–493, 1969. [ultsch 00] ultsch, a., clustering with databots, in: proc. int. conf. advances in intelligent systems theory and applications (aista), p 99-104, canberra, 2000. [ultsch 03] ultsch, a. maps for the visualization of high-dimensional data spaces. in proceedings workshop on self-organizing maps (wsom 2003), pages 225–230, kyushu, japan, 2003 eceasst 14 / 14 volume 27 (2010) [ultsch 07] ultsch, a. emergence in self organizing feature maps. in proc. 6th international workshop on self-organizing maps (wsom), bielefeld, 2007. [vinkovic/kirman 06] vinkovic, d., kirman, a. a physical analogue of the schelling mode, proceedings of the national academy of sciences, nr 5, 103, pp19261-19265, 2006 introduction swarm organized projection (sop) benchmarking swarm organized projections results of the benchmark sop for bioinformatics data discussion summary references [demartines/hérault 97] demartines,p., hérault,j. curvilinear component analysis: a self-organizing neural network for nonlinear mapping of data sets. ieee transactions on neural networks, 8, p 148–154, 1997. [nybo et al 07] nybo, k., venna, j., kaski, s. the self-organizing map as a visual neighbor retrieval method. in proc. 6th international workshop on self-organizing maps (wsom), bielefeld, 2007. [popescu 06] popescu, m., keller, j., mitchell, j. fuzzy measures on the gene ontology for gene product similarity, ieee trans computational biology and bioinformatics, 3(3), 2006. search-based refactoring based on unfolding of graph transformation systems electronic communications of the easst volume 38 (2010) proceedings of the fifth international conference on graph transformation doctoral symposium (icgt-ds 2010) search-based refactoring based on unfolding of graph transformation systems fawad qayum and reiko heckel 14 pages guest editor: andrea corradini managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst search-based refactoring based on unfolding of graph transformation systems fawad qayum1 and reiko heckel2 1 fq7@le.ac.uk 2 reiko@mcs.le.ac.uk department of computer science university of leicester, leicester united kingdom abstract: to improve scalability and understandability of search-based refactoring, in this paper, we propose a formulation based on graph transformation which allows us to make use of partial order semantics and an associated analysis technique, the approximated unfolding of graph transformation systems. we use graphs to represent object-oriented software architectures at the class level and graph transformations to describe their refactoring operations. in the unfolding we can identify dependencies and conflicts between refactoring steps leading to an implicit and therefore more scalable representation of the search space. an optimisation algorithm based on the ant colony paradigm is used to explore this search space, aiming to find a sequence of refactoring steps that leads to the best design at a minimal costs. keywords: search-based refactoring, unfolding of graph transformation systems, ant colony optimisation meta-heuristic. 1 introduction refactoring has emerged as a successful technique to enhance object-oriented software designs by series of small, behaviour-preserving transformations [fow99]. however, due to the number of design choices and the complex dependencies and conflicts between them it is difficult to choose an optimal sequence of refactoring steps, maximising the quality of the resulting design while minimising the cost of the transformation. in the case of large systems the situation becomes acute because existing tools offer only limited support for their automated application [mtr07]. therefore, search-based approaches have been suggested in order to provide automation in discovering appropriate refactoring sequences [ssb06, hpj01]. the idea is to see the design process as a combinatorial optimisation problem, attempting to derive the best solution (with respect to a given quality measure or objective function) from a given initial design [om02]. two obvious problems with search-based approaches are scalability, i.e., the ability to apply to large models [oc08], and traceability, i.e., the ability on behalf of the developer to understand the changes suggested by the optimisation [hpj01]. in particular, heavy modifications make it difficult to relate the improvement to the original design, so that developers will struggle to understand the new structure. we believe that both problems 1 / 14 volume 38 (2010) mailto:fq7@le.ac.uk mailto:reiko@mcs.le.ac.uk search-based refactoring based on unfolding of gts can be mitigated by exploiting the local nature of refactoring operations, which affect only a certain part of the design while leaving the context unchanged. in terms of scalability, local operations permit the use of partial order models representing the behaviour of a system by a set of actions (refactoring steps) equipped with relations of causality and conflict. such models provide an implicit representation of the states (designs) of the system as conflict-free subsets of actions closed under causal dependencies, which scales better than the explicit representation of reachable states. for traceability, causal dependency provide a model of explanation of why certain steps are required to perform later steps, thus reducing the problem to understanding the benefits of the final steps in a sequence. in this paper, we use a representation of object-oriented designs as graphs and refactoring operations as graph transformation rules [mtr07]. such rules provide a local description, identifying and changing a specific part of the design graph only. after suitably encoding our rules into a hypergraph representation, this enables us to derive a partial order structure of causality and conflict relations, using the approximated unfolding of a graph transformation system [bcm99] and its implementation in augur 2 [kk08]. the result is a structure called petri graph, presenting the behaviour in terms of an over-approximation of its transformations and dependencies [bck01]. causal dependencies and conflicts, derived directly from the petri graph, serve as input to our search problem. optimisation algorithms such the ant colony optimisation [dor05] (aco) metaheuristic rely on an explicit representation of the search space. thus states and their local neighbourhoods have to be reconstructed on the fly from the partial order representation. the desired result is a sequence of transformations leading from the given design to a design of high(er) quality, using only transformation steps that are necessary to achieve that improvement. a more detailed view of the approach is given by the diagram in figure 1. using uml activity diagram notation, boxes represent artifacts while oval nodes are the actions or transformations performed on them. the class structure of a given java program (excluding method bodies, but retaining call and data access dependencies) is encoded in the gxl format required by augur 2. this is achieved with the help of the infusion environment1 and a subsequent transformation of the resulting mse2 file into gxl. the result represents the start graph of the hyper graph grammar to be unfolded. the rules of the grammar formalising the refactoring operations are derived from the standard catalogue [fow99] shared across all java programs. augur 2 constructs the approximated unfolding of a system [bcm99], producing a petri graph to serve as input to the acobased search algorithm. aco is inspired by the behaviour of foraging ants, which search for food individually and concurrently, but share information about food sources and paths leading towards them by leaving pheromone trails. this amounts to a distributed traversal of a graph whose paths represent possible solutions [dmg97]. in our case, the nodes of that graph 1 http://www.intooitus.com/infusion.html 2 http://www.moosetechnology.org/docs/mse proc. doctoral symposium icgt 2010 2 / 14 eceasst are the designs to be explored and its edges are the refactoring steps. rather than representing this so-called construction graph explicitly, its nodes and edges are derived from the partial order structure as and when required. as a result, a path (refactoring sequence) is produced representing the cheapest way to transform the given design into an optimal one. since the unfolding represents an over-approximation, the existence of this sequence needs to be verified in the real model, possibly leading to a refinement of the approximation. however, this step is beyond the scope of this paper. the remainder of the paper is organised as follow. in section 2, we review the presentation of refactorings as graph transformations and introduce our example. section 3 describes the partial order analysis based on unfolding. the mapping into an aco problem is addressed in section 4. finally we evaluate our approach and conclude. 2 refactoring as graph transformation in order to provide a localised formal description of refactorings as input to the partial order analysis, we follow [mtr07] in representing refactoring operations as graph transformation rules. informally, such a rule p : l → r consists of a rule name p and a pair of graphs l, r called the leftand right-hand side of p. a transformation t : g p(m) =⇒ h changes graph g into graph h by replacing the occurrence of l specified by m with a copy of r. following the algebraic double-pushout approach [eps73], the change is local because elements of g outside the occurrence of l are not affected by the transformation. the graphs we transform represent java class structures, which can be visualised by class diagrams. as an example, consider the diagram in figure 2. we consider the following set of refactoring operations [fow99]. • extract superclass, creating a common superclass for two existing classes, usually in order to encapsulate shared features. • add parameter, introducing a new parameter for a method to make data access explicit. • pull up method, transferring a method from a sub to a superclass. • move method, transferring a method to any other class. • encapsulate attribute, to increase the modularity by changing a visibility of attribute in a class from public to private. the rule extract superclass is shown in figure 3 in class diagram notation. rules can be applied in different orders and locations, giving rise to a number of refactoring sequences. below we describe and motivate some of these for future reference. t1: extract superclass e from class b and class c, e.g., in order to encapsulate shared methods. t2: pull up method from class b and class c to superclass e created by t1. 3 / 14 volume 38 (2010) search-based refactoring based on unfolding of gts encoding into gxl refine unfolding (hyper) graph transformation system aco metaheuristic search transformations sequence verify sequence; with choices "valid" or "spurious" compute the sequence spurious valid petri graph approximated unfolding (augur 2) java program start graph class level refactoring rules graph transformation rules figure 1: abstract view of the approach proc. doctoral symposium icgt 2010 4 / 14 eceasst figure 2: initial class model t3: move method from class b to class d, because it may be more tightly coupled to that class (e.g., accessing its attribute). t4: move method from class c to class d, with the same motivation as in t3. t5: encapsulate attribute a1 in class d, making the attribute private and creating setter and getter methods. t6: add parameter p of type d to method1 in class b to make explicit the access to instances of d. t7: add parameter p of type class d to method1 in class c, for the same motivation. note that the transformations listed are not part of a single sequence. for example t2, t3 are potentially in conflict. 3 analysis of dependencies and conflicts as outlined in the introduction, we use an implicit representation of the search space based on causality and conflict relations over rule applications representing refactoring steps such as t1 to t7 above. these partial orders are derived in two steps. first, the approximated unfolding of the grammar given by the start graph representing the initial design and the generic refactoring rules is produced and second partial orders are derived by analysing the overlaps of pre and postconditions of these rules in the resulting petri graph. 5 / 14 volume 38 (2010) search-based refactoring based on unfolding of gts figure 3: rule for refactoring extract superclass, in class diagram notation 3.1 unfolding of the refactoring grammar the approximated unfolding and its implementation in augur 2 [bcm99] are defined for hypergraph grammars. thus, we have to encode the initial design and refactoring rules into a hypergraph representation. according to [bck01] a hypergraph g is a tuple (vg, eg, cg, lg) where vg and eg are finite sets of nodes and edges respectively, cg : eg → v ∗ g is a connection function, while lg is a labelling function for edges. the difference with the more common notions of typed or labelled graphs with binary edges is that, in hypergraphs, only edges are labelled and that each edge can be connected to a finite sequence of nodes, rather than just one source and one target. the hypergraph of the initial class model is depicted in figure 5. the idea is to introduce a node for each node in the original graph and plus one edge to carry a label representing the type of the node. additional binary hyperedges are introduced to represent edges in the original binary graphs. rules undergo a similar transformation, but an additional restriction (imposed by the theory of unfolding) is that rules can delete and produce, but not preserve edges, while nodes cannot be deleted. the left-hand side of a rule must be connected [bck01]. this does not directly impact on the expressivity of the rules, but requires us to delete and regenerate edges that are meant to be preserved. the result for extract superclass is shown in fig 6. nodes of the left-hand side are mapped to those in the right-hand side with the same number, while the unnumbered nodes in the right are newly created. edges in the leftand right-hand side are disjoint. given the hypergraph grammar, the unfolding starts with the initial hypergraph and produces a branching structure by applying all possible rules on the system at all possible matches. the resulting petri graph contains both the graph structure of the system (essentially the union of all reachable graphs) and a petri net with hyperedges as places and rule applications as transitions. the approximated unfolding creates a more abstract structure, potentially folding into one several graph elements or rule applicaproc. doctoral symposium icgt 2010 6 / 14 eceasst figure 4: result of applying rule extract superclass to the initial class model tions [bck01]. the result is an over approximation of the behaviour, i.e., spurious sequences may appear that do not exist in the actual behaviour. we use the augur 2 implementation of this construction [kk08] where initial hypergraph and rules are presented in the graph exchange language gxl [tae01]. the output petri graph produced is in gxl format as well [dksr04]. 3.2 analysis of the unfolding a petri graph [bck01] is a finite data structure which records the behaviour of a graph transformation system. it combines hypergraphs with petri nets used to approximate the behaviour. the hyperedges of the graph component are at the same time the places of the petri net. the gxl representation produced by augur 2 [dksr04] is a low-level graph format, which knows about graph elements and their attributes, but not about transformations. to create a problem-specific data structure to allow for dependency analysis, we have to extract information about rules and transformations, the graphs they consist of, etc. then we can derive conflict and dependency relations by comparing the preand post-sets of transformations. the class diagram in figure 7 provides the conceptual data model for the unfolding. a java object graph representing an instance of this model is extracted from the gxl representation produced by augur 2. from the preand post-conditions in this high-level representation we can extract causality and conflict relations on transitions. using petri net-like notation, we represent the preand post-sets for a transition t by •t and t•, respectively [bcm99]. then, two transitions are in conflict, t1#t2, if and only if •t1 ∩ • t2 6= φ. they are causally dependent, t1 < t2, if and only if t • 1 ∩ • t2 6= φ. 7 / 14 volume 38 (2010) search-based refactoring based on unfolding of gts package (15) 0 class (16) 0 class (17) 0 class (18) 0 method (19) 0 method (20) 0 method (21) 0 method (22) 0 class (23) 0 attribute (24) 0 attribute (25) 0 parameter (26) 0 parameter (27) 0 contains (28) 0 1 contains (29) 0 1 contains (30) 0 1 contains (31) 0 1 gen (32) 10 gen (33) 1 0tgen (34) 1 0 contains (35) 0 1 contains (36) 0 1 contains (37) 0 1 contains (38) 0 1 contains (39) 0 1 contains (40) 0 1 type (41) 1 0 type (42)1 0 hasparam (43) 0 1 hasparam (44) 0 1 type (45) 1 0 type (46) 1 0 figure 5: initial hypergraph the set of transitions t1, t2, . . . representing refactoring steps and relations # and < provide the input to our search for an optimal sequence of refactorings. 4 refactoring as aco problem we employ ant colony optimisation (aco) [dor05] meta-heuristic search to find an optimal solution. aco is applicable to a wide range of combinatorial optimisation problems [dor05]. it is based on a set of artificial ants cooperating to find a solution by searching a graph independently, but leaving pheromone deposits on the graph’s edges to indicate promising paths. to do this, ants have to know the local neighbourhood of their current solution node, from which they will select the most likely edge to traverse based on the evaluation of the successor node and the pheromone values of the edge itself. formally, aco problem [dor05] consists of the following elements. 1. a finite set of solution components c = {c1, c2, · · · , cn}, and a set of arcs e connecting the components in c. 2. the states of the search problem, defined as sequences of components x = 〈ci, cj , · · · 〉 in c. the set of all possible states x is denoted x. the length (number of components) of a sequence is denoted by | x |. 3. a finite set s of candidate solutions with distinguished subset s̄ ⊆ s of feasible candidate solutions determined by a set of constraints ω. proc. doctoral symposium icgt 2010 8 / 14 eceasst 1 2 3 package (43) 0 class (44) 0 class (45) 0 tgen (46) 1 0 contains (47) 2 1 0 =) 1 2 3 package (53) 0 class (54) 0 class (55) 0 class (56) 0 gen (57) 0 1 gen (58) 0 1 tgen (59) 1 0 contains (60) 1 0 figure 6: hypergraphs for extract superclass refactoring rule 4. a non-empty subset s∗ of optimal solutions. 5. an evaluation f (s) for each candidate solution s. for some problems it is possible to calculate partial evaluations fp(x) associated with intermediate states x of the problem. using the formulation above, artificial ants build solutions by performing randomised walks on the connected graph g = (c, e), based on the following basic operations [dmg97]. • a state transitions takes an ant from a one node to another across an arc; • a local update changes the pheromone deposit on the arc it currently walks on; • a global update changes the pheromone deposits on all arcs an ant has traversed when this ant successfully ends its trip; in addition, we require a comparison function to evaluate different paths and an end of activity condition to specify when an ant has completed its trip. to state refactoring as an aco problem we consider a graph defined by the set of transformation steps as nodes with edges representing potential successor relations derived from dependencies and conflicts as obtained from the unfolding construction. these conflicts include symmetric ones, requiring mutual exclusion of two refactoring steps, and asymmetric ones, prohibiting two steps to occur in a certain order, but allowing for the reverse order. pheromone values τij and heuristic values ηij are associated with the edges of the graph. the values are determined by partial evaluations fp(x), associated with incomplete candidate solutions x, which represent preliminary feedback on the success of the search. 9 / 14 volume 38 (2010) search-based refactoring based on unfolding of gts figure 7: metamodel for the unfolding process the problem is thus expressed as the search for an optimal path representing the best sequence of refactoring steps applicable to the original system. the optimisation depends on an evaluation of paths representing candidate solutions, which takes into account both the cost of the refactoring transformations and the quality of the end result. we use a so-called hybrid ant system [gd00] where aco is extended by local search, in particular, the java framework by chiricom [chi] implementing [dmg97] in order to implement and solve a variety of acs problems. we adapted this framework to an implicit representation of states based on our partial order model, deriving states and their local neighbourhood on the fly. 4.1 deriving states and transitions states s are subsets of transitions that are conflict-free and closed under causal dependencies, i.e., s = {t ∈ tn | t ′ ∈ s and t < t′ and ∄t′′ ∈ s s.t. t#t′′}, where tn is set of transitions. the neighbourhood for a state s is characterised by all transitions enabled in s. a transition t is enabled in s if all its dependencies are satisfied by transitions in s and it is not in conflict with any transition in that set. adding such a transition leads to a new state s ∪ {t}. while computing the neighbourhood for a state in the search space, we need to check that the new transition is not yet present in the state. the conditions for enabled transitions ensure that the new state is well-defined, i.e., the added transition does not introduce conflicts or unresolved dependencies. with these prerequisites the algorithms proceeds as follows. • we initialise each ant by assigning an empty state s0 = ∅. • in each state s, an ant will determine its local neighbourhood by computing all transitions ti enabled in s, with successor states si = s ∪ {ti}. it will select one of its neighbouring states based on the states’ evaluation and the pheromone values proc. doctoral symposium icgt 2010 10 / 14 eceasst table 1: step sequences computed by ants ant id computed path node id’s 1. [5, 6, 4, 3, 0] 2. [1, 2, 0, 6, 5] 3. [0, 6, 5, 1, 2] 4. [5, 6, 0, 4, 3] 5. [6, 5, 0, 1, 2] best path node id’s: [5, 6, 0, 4, 3] corresponding rule id’s: [_5291, _5290, _5296, _5292, _5293] optimal sequence of refactorings: [t7, t6, t5, t1, t2] associated with the transition. • moving to the selected state, the ant will update the pheromone deposit. • the ant stops if there are no more new transitions to be added, i.e., all remaining transitions are in conflict with transitions in the current state. • a global update will take place to increase the pheromone deposits on all arcs leading to success, or decrease them in case of failure. 4.2 objective function in order to formalise a notion of quality, we define probe rules as patterns to recognise situations that are desirable or to be avoided in object-oriented designs. then, we will look for a state having a maximum number of desirable and a minimum number of undesirable occurrences. using the unfolding as underlying data structure, such information about probe rule occurrences is available at little extra cost. for every probe p and state s, we define #p(s) as the number of occurrences of probe p in s. it will return negative integers for anti patterns. assuming probes p1, p2, · · · , pn (both positive and negative) the objective function is defined by o(s) = 〈#p1 (s), · · · , #pn (s)〉, returning a vector of probe counts. thus knowledge about good and bad patterns is embedded in occurrence function #p. we use pointwise extension of ≤ from integers to vectors to define a partial order on the states, i.e., v1 ≤ v2 if and only if v1[j] ≤ v2[j] for all 1 ≤ j ≤ n. that means the relation must holds for every entry in the vectors to holds for the vectors in total. the probability of choosing the next transition depends on the quality of the successor state, i.e., the number of occurrence of probe rules. each ant will compute the probe vector while it moves from one state to another in the search space. 11 / 14 volume 38 (2010) search-based refactoring based on unfolding of gts figure 8: final class level diagram 4.3 experimental results given the problem representation as in section 4, we consider the given set of refactoring steps as the set of components c. the search space will be defined by the associated set of transitions and each transition will be assigned an identification number for reference. we can employ any (finite) number of ants, depending on the size of the problem and computing resources available. in our example we use five ants, each to start with an empty state (|x| = 0). they select enabled transitions to move in the search space and which will enlarge their states and enable more transitions until all remaining transitions are in conflict. to guide the behaviour of future ants based on preliminary success, each ant will assign an improvement to the edge traversed when adding component c to path x. the objective function o(s) will evaluate the best resulting design by assigning a probe vector. the best path computed by the algorithm, representing an optimal sequence of refactorings is given in table 1. it represents a sequence of steps of the set in section 2 for the initial class model in figure 2. the resulting class model is visualised in figure 8. 5 conclusion our approach involves a combination of graph transformation theory and the aco meta heuristic, aiming to improve search-based refactoring. rather than representing the search space of designs and refactorings explicitly we use the unfolding as a more scalable representation where designs (states) are given by sets of transformations closed under causal dependencies. we can thus reconstruct states when needed, for example in order proc. doctoral symposium icgt 2010 12 / 14 eceasst to evaluate the objective function, but will deal with the more compact representation when navigating the search space. as a further tribute to scalability, we are using the approximated unfolding. algorithmically, we are following a hybrid approach [gd00] where the aco meta heuristic is augmented with local search to improve its performance. hybrid aco has been shown to be effective in situations of large and rugged search spaces with complex constraints on solutions. in particular, the implicit representation of states (by a sets of transformations closed under causality and without conflicts) should allow us to scale the search to larger problems, avoiding state-space explosion. traceability will be evaluated through experiments with smaller models, assessing the effort it takes a human developer to understand the changes proposed by the searchbased approach. the use of dependency information between transformations allows us to remove steps that are unrelated to the intended change, making each change relevant and therefore easier to interpret. we have implemented the approach up to a point where it remains to check that sequences produced in the approximated model are also executable in the full model. if the sequence does not exists in the real model then a refinement of the abstraction will be required [kk06], which will lead to a more accurate unfolding and another round of optimisation. acknowledgements: fawad qayum is financed by the higher education commission of pakistan under overseas faculty development programme university of malakand, for a phd studentship at university of leicester. references [bck01] p. baldan, a. corradini, b. könig. a static analysis technique for graph transformation systems. in proc. of concur ’01. pp. 381–395. springerverlag, 2001. lncs 2154. [bcm99] p. baldan, a. corradini, u. montanari. unfolding and event structure semantics for graph grammars. in fossacs ’99: held as part of the european joint conf: on the theory and practice of software, etaps’99. pp. 73–89. springer-verlag, london, uk, 1999. [chi] u. chirico. a java framework for ant colony systems. [dksr04] f. l. dotti, b. könig, o. m. dos santos, l. ribeiro. a case study: verifying a mutual exclusion protocol with process creation using graph transformation systems. technical report, 2004. [dmg97] m. dorigo, s. member, l. m. gambardella. ant colony system: a cooperative learning approach to the traveling salesman problem. ieee transactions on evolutionary computation, 1997. [dor05] review of “ant colony optimization" by m.dorigo, t.stützle, mit press, cambridge, ma, 2004. artif. intell. 165(2):261–264, 2005. reviewer-christian 13 / 14 volume 38 (2010) search-based refactoring based on unfolding of gts blum. doi:http://dx.doi.org/10.1016/j.artint.2005.03.003 [fow99] m. fowler. refactoring: improving the design of existing code. addisonwesley longman publishing co., inc., boston, ma, usa, 1999. [gd00] l. m. gambardella, m. dorigo. an ant colony system hybridized with a new local search for the sequential ordering problem. informs j. on computing 12(3):237–255, 2000. doi:http://dx.doi.org/10.1287/ijoc.12.3.237.12636 [hpj01] m. harman, u. ph, b. f. jones. search-based software engineering. information and software technology 43:833–839, 2001. [kk06] b. könig, v. kozioura. counterexample-guided abstraction refinement for the analysis of graph transformation systems. in proc. of tacas ’06. pp. 197–211. springer, 2006. lncs 3920. [kk08] b. könig, v. kozioura. augur 2—a new version of a tool for the analysis of graph transformation systems. in proc. of gt-vmt ’06 (workshop on graph transformation and visual modeling techniques). entcs 211, pp. 201–210. elsevier, 2008. [mtr07] t. mens, g. taentzer, o. runge. analysing refactoring dependencies using graph transformation. software and systems modeling (sosym), pp. 269– 285, september 2007. [oc08] m. o’keeffe, m. o. cinnéide. search-based refactoring: an empirical study. j. softw. maint. evol. 20(5):345–364, 2008. doi:http://dx.doi.org/10.1002/smr.v20:5 [om02] o. c. m. o’keeffe m. a stochastic approach to automated design improvement. in proc. of the 2nd inter: conf: on the principles and practice of programming in java.. pp. 56–62. comp.sc press, trinity college dublin: ireland, acm sigapp, 2002. [ssb06] o. seng, j. stammel, d. burkhart. search-based determination of refactorings for improving the class structure of object-oriented systems. in gecco 2006. pp. 1909–1916. acm, new york, ny, usa, 2006. doi:http://doi.acm.org/10.1145/1143997.1144315 [eps73] h. ehrig, m. pfender, h. schneider. graph grammars: an algebraic approach. in 14th annual ieee symposium on switching and automata theory. pp. 167–180. ieee, 1973. [tae01] g. taentzer. towards common exchange formats for graphs and graph transformation systems. electr. notes theor. comput. sci. 44(4), 2001. proc. doctoral symposium icgt 2010 14 / 14 http://dx.doi.org/http://dx.doi.org/10.1016/j.artint.2005.03.003 http://dx.doi.org/http://dx.doi.org/10.1287/ijoc.12.3.237.12636 http://dx.doi.org/http://dx.doi.org/10.1002/smr.v20:5 http://dx.doi.org/http://doi.acm.org/10.1145/1143997.1144315 introduction refactoring as graph transformation analysis of dependencies and conflicts unfolding of the refactoring grammar analysis of the unfolding refactoring as aco problem deriving states and transitions objective function experimental results conclusion electronic communications of the easst volume 31 (2010) guest editors: paolo bottoni, esther guerra, juan de lara managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 proceedings of the second international workshop on visual formalisms for patterns (vffp 2010) augmenting dsvl meta-tools with pattern specification, instantiation and reuse karen li, john hosking, john grundy, tony ly and brian webb 12 pages eceasst 2 / 13 volume 31 (2010) augmenting dsvl meta-tools with pattern specification, instantiation and reuse karen li 1 , john hosking 1 , john grundy 2 , tony ly 1 and brian webb 1 1 {k.li, j.hosking}@auckland.ac.nz, {triadle, webb.brian}@gmail.com departments of computer science, university of auckland, private bag 92019, auckland, new zealand 2 jgrundy@swin.edu.au 2 faculty of information and communication technologies, swinburne university of technology, po box 218, hawthorn, victoria, australia abstract: this paper describes an approach for using patterns in domain-specific visual language (dsvl) meta-tools. our approach facilitates dsvl development via high level design-for-reuse and design-by-reuse pattern modelling tools. it provides a simple visual pattern modelling language that is used in parallel with dsvl meta-model specifications for modelling and reusing dsvl structural and behavioural design patterns. it also provides tool support for instantiating and visualising structural patterns, as well as executing behavioural patterns on dsvl model instances. keywords: meta-tools, domain-specific visual languages, design patterns, code generation, model-driven engineering 1 introduction using dsvls (a.k.a. dsmls or dsls) for software development has recently gained more awareness in industries, open source communities and software tool vendors, thanks to their support for high level visual representations of domain-specific knowledge, making it possible for stakeholders to be more deeply involved in software development. we have previously described our eclipse-based marama meta-toolset for generating multi-view dsvl environments in [ghhl08]. marama features rapid specification of meta-models, visual notations, views, constraints, critics, event handlers, model transformations and code generations for dsvls. however, its support for reuse is currently very limited. other metatools (e.g. [mic08, klr96, lbm + 01, zgh + 07]) have attempted to support design-by-reuse, however, most approaches are limited to code-level (e.g. via white-box framework inheritance or composition) or fine-grained modular model-level reuse (e.g. via copy/paste and import/export). few (e.g. [sut02]) have addressed higher-level pattern-based reuse. in our work with various visual languages and tools, we have identified recurring problems and solutions for dsvl design and implementation. these include patterns for specifying:  model structures such as hierarchy, composability, cardinality, mutability, multiple linked views and model interoperability; and mailto:j.hosking%7d@auckland.ac.nz mailto:j.hosking%7d@auckland.ac.nz dsvl pattern specification, instantiation and reuse proc. vffp 2010 3 / 13  modelling behaviours for common visual analytics tasks such as retrieving model data of interest to create visualisations, detecting and removing conflicts, transforming views and visualisations, and diffing and merging models/views. in addition, we have discovered a common set of repeatedly used relationships including subtyping, containment, referencing, dependency, flow, mapping and merging. we are investigating these dsvl design patterns in terms of their generic specification (via a highlevel visual language), instantiation/execution and reuse (adoption, adaptation, composition and inheritance). this paper describes a generic but configurable meta-model level visual language and tool support for dsvl design pattern (both structural and behavioural) specification, application and reuse. it illustrates how loose-coupled structural and behavioural pattern specifications can be integrated coherently with reuse and customisation support. we begin by describing the motivation, related work and the overall tool architecture of our approach. we then separately describe structural pattern specification and instantiation followed by behavioural pattern specification and execution in maramadsl. we then discuss early analysis results and future research before we conclude the paper. 2 our approach our initial motivation for this research came from one of the lessons we learned from our intensive evaluations [li07] of marama. although we used simple metaphoric visual languages (multiple integrated dsvls for specifying structural and behavioural aspects) that map well to the problem domain for dsvl design specifications, end users are still faced with a steep learning curve and hard mental operations when dealing with complex designs that have both structural and behavioural dsvl aspects. this raises a major barrier to use. however, we have identified that many design specifications are generic (or can be generalised) and are reusable across domains. we believe that facilitating design-for-reuse and design-by-reuse via patterns [sut02] is an optimal way for removing this barrier. we aim to capture common aspects of design and implementation support for different dsvls, and facilitate pattern-based reuse to augment dsvl meta-tools. we want a family of modelling notations and tools for dsvl pattern specification, visualisation, instantiation and execution. we also desire easy reuse of dsvl patterns via language and environment support. our earlier work on abstract design pattern specification [mhg07] defined a visual design pattern modelling notation, dpml, and provided tool support for pattern instantiation on a uml object model. dpml provides relatively clean visual representations for various types of pattern participant (e.g. interfaces, methods and operations), their dimensions (collections) and constraints. the instantiation step permits both tailoring and traceability/consistency with pattern specifications. however, dpml was based on the uml meta-model, which constrains its adaptation to a wider range of dsvl application domains (such as performance engineering, business modelling and healthcare planning as in [ghhl08]) and its integration in a generic dsvl meta-tool for design and implementation of non-uml-based visual language notations for those domains. other existing uml-based pattern languages (e.g. eceasst 4 / 13 volume 31 (2010) [fkgs04, mcl04]) are similar. although they have enough expressive power to specify traditional design patterns, they are not flexible in collaboration with arbitrary dsvls. graph grammar based transformation techniques have also been used to specify design patterns [zkdz07]. however, the nature of graph transformation (pattern matching plus transformation through left to right-hand side rule mappings) makes it more suitable to define model evolution/refactoring changes instead of up-front pattern specification and instantiation. configurability also needs to be extended in order to allow reuse of generic rules. our current approach facilitates simple and holistic pattern support in dsvl meta-tools. to this end, we have designed a notation that explicitly models generic pattern participant roles and relationships, with the ability to accommodate variance of different dsvl meta-models through visual, meta-level configurations. our approach allows both domain specific patterns (such as the “abstract factory” pattern, specified and instantiated on uml design models) and generic design patterns that can be reused across multiple dsvl domains. our visual notation has been designed based on a theoretical foundation [moo09] to make it cognitively manageable by non-programmer dsvl end users. we have designed maramadsl, a tightly integrated meta-tool environment featuring easy to use pattern-oriented modelling tools. it was created using microsoft dsl tools [mic08], deployed to the visual studio ide and applied back to augment the dsl tools with extended designer views, framework code and code generators. figure 1 illustrates its usage architecture. a maramadsl editor (with multiple designer views) is added into a dsl project (figure 1 (a) dslextension.maramadsl) to co-function with the dsl designer (dsldefinition.dsl – dsl tools’ visual definer for domain classes, relationships, shapes, connectors and diagram element maps). the complementary maramadsl model (with user created pattern-related components) generates custom code onto the dsl project that is realised in the generated dsvl environment without the need for any additional configuration. maramadsl imports the dsl designer elements and provides a domain model view (figure 1 (b)), used to display the existing dsvl meta-model elements, but flattened (without trees) and with filtering choices for various components (e.g. relationship role links) to manage diagram clarity. two pattern specification views linked with the domain model view are available, the structural pattern designer (figure 1 (c)) and behavioural pattern designer (figure 1 (d)) views, for structural and behavioural pattern specification respectively. each exploits orthogonal representations for separate but easy to bind generic pattern specifications and contexts. they make shared use of the dsvl meta-model in a layer as the pattern specification context, with filters to add relevant domain elements for pattern participation. patterns are specified in two simple visual languages (structural and behavioural) described in the next sections. patterns can be saved context-free, i.e. with bindings removed, for designfor-reuse and design-by-reuse, appearing in a patterns explorer tree in the model explorer window. they can then be drag-dropped for reuse and binding with other dsvl meta-models. accessed pattern specifications can also be easily adapted for reuse in a variant manner, e.g. modify or remove any existing participant or relationship at the dsvl client, or add elements to a pattern specification to meet specific needs. maramadsl also allows complex patterns to be created by composing existing patterns. we demonstrate pattern composition in section 4 dsvl pattern specification, instantiation and reuse proc. vffp 2010 5 / 13 using a composite behavioural pattern example. we are currently expanding a set of generic dsvl patterns for simple reuse and composition purposes. figure 1. maramadsl usage architecture: (a) integration with dsl designer, (b) domain model view, (c) structural pattern designer view and (d) behavioural pattern designer view we used a set of consistent modelling and visualisation techniques in the design of maramadsl, providing end users with a cognitively manageable user experience. different visual language metaphors are used for structural and behavioural pattern specifications to accommodate end users’ mind maps (elaborated in the following). drag-drops are largely used for creation and reuse, while links are used for bindings of pattern roles and contexts. an overlay layer of annotations are used to expose constraints and dimensions. orthogonal layers of pattern modelling elements and the dsvl meta-model are juxtaposed for separated visualisation with cross-cutting concerns and convenient specification. multiple interacting views (domain model, structural and behavioural pattern perspectives) are also used together to complement one another within a unified underlying model. complex specifications can be collapsed and filtered, and relationships and links elided to manage diagram clutter. behavioural pattern specification layer structural pattern specification layer (b) (a) (c) (d) eceasst 6 / 13 volume 31 (2010) 3 structural pattern specification and instantiation our structural pattern specification language uses an entity-relationship (er) based metaphor and a visual notation shown in figure 2 for depicting (a) patterns, represented by container shapes with a pattern icon and a name decorator; (b) participants, inner shapes with a participant icon and name, type and bound domain context decorators; (c) participant relationships, inner shapes with a connection icon and type and bound domain context decorators; (d) dimensions, inner shapes with a dimension icon and a name decorator, as well as by port shapes on participants; and (e) constraints, port shapes on pattern elements to constrain participants and relationships. the dimension concept is based on dpml [mhg07] and complements participant relationships with participant role cardinality constraints. constraint specifications use c# expressions (e.g. the constraint expression “participant1 !=participant2” denotes two participants can’t be the same runtime instance), but we intend to replace this with ocl features in a spreadsheet metaphor similar to maramatatau in [li07]. a set of pattern categories, participant and relationship types are defined based on our prior work in the dsvl problem domain. examples include metrics, multiple view, model integration, query and process pattern categories; domain class, property and relationship, shape and connector participant types; sub-typing, containment, and referencing participant relationship types; and using, refinement, and dependency pattern relationship types. custom categories and types can be added as end user extensions. figure 2. structural pattern specification in maramadsl the binding of a structural pattern specification to a dsvl meta-model is visually supported via static context bindings, figure 2 (f), represented by green dotted lines connecting elements in the domain model with their specifications in the pattern specification layer. these are cross-cutting relationships between elements from the two layers, e.g. a domain class (d) (g) (e) (a) (b) (c) (f) dsvl pattern specification, instantiation and reuse proc. vffp 2010 7 / 13 contextualises a participant; and a domain relationship contextualises a participant relationship. context binding links can be elided at individual pattern element level for diagram clutter management. context bindings are supplemented by dual text encoding on a pattern element (underlined text in the bound pattern element) to ease context navigation. a specified pattern can be saved context-free (all bindings removed), appearing in the patterns explorer tree, figure 2 (g), for reuse in other dsvl meta-models. after static bindings have been defined, the dsvl meta-model on the dsl designer side is injected with pattern attributes, e.g. patterns and participant names, which are further specified by dynamic bindings on a dsvl model instance. this pattern instantiation process [mhg07], creates a pattern instance associated with a dsvl model. a structural pattern instantiation view, figure 3 (b), based on and linked to the structural pattern designer view design-level abstraction, is provided for such dynamic bindings. participant memberships can be added into the pattern instance specification. on pattern instantiation, whether completed or not, the dsvl model instance, figure 3 (c), is updated with element creation or modification through an extended generic validation procedure (future implementation). these are the generative effects of pattern application, facilitating both up-front design as well as design refactoring. multiple patterns can be specified for a dsvl meta-model and instantiated into its model instances. traceability of pattern role bindings on the dsvl model instance is supported via a “pattern message board” (using a “dashboard” metaphor), which allows interactive selection highlights of pattern participants, i.e. selecting a participant in the “pattern message board” will highlight all the participant members in the dsvl model instance. we revisit the abstract factory pattern example specified in dpml in [mhg07] and illustrate its new “skinning” in maramadsl. by repeating this example, we emphasise the generality and configurability of our new language. figure 3 (a) shows the pattern specification juxtaposed with the uml meta-model (bottom). the pattern contains six participants (abstract factory, concrete factory, abstract creator, concrete creator, abstract product and concrete product) and their relationships (“issubtypeof”, “contains”, “overrides”, and “outtype”). context bindings include: a uml model interface participates as an abstract factory; a uml model class participates as a concrete factory; and a uml implementation relationship links the abstract factory and the concrete factory. two dimensions are defined in the pattern: products and factories. they are selected by various participants as indicated by coloured overlay annotations. these are used to specify that the number of participant instance members (as shown later in figure 3 (b)) should be equated to the number of dynamic items added to a dimension, with the cross product of the numbers if more than one dimension is set on a participant [mhg07]). figure 3 (b) is the structural pattern instantiation view associated with a specific uml model instance, here showing the actual uml elements that are participants in the various roles in the abstract factory pattern. pattern creation effects, including creation of participants and relationships of the right types on the dsvl model instance, are based on the pattern instantiation. for instance, on adding a metalfactory member for the concrete factory participant in the structural pattern instantiation view, a uml model class is created with that name on the dsvl model instance and an implementation relationship is created linking it to the abstract factory member, guifactory, as shown in figure 3 (c). eceasst 8 / 13 volume 31 (2010) figure 3. abstract factory pattern specification and instantiation on a uml model (a) (b) (c) dsvl pattern specification, instantiation and reuse proc. vffp 2010 9 / 13 4 behavioural pattern specification and execution we initially used a uniform er-based visual language representation for both structural and behavioural pattern specifications, with behaviours represented as event, query, filter, or action participants. however, the er metaphor proved a failure for behaviours. we thus used a more traditional dataflow-based metaphor for behavioural pattern specifications, representing behaviours as executable queries and actions, composed from a set of generalised query and action elements. this approach is significantly different to uml using visual composition of strongly typed reusable activity building blocks for selection, insertion, deletion, update and visualisation of dsvl elements. to develop this approach, we initially hand implemented 40+ behavioural specification examples on different domain models, for visual analytics tasks such as content retrieval, conflict management and information aggregation. we examined similar codings, identifying common abstractions from which we obtained a vocabulary for behavioural specifications. the vocabulary comprises a set of (50+) query building blocks specialising the following query and action types: select, filter, update, insert and delete, plus a resultset for rendering elements selected by queries. they are used to retrieve data, set filtering criteria, or alter model/view elements for various query-based visual analytics tasks. the elements are all parameterized with query context (e.g. model/view or element/relationship/shape/connector parts) and criteria (e.g. typed value). each has a returning result state as the output. our developers have found behavioural composition using these elements to be much easier than the original er metaphor, requiring then to just place necessary building blocks and pipe the output from one to input of another. we wanted to allow non-programmer dsvl end users to take advantage of the generalised query and action elements to create behaviours via a visual language that represents the elements visually, and defines how they interact with each other to facilitate behaviour composition. we also wanted to minimise behavioural specification effort by providing high-level behavioural pattern reuse. the behavioural pattern language is realised via a behavioural pattern specification view. graphical symbols with inand out-ports and links between express what should happen (i.e. state retrieval, state modification and output generation) after a given data push or pull. the symbols include behavioural pattern model, select, filter, update, insert, delete, result set, custom value, and port dataflow in the visual forms shown in the table in figure 4 (top). we used different shapes to represent queries, actions, result sets and values, and different icons, colours and textures for different query and action types to enhance understandability. for each visual symbol, text also plays an important role in determining the specific building block within the more general category of select, filter, etc. as with the structural patterns, we juxtapose a dsvl meta-model to allow convenient context bindings, except that the dsvl meta-model layer is shifted to the top in this view to better fit the top-down data piping style of behaviour composition. every behavioural pattern model has two execution methods the user can specify: automatic or controlled. the former enables automatic execution based on userdiagram interaction; the latter provides context menus for users to run the behaviours. eceasst 10 / 13 volume 31 (2010) figure 4. behavioural pattern specification in maramadsl a simple example is shown in figure 4 (a). it defines a behavioural pattern model specifying a generic “select all elements and filter on type” operation. the filter is bound in this case to select filter update insert delete result set custom value output-to-input dataflow (c) (b) (a) dsvl pattern specification, instantiation and reuse proc. vffp 2010 11 / 13 the modelclass domain element, so selects all modelclass elements in diagrams it is applied to. figure 4 (b) shows a more complex example: a composed behavioural pattern is specified over an er tool to perform a cascade-delete behaviour. on deleting an entity from an er model, its associated attributes and their descendant member attributes (for compound attributes) are also deleted, as shown in figure 4 (c). specification of this behavioural pattern composes two earlier defined generic behavioural patterns: querytypedchildren and querytypeddecendants, which express the selections of children or descendants of generic model types. it also contains additional query and action elements between the composing and composed behavioural pattern model to describe the cascade deleting effect and bindings to the domain model for application of the composed behavioural pattern to er diagrams. 5 analysis our approach explicitly models pattern participant roles and relationships for easy configuration across dsvls. compared to uml-based approaches (e.g. [fkgs04, mcl04, mhg07]) it has fewer constructs (e.g. no inheritance, aggregation, interface or operation) and is thus simpler. it has a clearer role collaboration model (participants, relationships, dimensions, constraints and behaviours) specific to the pattern description domain so is more visually expressive for pattern specific concepts. it allows easier domain context binding of generic pattern models through decoupled but interacting parts; and it allows sharing of common pattern structure for better reuse of specification (e.g. the state and strategy patterns have a common structure, and by using our approach one specification can be easily adapted based on the whole other without the need to re-specify common individual parts). our solution provides appropriate abstractions, simple-to-use visual notations and high-level instantiation, execution and reuse support for both structural and behavioural pattern functionalities to be realised in dsvl tools. we have applied the physics of notations theory [moo09] for a principled visual language design:  our language supports cognitive integration by using multiple linked views with separated layer representations of sharable and filterable domain context elements; it also provides consistent design-for-reuse and design-by-reuse mechanisms for structural and behavioural pattern specifications and context bindings.  graphic economy is the dominant principle in our language, for which some tradeoffs were made. we chose to use “symbol overload” (e.g. one participant symbol representing various types of pattern participants; one query symbol representing multiple behavioural building blocks) in both types of pattern specification. this resulted in reduced semiotic clarity, but this is desirable to provide a cognitively manageable number of symbols. as a result, our language heavily relies on text dual coding to distinguish pattern elements.  we applied the principle of perceptual discriminability: colours and iconic annotations provide visual distance to distinguish pattern elements from each other. we didn’t use the full range of visual variables from the principle of visual expressiveness, but the channels used in the current form have sufficient visual expressiveness. the principle of semantic transparency is addressed by using depictive icons to suggest symbol semantics.  some visual patterns can become complex, with many symbols. applying the principle of complexity management, we introduced a mechanism to elide pattern elements into a sub pattern using the same container symbol but in elided form. form-based filtering features eceasst 12 / 13 volume 31 (2010) (to turn selected elements/links on/off) are also supported. the mechanism to reuse patterns also assists in managing complexity. for behavioural pattern specifications, we provide a behavioural pattern designer lite view (not illustrated in the paper due to limit space) with elided technical details such as ports and context bindings, using mainly descriptions and flows. this applies the principle of cognitive fit by exhibiting multiple dialects. the lite view essentially represents the same concept of the behavioural pattern designer view, can perform the same tasks, and translate to the same underlying query and action elements. it benefits users wanting high level specifications while the behavioural pattern designer view is for users needing behavioural composition detail. the ability to convert between the forms provides users alternative perspectives. we have also conducted a cognitive dimensions [gp96] analysis to evaluate tradeoffs, strengths and weaknesses of our solution. the visual language has expressiveness equivalent to domain-specific code written with apis, but with a lower abstraction gradient, augmented understanding, reduced effort, and a much shallower learning curve via better closeness of mapping to users’ mental models of pattern use. instantiating a pattern specification requires some hard mental operations and premature commitment when choosing appropriate pattern elements to compose. however adding abstractions in the form of pre-defined patterns reduces complexity and diffuseness. the use of the visual language reduces error proneness compared to coding, but requires proactive checking of model semantics for correctness. progressive evaluation is allowed but requires a compile-and-run cycle. the language uses a terse set of graphical symbols but with a rather verbose set of textual labels for expressing pattern elements. diffuseness caused by that is mitigated by using them within typed symbol groups. the visual symbols have clear role expressiveness. we use layout in behavioural pattern specification as a secondary notation because it does not affect any semantics but is good for promoting readability of the flow sequences with visual cues. the usual diagram insert viscosity problems occur, and require automatic layout to mitigate. we have mitigated areas of hidden dependency and visibility in the language by juxtaposition of orthogonal layered views, and dual coding of custom values though context links and dynamic properties. the preliminary analyses also helped identify missing functionality requiring further work. dsvl design patterns a level of quality to domain-specific modelling, as validated design patterns are quality design models themselves, so correctly applying them onto dsvls supports quality model design. however, we are yet to address how we can validate the dsvl design patterns and their instantiations/executions for completeness, consistency and soundness. another important issue is that conflicts do exist in design patterns and when a pattern language is supported, balancing the conflicts and providing users with decision support for pattern adoption is essential. to address this, we plan to use mussbacher et al’s goal-oriented approach [mwa06] for forces analysis in the pattern language. runtime animated visualisation of the execution of behavioural pattern elements was a suggested feature but is only partially supported to date. we are also planning extensive usability studies. 6 conclusion our aim is to augment dsvl meta-tools with pattern-oriented design for easier end user experience. maramadsl, extending the dsl tools, is a unified meta-modelling environment with both structural and behavioural pattern specification and usage. maramadsl provides a dsvl pattern specification, instantiation and reuse proc. vffp 2010 13 / 13 general language for specifying dsvl design patterns with also tool support for pattern instantiation, execution and cross-domain reuse. our ultimate goal is to facilitate a knowledge base (with formalised pattern representations) for sharing dsvl design knowledge to benefit the wider communities, and the work we demonstrated here leads towards that direction. bibliography [fkgs04] r.b. france, d.k. kim, s. ghosh, e. song. a uml-based pattern specification technique. ieee transactions on software engineering 30(3), 2004. [ghhl08] j. grundy, j. hosking, j. huh, k. li. marama: an eclipse meta-toolset for generating multi-view environments, in icse’08. 2008: leipzig, germany. [gp96] t.r.g. green, m. petre. usability analysis of visual programming environments: a 'cognitive dimensions' framework. jvlc, 7: 131-174, 1996. [klr96] s. kelly, k. lyytinen, and m. rossi. meta edit+: a fully configurable multiuser and multi-tool case environment, in proc. of caise'96. 1996. [lbm+01] a. ledeczi, a. bakay, m. maroti, p. volgyesi, g. nordstrom, j. sprinkle, g. karsai. composing domain-specific design environments. computer, 2001: 44-51. [li07] k.n.l. li. visual languages for event integration specification in computer science. 2007, university of auckland: auckland. [mcl04] j.k.h. mak, c.s.t. choy, and d.p.k. lun, precise modeling of design patterns in uml, in icse’04. 2004: scotland, uk. [mhg07] d. maplesden, j.g. hosking, and j.c. grundy. a visual language for design pattern modelling and instantiation, in design patterns formalization techniques. march 2007, toufik taibi (ed), idea group inc.: hershey, usa. [mic08] microsoft domain specific language tools. http://msdn.microsoft.com/enus/vsx/default.aspx, microsoft, 2008. [moo09] d.l. moody. the “physics” of notations: towards a scientific basis for constructing visual notations in software engineering. ieee tse 2009. [mwa06] g. mussbacher, m. weiss, and d. amyot. formalizing architectural patterns with the goal-oriented requirement language, in vikingplop 2006. [sut02] a. sutcliffe. the domain theory: patterns for knowledge and software reuse 2002: mahwah, n.j.: l. erlbaum associates. [zgh+07] n. zhu, j.c. grundy, j.g hosking, n. liu, s. cao, a. mehra. pounamu: a metatool for exploratory domain-specific visual language tool development. journal of systems and software, 80 (8), 2007. [zkdz07] c. zhao, j. kong, j. dong, k. zhang. pattern-based design evolution using graph transformation. jvlc 18(4), pp. 378-398, 2007. http://msdn.microsoft.com/en-us/vsx/default.aspx http://msdn.microsoft.com/en-us/vsx/default.aspx user interfaces for theorem provers: necessary nuisance or unexplored potential? electronic communications of the easst volume 23 (2009) proceedings of the ninth international workshop on automated verification of critical systems (avocs 2009) user interfaces for theorem provers: necessary nuisance or unexplored potential? christoph lüth 8 pages guest editor: markus roggenbach managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst user interfaces for theorem provers: necessary nuisance or unexplored potential? christoph lüth deutsches forschungszentrum für künstliche intelligenz, bremen abstract: this note considers the design of user interfaces for interactive theorem provers. the basic rules of interface design are reviewed, and their applicability to theorem provers is discussed, leading to considerations about the particular challenges of interface design for theorem provers. a short overview and classification of existing interfaces is given, followed by suggestions of possible future work in the area. keywords: user interfaces, theorem provers, interactive theorem proving 1 introduction theorem provers need to be interactive, and interactive theorem provers need user interfaces. the first part of this statement may sound controversial, but even fully automatic theorem provers need a way to state the proposition to be proven, and the fact of the matter is that any non-trivial proof, be it about program verification, formalised mathematics, or any other application domain, will have to have be conducted with human interaction. so user interfaces are a necessary nuisance, but do they offer more potential? for most theorem provers, user interfaces have been something of an afterthought in the beginning — understandably so, as developing the core technology was enough of a challenge. with the advances of this technology over the recent years, theorem proving has come of age. the use of theorem proving has spread beyond its previous confines, from case studies to real applications (e.g. in mathematics, software or hardware verification), and with new users the need for better interfaces arises. in this note, we consider interactive theorem provers (the best known examples of which are, in no particular order, coq, hol, hol light, isabelle, and pvs), which read proof scripts containing definitions, declarations, theorems and prover-specific commands. these proof scripts are the central artefacts under construction; supporting the user to interactively construct them should be the main purpose of the user interface. even though phrased in terms of theorem proving, the discussion also pertains to interactive formal method tools; we come back to this in the conclusions. we first consider criteria for a good user interface for theorem provers, and then review existing interfaces and their strengths and weaknesses. from this, we point out some directions of future research, and conclude with the major challenges and a résumé. 1 / 8 volume 23 (2009) user interfaces for theorem provers (i) strive for consistency. (ii) cater to universal usability. (iii) offer informative feedback. (iv) design dialogs to yield closure. (v) prevent errors. (vi) permit easy reversal of actions. (vii) support internal locus of control. (viii) reduce short-term memory load. figure 1: the ‘eight golden rules’ of interface design. taken from [sp09, p. 88f]. 2 what makes a good user interface? 2.1 general criteria figure 1 shows the ‘golden rules’ of interface design according to shneiderman [sp09] (other authors give similar guidelines). they are all relevant for interactive theorem proving, but some rules particularly so: the sixth, because interactive theorem proving by its very nature is an explorative process, so it is important to be able to try and undo proof steps; the eighth, alluding to the seven (plus or minus two) chunks of information that can be held in short-term memory, because theorem provers can actually offer a lot of information to the user, and the problem is to avoid overwhelming the user; and the second, because users will range from experts who know exactly what they want and how to achieve it and might prefer a programmable command line interface, to complete novices who need every help they can get, and prefer syntax-free interface elements such as menus. on the other hand, the seventh rule should be taken with a grain of salt. it means that it should be easy to get the system to do what the user wants to achieve, which in a theorem prover means proving propositions. unfortunately, keeping the user from proving wrong propositions is the core of interactive theorem proving, and the resulting frustrations are par for the course (and cannot be blamed on the interface). showing why a particular action does not work, on the other hand, is an important task of the interface, so the rule should be read in this sense. 2.2 challenges in user interfaces for theorem provers theorem provers are special programs, and designing a good interface for them offers special challenges. the first difficulty is that theorems or proofs are abstract in the sense that they have no physical counterpart. hence, syntax plays a central rôle in theorem proving (and mathematics), because this is what is being manipulated. the capability to read and write proofs in a notation which is close to what users are used to from text books cannot be overstated, because it eases the cognitive load on the user considerably. secondly, theorem proving is very hard, and proof scripts are very abstract in the sense that they condense much information; they cannot be manipulated as conveniently as e.g. source code. in particular, the high degree of interdependency tends to make proof scripts brittle, so changing them in one place may lead to unexpected failure elsewhere, which makes changing proc. avocs 2009 2 / 8 eceasst and maintaining larger proofs very frustrating. thirdly, theorem provers potentially offer a lot of information: the proof state can become very large, the amount of rules, theorems, proof procedures known to the system can run into thousands, etc. it is important not to overwhelm the user, but it is even as important (and more challenging to implement) to allow the user to query the system interactively, preferably at different levels of abstraction, depending on the user’s proficiency. the most important consequence of these considerations is that user interface and theorem prover need to interact closely, with control flow going in both directions; interface design for theorem prover is more than ‘bolting a bit of tcl/tk onto a text-command-driven existing prover in an afternoon’s work’ [bs98]. 3 a review of user interfaces past and present 3.1 the early days in the early days, interactive theorem provers were used from the command line. users wrote a proof script which they fed to the prover, and the prover would check it; the interaction was in batch mode, very much like a with a compiler. although today this modus operandi would be considered unproductive, it was standard practice back then. moreover, the interactive theorem proving community has never been large, and subsequently resources to develop user interfaces have always been scarce (comprised to no small part of postgraduate students struggling to produce a thesis under the limitations of the prevailing user interfaces, and gratefully finding some justifiable diversion from their thesis work). 3.2 emacs and proof general under these limitations, the emacs editor, which allows for comfortable and flexible customisation using the lisp dialect it is written in, offered an excellent platform, and soon specialised emacs modes for many of the popular provers appeared. after a while, it became clear that many provers shared a similar interaction mode, and maintaining each of them separately was an unnecessary burden. the proof general project [asp00] in edinburgh consolidates the different emacs interfaces for isabelle, lego and others into one emacs package which can be instantiated to the different provers. proof general found widespread use and is the most popular interface implementing the idea of script management introduced in [bt98], where the proof script is treated as a sequence of commands, which are processed in a linear fashion. this divides the script in three regions, one of which has already been processed, one of which is currently being processed, and one of which is unprocessed. once a region has been processed, it can not be edited anymore. a simple undo function allows the user to go back in the proof. this idea is strikingly simple and powerful; it is cheap to implement on the prover’s side, and on the other hand offers a flexible way to add more functionality in the user interface (e.g. a ‘go to here’ button, which performs forward or backward steps as required). 3 / 8 volume 23 (2009) user interfaces for theorem provers 3.3 integrated development environments an integrated development environment (ide) offers a tight integration of source code editor, compiler, debugger, documentation browser, and other tools. smalltalk was the first language to come with an ide, and they became really popular with borland’s turbo-pascal. with the similarities between theorem proving and software development (in both, the object of interest — source code and proof script respectively — is processed by an external tool — compiler or theorem prover), it seems tempting to construct an ide for theorem proving [tbk92]. early attempts include ctcoq and pcoq [abpr01]. these attempts have been hampered by the fact that the integration between a theorem prover and its interface needs to be far closer than between a compiler and a source-code editor, and that in particular maintaining an ide is a substantial task — many of these efforts fall out of use because the underlying prover changes and is no longer compatible with the interface, or because they were built using an interface toolkit which has fallen out of use. recently, more powerful toolkits made it easier to create ides, such as the coqide created using gtk+, but this is still the exception rather than the rule. 3.4 graphical user interfaces graphical user interfaces (guis) entered the scene as early as the 70s with the xerox star system. the methodology behind graphical user interfaces is direct interaction: all objects of interest are represented continuously and graphically, preferably using an understandable metaphor, and can be manipulated with syntax-free operations on this representation, such as pointing at them, moving them, or causing interaction by dropping them onto other objects. finding such a metaphor for theorem provers is a challenge, since the objects in a theorem prover are abstract, and it is far from clear how their manipulation can be modelled by intuitive gestures, although attempts have been made [lw99]. the jape system was a pioneering effort [bs99]; it was designed to be a ‘quiet interface’, meaning it would only show as little as needed and not as much as possible (which as pointed out above is good interface design practice), and uses gestures to select proof steps. 3.5 document-centered approaches the pvs system has developed a closer interaction model with the emacs editor then the other systems mentioned in sect. 3.2. the user is essentially editing an interactive document in the editor’s buffer, with the prover checking the semantic integrity in the background. this is the so-called document-centered approach, where the focus of attention is the proof script itself, and how to edit it, rather than it being processed by a prover. it works best with a style of proof scripts which is not a simple sequence of state-affecting prover commands, but where the proof script represents the proof itself, e.g. by stating a sequence of transformations or intermediate goals. the mizar prover pioneered this approach [t+73], and isar brought it to the isabelle system [wen99]. taking this idea one step further is the plato system [wab06], which uses the texmacs editor to provide wysiwyg editing of mathematical documents in a latex-like language with high quality typesetting, while the proofs are checked by the omega-prover in the background. proc. avocs 2009 4 / 8 eceasst 4 the future of user interfaces what have the interfaces introduced in the last chapter achieved? without wishing to denigrate the efforts of the researchers involved, there is still a lot of room for improvement. what we can take from the existing interfaces is that as proof general shows, it is good to be generic. hardly any theorem prover has a large enough developer base to develop its own interface, but by sharing the effort across different provers we can achieve something. genericity is also good because it helps to make the connection between interface and prover clear; e.g. the interaction protocol for proof general was made explicit in the pgip protocol [alw07]. it is also important to note that the success of a prover hinges mainly on its expressiveness and proof support; in the past, users have always preferred a powerful prover with an emacs interface over a less powerful prover with a slick gui, even if the latter is easier to use. the aim must be, then, to provide existing powerful provers with better interfaces. 4.1 modern ides early attempts to develop ides for theorem proving have been mentioned above. with modern ides such as eclipse and netbeans which are specifically designed to be generic, the situation has improved, and it is tempting to instantiate e.g. eclipse as a theorem proving interface [alwf06]. however, eclipse is not exactly light-weight, and a major disadvantage of most ides is that they do not support mathematical notation well. particularly appealing in eclipse is its incremental document processing. that is, there is no explicit ‘process this document’ step, rather the prover (or compiler) continuously processes as much of the document as possible in the background, flagging up errors as they occur. this asynchronous mode of interaction makes good use of the time the user spends thinking, increasing overall responsiveness of the system. 4.2 emerging technologies the most drastic change in interface technology over the last years has possibly been the rise of web-based technologies. the technique known as ajax (asynchronous java script and xml) has taken web-based interfaces from filling in forms to fully interactive graphical user interfaces, and in future the distinction between local (desktop-based) and remote (web-based) interfaces will probably be blurred even further. these technologies can play a rôle in theorem proving too, as they allow easy cross-platform access to a theorem prover without having to install it locally, often a daunting task for the novice. an impressive first step here is kaliszyk’s proofweb [kal07]. 4.3 interaction models there have been various attempts to adapt more intuitive interaction models like gestures into theorem proving interfaces, like in jape or coq (‘proof-by-pointing’ [bks97]). it seems tempting to allow the user to rearrange formulae by drag-and-drop, going beyond what pen-and-paper mathematics allows us to do. however, this has to be reconciliated with the fact that the main artefact of a theorem prover is the proof script; a proof consisting of a series of gestures is not 5 / 8 volume 23 (2009) user interfaces for theorem provers really useful. thus, gestures should be seen as a way to create proof scripts. users indicate that they wish to perform induction on x, or exchange the two arguments of + (and this can be done either via drag-and-drop gestures, a menu button, or even more exotic means), the prover returns a new proof script fragment, which the interface inserts into the proof script. the challenge is to provide a uniform interaction protocol which works reliably across different provers (a first attempt has been made in [alw06]). 4.4 foundations interfaces have mostly been seen in technological terms. this is understandable, because technology delivers to the user, but the theoretical foundations of user interfaces have not received much attention. an exception is denney’s work [dpt05], which introduced the notion of hierarchical proofs, and operations such as zooming into a proof, on a purely semantics-free level. this allows interfaces to implement operations on this level, separating the purely syntactic manipulation which can be done in the interface from the semantic manipulations in the theorem prover. 5 conclusions we have highlighted the challenges in constructing interfaces for theorem provers, reviewed existing interfaces, and pointed out some directions of future research. all of this is necessarily subjective, so the author is grateful for any omissions pointed out to him. the discussion here has been phrased in terms of interactive theorem provers, but applies equally well to formal methods tools; the key difference between formal method tools and theorem provers is that because formal method tools typically have a more singular purpose (e.g. proofs in a particular notation or of particular properties), users and their level of proficiency will be less diverse, but the points about consistent notation and genericity are equally valid. as a closing summary, the key technical challenges in the author’s estimate are the comprehensive support of mathematical notation (maybe standard vector graphics formats such as svg can offer a solution here), and a clear standard protocol for theorem provers to interact with user interfaces. pgip was a first start in this direction, but possibly it is oriented too much towards script management; a recent new version [aalw09] aims to rectify this shortcoming. the overall challenge in user interfaces is to leverage the underlying technology to an extent which makes it easier to do proofs in a computer than with pen and paper. presently, this is not the case. theorem provers tend to get in the way more often than they are helpful, and even though that is in part their duty as proof checkers, the preferable rôle model of a theorem prover should be that of a helpful co-author gently pointing out errors and suggesting improvements, rather than a stubborn civil servant refusing to accept the blindingly obvious because of some formality. in good part, this an interface issue, and hence the author’s answer to the initial question is that there is definitely unexplored potential, waiting to be developed by enterprising minds. acknowledgements: research in part supported by the german research agency (dfg) under grant lu 707-2/2. proc. avocs 2009 6 / 8 eceasst bibliography [aalw09] d. aspinall, s. autexier, c. lüth, m. wagner. towards merging platω and pgip. in proc. 8th international workshop on user interfaces for theorem provers (uitp 2008). electronic notes in theoretical computer science 226, pp. 3– 21. elsevier science, 2009. [abpr01] a. amerkad, y. bertot, l. pottier, l. rideau. mathematics and proof presentation in pcoq. in proof transformations, proof presentations and complexity of proofs (ptp’01), sienna, italy. 2001. also available as inria rr-4313. [alw06] d. aspinall, c. lüth, b. wolff. assisted proof document authoring. in kohlhase (ed.), mathematical knowledge management mkm 2005. lecture notes in artificial intelligence 3863, pp. 65– 80. springer, 2006. [alw07] d. aspinall, c. lüth, d. winterstein. a framework for interactive proof. in mathematical knowledge management mkm 2007. lnai 4573, pp. 161– 175. springer, 2007. [alwf06] d. aspinall, c. lüth, d. winterstein, a. fayyaz. proof general in eclipse. in eclipse technology exchange etx’06. acm press, 2006. [asp00] d. aspinall. proof general: a generic tool for proof development. in graf and schwartzbach (eds.), tools and algorithms for the construction and analysis of systems. lecture notes in computer science 1785, pp. 38–42. springer, 2000. [bks97] y. bertot, t. kleymann, d. sequeira. implementing proof by pointing without a structure editor. technical report ecs-lfcs-97-368, university of edinburgh, 1997. also published as rapport de recherche de l’inria sophia antipolis rr3286. [bs98] r. bornat, b. sufrin. using gestures to disambiguate unification. in user interfaces for theorem provers uitp’98. 1998. [bs99] r. bornat, b. sufrin. a minimal graphical user interface for the jape proof calculator. formal aspects of computing 11(3):244– 271, 1999. [bt98] y. bertot, l. théry. a generic approach to building user interfaces for theorem provers. journal of symbolic computation 25(7):161–194, feb. 1998. [dpt05] e. denney, j. power, k. tourlas. hiproofs: a hierarchical notion of proof tree. in proceedings of mathematical foundations of programing semantics (mfps). electronic notes in theoretical computer science (entcs). elsevier, 2005. [kal07] c. kaliszyk. web interfaces for proof assistants. in autexier and benzmüller (eds.), proc. user interfaces for theorem provers (uitp’06). entcs 174(2), pp. 49–61. 2007. 7 / 8 volume 23 (2009) user interfaces for theorem provers [lw99] c. lüth, b. wolff. functional design and implementation of graphical user interfaces for theorem provers. journal of functional programming 9(2):167– 189, mar. 1999. [sp09] b. shneiderman, c. plaisant. designing the user interface. addison-wesley, 5th edition, 2009. [t+73] a. trybulec et al. the mizar project. 1973. see web page hosted at http://mizar.org, university of bialystok, poland. [tbk92] l. théry, y. bertot, g. kahn. real theorem provers deserve real user-interfaces. sigsoft softw. eng. notes 17(5):120–129, 1992. [wab06] m. wagner, s. autexier, c. benzmüller. platω: a mediator between text-editors and proof assistance systems. in autexier and benzmüller (eds.), 7th workshop on user interfaces for theorem provers (uitp’06). entcs. elsevier, 2006. [wen99] m. wenzel. isar — a generic interpretative approach to readable formal proof documents. in bertot et al. (eds.), theorem proving in higher order logics tphols’99. lecture notes in computer science 1690, pp. 167– 184. springer, 1999. proc. avocs 2009 8 / 8 http://mizar.org introduction what makes a good user interface? general criteria challenges in user interfaces for theorem provers a review of user interfaces past and present the early days emacs and proof general integrated development environments graphical user interfaces document-centered approaches the future of user interfaces modern ides emerging technologies interaction models foundations conclusions microsoft word campus10_bch_final.doc electronic communications of the easst volume 28 (2010) guest editors: sonia ben mokhtar, romain rouvoy, michael wagner managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 proceedings of the third international discotec workshop on context-aware adaptation mechanisms for pervasive and ubiquitous services (campus 2010) training the behaviour preferences on context changes kuderna-iulian benţa, marcel cremene and amalia hoszu 12 pages eceasst 2 / 13 volume 28 (2010) training the behaviour preferences on context changes kuderna-iulian benţa, marcel cremene and amalia hoszu technical university of cluj-napoca abstract: personalized ambient intelligent systems should meet changes in user’s needs, which evolve over time. our objective is to create an adaptive system that learns the user behaviour preferences. we propose *bam – * behaviour adaptation mechanism, a neural-network based control system that is trained, supervised by user’s (affective) feedback in real-time. the system deduces the preferred behaviour, based on the detection of affective state’s valence (negative, neutral and positive) from facial features analysis. the neural network is retrained periodically with the updated training set, obtained from the interpretation of the user’s reaction to the system’s decisions. we investigated how many training examples, rendered from user’s behaviour, are required in order to train the neural network so that it reaches an accuracy of at least 75%. we present the evolution of behaviour preference learning parameters when the number of context elements increases. keywords: ambient intelligence, affective computing, personalization, context awareness, ontology, neural networks. 1 introduction intelligent ambient systems aim to help the user to manage the various devices surrounding him. an intelligent ambient (ia) system like a smart home should have the ability to respond to individual needs [kmga08]. also, such a system should be non-intrusive [cef09]. objective. our objective is to create an ia system that observes the user reactions and learns from these observations. a non-intrusive way to observe the user it is to monitor his facial expressions. our system deduces the preferred behaviour, based on the detection of affective state’s valence (negative, neutral and positive) from facial features analysis. in order to keep the system simple, we will consider just the interaction with one user, therefore avoiding the multi-user issues addressed by some other smart home solutions [ham+06]. motivation. the use of an affective, non-intrusive, feedback is motivated here by the fact that in some cases such a feedback is more suitable than an explicit command. for instance, an impaired person has difficulties to give some direct commands (vocal or physical) in order to control the behaviour of a smart home. our interest for online learning systems is motivated by the fact that the context, in particular the user needs, is evolving in time. a particular case is the structural modification of the context (i.e. adding e new context element). scenario. in order to have a better understanding of our problem we present an application scenario. part a concerns the learning of a new behaviour preference and part b concerns the situation when a new context element is added. training the behaviour preferences on context changes proc. campus 2010 3 / 13 a. maria is a physical and speech impaired person. she is invited to her friend laura that has an affective-aware smart home (ash). as maria is a welcomed guest, the system will authorize her to personalize the system’s behaviour. one of the house behaviour rules closes the blinds when the outside light has the same intensity as inside. maria likes to look outside the window and so, when the first decision of the system to close the blinds is triggered (at sunset, for instance), she will display immediately (in the following minute) a negative emotion (i.e. anger), showing her disapproval. the ash will learn (after repeating it a few times, if needed) maria’s new preference. b. later on, ash is upgraded with a temperature sensor that senses the room and the outside temperature. by expressing her reaction to the system’s decisions, maria is effectively providing new behavioural preference examples and the upgraded ash learns to react to both, light and temperature context elements. approach. we propose *bam, a control mechanism that allows the system to learn the new behaviour preferences without editing the rules by hand, but feeding back the user’s multiple kind of responses (symbolised by the “*” preceding the acronym “bam”), to the system’s decisions. in order to prove the concept we captured the user’s affective reaction from facial displays using the personalized version of “face reader” tool [bke+09], to detect three valence levels of the person’s emotional state, that are used as a as positive, negative or neutral feedback. the results in training a mlp neural network to learn the preferred behaviour from the user’s affective reaction are discussed. we used ontology to describe the user context and preferences. outline. the rest of the paper is organized as follows. in section 2 we overview the actual solutions. in section 3 we present the principle of the user reaction controlled loop mechanism, *bam, for behaviour preference online learning. the implementation details of the affectiveaware smart home (ash) with the ☺bam variant are explained in section 4. in the next section we analyse the accuracy of the mlp neural network to learn the preferred behaviour from the user’s affective reaction, when the context changes. in the last section we conclude our work and present the future work. 2 related work this section aims to respond to the following technical questions related to our objective: 1. how are the user‘s behaviour preferences discovered? 2. how should we represent the user preferences? 3. how should the system adapt its behaviour to the user’s needs of preferences? user preferences discovery. users’ needs are evolving over time. in order to meet this requirement, one option is to let the user edit the behaviour rules in a gui. but editing the ia rules is difficult for the user because of the complexity that comes with the use of different sensors and actuators, leading to a large number of rules to define [nys+05][gyc+07]. moreover in [gyc+07] the authors notice that “rule-based reasoning is not flexible and can eceasst 4 / 13 volume 28 (2010) not adapt to changing circumstances”. a second option to determine the user’s preferences is to use machine learning techniques. a third, hybrid option, is presented in [mtwp09], where the authors propose a combination of rules and machine learning to personalize the behaviour of the system. although this solution seems promising, it is yet unclear what would happen when the rule set will grow larger. behaviour preference representations. in [hir06], the authors present a review of the existing context related preference representation. also, they propose a score based solution. they assign a score to each preference possibility, consisting in a real value in the [0, 1] interval or a predefined value (veto, indifferent, mandatory, error situation). if a context c, and an associated variable set v are present, the score will be the function score(p.s,c,v), where p.s is the scoring expression, otherwise the score is indifferent. in this model the context elements are considered distinct, without any relation between them. an ontological representation of the preferences is presented in [all05]. it models ontologically the relations between the context elements and the preferences. the preferences class has relations with all the main classes (time, agent, location, activity). the preference can be positive or negative indicating an appropriate or inappropriate choice for a resource, environment or operation. this model uses a probability to set the preference priority, but has only two values to express the relation between the context and the service (desired behaviour). another solution [ham+06] uses bayes rn-meta-networks, organized in multi-layers. the preferences are modelled by complex levelled conditional probabilities between the user, the context and the preferred service. in the article [fla05] the author presents an associative network between context and application. each context element could be associated with all n applications for a user. the association relation is modelled by a variable weight w that indicates the connexion strength between the context element and the application, thus given the weight matrix and a certain context, one may predict the application a user will choose. extending this idea, the weights could store the user’s preferences, but lacks the advantages of ontological modelling. the neural networks are used in [skw05] to describe weighted relations between the context elements (responding to: who, where, when, how) and the context elements (responding to how), the services and service parameters. they use mlps (multi layer perceptrons) with one hidden layer. this solution does not use ontologies in context modelling. we may notice in table 1 that only one solution adopted an ontological context modelling and has only two values to express the relation between the context and the desired behaviour. solution ontological context context-service relation ctxprefscore [hir06] score ([0, 1]) owlpref [all05] + ontological (appropriate/not) bayes meta-nets [ham+06] probabilistic nnassoc [fla05] association network weights upm [skw05] mlp weights table 1: comparison between different preference representation solutions. training the behaviour preferences on context changes proc. campus 2010 5 / 13 behaviour adaptation mechanisms. there are different approaches for context-service (behaviour) relation which allow for a more or less fine grained expression of the preferences. the bayes meta network solution [ham+06] is the nearest to meet our online updatable preferences objective, in the sense that it uses user’s feedback, but in this case they do not use ontologies and need a prior probabilities calculation. regarding the use of emotional response for learning the desired behaviour, the article [bro07] presents a reinforcement learning mechanism where a social robot learns from rewards and punishments expressed by positive (happy) and negative (fear) emotions. a reinforcement learning mechanism implies giving feedback for a set of tasks, but our objective is to have a simpler loop with immediate response. we also searched for a more general emotion valence assessment tool, explained in detail in [bke+09] where we proposed a personalized version of the facereader [fr] for detecting the user’s affective state valence. solution machine learning learning type feedback on/off-line adaptive home [moz05] q-learning reinforcement implicit online bayes meta-nets [ham+06] bayes meta-nets supervised explicit online flora-mc [shrs08] flora-mc supervised implicit online casas [rac09] hmm supervised both (i&e) offline table2: comparison between different preference machine learning techniques. because the user's implicit reaction (from the historical data) can be intrusive, the explicit feedback is preferable [ham+06] [rac09]. bayes meta network solution [ham+06] supports online preference discovery mechanism in context awareness. the mechanism consists in updating the preference model for each user if the system’s decision was disproved by at least one user. the preference model update is done by calculating the distribution probability for each user and then propagating the values to the next meta-network layers. its main issue is that the prior probabilities need to be initially calculated by a human, which is difficult for a large number of context elements. the main advantage of this model is that it supports online preference update. there are preferences learning solutions that also allow online adaptation, when changes in user’s preferred system behaviour occur by relearning the preferences [moz05] [ham+06] [shrs08]. casas [rac09] handles this problem indirectly by observing the changes in activity patterns (activity start time, duration), making predictions about the action that the user will do in a house (e.g. to turn on the tv, the lights, etc.), in a certain temporal context that repeats in a similar way, periodically. the learning parameters of the modified preferences (re-learning), like the number of necessary examples for training, the time necessary for applying the preferences (feedforward), are rarely discussed (only [shrs08]). moreover, [mptw09] addresses preference learning when possible values of one context element vary. we describe a supervised preference learning mechanism based on explicit feedback and we analyse it in section 5, similar to [shrs08], the ☺bam learning parameters. in [mptw09], it is discussed the problem of preference update when possible values of a single context element increase. a rule based solution is presented to tackle the problem which appears when increasing the possible values number that a context element can take. another less addressed issue of context structural changes is that the number of context elements may change due to upgrades in an ia system, challenging the system to become scalable eceasst 6 / 13 volume 28 (2010) [acpp+09]. further more, our approach is original in the sense that it tries to answer an intriguing question: what happens with the learned preferences, when the number of context elements changes. after analysing these examples, our conclusions are: 1. rule based systems are difficult to extend. 2. ontological representation of the user preferences in context-aware systems is rarel y addressed despite the advantages of using ontologies. 3. the behaviour adaptation mechanisms are online and supervised, rarely use explicit user feedback. also, these solutions rarely handle preference when the context structure changes, like different number of values for a context element or variations in the number of context elements. 3 the principle of * behaviour adaptation mechanism we made the following decisions for modelling the intelligent ambient (ia), in particular ash’s knowledge: 1. to use the ontology for context and service representation 2. to represent the context-service relation, that is the preferred behaviour as weights, stored in the ontology 3. to update the preferred behaviour according to the user’s feedback to the system’s decisions in principle, we consider the context c, composed by context elements in relation with each other, a service vector s, and a weight vector w, that records the preferred behaviour, that is the service to choose when the context c is present and a current reaction r of the user u. the meaning of the “*” preceding bam is that this mechanism is acquired though multiple type of feedback, explicit: voice commands, affective states, gui-based or implicit: analysing the human behaviour. the affective “☺” variant of *bam is explained in section 3.2. 3.1 preference representation we argue that storing the preference in neural network weights is better than in bayes rn meta-networks like in [ham+06] because: 1. the neural network allows initial training by an example training set, comparing to a mandatory prior probability calculations, simplifying the work at this stage. 2. if the rules or the bayesian approach would be used, a full description of the behaviour should be given (all combinations of context values and desired behaviour), a neural network can run with a few training examples if any, due to its generalization capability, and adjust online. 3. the neural network has the ability to generalize from a given set of examples. representing the preferences in ontology is motivated by the following arguments: 1. the ontology supports the distribution and reuse of the once learned preference in other applications with the same context elements and services, or similar (when increasing or decreasing one or more context elements or services). training the behaviour preferences on context changes proc. campus 2010 7 / 13 2. the neural network is to become dynamically reconfigurable (we may change its parameters on runtime: the number of hidden layers, neurons on each layer, activation function type, learning rate for each layer neurons). the part of the ontology containing the representation of the neural network is beyond the purpose of this article, as in this first implementation we saved the neural network parameters values in a file. 3.2 the affective behaviour adaptation mechanism we propose to replace the rule based decision mechanism with a neural network that learns from the user’s feedback the new preferred behaviour, in order to respond to the user’s new needs. because we like the user to interact as natural as possible with the system, we propose to use the affective kind of user feedback (☺bam). to estimate the current affective state we used a software tool that analyses a person’s facial features and asses the current basic emotion [fr] and adapted it to determine the current affective state’s valence [bke+09]. figure 1 depicts the general architecture of our system. the context-sensitive control system is based on a mlp neural network. for capturing the facial images, we used a high quality web cam and the “facereader” affective states assessment software [fr] [bke+09]. voice commands and gesture interpretation are considered for future work. the system records the user emotional variations for a specific time period after the system actions are performed. these variations indicate if the system actions were as the user expected or not. for instance, taking as reference the normal neutral valence affective state, a positive displayed emotion will mean approval and a negative emotion will mean disapproval of the system’s decision, if expressed immediately after it. we hypothesize that if we consider one minute time reaction, the user’s affective states we measure is causally related to the systems behaviour observed by that particular user. the mechanism works as explained below (see figure1): context (ambient) context-sensitive control system with learning sensors services from intelligent home have effects on have effects on have effects on observes observes feedback user needs/requests analyzer commands: voice, gestures, actions, etc. observers: affective, location, etc. reasonners: deductive, inductive figure 1: the principle of preference update based on the user’s affective response ☺ bam. eceasst 8 / 13 volume 28 (2010) 1. at t0 the system will choose a service for the present context by feeding forward in the randomly or prior trained (with values from that user’s behaviour history in similar conditions) neural network. 2. this decision for a service s at t0 will determine a user reaction in the next time interval t1. from this reaction, we are interested only in the valence of the emotion: positive (meaning acceptance) or negative (denial). 3. the acceptance or denial will determine the adequate weight w modification. then the cycle repeats from 1. this way the system adapts itself in successive steps. the principle for training the neural network is a supervised one. the element that changes during the time is the training set. we used a modified version of the back-propagation algorithm. when the user affective reaction is negative, the desired output is inverted in the training set. the network is re-trained periodically. at this moment, the desired output is estimated only using the emotional reaction but we intend to add also explicit commands and thus the system will learn to respond according to these commands. 4 the affective-aware smart home implementation the details of the affective-aware smart home (ash) implementation are beyond the scope of this paper. briefly, ash is based on a jadex multi-agent system, on phidgets boards for the sensorial context information gathering and actuators [bhvc+09]. we use ontologies to model the context information because they are independent from any programming language, support formal representation of the context [gpz05][wzgp04], allow knowledge distribution and reuse, logical context reasoning (consistency check, subsumption reasoning, implicit knowledge inference) [yal06]. ontologies provide expressing power (i.e. owl has cardinality constraints), hierarchical organization, use standards for efficient reasoning, abstract programming and interoperability [esb07]. by using reasoning mechanisms, the context can be augmented, enriched and synthesized [bmc+06]. moreover it solves heterogeneity, ambiguity, quality and validity issues related to the context data. [krs07]. the user related data is usually considered as a part of the context and can also be ontologically modelled [hec05], including details on her/his affective states [brc07]. 4.1 the affective knowledge representation we added in the context ontology the state concept as in [brc07], but, as we were interested in the valence representation for the current state, we defined the subclass currentstate having the valence property with three possible values as depicted in figure 2: figure 2: fragment from the sh_lower ontology illustrating a currentstate individual (left) and its valence property with the three possible values (right) training the behaviour preferences on context changes proc. campus 2010 9 / 13 4.2 modelling preferences in a mlp neural network at this stage we implemented our multilayer perceptron (mlp) using a java api that allows to save the network parameters in a file [bct09]. the entrance of the mlp had two inputs, the room light (lightsensor1) and the outside light (lightsensor0), with three possible values (low, medium and high) which are permanently updated into the ontology by the sensor agent: light_indoor=sensormap.getsensorbyid("lightsensor1").getsensorvalue(); there is just one output of the neural network, the blinds’ status (on/off) that has to be set up in the ontology once a decision is taken: devicemap.setdevicestatus("blind_2","on"); we may compare this with the equivalent bayes rn meta-networks [bhvc+09] solution where there is an important increase of prior probabilities with the number of inputs. in our scenario we would have to fill in 32*21=18 combinations, but when adding a binary value input (authorized/not authorized user), the number of prior probabilities would double: 36. so, an there is an exponential grow. moreover, the presence of two users, demands one more layer, resulting that for n users, n+1 bayesian layers are needed. as a consequence 3*36 = 108 values need to be computed. the complexity of the bayes rn meta-networks [anh05] is: o(n*p*q α +q α*n*p ) (1) where n is the number of users, p is the user’s probability to be in a certain location, q the number of service values or possible actions, α is a value proportional with the number of context elements multiplied by the possible values for that element. for the given example the complexity would be o (1*1*2 6 +2 6*1*1 ) =o (128). in the neural network case we reduce the complexity to: o(e*q). (2) where e is the number of context elements, q the number of service values or possible actions, so we have o (2*2) =o (4). that reduces the complexity 32 times. 5 results and discussions the experiments were developed in two main stages. the first one was a functional test to see if ash with ☺bam is able to learn a new preference after the system was trained with an initial training set [bct09]. we worked under the hypothesis that affective responses are closely related in time (1-3 minutes) to system’s decisions and are not induced by some other factor. the second stage consisted in simulations of the ☺bam training, when varying the number of context elements. in this second stage we used weka [hfhp+09] to simulate training the neural network with an initial behaviour preference and then retrain it with a new one. we wanted to see how many training examples have to be provided to the system, so that it learns the new preference and we compared this with the to the number of examples needed for the initial behaviour preference learning. in figure 3, the particular case of four context elements with ternary values considered as inputs of the neural network and one binary service considered as output is depicted. the bullet-dotted line above shows the initial training phase and the square-dotted one below is the retraining result. the continuous straight line, eceasst 10 / 13 volume 28 (2010) representing 75% correct behaviour accuracy, is the threshold to consider that the new behaviour is learned in a considerable manner. the probability of correct behaviour starts at 50% as the blinds position can be only on/off. the training curve shows a faster learning slope then the retraining as changing the behaviour demands more examples for the system to follow up the new behaviour. 0.5 0.55 0.6 0.65 0.7 0.75 0.8 0.85 0.9 0.95 1 1 3 5 7 9 1 1 1 3 1 5 17 19 21 23 2 5 2 7 2 9 31 33 35 3 7 3 9 4 1 4 3 4 5 47 49 51 5 3 5 5 5 7 59 61 63 65 6 7 6 9 7 1 73 75 77 79 81 number of examples p ro b a b il it y o f c o rr e c t b e h a v io u r figure 3: an example of the variation of the number of examples needed for training we did the same simulations varying the number of context elements from 2 to 10. we noticed that because of the complexity the number of context elements should not exceed 8 otherwise the neural network will not learn from the examples in a consistent manner. however, even a smaller number of context elements are practically problematic, as the number of needed examples increases exponentially like in the figure 4. 4 21 53 118 351 761 0 100 200 300 400 500 600 700 800 2 3 4 5 6 7 number of context elements n u m b e r o f tr a in in g e x a m p le s figure 4: the training examples number needed when the context elements number increases regarding the computing time, there are two components. one is due to facial analysis and affective states valence interpretation that is estimated to 200ms. the second time component is due to training the control system. table 3 shows the mean time values spent in order to train/retrain the system with one example. the increase of the time duration with the number of context elements is determined by the increased complexity of the neural network. the time values for ‘retrain’ are higher then for ‘train’ as the changes in the input-output function training the behaviour preferences on context changes proc. campus 2010 11 / 13 approximated by the neural network lead to more calculations then the small adjustments needed when more examples are added for ‘train’. number of context elements 2 3 4 5 6 7 train 3.35 4.31 7.93 8.94 11.96 13.16 retrain 8.45 17.58 32.26 54.17 69.01 84.90 table 3. the time (ms) for training one example in function of the number of context elements we conclude that some other online machine learning solution should be also selected and tested. in order to do the selection the criteria are: 1. to learn faster the new behaviour preference 2. to allow the retraining even if the number of context elements is big 3. to allow a better generalization (to need for less training examples). acknowledgments this work was supported by cncsis –uefiscsu, pnii – idei, project number 1062/2007. 6 conclusions and future work we proposed and tested a new behaviour adaptation mechanism, *bam, for ambient intelligence. this is based on a neural network and is original in the sense that it learns from the user’s affective reactions (valence) to the system’s decisions. it allows preference discovery, storage and usage for responding to ever changing user needs. at this stage the preferences are stored as neural network weights in a file, but we envision storing them in an ontological representation. we found out that in order to learn a new behaviour preference, the neural network needs a number of examples that increases exponentially with the number of context elements. that is not practical for a user when more then four context elements are used by the context aware system. as a future development, we will analyse some other online machine learning solutions to increase robustness to context number increase, reduce the time and number of training instances needed by *bam to learn the new preference and obtain a better generalisation capability. references [acpp+09] r. anthony, d. chen, m. pelc, m. persson, m. törngren. context-aware adaptation in dyscas. in: electronic communications of the easst, vol. 19, 2009, (campus 2009), lisbon, portugal, june 12, 2009. [all05] k. anh, y.-k. lee, s. lee. owl-based user preference and behavior routine ontology for ubiquitous system. pp.1615-1622, lncs, vol.3761, springer, 2005. eceasst 12 / 13 volume 28 (2010) [anh05] k. anh. user preference learning in context-aware computing. master thesis, department of computer engineering, faculty of graduate school of kyung hee university, korea, 2005. [bct09] k.-i. benţa, m. cremene, v. todica. towards an affective aware home, icost’09, lncs, vol. 5597, pp. 74-81, springer, 2009 [bhvc09] k.-i. benţa, a. hoszu, l. văcariu, o. creţ. agent based smart house platform with affective control, eatis, prague, czech republic, 3-5 june 2009. [bke+09] k.-i. benţa, h. van kuilenburg, u. x. eligio, m. den uyl, m. cremene, a. hoszu and o. creţ. evaluation of a system for realtime valence assessment of spontaneous facial expressions. in: distributed environments adaptability, semantics and security issues international romanian french workshop, cluj-napoca, romania, 17-18 sep. 2009 [bmc+06] l. buriano, m. marchetti, f. carmagnola, f. cena, c. gena, i. torre. the role of ontologies in context-aware recommender systems. in: ieee international conference on mobile data management, pp. 80, 2006. [brc07] k.-i. benta, a. rarau, m. cremene. ontology based affective context representation. in: eatis, faro, 2007. [bro07] j. broekens. emotion and reinforcement: affective facial expressions facilitate robot learning. lnai, vol. 4451, pp. 113-132, springer, 2007. [cef09] m. chan, e. campo, d. esteve, j.-y. fourniols. smart homes current features and future perspectives, maturitas, vol. 64(2), pp. 90-97, oct. 2009. [esb07] d. ejigu, m. scuturici, l. brunie. an ontology-based approach to context modeling and reasoning in pervasive computing. in: proceedings of the fifth ieee international conference on pervasive computing and communications workshops, washington, 2007. [fla05] j. flanagan: context awareness in a mobile device: ontologies versus unsupervised/supervised learning. in: proceedings of international and interdisciplinary conference on adaptive knowledge representation and reasoning, pp. 167-170, espoo, 2005. [fr] noldus information technology, facereader™, http://www.noldus.com/human-behavior-research/products/facereader [gpz05] t. gu, h.k. pung, d. zhang. a service-oriented middleware for building context-aware services. elsevier jnca, vol. 28(1), pp. 1-18, 2005. [gyc+07] d. guan, w. yuan, s.j. cho, a. gavrilov, y.-k. lee, s. lee. devising a context selection-based reasoning engine for context-aware ubiquitous computing middleware, lncs, vol. 4611, pp. 849-857, springer, 2007. [ham+06] md. k. hasan, k. anh, l. mehedy, y.k. lee, s. lee. conflict resolution and preference learning in ubiquitous environment. in: the 2006 international conference on intelligent computing, lnai, vol. 4114 0355, kunming yunnan province, 2006. [hec05] d. heckmann. ubiquitous user modeling, phd. thesis, saarbrucken, 2005. [hir06] k. henricksen, j. indulska, a. rakotonirainy. using context and preferences to implement self-adapting pervasive computing applications, softwarepractice & experience, vol. 36(11-12), pp. 1307-1330, ed. john wiley & sons ltd., 2006. training the behaviour preferences on context changes proc. campus 2010 13 / 13 [hfhp+09] m. hall, e. frank, g. holmes, b. pfahringer, p. reutemann, i. h. witten. the weka data mining software: an update. in: sigkdd explorations, vol. 11(1), 2009. [kmga08] r. kadouche, m. mokhtari, s. giroux, b. abdulrazak. personalization in smart homes for disabled people, in:2nd international conference on future generation communication and networking, vol.2, pp.411-415, dec. 2008. [krs07] r. krummenacher, t. strang. ontology-based context modeling. in: 3rd workshop on context awareness for proactive systems, guildford, 2007. [moz05] mozer, m. c. lessons from an adaptive house. in d. cook & r. das (eds.), smart environments: technologies, protocols, and applications (pp. 273294). hoboken, nj: j. wiley & sons, 2005. [mptw09] s. m. mcburney, e. papadopoulou, n. k. taylor & m. h. williams. implicit adaptation of user preferences in pervasive systems. in: proceedings of the 4 th international conference on systems : icons 2009, pp. 56-62. ieee computer society. cancun mexico, 2009. [mtwp09] s. mcburney, n. taylor, h. williams, e. papadopoulou. giving the user explicit control over implicit personalisation. in proc. persist workshop on intelligent pervasive environments (aisb 09), (in press), 2009. [nys+05] k. nishigaki, k. yasumoto, n. shibata, m. ito, t. higashino. framework and rule-based language for facilitating context-aware computing using information appliances. in: first international workshop on services and infrastructure for the ubiquitous and mobile internet, pp. 345-351, 2005. [rac09] p. rashidi and d. cook. keeping the resident in the loop: adapting the smart home to the user. ieee transactions on systems, man, and cybernetics, part a: systems and humans, 39(5), pp. 949-959, 2009. [shrs08] j. schmitt, m. hollick, c. roos, r. steinmetz. adapting the user context in realtime: tailoring online machine learning algorithms to ambient computing. monet 13(6), pp. 583-598, 2008. [skw05] y. suh, d. kang, w. woo. context-based user profile management for personalized services, ubicomp, workshop ubipcmm, 2005. [wzgp04] x. wang, d. zhang, t. gu, h. k. pung. ontology based context modeling and reasoning using owl. in: proceedings of comorea, orlando, 2004. [yal06] s. s. yau, j. liu. hierarchical situation modeling and reasoning for pervasive computing. in: proceedings of the fourth ieee workshop on software technologies for future embedded and ubiquitous systems, and the second international workshop on collaborative computing, integration, and assurance, washington, 2006. electronic communications of the easst volume 3 (2006) proceedings of the third workshop on software evolution through transformations: embracing the chance (setra 2006) refactoring information systems michael löwe, harald könig, michael peters, and christoph schulz 17 pages guest editors: jean-marie favre, reiko heckel, tom mens managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst issn 1863-2122 eceasst refactoring information systems handling partial compositions michael löwe, harald könig, michael peters, and christoph schulz fhdw hannover, freundallee 15 d-30173 hannover, germany abstract: we present our formal framework for the refactoring of complete information systems, i.e., the data model and the data itself. it is described using general and abstract notions of category theory and can handle addition, renaming and removal of model objects as well as folding and unfolding within complete and partial object compositions. keywords: refactoring, migration, graph transformation, pullback complement 1. introduction the only constant thing is change. this is especially true for the information and communication business. currently, information systems in many companies are subject to change. this is mainly due to the technological progress connected to the internet which enables completely new sorts of electronic business. thus, we see big efforts to re-engineer the technical basis on the one hand and to improve the business processes and information models on the other hand [1]. this development has been reflected in the research and development community in the last years. agile and extreme programming techniques [2] [3] [4] aim at supporting the ongoing reengineering processes by providing refactoring methods, techniques, patterns [5] [6] and tools [7]. these tools enable consistent global changes of a whole software system, for example to introduce some design patterns which are necessary for the system to take the next evolution step. this puts the flexibility into the development process that is needed to keep a system upto-date (without any over-specifications at the beginning of the development) and to realize changing requirements quickly. for the time being, agile techniques in database engineering were often restricted to the improvement and change of model artifacts. the main obstacle for agile techniques here is existing data. attempts to describe semantics-preserving schema transformations that also migrate data can be found in [8] [9]. a transformational approach that considers the instance level is discussed in [10]. if a model of a productive information system is changed, we are faced with one central question: “what shall we do with the data conforming to the old model?” up to now, we hear two major answers: 2 / 17 volume 3 (2006) refactoring information systems 1. leave the data as it is and map the new model to the old one using for example some objectrelational-mapping tools [11].1 2. migrate the data from the old model to the new one by crafting corresponding migration scripts and performing the (long-running) data migration at night or on the weekend. both solutions possess big disadvantages. the first one leads to complex mappings if applied several times. this complexity is very likely to produce performance problems and reduce the development speed of the engineering team in the long run.2 the second solution requires long production breaks and consumes a lot of development and test time for software (migration scripts) that is thrown away after success. we propose another approach, namely the generation of the necessary data migration directly from model refactoring, compare also [12]. one central issue is the correctness of the induced migrations. we can only benefit from this approach if we can trust in the produced migrations without any further tests. therefore, we present a theoretical framework in this paper, which 1. is able to represent models and instances in a uniform meta-model, 2. comes equipped with a suitable notion of model refactoring, 3. provides refactoring-induced correct transformations of the instances (migrations), and 4. proves its applicability by satisfying necessary and natural properties for refactorings and migrations, i.e., that refactoring can be composed in a natural way. the framework is built on category theory [13] and algebraic graph transformation [14]. in this theory, we not only have a very general notion of structured object. by the notion of morphism, we also get a natural way of representing (1) typings of instance objects in model objects as well as (2) model changes (refactorings) and instance migrations. section 2 presents our current framework built on a double-pullback construction, which can handle addition, renaming, and removal of model objects as well as folding and unfolding within complete object compositions [15]. this framework is not able to handle inheritance structures directly. section 3 provides a slight generalization: we do not longer require that the right-hand side of a migration is a pullback. instead we re-use the explicit construction of the pullback complements in more general situations. it turns out that this construction enjoys some categorical properties that guarantee uniqueness up to isomorphism. section 4 shows that the usual sequential composition of refactorings extends to migrations in the generalized framework as well. we sketch in section 5, how the results in this paper can be reformulated on a purely categorical level. we explicitly point out the similarities to the approach of ehrig et al. using adhesive categories [14]. section 6 provides a conclusion and contains hints for future research activities. 1 an older and worse version of this approach is: leave the data-model and the corresponding data as it is and redefine the meaning of the data within the model, for example by using comma-separated multi-value fields in a single string column. 2 the longer this approach is applied, the bigger the problems to switch to the second one. proc. setra 2006 3 / 17 eceasst 2. migration framework for a motivation of the following theoretical aspects, consider the situation of a class department. a possible refactoring would be to extract an abstract superclass unit in order to be prepared for additional specializations [5]. if we interpret generalization as object composition on the instance level, an automated migration must add a unit-object to each department-object in a 1:1 fashion3. after the migration client objects no longer use a single department-object but a new object which contains the unit-information as an aggregated object, see fig. 1. since unit is an abstract class, we can model this refactoring by unfolding department to two classes. this can be done by a morphism l that maps the new model n to the old model m assigning the two classes department and unit in n to department in m. having data d which is typed by the morphism t : d m we obviously can generate the migrated data by calculating the pullback object f of t and l4. another possible refactoring is the addition of a new class [5]. this can be achieved with a (non-surjective) map r from the old to the new model, see fig. 2. here the question arises which categorical construct generates a reasonable migration. moreover, different data structures are possible after the migration: one possibility would be to create no b-object, another to create a default-value or prototype object for b. both solutions lead to pullback diagrams, if objects a1 and a2 are preserved. category theory can be applied in the following way. we can express the typing of some data d in a model m by a morphism t : d m . and we need to express refactorings between models and migrations between typed data. we will have to use the two variations l and r discussed above. but we are not only interested in the model states before and after 3 this interpretation is often used when object models are mapped to relational database systems using the “one table per class”-strategy. this strategy provides one relational table for each class and maps each inheritance association to a foreign key relation from the special to the general class. 4 later, we discuss in which category the construction is carried out. 4 / 17 volume 3 (2006) fig. 1: extracting a superclass d m unit client dept. cl2 dept1 cl1 client dept. l' l vt cl2 dept1 cl1 unit1 n f fig. 2: adding a new class r t' nm t a a b a1 a2 r' d “a reasonable object collection” refactoring information systems refactoring but in the refactoring process itself. hence, it is a good choice to represent one model refactoring from model m to n by a combination of the two variants, i.e., by a pair of morphisms: m  l k  r n . the pair (l, r) represents an arbitrary relation between m and n and can model: 1. deletion of model objects, i.e., l is not surjective, 2. addition of model objects, i.e., r is not surjective, 3. renaming of model objects, i.e., l and r are bijective but not identities, 4. splitting or unfolding of model objects, i.e., l is not injective, and 5. gluing or folding of model objects, i.e., r is not injective. given a typed database t : d m and a model refactoring m  l k  r n , we want to canonically construct the induced migration to some typed database u : e  n . as a first step, we can use the pullback construction of t and l, which shall result in a typed database v : f  k . for reasons of symmetry, we need to construct a pullback complement of v and r in the second step. unfortunately, such a pullback complement is not guaranteed to exist nor need be unique if it exists (see fig. 2). even worse, there is no simple property for r that guarantees existence and uniqueness of the pullback complement. some authors argue that r being epimorphism is sufficient, compare [16] or [17]. this is wrong as the following examples demonstrate. example 1 (ambiguous pullback complements). consider the situation depicted in fig. 3 in the usual category of graphs and graph morphisms. the epimorphism f and the morphism g do not possess a unique (up to isomorphism) pullback complement, since (g, f1*) is pullback of (f, g1*) and (g, f2*) is pullback of (f, g2*) but d1 and d2 are not isomorphic. □ in the category of sets and mappings, however, pullback complements seem to be uniquely determined. this is not (really) true, as is demonstrated by the following example. proc. setra 2006 5 / 17 fig. 3: ambiguous pullback complement g 2 * 1d 1 3 2 g 1 2 1 ,3 1 2 2 ,3 2 f 2 * 2,3 11 32 b g 1 * 2 1 ,3 2 2 2 d 2 f 1 * 2 1 ,3 2 1 2 1 f 3 1 a c m nk d ef r u v r'l' l t (1) (2) eceasst example 2 (ambiguous pullback complements in set). let g:{1,2,3,4}→{a,b} be given by g(1)=a, g(2)=a, g(3)=b, g(4)=b and f:{a,b}→{3} be the constant function as in fig. 4. there are two pullback complements: 1. ({13,24}, f*1:{1,2,3,4}→{13,24}, g*1: {13,24}→{3}) with f*1(1)=13, f*1(2)=24, f*1(3)=13, and f*1(4)=24. 2. ({14,23}, f*2:{1,2,3,4}→{14,23}, g*2: {13,24}→{3}) with f*2(1)=14, f*2(2)=23, f*2(3)=23, and f*2(4)=14. obviously, {13,24} and {14,23} are isomorphic. but no isomorphism i:{13,24}→{14,23} translates f*1 to f*2, in the sense: i ○ f*1 = f*2. hence, we have isomorphic pullback complement objects. but the induced morphisms are ambiguous since they cannot be compared by the existing isomorphisms. □ this type of ambiguity cannot be accepted in our context, since the morphisms represent the transition of the data from the old to the new model. there seems to be no chance to avoid this type of ambiguity, if we do not put additional requirements on the “vertical” morphisms g, g1* and g2*. these properties shall single out a unique choice for the pullback complement extension of g. these examples provide the motivation for the following definitions: definition 3 (graph). the category g of graphs is the algebraic category w. r. t. the signature: sorts: o(bject) opns: s(ource), t(arget): o → o. this is a simple form of graphs where we do not distinguish between nodes and edges. in such a graph, nodes can be characterized as objects n such that s(n) = n = t(n). graphs and graph morphisms of this type provide more flexibility in the refactoring/migration context we are considering here, for example: if two nodes x and y are mapped to the same node z, it is possible that a morphism maps an edge e with s(e) = x and t(e) = y to z, too. e.g. in fig. 1, l(unit) = l(dept.) = dept. and the edge between them is mapped to the node dept. as well. definition 4 (component graph). a component graph g: g → g is a morphism in g. a component graph morphism α: (g: g → g) → (h: h → h) is a pair (α: g → h, α: g → h) such that the resulting square commutes, i.e., ° g=h ° . the comma category cg consists of all component graphs and all morphisms between them. if not otherwise stated, we just write g for a component graph g: g → g. note that g is the underlying graph and g provides a decomposition of g into parts or components via the the 6 / 17 volume 3 (2006) fig. 4: ambiguous pullback complement in set f*1 a b 3 1 3 4 2 13 24 14 23 f g f*2 g*1 g*2 refactoring information systems congruence kern(g)5. thus for the carrier set g we have g= {[ x ]g : x ∈g} where []g denotes congruence classes of kern(g). we also note that congruence classes are not necessarily subgraphs of g as can easily be seen in component graphs id: g → g where g contains edges. the additional component structure on graphs provides means to distinguish typings from refactorings. in a typing, we require that all components are instantiated completely in a 1:1 manner. in a refactoring we allow identification of objects if and only if they belong to the same component. hence, refactorings map components injectively and typings map objects within components bijectively. note that cg has all limits and that pullbacks in cg can be constructed component-wise. definition 5 (typings, refactorings, and migrations). a typing t: g → h is a cg-morphism if for each x ∈g the mapping t :[ x]g [t x]h considered as a set-morphism is bijective. a refactoring is a pair of morphisms m  l k  r n in cg such that l and r are injective. the morphisms l and r are called refactoring morphisms in this case. a refactoring m  l k  r n and a typing t : d  m induce a migration from typing t : d  m to typing u : e n , if there is a diagram as depicted to the right that satisfies: 1. (1) and (2) are pullbacks, and 2. r' is epimorphism. the proof of the following proposition is straightforward and relies on the fact, that pullbacks preserve monomorphisms and isomorphisms. propositon 6 (refactorings, typings, and pullbacks). if (n*: l → g, m*: l → k) is the pullback of (n: k → h, m: g → h) in cg, then 1. m* is a refactoring if m is, 2. n* is a typing if n is, and 3. if n is injective on components, i.e., ∀ x , y∈k : n x=n y∧k x =k  y⇒ x= y , then the same property holds for n*, i.e., ∀ x , y∈ l :n *  x=n *  y∧l x=l  y⇒ x= y proposition 7 (existence and uniqueness of migrations). let m  l k  r n be a refactoring and let t: d → m be a typing. if r: k → n is an epimorphism, then: 1. there is a migration as defined in definition 5 and 2. the result of the migration is uniquely determined (up to isomorphism). 5 the relation kern(f) denotes the congruence that the morphism f induces on its domain, i.e., (x, y) ∈ kern(f) iff f(x) = f(y). proc. setra 2006 7 / 17 m k n d f e l r t v(1) (2) u l' r' eceasst proof. subdiagram (1) can be constructed as a pullback. thus (f, v, l') are unique up to isomorphism. the morphism v is a typing due to proposition 6. having a typing v and a refactoring morphism r, we construct diagram (2), i.e., (e, r', u), as follows and depicted in fig. 5: if the component graph f is the morphism f: f → f, then 1. r' is the identity on f, 2. e=f /≡ where ≡=kern  f  ∩ kernr ° v 3. r ' =[]≡ , 4. u = r °v , 5. u is the unique morphism providing u °r ' =r° v which exists since kern r° v⊇≡ , and 6. component graph e: e → e is the morphism with e° r ' = f which exists since kern  f ⊇≡ . by construction u°r ' =r° v and r' is epimorphism. since kern r ' =kernr ° v on each component and r is an epimorphism, u is bijective on components and thus a typing. and it is easy to show that (v, r') is pullback of (r, u) in set and therefore in cg: if there is o such that r(x(o)) = u(y(o)), then choose o ' = r '−1  yo ∩ v−1 xo . this is unique, since v is bijective on components and, by construction, r' folds on components only. this completes the proof of the first statement. to prove the second statement, let (r*: f → e', u*: e' → n) be any other completion with the required properties. it is easy to see, that the two pullback situations project to pullback situations in set on each component. here we have u * ° r *=u° r ' where u* and u are bijective. hence kern(r*) = kern(r') on each component of f. because r is a refactoring, so are r' and r* (see proposition 6) such that this property holds throughout f. thus e= ~ e ' . □ although the framework presented so far allows copying and gluing of objects within the same component only, it provides some nice features for our purposes of information system refactoring, as the following example demonstrates. example 8 (association redirection). in fig. 1 we showed how to introduce a superclass unit. subsequently, one needs to check the references to departmentobjects and redirect them to unitobjects if necessary. to do this, consider the model refactoring in 8 / 17 volume 3 (2006) fig. 6: redirection of associations 1 2 4 5 6 3 7 1 2,4,5 6 3 7 1,2,6 4 5 3 7 rl fig. 5: constructing the right side of a refactoring k n k n f f e er' r' r r f e vv u u k n refactoring information systems fig. 66: all three graphs have 3 components; the non-trivial component in each graph (the component that has more than one element) is highlighted. using this refactoring in a migration redirects all associations of type “7” from the source of “6” to the target of “6”. it uses an intermediate vertex “2”, that is introduced by the left-hand side l as an unfolding and removed again by the right-hand side r by a corresponding folding. this example shows, that we are able to redirect association sources and targets as long as we stay in the same component. □ with these features, we should be able to handle all refactorings that are concerned with inheritance structures. recall, that inheritance can be considered as some sort of static composition between objects: an object of class c can be considered to be composed of a set of (sub-)objects, namely one object for each direct or indirect ancestor class c' of c. all these objects are created at the same time the most special object is created. and they are also destroyed at the same time. hence, we can model them as explicit parts in a component graph on the instance level in our framework . but these components are not components in the sense of typings (def. 5). it is not the case, that the complete inheritance tree of classes needs to be instantiated, if one class is. if there are concrete classes that possess subclasses, an object might instantiate a proper subpart of the complete inheritance tree of its class, only. our approach is not able to handle those incomplete parts, since pullback complements do not always exist in these situations. example 9 (missing pullback complement). consider the reverse process as in example 8. an association to class “1,2,6” (a concrete superclass of “4”) shall be redirected to its subclass, see fig. 7. we apply this rule to an instance of “1,2,6”, called “1,2,6' ”. the pullback on the left produces an intermediate object “2' ” in f. but we can easily deduce, that the right part is not able to complete the diagram to a double-pullback situation. this is mainly due to the fact that the non-trivial component in k is only partially instantiated in f (there is no “4”-object). for suppose, that such a pullback complement r': f → e, u: e → n exists. then r'(2') is a preimage of “2,4,5” under u. this is only possible if there is a preimage of “4” in f. □ 6 we indicate the model objects numerically to clarify the mappings. proc. setra 2006 9 / 17 fig. 7: missing pullback complement f 1 2 4 5 6 3 7 1 2,4,5 6 3 7 r 1' 2' 6' 3' 7' r v 1,2,6 4 5 3 7 l 1,2,6' 3' 7' t l' m k n d ? eceasst we might use a trick to handle inheritance. we always instantiate complete inheritance graphs, when an object is created and keep the information about the most special real object in the resulting part (of real and extra objects). then we distinguish two views on the system: (1) the refactoring perspective and (2) the operational perspective. in the first perspective, all objects are visible and our framework is applicable. the second perspective blends out all extra objects in order to keep the system's state consistent from the operational point of view.7 with these additional arrangements, inheritance structures and the typical refactorings could be modeled. but there are also disadvantages of this approach: the additional instantiations might cause a significant memory overhead. in this paper, we use a different approach, which omits this problem: in the next section, we slightly generalize our framework such that partial instantiations of components in the model are allowed. to achieve that, we do no longer require that the right-hand side of a migration is a pullback. 3. partial instantiation of components in this section, we relax the requirements for typings. weak typings allow partial instantiations of model components, since they are injective on each component but need not be surjective. definition 10 (weak typing). a component graph morphism α: (g: g → g) → (h: h → h) is a weak typing if it is injective on each component, i.e.,  x =  y ∧ g x = g  y ⇒ x = y . now we use the construction in the proof of proposition 7 to construct the right-hand side of a migration. this works for weak typings as well. construction 11 (folding). consider fig. 8, where weak typing n and refactoring morphism m are given. we construct the folding completion of this situation as follows: 1. m* = ([]≡, idg), where ≡ = kerng  ∩ kernm° n , 2. n* = (i, m°n ), where i is the unique morphism with i °[]≡ = m° n , since kern m° n⊇≡ , and 3. the component graph j is the unique morphism with j °[]≡ = id ° g , since kern g ⊇≡ . m* is a cg-morphism by construction. moreover, we obtain k ° i = m° n° j , since []≡ is epi and k °i °[]≡ = k °m° n = m° n ° g = m° n° j °[]≡ . thus, n* is a cg-morphism, too. □ lemma 12 (folding). if (m*, n*) is folding of (m, n), m* is refactoring morphism and n* is typing. 7 note that the model is stable under the operational perspective! 10 / 17 volume 3 (2006) fig. 8: construction of a folding h h k g g g g/≡ k m id []≡ m k j h g n n i m ○ n refactoring information systems proof. the first part is obvious, since m * has been constructed as the identity which is a mono. for the proof of the second statement let i x = i  y and j x = j  y . now consider arbitrary preimages x' and y' for x and y wrt. []≡, i.e., [x']≡ = x and [y']≡ = y. since j °[]≡ = id ° g , we conclude g(x') = g(y'). since i °[]≡ = m° n , it follows that m(n(x')) = m(n(y')). thus, x ' , y ' ∈ kern g ∩ kernm° n , which means that [x']≡ = [y']≡. hence, x = y. □ folding diagrams possess an interesting universal property as the following proposition shows. proposition 13 (initiality of foldings). let the pair of morphisms (m*: g → f, n*: f → k) be the folding of a weak typing n: g → h and a refactoring morphism m: h → k as it is constructed in construction 11. then for every triple of morphisms (w: g → b, t: b → a, v: k → a) such that t is weak typing and t ° w = v°m°n , there is a unique morphism u: f → b with t °u = v° n * and u° m * = w . proof. let the folding be given as in fig. 8. we set u = w and get immediately (1) u° m * = u ° id = u = w . we show that ≡ ⊆ kernw . let m(n(x)) = m(n(y)) and g(x) = g(y). it follows t(w(x)) = v(m(n(x))) = v(m(n(y))) = t(w(y)) and b(w(x)) = w(g(x)) = w(g(y)) = b(w(y)). since t is weak typing, we get w(x) = w(y) as desired. now there is a unique u: g/≡ → b with (2) u °[]≡ = u °m * = w . since b° u °[]≡ = b°w = w ° g = w ° j °[]≡ = u° j °[]≡ , we can conclude (3) b° u = u ° j . and t °u °[]≡ = t °w = v °m° n = v° i °[]≡ provides (4) t °u = v°i = v° n * . finally, we also have (5) t ° u = v° m° n = v° n * . □ proposition 13 characterizes foldings up to isomorphism. in the following, we say that a diagram is an abstract folding if it has the property of proposition 13: definition 14 (abstract folding). as depicted in fig. 9, a pair (m*: g → f, n*: f → k) consisting of a refactoring morphism m* and a weak typing n* is the abstract folding of a weak typing n: g → h and a refactoring morphism m: h → k if (1) n *°m * = m° n and (2) for every triple (w: g → b, t: b → a, v: k → a) such that t is weak typing and t ° w = v°m°n , there is a unique morphism u: f → b with t ° u = v°n * and u° m * = w . corollary 15 (uniqueness of abstract foldings). two abstract foldings of a weak typing n: g → h and a refactoring morphism m: h → k coincide up to isomorphism. hence (m*: g → f, n*: f → k) is the abstract folding if and only if the statement m* is epimorphism and m * x=m *  y⇔ g x=g  y∧mnx=mn y holds. proof. direct consequence of definition 14 and the fact that the first folding compares to the second and vice versa. therefore, we get two morphisms between the two foldings, which must proc. setra 2006 11 / 17 fig. 9: abstract folding h k a g f b m v n m* n* t w u! eceasst be inverse morphisms, because their composition coincide with the identity on the folding objects (unique morphism from a folding to itself). □ abstract foldings enjoy the same composition and decomposition properties as pushouts or pullbacks. proposition 16 (composition and decomposition of abstract foldings). consider the situation depicted in the diagram below8. 1. if the squares (1) and (2) are abstract foldings, then the rectangle (1) + (2) is an abstract folding.9 2. if the rectangle (1) + (2) and the square (1) are abstract foldings, then (2) is an abstract folding. 3. if typing e and refactoring h is the abstract folding of typing c and refactoring b° a , it can be decomposed into two foldings as in the diagram on the right, where h = g° f , if the underlying category has all abstract foldings. proof. (1) let morphisms v, t, w, be given such that t is typing and t °w = v° b°a °c . since (1) is abstract folding, we get u1 such that u1 ° f = w and t ° u1 = v °b° d . now u1, t and v compare to (2) and we get u2 with u2 ° g = u1 and t °u2 = v°e . substituting u2 ° g = u1 in u1 ° f = w provides u2 ° g ° f = w . for the proof of uniqueness, let morphism u3 be given such that u3 ° g ° f = w and t ° u3 = v °e . then u3 ° g ° f = u 2°g ° f and t °u3 °g = v° b° d = t °u 2° g hold. we obtain u3 ° g = u2 ° g , since (1) is abstract folding. but this implies u3 = u2, since (2) is abstract folding. (2) let v, t, w, be given such that t is typing and t °w = v°b° d . it follows t °w° f = v °b°a° c . since (1)+(2) is abstract folding, there is u such that u ° g ° f = w° f and t ° u = v°e . we also have t ° u ° g = v °e° g = v °b°d . since (1) is abstract folding, we get u° g = w . uniqueness follows from the uniqueness of u for (1)+(2). (3) if there are all abstract foldings, we can construct (d, f) as a folding, which provides diagram (1). the morphism g is obtained as the unique completion of the diagram from the folding (1). that diagram (2) is an abstract folding follows from (2) of this proposition. □ definition 17 (generalized migration). a refactoring m  l k  r n and a weak typing t : d  m induce a generalized migration from t : d  m to weak typing u : e n , if there is a diagram as depicted to the right that satisfies: 1. subdiagram (1) is pullback and 2. subdiagram (2) is abstract folding. 8 here, for the sake of readability, cg-objects are presented in capital letters. 9 (1)+(2) consists of the morphisms b° a , e , g ° f , and c . 12 / 17 volume 3 (2006) a b d ef a c d c fg b e(1) (2) m k n d f e l r t v(1) (2) u l' r' refactoring information systems theorem 18 (existence and uniqueness of generalized migrations). given a weak typing t : d m and refactoring m  l k  r n for the model of t, there is an induced migration and the result of the migration is unique up to isomorphism. proof. direct consequence of (1) the existence and uniqueness of pullbacks in cg, (2) the fact that pullbacks in cg preserve weak typings (proposition 6, 3.), and (3) the existence and uniqueness of abstract foldings in cg (construction 11 and corollary 15). □ theorem 18 justifies that we write r(t) for the result typing of a migration from a typing t : d m using a refactoring r = m  l k  r n . fig. 10 shows the generalized migration that we searched for in fig. 7. 4. sequential composition in this section, we show that there is a natural sequential composition r2 ° r1 of refactorings r1 and r2 and that applying a sequential composition to a weak typing t provides exactly the same result as the sequence of first applying r1 to t and second r2 to r1(t), i.e., r2 ° r 1t =r 2r 1t . definition 19 (sequential composition of refactorings). the sequential composition r2 °r1=l1 ° p1 : j  m , r 2° p2 : j  p of two refactorings r1=l1 : k  m , r1 : k  n  and r2=l 2 : h  n , r2 : h  p is defined with the help of the pullback object  p1 : j  k , p2 : j  h  of r1 and l2 as depicted in fig. 11. note that the sequential composition is well-defined due to proposition 6, 1. and the fact that the composition of two refactoring morphisms is a refactoring morphism again. in order to prove our main theorem, i.e., r2 °r1t=r 2r 1t , we need the following technical lemma. lemma 20 (pullback cubes preserve abstract foldings). consider the commuting diagram in cg below10. if the pair of morphisms (i, q) is the abstract folding of the morphism pair (r, m), 10 here, we depict cg-objects as arrows with filled tip. proc. setra 2006 13 / 17 fig. 11: sequential composition m n k r1 l 1 ph r 2 l 2 j p 2 p 1 (pb) fig. 10: a generalized migration 1 2 4 5 6 3 7 1 2,4,5 6 3 7 r 1' 2' 6' 3' 7' r u 1,2,6 4 5 3 7 l 1,2,6' 3' 7' t l' m k n d 1' 2' 6' 3' 7'r' v f e eceasst the pair (p, t) is the pullback of the pair (s, q), and (j, v) is the pullback of (t, i), then the pair of morphisms (j, p) is the abstract folding of (n, k). proof. the assumptions of the lemma provide that i is the identity. since pullbacks preserve isomorphisms, we can set j = id without loss of generality. because the bottom face is a pullback and i is an epimorphism (see corollary 15), j is an epimorphism as well. again, from corollary 15 we deduce that it suffices to show, that j  x = j y ⇔ [ k n x = k n y ∧ g  x = g y] holds for all x , y ∈ g . “⇒”: (1) j  x = j y ⇒ p j  x = p j  y ⇒ k nx = k n y (2) j  x = j y ⇒ c j  x = c j  y ⇒ id g x = id g y ⇒ g  x = g y “⇐”: let k n x = kn  y ∧ g  x = g  y be given. since (p, t) is pullback, it is sufficient to show: (3) t  j x = t  j  y ∧ (4) p  j x = p j  y: (3) (a) g x = g y ⇒ vg  x = v g y ⇒ h v x = hv y . (b) k n x = kn  y ⇒ sk n x = skn  y ⇒ mrvx = mr v y . since (q, i) is abstract folding, it follows from corollary 15, (a) and (b) that i v x = i v y , which provides t  j x = t  j  y , because t ° j = i °v . (4) k n  x = kn  y ⇒ p j x = p  j y . □ theorem 21 (sequential composition). if r2 r1t  for two refactorings r1 and r2 is defined, we have r2 °r1t=r 2r 1t . 14 / 17 volume 3 (2006) fig. 12: pullback cube s b c a d f g e h k j id i m id n p q r t u v refactoring information systems proof. consider the following diagram, which depicts r2 r1t  . this migration sequence is given by the four squares (1) mkfd, (2) knef, (3) nhce, and (4) hpbc. (1) and (3) are pullbacks and (2) and (4) are abstract foldings. the additional material in the diagram is defined as follows: the pair of morphisms (p1, p2) is given as a pullback of r1 and l2, compare construction of r2 °r1 in definition 19. we write (5) for the resulting square nkjh. we construct (p1',p2') as pullback of (r1',l2'). we write (6) for the resulting square efic. the morphism u2 is the universal completion of the diagram into the pullback object j. now, the square (7) kjif is pullback as well. this is due to the fact that (3)+(6) is pullback11, (3)+(6) = (5)+(7), and (5) is pullback12. the square (8) jich is abstract folding due to lemma 20. now diagram (1)+(7) is pullback, since pullbacks compose. it is the left-hand side of the migration induced by r2 °r 1 . diagram (8)+(4) is abstract folding, since abstract foldings compose (compare proposition 16, 1.). it is the righthand side of the migration induced by r2 °r1 . this together shows that r2 °r1 migrates t to w as well. □ with theorem 21 we are, on the one hand, able to compose long refactoring sequences into one single refactoring, which can capture the effect of the whole sequence. on the other hand, we can decompose complex refactorings into a composition of simpler ones. 5. general framework the whole approach presented above is almost independent from the underlying category of graphs resp. component graphs. what we need for the existence and uniqueness of migrations is the existence of pullbacks and abstract foldings. for the results concerning sequential composition, we need the cube lemma 20, i.e., that pullbacks “pull back” abstract foldings. thus, we can present our requirements for a category to provide the infrastructure for unique migrations and sequential compositions as follows: an abstract migration framework is a category c together with two subcategories t and r which have the same objects as c. the morphisms in t are called typings and the morphisms in r are called refactoring morphisms. the system (c, t, r) is subject to the following requirements: (1) c has all pullbacks 11 composition property of pullbacks. 12 decomposition property of pullbacks. proc. setra 2006 15 / 17 fig. 13: migration sequence j m k n p h l 1 p 1 p 2 r 1 l 2 r 2 d f i e b c l 1 ' p 1 ' p 2 ' r 1 ' l 2 ' r 2 ' t v1 u 2 u 1 v 2 w eceasst (2) c has abstract foldings for all pairs of morphisms (f: a → b ∈ t, g: b → c ∈ r). (3) pullbacks in c preserve morphisms of t and of r. (4) in each cube with corners k, n, h, j, f, e, c, and i, as it is depicted in fig. 13, the square jich is an abstract folding if knef is abstract folding and the squares ifec and nech are pullbacks. since abstract foldings are a generalization of surjective pullback complements13, the framework presented in section 2 fits into this setting as well. another instance is given by simple graphs, arbitrary morphisms as typings and injective morphisms as refactoring morphisms. here we can use surjective pullback complements as abstract foldings as well [15]. 6. conclusion we propose formalizations of aspects in the process of refactoring information systems. the power of our attempt is that a model refactoring can uniquely and automatically be extended to the instance level. in contrast to other more practical solutions, we can prove correctness of our approach. the framework is described using abstract notions from category theory. with a strong assumption to the typing morphisms we can generalize a migration to a doublepullback diagram. as a first step, it is possible to handle addition, renaming, and removal of model objects. the investigation under which conditions folding and unfolding is possible, leads to a model structure where one had to restrict to 1:1 associations on certain components. a refactoring morphism may fold or unfold on these components, only. in a second step we showed that these settings are correct as well. however, object trees of inheritance structures are, in general, not completely instantiated. to treat this case in a similar way, we have to weaken the assumptions on the type mappings. but weak typings do not always lead to double-pullback constructions. thus, this third step requires a generalization of pullback complements. we introduced abstract foldings that enjoy some of the well-known properties of pullbacks and pushouts. abstract foldings are initial in a reasonable context, which reveales a uniqueness statement of generalized migrations and prepares a statement on the composition of refactorings. composing migrations into larger projects and decomposing migrations into smaller steps leads to the question if there is a minimal set of atomic refactorings, from which each refactoring can be constructed by sequential composition. this might be an interesting topic for future research as well as the question, under which conditions refactorings are parallel or sequential independent and can be performed concurrently. these results are valuable for tools that produce migrations on the basis of the construction of pullbacks and abstract foldings. finally, in a forth step, we describe a way of integrating refactoring and migration procedures in a more general framework that abstracts away from the underlying category. we define requirements that are the basis for a generalized system. these requirements are very similar to the axioms for adhesive categories in [14]. it is up to future research to investigate if both frameworks can be seen as two instances of an even more general system. 13 pullback complements such that the morphism into the complement is surjective 16 / 17 volume 3 (2006) refactoring information systems references 1 havey, m.: essential business process modeling. o'reilly (2005) 2 martin, r. c.: agile software development, principles, patterns, and practices. prentice hall (2002) 3 beck, k.: extreme programming explained. addison wesley (2000) 4 beck, k.: test-driven development by example. addison-wesley (2002) 5 fowler, m.: refactoring: improving the design of existing code. addison-wesley (1999) 6 kerievsky, j.: refactoring to patterns. addison-wesley (2004) 7 d’anjou, j et al: the java developer’s guide to eclipse. addison-wesley (2005) 8 ambler, s. w.: agile database techniques. wiley (2003) 9 ambler, s. w.: refactoring databases : evolutionary database design. addison-wesley (2006) 10 hainaut, j.-l.: introduction to database reverse engineering. libd publish. (2002) 11 bauer, ch., king, g.: hibernate in action. manning publications (2004) 12 löwe, m.: evolution patterns – a graphical framework for software redesign. proceedings isas'99 (1999) 13 adamek, j., herrlich, h., strecker g. e.: abstract and concrete categories – the joy of cats. (2004) [http://katmat.math.uni-bremen.de/acc/acc.pdf] 14 ehrig, h., ehrig, k., prange, u., taentzer, g.: fundamentals of algebraic graph transformation. springer (2006) 15 löwe, m., könig, h., peters, m., schulz, ch.: a formal framework for information system refactorization. proceedings wmsci 2006, vol. 1, 75-80 (2006) 16 meisen, j.: pullbacks in regular categories. canad. math. bull. vol.16(2) (1973) 17 bauderon, m., jacquet, h.: pullback as a generic graph rewriting mechanism. applied categorical structures vol.9(1) (2001) proc. setra 2006 17 / 17 1.introduction 2.migration framework 3.partial instantiation of components 4.sequential composition 5.general framework 6.conclusion formal modeling of communication platforms usingreconfigurable algebraic high-level netsthis work has been partly funded by the research project formalnet (see ` `%%%`#`&12_`__~~~) of the german research council and by the integrated graduate program on human-centric communication at technische universität berlin electronic communications of the easst volume 30 (2010) international colloquium on graph and model transformation on the occasion of the 65th birthday of hartmut ehrig (gramot 2010) formal modeling of communication platforms using reconfigurable algebraic high-level nets tony modica, kathrin hoffmann 24 pages guest editors: claudia ermel, hartmut ehrig, fernando orejas, gabriele taentzer managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst formal modeling of communication platforms using reconfigurable algebraic high-level nets∗ tony modica1, kathrin hoffmann2 technische universität berlin1 hochschule für angewandte wissenschaften hamburg2 abstract: communication nowadays is based on communication platforms like skype, facebook, or secondlife. the formal modeling and analysis of communication platforms poses considerable challenges, namely highly dynamic structures and complex behavior. since most of the well-known formal modeling approaches are adequate only for specific aspects of communication platforms, in this paper we introduce the approach of reconfigurable algebraic high-level nets with individual tokens and show in our case study skype that this approach is adequate for modeling the main aspects and features of communication platforms. keywords: algebraic high-level nets, higher-order nets, individual token approach, communication platforms, skype 1 introduction during the last decade, mobile and adaptive communication systems like skype, facebook, or secondlife have become more and more important. these systems have several aspects in common. in mobile and adaptive communication-based systems, communicating entities (actors) can transmit content, which is contextually interpreted. actors may join, move in or leave communication platforms, where the actors’ preferences, access rights and roles are respected and define a temporary set of communicating partners and a context of interpretation for communicated data.1 it is desirable to have a formal modeling technique for communication platforms, so that we can specify the features of such systems in an appropriate way and are able to simulate, test, and analyze/verify them by using not only the structure but also the formal semantics of the modeling technique. general properties of interest are related to consistency, safety and security requirements, liveness, termination etc. we have observed that most of the well-known modeling techniques like uml and actor systems [agh85] or formal specification techniques like process algebras [mil99], low-level and high-level petri nets [rei85, jr91], algebraic specification [em85] and graph transformation [eept06], as well as different kinds of logic are ∗ this work has been partly funded by the research project formalnet (see tfs.cs.tu-berlin.de/formalnet) of the german research council and by the integrated graduate program on human-centric communication at technische universität berlin 1 the notion of communication spaces has been coined in the research area ”modeling and engineering of computer supported communication spaces” of the recently founded innovation center human-centric communication at technische universität berlin as an characterizing concept of communication systems with these properties and as an ontology for describing mobile and adaptive communication systems. 1 / 24 volume 30 (2010) tfs.cs.tu-berlin.de/formalnet formal modeling of communication platforms using reconfigurable ahl nets able to model and/or analyze these aspects only partially. conventional modeling techniques for communication-based systems like classical petri nets and the uml are restricted to model static, immutable network topologies. graph transformation systems in contrast are dynamic in their structure but lack a notion of behavior. of course, appropriate graph transformation systems may also be used to simulate e.g. the behavior of petri nets but it seems advisable to distinguish user behavior from reconfiguration and to possibly use standard results for the behavior analysis of petri nets. moreover, we believe that diagrammatic models like petri nets and graphs supporting visual modeling and visual behavior simulation can have advantages for system modeling w.r.t. readability and understandability, though there is no standard measure for these properties. in the context of concurrent and distributed systems petri nets, first introduced by c.a. petri in [pet62], are a well-known and widely used formalism and have been employed in practical applications in many different areas (see e.g. [rei85, rt86, mm89, mm90, win87, bau90]). their graphical representation and formal semantics excellently support the modeling, simulation, and formal analysis of such systems. high-level net classes are obtained by combining petri nets with an appropriate data type part. most prominent are coloured petri nets [jen92, jen94, jen97], a combination of petri nets and a high-level programming language, which is an extension of the functional programming language standard ml. coloured petri nets offer formal verification methods and an excellent tool support, which has been used in numerous case studies within a large variety of different application areas. apart from this, there are algebraic high-level (ahl) nets [epr93, ehp+02], which give rise to a formal and well-defined description due to their integration of classical algebraic specifications [em85] into petri nets. especially in communication platforms we have to deal with highly dynamic structures and behavior; most notably, the number of users known to the system can grow or decrease during runtime. in order to maintain a variable number of users, we also need a possibility to reconfigure the structure. so we advocate the integrated formal modeling technique of reconfigurable ahl nets for communication platforms like skype, where on the one hand the data type part represents users identities and their communication data and on the other hand suitable rules express the essential features of communication-based activities. moreover, we need to change the marking of a net freely by appropriate rules to be able to process data in a distributed way in contrast to the local effect of transition firing. thus, to achieve an adequate dynamic reconfiguration at runtime, not only the structure of an ahl net is manipulated by rule application but also its marking. a further essential aspect of communication platforms that needs marking-changing rules is multicasting, i.e. transmission of data to selected actors, which can not be realized adequately by the classical firing behavior of petri nets [bee+09]. this paper is organized as follows: in section 2, we show how to model the main requirements of communication platforms in an adequate way with reconfigurable algebraic high-level nets with individual tokens by our case study skype as a typical example of a communication platform. section 3 gives an overview of the analysis results for ahl nets with marking-changing rules. section 4 discusses higher-order markings as concept to provide a control structure for more complex systems to model. section 5 ends with the conclusions and an outlook to future work. proc. gramot 2010 2 / 24 eceasst 2 formal modeling of skype with reconfigurable ahoi nets skype is currently a widely used internet telephone software and can be obtained and used free of charge. in its basic version it features most of the functions a communication tool is expected to have like multi-user conferences and contact management and therefore skype is a reasonable choice for a modeling case study of communication platforms. in this section, we discuss the principles we chose to model skype with ahli nets and demonstrate how we model several aspects of skype features according to these principles. contact management a user should call or chat only with users who explicitly allowed this specific user to contact them. in many communication applications like skype, this is solved with contact lists. to enable a user to add them to his contact list, skype offers a function to search for contacts in a white pages directory of all registered users. the asked user can deny this request. calls a user can directly call one user on his contact list like in a telephone call. the callee gets notified by its skype client and he may then accept the call unless he is already in another call or conference. in this case he has to end the current call before accepting the incoming one. this means that calls and conferences are exclusive communications and a user can only participate in one at a time. conferences a conference is a generalized form of direct call where several participants (up to a technically bounded number) talk to all other participants. a direct call can be considered as special case of a conference with two participants. in skype, if someone starts a conference he is designated as its host who is the only one who can invite other people and kick them out after having joined the conference. if the host quits a conference, it is terminated, i.e. the other conference participant can not send any further messages afterwards. call forwarding known from service hotlines in the field of commercial communications, call forwarding means that the callee transfers an incoming call to another contact in his list as if the caller would have called the contact he is being forwarded to directly, even if the caller does not know this contact. in skype, call forwarding only works for direct calls and is no longer available once a direct call is expanded by the caller to a conference of at least three people. chats chats are similar to conferences but in contrast they are mostly based on sending messages that do not have to be perceived immediately like acoustic messages in calls, wherefore we classify chats as non-exclusive communication. in skype, a user can participate in as many chats as he likes in parallel, add references to them in his contact lists, and look through each chat’s history when it is opened2. apparently, it is not possible to delete the history of a chat in the skype client, so we simply consider skype chats as persistent and users can not actively leave 2 however, management of chats in the skype client is not clearly explained; you may select a set of contacts and start a chat and invite and kick contacts like in conferences. but if you already have created a chat for a set of contacts the old chat and its history are displayed when selecting this particular set of contacts again. 3 / 24 volume 30 (2010) formal modeling of communication platforms using reconfigurable ahl nets a chat they have joined before but only be invited and kicked by other participating users. this is another difference to conferences, where only the host has the right to invite and kick other users; for this reason, a chat does not have an designated host. in the rest of this section, we discuss how to use ahl nets with marking-changing rules to realize these main skype features. 2.1 skype clients as ahli nets ahl nets as a fundamental, visual and formal model in concurrency, have recently been subject for suitable extensions. a useful approach for transformation of marked ahl nets is the rule-based approach with double pushouts of [per95], which has been proven to have the properties of m -adhesive systems (also known as weak adhesive high-level replacement systems) in [eept06] and, thus, providing many analysis results concerning the local church-rosser property, parallelism, and concurrency of transformations. in [per95], the marking of an ahl net has been defined as an element of the commutative monoid (a⊗p)⊕, i.e. a sum of pairs (a, p) where p is a place in the net and a is a data element of the algebra’s carrier set atype(p) that resides as a token on place p. unfortunately, in m -adhesive systems for nets with such “collective” markings, we can only define rules that must not change the markings of places3, which is too restrictive for our modeling approach. ahli nets for this reason, we use the formal technique of ahl nets with “individual” tokens (ahli nets) because for ahli nets we can overcome this restriction and formulate m -adhesive systems with rules that arbitrarily alter the marking of places [mge+10]. thus, essential features like multicasting can be modeled in an appropriate way, which we show in a case study that unites and extends the work done in [bee+09, mod10, mee+10]. an individual marking for a net is a pair (i,m) with i the set of individual tokens and m : i → a⊗p is the marking function, assigning the individual tokens to the data elements on the places. each ahli net with a placewise finite individual token marking (i,m) can be interpreted as an ahl net with marking ∑ i∈i m(i). as a main principle, we strictly distinguish user behavior from system reactions, i.e. we represent everything a user can do like entering data or pushing some buttons in its skype client by some transition in an ahli net. everything else that happens as a consequence to user behavior, especially the extension or restriction of possible user actions, is realized by reconfiguring rule applications. in the following, the whole skype system is always represented by a single ahli net, possibly with discrete components that represent idle user clients or other structures like ongoing conferences. we discuss an extension of ahli nets to further structure and control the components of a skype system is introduced in sect. 4, but as a first step we model skype in a single ahli net. 3 in fact, to simulate the change of a place’s marking this place could be deleted and recreated by the rule with a new marking but this is not possible in every context due to other structural restrictions. proc. gramot 2010 4 / 24 eceasst data types for skype ahli nets for the skype case study, we fix a common signature skype−σ for all nets describing a skype system and for all nets in the transformation rules. this signature consists of the following sorts and operations. we also give the carrier sets of the skype−σ-algebra a we are using for the following skype nets. bool are the usual truth values {true,false} for expressing the state of condition predicates. skypename is the type of words in {a,...,z,a...,z,0,...,9}∗ for identifiying the clients’ user names. data is the type of words in {a,...,z,a...,z,0,...,9}∗ for the data to be transmitted in calls and chats. we chose it for this example but it may be any kind of data. commode is the finite type {call,chat} describing the possible kinds of communications in skype. comrequest is a special type whose elements describe the requests for a communication with some user. there is a simple constructor operation req : skypename × commode → comrequest that builds a request for a name and a mode. state elements from {online,offline,dnd} describe the state of a skype client. states can be compared with a predicate notequal : state×state → bool. log is a type for logging communication events. there is a constant empty for the initial log and two constructor operations sent : log×data → log and rec : log×skypename×data → log to add events for sent data and received data (with information about the sender) to a log. control is a singleton type {•} that is used for controlling the firing of transitions, e.g. to ensure that a transition can be fired only once. the carrier sets in the skype−σ algebra a for the sorts comrequest and log consist only of the terms over the given constructor operations. note that this algebra is used for concrete skype nets only and we describe special algebras for the nets in transformation rules in subsect. 2.2. graphical notation for the nets and rules we use a simplified graphical notation of ahli nets as in fig. 1. the rectangles are transitions and the ovals are places with inscriptions denoting the name and type of a place, e.g. in the lower left the place user of type skypename. below the place’s name we arrange the values of the tokens that mark this place. for example, on place user lies one token with the algebraic value alice. though we are dealing with individual token markings, the actual individuals are not relevant, so we omit the token’s individuals in the graphical notation and give only the values on the corresponding places. the arcs are inscripted with skype−σ terms over variables. a special short notation are inscriptions like s! = offline on the arcs going out from the place state, which means formally that the arc is inscripted with s only and the adjacent transition has a firing condition notequal(s,offline), while the firing condition sets of the other transitions are empty. 5 / 24 volume 30 (2010) formal modeling of communication platforms using reconfigurable ahl nets figure 1: net component for a single skype client client net components the net component in fig. 1 represents the skype client of the user alice. we assume that each registered user is represented by such a client in the overall skype ahli net, though they are unconnected (yet). the owner of a client is determined by the skypename token on the place named user, i.e. this client belongs to a user alice. moreover, it is currently in the state offline as one can tell from the corresponding place. in this configuration, the only activated transition is activate, which on firing replaces the offline state with online and adds a false token to place isparticipating. in this basic form, a client can change its state between offline, online, and “do not disturb”, request a communication to a known user on its contact list, and send data if it is participating in a conference. in the following, we show an example firing step for transition activate in fig. 1. example firing step intuitively, activating the client should result in a token value online on place state. formally, we first have to check that activate is enabled, i.e. that for each term on its incoming arcs there is a corresponding token on the place the arc is going out from. as arcs are inscripted with terms over variables (or here just with variables), we need a variable assignment asg : var(activate) → a assigning algebra values to the variables ocurring on the arcs adjacent to activate. if there is the right number of tokens on the corresponding places with the same values as the evaluated terms (with asg) we say that activate is activated under the assigment asg. in the marked ahli net fig. 1, we see that place state carries a token with value offline which is demanded by the arc going to activate. further, for the variable assignment asg with asg(n) = alice we have obviously that the evaluation of n is the same value as of the token on place user. these are all arcs incoming to activate, so activate is actually activated under this asg and can fire. when firing, activate consumes the aforementioned tokens and as a result produces tokens proc. gramot 2010 6 / 24 eceasst with the values of the evaluated terms of its outgoing arcs on the corresponding places. in the case of fig. 1 and asg(n) = alice, activate produces one token with value online on place state, one with false on isparticipating, and another with asg(n) = alice on user as depicted in fig. 2. the purpose of the other transitions is discussed briefly in the following sections of the corresponding skype features. figure 2: activated net component for a single skype client 2.2 reconfiguration of skype clients following the guideline of behavior distinction, we allow a client just to announce a request for a call to a known client (i.e. whose owner name is present on its place contacts) by firing requestcom. for example, the client in fig. 2 can fire requestcom with variable assignment asg(n) = bob, asg(m) = call, if its user wants to give a call to the client of user bob, which produces a token value (bob,call) on the callee client’s place comrequest. this request enables the system to execute it with the application of the rules that we discuss in the following in more detail. we assume that the skype system promptly reacts to requests with application of the rules that are currently applicable. reconfiguration of ahli nets next, we informally describe a special form of ahli transformations that is sufficient for modeling and understanding the case study in the following section. formally, we use ahli transformation rules following the graph transformation-based approach with double pushouts [eept06]. rules are spans of morphisms ρ : l ← k → r with a left-hand side l, a right-hand side r, and an interface k being the intersection of l and r4, all 4 this means that the rule morphisms are inclusions. 7 / 24 volume 30 (2010) formal modeling of communication platforms using reconfigurable ahl nets these being ahli nets with the same fixed signature skype−σ and a special skype−σ-algebra for this rule. for a rule ρ , we first choose a family yρ = (yρ,s)s∈s of variables that we want to use as variable tokens on the rule net places, such that yρ is disjoint to the variables on the net’s arcs. we then define the algebra for rule ρ as aρ = top(yρ ), i.e. the skype−σ-term algebra over the variables of yρ . due to space limitation in this paper a rule is depicted by l → r, while the interface is obvious. to apply a rule ρ : l ← k → r to an ahli net an, we need a match morphism o : l → an describing the occurrence of l in an. an occurrence match morphism is sufficiently specified by mapping the places, transitions, and tokens of the left-hand side into the target net an. for mapping the tokens, a match needs a token variable assignment asg : yρ → aan . a rule ρ is applicable at a match if the following gluing conditions (cf. [mge+10]) are met w.r.t the match: (1) if a place p in an is adjacent to a transition t that is not in the match then p must be preserved by ρ , and (2) if a token in an that is not matched lies on a place p, then this token must be preserved by ρ . in this case, we achieve the transformation step an = ρ,o =⇒ an′, where an′ results from deleting all parts in an that are matched by parts in l that do not occur in r and then creating the parts occurring only in r and not in l. we give a detailed example of a rule application for the rule in the next paragraph. initiating a conference we do not distinguish one-to-one calls from conferences but we use calls in the sense of a special initial case of conferences. because of this, we go directly for conferences and do not treat calls explicitly. we refer to subsect. 2.3 for how to model data transmission and focus on the conference management in this subsection. fig. 3 shows the left-hand and right-hand side of the rule executecallrequest1, which executes a call request by connecting the client components that play the role of the host (who requested the call) and the callee with a newly created conference structure. given a request for a call as a token req(n,call) (with some skypename value n) on the comrequest place of any client component, the rule executecallrequest1 in fig. 3 can be applied. this rule application extends the host’s behavior options with one transition quit and the callee’s ones with three transitions join,refuse,leave. in fig. 4(a), an example skype ahli net with two unconnected client components is depicted. their owners are alice for the left and bob for the right client and both clients are in the state online. in the following, the token variables of a rule are just the token terms that are not already defined in skype−σ (u1,u2 in executecallrequest1) and their type can be deduced by the corresponding place and operation types the variables are occurring within. the token variable assignment asg : yexecutecallrequest1 → a with asg(u1) = alice,asg(u2) = bob and the place matching indicated by similar place names, e.g. usera 7→ user1 etc. (also denoted with the dashed boxes in fig. 4(a)), describes a valid match for the rule executecallrequest1. the result of applying the rule on this match is shown in fig. 4(b): the newly created nodes and transitions are highlighted with green boxes and the changes in the marking (deletion of the request token and replacing false with true on isparticipatinga) is highlighted with red circles. proc. gramot 2010 8 / 24 eceasst extended client behavior in the reconfigured skype ahli net, the host may quit5, which sets a request to disband the conference. the conferencing place holds the names of all users that actively participate in this conference. we consider a client as participating if it can send and receive messages from all other participants, i.e. it has been invited and joined the conference but has not left it yet. at the beginning of a conference, the host is the participating client. initially, if the callee is not already participating in another conference he has the choice to either join, which would copy his name to the conferencing place, or to refuse, which signals a request to disconnect the client from this conferencing structure. note that the firings of join and refuse are mutually exclusive due to the invited place type control, which carries a black token to allow firing either join or refuse. after having joined, a client may leave which removes the client’s name from the conferencing place and announces the request to disconnect like transition refuse would do. finally, the callee can choose to forward the call to another of its known clients (not the host) by firing requestforward, which produces a request token req(n,forward) on the place forwardrequest. figure 3: rule executecallrequest1 ensuring sensible rule applications of course, rules that execute requests by reconfiguring the ahli net must not be applied to random places of the appropriate type somewhere in the whole system but to specific places of a client in order to yield sensible structures. for example, in the left-hand side of the rule in fig. 3, we assume the upper three places to be matched on the corresponding places of one client component. we can restrict applications of this rule on desired matches by demanding that the matches satisfy (positive) application conditions in the sense of [eept06]. formally, an application condition for a rule lρ ← kρ → rρ is an additional morphism (inclusion) ac ← lρ . if an application condition is a positive application condition, it is satisfied for a match o : lρ → an if there exists also a valid match ac → an. this means that a positive application condition requires additional structures for a match to find. for example, for the three 5 in the following, we simply use the transition name for describing the triggering action, e.g. “the host quits”, instead of saying “the host client fires the transition quit”. 9 / 24 volume 30 (2010) formal modeling of communication platforms using reconfigurable ahl nets (a) skype ahli net before application (b) after application of executecallrequest1 figure 4: example application of executecallrequest1 for alice calling bob proc. gramot 2010 10 / 24 eceasst upper places in lexecutecallrequest1 we can formulate an application condition consisting of the net in fig. 1. this ensures that the match has to find e.g. a transition like activate in fig. 1 between the places in an that are matched by user1 and isparticipating1 with o. similarly, we can forbid additional parts with negative application conditions, which demand that there does not exist a valid match ac → an. we omit the actual positive application conditions for rules in this paper and express informally in the left-hand side with dashed boxes that their contents can be matched only on corresponding places of a client, e.g. as in the left-hand side of executecallrequest1 with the box around the three upper places and similarly with the box around the lower two places. additionally, for a better understanding of the rule’s effect, a dashed box for a client role in the rule’s right-hand side comprises the transitions that are intended to represent new possible actions that can be performed by this particular client, e.g. the transition quit in the right-hand side of executecallrequest1 that is supposed to be a host action. inviting to a conference the rule executecallrequest1 would be sufficient for modeling direct calls involving only two people, which we consider as a minimalistic conference. now we extend the system by a rule that allows to invite more clients to a running conference. in this case, we employ the second rule executecallrequest2 in fig. 5 for reacting to call requests and for inviting more clients. this rule needs to match a conferencing place that is hosted by the requesting client (note the dashed box, representing an appropriate application condition) who has not already quit. on the one hand, this rule simply connects the requested participant (containing the lower boxed parts) to the existing conference as the previous rule would do if the conference were not already created. on the other hand, it deletes the transition requestforward, which restricts the behavior of the first callee that has been connected with executecallrequest1 before, because we allow call forwarding only in one-to-one calls. the empty place quitrequest in the left-hand side could perfectly match a place with a token control, so we have to avoid a host to quit the conference before the system connects a newly invited participant by an explicit token value false. figure 5: rule executecallrequest2 11 / 24 volume 30 (2010) formal modeling of communication platforms using reconfigurable ahl nets leaving a conference the rule executedisconnectrequest in fig. 6, which handles the request for disconnecting a called client, is almost the inverse of the rule executecallrequest2 in fig. 5 but with a control token on disconnectrequest instead of invited. it assumes that a client either has refused the connection or has joined and then left, which created a request token for disconnection. the rule then deletes the conference structure part of the client to be disconnected as they are no longer needed. when leaving a conference there is just no need to represent these actions any more. note that the rule leaves the parts untouched that have been in the client from the start in order to leave the core client functional and to allow further connections. for disconnecting the callee that has been connected first to a conference with executecallrequest1, a similar rule is needed that also deletes this participant’s requestforward transition and forwardrequest place. figure 6: rule executedisconnectrequest closing a conference if the host has quit the conference, the rule executequitrequest in fig. 7 can match and remove the remaining conference structure after all participants have left the conference with the previous rule. we do not need a negative application condition to prevent “dangling” join and leave transitions from possibly connected clients. due to the dangling conditions for rule applications, a rule can not delete the environment of a transition that is not part of the match. more precisely, a rule is not applicable if a matched place is connected to an unmatched transition and the rule deletes this place. further use cases for reconfiguration due to space limitations we only discuss briefly some more use cases for reconfiguring rules: a rule for executing the forward request of the callee in a one-to-one call deletes the transitions and places of the callee appearing in a conference and builds up the same structure for the client that the call is forwarded to so that it has the choice to join or refuse the call. another interesting aspect is the creation of clients. a rule with empty left hand side and the client net of fig. 1 as right-hand side (but with a variable as skypename user token and empty contacts place) could be used to create clients for new users. an application condition should proc. gramot 2010 12 / 24 eceasst figure 7: rule executequitrequest prevent that a client with the same user name as an existing one is created by the rule. for the previous rules, we assumed that the host accesses contacts on his contact place. with an additional transition, the client could produce requests for contact exchanges that lets a client with the requested name decide whether the requester may add the unknown client’s name to its contact list (cf. the rules given in [mod10]). finally, one may object that there are cases when call requests should be discarded, e.g. when the called client is offline or does not want to be disturbed, which can be realized with appropriate negative application conditions for the executing rules and a rule that catches these illegal requests by deleting them. 2.3 multicasting with amalgamated rules in skype conferences and chats, one client transmits data to a group of clients, i.e. the participating clients, which is a typical concept in communication platforms. this communication behavior is called multicasting and is a challenge for petri net-based modeling techniques since the number of participating clients is not known a priori. a possible but not fully adequate way is to split the group transmission into single transmissions to each participating actor. this makes it necessary to code the status of the multicast data for each actor into the net. furthermore, each client has to be connected to every other actor in order to be able to perform multicasting which leads to a massive explosion of the net structure size in communication nets with multicasting. instead, we use a more practical way of specifying multicasting for communication platforms [bee+09], namely amalgamation of ahli net transformation rules, which realizes a controlled, parallel rule application at all possible matches at once [gol10]. informally, the application of an amalgamated rule is the application of one or more rules (called multi-rules) that have a common subrule (called kernel rule) at several matches in parallel that overlap in a match of the kernel rule. an interaction scheme defines such a set of multi rules and relates them by a common subrule. consider a conference in the ahli skype net. now, one of its participating clients, considered the sender in this situation, generates some data to be transmitted by firing its transition send (cf. fig. 1). this produces a token of type data on the out place of this client component6. 6 actually, data may be any kind of data: textual, visual, acoustic etc. 13 / 24 volume 30 (2010) formal modeling of communication platforms using reconfigurable ahl nets figure 8: interaction scheme for multicasting in conferences somehow, this data has to be dispatched to all other participating clients, which we realize with the interaction scheme consisting of the one multi rule and the kernel rule in fig. 8. the top part is the kernel rule that matches the sender client’s name token on the conference place and its out place with the data token to send. the only effect of the kernel rule is that the data token is deleted from the sender’s client. a match for the kernel rule fixes the conference and the sender whose message is multicasted to all participating clients. a match for the multi rule now complies to the kernel match on the common parts and additionally matches another client that corresponds to another skypename token on the conference place and sends the message to the receiving client. here we use an appropriate algebraic operation rec that combines the actual history h2, the sender u1 and the message itself to generate the new history of messages. we require that amalgamated rules over this interaction scheme are built with maximal matching, i.e. that for a given kernel match the multi rule is applied at all possible matches on the skype ahli net. clearly, for every participant in a conference fixed by the kernel match there exists a match for the multi rule. each match of the multi rule is part of the amalgamated rule and lets this participant receive the multicasted message when the amalgamated rule is applied. thus, applications of amalgamated rules built over maximal matchings of the interaction scheme in fig. 8 realize complete multicastings in conferences. further use cases for amalgamated rules interaction schemes with maximal multi rule matching is an important and often used formalism to handle an unknown number of structural parts or tokens. for example, the deletion of a user client is not possible with a simple rule because there is an unknown number of name tokens on its contacts place and a rule can only delete a place when all of its tokens are matched (cf. subsect. 2.2). another interesting case proc. gramot 2010 14 / 24 eceasst would be an interaction scheme for executing more than one call request of a conference host with one transformation step, which, when amalgamated over all possible matches, connects all clients to the conference structure that correspond to the request tokens. 2.4 chats in skype, a client can participate in many chats in parallel. this means that a client has to create the data to be transmitted and to log events in the context of the chat. the transition send in the client component in fig. 1 is not adequate to create messages for chats because there is no way to specify the context of the message, i.e. the chat it is meant to be multicasted in. moreover, the part of the history of a chat that a participant experienced is always available to him once the chat has started, even if he was kicked by another participant. we assume a further functional requirement for chats: if a client participated in a chat and has been kicked out, then its history should be preserved so that on reinvitation the client can continue its history for the same chat where it has left. creating chats with the rule executecreatechat in fig. 9(a), the system reacts to a request token req(u2,chat) on a client’s comrequest place by creating a chat structure similar to rule executecallrequest1 in fig. 3 before. a place carries the names of all participating users and for the initiator and the invited user the rule creates transitions and places for sending and receiving data in the context of this chat. multicasting in chats for multicasting data tokens that a participating chat user has produced with the local send transition, we can employ an interaction scheme similar to the one for conferences in fig. 8. the only differences are that the conferencing place is now a chat place and the application conditions have to ensure that the out and history places associated to a participant are the local ones for this chat instead of the corresponding places in the client of fig. 1. managing chats in chats, every participant may kick other participants and add some of his contacts, as long as he has not already been kicked himself. in the two rules executecreatechat in fig. 9(a) and executeaddchat in fig. 9(b) the corresponding transitions for these actions are created for clients that have been invited to a chat, where the rule executeaddchat reacts to an invitation request that any chat participant has created. a kicked participant’s name gets removed from the chat place but the structure around his local chat transition send will be preserved and so will his history. nevertheless, henceforth this user can not send or receive messages in this chat. if a kicked user of a chat gets readded, the rule executereaddchat in fig. 9(c) can be applied, which assumes that the local chat structure for a client is already present and simply readds its user name to the chat place. as a result, the history of a kicked participant is preserved and the client again can send messages and receives messages from applications of the multicasting interaction scheme. finally, in order to avoid redundant structure to be created, we have to prevent the rule executeaddchat to be applied in the case when a client is already connected to a chat. we realize this by defining the left-hand side of rule executereaddchat as a negative application condition for rule executeaddchat. 15 / 24 volume 30 (2010) formal modeling of communication platforms using reconfigurable ahl nets (a) rule executecreatechat (b) rule executeaddchat (c) rule executereaddchat figure 9: rules for creating and managing chats 3 analysis of reconfigurable ahli net models in this section, we first state that ahl nets with individual tokens are an m -adhesive category and summarize the main results available for reconfigurable ahli nets. the proof of these technicalities can be found in [mge+10]. afterwards we show that a firing step can be simulated by an appropriate rule and present an important result concerning the independence of firing steps and rule applications. proc. gramot 2010 16 / 24 eceasst 3.1 petri nets with individual tokens compared to collective tokens the main result in [eept06] concerns the formal foundation for transformations of low-level and high-level petri nets in the collective token approach based on the framework of m -adhesive categories, i.e. weak adhesive high-level replacement (hlr) systems in the sense of [ehpp06]. m -adhesive categories have been introduced as a new categorical framework for graph transformation in the dpo approach. they combine the well known framework of hlr systems with the framework of adhesive categories introduced in [ls05]. the framework of m -adhesive categories provides many useful results well-known from graph transformation [roz97], concerning the applicability of rules, embedding and extension of transformations, parallel and sequential dependence and independence, and concurrency of rule applications. the concept of parallel independence states that two parallel transformation steps are not in conflict, i.e. each of the transformations does not delete anything that is required by the other one. two consecutive transformation steps are sequentially independent if they are not causally dependent, i.e. the first rule does not produce anything that is required by the second. provided that the corresponding conditions are satisfied two alternative transformation steps can be swapped and each of them is applicable after the other one. classical petri nets and ahl nets have been shown in [eept06, ehp+08] to define a weak adhesive hlr category for the class m of all injective net morphisms. this allows us to apply all the results for m -adhesive systems shown in [eept06] also for petri net transformation systems. the concept of petri systems leads to a category ptsys with morphisms allowing to increase the number of tokens on corresponding places. unfortunately, (ptsys,min j) with the class min j of all injective morphisms is not m -adhesive in contrast to (ptsys,mstrict), where mstrict is the class of strict injective morphisms where the number of tokens on corresponding places is equal. this, however, is an unpleasant restriction for the usability of the transformation approach, especially the firing of a transition cannot be simulated in a natural way by the application of a corresponding “transition rule”. since we have shown that ahli nets form an m -adhesive category with a class of non-strict morphisms m , we can apply these results to the rules presented in sect. 2. amalgamated rules are in general standard rules in m -adhesive transformation systems so that we have the same results for them [gol10]. an example for parallel independent transformation steps is given by the rules executecallrequest2 (cf. fig. 5) and executedisconnectrequest (cf. fig. 6) applied to the same clients, where alice is hosting a conference in which both bob and carol are currently participating and there is a call request for dave. in this case we can first apply executedisconnectrequest to disconnect carol’s client, as well as dave can be invited first by applying executecallrequest2. these requests are parallel independent because each of these rules can be applied after the application of the other yielding the same result where carol’s client has been disconnected and dave has been invited. 3.2 simulating firing steps by rule applications based on the observation of parallel and sequential independence of rule applications the main results in [ehp+07] deals with conflict situations between transformations and token firing. the traditional concurrency situation in petri nets is that two transitions with overlapping pre domain 17 / 24 volume 30 (2010) formal modeling of communication platforms using reconfigurable ahl nets are both enabled and together require more tokens than are available in the current marking. as ahli nets can evolve in two different ways the notions of conflict and concurrency become more complex. assume that a given ahli net represents a certain system state. the next evolution step can be obtained not only by token firing but also by the application of one of the rules available. hence under certain conditions each of these evolution steps can be postponed after the realization of the other, yielding the same result, and can be performed in a different order without changing the result. in the individual token approach we are able to manipulate the net’s marking by rule application. thus, here the result of independent firing and transformation steps is achieved in a more elegant way by using the well-known result of two independent transformation steps. for this reason we first construct a specific rule which application corresponds to a single firing step. the so-called ahli transition rule consists of a fixed ahli net part given by a transition and its environment. the marking of the ahli net in the left hand side is chosen in such a way that the transition is enabled and the marking of the ahli net in the right hand side is exactly the follower marking after transition firing, while the marking in the interface is empty. note, that the construction of an ahli transition rule only depends on a specific transition with corresponding token selection. but there may exist several consistent transition assignments enabling the transition and, therefore, different consistent transition assignments may result in the same ahli transition rule. in [mge+10], we have shown that there is an equivalence between a firing step of an ahli net and a transformation step via the corresponding ahli transition rule. figure 10: example transition rule an ahli transition rule is depicted in fig. 10: the fixed ahli net part for l,k, and r is given by the transition activate and its environment consisting of the places state,user and isparticipating as well as the net inscriptions according in fig. 1. as explained in subsect. 2.1 the tokens with values offline and alice in the left-hand side l enable the transition activate and are replaced by tokens with values online, alice, and false on the corresponding places in the right-hand side r while the marking of the interface k is empty. proc. gramot 2010 18 / 24 eceasst 4 higher-order nets as control structures in this section, we discuss an extension of ahli nets to support an adequate control structure over complex skype systems and their rule applications. due to our case study modeling skype with ahli nets and ahli transformation rules, we have proven that this technique is powerful enough to model typical features of communication platforms. anyway, the concepts of petri net behaviour via transition firing and petri net reconfiguration with transformation rules are only loosely coupled. we designed the rules to demand requests to be applicable to the skype ahli net for realizing the requests with reconfiguration of the skype net, but the formalism of reconfigurable ahli nets itself is more similar to graph transformation systems in the sense that rules are assumed to be applied “at the right time”. so, we need a possibility to express that requests must be processed immediately, i.e. a control structure for the firing behavior and reconfiguration of ahli nets. several formalisms for controlling graph transformations have been proposed [heet98, kk99] but due to their orientation to graph transformation they lack the possibility to relate reconfigurations (by rule applications) to firing steps. algebraic higher-order nets a useful approach for controlling firing steps and transformations of low-level petri nets has been introduced in [hme05] with ahl nets that contain place/transition nets and transformation rules as tokens. in our project formalnet, we call such nets algebraic higher-order (aho) nets due to the “nets on nets” structure. aho nets have two important aspects that distinguish them from the original notion of nested petri nets called object nets in [val98]: first, aho nets do not only have petri nets as tokens but also transformation rules, which qualifies them especially for controlling reconfigurable petri nets. second, ahos are formulated as regular ahl nets with signatures and algebras that provide operations for firing the token nets and for applying token rules on token nets. this means, that we do not need a new formalism and can use all results for aho nets that we already have for ahl nets. moreover, we can use any kind of petri nets and their corresponding transformation rules as tokens, as long as we can define their firing behavior and transformation algebraically for the containing aho net. we recapitulate the example from [hme05] that realizes reconfigurable petri nets as an algebraic higher-order net and then discuss an idea how we can use this approach for better controlling request execution in our case study. figure 11: algebraic higher-order net for reconfigurable petri nets fig. 11 depicts an aho net where we assume that it can carry marked place/transition nets 19 / 24 volume 30 (2010) formal modeling of communication platforms using reconfigurable ahl nets as tokens of the sort system on its place p1 and petri net transformation rules as tokens of the sort rules on its place p2. to simulate a firing step of a net token on p1, the aho net fires its transition token game, which selects a net token n from p1 if this net contains some enabled transition, which is ensured by the firing condition enabled(n,t) = true of the higher-order transition. the firing of token game then produces a token with value fire(n,t) that is just the net n where t has fired. rule applications are realized similarly by firing the higher-order transition transformation, which selects a net token n from p1 and a rule token r from p2 if the rule is applicable at some match m into net n. firing transformation then produces the token net that results from the application of the selected rule on this match, which is calculated algebraically by transform(r,m). controlling skype ahli nets we now consider two extensions of the approach in [hme05] in order to express with an aho net that actions in skype ahli nets posing requests must be handled immediately by reconfiguring rule applications. obviously, we have to extend the definitions of the sorts system and rules (cf. fig. 11) from place/transition nets and rules to ahli nets, ahli rules and interaction schemes with maximal matching, respectively. then we can build an aho net for the skype case study as in fig. 12. the transition token game now only fires transitions in the token net skype that are not producing a request token or can be understood as a signaling request in any way. this is decided by the predicate produces request(n,t,asg) that has to be defined according to the system to be modeled. note that for high-level nets as tokens we also need to consider a valid variable assignment for a firing step. the other transitions in the token net that may trigger a reconfiguring rule, i.e. with produces request(n,t,asg) evaluating to true, are fired in the token net skype via the higher-order transition request and execute, which first fires a transition in the token net n and then immediately applies a rule from p2 on n. with this aho net, we can express the complete firing and reconfiguration behavior of the case study in a single ahl net and requests in the skype systems can not remain unexecuted. this is just a first step of generalizing reconfigurable nets. we are free to distribute the transformation rules to different places and to restrict their applications by conditions that are expressed by algebraic operations depending on the system we want to model, like we did with produces request in the small example. with aho nets we can ensure that these conditions are met and for example relate transition firing steps with rule applications, which is a further valuable tool for modeling and proving properties in addition to the analysis results in the previous section. figure 12: algebraic higher-order net for skype ahli nets proc. gramot 2010 20 / 24 eceasst 5 conclusion in this paper, we have shown that our approach of algebraic high-level nets with individual tokens is powerful enough to cover the main requirements of communication platforms by examplarily modeling the network’s topology and the group communication in skype. in our approach, structures for communication are added to system only in case when they are needed and are removed after the communication action has been completed and we strictly distinguish user triggered client behavior and system reactions. we have presented the important result of the category of ahli nets forming a m -adhesive category to analyze ahli models for communication platforms e.g. by parallel and sequential independence. an essential aspect that is used frequently in communication platforms is multicasting, i.e. transmission of data to selected actors, which can not be realized adequately only with the classical firing behavior of petri nets [bee+09]. for modeling multicasting, we refrain from adding a massive net structure that connects the sender with each of the receiver components. instead, we defined an interactions scheme allowing to find all receivers with the appropriate access rights in a possibly large system net. for our approach of modeling multicasting with amalgamated rule applications [bfh87], we rely on the formalism of nets with individual tokens, which allows to formulate rules for m -adhesive systems with that can manipualte freely the marking of nets, in contrast to m -adhesive systems of nets with “collective” markings. in order to control the firing and reconfiguration of ahli models for communication platforms we proposed to use the ahli formalism itself by considering the actual net and the rules of a reconfigurable ahli system to be tokens in an algebraic higher-order net. the means, for controling the firing and reconfiguration behavior of their net and rule tokens, suitable operations are defined in the higher-order net’s algebra for firing transitions in the net tokens and for applying the rule tokens on the net tokens [hme05]. it remains to examine how the structure of the higher-order net can be further used to improve the modeling of communication platforms. another possible abstraction is the step to reconfigurable aho nets, which could be used for specifying system updates and changes by creating new rule tokens or modifying existing rules. we have implemented an eclipse-based tool environment, which currently allows modeling, simulation and analysis of a restricted kind of aho nets with p/t nets and rules as tokens [bm08]. this tool supports analysis of all possible types of conflicts w.r.t to a token net: between applications of two rules on a net token, between firing steps in a net token, and between firign steps and applications of a rule on a net token (cf. subsect. 3.2). an extension of our tool to reconfigurable ahli nets with amalgamation and controlling aho nets that supports the presented approach is planned for the future. bibliography [agh85] g. agha. actors: a model of concurrent computation in distributed systems. phd thesis, mit, 1985. cambridge: mit press. [bau90] b. baumgarten. petrinetze, grundlagen und anwendungen. bi, 1990. 21 / 24 volume 30 (2010) formal modeling of communication platforms using reconfigurable ahl nets [bee+09] e. biermann, h. ehrig, c. ermel, k. hoffmann, t. modica. modeling multicasting in dynamic communication-based systems by reconfigurable high-level petri nets. in ieee symposium on visual languages and human-centric computing, vl/hcc 2009, corvallis, or, usa, 20-24 september 2009, proceedings. pp. 47– 50. ieee, 2009. [bfh87] p. böhm, h.-r. fonio, a. habel. amalgamation of graph transformations: a synchronization mechanism. journal of computer and system science, pp. 377–408, 1987. [bm08] e. biermann, t. modica. independence analysis of firing and rule-based net transformations in reconfigurable object nets. in c. ermel and heckel (eds.), proc. workshop on graph transformation and visual modeling techniques (gtvmt’08). volume 10. ec-easst, 2008. [eept06] h. ehrig, k. ehrig, u. prange, g. taentzer. fundamentals of algebraic graph transformation. eatcs monographs in theoretical computer science. springer verlag, 2006. [ehp+02] h. ehrig, k. hoffmann, j. padberg, p. baldan, r. heckel. high-level net processes. in formal and natural computing. lncs 2300, pp. 191 – 219. springer, 2002. [ehp+07] h. ehrig, k. hoffmann, j. padberg, u. prange, c. ermel. independence of net transformations and token firing in reconfigurable place/transition systems. in proc. of 28th international conference on application and theory of petri nets and other models of concurrency. lncs 4546, pp. 104–123. springer, 2007. [ehp+08] h. ehrig, k. hoffmann, j. padberg, c. ermel, u. prange, e. biermann, t. modica. petri net transformations. in petri net theory and applications. pp. 1–16. i-tech education and publication, 2008. [ehpp06] h. ehrig, a. habel, j. padberg, u. prange. adhesive high-level replacement systems: a new categorical framework for graph transformation. fundamenta informaticae 74(1):1–29, 2006. [em85] h. ehrig, b. mahr. fundamentals of algebraic specification 1: equations and initial semantics. eatcs monographs on theoretical computer science 6. springer, 1985. [epr93] h. ehrig, j. padberg, l. ribeiro. algebraic high-level nets: petri nets revisited. in proc. of the adt-compass workshop’92 (caldes de malavella, spain). berlin, 1993. technical report 93-06. [gol10] u. golas. multi-amalgamation in m -adhesive categories. technical report 2010/05, technische universität berlin, 2010. [heet98] r. heckel, h. ehrig, g. engels, g. taentzer. classification and comparison of modularity concepts for graph transformation systems. in proc. 6th int. workshop on theory and application of graph transformation (tagt’98). 1998. proc. gramot 2010 22 / 24 eceasst [hme05] k. hoffmann, t. mossakowski, h. ehrig. high-level nets with nets and rules as tokens. in proc. of 26th intern. conf. on application and theory of petri nets and other models of concurrency. lncs 3536, pp. 268–288. springer, 2005. [jen92] k. jensen. coloured petri nets. basic concepts, analysis methods and practical use. volume 1: basic concepts. springer verlag, eatcs monographs in theoretical computer science edition, 1992. [jen94] k. jensen. coloured petri nets basic concepts, analysis methods and practical use. volume 2: analysis methods. springer, eatcs monographs in theoretical computer science edition, 1994. [jen97] k. jensen. coloured petri nets basic concepts, analysis methods and practical use. volume 3: practical use. springer, eatcs monographs in theoretical computer science edition, 1997. [jr91] k. jensen, g. rozenberg (eds.). high-level petri nets. springer, 1991. [kk99] h.-j. kreowski, s. kuske. graph transformation units with interleaving semantics. formal aspects of computing 11:690–723, 1999. [ls05] s. lack, p. sobocinski. adhesive and quasiadhesive categories. theoretical informatics and applications 39(5):511–546, 2005. [mee+10] t. modica, c. ermel, h. ehrig, k. hoffmann, e. biermann. modeling communication spaces with higher-order petri nets. in lasker and pfalzgraf (eds.), advances in multiagent systems, robotics and cybernetics: theory and practice. volume iii. the international institute for advanced studies in systems research and cybernetics, tecumseh, canada, 2010. to appear. [mge+10] t. modica, k. gabriel, h. ehrig, k. hoffmann, s. shareef, c. ermel, f. hermann, u. golas, e. biermann. low and high-level petri nets with individual tokens. technical report 13/2009, technische universität berlin, 2010. [mil99] r. milner. communicating and mobile systems: the pi-calculus. cambridge university press, june 1999. [mm89] n. martı́-oliet, j. meseguer. from petri nets to linear logic. in lncs389 (ed.), proc. category theory and computer science. pp. 313–340. springer-verlag, 1989. [mm90] j. meseguer, u. montanari. petri nets are monoids. information and computation 88(2):105–155, 1990. [mod10] t. modica. towards formal algebraic modeling and analysis of communication spaces. in haveraaen et al. (eds.), calco young researchers workshop (calcojnr 2009) – selected papers. technical report 5-2010, pp. 89–103. università di udine – dipartimento di matematica e informatica, 2010. http://calco09.dimi.uniud.it/calcojnr booklet.pdf 23 / 24 volume 30 (2010) http://calco09.dimi.uniud.it/calcojnr_booklet.pdf formal modeling of communication platforms using reconfigurable ahl nets [per95] j. padberg, h. ehrig, l. ribeiro. algebraic high-level net transformation systems. mathematical structures in computer science 5:217–256, 1995. [pet62] c. petri. kommunikation mit automaten. phd thesis, schriften des institutes für instrumentelle mathematik, bonn, 1962. [rei85] w. reisig. petri nets: an introduction. eatcs monographs on theoretical computer science 4. springer, 1985. [roz97] g. rozenberg. handbook of graph grammars and computing by graph transformations, volume 1: foundations. world scientific, 1997. [rt86] g. rozenberg, p. thiagarajan. petri nets: basic notions, structure, behaviour. in current trends in concurrency. lncs 224, pp. 585–668. springer, 1986. [val98] r. valk. petri nets as token objects: an introduction to elementary object nets. in icatpn ’98: proceedings of the 19th international conference on application and theory of petri nets. lncs 2987, pp. 1–25. springer, 1998. [win87] g. winskel. petri nets, algebras, morphisms, and compositionality. information and computation 72:197–238, 1987. proc. gramot 2010 24 / 24 introduction formal modeling of skype with reconfigurable ahoi nets skype clients as ahli nets reconfiguration of skype clients multicasting with amalgamated rules chats analysis of reconfigurable ahli net models petri nets with individual tokens compared to collective tokens simulating firing steps by rule applications higher-order nets as control structures conclusion optimizing pattern matching compilation by program transformation electronic communications of the easst volume 3 (2006) proceedings of the third workshop on software evolution through transformations: embracing the change (setra 2006) optimizing pattern matching compilation by program transformation emilie balland and pierre-etienne moreau 14 pages guest editors: jean-marie favre, reiko heckel, tom mens managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst optimizing pattern matching compilation by program transformation emilie balland1 and pierre-etienne moreau2 1uhp & loria at nancy, france emilie.balland@loria.fr 2inria & loria at nancy, france pierre-etienne.moreau@loria.fr abstract: motivated by the promotion of rewriting techniques and their use in major industrial applications, we have designed tom: a pattern matching layer on top of conventional programming languages. the main originality is to support pattern matching against native data-structures like objects or records. while crucial to the efficient implementation of functional languages as well as rewrite rule based languages, in our case, this combination of algebraic constructs with arbitrary native data-structures makes the pattern matching algorithm more difficult to compile. in particular, well-known many-to-one automaton-based techniques cannot be used. we present a two-stages approach which first compiles pattern matching constructs in a naive way, and then optimize the resulting code by program transformation using rewriting. as a benefit, the compilation algorithm is simpler, easier to extend, and the resulting pattern matching code is almost as efficient as best known implementations. keywords: pattern matching, optimization, program transformation 1 introduction to tom pattern matching is an elegant high-level construct which appears in many programming languages. similarly to method dispatching in object oriented languages, it is essential in functional languages like caml, haskell, or sml. it is part of the main execution mechanism in rewrite rule based languages like asf+sdf, elan, maude, or stratego. in this paper, we present tom1 whose goal, similarly to prop [leu96] or pizza [ow97], is to integrate the notion of pattern matching into classical languages such as c and java. following the first ideas presented in [mrv03], illustrated in figure 1, a tom program is a program written in a host language and extended by some new instructions like the %match construct. therefore, a program can be seen as a list of tom constructs interleaved with some sequences of characters. during the compilation process, all tom constructs are dissolved and replaced by instructions of the host-language, as it is usually done by a preprocessor. in order to understand the choices we have made when designing the pattern matching algorithm, it is important to consider tom as a generic and partial compiler (like a pre-processor) which does not have any information about the host-language. in [bkm06], tom programs are 1 http://tom.loria.fr 1 / 14 volume 3 (2006) mailto:emilie.balland@loria.fr mailto:pierre-etienne.moreau@loria.fr optimizing pattern matching compilation by program transformation definition of the data-structure public class peanoexample { ... term plus(term t1, term t2) { %match(t1, t2) { x,zero -> { return x; } x,suc(y) -> { return suc(plus(x,y)); } } } void run() { system.out.println("plus(1,2) = " + plus(suc(zero),suc(suc(zero)))); } } parser backend output program compiler optimizer tom compiler pil pil input program figure 1: general architecture of tom: the compiler generates an intermediate pil program which is optimized before being pretty-printed by the back-end into the host-language. described as islands anchored in host programs and the link between the two languages is formally defined in a generalized framework. in particular, the data-structure, against which the pattern matching is performed, is not fixed. in some sense, the data-structure is a parameter of the pattern matching, see [kmr05] for more details. in practice, this means that a description of the data-structure (a mapping) has to be given to explain tom how to access subterms for example. in this paper, we present how the introduced pattern matching construct is compiled, using a program transformation approach. there exists several methods [car84, aug85, grä91, fm01] to efficiently compile pattern matching. the simplest ones, called one-to-one, inspect and compile each pattern independently. a more efficient approach consists in considering the system globally and building a discrimination network. these methods are called many-to-one, and they usually consist of three phases: constructing an automaton, optimizing it, and finally generating the implementation code. there are two main approaches to construct a matching automaton: one based on decision trees [car84, grä91] and the other on backtracking automata [aug85]. these two approaches emphasize the unavoidable compromise between speed and memory space [srr95]. in our case, we cannot assume that a function symbol (i.e. a node of a tree) is represented by an integer, like it is commonly done in other implementations of pattern matching. therefore, the classical switch/case instruction can no longer be used to perform the discrimination. since tom supports several languages, it is also not possible to use an exception mechanism or a jump statement, like it can be done in ml compilers [jon87]. the approach chosen in tom is to keep the optimization phase separated from the one-to-one compilation phase. this allows us to design algorithms which are generic, simpler to implement, easier to extend and maintain, and that can be formally certified [kmr05]. in addition, this work allows to generate efficient implementations. in section 2, we present the compilation algorithm and its intermediate language pil. in section 3, we introduce a set of rules which describes the optimizer and a strategy to efficiently apply them. in section 4 we show that the optimizations are correct and improve the program in execution and size. finally, in section 5, some experimental results are given for several revealing examples. this paper assumes some proc. setra 2006 2 / 14 eceasst familiarity with term rewriting notations introduced in [bm05]. 2 compilation to be data-structure independent and support several host-languages, tom instructions, like %match, are compiled into an intermediate language code, called pil, before being translated into the selected host-language. to compile the %match construct, we consider each rule independently. contrary to many-to-one algorithms which construct decision trees or pattern automata, given a pattern, it is traversed top-down and left-to-right. nested if-then-else constructs are generated to ensure that constructors of the pattern effectively occur in the subject at a correct position. this technique is inefficient because, for a set of rules, identical tests may be repeatedly performed. the worst-case complexity is thus the product of the number of rules and the size of the subject. the nested if-then-else are expressed in an intermediate language called pil, whose syntax is given in figure 2. note that pil has both functional and imperative flavors: the assignment instruction let(variable,〈term〉,〈instr〉) defines a scoped unmodifiable variable, whereas the sequence instruction 〈instr〉 ; 〈instr〉 comes from imperative languages. a last particularity of pil comes from the hostcode(. . .) instruction which is used to abstract part of code written in the underlying host-language. this instruction is parameterized by a list of pil-variables which are used in this part of host-code. pil ::= 〈instr〉 symbol ::= f ∈ f variable ::= x ∈ x 〈term〉 ::= t ∈ t (f , x ) | subterm f (〈term〉, n) ( f ∈ f ∧ n ∈ n) 〈ex pr〉 ::= true | false | eq(〈term〉,〈term〉) | is fsym(〈term〉, symbol) 〈instr〉 ::= let(variable,〈term〉,〈instr〉) | if(〈ex pr〉,〈instr〉,〈instr〉) | 〈instr〉;〈instr〉 | hostcode(variable∗) | nop figure 2: pil syntax similarly to functional programming languages, given a signature f and a set of variables x , the considered pil language can directly handle terms, boolean values (true,false), and perform operations like checking that a given term t is rooted by a symbol f (is fsym(t, f )), accessing to the n-th child of a term t (subterm f (t, n)), or comparing two terms (eq(t1,t2)). the implementation of subterm f , eq and is fsym is given by the mapping which describes datastructures. to support the intuition, examples of tom and pil code are given in figure 3. we define pil semantics as in [kmr05] by a big-step semantics à la kahn. to represent a substitution, we model an environment by a stack of assignments of terms to variables. the set of environments is noted e nv. the reduction relation of the big-step semantics is expressed on tuples 〈ε, δ , i〉 where ε is an environment, δ is a list of pairs (environment, host-code), and i is an instruction. thanks to δ , we can keep track of the executed host-code blocks within their environment: the environment associated to each host-code construct gives the instances of all variables 3 / 14 volume 3 (2006) optimizing pattern matching compilation by program transformation tom code: . . . java code . . . . . . %match(term t) { f(a) ⇒ { print(. . . ); } g(x)⇒ { print(. . . x. . . ); } f(b) ⇒ { print(. . . ); } } . . . . . . java code . . . generated pil code: hostcode(. . .) ; if(is fsym (t,f),let(t1,subtermf(t,1), if(is fsym(t1,a),hostcode(),nop)), nop) ; if(is fsym (t,g),let(t1,subtermg(t,1), let(x,t1,hostcode(x))) nop) ; if(is fsym (t,f),let(t1,subtermf(t,1), if(is fsym(t1,b),hostcode(),nop)), nop) ; hostcode(. . .) ; figure 3: the left column shows a tom program which contains three patterns: f (a), g(x), and f (b), where x is a variable. as an example, when the second pattern matches t, this means that t is rooted by the symbol g, and the variable x is instantiated by its immediate subterm. the right column shows the corresponding pil code generated by tom. we can notice that this code is not optimal, but will hopefully be optimized by transformation rules afterwards. which appear in the block. a complete definition of the semantics can be found in [bm05]. 〈ε, δ , i〉 7→bs δ ′, with ε ∈ e nv, δ , δ ′ ∈ [e nv,〈instr〉]∗, and i ∈ 〈instr〉 as pil programs are predominantly constituted of if-then-else statements, the optimization rules will depend of the evaluation of expressions e ∈ 〈ex pr〉. in the following we introduce the notions of equivalence and incompatibility for expressions, and we consider two functions eval and φ. eval is a function which given an environment ε and an expression e evaluates e in ε to obtain a value (i.e true for true or false for false). given an environment ε and a host-code list δ , the evaluation of a program π ∈ pil results in a host-code list: 〈ε, δ , π〉 7→bs δ ′. during this evaluation, expressions e, subterm of π , are evaluated in environments ε′. we call φ the function that associates such an environment ε′ to a sub-expression e of π : ε′ = φ(π, e, ε, δ ). more formal definitions can be found in [bm05]. definition 1 given a program π , two expressions e1 and e2 are said π -equivalent, and noted e1 ∼π e2, if for all starting environment ε , δ , eval(ε1, e1) = eval(ε2, e2) where ε1 = φ(π, e1, ε, δ ) and ε2 = φ(π, e2, ε, δ ). definition 2 given a program π , two expressions e1 and e2 are said π -incompatible, and noted e1 ⊥π e2, if for all starting environment ε , δ , eval(ε1, e1) 6= eval(ε4, e2) where ε1 = φ(π, e1, ε, δ ) and ε2 = φ(π, e2, ε, δ ). we can now define two conditions which are sufficient to determine whether two expressions are π -equivalent or π -incompatible. propositions 1 and 2 are interesting because the problem is generally undecidable [rks99], but here, conditions can be easily used in practice. indeed cond1 which ensures that the two expressions are evaluated in the same environment is proc. setra 2006 4 / 14 eceasst easy to be checked because of pil language restrictions and cond2 is a purely syntactic condition. proofs of these propositions are in [bm05]. proposition 1 given a program π and two expressions e1, e2 ∈ 〈ex pr〉 at different positions in, we have e1 ∼π e2 if: ∀ε, δ , φ(π, e1, ε, δ ) = φ(π, e2, ε, δ ) (cond1) and e1 = e2 (cond2). the equality = correspond to syntactic equality and the two considered expressions are in a different position in the program so the two environments of evaluation are not trivially equal. proposition 2 given a program π and two expressions e1, e2 ∈ 〈ex pr〉, we have e1 ⊥π e2 if: ∀ε, δ , φ(π, e1, ε, δ ) = φ(π, e2, ε, δ ) (cond1) and incompatible(e1, e2) (cond2), where incompatible is defined as follows: incompatible(e1, e2) = match e1, e2 with | false,true → > | true,false → > | is fsym(t, f1),is fsym(t, f2) → > if f1 6= f2 | , → ⊥ 3 optimization an optimization is a transformation which reduces the size of code (space optimization) or the execution time (time optimization). in the case of pil, the presented optimizations reduce the number of assignments (let) and tests (if) that are executed at run time. when manipulating abstract syntax trees, an optimization can easily be described by a rewriting system. its application consists in rewriting an instruction into an equivalent one, using a conditional rewrite rule of the form i1 → i2 if c. definition 3 an optimization rule i1 → i2 if c rewrites a program π into a program π′ if there exists a position ω and a substitution σ such that σ (i1) = π|ω , π ′ = π[σ (i2)]ω and σ (c) is verified. if c = e1 ∼ e2 (resp. c = e1 ⊥ e2), we say that σ (c) is verified when σ (e1) ∼π|ω σ (e2) (resp. σ (e1) ⊥π|ω σ (e2)). 3.1 reducing the number of assignments this kind of optimization is standard, but useful to eliminate useless assignments. in the context of pattern matching, this improves the construction of substitutions, when a variable from the left-hand side is not used in the right-hand side for example. 3.1.1 constant propagation. this first optimization removes the assignment of a variable defined as a constant. since no sideeffect can occur in a pil program, it is possible to replace all occurrences of the variable by the constant (written i[v/t]). constprop: let(v,t, i) → i[v/t] if t ∈ t (f ) 5 / 14 volume 3 (2006) optimizing pattern matching compilation by program transformation 3.1.2 dead variable elimination and inlining. using a simple static analysis, these optimizations eliminate useless assignments: deadvarelim: let(v,t, i) → i if use(v, i) = 0 inlining: let(v,t, i) → i[v/t] if use(v, i) = 1 where use(v, i) is a function that computes an upper bound on the number of occurences of a variable v in an instruction i. 3.1.3 fusion. the following rule merges two successive let which assign the same value to two different variables. this kind of optimization rarely applies on human written code, but in the context of pattern matching compilation (see figure 3), this case often occurs. by merging the bodies, this allows to recursively perform some optimizations on subterms. letfusion: let(v1,t1, i1);let(v2,t2, i2) → let(v1,t2, i1; i2[v2/v1]) if t1 ∼ t2 note that the terms t1 and t2 must be compatible to ensure that values of v1 and v2 are the same at run time. we also suppose that use(v1, i2) = 0. otherwise, it would require to replace v1 by a fresh variable in i2. 3.2 reducing the number of tests the key technique to optimize pattern matching consists in merging branches, and thus tests that correspond to patterns with identical prefix. usually, the discrimination between branches is performed by a switch/case instruction. in tom, since the data-structure is not fixed, we cannot assume that a symbol is represented by an integer, and thus, contrary to standard approaches, we have to use an if statement instead. this restriction prevents us from selecting a branch in constant time. the two following rules define the fusion and the interleaving of conditional blocks. 3.2.1 fusion. the fusion of two conditional adjacent blocks reduces the number of tests. this fusion is possible only when the two conditions are π -equivalent. remind that the notion of π -equivalence means that the evaluation of the two conditions in a given program are the same (see definition 1): iffusion: if(c1, i1, i′1);if(c2, i2, i ′ 2) → if(c1, i1; i2, i ′ 1; i ′ 2) if c1 ∼ c2 to evaluate c1 ∼ c2 (i.e. c1 ∼π c2 with π the redex of the rule), we use proposition 1. the condition φ(π, ε, δ , e1) = φ(π, ε, δ , e2) (cond1) is trivially verified because the semantics of the sequence instruction preserves the environment (∀δ , ε, φ(π, ε, δ , i1; i2) = φ(π, ε, δ , i1) = φ(π, ε, δ , i2)) and then ∀δ , ε, φ(π, ε, δ , σ (c1)) = φ(π, ε, δ , σ (c2)). we just have to verify that e1 = e2 (cond2), which is easy. proc. setra 2006 6 / 14 eceasst 3.2.2 interleaving. as matching code consists of a sequence of conditional blocks, we would like to optimize blocks with π -incompatible conditions (see definition 2). some parts of the code cannot be both executed in a given environment, so swapping statically their order does not change the program behavior. as we want to keep only one of the conditional block, we determine what instructions must be executed in case of success or failure of the condition and we obtain the two following transformation rules: if(c1, i1, i′1);if(c2, i2, i ′ 2) → if(c1, i1; i ′ 2, i ′ 1;if(c2, i2, i ′ 2)) if c1 ⊥ c2 if(c1, i1, i′1);if(c2, i2, i ′ 2) → if(c2, i ′ 1; i2,if(c1, i1, i ′ 1); i ′ 2) if c1 ⊥ c2 as for the equivalence in the iffusion rule, to evaluate c1 ⊥ c2, we just have to verify that e1 and e2 are incompatible (cond2). note that the two presented rules are not right-linear, therefore some code is duplicated (i′2 in the first rule, and i ′ 1 in the second one). as we want to maintain linear the size of the code, we consider specialized instances of these rules with respectively i′2 and i′1 equal to nop. ifinterleaving: if(c1, i1, i′1);if(c2, i2,nop) → if(c1, i1, i ′ 1;if(c2, i2,nop)) if c1 ⊥ c2 if(c1, i1,nop);if(c2, i2, i′2) → if(c2, i2,if(c1, i1,nop); i ′ 2) if c1 ⊥ c2 these two rules reduce the number of tests at run time because one of the tests is moved into the “else” branch of the other. in practice, we only use the first one labelled by ifinterleaving. the second rule can be instantiated and used to swap blocks. when i′1 and i ′ 2 are reduced to the instruction nop, the second rule can be simplified into: if(c1, i1,nop);if(c2, i2,nop) → if(c2, i2,if(c1, i1,nop)) if c1 ⊥ c2 as c1 and c2 are π -incompatible, we have the following equivalence: if(c2, i2,if(c1, i1,nop)) ≡ if(c2, i2,nop);if(c1, i1,nop) after all, we obtain the following rule corresponding to the swapping of two conditional adjacent blocks. this rule does not optimize the number of tests but is useful to bring closer blocks subject to be merged thanks to the strategy presented in the next section. ifswapping: if(c1, i1,nop);if(c2, i2,nop) → if(c2, i2,nop);if(c1, i1,nop) if c1 ⊥ c2 3.3 application strategy from the rules presented in section 3.1 and 3.2, we define a rewrite system. without strategy, this system is clearly not confluent and not terminating. for example, the ifswapping rule can be applied indefinitely because of the symmetry of incompatibility. the confluence of the system is not necessary as long as the programs obtained are semantically equivalent to the 7 / 14 volume 3 (2006) optimizing pattern matching compilation by program transformation source program but the termination is an essential criterion. moreover, the strategy should apply the rules to obtain a program as efficient as possible. let us consider again the program given in figure 3, and let us suppose that we interleave the last two patterns. this would result in the following sub-optimal program: if(is fsym(t, f ), let(t1,subtermf(t,1),if(is fsym(t1,a),hostcode(),nop)),nop) ; if(is fsym(t, g), let(t1,subtermg(t,1),let(x,t1,hostcode(x))) if(is fsym(t, f ),let(t1,subtermf(t,1),if(is fsym(t1,b),hostcode(),nop)),nop) the ifswapping and iffusion rules can no longer be applied to share the is fsym(t, f ) tests. this order of application is not optimal. as we want to grant iffusion, the interleaving rule must be applied afterward, when no more optimization is possible. the second matter is to ensure termination. the ifswapping rule is the only rule that does not decrease the size or the number of assignments of a program. to limit its application to interesting cases, we define a condition which ensures that a swapping is performed only if it enables a fusion. this condition can be implemented in two ways, either in using a context, or in defining a total order on conditions noted < (a lexicographic order for example). the second approach is more efficient: similarly to a swap-sort algorithm it ensures the termination of the algorithm. in this way, we obtain a new ifswapping rule: if(c1, i1,nop);if(c2, i2,nop) → if(c2, i2,nop);if(c1, i1,nop) if c1 ⊥ c2 ∧ c1 < c2 using basic strategy operators such as innermost(s) (which applies s as many times as possible, starting from the leaves), s1 | s2 (which applies s1 or s2 indifferently), repeat(s) (which applies s as many times as possible, returning the last unfailing result), and s1 ; s2 (which applies s1, and then s2 if s1 did not fail), we can define a strategy which describes how the considered rewrite system should be applied to normalize a pil program: innermost( repeat(constprop | deadvarelim | inlining | letfusion | iffusion | ifswapping) ; repeat(ifinterleaving) ) starting from the program given in figure 3, we can apply the rule ifswapping, followed by a step of iffusion, and we obtain: if(is fsym(t, f ), let(t1,subtermf(t,1),if(is fsym(t1,a),hostcode(),nop)) ; let(t1,subtermf(t,1),if(is fsym(t1,b),hostcode(),nop)),nop) ; if(is fsym(t, g), let(t1,subtermg(t,1),let(x,t1,hostcode(x))),nop) then, we can apply a step of inlining to remove the second instance of t1, a step of letfusion, and a step of interleaving (is fsym(t1, a) and is fsym(t1, b) are π -incompatible). this results in the following program: if(is fsym(t, f ), let(t1,subtermf(t,1), if(is fsym(t1,a),hostcode(),if(is fsym(t1,b),hostcode(),nop))),nop) ; if(is fsym(t, g), let(x,subtermg(t,1),hostcode(x)),nop) proc. setra 2006 8 / 14 eceasst since is fsym(t, f ) and is fsym(t, g) are π -incompatible, we can apply a step of ifinterleaving, and get the irreducible following program: if(is fsym(t, f ), let(t1,subtermf(t,1),if(is fsym(t1,a),hostcode(),if(is fsym(t1,b),hostcode(),nop))), if(is fsym(t, g),let(x,subtermg(t,1),hostcode(x)),nop) 4 properties when performing optimization by program transformation, it is important to ensure that the generated code has some expected properties. the use of formal methods to describe our optimization algorithm allows us to give proofs. in this section we show that each transformation rule is correct, in the sense that the the optimized program has the same observational behavior as the original. we also show that the optimized code is both more efficient, and smaller than the initial program. 4.1 correction definition 4 given π1 and π2 two well-formed pil programs, they are semantically equivalent, noted π1 ∼ π2, when: ∀ε, δ ,∃δ ′ s.t. 〈ε, δ , π1〉 7→bs δ ′ and 〈ε, δ , π2〉 7→bs δ ′ definition 5 a transformation rule r is correct if for all well-formed program π , r rewrites π in π′ (definition 3) implies that π ∼ π′ (definition 4). from this definition, we prove that every rule given in section 3 is correct. for that, two conditions have to be verified: 1. π′ is well-formed, 2. ∀ε, δ , the derivations of π and π′ lead to the same result δ ′. the first condition is quite easy to verify. the second one is more interesting: we consider a program π , a rule l → r if c, a position ω , and a substitution σ such that σ (l) = π|ω . we have π ′ = π[σ (r)]ω . we have to compare the derivations of π and π′ in the context ε, δ . • when ω is the empty position (which corresponds to the root), we have to compare the derivation tree of π = σ (l) and π′ = σ (r), • otherwise, we consider the derivation of π (resp. π′): there is a step which needs in premise the derivation of π|ω (resp. π[σ (r)]ω ). this is the only difference between the two trees. in both cases, we have to verify that π|ω = σ (l) and σ (r) have the same derivation in a given context: 9 / 14 volume 3 (2006) optimizing pattern matching compilation by program transformation • equal to ε, δ when ω is the empty position, • otherwise, we have to consider the instruction i which immediately contains σ (l) (resp. σ (r)). the context is defined by the context in which i is evaluated in the derivation tree of π (resp. π′). in the following, we give one representative proof of correction: ifswapping2. to simplify the proof we consider l, r and c instead of σ (l), σ (r) and σ (c). in this rule, l = if(c1, i1,nop);if(c2, i2,nop) and r = if(c2, i2,nop);if(c1, i1,nop). to prove that π ∼ π′, we have to verify that for a given ε, δ , l and r have the same derivation. since c1 and c2 are π -incompatible, three cases have to be studied: case 1: eval(ε, c1) = true and eval(ε, c2) = false 〈ε, δ , i1〉 7→bs δ ′ eval(ε, c1) = true 〈ε, δ ,if(c1, i1,nop)〉 7→bs δ ′ 〈ε, δ ′,nop〉 7→bs δ ′ eval(ε, c2) = false 〈ε, δ ′,if(c2, i2,nop)〉 7→bs δ ′ 〈ε, δ ,if(c1, i1,nop);if(c2, i2,nop)〉 7→bs δ ′ we now consider the program if(c2, i2,nop);if(c1, i1,nop). starting from the same environment ε and δ , we show that the derivation leads to the same state δ ′, and thus prove that if(c1, i1,nop);if(c2, i2,nop) and if(c2, s2,nop);if(c1, s1,nop) are equivalent: 〈ε, δ ,nop〉 7→bs δ eval(ε, c2) = false 〈ε, δ ,if(c2, i2,nop)〉 7→bs δ 〈ε, δ , i1〉 7→bs δ ′ eval(ε, c1) = true 〈ε, δ ,if(c1, i1,nop)〉 7→bs δ ′ 〈ε, δ ,if(c2, i2,nop);if(c1, i1,nop)〉 7→bs δ ′ since π and π′ are well-formed, their derivation in a given context are unique (see [bm05]). 〈ε, δ , i1〉 7→bs δ ′ is part of these derivation trees, so it is unique, and δ ′ is identical in both derivations. case 2: eval(ε, c1) = false and eval(ε, c2) = true, the proof is similar. case 3: eval(ε, c1) = false and eval(ε, c2)false, the proof is similar. 4.2 time and space reduction to show that the optimized code is both more efficient, and smaller than the initial program, we consider two measures: • the size of a program π is the number of instructions which constitute the program, 2 the other proofs can be found in [bm05] proc. setra 2006 10 / 14 eceasst • the efficiency of a program π is determined by the number of tests and assignments which are performed at run time. it is quite easy to verify that each transformation rule does not increase the size of the program: deadvarelim, constprop, inlining, and letfusion decrease the size of a program, whereas iffusion, ifinterleaving and ifswapping maintain the size of the transformed program. it is also clear that no transformation can reduce the efficiency of a given program: • each application of deadvarelim, constprop, and inlining reduces by one the number of assignment that can be performed at run time, • iffusion reduces by one the number of tests, • ifinterleaving also decreases the number of tests when the first alternative is chosen. otherwise, there is no optimization, • ifswapping does not modify the efficiency of a program. the program transformation presented in section 3 is an optimization which improves the efficiency of a given program, without increasing its size. similarly to [fm01], this result is interesting since it allows to generate efficient pattern matching implementations whose size is linear in the number and size of patterns. 5 experimental results the tom compiler is written in tom and java. therefore, the presented algorithm described using rules and strategies, has been implemented in tom. as illustrated figure 1, the optimizer is just an extra phase of the compiler, which is now integrated into the main distribution using the strategy given in section 3.3. in order to illustrate the efficiency of the compiler we have selected several representative programs and measured the effect of optimization in practice: fibonnacci eratosthene langton gomoku nspk structure tom java 21.3 s 174.0 s 15.7 s 70.0 s 1.7 s 12.3 s tom java optimized 20.0 s 2.8 s 1.4 s 30.4 s 1.2 s 11.3 s fibonacci computes 500 times the 18th fibonacci number, using a peano representation. on this example, the optimizer has a small impact because the time spent in matching is smaller than the time spent in allocating successors and managing the memory. eratosthene computes prime numbers up to 1000, using associative list matching. the improvement comes from the inlining rules which avoids computing a substitution unless the rule applies (i.e. the conditions are verified). langton is a program which computes the 1000th iteration of a cellular automaton, using pattern matching to implement the transition function. this example is interesting because it contains more than 100 (ground) patterns. starting from a simple one-to-one pattern matching 11 / 14 volume 3 (2006) optimizing pattern matching compilation by program transformation algorithm, the optimizer performs program transformations such that a pair (position,symbol) is never tested more than once. this interesting property, which characterizes deterministic automata based approaches, can unfortunately not be generalized to any program. gomoku looks for five pawn on a go board, using list matching. this example contains more than 40 patterns and illustrates the interest of test-sharing. nspk implements the verification of the needham-schroeder public-key protocol. structure is a prover for the calculus of structures where the inference is performed by pattern matching and rewriting. the following table gives some comparisons with other well known implementations. fibonnacci eratosthene langton tom java optimized 20.0 s 2.8 s 1.4 s tom c optimized 0.95 s 0.36 s 0.84 s ocaml 0.44 s 0.7 s 1.36 s elan 0.77 s 0.8 s 1.26 s all these examples are available on the tom web page. the measures have been done on a powermac 2 ghz, using java 1.4.2, gcc 4.0, and ocaml 3.09. they show that the proposed approach is effective in practice and allows tom to become competitive with state of the art implementations such as ocaml. we should remind that tom is not dedicated to a unique language. in particular, the fact that data-structure can be user-defined contrary to functional languages prevents us from using exception, goto, and switch constructs and thus optimizations like those presented in [fm01]. 6 conclusion in this paper, we have presented a new approach to compile pattern matching. this method is based on well-attested program optimization methods. separating compilation and optimization in order to keep modularity, and to facilitate extensions is long-established in the compiler construction community. using a program transformation and a formal method approach is an elegant way to describe, implement, and certify the proposed optimizations. this work is closed to sestoft approach [ses96] which compiles naively ml-style pattern matches and by partial evaluation removes redundant cases instead of constructing directly the decision tree. moreover, this two-stage pattern compilation is directly implemented in tom and shows how tom language is well-adapted for program analysis-transformation. we have only be interested in optimizing syntactic matching and thus considered a subset of pil language. as tom already manages associativity, a future work will consist in developing new transformation rules adapted to this theory, without having to change the rules relative to syntactic one. however, note that the presented rules remain correct when considering an extension of pil. this paper shows that using program transformation rules to optimize pattern matching is an efficient solution, with respect to algorithms based on automata. the implementation of this proc. setra 2006 12 / 14 eceasst work combined with the formal validation of pattern matching [kmr05] is another step towards the construction of certified/certifying optimizing compilers. bibliography [aug85] l. augustsson. compiling pattern matching. in proceedings of the conference on functional programming languages and computer architecture. pp. 368–381. springer-verlag, 1985. [bkm06] e. balland, c. kirchner, p.-e. moreau. formal islands. in johnson and vene (eds.), proceedings of the 11th international conference on algebraic methodology and software technology. lncs 4019, pp. 51–65. springer-verlag, 2006. [bm05] e. balland, p.-e. moreau. optimizing pattern matching by program transformation. technical report, inria-loria, 2005. http://hal.inria.fr/inria-00000763. [car84] l. cardelli. compiling a functional language. in proceedings of the acm symposium on lisp and functional programming. pp. 208–217. 1984. [fm01] f. l. fessant, l. maranget. optimizing pattern matching. in proceedings of the sixth international conference on functional programming. pp. 26–37. acm press, 2001. doi:http://doi.acm.org/10.1145/507635.507641 [grä91] a. gräf. left-to-right tree pattern matching. in proceedings of the 4th international conference on rewriting techniques and applications. lncs 488, pp. 323– 334. springer-verlag, 1991. [jon87] s. l. p. jones. the implementation of functional programming languages (prenticehall international series in computer science). prentice-hall, inc., upper saddle river, nj, usa, 1987. [kmr05] c. kirchner, p.-e. moreau, a. reilles. formal validation of pattern matching code. in barahone and felty (eds.), proceedings of the 7th international conference on principles and practice of declarative programming. pp. 187–197. acm, july 2005. [leu96] a. leung. c++-based pattern matching language. 1996. citeseer.ist.psu.edu/leung96cbased.html [mrv03] p.-e. moreau, c. ringeissen, m. vittek. a pattern matching compiler for multiple target languages. in hedin (ed.), 12th conference on compiler construction. lncs 2622, pp. 61–76. springer-verlag, may 2003. [ow97] m. odersky, p. wadler. pizza into java: translating theory into practice. in proceedings of the 24th acm symposium on principles of programming languages. pp. 146–159. acm press, usa, 1997. 13 / 14 volume 3 (2006) http://hal.inria.fr/inria-00000763 http://dx.doi.org/http://doi.acm.org/10.1145/507635.507641 citeseer.ist.psu.edu/leung96cbased.html optimizing pattern matching compilation by program transformation [rks99] o. rüthing, j. knoop, b. steffen. detecting equalities of variables: combining efficiency with precision. in cortesi and filé (eds.), sas. lncs 1694, pp. 232–247. springer-verlag, 1999. [ses96] p. sestoft. ml pattern match compilation and partial evaluation. in danvy et al. (eds.), dagstuhl seminar on partial evaluation. lncs 1110, pp. 446–464. springerverlag, 1996. [srr95] r. c. sekar, r. ramesh, i. v. ramakrishnan. adaptive pattern matching. siam journal on computing 24(6):1207–1234, 1995. proc. setra 2006 14 / 14 introduction to tom compilation optimization reducing the number of assignments constant propagation. dead variable elimination and inlining. fusion. reducing the number of tests fusion. interleaving. application strategy properties correction time and space reduction experimental results conclusion electronic communications of the easst volume 27 (2010) guest editors: klaus david, michael zapf managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 workshop über selbstorganisierende, adaptive, kontextsensitive verteilte systeme (saks 2010) nutzerintegration in die anforderungserhebung für ubiquitous computing systeme axel hoffmann, holger hoffmann und jan marco leimeister 9 pages eceasst 2 / 9 volume 27 (2010) nutzerintegration in die anforderungserhebung für ubiquitous computing systeme axel hoffmann, holger hoffmann und jan marco leimeister fachgebiet wirtschaftsinformatik, fachbereich wirtschaftswissenschaften, universität kassel abstract: der nutzer wird als die wichtigste quelle für anforderungen an technische systeme gesehen. die technikgetriebene entwicklung ubiquitärer systeme nimmt darauf zurzeit jedoch wenig rücksicht. wir beschreiben, wie der nutzer nach bekannten requirements engineering ansätzen besser in die anforderungserhebung einbezogen werden kann und welche probleme dabei auftreten. dabei stehen die besonderen eigenschaften ubiquitärerer systeme – wie die tatsache, dass der nutzer das system nicht mehr aktiv bedient, sondern durch verwendung von smart devices steuert – im vordergrund. ein weiterer fokus bei der von uns beschriebenen nutzerintegration liegt zudem auf der tatsache, dass die nutzer durch die neuartigkeit ubiquitärer systeme kaum eine vorstellung von den sich bietenden möglichkeiten für ubiquitäre anwendungen haben und entsprechend anfänglich keine spezifischen anforderungen nennen können. keywords: anforderungserhebung, requirements engineering, ubiquitous computing, nutzergetriebene entwicklung, user-centered design 1 einleitung ubiquitous computing schafft in der vision von weiser dem nutzer ungeahnte möglichkeiten [1]. it-unterstützung im alltagsleben ohne die fokussierung auf einen computer bringt bei der entwicklung neue freiheitsgerade mit sich, die durch immer neue entwicklungen im hardwarebereich auch realisierbar werden. die entwicklung von ubiquitous computing systemen findet jedoch weitestgehend unter ausschluss späterer nutzer statt, deren anforderungen somit auch keine beachtung finden. erfolgreiche uc anwendungen müssen aber nicht nur technische aspekte korrekt abbilden, sondern vor allem die bedürfnisse der nutzer erfüllen [2]. daher ist es unerlässlich, die nutzerbeteiligung an der entwicklung zu erhöhen. die neuartigkeit ubiquitärer systeme und die damit verbundene fehlende vorstellungskraft der nutzer, welche möglichkeiten derartige systeme haben, schränken den nutzereinsatz im klassischen requirements engineering aber ein. daher stellen wir im folgenden beitrag eine systematische lösung vor, welche die innovationskraft größerer gruppen, die neuartigkeit der technik und die anforderungen der späteren nutzer zu einem integrativen ansatz für das requirements engineering für ubiquitäre systeme verbindet. nutzerintegration in die anforderungserhebung für uc-systeme saks 2010 3 / 9 2 technikgetriebene entwicklung die vision des ubiquitous computing hat in der vergangenheit die erwartungen von hard und softwareherstellern, dienstleistern und endkunden geschürt, in naher zukunft bereits „intelligente“ haushaltsgegenstände zu verkaufen und darauf basierende services anbieten und nutzen zu können. mit dem vernetzen der alltagswelt und den darin befindlichen gegenständen lassen sich möglichkeiten realisieren, die vorher undenkbar waren [3]. immer neue technische entwicklungen steigern die leistung von eingebetteten prozessoren, erhöhen die bandbreite drahtloser übertragungstechniken und verbessern die genauigkeit von nutzbaren sensoren. diese entwicklungen im hardwarebereich werden von systemdesignern aufgegriffen und zu lösungen kombiniert, welche die fähigkeiten der hardware ausloten und die entwicklung weiter voran treiben. dabei entstehen ubiquitäre systeme, die in übereinstimmung mit der vision des ubiquitous computing das potenzial haben, die welt der it zu revolutionieren [4]. jedoch ist die entwicklung dieser systeme bisher rein technikzentriert. sie demonstrieren die schöne neue welt, zeigen möglichkeiten der technik und versetzen die betrachter in staunen. die bedarfe der endkunden finden dabei in den vorgestellten szenarien wenig beachtung [5]. entsprechend ist fraglich, ob es einen markt für die neue technik geben wird oder die entwickler weiter wie bisher, also an den anforderungen der nutzer vorbei, entwickeln? 3 nutzergetriebene entwicklung die entwicklung von technischen systemen ist in der regel kein selbstzweck. so sollten auch die systeme des ubiquitous computing dafür ausgelegt sein, die anforderungen der nutzer zu erfüllen und ihnen eine bestmögliche unterstützung innerhalb des funktionsumfangs zu bieten. viele ansätze der produktentwicklung stellen deshalb den anwender in den mittelpunkt der anforderungserhebung (user-centered design [6]) oder erklären ihn zum designer (open design [7]) und binden ihn so aktiv in die entwicklung mit ein [8, 9]. die idee, den anwender als designer für das system einzusetzen, welches er später nutzen möchte, basiert dabei auf einem einfachen gedanken: wer könnte besser beurteilen, was der nutzer braucht, als der nutzer selbst. bei einem derartiges vorgehen müssen jedoch probleme berücksichtigt werden [10]: • es gibt nicht den einen benutzer. ein kommerzielles system zielt in der regel auf mehrere spätere benutzergruppen ab [11] und es ist nicht möglich, jeden potenziellen nutzer das system bewerten zu lassen. • wie werden möglichst repräsentative nutzer für die anforderungserhebung ermittelt? in der von der wirtschaftsinformatik geprägten forschung findet sich hierzu der ansatz, fokusgruppen [12] zu nutzen und lead user zu befragen. • es können nie die anforderungen aller benutzer berücksichtigt und vor allem umgesetzt werden, da verschiedene nutzer komplementäre oder konfliktäre anforderungen an ein system stellen werden. • auch bei anforderungen, die grundsätzlich miteinander vereinbar sind, bleibt die frage, wie diese möglichst stringent in einem system vereinigt werden können. eceasst 4 / 9 volume 27 (2010) • ebenso muss geklärt werden, wie lösungsinformationen, also ansätze, wie der benutzer eine anforderung umsetzen würde, mit in den erstellungsprozess integriert werden können. ein problem im zusammenhang mit ubiquitous computing ist gerade die neuartigkeit der systeme. die vision von weiser ist sehr abstrakt [1]. konkrete beispiele beschränken sich auf umsetzung in forschungseinrichtungen. der breiten öffentlichkeit sind der begriff und das dahinterliegende paradigma kaum bekannt. wird der nutzer an der entwicklung beteiligt oder in die mitte der anforderungserhebung gestellt, steht er vor der herausforderung, gleichzeitig die systeme zu begreifen, ihre regeln zu verstehen und innerhalb dieser regeln anforderungen für ein neues system zu sammeln. er ist also durch die neuartigkeit überfordert [11]. abbildung 1: personal computing – mobile computing – ubiquitous computing den meisten nutzern ist dieser spagat möglich, solange sie mit der art des systems vertraut sind und sich die interaktion mit dem system vorstellen können. als beispiel ist es relativ einfach zu erfassen, welche anforderungen sie an eine textverarbeitung haben, weil sie bereits mit der art des systems vertraut sind. sie kennen die regeln der interaktion, sind gewohnt, dass sie informationen über tastatur und maus (in seltenen fällen per mikrofon) eingeben und ihnen das ergebnis auf einem bildschirm präsentiert wird. das design eines ubiquitous computing systems unterscheidet sich jedoch völlig von den bisherigen interaktionskonzepten (abbildung 1). der anwender soll anforderungen an ein system verbalisieren, dessen nutzung für ihn völlig implizit sein soll, also von ihm keine aufmerksamkeit fordert [13]. dieser abstraktionsgrad wird die meisten anwender überfordern. 4 partizipative entwicklung & prototyping ein umfassendes verständnis der anforderungen von benutzern eines umzusetzenden systems ist für dessen erfolgreiche einführung unerlässlich. um ein solches verständnis aufzubauen, ist es besonders bei anwendernahen systemen wichtig, die anforderungen direkt im späteren nutzungskontext zu erfassen [14, 15, 16, 17, 18]. die forschungsbereiche der partizipativen gestaltung und der mensch-maschine interaktion haben ansätze entwickelt, die es ermöglichen, gemeinsam mit verschiedenen beteiligten an der erstellung von lösungen zu arbeiten [19]. durch die einbeziehung von endkunden in den entwicklungsprozess ergeben sich dabei zahlreiche vorteile. nutzerintegration in die anforderungserhebung für uc-systeme saks 2010 5 / 9 nutzer kennen oft die möglichkeiten verfügbarer technologie nicht, vor allem, wenn diese, wie das ubiquitous computing, ein neues paradigma verfolgt. entwicklern ist dagegen der kontext für die spätere nutzung nicht bekannt. mit der partizipativen entwicklung wird die bestehende wissenslücke zwischen nutzer und entwickler kleiner [20]. gleichzeitig verschmilzt die beteiligung von nutzer und entwickler im gesamten produktlebenszyklus. der nutzer erhält das produkt nicht erst, wenn die entwicklung abgeschlossen ist [21]. endanwender und entwickler können so gemeinsam bereits früh im entwicklungsprozess, und oftmals über mehrere iterationen, anforderungen an das zu erstellende system erheben und analysieren [15]. das prototyping von anwendungen – also die teilweise umsetzung von elementen der anwendung, die nutzbar und damit auch evaluierbar ist – stellt einen möglichen partizipativen ansatz zur anforderungserhebung dar [15, 16]. dabei wird das finale system iterativ anhand zahlreicher prototypen, die zwischenschritte auf dem weg zum gewünschten endergebnis darstellen, aufgebaut. so werden wenige, initial erhobene oder aus festgelegten rahmenbedingungen abgeleitete anforderungen (bzw. deren umsetzung) in jeder iterationsstufe evaluiert, verfeinert und um weitere anforderungen ergänzt. auf diese weise entsteht systematisch eine vorstellung vom system bei den beteiligten anwendern, mit deren hilfe sie neune anforderungen an das system erschließen können. diese art der gemeinsamen arbeit wird von [15] im „framework der kooperativen zusammenarbeit“(abbildung 1) theoretisch beschrieben. abbildung 2: framework der kooperativen zusammenarbeit nach [15] kernaussage dieser theorie ist, dass „artefakte“ – also vom menschen geschaffene objekte wie z.b. prototypen von ubiquitous computing anwendungen – unterschiedlichen prozessbeteiligten neben der direkten kommunikation eine weitere möglichkeit bieten, ein gemeinsames verständnis über einen sachverhalt aufzubauen. auf diese weise ist es demnach möglich, dass die entwickler ubiquitärer systeme durch nutzung von (realitätsnahen) prototypen die anforderungen der kunden als primäre anspruchsgruppe besser verstehen und kunden ihre anforderungen leichter kommunizieren können. zudem lassen sich durch die beobachtung der nutzung der prototypen im rahmen von pilotprojekten und feldexperimenten in der späteren zielumgebung durch kundengruppen auch solche eceasst 6 / 9 volume 27 (2010) anforderungen erfassen, die von kunden nicht direkt kommuniziert werden (konnten) [22, 23, 24]. 5 vorgelagerte vision als erster schritt des requirements engineering das prototyping zu nutzen, um den späteren nutzern eine vorstellung des zu entwickelnden system zu schaffen und dadurch konkretere anforderungen zu bekommen, wurde für das ubiquitous computing schon mehrfach erkannt [5, 25]. der vorgestellte iterative ansatz des prototyping unterstützt hierbei die entwickler und benutzer ein gemeinsames verständnis der anwendung, und damit der anforderungen an die anwendung zu entwickeln. jedoch müssen auch hier initial anforderungen an den ersten prototypen des entwicklungsprozesses erfasst werden, der dann anschließend zur sinnvollen integration der nutzer eingesetzt werden kann. der klassische prozess des requirements engineering der softwareentwicklung beginnt mit der anforderungsgewinnung [26]. in dieser phase sollen bereits die (endgültigen) anforderungen von nutzern und anderen stakeholdern gesammelt werden. wie beschrieben ist aber eine anforderungserhebung für ubiquitous computing systeme nur sinnvoll, wenn es gelingt, dem nutzer die neuen möglichkeiten deutlich und nachvollziehbar zu machen. für eine erste vorstellung des umzusetzenden ubiquitous computing systems benötigt die anforderungserhebung dementsprechend eine phase, die im vergleich zum klassischen requirements engineering dem prozess vorgelagert ist. in dieser phase müssen die bedürfnisse des benutzers erfasst und darauf basierend ideen und nicht-technische anforderungen an das system gesammelt werden[27]. diese dienen dann als grundlage, an der sich eine erste umsetzung orientieren kann. für diese szenarien ist darauf zu achten, dass die entwicklung sich nicht nur an technischen gegebenheiten orientiert und somit die technikgetriebene entwicklung alle anderen sichtweisen in den hintergrund drängt. vielmehr ist darauf zu achten, dass, auch ohne die konkrete einbeziehung der parteien, relevante interessen von stakeholdern gewahrt werden [28]. für die frühe gestaltung des systems bieten sich methoden aus dem bereich ideation [29] oder collaboration engineering [30] an. mit deren hilfe können ideen produziert, erweitert und ausgestaltet werden. dabei liegen die stärken der einbeziehung von gruppentechniken vor allem auch in einem heterogenen teilnehmerfeld, wobei die beteiligung potenzieller nutzer auf keinen fall ausgeschlossen werden soll. der fokus liegt hier aber nicht darauf, das system später an die anforderungen der nutzer zu optimieren, sondern erst einmal einen lösungsraum für das umzusetzende system zu erstellen. dafür ist vor allem beim ubiquitous computing die verinnerlichung der vision durch die teilnehmer entscheidend. die eigentliche partizipation der nutzer beginnt dann in den späteren phasen, wenn es gelingt, diesen, zum beispiel durch prototypen, eine vorstellung vom system zu vermitteln. nutzerintegration in die anforderungserhebung für uc-systeme saks 2010 7 / 9 6 fazit und ausblick die anforderungserhebung an ubiquitäre systeme weißt zahlreiche herausforderungen auf, die mit dem klassischen requirements engineering nicht abgedeckt werden können. gerade durch die neuartigkeit des paradigmas sind die initiale anforderungserhebung und die einbeziehung des späteren nutzers nicht problemlos möglich. hier muss für die anforderungserhebung im ubiquitous computing ein vorgehen gefunden werden, das diese herausforderungen adressiert und die damit verbunden probleme lösen kann. einen ersten schritt in diese richtung machen partizipative ansätze, die den benutzer mit hilfe von iterativ erstellen prototypen immer näher an das spätere system heranführen und so sukzessive ein gemeinsames verständnis von entwickler und anwender fördern. um diese partizipativen prozesse beginnen zu können ist es jedoch notwendig, zunächst die bedürfnisse des benutzers zu verstehen, um initiale konzepte für eine unterstützung durch ein ubiquitäres system entwickeln zu können. diese dienen dann konsequent als grundlage für die systematische entwicklung eines derartigen systems unter beteiligung der späteren nutzer. für die weitere forschung zur analyse von anforderungen an ubiquitäre systeme bedeutet dies konkret, dass zunächst methoden und techniken aus verschiedenen technischen und sozial relevanten disziplinen für die jeweiligen phasen der anforderungserhebung identifiziert und auf ihre eignung für die entwicklung ubiquitärer systeme evaluiert werden. anschließend sind geeignete methoden zu einem handhabbaren vorgehen zur anforderungserhebung ubiquitärer systeme zu integrieren. neben dem nutzer existieren noch weitere quellen für anforderungen im ubiquitous computing, z.b. um die sozialverträglichkeit und rechtskonformität der anwendungen garantieren zu können. diese gilt es vollständig zu identifizieren, damit eine umfassende anforderungserhebung möglich wird. zudem muss, wie gewöhnlich bei der einführung neuer technologien, das problem des vertrauens der nutzer in die neue technologie hinzu. hier müssen jene eigenschaften des systems identifiziert werden, die das vertrauen der potenziellen nutzer in ubiquitäre systeme unterstützen, um diese später gezielt gestalten zu können. acknowledgements: die forschungsarbeit wurde unterstützt durch das venus-projekt. venus ist ein forschungsprojekt der universität kassel, gefördert durch das land hessen als teil der landes-offensive zur entwicklung wissenschaftlich-ökonomischer exzellenz (loewe). weitere informationen unter: www.iteg.uni-kassel.de/venus bibliography [1] weiser, m.: the computer for the 21st century. sigmobile mobile computing and communications review. 3(3): s. 3-11, 1999. [2] baier, g. and m. rothensee: die akzeptanz zukünftiger ubiquitous computing anwendungen. in hrsg.: a.m. heinecke, h. paul: mensch und computer 2006: mensch und computer im strukturwandel. oldenburg verlag, münchen, 2006. [3] mattern, f.: ubiquitous computing: schlaue alltagsgegenstände – die vision von der eceasst 8 / 9 volume 27 (2010) informatisierung des alltags. bulletin sev/vse. 2004(19): s. 9-13, 2004. [4] want, r.: an introduction to ubiquitous computingr. in hrsg.: j. krumm: ubiquitous computing fundamentals, crc press, boca raton, 2009. [5] pichler, m.: a novel view on requirements engineering for ubiquitous computing: the innovation perspective. dissertation, linz, 2007. [6] norman, d.a.: the design of everyday things. mit press, london, 1999. [7] vallance, r., s. kiani and s. nayfeh: open design of manufactoring equipment. in proceedings of the cirp 1st international conference on agile and reconfigurable manufacturing. ann arbor, 2001. [8] hoffmann, h., j.m. leimeister and h. krcmar: a framework for developing personalizeable mobile services in automobiles. proceedings of the fifteenth european conference on information systems. st. gallen, 2007. [9] hoffmann, h., j.m. leimeister and h. krcmar: kundenintegration bei der erstellung bedarfsgerechter automotive software. in hrsg.: h. heilmann: humane nutzung der informationstechnologie, akademische verlagsgesellschaft aka gmbh, heidelberg, 2010. [10] he, j. and w.r. king: the role of user participation in information systems development: implications from a meta-analysis. journal of management information systems. 25(1): s. 301-331, 2008. [11] ebb, b.r.w.: the role of users in interactive systems design: when computers are theatre, do we want the audience to write the script? behaviour and information technology. 15(2): s. 76-83, 1996. [12] bruseberg, a. and d. mcdonagh-philp: focus groups to support the industrial/product designer: a review based on current literature and designers' feedback. applied ergonomics. 33(1): s. 27-38, 2002. [13] fleisch, e., f. mattern and s. billinger: betriebswirtschaftliche applikationen des ubiquitous computing: beispiele, bausteine und nutzenpotenziale. hmd praxis der wirtschaftsinformatik. 229: s. 5-15, 2003. [14] beyer, h. and k. holtzblatt: contextual design: defining customer-centered systems. morgan kaufmann publ., san francisco, 1998. [15] dix, a., j. finley, g. abowd and b. russel: human-computer interaction. pearson prentice hall, harlow, 2004. [16] sharp, h., y. rogers, and j. preece: interaction design. wiley, chichester, 2007. [17] hoffmann, h., j. fähling , j.m. leimeister and h. krcmar: kundenintegration in die innovationsprozesse bei hybriden produkten eine bestandsaufnahme. in: informatik 2009 im focus das leben. lübeck, 2009. [18] hoffmann, h., j.m. leimeister, and h. krcmar: tool support for the participatory design of end user oriented applications in the automobile. proceedings of the 18th european conference on information systems. pretoria, 2010. [19] ahrens, g.: das erfassen und handhaben von produktanforderungen methodische voraussetzungen und anwendung in der praxis. dissertation, berlin, 2000. [20] foltz, c., s. killich, m. wolf, l. schmidt and h. luczak: task and information nutzerintegration in die anforderungserhebung für uc-systeme saks 2010 9 / 9 modeling for cooperative work. in: systems, social and internationalization design aspects of human-computer interaction proceedings of the hci international. new orleans, 2001. [21] mambrey, p. and v. pipek: enhancing participatory design by multiple communication channelsr. in hrsg.: h.-j. bullinger and j. ziegler: human-computer interaction: communication, cooperation, and application design, s. 387-391, lawrence earlbaum ass., london, 1999. [22] szyperski, n.: zur wissensprogrammatischen und forschungsstrategischen orientierung der betriebswirtschaft. zeitschrift für betriebswirtschaftliche forschung. 23: s. 261282, 1971. [23] witte, e.: feldexperimente als innovationstest die pilotprojekte zu neuen medien. zeitschrift für betriebswirtschaftliche forschung. 49(5): s. 419-436, 1997. [24] schwabe, g. and h. krcmar: piloting a socio-technical innovation. proceedings of the 8th european conference on information systems ecis 2000. vienna, 2000. [25] michahelles, f.: innovative application development for ubiquitous and wearable computing. hartung-gorre, konstanz, 2005. [26] kotonya, g. and i. sommerville: requirements engineering: processes and techniques. wiley, chichester, 1998. [27] pohl, k.: requirements engineering: grundlagen, prinzipien, techniken. dpunkt-verl., heidelberg, 2008. [28] sommerville, i. and p. sawyer: viewpoints: principles, problems and a practical approach to requirements engineering. annals of software engineering. 3: s. 101-130, 1997. [29] knoll, s.w. and g. horton: changing the perspective: improving generate thinklets for ideation. proceedings of the hawaii international conference on system sciences 2010 (hicss). koloa, kauai, hawaii, 2010. [30] briggs, r.o., g.-j.d. vreede, and j. jay f. nunamaker: collaboration engineering with thinklets to pursue sustained success with group support systems. journal of management information systems. 19(4): s. 31-64, 2003. testing self-adaptive applications with simulation of context events electronic communications of the easst volume 28 (2010) proceedings of the third international discotec workshop on context-aware adaptation mechanisms for pervasive and ubiquitous services (campus 2010) testing self-adaptive applications with simulation of context events konstantinos kakousis, nearchos paspallis, george a. papadopoulos, pedro antonio ruiz 12 pages guest editors: sonia ben mokhtar, romain rouvoy, michael wagner managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst testing self-adaptive applications with simulation of context events konstantinos kakousis1, nearchos paspallis1, george a. papadopoulos1, pedro antonio ruiz2 department of computer science, university of cyprus1 integrasys s.a., esquillo, spain2 abstract: modern trends in mobile computing have raised the expectations of users in terms of such features such as context-awareness and self-adaptiveness. with such capabilities, applications can autonomously sense their context and automate a number of tasks, effectively reducing the attention required by the end users. this paper presents a custom simulation engine, designed to support the testing of applications developed using the music platform. the simulation tool consists of a platform-independent server module, deployed along with the application, and a client module which is responsible for interpreting and executing the simulation script. the use of the tool is demonstrated in the scope of the satmotion application, which is designed to assist satellite antenna installers with specialized functionality. keywords: context-awareness, self-adaptation, simulation, context plug-ins, osgi 1 introduction with recent advances in hardware and software for mobile devices, the users have grown to expect more from their smart-phones. in particular, with the widespread use of sensors and the pervasiveness of network connectivity, many applications featuring advanced context-awareness and self-adaptiveness are now possible. nevertheless, the design, implementation and testing of such applications remains a work-in-progress, posing significant challenges to their developers. this paper presents a custom context simulation tool, designed to support the testing of applications developed using the music platform. the latter provides modeling tools for design-time support, along with a middleware architecture used in run-time. the context simulation tool is used to verify the operation of the designed applications and consists of a platform-independent server module, deployed along with the application, and a client module which is responsible for interpreting and executing the simulation script. the use of the tool is demonstrated in the scope of the satmotion application, which is designed to assist satellite antenna installers with specialized functionality. the rest of this paper is organized as follows: chapter 2 presents the foundations of the music platform, which is the one targeted by the proposed simulation tool. next, chapter 3 presents the functionality and design of the context simulation tool, which is then demonstrated in the context of testing a real application—the satmotion—in section 4. the paper then discusses related work in section 5 and closes with the conclusions in section 6. 1 / 12 volume 28 (2010) testing self-adaptive applications with simulation of context events 2 the music platform as part of a more general framework [rbd+09], the music context management middleware provides developers with both a methodology for designing context-aware applications, as well as a platform for deploying them [pas09]. to enable context-aware, self-adaptive applications, the developers specify their applications in terms of components and configuration plans. the former are normal self-contained and reusable software entities, commonly termed as software components [szy97]. the latter are customized artifacts used to define the composition possibilities for the application [fhs+06]. in this case, the composition variations are defined either in terms of configurable parameters, or in terms of interchangeable components [mskc04]. while the composition plans are sufficient to define the adaptation domain of an application (i.e., the set of possible states it can be adapted to), additional adaptation reasoning mechanisms are needed for autonomously selecting the optimal adaptation as needed. in the case of the music platform, these mechanisms are based on the use of utility functions [aep+07, pehp09, krw+09]. these provide a means for selecting an adaptation by assigning a utility value to each possible configuration, in a way that corresponds to their overall fitness to the context. in this way, it is possible for the middleware to continuously evaluate the context in runtime, and pick a configuration that optimizes utility, as measured by the utility functions [fhs+06]. an important component of the music middleware is the context manager, which is of particular interest to this paper. in music, context is dealt with as an individual aspect. in this regard, context clients—including the adaptation reasoning module that evaluates the utility functions— register with the context middleware for particular context types. in the used context model [rwk+08a, rwk+08b], the context types are disambiguated via two concepts: the scope and the entity. the former models the targeted context property (e.g., location, temperature, memory use, etc) and the latter defines the entity which is described by the property (e.g., my car, the room i am in, the device i am holding, etc). while the context needs of clients are explicitly identified, so does the context provided in the middleware. for the latter, pluggable mechanism is used which allows individual context plug-ins to be dynamically installed and deployed to provide the necessary context types (e.g., a location plug-in which uses an underlying gps sensor, a temperature sensor plug-in that uses a web-service, etc) [pas09]. the context middleware, as well as the whole music middleware, are built on top of the osgi framework. the functionality of the music middleware architecture is illustrated in the satmotion application, presented throughout the paper. 2.1 the satmotion application satmotion, developed by integrasys, is an application that runs on pdas and assists installers during the process of alignment of satellite antennas that provide broadband access through bidirectional satellite communications. satmotion allows the control and command of a measurement instrument, normally a spectrum analyzer, from a remote wireless handheld terminal in order to obtain trace information representing electromagnetic signals acquired by the instrument. signal traces are retrieved from the measurement instrument by a software server module, then transmitted wirelessly and finally displayed in real-time on the screen of the remote terminal. the satmotion runtime high-level architecture is illustrated in figure 1. proc. campus 2010 2 / 12 eceasst figure 1: using satmotion to line-up a vsat antenna installation satmotion is the main application of a software suite called satcom. besides satmotion, satcom contains two complementary applications that ease the installer in his daily tasks: first, the plainstallation application is in charge of controlling the connection with the company server, as well as for authenticating and retrieving the task schedule. the task schedule contains route information, installation sites and specific tasks to do. second, the adap2nav application provides navigation facilities to guide the user to the installation site, and provide different interfaces, such as graphical navigation mode, text mode or voice mode. 2.2 variability in the satmotion application the satmotion trial is a mobile application whose usability can be affected by several factors, and therefore, can benefit from music. in order to maximize the usability, the application exhibits context-aware behavior that is manifested through the self-reconfiguration of the application. the selection of the optimal variant depends on the contextual information, as described in the potential adaptations below: • the plainstallation application connects to a remote service provider in order to download the installation site/sites. the application uses the network interface available at the moment (wi-fi/gprs). depending on the economic cost of the attached network, the middleware decides whether to download just the necessary or all of the information. therefore, the amount of downloaded data depends on the currently used network. • when the installer accepts the tasks in her or his pda, the platform automatically shows the optimal route on pda (adapt2nav application). if a car gps is detected, the platform selects it as the optimal interface. depending on the device type (i.e., pc, pda or car gps) different versions of the user interface are presented. • when the installer is aligning the antenna, several applications modes are automatically offered, depending on the context conditions. the network qos is the most influential context parameter during the alignment process: – twoway communication: when there are plenty of network resources. the application receives the signal information from the server. also, it sends commands to the 3 / 12 volume 28 (2010) testing self-adaptive applications with simulation of context events server to change the setup of the spectrum analyser and consequently the setup of the application. – oneway: when the network does not provide enough throughput for a usable twoway mode, a unidirectional communication mode is selected. this application mode does not allow neither control nor command of the spectrum analyzer. – text mode: it only receives relevant data (signal noise ratio and cross polarization value) when the network qos is extremely low. – adjust the trace resolution: the resolution of the received signal can also be adjusted to the quality of the network. – if the terminal provides signal traces through the satellite network, this service is selected as the optimal one. • if several installers are using the server at the same time to align antennas, the satmotion server may not be able to serve all of them. the installer has to wait until a free slot is available. the installation processes with the lowest priority is interrupted until the resources become available. the priority of installation is given by the user profile and client profile. the main contextual information relevant to the adaptation of the satmotion application are: • application status: a sensor that monitors specific information of the application, such as the installation sites, alignment status, user profiles, etc. • user preferred mode: the application provides an interface for the users to set their preferences. • network throughput: it is simulated with a sensor plugin. • network availability: wifi, 3g, or none available. • device memory: the available memory of the device for applications. • location: the gps coordinates of the installer. 3 context simulation tool this section presents the mechanism developed for simulating context events within the music middleware. the implementation of this mechanism is provided as an independent application— not part of the core middleware—allowing the developers to use it only as needed. this mechanism is directly interfaced with the context middleware. the middleware provides interfaces (in the form of osgi services) that enable external components to: • first, access information concerning the available and required context types (and optionally receive asynchronous notification upon their update); proc. campus 2010 4 / 12 eceasst • second, use the simulation mode which allows for the interception of all context data while blocking a subset of it as needed; and • third, create and publish arbitrary context events containing the simulated context values. the simulation mode is an option, that when set can intercept the flow of all context events from the providers (i.e., the context plug-ins) so that they do not reach the corresponding context clients. with this option, it is possible to have complete control of the middleware, so that context events (both real and simulated) are forwarded to the middleware and the context clients only as intended by the testers. the context simulation tool is organized in a client-server architecture. the two sides coordinate via invocations of commands, as formalized by a predefined script (discussed in the next subsection). the server side consists of the scenario engine which interprets and executes the commands, as defined in the script. the client side typically consists of a graphical frontend, that the tester can use to load, edit, and execute simulation scripts. 3.1 scenario engine dialect the scenario engine consists of a simple parser that recognizes a set of predefined middleware commands, and an execution engine that executes the commands on a local (or remote) music host. the main purpose of the scenario engine is to enable application and middleware developers to introspect the context middleware reaction to specific context events. the dialect supported by the scenario engine includes the following commands: • logtime logs the current date and time. the logtime command has no arguments and returns the current date and time in milliseconds precision in the format “yyyyy-mm-dd hh:mm:ss.sss”. • sleep int duration halts the execution of the script for a predefined number of milliseconds. the sleep command accepts a single argument of the integer type. • memory lists the available and the total memory. the memory command has no arguments and returns the amount of free and total memory of the java virtual machine (jvm) that the music node is deployed on (in bytes). • contextevent string #entity string #scope string #representation object[] values executes a simulated context event. this command generates a new context event as defined by its four arguments. the first argument specifies the entity of the context event to be generated, the second one its scope and the third argument its representation. the last argument is a list of values of any type, enclosed in brackets and separated by commas. an example is illustrated below. example 1: contextevent #...entity.user|myself #...scope.location #...representation.location [#latitude=30.1, #longitude=31.2] 5 / 12 volume 28 (2010) testing self-adaptive applications with simulation of context events • invocation string bundlename string servicename string methodname object[] arguments invokes arbitrary services published by the installed osgi bundles. the invocation method accepts four arguments and can be used for invoking just any method, of any service, provided by any resolved bundle. the first argument specifies the bundle’s symbolic (full) name, the second argument the name of the selected provided service, the third argument the name of one of the desired method and finally the last argument defines the list of arguments that the defined method requires. the arguments must be enclosed in brackets, separated by commas. an example is illustrated below. example 2: invocation org.istmusic.mw.gui.context.viewer testinvocation testmethod [false,some string,5.555,5] the above list contains the commands that are currently supported by the scenario engine. however, this list can be easily extended to support additional commands, if needed. as it was mentioned already, the scenario engine is accessed by a frontend graphical application. in the current implementation, this frontend is simply a subsystem of a wider visualization tool, used for monitoring and controlling many aspects of the music middleware. the simulation script can be loaded from an external text file, or it can be directly typed in a text area inside the frontend tool. after the simulation script has been loaded it can be executed. the output is also displayed in a text area of the frontend tool, and is also written to the middleware log. if needed the contents of the log area can be saved in a separate text file for further study and use. in the simulation mode the context events are redirected to the visualization tool. the latter intercepts the events and does not let them back to the system for normal execution. thus, only simulated events created in the simulator are delivered to the listeners. the interception mode is especially useful for testing certain aspects (i.e., context-aware or self-adaptive behavior) of the applications in isolation of the rest of the context events monitored. 3.2 distributed simulation an important feature of the music middleware is that it supports distributed applications which involve adaptable components from multiple nodes. in practice, applications might include components or services deployed in distributed nodes (which must also run an instance of the music middleware). in effect, all the nodes that contribute to an application form a so-called adaptation domain [ahpe07, aep+07]. for this purpose, the simulation engine—and the corresponding script—were enhanced to also facilitate such distributed environments. as argued already, the scenario engine is organized in two complementary components: the scenario engine client and the scenario engine server. the client can handle more than one server. the client sends commands (as parsed from the script) to the server for execution. the server executes the commands and returns a response which is received by the client. communication is initiated by the client side only. the support for distribution implies some changes in the script as well. for the two commands that is reasonable to expect distributed execution (i.e., contextevent and invocation), the [nodex] prefix is introduced. in principle, when a prefix is not indicated, then the command is proc. campus 2010 6 / 12 eceasst figure 2: overview of communications in distributed simulation always executed locally. when the [nodex] prefix is used (where x can be a integer), then the command is delegated to the corresponding node. at this point, the only missing piece is which nodes do the [nodex] prefixes correspond to. this is assigned dynamically right before the execution of the script, as shown below. the first step is the discovery of the available music nodes and, consequently, the available instances of the scenario engine server. for this purpose, a service discovery agent is used to dynamically discover the music nodes. at a lower level, this is done using the service location protocol (slp). for example, in figure 2, the master node and the two slave nodes (i.e., the windows mobile and the android devices) discover and are aware of each other. the next step is the association of each logical name (i.e., indicated by [nodex]) with actual nodes. it is possible during the launch of the script to check whether there are references to distributed nodes (e.g., to [node1] and to [node2]) and ask the user to manually associate the actual nodes with the corresponding logical names (e.g., the windows mobile and the android devices respectively in the example in figure 2). this approach has the important advantage that the scripts remain agnostic to specific nodes (as indicated by their host names or ips), and thus can be reused in different situations with various devices deploying the music middleware. 4 demonstrating the context simulation tool in satmotion this section presents a scenario, encoded using the proposed scripting language, which is used to evaluate the context-aware and self-adaptive behavior of the satmotion application which was presented in subsections 2.1 and 2.2. in principle, the script dictates specific context changes which are expected to trigger certain adaptations by the middleware. these adaptations can be 7 / 12 volume 28 (2010) testing self-adaptive applications with simulation of context events eventually confirmed by examining the log messages. the initial situation is that the plainstallation application is launched and the 3g connection is available. the script is as follows (comments appear as text after the “%” character): 1. logtime % logs time 2. invocation satcom.plainstall authenticate authenticateclient ["login", "password"] % invocation of authentication method 3. sleep 10000 % sleeps 10 seconds 4. logtime 5. contextevent #...entity.device|this #...scope.wifi.signal #...representation.network.signal [#strength=0.95] % change % 3g to wifi (by making a strong wifi signal available) 6. memory % logs the available memory 7. sleep 10000 % sleeps another 10 seconds 8. invocation satcom.plainstall taskmanager accept % invocation of method that signals tasks acceptance once, % the tasks are downloaded and accepted, the navigation % application is automatically selected by the middleware 9. contextevent #...entity.device|this #...scope.location #...representation [#longitude=35.1, #latitude=33.4] % changes location 10. memory the script starts by printing out the time (step 1) and then proceeds by invoking the command authenticateclient, using as arguments the login and password strings (step 2). at the next step (3), the simulation sleeps for 10 seconds, and then it resumes with logging time again (step 4). the next step includes a context change that signifies transition from 3g to wifi connection. this is modeled in terms of a context event that shows that the wifi signal is now 95% strong (step 5). the script then proceeds with printing out details of the memory (step 6) and then sleeping again for another 10 seconds (step 7). following that, the taskmanager is then explicitly asked to accept the assigned tasks through an appropriate invocation (step 8). at that point, a new context event is triggered, encoding that the location of the user has changed to a pair of designated longitude/latitude coordinates (step 9). the script ends with printing out details of the memory (step 10). 11. logtime 12. [node1] invocation navigation navigationservice start proc. campus 2010 8 / 12 eceasst 13. sleep 15000 14. logtime 15. [node1] invocation navigation navigationservice stop at this point, the distribution capabilities of the simulation engine are shown. at the next step (11), the time is logged and then the navigationservice is started on node1 (step 12). this slave node offers the navigation service which allows the application to receive driving directions. by making this service available (simply by starting it), the client side of the application is adapted by binding to the service and start using it (the actual moment that this happens appears in the log of the adaptation engine). after a small delay of fifteen seconds (step 13) to allow the service to be started and discovered, and the adaptation engine to respond accordingly, the time is logged (step 14) and the navigation service is stopped (step 15). this eventually causes the service absence to be discovered again and the adaptation engine to respond accordingly (with all these event being recorded in the log). 5 discussion and related work over the last decade much research work has been conducted on self-adaptive software. several research groups and individuals have proposed middleware solutions for monitoring and reacting to context changes [sg02, hen03, mpf+06, pas09]. however, only a few works provide appropriate tools that aim to simplify the task of testing context-aware applications and frameworks. as already noted in [mskc04], compositional adaptation is very powerful, but appropriate tools are needed to fully exploit its power. the music studio aims to provide a suite of tools and methods that help music application developers creating applications based on the music middleware. the proposed simulation tool has been developed as part of this suite and allows to monitor and control context changes and visualize adaptation decisions and effects. similar to our work, du and wang [dw08] have proposed a programming model, an implementation framework and a development environment that facilitate the development of contextaware applications. the development environment provides a series of tools to simplify the development process. the environment is composed of three parts: program integrator, context change simulator and an interpreter library. the program integrator reduces the users effort on binding user-defined programs with the implementation framework, by automatically generating the binding code. the context change simulator provides testability for developed applications. the simulator can run in two different modes to support high-level application logic testing or implementation level testing. finally, the extensible interpreter library reduces the effort on context conversion by providing a set of reusable and widely used context interpreters. when compared to our tool, du and wang’s framework lack of support for simulating/testing system’s behavior in the case of distributed adaptation. in another work, huebscher and mccan [hm04] have proposed a simulation framework for context-aware applications targeting developers who want to test their applications’ context and autonomic logic prior to real-life deployment. their framework runs on top of another simulation tool called tossim [llwc03], a simulator for tinyos applications. the primary objective of 9 / 12 volume 28 (2010) testing self-adaptive applications with simulation of context events this work was to simulate the data produced from real sensors while in our case the focus is on simulating and monitoring the behavior of the applications and context middleware. finally, the rainbow approach [gch+04] provides a framework for monitoring and managing a target system throughout the adaptation cycle. rainbow uses an external adaptation mechanism based on the utilization of architectural models at runtime. this enables system administrators to monitor a managed system and its runtime behavior and thus easier detect possible problems. cheng et al [cgs06] have proposed a specialized adaptation language for communicating with the rainbow framework. this language aims to improve adaptation decision making by capturing more effectively several adaptation factors that are considered relevant to an adaptation decision. a utility theory-based evaluation mechanism is then used for choosing the adaptation variant that maximizes user’s utility. 6 conclusions this paper presented a context simulation engine developed in the scope of the music project to support developers of context-aware, self-adaptive applications into testing their applications. while many testing frameworks exist in terms of evaluating the functional properties of software, little support is provided in terms of testing extra-functional properties such as contextaware and self-adaptive behavior. the proposed framework achieves that in terms of reusable, parseable scripts which can be designed to evaluate the correctness and performance of custom applications. the proposed script format and the simulation framework are evaluated in terms of describing their applicability in the test of the satmotion application. for the future we aim to enrich the scenario engine with more sophisticated commands and provide a graphical representation of the middleware performance during the simulation. finally, the effectiveness of the tool will be evaluated in the scope of other music pilot applications as well. acknowledgements: the authors of this paper would like to thank their partners in the musicist project and especially ultan carrol for his valuable input on the details of the communication aspects. we would also like to acknowledge the financial support given to this research by the european union (6th framework programme, contract number 35166). bibliography [aep+07] m. alia, v. s. w. eide, n. paspallis, f. eliassen, s. o. hallsteinsen, g. a. papadopoulos. a utility-based adaptivity model for mobile applications. in proceedings of the 21st international conference on advanced information networking and applications workshops (ainaw’07). pp. 556–563. ieee computer society press, niagara falls, ontario, canada, may 2007. [ahpe07] alia, hallsteinsen, paspallis, eliassen. managing distributed adaptation of mobile applications. in proceedings of the 7th ifip international conference on distributed applications and interoperable systems (dais’07). lncs 4531, pp. 104– 118. springer verlag, paphos, cyprus, 2007. proc. campus 2010 10 / 12 eceasst [cgs06] s.-w. cheng, d. garlan, b. schmerl. architecture-based self-adaptation in the presence of multiple objectives. in seams ’06: proceedings of the 2006 international workshop on self-adaptation and self-managing systems. pp. 2–8. acm, new york, ny, usa, 2006. doi:http://doi.acm.org/10.1145/1137677.1137679 [dw08] w. du, l. wang. context-aware application programming for mobile devices. in proceedings of the 2008 c3s2e conference. pp. 215–227. acm, montreal, quebec, canada, 2008. [fhs+06] j. floch, s. hallsteinsen, e. stav, f. eliassen, k. lund, e. gjorven. using architecture models for runtime adaptability. ieee software 23(2):62–70, 2006. [gch+04] d. garlan, s.-w. cheng, a.-c. huang, b. schmerl, p. steenkiste. rainbow: architecture-based self-adaptation with reusable infrastructure. computer 37:46– 54, 2004. doi:http://doi.ieeecomputersociety.org/10.1109/mc.2004.175 [hen03] k. henricksen. a framework for context-aware pervasive computing applications. phd thesis, the university of queensland, sept. 2003. [hm04] m. c. huebscher, j. a. mccann. simulation model for self-adaptive applications in pervasive computing. in proceedings of the database and expert systems applications, 15th international workshop. pp. 694–698. ieee computer society, 2004. [krw+09] m. u. khan, r. reichle, m. wagner, k. geihs, u. scholz, c. kakousis, g. a. papadopoulos. an adaptation reasoning approach for large scale componentbased applications. volume 19, p. 12. electronic communications of the easst, amsterdam, netherlands, 2009. [llwc03] p. levis, n. lee, m. welsh, d. culler. tossim: accurate and scalable simulation of entire tinyos applications. in proceedings of the 1st international conference on embedded networked sensor systems. pp. 126–137. acm, los angeles, california, usa, 2003. [mpf+06] m. mikalsen, n. paspallis, j. floch, e. stav, g. a. papadopoulos, a. chimaris. distributed context management in a mobility and adaptation enabling middleware (madam). in proceedings of the 21st annual acm symposium of applied computing, track of dependable and adaptive systems (sac’06). pp. 733–734. acm, dijon, france, 2006. [mskc04] p. k. mckinley, s. m. sadjadi, e. p. kasten, b. h. c. cheng. composing adaptive software. ieee computer 37(7):56–64, 2004. [pas09] n. paspallis. middleware-based development of context-aware applications with reusable components. phd thesis, university of cyprus, sept. 2009. http://member.acm.org/∼nearchos/phd 11 / 12 volume 28 (2010) http://dx.doi.org/http://doi.acm.org/10.1145/1137677.1137679 http://dx.doi.org/http://doi.ieeecomputersociety.org/10.1109/mc.2004.175 http://member.acm.org/~nearchos/phd testing self-adaptive applications with simulation of context events [pehp09] n. paspallis, f. eliassen, s. hallsteinsen, g. a. papadopoulos. developing selfadaptive mobile applications and services with separation-of-concerns. in nitto et al. (eds.), at your service: service-oriented computing from an eu perspective. pp. 129–158. mit press, 2009. [rbd+09] r. rouvoy, p. barone, y. ding, f. eliassen, s. hallsteinsen, j. lorenzo, a. mamelli, u. scholz. music: middleware support for self-adaptation in ubiquitous and service-oriented environments. in software engineering for self-adaptive systems. pp. 164–182. 2009. [rwk+08a] r. reichle, m. wagner, m. khan, k. geihs, j. lorenzo, m. valla, c. fra, n. paspallis, g. a. papadopoulos. a comprehensive context modeling framework for pervasive computing systems. in proceedings of the 8th ifip international conference on distributed applications and interoperable systems (dais’08). lncs 5053, pp. 281–295. springer verlag, oslo, norway, 2008. [rwk+08b] r. reichle, m. wagner, m. u. khan, k. geihs, m. valla, c. fra, n. paspallis, g. a. papa. a context query language for pervasive computing environments. in proceedings of the 5th ieee workshop on context modeling and reasoning (comorea’08) in conjunction with the 6th ieee international conference on pervasive computing and communication (percom’08). pp. 434–440. ieee computer society, hong kong, mar. 2008. [sg02] j. p. sousa, d. garlan. aura: an architectural framework for user mobility in ubiquitous computing environments. in proceedings of the ifip 17th world computer congress tc2 stream / 3rd ieee/ifip conference on software architecture: system design, development and maintenance. pp. 29–43. kluwer, b.v, montreal, quebec, canada, 2002. [szy97] c. szyperski. component software: beyond object-oriented programming. addisonwesley professional, dec. 1997. proc. campus 2010 12 / 12 introduction the music platform the satmotion application variability in the satmotion application context simulation tool scenario engine dialect distributed simulation demonstrating the context simulation tool in satmotion discussion and related work conclusions defining models \205 meta models versus graph grammars electronic communications of the easst volume 29 (2010) proceedings of the ninth international workshop on graph transformation and visual modeling techniques (gt-vmt 2010) defining models – meta models versus graph grammars berthold hoffmann, mark minas 13 pages guest editors: jochen küster, emilio tuosto managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst defining models – meta models versus graph grammars berthold hoffmann1, mark minas2 1hof@informatik.uni-bremen.de universität bremen und dfki bremen, germany 2mark.minas@unibw.de universität der bundeswehr münchen, germany abstract: the precise specification of software models is a major concern in modeldriven design of object-oriented software. metamodelling and graph grammars are apparent choices for such specifications. metamodelling has several advantages: it is easy to use, and provides procedures that check automatically whether a model is valid or not. however, it is less suited for proving properties of models, or for generating large sets of example models. graph grammars, in contrast, offer a natural procedure – the derivation process – for generating example models, and they support proofs because they define a graph language inductively. however, not all graph grammars that allow to specify practically relevant models are easily parseable. in this paper, we propose contextual star grammars as a graph grammar approach that allows for simple parsing and that is powerful enough for specifying non-trivial software models. this is demonstrated by defining program graphs, a language-independent model of object-oriented programs, with a focus on shape (static structure) rather than behavior. keywords: graph grammar, meta-model 1 introduction the precise specification of software models is a major concern in model-driven design of objectoriented software. such specifications should support a checking procedure for distinguishing valid from invalid models, they should be well-suited for proofs in order to reason about the specified models, and they should allow for automatically generating model instances that may be used as test cases for computer programs being based on such models. the meta-modeling approach is an apparent choice for such specifications. it allows for precise model definitions and provides checking procedures. however, it is less suited for proofs and for instance generation. graph grammars are another natural candidate for specifying software models. they precisely define model languages, they are well-suited for proofs because of their inductive way of defining a graph language, and they offer a natural procedure for automatically generating model instances. several kinds of graph grammars have been proposed in the literature. in order to allow for the specification of practically relevant models, we need a formalism that is powerful so that all properties of models can be captured, and simple in order to be practically useful, in particular for parsing models in order to determine their validity. however, easy to use graph grammar approaches often fail to completely specify models. as a case study, we consider pro1 / 13 volume 29 (2010) mailto:hof@informatik.uni-bremen.de mailto:mark.minas@unibw.de meta models versus graph grammars gram graphs, a language-independent model of object-oriented programs that has been devised for specifying refactoring operations on programs [medj05]. however, neither hyperedge replacement grammars [dhk97], nor the equivalent star grammars [dhjm10, theorem 2.8], nor node replacement grammars [er97] are powerful enough for completely specifying program graphs. even the recently proposed adaptive star grammars [dhj+06, dhjm10] fail for certain more delicate properties of program graphs. their rules must be extended by application conditions in order to describe program graphs completely [hof10]. in this paper, we propose the simpler graph grammar approach of contextual star grammars, an extension of star grammars that allows for easy parsing. plain star rules are extended with positive and negative contexts, which must exist (or must not exist, respectively) in order to apply a star rule. contexts may specify the existence of paths to certain nodes in the host graph, which may then be linked by the rule application. it turns out that program graphs can be defined by a contextual star grammar. hence, this graph grammar approach allows for the precise specification of program graphs, i.e., non-trivial software models, supports a natural procedure for generating model instances, is well-suited for proofs, and allows for easy parsing. we contrast this grammar with the definition of program graphs using a conventional meta-model, which is specified by a uml class diagram and logical ocl constraints. the paper is structured as follows. in section 2, we recall how object-oriented programs can abstractly be represented as program graphs. we define the language of program graphs by a metamodel that consists of a class diagram with additional ocl constraints. then we introduce star grammars in section 3, show that they can define program skeletons, a sub-structure of program graphs, but fail to define program graphs themselves. we introduce contextual star grammars in section 4, define program graphs with them, and outline an easy parsing procedure. we discuss these specifications—by metamodels and by contextual star grammars—in section 5. we conclude with some remarks on related and future work in section 6. 2 graphs representing object-oriented programs program graphs have been devised as a language-independent representation of object-oriented code that can be used for studying refactoring operations [medj05]. therefore, they do not represent the abstract syntax of an object-oriented program, but rather its structural components and their dependencies. for instance, they capture single inheritance of classes and method overriding. data flow between parameters, attributes, and method invocations represents the structure within method bodies. consider the object-oriented program shown in figure 1 as an example. the program, written in object-oriented pseudo code, consists of class cell and its subclass recell. the superclass has an attribute variable cts and two methods get and set. subclass recell inherits these three features and additionally has an attribute variable backup and a method restore. moreover, it overrides the method set of its superclass. figure 1 also shows the corresponding program graph. the graph is actually represented as an object diagram according to the program graphs’ model whose class diagram is shown in figure 2. note that not all association roles of figure 2 are shown figure 1. only one of the two roles of the associations is shown to avoid clutter. note also the fat links in figure 1; they proc. gt-vmt 2010 2 / 13 eceasst class cell is var cts: any; method get() any is return cts; method set(var n: any) is cts := n subclass recell of cell is var backup: any; method restore() is cts := backup; override set(var n: any) is backup := cts; super.set(n) figure 1: an object-oriented program and its program graph accessvariable body invoc class exprfeature method value 1 expr 1..* bodyclass1 sig1 calls 1 param feature sub super0..1 body featureclass 0..1 impl 0..1 body 0..1 param method 0..1 /parent /child {union} {union} callee {subsets parent} var {subsets parent} {subsets child} {subsets child} 0..1 refersto 0..1 0..1 figure 2: a model m for program graphs shown as a class diagram correspond to the composition associations of figure 2. each class is represented by a class node. note the universal superclass any. each class represents its (protected) attribute variables and (public) methods as features. method nodes together with variable nodes as their parameters represent method signatures; method bodies are represented separately by body nodes. if a method is overridden, a new body refers to (we say: implements) the signature of the overridden method. method set is an example: the signature node set:method is implemented by two body nodes, one being part of class cell, the other being part of subclass recell. data flow within method bodies is represented by (abstract) expressions that a body consists of (link expr). expressions are represented by access or invoc nodes, both being subclasses of expr. access represents a reference to a variable either using its value, or assigning the value of an expression to it. invoc nodes represent method invocations with their actual parameters being referred to by param links. 3 / 13 volume 29 (2010) meta models versus graph grammars figure 2 shows a uml class diagram for program graphs. the class diagram represents a model m of program graphs and also a meta-model because program graphs are models of object-oriented programs, i.e., m is a model of a modeling language. as usual, missing cardinalities mean 0..*. also note the child-parent association at class expr. it is subsetted by the corresponding associations (actually their association ends) for the subclasses invoc and access. however, not all instances of the model represented by the class diagram are valid program graphs. certain syntactic properties, usually called static semantics or consistency conditions, cannot be expressed by just a class diagram. the class p of all program graphs is rather defined by the class diagram and additional constraints: definition 1 (program graphs) the class p of program graphs consists of all instances of the model m in figure 2 that additionally satisfy the following constraints: 1. there is exactly one root class, i.e., class node without superclass. 2. a variable node either belongs to a class (link feature) or to a method (link param). 3. an expr node either belongs to a body (link body) or to another expression (link parent). 4. a body b may implement a method contained in some class c if b is contained in c or in a subclass of c. 5. every class may contain at most one body defining or overriding a particular method m. 6. an access node e may refer to a variable node representing an attribute contained in some class c if e is a sub-expression of a body that is contained in c or some subclass of c. 7. an access node e may refer to a parameter of a method node m if e is a sub-expression of a body implementing m. context class def: visible : set(feature) = if super→isempty() then feature else feature→union(super.visible) endif context expr def: visible : set(feature) = if body→isempty() then parent.visible else body.bodyclass.visible →union(body.sig.param) endif 1) inv uniqueroot: class.allinstances() →select(c | c.super→isempty())→size() = 1 2) context variable inv validvariable: featureclass→isempty() <> method→isempty() 3) context expr inv validexpr: body→isempty() <> parent→isempty() 4) context body inv implementsvisiblemethod: bodyclass.visible→includes(sig) 5) context body inv methodimplementedonce: not bodyclass.body→exists(b | b <> self and b.sig = self.sig) 6,7) context access inv accessesvisiblevariable: visible→includes(refersto) figure 3: ocl constraints for the program graph model m . proc. gt-vmt 2010 4 / 13 eceasst the object constraint language ocl of the uml has been defined for formally defining such consistency conditions [obj06]. figure 3 shows the ocl constraints for program graphs based on the class diagram in figure 2. the derived attributes visible of each class instance contain all features directly defined in the own class together with all visible features of its superclass. these sets, together with all parameters of the implemented method, are propagated to sub-expressions of method bodies. conditions 1–5 are formalized by constraints uniqueroot, validvariable, validexpr, implementsvisiblemethod, and methodimplementedonce, respectively. constraint accessesvisiblevariable formalizes conditions 6 as well as 7. numbers in figure 3 correspond to the ones used above. note that conditions 1–3 require each node, except a unique class node, to be a composite part of exactly one other node. the following observation follows from the fact that compositions cannot form cycles: fact 1 the subgraph p̄ of a program graph p induced by the composition edges is a spanning tree of p; the root of p̄ is a class node. 3 star grammars we first recall many-sorted graphs: definition 2 (graph) let σ = 〈σ̇,σ̄〉 be a pair of disjoint finite sets of sorts. a many-sorted directed graph over σ (graph, for short) is a tuple g = 〈ġ,ḡ,s,t,σ〉 where ġ is a finite set of nodes, ḡ is a finite set of edges, the functions s,t : ḡ → ġ define the source and target nodes of edges, and the pair σ = 〈σ̇,σ̄〉 of functions σ̇ : ġ → σ̇ and σ̄ : ḡ → σ̄ associate nodes and edges with sorts. given graphs g and h, a pair m = 〈ṁ,m̄〉 of functions ṁ : ġ → ḣ and m̄ : ḡ → h̄ is a morphism if it preserves sources, targets and sorts. star grammars are a special case of double pushout (dpo) graph transformation [eept06]. by [dhjm10, theorem 2.8], they are equivalent to hyperedge replacement grammars [dhk97] a well-understood context-free kind of graph grammars. definition 3 (star) we assume that the node sorts contain nonterminal sorts σ̇v ⊆ σ̇ so that the terminal node sorts are σ̇t = σ̇ \ σ̇v. consider a (star-like) graph x , with one center node cx of nonterminal sort x ∈ σ̇v, and with some border nodes (of terminal sorts from σ̇t) so that the edges of x connect cx to some of the border nodes. then x is called an incomplete star named x. an incomplete star is called a star if each border node is incident with at least one edge. an (incomplete) star is straight if every border node is incident with at most one edge. let x denote the class of stars, g (x ) the graphs with stars, and g those without stars (where all nodes are labeled by σ̇t). we assume that nodes of nonterminal sort are not adjacent to each other in any graph. definition 4 (star replacement) an incomplete star rule is written r = l ::= r, where the lefthand side l ∈ x is a straight incomplete star and the replacement (right-hand side) is a graph 5 / 13 volume 29 (2010) meta models versus graph grammars c1 prg : := start c 1 hy c1 hy : := hy ∗ c 1 ccls hy c1 cls : := cls ∗ c 1 fea c1 fea : := var c 1 v c1 fea : := meth ∗ ? c 1 m b v bdy c1 fea : := ovrd c 1 m b bdy b1 bdy : := bdy ∗ b 1 exp x1 exp : := exp x 1 a acc ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ x 1 i inv a1 acc : := acc ? a 1 exp v i1 inv : := call i 1 ∗ m exp figure 4: the rules of the star grammar pt r ∈ g (x ) that contains the border nodes of l. an incomplete star rule is called a star rule if l is a star. the (incomplete) star rule r applies to some graph g if there is a morphism m : l → g, yielding a graph h that is constructed by adding the nodes ṙ \ l̇ and edges r̄ disjointly to g, and by replacing, for every edge in r̄, every source or target node v ∈ l̇ by the node ṁ(v), and by removing the edges m̄(l̄) and the node ṁ(cl). we write g ⇒r h if such a star replacement exists, g ⇒r h if g ⇒r h for some r from a finite set r of (incomplete) star rules, and denote the reflexive-transitive closure of this relation by ⇒∗ r . in the remainder of this section, we consider star rules only; incomplete star rules will only be used as a part of contextual star rules in section 4. example 1 (star replacement) figure 4 shows a set of star rules. the center nodes of stars are depicted as boxes enclosing the star name. nodes with terminal symbols are drawn as circles with their sort inscribed. the replacements of some rules show examples of abbreviating notation for repetitions in graphs and for optional subgraphs, which we will use frequently in star rules. shaded boxes with a “∗” in the top-right corner, like those in rules hy, cls, meth, bdy, and call, designate multiple subgraphs that may occur n times, n > 0, in the graph, with the same connections to the rest. if the shaded box has a “?” in its top-right corner (in rules meth and acc), its contained subgraph may occur 1 or 0 times in the graph. note that this notation is similar to the ebnf notation of context-free string grammars. likewise, it is just an abbreviating notation; one can always replace rules with this notation by several plain star rules using auxiliary stars and recursion, as long as shaded boxes do not include any of their rules’ border nodes. definition 5 (star grammar) γ = 〈g (x ),x ,r,z〉 is a star grammar with a start star z ∈ x . the language of γ is obtained by exhaustive star replacement with its rules, starting from the start star: l (γ) = {g ∈ g | z ⇒∗ r g}. proc. gt-vmt 2010 6 / 13 eceasst example 2 (star grammar for program skeletons) figure 4 shows the star rules generating the program skeletons that underlie program graphs. the rules define a star grammar pt, with the left-hand side of the first rule indicating the start star (named prg). terminal node sorts are abbreviations of the class names in figure 2, e.g., c instead of class. terminal edge sorts are omitted completely. they can be easily inferred from the sorts of the incident nodes. rule exp, which already is a shorthand for two rules, indicated by the two alternative replacements, uses x as border node sort where x stands for b, a, or i. note that this is again just an abbreviating notation. consider rules ovrd, acc, and call, which generate method overriding, variable access, and method invocations. the overridden method, the accessed variable, and the invoked method, respectively, are distinguished by drawing them as filled circles with thick lines. in the skeleton rules, they are created anew. in a correct program graph according to section 2, these distinguished nodes have to be identified (“merged”) with the corresponding nodes that have been created elsewhere by rules var and meth, and represent their declarations. however, identification of nodes cannot be represented by star grammars, but requires contextual star grammars as defined in the next section. pt generates graphs that are closely related to program graphs. given any graph g ∈ l (pt), let gt denote the graph obtained from g by removing all filled nodes and dashed edges from g. let l t(pt) := {gt | g ∈ l (pt)} denote the class of all such graphs. the following fact directly follows from the structure of rules in pt: fact 2 l t(pt) is a language of trees. obviously, grammar pt creates a single root class, and for each class an arbitrary number of subclasses. each class gets arbitrarily many variables, method declarations, and bodies that consist of an arbitrary number of expressions that are either variable accesses or method invocations, consistent with the class diagram in figure 2. apparently, l t(pt) is the language of all trees that fit the class diagram when considering just its composition associations and additionally requiring the conditions 1–3 in definition 1. based on fact 1 we can infer: fact 3 the spanning tree p̄ of each program graph p ∈ p (cf. fact 1) is a member of l t(pt). let l m(pt) denote the language of all graphs that can be obtained from a member of l (pt) by merging each filled node with a corresponding declaration node. let p ∈ p be an arbitrary program graph. its spanning tree p̄ is equal to graph gt of some graph g ∈ l (pt) because of fact 3. p can be obtained by identifying the filled nodes of g with appropriate declaration nodes, i.e., p ∈ l m(pt). on the other hand, it is obvious that each identification of filled nodes with declaration nodes fits the class diagram and conditions 1–3 in definition 1. therefore, each graph g ∈ l m(pt) satisfying conditions 4–7, too, is a program graph. we can summarize: fact 4 the set of all graphs g ∈ l m(pt) that satisfy conditions 4–7 in definition 1 is equal to p. star grammars are context-free in the sense defined by courcelle [cou87]. this suggests that 7 / 13 volume 29 (2010) meta models versus graph grammars their generative power is limited. indeed, we have the following fact 5 there is no star grammar γ with l (γ) = p. proof sketch consider the rule call in figure 4. (the situation is similar for rules ovrd and acc.) this rule generates a new node for a method (drawn filled, and with thick lines). however, for generating a program graph, the rule should insert a call to a method that already exists in the host graph, and may be called in the expression. due to the restricted form of star rules, the method had to be on the border of the rule. since expressions may call every method in the graph, the star rule must have all these methods as its border nodes so that one of them can be selected. however, the number of callable methods depends on the size of the program, and is unbounded. thus a finite set of star rules does not suffice to define all legal method calls. 4 contextual star grammars the adaptive star grammars defined in [dhj+06] overcome the deficiencies illustrated in the proof sketch for fact 5 by allowing the left-hand sides of star rules to adapt to as many border nodes as needed. a further extension, by positive and negative application conditions, extended their power, however with rather complicated rules [hof10]. in this paper, we therefore consider a different extension of star rules with which program graphs can be completely defined in a simple way. we allow that the application of a star rule depends on its context in the host graph. some positive context may be required whereas other, negative, context is forbidden if the rule shall apply. nodes of the positive context may be used by the replacement graph of the rule. definition 6 (contextual star rule) a contextual star rule r has the form r = p/n ≀ l ::= r, where l ::= r is an incomplete star rule, and the positive contexts p as well as the negative contexts n are (decidable) sets of graphs that contain the border nodes of l as subgraph. (note that r is a star rule if l is a star and the sets p and n are empty.) the contextual star rule r applies to some graph g if there is a morphism m : l → g that can be extended to a morphism c → g for at least one positive context c ∈ p (if p 6= /0) and that cannot be extended to a morphism c → g for any negative context c ∈ n, yielding a graph h by applying the incomplete star rule l ::= r to g with morphism m. then we write g c =⇒r h, g c =⇒r h if g c =⇒r h for some r from a finite set r of contextual star rules, and denote the reflexive-transitive closure of this relation by c =⇒ ∗ r . definition 7 (contextual star grammar) γ = 〈g (x ),x ,r,z〉 is a contextual star grammar (csg) with a start star z ∈ x and a finite set r of contextual star rules. the language of γ is obtained by exhaustive application of its rules, starting from the start star: l (γ) = {g ∈ g | z c =⇒ ∗ r′ g}. in the following, we will either enumerate context graphs of the sets p and n of positive and negative contexts, respectively, or we will specify them by path expressions similar to the progres language [sch97]. even more powerful specifications of context graphs are conceivable, e.g., by hyperedge replacement systems, as proposed in [hr10], or by star grammars. but this proc. gt-vmt 2010 8 / 13 eceasst m2 c1 fea : := ovrd c 1 m b bdy p = c c m + 1 2 n = c b m1 2 v2 a1 acc : := acc ? a 1 exp v p1 = a x b c v + + 1 2 p2 = a x b m v + 1 2 m2 i1 inv : := call i 1 ∗ m exp figure 5: the contextual star rules of the grammar pg is not necessary for specifying program graphs. example 3 (contextual star grammar for program graphs) the csg for program graphs contains the star rules start, hy, cls, var, meth, bdy, and exp of pt in figure 4, and the contextual rules in figure 5. in these rules, specifications of positive and negative contexts are drawn below their incomplete star rules. small numbers indicate the correspondence between context nodes and border nodes. so filled nodes in rules ovrd, acc, and call of pt are turned into context nodes in pg. path expressions encode conditions 4–7 in definition 1. a small “+” above an edge represents any path of length > 1. in rule ovrd, the path expression of the positive context p encodes condition 4, i.e., the method declaration must be inherited by the current class, while the negative context encodes condition 5, i.e., the current class must not have a second body for the same method declaration. rule acc does not have a negative context, but two positive contexts. rule acc may be applied either with context p1 or with context p2. p1 and p2 encode conditions 6 and 7, i.e., access to a visible attribute variable and to a visible parameter, respectively. the node labeled x represents a node of any sort. rule call has empty positive and negative contexts and is applicable if its incomplete star rule applies. however, it still is a contextual star rule because its left-hand side requires the existence of an m-node in the context. in figure 6, some steps in the derivation of the program graph in figure 1 are shown. the first graph represents the class hierarchy of the program graph. the grey bubbles in these graphs abstract from parts of the derived graph that are nor relevant for the derivation steps shown. the rule ovrd can be applied to this graph, where we draw the context node filled, with thick lines, and underlay the path leading to it in grey. we use the same drawing convention for the remaining derivation steps using bdy, call, acc, and again acc. the following fact is a direct implication of fact 4: fact 6 l (pg) = p. star grammars can be easily transformed into equivalent hyperedge replacement grammars [dhjm10, theorem 2.8] and vice versa by interpreting stars as hyperedges with nonterminal labels. hence, parsers for hyperedge replacement grammars like the diagen parser [min02] 9 / 13 volume 29 (2010) meta models versus graph grammars c any c cell b m set c recell v cts v n fea v backup c =⇒ ovrd c any c cell b m set c recell v cts v n b v backup bdy c =⇒ bdy c any c cell b m set c recell v cts v n b v backup i a inv acc c =⇒ call c any c cell b m set c recell v cts v n b v backup i a a inv acc c =⇒ acc c any c cell b m set c recell v cts v n b v backup i a a acc c =⇒ acc c any c cell b m set c recell v cts v n b v backup i a a a acc figure 6: deriving the program graph of figure 1 with pg can be used to parse star grammars. the same parser with only slight extensions can also be used for parsing csgs. this parser is outlined below. the parser works on csgs like a cocke-younger-kasami (cyk) parser for string grammars. the csg has to be in chomsky normalform (cnf) so that each production rule is either terminal or nonterminal. the right-hand side of a terminal rule is a terminal graph with only one edge, the right-hand side of a non-terminal rule is the union of two stars. similar to string grammars, each csg that does not produce the empty graph can be transformed into cnf. given a terminal graph g, the parser creates a derivation for g, if it exists, in two phases. the first phase completely ignores contexts of contextual star rules and creates candidates for derivations. the second phase searches for a derivation by checking these candidates, this time considering contexts. in the first phase, the parser builds up n sets l1,l2,...,ln where n is the number of edges in g. each set li eventually contains all stars that can be derived to any subgraph of g that contains exactly i edges. set l1 is built by first finding each embedding of the right-hand side of each terminal rule and adding the star of the corresponding left-hand side to l1. if the corresponding rule is a contextual star rule with an incomplete star as left-hand side, only the (complete) star within the incomplete star is added to l1. the remaining sets are then constructed using nonterminal rules. a nonterminal rule is reversely applied by searching for appropriate stars s and s′ in sets si and s j, respectively. if a nonterminal rule (without considering contexts) is applicable, i.e., if the rule’s right-hand side is isomorphic to the union of s and s′, a new star corresponding to the rule’s left-hand side is added to a set sk. note that k = i + j since each star in a set si can be derived to a subgraph of g with exactly i edges. each instance of the start star z in sn represents a derivation candidate for g. proc. gt-vmt 2010 10 / 13 eceasst the second parser phase checks these derivation candidates by testing for each application of a contextual star rule whether required context has already been created and forbidden context has not (yet) been created earlier in the derivation. the parser stops when it finds the first valid derivation, or when it has checked the last derivation candidate without success. 5 discussion in the previous sections we have used two different techniques to describe program graphs. we have shown that the specification of program graphs by csgs is indeed equivalent to their definition using a model together with ocl constraints. moreover, both approaches allow for automatic checking whether a given graph is a valid program graph. both specifications are actually even more closely related as the following discussion shows. the csg for program graphs consists of (plain) star rules and contextual star rules. as described by fact 2, the tree structure (made from composition links) of program graphs can be constructed by (plain) star rules. plain star grammars, however, fail for links refersto and call, i.e., those program graph edges that represent references to objects that are located “far away” in the program structure. contextual star rules are needed to add those edges; the far away objects are represented by the rules’ context nodes (figure 5). the positive and negative contexts of those rules play the same role like the ocl constraints for conditions 4–7 in figure 3. these constraints actually can be considered as an ocl implementation of the rules’ context conditions. e.g., constraint methodimplementedonce for condition 5 in definition 1 prohibits a second body of the same method within the same class; this exactly corresponds to the negative context n of rule ovrd (figure 5). the path expressions p, p1, and p2 of rules ovrd and acc, respectively, realize conditions 4, 6, and 7. their ocl realizations make use of the derived attributes visible whose recursive definition exactly reflects the iteration operator “+” in the path expressions. the contextual star grammar pg (figure 4 and 5) for program graphs has been created by hand. the discussion, however, has revealed a close relation between ocl constraints and positive as well as negative contexts on the one hand, and between class diagram and contextual star rules without those contexts on the other hand. this close relation may lead to a procedure for translating csgs and meta models with ocl constraints into each other at least in a semiautomatic way. this line of research is also motivated by work of ehrig et al. [ekt09]. they create graph transformation rules with graph constraints from meta models with ocl constraints. the graph transformation system is then used to automatically generate model instances of the meta model. however, they only consider very restricted ocl constraints that are not sufficient for the specification of program graphs, and their generated layered graph transformation rules are rather complicated, and are less suited for parsing. 6 conclusions we have extended star rules by positive and negative context. these contextual star grammars allow to define program graphs precisely, without sacrificing parseability. program graphs, which represent certain aspects of object-oriented programs, can also be defined by a class diagram together with ocl constraints in a model-based style. however, this approach is less suited 11 / 13 volume 29 (2010) meta models versus graph grammars for inductive proofs or for automatic instance generation than the proposed grammar-based approach. a comparison of both specification approaches, however, has shown close relations between both specification approaches which may allow for a semi-automatic translation process between both specification approaches. this will be subject of future work. too many kinds of graph grammars are related to contextual star grammars to mention all of them. so we restrict our discussion to those that aim at similar applications. contextual star rules re-use path expressions first devised by m. nagl [nag79], which have later been implemented in the progres graph transformation language [sch97]. using context conditions and examining their relation to logical graph properties and constraints is not new either. a. habel and k.-h. pennemann have shown that nested graph conditions are equivalent to first-order graph formulas [hp09]. these conditions are still too weak to specify program graphs, as they only allow to require or forbid the existence of subgraphs of bounded size. only in [hr10], a. habel and h. radke devised nested graph conditions with variables that allow to express the conditions of csgs (and more). however, rules and grammars using such conditions are not yet considered in that paper. context-embedding rules [min02] extend hyperedge replacement grammars by rules that add a single edge to an arbitrary graph pattern. they are used to define and parse diagram languages, but are not powerful enough to define models like program graphs. graph reduction grammars [bpr10] have been proposed to define and check the shape of data structures with pointers. while the form of their rules is not restricted, reduction with them is required to be terminating and confluent, so that random application of rules provides a backtracking-free parsing algorithm. it is still open whether graph reduction grammars suffice to define program graphs. the nested patterns [hjg08] recently introduced to grgen [gbg+06], an efficient graph rewrite tool, allow to express nested graph conditions with variables that are defined by hyperedge replacement systems, and can thus be used to implement contextual star grammars (like that for program graphs) in the future. acknowledgements: we thank the reviewers for their constructive criticism that helped to improve our paper. bibliography [bpr10] a. bakewell, d. plump, c. runciman. specifying pointer structures by graph reduction. mathematical structures in computer science, 2010. to appear. [cem+06] a. corradini, h. ehrig, u. montanari, l. ribeiro, g. rozenberg (eds.). 3rd int’l conference on graph transformation (icgt’06). lecture notes in computer science 4178. springer, 2006. [cou87] b. courcelle. an axiomatic definition of context-free rewriting and its application to nlc rewriting. theoretical computer science 55:141–181, 1987. [dhj+06] f. drewes, b. hoffmann, d. janssens, m. minas, n. v. eetvelde. adaptive star grammars. pp. 77–91 in [cem+06]. proc. gt-vmt 2010 12 / 13 eceasst [dhjm10] f. drewes, b. hoffmann, d. janssens, m. minas. adaptive star grammars and their languages. theoretical computer science, 2010. accepted for publication. [dhk97] f. drewes, a. habel, h.-j. kreowski. hyperedge replacement graph grammars. chapter 2 in [roz97]. [eept06] h. ehrig, k. ehrig, u. prange, g. taentzer. fundamentals of algebraic graph transformation. eatcs monographs on theoretical computer science. springer, 2006. [ekt09] k. ehrig, j. m. küster, g. taentzer. generating instance models from meta models. software and system modeling 8(4):479–500, 2009. [er97] j. engelfriet, g. rozenberg. node replacement graph grammars. chapter 1 in [roz97]. [gbg+06] r. geiß, g. v. batz, d. grund, s. hack, a. szalkowski. grgen: a fast spo-based graph rewriting tool. pp. 383–397 in [cem+06]. url: http://www.grgen.net. [hjg08] b. hoffmann, e. jakumeit, r. geiß. graph rewrite rules with structural recursion. in mosbah and habel (eds.), 2nd intl. workshop on graph computational models (gcm 2008). pp. 5–16. 2008. [hof10] b. hoffmann. conditional adaptive star grammars. electr. comm. of the easst, 2010. to appear. [hp09] a. habel, k.-h. pennemann. correctness of high-level transformation systems relative to nested conditions. mathematical structures in computer science 19(2):245– 296, 2009. [hr10] a. habel, h. radke. expressiveness of graph conditions with variables. in ehrig and ermel (eds.), international colloquium on graph and model transformation (gramot’10). 2010. to appear in electr. comm. of the easst. [medj05] t. mens, n. v. eetvelde, s. demeyer, d. janssens. formalizing refactorings with graph transformations. journal on software maintenance and evolution: research and practice 17(4):247–276, 2005. [min02] m. minas. concepts and realization of a diagram editor generator based on hypergraph transformation. science of computer programming 44(2):157–180, 2002. [nag79] m. nagl. graph-grammatiken: theorie, anwendungen, implementierungen. vieweg-verlag, braunschweig, 1979. in german. [obj06] object management group. specification of the object constraint language. http://www.omg.org/spec/ocl/2.0/, 2006. [roz97] g. rozenberg (ed.). handbook of graph grammars and computing by graph transformation, vol. i: foundations. world scientific, singapore, 1997. [sch97] a. schürr. programmed graph replacement systems. chapter 7 in [roz97]. 13 / 13 volume 29 (2010) http://www.grgen.net http://www.omg.org/spec/ocl/2.0/ introduction graphs representing object-oriented programs star grammars contextual star grammars discussion conclusions microsoft word oclapps06_preface.doc electronic communications of the easst volume 5 (2006) guest editors: dan chiorean, birgit demuth, martin gogolla, jos warmer managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 proceedings of the sixth ocl workshop ocl for (meta-)models in multiple application domains (oclapps 2006) preface dan chiorean, birgit demuth, martin gogolla and jos warmer 1 page eceasst 2 / 2 volume 5 (2006) preface dan chiorean, birgit demuth, martin gogolla and jos warmer conceived as a formalism meant to support unambiguous and detailed modeling using uml (unified modeling language), ocl (object constraint language) needs adaptation to changes expressed in the modeling community. the requirements that the modelers want to see supported today by ocl go far beyond its initial requirements. the advent of the mda (model driven architecture) vision and the rapid acceptance of mde (model driven engineering) approaches emphasize new application domains (like semantic web or domain specific languages) and call for new ocl functionalities. apart from the requirements asked by application domains, technologies, visions and paradigms used in modeling, the formalisms and techniques currently used have to support development of large scale applications. therefore, efficiency represents another important feature that tools supporting ocl must provide. the ocl is required to ensure a fine balance between the use of language in specifying models realized in early life-cycle phases and the rigor asked by the strong relationship with formal languages. fixing ambiguities reported from the ocl specification without affecting the above mentioned balance is also important. today, promoting ocl needs a conjoint support from both the research community and the industry. the main target of the oclapps 2006 workshop was to organize a debate forum joining people from research and industry able to present an updated state of the art in this domain, to contribute to the ocl dissemination and use. the workshop was organized as a part of models/uml 2006 conference in genova – italy, continuing the series of ocl workshops held at previous uml/models conferences in: york (2000), toronto (2001), san francisco (2003), lisbon (2004) and montego bay (2005). this eceasst volume contains 10 improved and extended papers out of the 18 papers already published in the workshop proceedings as a technical report of technische universität dresden. we are grateful to authors for their effort to improve and polish the versions presented, according with the feedback received and the workshop discussions. last but not least, we are grateful to the members of the program committee and to the eceasst redactors for their support. december 2006 dan, birgit, martin and jos verified visualisation oftextual modelling languages electronic communications of the easst volume 36 (2010) proceedings of the workshop on ocl and textual modelling (ocl 2010) verified visualisation of textual modelling languages fintan fairmichael and joseph r. kiniry 18 pages guest editors: jordi cabot, tony clark, manuel clavel, martin gogolla managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst verified visualisation of textual modelling languages fintan fairmichael1 and joseph r. kiniry2 university college dublin, ireland1 it university of copenhagen, denmark2 abstract: many modelling languages have both a textual and a graphical form. the relationship between these two forms ought to be clear and concrete, but is instead commonly underspecified, weak, and informal. further, processes and tool support for modelling often do not treat both forms as first-class citizens, instead choosing to favour one as the “real” representation and the other as a derivable representation. as textual and graphical forms have their individual strengths and weaknesses, ideally one should be able to view and edit a model in whichever form is most desirable at the moment. furthermore, we should be able to do so without having to worry about semantic differences between what is seen in a graphical view versus what is seen in a textual view. if we are to develop tools that allow dual-editing— simultaneous editing of both the textual and graphical forms—then it is essential that their relationship is clearly and precisely defined. this paper details a formal relationship between the textual and graphical forms of a high-level modelling language called the business object notation (bon). we describe the semantics of the graphical and textual representations and the relationship that holds between them. we also formally define a view on an underlying model as an extraction function, and model diffs as a means of tracking changes as a model evolves. this theoretical foundation provides a means by which tools guarantee consistency between textual and graphical notations, as well shows how to efficiently perform model updates, reason about model views, and interpret properties between modelling perspectives. keywords: textual modelling, graphical modelling, consistency, formalisation 1 introduction a wide variety of modelling languages and tools are now available to developers. for those languages that have both graphical and textual representations, it is essential that these are consistent such that the text that appears in the textual form and the dots, lines and shapes that are drawn for the graphical form are semantically equivalent or consistent. the specification of the relationship between the textual and graphical forms of a modelling language should be more than the reference implementation of a tool that converts from one to the other. edits to either representation change the underlying model in some fashion, and a corresponding edit should be applied to the other representation. for instance, when we draw a new class a 1 / 18 volume 36 (2010) verified visualisation in our graphical editor, a class a should also be added to our text, and vice versa. it is crucial that both forms are updated accurately and kept in sync. if no synchronisation guarantees are made, then the model a user is viewing in one or other representation may not be accurate, leading to a plethora of potential issues as development continues. frequently, each form represents a different subset of the overall model. for example, the object constraint language (ocl) for uml has no graphical representation. ocl annotations are simply encoded in uml diagrams using unstructured notes or semi-structured stereotypes. similarly, most graphical forms contain some layout information that is not expressed in the corresponding textual notation. since we are concerned with the interrelationship and interactions of the two formats, in these cases we simply consider the subset of each form that is relatable, as the matter of maintaining this extraneous information is one of careful engineering. by formalising the textual and graphical models of bon, and the relationship between them, we provide a precise notion of consistency between these two representations. by also formalising the notion of a view on a model, we are able to examine some common views, how they relate to the original model, and their translation from one representation to another. before looking in detail at this formalisation, we first discuss our modelling language of choice, bon. 1.1 bon the business object notation (bon) was developed from within the eiffel community, back in the late 1980s and early 1990s, as a descriptive method that addresses both analysis and design issues [ner92]. in fact, much of its syntactical style is inherited from the eiffel programming language. bon has two levels, which are loosely referred to as the informal and formal levels. diagrams at the informal level are comprised of natural language, written in a highly structured manner. at the formal level we have dependent types, including behavioural contracts on features1 (preconditions/postconditions) and classes (invariants). inheritance (with generics and multiple superclasses) and client relations (associations and aggregations) are also expressed at the formal level. classes are hierarchically arranged in clusters, which are structures that simply group together one or more classes and/or clusters. clusters are similar to packages in java, except without the additional effects on visibility that packages exert. a well-formed model in bon must have a single top-level cluster—the system cluster. classes and clusters are described in the static part of a bon model, but there are also dynamic diagrams that allow one to describe events and scenarios over the static system. in this work we are concentrating on the static and formal parts of bon, although broadening it to cover the entire modelling language is a natural extension. bon models have both a textual and a graphical form, with a one-to-one structural mapping between them. the bon authors also describe interesting views on models, through the use of compressions—representing a set of graphical or textual elements with a simpler element [wn95]. this is standard practice in many graphical systems as a user zooms out, and similar techniques are employed through outline views and folding for textual editors. however, 1 features in bon can be thought of as methods or fields, but are more general than these and can potentially be refined to either when creating an implementation from the model. proc. ocl 2010 2 / 18 eceasst when dealing with a modelling language, the meaning of these simpler elements is important in the context of the elided elements that they represent. it is made all the more interesting in bon, as we can write and display relationships between clusters, as an abstraction from the underlying classes upon which the relationships really exist. we discuss this further in section 3.3.3. static_diagram example component cluster example_components component class a feature name: string set_name: void -> n:string require x.is_valid_identifier(n) end end class b inherit a end class c inherit b end class d inherit b end b client utilities.x end cluster utilities component class x feature is_valid_identifier: boolean -> id:string end end end listing 1: a static diagram in textual bon listing 1 shows an example of a textual bon model, which contains several classes linked through inheritance and a single client relation. the same model represented in graphical bon is shown in figure 1. 1.2 tools 1.2.1 bonc we have previously developed a parser, typechecker and documentation generator for bon, the bonc tool.2 it is open source, and available as a command line tool or as an eclipse plugin. we have used bonc as a foundation for a number of projects, including a model-code consistency checker and the bon ide. 2 available from http://kind.ucd.ie/products/opensource/bonc/ 3 / 18 volume 36 (2010) http://kind.ucd.ie/products/opensource/bonc/ http://kind.ucd.ie/products/opensource/bonc/ verified visualisation figure 1: graphical bon. proc. ocl 2010 4 / 18 eceasst 1.2.2 bon ide we have recently developed a prototype visual editor for bon, built on top of the eclipse platform, leveraging the eclipse graphical modeling project (gmp) tools [ski10]. a bon metamodel is defined using the eclipse modeling framework project (emf) ecore metamodel. defining the bon metamodel as an ecore model empowers the use of the eclipse gmp and graphical editing framework (gef) to aid in the development/generation of tools for manipulating graphical bon. the culmination of these efforts is a graphical editor for bon— the bon ide. the screenshot previously shown in figure 1 is taken of the bon ide in action. the bon ide checks the validity of a graphical bon model through constraints expressed in the ecore metamodel, with additional validity expressions written in the check language (part of the model to text (m2t)3 project). the remainder of this paper is organised as follows. the next section describes the formalisation of graphical and textual bon models, the translation between these, as well as views on a model. section 3 discusses some uses of our setup, in particular tracking model evolutions and keeping models synchronised. we next discuss related work, before finally drawing conclusions about the current state and future directions of this work. 2 model formalisation we have mechanically formalised our textual and graphical models in higher-order logic using the pvs specification and verification system [ors92]. much of the formalisation is presented here in standard mathematical syntax (i.e., the reader need not be familiar with pvs to understand our theory), but several small examples of pvs are given as well to concretise our mechanisation. the motivated reader is welcome to download the full mechanisation via our website.4 pvs provides an interactive proof checker for proving the correctness of theorems as well as type-correctness of the input specifications. by mechanising our theory in pvs we are able to assert desirable properties of our specification in a manner that is easily independently verified by others. 2.1 graphical formalisation due to our use of the eclipse modeling framework [the10] it was first necessary to describe the core ecore types, and their type hierarchy. the relevant parts of this type hierarchy are depicted in figure 2. bon types are defined as subtypes of the relevant ecore constructs, summarised in figure 3. a formal definition of several elements of this type hierarchy are necessary. types that are not mentioned below have mechanisations but are irrelevant to the focus of this paper. definition 1 (basic constructs) a system is a bon model instance. a class is a named concept or idea in a system. a cluster is a named set of classes and sub-clusters. every system has exactly one cluster denoted as the system cluster. 3 http://www.eclipse.org/modeling/m2t/?project=xpand 4 available from http://kindsoftware.com/documents/mech theory/verified vis.html 5 / 18 volume 36 (2010) http://www.eclipse.org/modeling/m2t/?project=xpand http://kindsoftware.com/documents/mech_theory/verified_vis.html http://www.eclipse.org/modeling/m2t/?project=xpand http://kindsoftware.com/documents/mech_theory/verified_vis.html verified visualisation eobject emodelelement egenerictype eannotation efactory enamedelement eclassifier etypedelement etypedparameter eenumliteral epackage eclass edatatype eenum estructuralfeature eparameter eoperation eattribute ereference figure 2: ecore type hierarchy. eclass abstraction model staticabstraction cluster bonclass staticrelationship feature indexclause inheritanceclause featureargument precondition postcondition invariant inheritancerel clientsupplierrel aggregationrel associationrel relationshiptype eenum implementationstatus figure 3: bon graphical model type hierarchy. proc. ocl 2010 6 / 18 eceasst we denote classes with the metavariable c , clusters with d, and the system cluster as s . functions on classes and clusters exist for extracting the relevant attributes (e.g., identifier, list of features, etc.), but are not discussed further here. informally, a bon model consists of a set of classes, a set of clusters, and a set of relations between these classes and clusters. the general idea is that inheritance relations define the subtyping relations between classes, cluster relations give the clustering structure of the system, and client relations state dependencies between the classes in the system. each of these constructs, in turn, is formalised in the following. the inheritance, cluster, and client relations of a system are all dependently typed directed graphs (“digraphs” within pvs). an inheritance graph is more precisely a tree of bonclasses, rooted with the any class.5 definition 2 (inheritance tree) an inheritance tree is a (directed) tree whose vertices are elements of the type bonclass and whose root is the bonclass any. this definition is expressed in pvs in the following fashion. any: bonclass i n h e r i t a n c e t r e e : type = { t : t r e e [ bonclass ] | r o o t ? ( t ) ( any) } this pvs specification states that the constant any is of type bonclass and the simple dependent type inheritance tree is a tree of bonclasses whose root vertex is any. a cluster graph is also a tree, with the system cluster at its root. since staticabstraction is subtyped by both the cluster and bonclass types, we thus use staticabstractions as the vertex type in our cluster tree. definition 3 (cluster tree) a cluster tree is a directed tree ct of staticabstractions where the root of ct is the system cluster, and every non-root vertex in ct has exactly one cluster as its parent. the last condition within this definition is necessary to insist that only clusters may contain other static abstractions (i.e., classes must be leaf vertices within the cluster graph), and every static abstraction is directly contained within one cluster (except the system cluster). definition 4 (client graph) a client graph is a directed graph of bonclasses. each edge in the graph is a client relation. note that, as no further constraints are placed on the client graph, cycles are permitted—as would be expected for client relations. a bon model is comprised of an inheritance tree, a cluster tree and a client graph. additionally, all classes in the system must appear as vertices in both the inheritance tree and the cluster tree, and no other classes may appear in the client graph. the metavariable used to denote a bon model is m . 5 any is the top-most type in bon. 7 / 18 volume 36 (2010) verified visualisation definition 5 (bon model) a bon model is a record [it , ct , cg] where: • it is an inheritance tree, ct is a cluster tree, and cg is a client graph, • the set of bonclasses that are vertices in ct must be equivalent to the set of vertices in it , • and the set of bonclasses that are vertices in cg must be a subset of those appearing in ct /it this definition is expressed within pvs by declaring the record type and a predicate that determines if such a record meets the latter two criteria above. the bon model type is then the subset of these records that satisfies this predicate. b o n m o d e l r e c : type = [ # i t : i n h e r i t a n c e t r e e , c t : c l u s t e r t r e e , c g : c l i e n t d i g r a p h # ] bon model ? (m: b o n m o d e l r e c ) : b o o l = v e r t (m‘ i t ) = c l a s s v e r t (m‘ c t ) and s u b s e t ? ( v e r t (m‘ c g ) , v e r t (m‘ i t ) ) bon model : type = ( bon model ? ) 2.2 textual formalisation bon textual models are represented as a type context. classes are stored in the type context in a partial function from a formalclasstype to a formalclassdefinition. the function is partial, as it only returns a class definition when such has been given in the system and stored in the type context. asking for the definition of a class type that is not present in the type context returns bottom.6 the metavariables ct and cd denote formalclasstypes and formalclassdefinitions, respectively. a formalclasstype contains the identifier that denotes the class in question and a list of generic parameters for the type it represents. the type function extracts the type from a given class definition: type : cd → ct . definition 6 (class definition map) a class definition map cdm is a partial function def : ct ′ → cd where: • ct ′ is a subset of ct and • ∀ct′ ∈ ct ′ : type(de f (ct′)) = ct′. 6 in a partial function in pvs the function returns bottom when the function is undefined for the input. proc. ocl 2010 8 / 18 eceasst the second condition in this definition ensures that class types are only mapped to class definitions that actually have the type in question. clusters are similarly stored in a partial function from formalclustertype to formalclusterdefinition. we omit the precise definition for brevity. typerelationpairs are used to represent the various relations between types in a system with subtypes inheritancerelation, clusteringrelation and clientrelation. in our pvs mechanisation typerelationpair is an abstract datatype with these three subtypes.7 using all of this mathematical infrastructure, one can now define bon textual type contexts. definition 7 (type context) a bon textual type context is a record [cdm , cldm , s, r ] where cdm is a class definition map, cldm is a cluster definition map, s is the system cluster type, and r is a set of typerelationpairs. as usual, the metavariable γ denotes a bon textual type context, and the sentence γ ` � indicates that γ is well-formed. type contexts are created and reasoned about with a standard suite of operations that guarantee they remain well-formed and consistent. as is normal, our formalisation of type contexts only permits types (i.e., classes and clusters) to be added to the context, not removed, at this time. 2.3 relating textual and graphical formalisations next comes the meat of the matter: relating the theory of textual bon to the theory of graphical bon. the key idea here is that one incrementally defines a semantics-preserving bijective function, called a model interpretation, that maps from a well-formed textual type context to a well-formed graphical type context. as the function is bijective, it implicitly defines an equivalence class between (pairs of elements in) the contexts, and hence between contexts’ contents (classes and clusters). moreover, since the interpretation is semantics-preserving, any property proven about constructs at one end of the interpretation can be “pushed” through the interpretation to its other end. providing the details of this interpretation is beyond the scope of this paper. the interested reader should obtain the pvs source and look, in particular, at the theory viz to typesystem. this theory contains about a dozen critical lemmas, of which we have mechanically proven half at this time, and sketched out proofs of the other half by-hand. commonly, one only defines this kind of interpretation as a model relation; but, as we have carefully crafted the theories at both ends of the relation, we have also defined “executable” interpretation functions that go “both ways,” from graphical to textual and vice versa. mathematically, this is unsurprising and not necessarily terribly useful. but practically, the existence of these functions is extremely useful, as any well-formed type context created with a tool realising either side of the relation (i.e., whether a developer draws a picture or writes a 7 abstract datatypes in pvs automatically generate additional axioms. this includes an axiom that each type must be one of its subtypes (inclusive) and an axiom that the subtypes do not overlap (disjointness). these properties are especially useful for case analysis. 9 / 18 volume 36 (2010) verified visualisation textual specification that describes a system) can be interpreted into the dual semantic domain. performing the defined conversion in pvs involves applying the relevant functions to rewrite a model from one representation to another. as such, the conversion scales to large models, although the number of intermediate steps in the conversion may grow with the model size. a textual specification is “rendered” into a graphical specification, and it is guaranteed that all properties of the textual specification are captured in the graphical specification. likewise, a graphical specification is “pretty-printed” into a textual specification, and the same semantic guarantees hold. finally, the relation itself is useful as it permits one to check that two specifications, graphical and textual, are consistent with each other and if one is a refinement of the other. definition 8 (consistent models) a (graphical) bon model m is consistent with a (textual) type context γ iff there exists a quintuple of maps between classes, clusters, systems, and relations that are bijections. we write m ∼= γ if this is the case. definition 9 (refinements as submodels) a model m is a refinement of a type context γ iff there exists a quintuple of maps between classes, clusters, systems, and relations from m to γ are surjections. we write m a γ if this is the case. this definition is symmetric. now that we can compare textual and graphical specifications, and understand what it means to refine between them, we must reflect on the kind of operations that we can perform to either end of the interpretation, and what each of those operations means in the dual domain. the first operation of interest is views, as it is not always the case that one wishes to render an entire graphical model. 2.4 views we can informally define a view as the display of a subset of the elements (classes, clusters, relations) in a model. in order to formally define a view, we first define the type of a (generic) model view. a model view is a “slice” of a model amenable to visualisation. as our models have three components—inheritance and cluster hierarchies and a client relation graph—a view slices through all three components. definition 10 (bon model view) a bon model view for a bon model [it , ct , cg] (recall definition 5) is a record [it v, ct v, cg v] where it v is a (possibly empty) subgraph of it (resp. ct v and ct , and cg v and cg ). the metavariable we use for the bon model view type is v , and we denote the corresponding relation as 6 : m ×v . a relation is expressed in pvs in one of several ways. we have chosen to formalise this relation as a (curried) function with a codomain of type boolean.8 the definition is based upon a 8 in pvs, the declaration of a function f of type a×b → c is denoted as f(a,b):c, in which case any use of the function must include all parameters; whereas a curried function type a → (b → c) is denoted f(a)(b):c. the latter allows for partial application yielding a new function of type b → c. as relations can be represented as a × b → b, if we use the curried form we can, through partial evaluation, obtain a predicate on the type b. proc. ocl 2010 10 / 18 eceasst case distinction on all subtypes of v . the function type definition in pvs is shown below. bon model view ? (m: bon model ) ( v : b o n m o d e l v i e w r e c ) : b o o l using a curriable representation enables us to define a type for all legal views of a given model. we do so by defining a dependent type of a view function that takes a bon model and returns a valid view for the given model. definition 11 (the view type) the view type vm is a function type dependent upon a model m and is of type m : m → (v : v |m 6 v). such a dependent type is realised in pvs by the following type declaration. note that the codomain is the type of all views on m. v i e w : type = [m: bon model −> ( bo n model view ? (m ) ) ] 3 uses 3.1 model evolution as models change over time, keeping track of those changes and maintaining the consistency of the graphical and textual forms is crucial. we will first define a few relevant functions on graphs, leading up to a definition of a diff on a pair of bon models. definition 12 (graph merge) a graph merge is a function gm : g ×g → g that produces a graph that contains a union of the vertices and edges from the two input graphs. the difference of two graphs is a new graph with vertices as the difference of the two input graphs’ vertices, and edges as the difference of the two input graphs’ edges. definition 13 (graph difference) a graph difference is a function gd : g ×g → g , such that the resultant graph contains all the edges and vertices that are contained in the first of the input graphs, but not in the second. a model difference record, md, is a record [it d, ct d, cg d] where it d is a directed graph of bonclasses, ct d is a directed graph of staticabstractions and cg d is a directed graph of bonclasses. model difference records are used to store the output of a model difference. definition 14 (model difference) the model difference function difference : m ×m → md creates a record containing the graph differences of each of the constituent graphs of the input models. a model difference gives us what was present in the first model and not in the second—i.e., the elements that are removed when translating from the first model to the second. however, we consequently, since pvs uses predicate subtyping in hol, this partial application denotes a new subtype of b. 11 / 18 volume 36 (2010) verified visualisation also need to know what was present in the second model but not in the first (the elements that were “added”). definition 15 (model diff) the model diff function for input models m1, m2 produces a record [add,rem], where add = difference(m2,m1) and rem = difference(m1,m2). this is akin to the diff file comparison utility that represents the changes between two files through the parts that are added and the parts that are removed. we now define a diff application function for bon models that “applies” a diff to a given model. definition 16 (model diff application) the model diff application function apply diff : m × md → m creates a new model produced by adding all elements in the add field of the model diff and removing all elements in the rem field. technically the output of a model diff application is a bon model record, as the diff used might produce an invalid bon model. in pvs this means that we produce a bon model rec that does not necessarily satisfy the predicate bon model?. we could of course define a predicate that tells us if a given input model and model diff would produce a valid model through apply diff, but this is not likely to be more useful than simply applying the diff and then seeing if the result is a valid model. one essential property of the apply diff and diff functions is that apply diff (m1,diff (m1,m2)) = m2 that is, if we take the diff of two models, and apply this diff to the first of those models we should produce the second model. this property is intuitive from the understanding that a diff describes the changes that must be made to the first input model to produce the second. it is possible to define a bijective translation of the bon graphical model diff to a (similarly defined) textual diff that operates on the bon textual model, allowing updating of the textual model from the graphical model (and similarly the graphical model from the textual model) by computing the diff for the changes, translating this diff and applying it to the textual model. this removes the need to translate the full model every time we want to synchronise our two model forms. 3.2 chasing refinements given the relation and functions defined in section 2.3, there are a number of interesting properties we can “push” between worlds. in essence, much like in theoretical physics and other branches of mathematics involving symmetries, sometimes it is easier to state or reason about a property in one theory than another. we propose taking advantage of this situation in a few novel ways, though we summarise only a few here due to space reasons. note that we have not mechanised any of these ideas as of yet, nor have any been implemented in our toolset in a fashion that reflects our formalisation. proc. ocl 2010 12 / 18 eceasst 3.2.1 the right tool principle certain activities, like brainstorming or sketching out an architecture, are often better accomplished in one tool (e.g., a graphical model editor, like the bon ide) than another. since an interpretation exists between domains, generating a complete, human-readable, consistent textual specification from a “sketch” of a system is trivial. we call this idea “the right tool” principle—one should not be prevented from using the right tool for the job and one should be able to leverage such work in both domains. 3.2.2 difficult properties at first blush, the idea of a well-formed graphical model seems simple enough. but we found encoding such in a framework as complex as the emf+gef to be fraught with peril. on the other hand, defining such a property in the textual model is a straightforward proposition. consequently, we do not bother attempting to specify complete and complex well-formedness conditions on a graphical model, we simply translate from the graphical to the textual and check well-formedness there. 3.2.3 axiomatic properties axiomatic properties like well-formedness are delicately realised in textual and graphical tools. when should such properties hold, and when must they hold? in our experience, too many tools, especially those with formal underpinnings, improperly force consistency-like properties. for example, many modern compilers are able to successfully compile erroneous programs by making assumptions about developer intent and performing runtime error correction of the input program. of course, they issue warnings in such cases, but overall this behavior makes the tools easier to use and more robust. the java compiler included with the eclipse ide is an excellent example. eclipse can perform type-completion and summarise a class in the outline view even if the program code in the editor is not type-correct. as another example, while using a tool like the bon ide, often it is not just useful, but is necessary to draw an inconsistent or ill-formed model. perhaps such happens during brainstorming; perhaps in a few more steps the model will be consistent again; perhaps the designer is modelling an existing system which, by virtue of its very definition, is inconsistent in the first place. by formally defining such properties on either side of the interpretation and understanding precisely when reasoning infrastructure depends upon their validity, we are able to characterise how and when to enforce them. within pvs we realise such a theoretical trick by putting properties that are strictly necessary for reasoning within the definitions of our predicate types, while those that are optional are encoded as axioms or lemmas. if a definition of a formula f that is used to reason about a model, or proofs relating to such a formula, does not involve a given axiom or lemma p, then we know f and p to be independent, and as such is optional. 3.3 views the simplest and least interesting views are of course the empty view, where none of the model elements are displayed, and the full view, where all elements of the model are displayed. this 13 / 18 volume 36 (2010) verified visualisation figure 4: code folding in the eclipse java editor. section discusses a couple of more interesting views commonly provided for textual models, and explores what should happen to relationships involving elements that are hidden in a view (i.e., present in the original model, but not in the view). 3.3.1 outline view outline views of textual modelling languages typically give a hierarchical view of the principal elements in the model. it is clear that an outline view is indeed a view, under our definition, since the hierarchies in question are present in the original model. outline views are less common for graphical editors, but the principle remains the same and can be provided in a similar manner. 3.3.2 folding another common feature with modern textual editors is folding. this is where a large, multi-line element can be collapsed in the view to a single line. for instance, a class definition that normally spans dozens of lines can be collapsed to just one line. typically a small graphical widget in the left margin of the line denotes the folding state of an element, as well as to function as a button for the fold and unfold operations. an example of code folding in the eclipse java development tools (jdt) source editor is shown in figure 4. here a method body (lines 8–13) has been hidden from view, with graphical artifacts to indicate this to the user. collapsing or restoring a foldable element are relatively straightforward alterations to the view on a model. when an element is collapsed, the view has been altered so that sub-elements in the hierarchical structure of the original model are ellided from the view. 3.3.3 relationships involving hidden elements folding is related to compression in bon, as previously discussed in section 1.1. when one performs folding, compression, or some other view adjustment where model elements are being hidden as a means of providing a simplified or abstracted view of the system, it raises an interesting question as to what should happen to the relationships that exist between model elements that are hidden. in the case where model elements are hidden because they are not relevant, then of course no relationships involving these elements should appear in the view. consider the specific example of views to visualise the dependencies that exist in a system. client relationships are expressed between classes, and in our definition of a view no relationships can appear involving a class that is not present in the view—since a relationship is an edge in a graph, we cannot have an edge involving a non-existent vertex. however, a view that showed the dependencies that exist between clusters that did not contain the clutter of the underlying classes would be useful. the client relationships are “pulled up” in the clustering hierarchy proc. ocl 2010 14 / 18 eceasst figure 5: graphical bon compression example (from [wn95]). to appear at the cluster level. it is this type of view that the bon authors were keen to support. figure 5 shows a simple example of an inheritance relationship that has been abstracted from the underlying classes b, c, d, e, to their containing cluster children. how to amend our definition of a view of a model, such that it can accommodate this “pulling up” of relationships to higher-level abstractions, is an ongoing research question for us. 4 related work there is a great abundance of related work on modelling languages and tools that deal with textual and graphical representations, so we will only briefly mention a few of those that are relevant. lancaric et al. developed a case tool for bon that supported drawing and editing of graphical bon class diagrams (static) and dynamic diagrams [lop02, pkol02]. the graphical representation they used largely followed that originally set out by walden and nerson. skeleton code generation is possible to the target languages of eiffel, java with jml, and textual bon. importing existing bon models is not supported, so round-tripping during development is not possible. goguen’s early work on formal semiotics [gog99] and feferman’s work on reasoning with diagrams [fef10] has been inspirational to our work. both researchers argue, in essence, that only by connecting the formal world (of which computing, and thus system design, is definitely one of the most complex examples thereof) with a grounding in social reality via semiotics, or the general theory of signs, can one effectively communicate complex constructs in effective ways. moreover, proofs appealing to diagrams and other semiotic constructs are ubiquitous in geometry, number theory, and especially category theory. uml-b is a profile of uml, which defines a subset and specialisation of uml that has a mapping to, and is therefore suitable for, translation into the (textual) b language [sb06]. although an equivalency of uml features to b structures is defined, this work is differentiated by the fact that uml-b operates across two very disparate modelling languages. the alloy analyzer [jac02] tool contains a visualiser for graphically displaying alloy models. 15 / 18 volume 36 (2010) verified visualisation however, the graphical form is not editable so synchronisation of the graphical with the textual formats is simply a matter of updating the visualiser with the current version of the textual model. uml2alloy [abgr07] defines a profile of uml (and ocl) suitable for translation to alloy, and translates an xmi representation (exported from argouml) of a uml model from this profile to an alloy textual model for analysis. again, this process is in one direction—from graphical uml to textual alloy. our description of model diffs is related to the work of alanen and porres [ap03], although our definitions are simpler as we operate on graph structures and treat a change to a class or cluster (a vertex/node) as the removal of the old version and the insertion of the new. modern eclipse platform projects provide powerful tools for creating textual and graphical editors. the xtext project focuses on supporting the development of textual editors and integrates with the eclipse modeling framework. thus, a modelling language textual editor built on top of xtext can integrate with graphical modelling tools built using the eclipse graphical editing framework. model edits are represented through eclipse model transactions and these can be used to keep the graphical and textual models synchronised. paige and ostroff previously developed a formally specified metamodel for a subset of the bon language [po01]. two versions of the metamodel were produced: the first written in bon itself, and the second formalised in the pvs specification language. their metamodel was used as a starting point for our own ecore-based metamodel. 5 conclusions and future work we believe that formalising the textual and graphical sides of a modelling language and their interrelationship helps to bring clarity to the semantics of the language and the representations employed therein. semantically consistent translations and updates to the model representations are essential to provide high reliability on the validity of models that have been automatically updated by tools. our tool support is at an early stage; in particular, the bon ide cannot yet be used to describe any of the dynamic parts of the bon modelling language. translation between the graphical and textual models as described here has been started, but not completed. there also still remains a great deal to be completed in the formalisation. the work described in this paper only deals with the static elements of formal bon, but providing full coverage is both desirable and necessary to reason about complete bon models. this approach can be generalised and applied to other modelling languages, such as uml with ocl. the complexity is likely to rise with the size of the language, however, and the utility will be reduced if the textual and graphical forms are only loosely integrated. acknowledgements: thanks to ralph skinner for his work on the bon ide. this work is supported by the eu artemis project charter. proc. ocl 2010 16 / 18 eceasst bibliography [abgr07] k. anastasakis, b. bordbar, g. georg, i. ray. uml2alloy: a challenging model transformation. model driven engineering languages and systems, pp. 436–450, 2007. doi:http://dx.doi.org/10.1007/978-3-540-75209-7 30 [ap03] m. alanen, i. porres. difference and union of models. in stevens et al. (eds.), uml 2003 the unified modeling language. lecture notes in computer science 2863, pp. 2–17. springer-verlag, oct. 2003. [fef10] s. feferman. and so on... reasoning with infinite diagrams. synthese, 2010. to appear. [gog99] j. goguen. an introduction to algebraic semiotics, with application to user interface design. lecture notes in computer science 1562. springer berlin heidelberg, berlin, heidelberg, mar. 1999. doi:10.1007/3-540-48834-0 [jac02] d. jackson. alloy: a lightweight object modelling notation. acm transactions on software engineering and methodology 11(2):256–290, 2002. doi:http://doi.acm.org/10.1145/505145.505149 [lop02] j. lancaric, j. ostroff, r. paige. the bon case tool. details available via http://www.cs.yorku.ca/∼eiffel/bon case tool/, mar. 2002. [ner92] j.-m. nerson. applying object-oriented analysis and design. communications of the acm 35(9):63–74, 1992. doi:http://doi.acm.org/10.1145/130994.130997 [ors92] s. owre, j. rushby, , n. shankar. pvs: a prototype verification system. in kapur (ed.), 11th international conference on automated deduction (cade). lecture notes in artificial intelligence 607, pp. 748–752. springer-verlag, saratoga, ny, june 1992. [pkol02] r. paige, l. kaminskaya, j. ostroff, j. lancaric. bon-case: an extensible case tool for formal specification and reasoning. journal of object technology 1(3):77– 96, 2002. [po01] r. f. paige, j. ostroff. metamodelling and conformance checking with pvs. in proceedings of fundamental aspects of software engineering. lecture notes in computer science 2029. springer-verlag, apr. 2001. [sb06] c. snook, m. butler. uml-b: formal modelling and design aided by uml. acm transactions on software engineering and methodology 15(1):92–122, january 2006. 17 / 18 volume 36 (2010) http://dx.doi.org/http://dx.doi.org/10.1007/978-3-540-75209-7_30 http://dx.doi.org/10.1007/3-540-48834-0 http://dx.doi.org/http://doi.acm.org/10.1145/505145.505149 http://www.cs.yorku.ca/~eiffel/bon_case_tool/ http://dx.doi.org/http://doi.acm.org/10.1145/130994.130997 verified visualisation [ski10] r. skinner. an integrated development environment for the business object notation. 2010. msc thesis, university college dublin. [the10] the eclipse modeling framework project. http://http://www.eclipse.org/modeling/emf/, 2010. [wn95] k. waldén, j.-m. nerson. seamless object-oriented software architecture: analysis and design of reliable systems. prentice-hall, inc., upper saddle river, nj, usa, 1995. proc. ocl 2010 18 / 18 http://http://www.eclipse.org/modeling/emf/ introduction bon tools bonc bon ide model formalisation graphical formalisation textual formalisation relating textual and graphical formalisations views uses model evolution chasing refinements the right tool principle difficult properties axiomatic properties views outline view folding relationships involving hidden elements related work conclusions and future work electronic communications of the easst volume 33 (2010) proceedings of the fourth international workshop on foundations and techniques for open source software certification (opencert 2010) security evaluation and hardening of free and open source software (foss) robert charpentier, mourad debbabi, dima alhadidi , azzam mourad , nadia belblidia , amine boukhtouta , aiman hanna , rachid hadjidj , hakim kaitouni , marc-andré laverdière , hai zhou ling , syrine tlili , xiaochun yang , and zhenrong yang. 18 pages guest editors: luis s. barbosa, antonio cerone, siraj a. shaikh managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 eceasst security evaluation and hardening of free and open source software (foss) robert charpentier1, mourad debbabi2, dima alhadidi 2, azzam mourad 2, nadia belblidia 2, amine boukhtouta 2, aiman hanna 2, rachid hadjidj 2, hakim kaitouni 2, marc-andré laverdière 2, hai zhou ling 2, syrine tlili 2, xiaochun yang 2, and zhenrong yang.2∗ 1 defence research and development canada, valcartier, quebec, canada 2 computer security laboratory, concordia university, montreal, quebec, canada abstract: recently, free and open source software (foss) has emerged as an alternative to commercial-off-the-shelf (cots) software. now, foss is perceived as a viable long-term solution that deserves careful consideration because of its potential for significant cost savings, improved reliability, and numerous advantages over proprietary software. however, the secure integration of foss in it infrastructures is very challenging and demanding. methodologies and technical policies must be adapted to reliably compose large foss-based software systems. a drdc valcartier-concordia university feasibility study completed in march 2004 concluded that the most promising approach for securing foss is to combine advanced design patterns and aspect-oriented programming (aop). following the recommendations of this study a three years project have been conducted as a collaboration between concordia university, drdc valcartier, and bell canada. this paper aims at presenting the main contributions of this project. it consists of a practical framework with the underlying solid semantic foundations for the security evaluation and hardening of foss. keywords: free and open source software, security hardening, static analysis, dynamic analysis, aspect oriented programming. 1 introduction during the past two decades, the software market has been dominated by commercial-off-theshelf (cots) products that offer a myriad of functionalities at reasonable prices. however, the intrinsic limitations of cots software such as security weaknesses, closed source code, expensive upgrades, and lock-in effect have emerged over time. this led to the development of a parallel “economy" based on free and open source software (foss). the latter refers to software whose source code is made available for use and modification without the expensive license fees imposed by cots software vendors. foss is developed either by volunteers, nonprofit organizations, or by large computer firms who want to include “commodity" software to give a competitive advantage to their hardware products. to date, thousands of foss projects ∗ this research is the result of a fruitful collaboration with bell canada and the dnd/nserc research partnership program. 1 / 18 volume 33 (2010) security evaluation and hardening of foss are carried out via internet collaboration. a plethora of high-quality applications are available for use or modification at no (or small) cost. many of these foss products are widely available and are considered to be as mature as their cots equivalents. foss is now perceived as a viable long-term solution that deserves careful consideration because of its potential for significant cost savings, improved reliability, and support advantages over proprietary software [cc04]. technically, the secure integration of foss in it infrastructures is very challenging and demanding. methodologies and technical policies must be adapted to reliably compose large foss-based software systems [bol03]. this requirement is exacerbated by the fact that our dependency on software will continue to grow in the next decade. recent studies confirm that the level of reliability and security currently offered by commercial products is clearly inadequate and that an order of magnitude increase is needed to cope properly with cyber threats [fr03]. a drdc valcartier (defence r&d canada valcartier)-concordia university feasibility study, completed in march 2004, addressed these issues and considered the technological options to cope with the security and reliability of complex information systems including foss and cots software [cc04]. it concluded that the most promising approach is to combine advanced security design patterns and aspect-oriented programming (aop). this facilitates the separation of the definition and implementation of quality and functional specifications. such a “separation of concerns" will ease the development of secure design patterns to be applied to a wide range of applications. time and cost investments were also evaluated for the scientific demonstration of these concepts. following the recommendations of this study, a three-year project has been conducted as a collaboration between concordia university, drdc valcartier, and bell canada. this paper aims at presenting the main contributions of this project. more precisely, it presents a practical framework with the underlying solid semantic foundations for the security evaluation and hardening of free and open source software. the evaluation aims to automatically detect vulnerabilities in foss that will be corrected by the systematic injection of security code thanks to dedicated aspect-oriented technologies. the security code is meant to be derived from security hardening patterns. the remainder of this paper is organized as follows. section 2 surveys the related work. in section 3, we present our first contribution involving static analysis and model checking for detecting security vulnerabilities. section 4 shows our contribution for security hardening, which is based on aspect-orientation. finally, section 5 concludes the paper. 2 related work security code analysis includes security code inspection, automatic analysis and static analysis techniques. security code inspection techniques are borrowed from software engineering practices [fag76] and adapted specifically for security purposes. automatic analysis techniques generally scan the code looking for security sensitive coding patterns that are compiled in checklists. the available techniques are limited to vulnerable coding patterns such as buffer overflows, heap overflows, integer overflows, format string vulnerabilities, sql injection, cross-site scripting and race conditions [gre]. among the tools that implement these techniques, we can cite: flawfinder [whe], coverity [cov] and polyspace [pol]. static analysis is used to predict secuproc. opencert 2010 2 / 18 eceasst rity properties of programs without resorting to their execution. static analysis techniques include flow-based analysis [bdnn01], type-based analysis [cgg02] and abstract interpretation [cc77]. finally, the evaluation by security testing is based on the design and execution of test cases in order to identify vulnerabilities in the security features of the software [her03, wts03]. for foss security hardening, four approaches could be distinguished: analyzing, monitoring, auditing, and rewriting [mm00]. analysis-based techniques range from simple scanning of code in order to detect malicious code to sophisticated semantics-based analysis of programs. one popular form of analysis-based techniques is certified compilation, which leverages the information generated by the compiler in order to endow the code with a security certificate. this could take the form of proofs as in pcc [nec97], structured annotations as in ecc [koz98], or typing annotations with typed assembly languages tal [mwcg99], stal [mcgw98], dtal [xh99], alias types [swm00], hbal [ac03] and linearly typed assembly language [cm03]. nevertheless, static analysis is to some extent complex and in some regards undecidable. monitoring is based on background daemons watching the execution of a program to prevent, at run-time, any harmful operation from taking place [hms03]. the main drawback of monitoring is the overhead in terms of performance that is induced by the daemons. with auditing-based approaches, the system activity is recorded in an audit trail. this provides a sequence of events related to a trace of program execution and allows to track back any harmful action. if any malicious code causes damage, the audit trail allows to do the recovery and to take the necessary precautions for the future. as of the rewriting-based approach, the code is modified to prevent deviation from the security policies in place. a rewriting tool inserts extra code to perform dynamic checks that ensure that “bad things” cannot happen. among the research contributions in rewriting-based security, we can cite [rw02]. in our project, we use aspect-orientation as an enabling technology that allows the systematic injection of security in foss. aspect-oriented programming (aop) [klm+97] promotes the principle of separation of concerns, thus allowing smooth integration of security hardening mechanisms inside existing software. the most prominent aop languages are aspectj [khh+01] and hyper/j [to00], which are built on top of java programming language. a similar work has also been done to provide aop frameworks for other languages. for instance, aspectc [ckfs01] is an aspect extension of c that is used to provide separation of concerns in operating systems. similarly, aspectc++ [sgs02] and aspectc# [kim02] are respectively aop extensions of c++ and c# languages. some attempts have been made to use aop for security. for instance, cigital labs have conducted a darpa-funded project [lab03], where the aop paradigm has been used to address software security. the main outcomes of this project are a security dedicated aspect extension of c called csaw [lab03] and a weaving tool. de win [wpjv02] has explored the use of aspectj to integrate security aspects within applications. 3 static analysis and model-checking for vulnerability detection our approach brings into a synergy static analysis and model-checking in order to leverage the advantages and overcome the shortcomings of both techniques. the core idea is to utilize static analysis for the automation and the optimization of program abstraction processes. moreover, programmers take advantage of model-checking techniques to define a wide range of system3 / 18 volume 33 (2010) security evaluation and hardening of foss specific security properties. as a result, our approach can model-check large software against customized system-specific security properties. our ultimate goal is to provide a security verification technique for open source software, thus we base our approach on gcc, which is usually a defacto open-source compiler. the language-independent and platform-independent gimple representation [nov03] of gcc facilitates static analysis by providing easy access to flow, type, and alias information. being based on gimple, our approach can be extended to support other languages such as c, c++, and java. for the verification process, we use the moped modelchecker for pushdown systems [kss]. the latter are known to efficiently model program execution and inter-procedural behavior. moped has a procedural input language called remopla to define programs as pushdown systems. as such, the program abstraction derived from the gimple representation is serialized into remopla representation. in addition, we enrich program abstractions with remopla constructs that compute and capture data dependencies between program expressions. therefore, we are able to detect insidious errors that involve variable aliasing and function parameter passing. security properties and program remopla model are input to moped in order to detect security violations and provide witness paths leading to them. moped allows the verification of reachability properties by looking for the reachability of a specific statement in the remopla code. though interesting, this capability is not directly sufficient for verifying security properties. in fact, a security property is the description of a pathological behavior in the execution of a program. such a behavior requires in general an elaborated formalism to be specified and can rarely be stated as the simple reachability of a specific statement in the program. to specify security properties, we use the formalism of security automata. a security automaton is a simple automaton with two spacial states: start and error, and transitions are mapped to instructions or statements in the program to verify. the reachability of the error state in the security automaton when synchronized with the program behaviors is an indication of the occurrence of the pathology. to overcome the limitation of moped in this regard, we translate a security automaton into a remopla representation then synchronize it with the remopla model of the program in question. this comes to synchronizing the pushdown systems of the program and the security automaton. as such, the problem of verifying a security property is translated into detecting the reachability of the error state in the synchronized model. 3.1 design and implementation fig. 1 depicts the architecture of our security verification environment. the security verification of programs is carried out through different phases including security property specification, static pre-processing, program model extraction, and property model-checking. in the following paragraphs, we describe the input, the output, and the tasks of each of these phases. • phase1. security property specification: – input: security properties. – output: remopla automata of security properties. the first step of our verification process requires the definition of security properties describing what not to do for the purpose of building secure code. we provide users with proc. opencert 2010 4 / 18 eceasst a tool in order to graphically characterize the security rules that a program should obey. each property is specified as a finite state automaton where the nodes represent program states and the transitions match program actions. final states of automata are risky states that should never be reached. to ease the property specification, our tool supports syntactical pattern matching for program expressions and program statements. the graphically defined properties are then serialized into the remopla language of moped model-checker. security policysource code gimple representation security automata remopla model yes no verified property error trace call-graph/alias information gcc compilation property translation static analysis model contruction model checking figure 1: security verification framework • phase2. static analysis for pre-processing: – input: program gimple representation and security properties. – output: call-graph and alias information. given a program and a set of security properties to verify, this process conducts call-graph analysis and alias analysis of the program. by considering the required properties, this phase identifies property-relevant behaviors of the analyzed program and discards those that are irrelevant. besides, we resort to alias analysis in order to limit the number of tracked variables. we only consider variables that are explicitly used in security-relevant operations together with their aliases. all other variables are discarded from the verification process. the static pre-processing phase helps generating concise models that reduce the size of state spaces to explore. • phase3. program model extraction: 5 / 18 volume 33 (2010) security evaluation and hardening of foss – input: program source code and specified security properties. – output: control-flow driven remopla model or data-driven remopla model. both the program and the specified properties are translated into remopla representation and then combined together. the combination of program models and security properties serves the purpose of synchronizing the program behaviors with the security automaton transitions. in other words, transitions in security automata are triggered when they match the current program statement. our verification approach carries out program model extraction in two different modes: the control-flow driven mode and the data-driven mode. the control-flow mode preserves in the remopla model the flow structure of the program, but discards data dependencies between program expressions. the resulting remopla model is efficiently used to detect temporal security property violations and scales to large programs. on the other hand, our data-driven model captures data dependencies between program expressions. hence, it enhances the precision of our analysis and reduces the number of false positives. • phase4. program model-checking: – input: remopla model. – output: detected error traces. model-checking is the ultimate step of our process. the generated remopla model is given as input to the moped model-checker for security verification. an error is reported when a security automaton specified in the model reaches a risky state. the original version of moped has a shortcoming in a sense that it stops processing at the first encountered error. we have done a modification to moped in order to be able to detect more than one error in a run. moreover, we have developed an error trace generation functionality that maps error traces derived from the remopla model to actual traces from the source code. 3.2 results and experiments this section demonstrates the capability of our security verification framework in detecting real errors in large c software packages. we show that our approach can be efficiently used for uncovering undesirable vulnerabilities in source code. the cert secure coding website [cer] provides a valuable source of information to learn the best practices of c, c++, and java programming. it defines a standard that encompasses a set of rules and recommendations for building secure code. rules must be followed to prevent security flaws that may be exploitable, whereas recommendations are guidelines that help improve the system security. the cert standard also makes another difference between rules and recommendations stating that compliance of a code to rules can be verified whereas the compliance to recommendations is not always verifiable. to assist programmers with the verification of their code, we have integrated in our tool a set of secure coding rules defined in the cert standard. as such, programmers can use our framework to evaluate the security of their code without the need to have high security expertise. cert rules can mainly be classified into the following categories: proc. opencert 2010 6 / 18 eceasst • deprecation rules: these rules are related to the deprecation of legacy functions that are inherently vulnerable such as gets for user input, tmpnam for temporary file creation, and rand for random value generation. the presence of these functions in the code should be flagged as a vulnerability. for instance, cert rule msc30-c states the following “do not use the rand() function for generating pseudorandom numbers”. • temporal rules: these rules are related to a sequence of program actions that appear in source code. for instance, the rule mem3-c from the cert entails to “free dynamically allocated memory exactly once”. consecutive free operations on a given memory location represents a security violation. intuitively, these kind of rules are modeled as finite state automata where state transitions correspond to program actions. the final state of an automaton is the risky state that should never be reached. • type-based rules: these rules are related to the typing information of program expressions. for instance, the rule exp39-c from the cert states the following “do not access a variable through a pointer of an incompatible type”. a type-based analysis can be used to track violations of these kind of rules. • structural rules: these rules are related to the structure of source code such as variable declarations, function inlining, macro invocation, etc. for instance, rule dcl32-c entails to “guarantee that mutually visible identifiers are unique”. for instance, the first characters in variable identifiers should be different to prevent confusion and facilitates the code maintenance. our approach covers the first two categories of coding rules that we can formally model as finite state automata. in fact, we cover 31 rules out of 97 rules in the cert standard. we also cover 21 recommendations that can be verified according to cert. we conduct experiments that consist in detecting the defined set of cert coding rules against a set of well-known and widely used open-source software. we strive to cover different kinds of security coding errors that skilled programmers can inadvertently produce in their code. the experiments are conducted in the two modes of our security verification tool: the control-flow mode that discards data dependencies and the data-driven mode that establishes data dependencies between program variables. to illustrate, fig. 2 gives an example of a security automaton that captures the race condition errors. this security automaton can be used to check the compliance of source code to the following cert rules: • pos35-c: “avoid race conditions while checking for the existence of a symbolic link". • fio01-c: “be careful using functions that use file names for identification". the time-of-check-to-time-of-use vulnerabilities (tocttou) in file accesses are a classical form of race conditions. in fact, there is a time gap between the file permission check and the actual access to the file that can be maliciously exploited to redirect the access operation to another file. the automaton in fig. 2 flags a check function followed by a subsequent use function as a tocttou error. the analysis results are given in table 1. the three first columns 7 / 18 volume 33 (2010) security evaluation and hardening of foss check = { access, stat, statfs, statvfs, lstat, readlink, tempnam, tmpnam, tmpnam_r } use = { acct, au_to_path, basename, catopen, chdir, chmod, chown, chroot, copylist, creat, db_initialize, dbm_open, dbminit, dirname, dlopen, execl, execle, execlp, execv, execve, execvp, fattach, fdetach, fopen, freopen, ftok, ftw, getattr, krb_recvauth, krb_set_tkt_string, kvm_open, lchown, link, mkdir, mkdirp, mknod, mount, nftw, nis_getservlist, nis_mkdir, nis_ping, nis_rmdir, nlist, open, opendir, pathconf, pathfind, realpath, remove, rename, rmdir, rmdirp, scandir, symlink, system, t_open, truncate, umount, unlink, utime, utimes, utmpname } start errorstate1 use(x)check(x) figure 2: race condition automaton (tocttou). define the package name, the size of the package, and the program that contains coding errors. the number of reported errors is given in the fourth column (reported errors). after inspection of the reported error traces, we classify them into three following columns: column (err) for potential errors, column (fp) for false positive alerts, and column (dn) for traces that are undecidable with manual inspection. the checking time of programs is given in the last column. from table 1, we demonstrate the efficiency and the usability of our approach in detecting real errors in real-software packages. moreover, our experiment shows that the use of data-driven mode in our framework enhances the analysis precision. table 2 summarizes the error traces our tool detected during the experimentation. the properties, the number of reported traces, and the corresponding cert rules are given in the table, and more details of our experimentation can be found in [tyd09]. 4 foss security hardening software security hardening is defined in [mld06] as any process, methodology, product or combination that is used to add security functionalities, remove vulnerabilities or prevent their exploitation in existing software. security hardening practices are usually manually applied by injecting security code into software [bis05, hl02, sea05]. in this section, we address the problems related to the security hardening of foss. in this respect, we propose two aspectoriented and pattern-based approaches for systematic security hardening. the first one is built on top of existing aspect-oriented programming (aop) technologies while the other one is based on gimple. both approaches are supported by a common structure, which is based on the full separation between the roles and duties of the security experts and the developers performing the hardening. such proposition constitutes a bridge that allows the security experts to provide the best solutions to particular security problems with the details on why, how and where to apply them. moreover, it allows the developers to use these solutions to harden open source software without the need to have high security expertise. we realize the proposed structure by elaborating a programming independent and aspectproc. opencert 2010 8 / 18 eceasst table 1: results of tocttou analysis. package loc program reported errors err fp dn model-checking time (sec) amanda-2.5.1p2 87k chunker 1 0 1 0 71.6 chg-scsi 3 2 1 0 119.99 amflush 1 0 0 1 72.97 amtrmidx 1 1 0 0 70.21 taper 3 2 1 0 84.603 amfetchdump 4 1 0 3 122.95 driver 1 0 1 0 103.16 sendsize 3 3 0 0 22.67 amindexd 1 1 0 0 92.03 at-3.1.10 2.5k atd 4 3 1 0 1.16 at 4 3 1 0 1.12 bintuils-2.19.1 986k ranlib 1 1 0 0 2.89 strip-new 1 0 1 0 5.49 readelf 1 1 0 0 0.23 freeradius-server-2.1.3 77k radwho 1 1 0 0 1.29 inn-2.4.6 89k nnrpd 1 1 0 0 4.11 fastrm 1 1 0 0 0.37 archive 1 0 1 0 0.95 rnews 1 1 0 0 0.57 openssh-5.0p1 58k ssh-agent 2 0 0 2 22.46 ssh 1 0 1 0 100.6 sshd 6 3 1 2 486.02 scp 3 2 0 1 87.95 shadow-4.1.2.2 22.7k usermod 3 1 0 2 9.79 useradd 1 1 0 0 11.45 vipw 2 2 0 0 10.32 newusers 1 1 0 0 9.2 zebra-0.95a 142k ripd 1 1 0 0 0.46 oriented based language for security hardening called shl, developing its corresponding parser, compiler and integrating all of them into a framework for software security hardening. in the following, we present the architecture, the design and implementation as well as the results and experiments of each of the aforementioned two approaches. 4.1 aspect-oriented security hardening this approach is based on the security hardening language (shl) that is defined in [mld07a, mld07b]. we have elaborated an aspect-oriented approach to perform security hardening in a systematic way. in this approach, security experts provide security solutions using an abstract 9 / 18 volume 33 (2010) security evaluation and hardening of foss table 2: summary of analysis results. experiment property reported err fp dn cert rule error race condition 54 33 10 11 pos35-c, fio01-c temporary file usage 23 23 0 0 fio43-c chroot jail 2 1 1 0 pos02-c, fio16-c memory leak 61 11 13 37 mem-c unchecked return value 14 14 0 0 mem32-c, exp34-c environment variable usage 11 10 1 0 str31-c, str32-c, env31-c deprecated function too many fio33-c, pos33-c, msc30-c and a general aspect-oriented language called shl that is expressive, human-readable, multilanguage support. this will relieve developers from the burden of security issues and let them focus on the main functionality of programs. the security solutions are then applied in a systematic way eliminating the need for manual hardening. the approach provides an abstraction over the actions that are required to improve the security of programs and adopt an aspect-oriented approach to build and develop the solutions. 4.1.1 architecture we present in fig. 3 the architecture of this approach. shl is built on the top of the current aop technologies that are based on the pointcut-advice model. the solutions elaborated in shl are expressed by plans and patterns and can be refined into a selected aop language. security hardening patterns are high-level and well-defined solutions to known security problems, together with detailed information on how and where to inject each component of the solution into an application. security hardening plans instantiate security hardening patterns with parameters regarding platforms, libraries and languages. the combination of hardening plans and patterns constitutes a bridge that allows security experts to provide the best solutions to particular security problems and allows developers to use these solutions to harden applications by developing security hardening patterns. the development implies refinement of solutions into advices using the existing aop languages (e.g., aspectj, aspectc++). proc. opencert 2010 10 / 18 eceasst figure 3: framework architecture 4.1.2 shl compiler and framework implementation we implement the bnf specification of shl using antlr and its associated antlrworks development environment. the generated java code allows to parse hardening plans and patterns and verify the correctness of their syntax. we build on top of it a compiler that uses the information provided by the parser to build first its data structure, then reacts upon the provided values in order to run the hardening plan and compile and run the specified pattern and its corresponding aspect. moreover, we integrate this compiler into a development graphical user interface for security hardening. the resulting system provides the user with graphical facilities to develop, compile, debug and run security hardening plans and patterns. it allows also to visualize the software to be hardened and all the compilation and integration activities performed during the hardening. the compilation process is divided into many phases that are performed consequently and automatically. in the sequel, we present and explain these phases. • plan compilation: this phase consists of parsing the plan, verifying its syntax correctness and building the data structure required for the other compilation phases. any error during the execution of this phase stops the whole compilation process and provides the developer with information to correct the bug. this statement also applies on all the other phases. • pattern compilation and matching: a search engine is developed to find the pattern that matches the pattern instantiations requested in the hardening plan (i.e., pattern name and parameters). a naming convention composed of the pattern name and parameters is adopted to differentiate between the patterns with same name but different parameters. once the pattern-matching the criteria is found, another check on the name and parameters specified inside the pattern is applied in order to ensure that the matching is correct 11 / 18 volume 33 (2010) security evaluation and hardening of foss and there is no error in the naming procedure. this includes automatically parsing and compiling the pattern contents to check the correctness of its syntax, verify the matching result and build the data structure required for the running process. • aspect matching: once the pattern is compiled successfully, a search engine similar to the aforementioned one is used to find the aspect corresponding to the matched pattern. • plan running and weaving: plan running is the last phase of the compilation process. once the corresponding aspect is matched, the execution command is constructed based on the information provided in the data structure, which is built during the previous compilation phases. afterwards, the aspect is woven with the specified application or module and the resulted hardened software is produced. • aspect generation: aspect generation is an additional feature launched separately to assist the developer during the refinement of a pattern by generating automatically parts of the corresponding aspect. the generated poincuts and advices are enclosed into an aspect that has the same name as the pattern concatenated to its parameters. the developer will have to refine the advices’ bodies into programming language code (i.e, c++ or java) and then run the plan to apply the weaving. 4.2 gimple-based software security hardening this approach allows applying the security hardening on the gimple representation of software [nov03]. gimple is an intermediate representation of programs. it is a language-independent and a tree-based representation generated by the the gnu compiler collection (gcc) [gcc] during compilation. gcc is a compiler system supporting various programming languages, e.g., c, c++, objective-c, fortran, java, and ada. in transforming the source code to gimple, complex expressions are split into three address codes using temporary variables. exploiting the intermediate representation of gimple enables to define language-independent weaving semantics that facilitates introducing new security-related aop extensions. the importance of this stems from the fact that aspect-oriented languages are language dependent. accordingly, gimple weaving allows defining common weaving semantics and implementation for all programming languages supported by the gcc compiler instead of doing them for each aop language. this approach is also based on the aforementioned security hardening language (shl). fig. 4 illustrates the architecture of the gimple weaving approach together with the one presented in fig. 3. the gimple weaving approach bypasses the refinement step from patterns into aop languages. the hardening tasks specified in patterns are abstract and support multiple languages, which makes the gimple representation of software a relevant target to apply the hardening. this is done by passing the shl patterns and the original software to an extended version of the gcc compiler, which at the end generates the executable of the trusted software. for this purpose, an additional pass is added to the gcc compiler in order to interrupt the compilation once the gimple representation of the code is completed. in parallel, the hardening pattern is compiled and a gimple tree is built for each behavior using the routines of the gcc compiler that are provided for this purpose. afterwards, the gimple trees generated from the hardening patterns are integrated in the gimple tree of the original code with respect to the proc. opencert 2010 12 / 18 eceasst security hardening aspects security hardening pattern security requirements security expert software trusted software weaver security apis security hardening plan shl refining developer extended gcc / gimple weaving interrupt gcc compile pattern gimple weaving gcc compilation security gimple trees software gimple tree figure 4: approach architecture location(s) specified in each behavior of the hardening pattern. finally, the resulted gimple tree is passed again to the gcc compiler in order to continue the regular compilation process and produce the executable of the secure software. 4.2.1 design and implementation of gimple weaving capabilities into gcc this implementation allows weaving patterns into the gimple representation of programs before generating the corresponding executables. we handle before, after, and replace behaviors. in addition, we target call, set, get, and withincode locations. the implementation methodology that is adopted consists of the following steps. first, we generate a configuration file from the shl file. this configuration file contains all the information needed for the weaving using our extended gcc. then, we use the name of this configuration file as an option in a specific command line of the extended gcc compiler. this compiler, which has weaving capabilities, is an extension to the gcc compiler version 4.2.0. consequently, three input files are needed by the extended compiler to perform the weaving: a source code, a configuration file, and a library containing the subroutines to be woven. in addition to the above option, it is required to specify the library that contains the code to be woven. this is done through gcc’s options -l and 13 / 18 volume 33 (2010) security evaluation and hardening of foss -l. then, a gimple tree is built for the code of each behavior in a pattern. afterwards, each generated tree is injected in the program tree depending on the insertion point and the location specified in each behavior. once this weaving procedure is done, the gcc compiler takes over and continues the classical compilation of the modified tree to generate the executable of the hardened program. 4.2.2 results and experiments the main contributions of this approach can be summarized as follows: • semantics and algorithms for matching and weaving in gimple are formalized. for this reason, a syntax for a common aspect-oriented language that is abstract and multilanguage support and a syntax for gimple constructs are defined. • correctness and completeness of gimple weaving are explored from two different views. in the first approach, we address them according to the provided formal matching and weaving rules and the defined algorithms in this paper. on the other hand, we accommodate in the second approach kniesel’s discipline to prove that gimple weaving is correct and complete just in some specific cases because of behavior interactions and interferences. • implementation strategies of the proposed semantics are introduced. to explore the viability and the relevance of the defined approach, case studies are developed to solve the problems of unsafe creating of chroot jail, unsafe creating of temporary files, and using deprecated functions. 5 conclusion in this paper, we have presented an innovative framework for security evaluation and hardening of free and open-source software. for security evaluation, first a vulnerability detection approach has been proposed. this approach brings into a synergy the static analysis and the modelchecking in order to leverage the advantages and overcome the shortcomings of both techniques. we have demonstrated the efficiency and the usability of our approach in detecting real errors in real-software packages. moreover, our experiment shows that the use of data-driven mode in our framework enhances the analysis precision. it is important to mention that we have also developed a second approach to detect security vulnerabilities that is based on security testing and code instrumentation. this approach has not been detailed in this paper for the lack of space. finally, we have presented a security hardening approach. the approach is aspectoriented and performs security hardening in a systematic way. in this approach, security experts provide security solutions using an abstract and a general aspect-oriented language called shl that is expressive, human-readable, multi-language support. the use of this language relieve developers from the burden of security issues and let them focus on the main functionality of programs. the approach provides an abstraction over the actions that are required to improve the security of programs and adopt an aspect-oriented approach to build and develop the solutions. proc. opencert 2010 14 / 18 eceasst bibliography [ac03] d. aspinall, a. b. compagnoni. heap bounded assembly language. journal of automated reasoning 31:261–302, 2003. [bdnn01] c. bodei, p. degano, f. nielson, h. r. nielson. static analysis for secrecy and non-interference in networks of processes. lecture notes in computer science 2127:27–41, 2001. [bis05] m. bishop. how attackers break programs, and how to write more secure programs. 2005. available at http://nob.cs.ucdavis.edu/~bishop/secprog/sans2002/index.html. accessed on 2008/11/11. [bol03] t. bollinger. use of free and open-source software (foss) in the u.s. department of defense. technical report mp 02w0000101 v1.2.04, mitre, january 2003. [cc77] p. cousot, r. cousot. abstract interpretation: a unified lattice model for static analysis of programs by construction or approximation of fixpoints. in proceedings of conference record of the fourth annual acm sigplan-sigact symposium on principles of programming languages. pp. 238–252. acm press, new york, ny, los angeles, california, 1977. [cc04] r. charpentier, r. carbone. free and open source software: overview and preliminary guidelines for the government of canada. march 2004. defence research and development canada – valcartier. [cer] cert secure coding standard. http://www.securecoding.cert.org. accessed in april 2009. [cgg02] l. cardelli, a. gordon, g. ghelli. secrecy and group creation. in hurley et al. (eds.), electronic notes in theoretical computer science. volume 40. elsevier, 2002. [ckfs01] y. coady, g. kiczales, m. feeley, g. smolyn. using aspectc to improve the modularity of path-specific customization in operating system code. in proceedings of foundations of software engineering. vienne, austria, september 2001. [cm03] j. cheney, g. morrisett. a linearly typed assembly language. technical report 2003-1900, department of computer science, cornell university, 2003. [cov] coverity. coverity prevent for c and c++. http://www.coverity.com/main.html. accesses on june 1, 2010. [fag76] m. e. fagan. design and code inspections to reduce errors in program development. ibm systems journal 15(3), 1976. 15 / 18 volume 33 (2010) security evaluation and hardening of foss [fr03] a. fecteau, j. p. rodrique. certifying critical software: jacc market survey. technical report, geo alliance international inc, june 2003. [gcc] gcc-the gnu compiler collection. available at http://gcc.gnu.org/. accessed on 2009/6/1. [gre] l. grenier. practical code auditing. openbsd journal. [her03] p. herzog. open-source security testing methodology manual. institute for security and open methodologies (isecom), august 2003. [hl02] m. howard, d. e. leblanc. writing secure code. microsoft, redmond, wa, usa, 2002. [hms03] k. w. hamlen, g. morrisett, f. b. schneider. computability classes for enforcement mechanisms. technical report tr2003-1908, cornell university, computing and information science, ithaca, new york, august 2003. [khh+01] g. kiczales, e. hilsdale, j. hugunin, m. kersten, j. palm, w. griswold. an overview of aspectj. in proceedings of the 2001 european conference on objectoriented programming (ecoop’01). 2001. [kim02] h. kim. aspectc#: an aosd implementation for c#. technical report tcd cs2002-55, department of computer science, trinity college, dublin, 2002. [klm+97] g. kiczales, j. lamping, a. menhdhekar, c. maeda, c. lopes, j.-m. loingtier, j. irwin. aspect-oriented programming. in akşit and matsuoka (eds.), proceedings european conference on object-oriented programming. volume 1241, pp. 220–242. springer-verlag, berlin, heidelberg, and new york, 1997. [koz98] d. kozen. efficient code certification. technical report 98-1661, computer science department, cornell university, january 1998. [kss] s. kiefer, s. schwoon, d. suwimonteerabuth. moped a model-checker for pushdown systems. http://www.fmi.uni-stuttgart.de/szs/tools/moped/. accessed on january 20, 2009. [lab03] c. labs. an aspect-oriented security assurance solution. technical report afrl-if-rs-tr-2003-254, cigital labs, dulles, virginia, usa, oct 2003. [mcgw98] g. morrisett, k. crary, n. glew, d. walker. stack-based typed assembly language. in tic. lecture notes in computer science 1473, pp. 28–52. springer, kyoto, japan, march 1998. [mld06] a. mourad, m.-a. laverdière, m. debbabi. security hardening of open source software. in proceedings of the 2006 international conference on privacy, security and trust (pst 2006). mcgraw-hill/acm, 2006. proc. opencert 2010 16 / 18 eceasst [mld07a] a. mourad, m.-a. laverdière, m. debbabi. a high-level aspect-oriented based language for software security hardening. in proceedings of the international conference on security and cryptography (secrypt). barcelona, spain, 2007. [mld07b] a. mourad, m.-a. laverdiere, m. debbabi. towards an aspect oriented approach for the security hardening of code. in proceedings of the 21st international conference on advanced information networking and applications workshops, ainaw ’07. pp. 595–600. 2007. [mm00] g. mcgraw, g. morrisett. attacking malicious code: a report to the infosec research council. ieee software 5(17), september/october 2000. [mwcg99] g. morrisett, d. walker, k. crary, n. glew. from system f to typed assembly language. 21(3):528–569, may 1999. [nec97] g. necula. proof-carrying code. in 24th popl. pp. 106–119. paris, france, january 1997. [nov03] d. novillo. tree ssa: a new optimization infrastructure for gcc. in proceedings the gcc developers summits3. pp. 181–193. may 25-27 2003. [pol] polyspace. automatic detection of run-time errors at compile time. http://www.polyspace.com/. [rw02] a. rudys, d. s. wallach. enforcing java run-time properties using bytecode rewriting. in proceedings of the international symposium on software security. tokyo, japan, november 2002. [sea05] r. c. seacord. secure coding in c and c++. sei series. addison-wesley, 2005. [sgs02] o. spinczyk, a. gal, w. schröder-preikschat. aspectc++: an aspect-oriented extension to c++. in proceedings of the 40th international conference on technology of object-oriented languages and systems. sydney, australia, february 2002. [swm00] f. smith, d. walker, g. morrisett. alias types. lecture notes in computer science 1782:366+, 2000. [to00] p. tarr, h. ossher. hyperj user and installation manual. 2000. http://www.research.ibm.com/hyperspace. accessed on june 1,2010. [tyd09] s. tlili, x. yang, m. debbabi. verification of cert secure coding rules: case studies. in international symposium on information security. springer verlag, 2009. [whe] d. a. wheeler. flawfinder. http://www.dwheeler.com/flawfinder/. accessed in june, 2010. 17 / 18 volume 33 (2010) security evaluation and hardening of foss [wpjv02] b. d. win, f. piessens, w. joosen, t. verhanneman. on the importance of the separation-of-concerns principle in secure software engineering. 2002. workshop on the application of engineering principles to system security design, boston, ma, usa, november 6–8, 2002, applied computer security associates (acsa). [wts03] j. wack, m. tracy, m. souppaya. guideline on network security testing. nist special publication 800-42, national institute of standards and technology (nist), october 2003. [xh99] h. xi, r. harper. dependently typed assembly language. technical report ogicse-99-008, department of computer science and engineering, oregon graduate institute of science and technology, july 1999. proc. opencert 2010 18 / 18 towards the verification of pervasive systems electronic communications of the easst volume 22 (2009) proceedings of the third international workshop on formal methods for interactive systems (fmis 2009) towards the verification of pervasive systems myrto arapinis, muffy calder, louise denis, michael fisher, philip gray, savas konur, alice miller, eike ritter, mark ryan, sven schewe, chris unsworth, rehana yasmin, 15 pages guest editors: michael harrison, mieke massink managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst towards the verification of pervasive systems myrto arapinisa, muffy calderb, louise denisc, michael fisherd , philip graye, savas konur f , alice millerg, eike ritterh, mark ryani, sven schewe j, chris unsworthk, rehana yasminl , a m.d.arapinis@cs.bham.ac.uk h e.ritter@cs.bham.ac.uk i m.d.ryan@cs.bham.ac.uk l r.yasmin@cs.bham.ac.uk school of computer science, university of birmingham c l.a.denis@liverpool.ac.uk d mfisher@liverpool.ac.uk f s.konur@liverpool.ac.uk j sven.schewe@liverpool.ac.uk department of computer science, university of liverpool b muffy@dcs.gla.ac.uk e pdg@dcs.gla.ac.uk g alice@dcs.gla.ac.uk k chrisu@dcs.gla.ac.uk department of computer science, university of glasgow abstract: pervasive systems, that is roughly speaking systems that can interact with their environment, are increasingly common. in such systems, there are many dimensions to assess: security and reliability, safety and liveness, real-time response, etc. so far modelling and formalizing attempts have been very piecemeal approaches. this paper describes our analysis of a pervasive case study (match, a homecare application) and our proposal for formal (particularly verification) approaches. our goal is to see to what extent current state of the art formal methods are capable of coping with the verification demand introduced by pervasive systems, and to point out their limitations. keywords: pervasive systems, modelling, formalizing, verification 1 introduction pervasive systems (often also termed ubiquitous systems) are increasingly common. but what are they? one of the many definitions is that pervasive computing refers to a general class of mobile systems that can sense their physical environment, i.e., their context of use, and adapt their behaviour accordingly [pshc08]. while there are very many forms of pervasive system, they are often: • mobile and autonomous; • distributed and concurrent; • interacting and interactive; 1 / 15 volume 22 (2009) mailto:m.d.arapinis@cs.bham.ac.uk mailto:e.ritter@cs.bham.ac.uk mailto:m.d.ryan@cs.bham.ac.uk mailto:r.yasmin@cs.bham.ac.uk mailto:l.a.denis@liverpool.ac.uk mailto:mfisher@liverpool.ac.uk mailto:s.konur@liverpool.ac.uk mailto:sven.schewe@liverpool.ac.uk mailto:muffy@dcs.gla.ac.uk mailto:pdg@dcs.gla.ac.uk mailto:alice@dcs.gla.ac.uk mailto:chrisu@dcs.gla.ac.uk towards the verification of pervasive systems • reactive and potentially non-terminating; and • composed of humans, agents and artifacts interacting together. existing pervasive systems provide services to the inhabitants of a home, the workers of an office or the drivers in a car park. we know that requirements for current and future pervasive systems involve great diversity in terms of their types of services, such as multimedia, communication or automation services. typical example. as we walk into a shopping area, our intelligent clothing interacts wirelessly with shops in the area and then with our mobile phone to let us know that our shoes are wearing out and that the best deals nearby are at shops ‘x’, ‘y’ and ‘z’. our pda, which holds our shopping list, also interacts with our phone to suggest the optimum route to include shoes in our shopping. at the same time, our pda interacts with the shopping area’s network and finds that one of our friends is also shopping − a text message is sent to the friend’s mobile/pda to coordinate shopping plans and schedule a meeting for coffee at a close location in 15 minutes. even in this simple example the components at least need capabilities to carry out: • plan synchronisation; • spatial reasoning and context-awareness; • planning and scheduling; • mobility and communication, etc. the above is an example but there are many more, often more complex examples1. what is of concern to us is that pervasive computing is increasingly used in (safety, business, or mission) critical areas. this, of course, leads us to the potential use of formal methods in this area. again, even considering the simple example above there are many dimensions to assess: security and reliability; safety and liveness; real-time response, etc. although there have been some attempts at modelling, e.g. [cfj03, wzgp04, hi04, sb05, sim07], formalising and even verifying aspects of pervasive and ubiquitous systems, e.g. [dknp06], these have been very piecemeal approaches. we wish to be able to analyse the varied behaviours of a pervasive system from a number of viewpoints. but how might this be achieved? this paper describes our analysis of a pervasive case study, match [cm07], and our proposals for formal (particularly verification) approaches. as we have seen, pervasive systems have some quite complex specification aspects. this explains, in part, why the verification of such systems is difficult. essentially, most pervasive systems involve many dimensions that we must address (formalise and verify) simultaneously: 1 see personal and ubiquitous computing journal (springer); pervasive and mobile computing journal (elsevier); journal of ubiquitous computing and intelligence (american scientific publishers); international journal of ad hoc and ubiquitous computing (inderscience publishers); and journal of ubiquitous computing and communication (ubicc publishers). proc. fmis 2009 2 / 15 eceasst • autonomous behaviour of agents; • uncertainty in communications; • teamwork, collaboration and coordination; • organisations, norms, societal interactions; • uncertainty in sensing; • real-time aspects; • etc... in addition, such systems often involve humans within the system which directly affect the system’s behaviour. current state of the art formal methods appear incapable of coping with the verification demand introduced by pervasive systems, primarily because reasoning about such systems requires considering quantitative, continuous and stochastic behaviour. we also require to prove interaction properties which are quite subtle to express. 2 match overview match (mobilising advanced technology for care at home) is a collaborative research project focused on technologies for care at home. the overall aim of match is to develop a research base for advanced technologies in support of social and health care at home. the client users for match will include older people and people with disabilities of all ages. the goal is to enable people to manage their health and way of life so that they can continue to live independently in their own homes for longer. the main aim of the research in the match project is to integrate a number of home-care technologies into one system that can be installed into a user’s home. this system will provide support and assistance where needed by realising a number of goals. goals may include “warn the user if they are doing something dangerous”, “call for help if the user has an accident and needs assistance”, “inform a medical professional if the user’s health deteriorates”. this could be implemented as a rule based, event driven pervasive system in which a set of input components such as: motion detectors, rfid readers, temperature sensors, heart monitors, and microphones, and enable the detection of significant events. a set of output components such as: speakers, guis, mobile devices, tvs, lights, and tactile devices, allow the system to interact with the environment. a set of rules will determine under what circumstances the system should take action and what action should be taken. a significant factor in whether such a system would be adopted within a home would be the issue of trust. therefore, it would be advantageous if properties of the match system could be verified. this would then provide support to the claims made by the system developers. properties of interest can be categorised as (but not limited to) security, safety and/or usability. 3 / 15 volume 22 (2009) towards the verification of pervasive systems 2.1 security security properties relate to the integrity of the system and its ability to withstand the efforts of malicious agents. as an example the property “food delivery staff cannot see mental health records” is concerned with the user’s confidentiality. it would be advantageous if the food delivery staff could have limited access to the homecare system. this could be used to find relevant information about the user, such as dietary requirements. however, it would not be reasonable for all of the user’s confidential medical records to be divulged to anyone who interacts with the system. another example, “medical records are consistent across the system” relates to system integrity. because of the distributed nature of a pervasive system, there maybe several different devices used to monitor and record the medical condition of the user. a number of these devices may hold similar or overlapping data. it should be the case that all such data is consistent. “correspondence between the system view of events and the events taking place on portable devices” is another integrity property. it is unlikely that portable devices will have complete knowledge of the state of the system. however, they should act in a manner that corresponds to the current state of the system as a whole. “no unauthorised tracking” is a property which is concerned with confidentiality. it should not be possible for a malicious agent to use system outputs to allow them to track the user. 2.2 safety safety properties relate to situations in which the system may cause harm, either by action or inaction. for example, “sensors are never offline when a patient is in danger”. the system should always have sufficient sensor coverage to detect all potentially dangerous situations that it can be reasonably expected to recognise. if the system does detect that a patient is in danger then appropriate action should be taken. the action taken should have an expected response time that is appropriate for the situation. for example, if the patient is having a heart attack then an ambulance should be called. other forms of notification such as e-mail are unlikely to be received in time. this could be represented by the property “if a patient is in danger, assistance should arrive within a given time”. properties such as “no component will perform an action that it believes will endanger the patient” can relate the hardware devices used within the system. a more traditional property, “urgent actions related to the patient’s safety will always take precedence over all other actions” ensures that important actions are prioritised. it is also important to consider potentially damaging actions a user may attempt, “users have no reasonable strategy for cooperating to falsify records or events”. this property aims to prevent users from being able to manipulate the system so as to deceive a health professional. 2.3 usability usability properties refer to aspects that directly affect the user’s experience and interaction with the system. example properties include, “notifications occur only at appropriate intervals and in appropriate circumstances”. if a user is bombarded with too many insignificant messages or is interrupted while busy, they are likely to find the system obtrusive and will probably reject it. similarly “requests to the users must be relevant to them” and “there should not be to many pending requests on a user/patient” also relate to the users’ acceptance of the system. proc. fmis 2009 4 / 15 eceasst 3 some sample properties in this section we will recall the earlier sample properties of the match system, and formulate them using formal languages. in particular, we consider formal languages for which a model checking or verification tool is available. below we consider an informal and formal account of the relevant properties. 3.1 security 3.1.1 formalisation food delivery staff cannot see mental health records. in order to formalise this property we could use the access control language rw of [grs04]. in that system, we assume predicates such as f d(x ) : x is a member of food delivery staff mhr(x ,y ) : x is the mental health record of y td(x ,y ) : x is a treating doctor for y ha(x ) : x is a health administrator predicates read and write indicate read and write permissions respectively. the following formulae show how such permissions are granted: read(mhr(x ,y ), z) ⇔ y = z ∨ td(z,y ) write(td(x ,y ), z) ⇔ z = y ∨ ha(z) ... rw can calculate whether a user can manipulate the access control system in order to give himself the necessary permissions to achieve a goal. in this example, a member of food delivery staff might be able to read mental health records if he can promote himself to treating doctor. we can verify that this is not possible by evaluating the query ∀a, b ∈ agent. r ∈ record. f d(a) → ¬[a : mhr(r, b)] this query evaluates whether there is a (perhaps roundabout) sequence of reads and writes resulting in a food delivery staff member a being able to read the health records of some patient b. correspondence between the system view of events and the events taking place on portable devices. this property is known as injective agreement in lowe’s hierarchy of authentication [low97]. intuitively, this property states that each time the match system stores some value v in the record of a patient p, then p’s doctor d has submitted this value v. in the same way, each time doctor d submits some value v for p’s record to the system, then the match system should update its state accordingly. this can be expressed in proverif’s query language [bla01] as follows: query evin j : evsyst (d, p, v) ==> evin j : evpatient (d, p, v) query evin j : evpatient (d, p, v) ==> evin j : evsyst (d, p, v) 5 / 15 volume 22 (2009) towards the verification of pervasive systems the first (resp. second) query is true when, for each executed event evsyst (d, p, v) (resp. evpatient (d, p, v)), there exists a distinct executed event evpatient (d, p, v) (resp. evsyst (d, p, v)); and evsyst (d, p, v) is executed before evpatient (d, p, v) (resp. evpatient (d, p, v) is executed before evsyst (d, p, v)). non-authorised tracking (e.g. by strangers outside the house). match’s implementation will rely on radio frequency identification (rfid) tags attached to patients, in order for the system to be able to detect if a particular patient is in the house. however, one wouldn’t want someone outside the house with an rf reader to be able to determine patient’s position. in the rfid literature [gjp05, jue06, wsre03], this security requirement is known as untraceability. intuitively, this property states that an attacker cannot link two different identifications to the system of the same tag (and thus of the same patient). in other words, all tags that identify themselves to the system look different to an outsider. this property can be specified in the applied pi calculus formalism. the applied pi-calculus [af01] is a language for describing concurrent processes and their interactions. it is based on the picalculus, but adds equations which make it possible to model a range of cryptographic primitives. we consider rfid protocols that can be expressed in the applied pi calculus as a closed plain process p p ≡ ν ñ. (db | !r | !t ) where t ≡ ν m̃. init. !main for some processes init and main2. intuitively, t is the process modeling one tag, and having t under a replication in p corresponds to considering a system with an unbounded number of tags. each tag initialises itself (this includes registering at the database db and is modelled by init in t ) and then may execute itself an unbounded number of times. thus main models one session of the tag’s protocol. r corresponds to one session of the reader’s protocol, and db to the database. we consider an unbounded number of readers, thus r is under a replication in p. many properties of security protocols (including untraceability) are formalised in terms of observational equivalence (≈) between two processes. intuitively, processes which are observationally equivalent cannot be distinguished by an outside observer, no matter what sort of test he makes. this is formalised by saying that the processes are indistinguishable under any context, i.e. no matter in what environment they are executed. let p be an rfid protocol as defined above, p is said to satisfy untraceability if p ≈ p′ where p′ ≡ ν ñ. (db | !r | !t ′) and t ′ ≡ ν m̃. init. main the intuitive idea behind this definition is as follows: each session of p should look to the intruder as initiated by a different tag. in other words, an ideal version of the protocol, w.r.t. untraceability, would allow tags to execute themselves at most once. the intruder should then not be able to tell the difference between the protocol p and the ideal version of p. 2 ν ñ models a sequence of names n1, . . . , nk restricted to (db | !r | !t ). in the same way ν m̃ denotes a sequence of names m1, . . . , m` restricted to (init. !main). proc. fmis 2009 6 / 15 eceasst 3.1.2 verification at present several tools are available for verifying the properties defined above. considering the first property, rw is supported by the acpeg tool [zha06] which accepts descriptions of access control models and evaluates queries. it treats the case that the sets of agents and other resources are finite (this case is decidable). it is currently not able to deal with non-bounded sets of resources, a problem known to be undecidable [hru76]. dynpal [bec09] also analyses access control systems of a dynamic nature, similar to rw, and is more able to treat unbounded systems, but does not handle queries about “read” capabilities. we expressed the second property in proverif’s query language and the third using observational equivalence. this, in some cases, allows a user to automatically check that a protocol satisfies these requirements using the tool proverif [bla01]. however, the verification of these properties is an undecidable problem [dlms99], and proverif isn’t always able to give an answer. it may even introduce false attacks. for the second property, which is a correspondence property one could use other tools like avispa [abb+05] or casper [low98]. in order for these tools to be able to give some results, only bounded systems are considered. indeed, when the number of executions of a protocol is bounded, the verification of many correspondence properties becomes decidable. to the best of our knowledge, proverif is the only tool able in some cases to prove that processes are observationally equivalent. 3.2 safety 3.2.1 formalisation sensors are never offline when a patient is in danger. we can, for example, formulate such a statement using standard linear-time temporal logic (ltl) [eme90, mp92, fis07]. we first capture the notions of sensors being “offline” and patients being “in danger”. assume si is a sensor (i∈{1, .., m}). we define propositions3 fail(si), switch off (si) and offline(si) as follows: fail(si) denotes that the sensor si fails; switch off (si) denotes that si is switched off; and offline(si) denotes that si is offline. now, we assume that if either the sensor fails or it has been switched off, then it is offline �[(fail(si)∨switch off (si)) ⇒ offline(si)], ∀i ∈{1, .., m} future time points”, ‘♦’ means “at some present or future time point”, and ‘©’ means “at the next time point”.) we now consider the cases where patients are in danger. assume p j is a patient ( j ∈{1, .., n}). we define the following propositions: in danger(p j) denotes that the patient p j is in danger; high heart rate(p j) denotes that the heart rate monitor of p j has detected p j’s heart rate to be higher than normal; low activity(pj) denotes that the activity monitors of the patient p j have detected that p j has moved very little for a period of time; motionless(p j) denotes that sensors have detected that p j has not moved at all for a period of time. if we assume that a patient 3 while we use a fragment of first-order language, the finiteness of the domain in question ensures that this is essentially propositional temporal logic. 7 / 15 volume 22 (2009) towards the verification of pervasive systems is in danger only if either his/her heart rate is higher than normal, he/she has moved very little with a period of time, or he/she has been inactive (but not in bed) for a while, then �[(high heart rate(p j)∨low activity(p j)∨motionless(p j)) ⇒ in danger(p j)] the truth of predicates such as ‘low activity’ can also be defined in terms of the values of sensors, together with some real-time and probabilistic constraints. we can now specify the property “if a patient is in danger sensors never go offline until the patient is no longer in danger” as follows: �[in danger(p j) ⇒ (¬ ∨ i∈{1,..,m} offline(si))u (¬in danger(p j))], ∀ j ∈{1, .., n} of course, this simple version assumes that the dangerous situation will eventually be resolved. let us now consider the second property. urgent actions related to the patients’ safety will always take place before other actions assume a is a set of urgent actions, and b is a set of non-urgent actions such that a∩b = /0 (again, this notion of urgency might well be defined in terms of some priority measure.) we use the proposition action(a) to denote that the action ‘a’ takes place. property (ii) states that if a patient is in danger, a non-urgent action should not take place before an urgent action. this can again be expressed in ltl as follows: �[in danger(p j) ⇒ (¬( ∨ b∈b action(b) u ∨ a∈a action(a))u ¬in danger(p j)], ∀ j ∈{1, .., n} this, of course, can be made more detailed and complex, for example if we delve into the properties of actions. if a patient is in danger, assistance should arrive within a given time we define the proposition assistance(p j) as denoting that assistance arrives for p j. if the specification were “if a patient is in danger, assistance should arrive eventually”, then we could formulate this in ltl as follows: �[in danger(p j) ⇒ ♦assistance(p j)], ∀ j ∈{1, .., n}. assistance must be available. since this is a real-time property, we must extend the logic to capture this specification. alternatively, we might use a logic such as tctl [acd90]. tctl is a branching-time temporal logic, specifically a real-time extension of the logic ctl [ce82], which can express real-time properties. thus, (ii) can be expressed in tctl as follows: ∀�[in danger(p j) ⇒∀♦≤t assistance(p j)], ∀ j ∈{1, .., n} this formula states that if a patient is in danger, it is guaranteed that some assistance will arrive within time t. (note that ‘∀’ here refers to all possible paths through the branching futures.) proc. fmis 2009 8 / 15 eceasst if a patient is in danger, assistance should arrive within a given time with a probability of 95% this property has both real-time and probabilistic aspects. therefore, tctl can no longer be used. in order to express this specification we can use the logic pctl [hj94], which can express quantitative bounds on the probability of system evolutions. thus, (iv) can be specified in pctl as follows: p≥0.95[in danger(p j) u ≤t assistance(p j)], ∀ j ∈{1, .., n} no component will take an action that it believes will endanger the patient the property (v) now includes a situation where each component’s beliefs must be taken into account. this suggests the use of a modal logic which uses possible worlds to capture the beliefs (or knowledge) that the component/agent has. temporal logics of knowledge or belief[fhmv96, hmv04] can be used to express the property (v) as they combine the temporal aspects with a modal logic of knowledge (or belief). assume ci (i ∈{1, ..,c}) is a component agent, and a is the set of all urgent and non-urgent actions. (v) might be expressed in a temporal logic of belief as: �kci [¬( ∨ a∈a action(a) ⇒ ♦ ∨ j∈{1,..,n} in danger(p j))], ∀i ∈{1, ..,c} 3.2.2 verification approaches there are various verification and model checking tools for the logics we introduced in the previous section. the properties (i)-(v) can be verified using a suitable model checker or verification tool described below. for the logic ltl some well-known tools are nusmv [ccgr99], spin [hol03], vis [gro96], trp++ [hk03]. nusmv is an extension of the model checking tool smv [mcm93], which is a software tool for the formal verification of finite state systems. unlike smv, nusmv provides facility for ltl model checking. spin is an ltl model checking system, supporting all correctness requirements expressible in ltl, but it can also be used as an efficient on-the-fly verifier for more basic safety and liveness properties. vis is a symbolic model checker supporting ltl. vis is able to synthesise finite state systems and/or verify properties of such systems, which have been specified hierarchically as a collection of interacting finite state machines. trp++ is a resolution based theorem prover for ltl. trp++ is based on resolution method for ltl [fdp01]. the best-known tools for the logic tctl are uppaal [bll+95] and kronos [bdm+98]. uppaal is an integrated tool environment for modelling, validation and verification of realtime systems modelled as networks of timed automata, extended with data types. the tool can be used for the automatic verification of safety and bounded liveness properties of real-time systems. kronos is a tool developed with the aim to verify complex real-time systems. in kronos, components of real-time systems are modelled by timed automata and the correctness requirements are expressed in the real-time temporal logic tctl. prism [hknp06] and apmc [hlmp04] are tools which can be used to model check pctl formulae. prism is a probabilistic model checker, a tool for formal modelling and analysis of systems which exhibit random or probabilistic behaviour. it supports three types of probabilistic models: discrete-time markov chains (dtmcs), continuous-time markov chains (ctmcs) and markov decision processes (mdps), plus extensions of these models with costs and rewards. the 9 / 15 volume 22 (2009) towards the verification of pervasive systems property specification language is mainly pctl; however, the tool also supports the temporal logics csl and ltl. the “approximate probabilistic model checker” (apmc) [hlmp04] is an approximate distributed model checker for fully probabilistic systems. apmc uses a randomised algorithm to approximate the probability that a temporal formula is true, by using sampling of execution paths of the system. finally, there are tools for tackling the verification of specifications in combined modal and temporal logics, such as temporal logics of belief or temporal logics of knowledge. although less well developed that some of the tools above, these range from deductive approaches [jhs+96, dfb02] to model checking for such logics [klp04, gm04, bdff08]. 4 discussion 4.1 limitations in section 3, we give some example properties of different dimensions, e.g. security and safety, and describe various tools that can be used in the verification and model checking of these properties. there are several limitations of these tools and techniques. as discussed in section 3.2.1 and section 3.2.2, different formal frameworks and tools are used to specify and verify different safety properties. for example, we should consider different temporal logics and model checking tools for real-time aspects, probabilistic aspects, belief aspects, etc. unfortunately, there is no standard methods which can be used for all aspects we are interested in. this makes it difficult to use a certain formal framework for all safety properties. another limitation is that each tool requires a different presentation of the model of the system. as we discussed in section 3.1.2, there exist several tools that allow us to verify systems w.r.t. security. however, some security properties of interest in pervasive systems are not supported well or even at all by these tools. indeed, while proverif (to name only one) is very efficient for verifying correspondence and reachability properties like injective agreement, it seems to reach its limits when used for verifying observational equivalence, and thus properties like untraceability. this is due to the fact that proverif considers a stronger relation than observational equivalence introducing in practise many false attacks. all the existing tools for verifying systems w.r.t. security abstract away from real time, focusing only on the sequencing of events. although this has many advantages, it is a serious limitation for reasoning about protocols such as distance bounding protocols, which rely on real time considerations. these protocols are often implemented in rfid-based systems, and thus in many pervasive applications, in order to prevent relay attacks. modelling time will thus be necessary for reasoning about pervasive systems. in the same way, some features of many protocols designed to achieve the above mentioned requirements are not efficiently handled by existing tools. in particular, proverif is also inefficient for systems with local non-monotonic mutable states. but, protocols which aim to enforce untraceability often rely on such states. more precisely, proverif handles all states as monotonic introducing again false attacks. as far as tools for verifying access control systems are concerned, the biggest limitation would be, as we already mentioned in section 3.1.2 that they usually cannot deal with unbounded access control models. moreover, it is difficult to express and model integrity constraints in these tools. proc. fmis 2009 10 / 15 eceasst finally, we have introduced three existing theories for formally specifying security properties, namely rw, proverif’s query language, and observational equivalence. it is important to note that they involve different levels of abstraction. indeed, one can reason at the access control policy level, or at some symbolic model for protocols level, or even at the implementation level. it will be very important, to link these levels in order to transfer results from more abstract levels to more concrete ones. 4.2 our approach as mentioned, a pervasive system might have quite complex specification aspects. most pervasive systems involve many dimensions that must be formalised and verified simultaneously. some of the dimensions that are common in pervasive systems are real-time aspects, uncertainty in sensing and communication, teamwork, collaboration and coordination, organizations, norms and social interactions, autonomous behaviour of agents, etc. current state of the art of formal methods appears incapable of coping with the verification demand introduced by pervasive systems, because reasoning about such systems requires combinations of multiple dimensions such as quantitative, continuous and stochastic behaviour to be considered, and requires proving properties which are quite subtle to express. for example, [zah09, kzf09] show that some simple properties of a typical pervasive system can be verified using a single verification tool; but a single verification approach cannot be used in verification of more complex properties involving different dimensions. generally speaking, while the formal description of pervasive systems is essentially multidimensional, we generally do not have verification tools for all the appropriate combinations. it is very clear that developing a framework covering all these dimensions is almost impossible, or verification over very complex frameworks is very challenging. in order to tackle the challenge of pervasive system verification, we aim to combine the power of established verification techniques, notably model checking, deduction, abstraction, etc. in particular, we are currently working on a generic framework for the model-checking of combined logics, including logics of knowledge, logics of context, real-time temporal logics, probabilistic temporal logics, etc. this work is based on the work of [fmd04], where a framework is given for the model-checking of combined modal temporal logics. this framework does not capture complex logics, which are quite essential in specifying different dimensions of pervasive systems. we therefore will extend this approach to provide a coherent framework for the formal analysis of pervasive systems. we will then apply the new technique to the verification of combined properties of a sample pervasive system, e.g. match. 5 conclusion this paper describes our analysis of a pervasive case study, match. as an initial step, we formally specify some safety and security properties of the match system. we discuss to what extent current state of the art formal methods are capable of coping with the verification demand introduced by pervasive systems, and we point out their limitations. we also give an account of our proposal for formal verification of pervasive systems. 11 / 15 volume 22 (2009) towards the verification of pervasive systems bibliography [abb+05] a. armando, d. a. basin, y. boichut, y. chevalier, l. compagna, j. cullar, p. h. drielsma, p.-c. ham, o. kouchnarenko, j. mantovani, s. mdersheim, d. von oheimb, m. rusinowitch, j. santiago, m. turuani, l. vigan, l. vigneron. the avispa tool for the automated validation of internet security protocols and applications. in etessami and rajamani (eds.), cav. lecture notes in computer science 3576, pp. 281–285. springer, 2005. [acd90] r. alur, c. courcoubetis, d. dill. model-checking for real-time systems. in proc. logic in computer science (lics). pp. 414–425. 1990. [af01] m. abadi, c. fournet. mobile values, new names, and secure communication. sigplan not. 36(3):104–115, 2001. [bdff08] r. h. bordini, l. a. dennis, b. farwer, m. fisher. automated verification of multiagent programs. in proc. 23rd ieee/acm international conference on automated software engineering (ase). pp. 69–78. 2008. [bdm+98] m. bozga, c. daws, o. maler, a. olivero, stavrostripakis, s. yovine. kronos: a model-checking tool for real-time systems. in cav ’98: proceedings of the 10th international conference on computer aided verification. pp. 546–550. springer verlag, 1998. [bec09] m. y. becker. specification and analysis of dynamic authorisation policies. in csf ’09: proceedings of the 2009 22nd ieee computer security foundations symposium. pp. 203–217. ieee computer society, 2009. [bla01] b. blanchet. an efficient cryptographic protocol verifier based on prolog rules. in csfw ’01: proceedings of the 14th ieee workshop on computer security foundations. p. 82. ieee computer society, washington, dc, usa, 2001. [bll+95] j. bengtsson, k. g. larsen, f. larsson, p. pettersson, w. yi. uppaal — a tool suite for automatic verification of real–time systems. in proceedings of workshop on verification and control of hybrid systems iii. lecture notes in computer science 1066, pp. 232–243. springer verlag, 1995. [ccgr99] a. cimatti, e. clarke, f. giunchiglia, m. roveri. nusmv: a new symbolic model verifier. in proceedings of international conference on computer-aided verification (cav’99). pp. 495–499. 1999. [ce82] e. m. clarke, e. a. emerson. using branching time temporal logic to synthesise synchronisation skeletons. science of computer programming 2:241–266, 1982. [cfj03] h. chen, t. finin, a. joshi. an ontology for context-aware pervasive computing environments. knowl. eng. rev. 18(3):197–207, 2003. proc. fmis 2009 12 / 15 eceasst [cm07] j. s. clark, m. r. mcgee-lennon. match: mobilising advanced technologies for care at home. 2007. poster at delivering healthcare for the 21st century, glasgow. [dfb02] c. dixon, m. fisher, a. bolotov. resolution in a logic of rational agency. artificial intelligence 139(1):47–89, july 2002. [dknp06] m. duflot, m. z. kwiatkowska, g. norman, d. parker. a formal analysis of bluetooth device discovery. sttt 8(6):621–632, 2006. [dlms99] n. a. durgin, p. d. lincoln, j. c. mitchell, a. scedrov. undecidability of bounded security protocols. in proceedings of the workshop on formal methods and security protocols-fmsp. 1999. [eme90] e. a. emerson. temporal and modal logic. in leeuwen (ed.), handbook of theoretical computer science. pp. 996–1072. elsevier, 1990. [fdp01] m. fisher, c. dixon, m. peim. clausal temporal resolution. acm transactions on computational logic 2(1):12–56, jan. 2001. [fhmv96] r. fagin, j. halpern, y. moses, m. vardi. reasoning about knowledge. mit press, 1996. [fis07] m. fisher. temporal representation and reasoning. in van harmelen et al. (eds.), handbook of knowledge representation. elsevier press, 2007. [fmd04] m. franceschet, a. montanari, m. de rijke. model checking for combined logics with an application to mobile systems. automated software engg. 11(3):289–321, 2004. [gjp05] s. l. garfinkel, a. juels, r. pappu. rfid privacy: an overview of problems and proposed solutions. ieee security and privacy 3(3):34–43, 2005. [gm04] p. gammie, r. van der meyden. mck: model checking the logic of knowledge. in proc. 16th international conference on computer aided verification (cav). lecture notes in computer science 3114, pp. 479–483. springer, 2004. [gro96] t. v. group. vis: a system for verification and synthesis. in proceedings of the 8th international conference on computer aided verification. pp. 428–432. 1996. [grs04] d. p. guelev, m. ryan, p. y. schobbens. model-checking access control policies. 3225:219–230, 2004. [hi04] k. henricksen, j. indulska. a software engineering framework for context-aware pervasive computing. in proceedings 2nd ieee conf. on pervasive computing and communications. pp. 77–86. 2004. [hj94] h. hansson, b. jonsson. a logic for reasoning about time and reliability. formal aspects of computing 6:102–111, 1994. 13 / 15 volume 22 (2009) towards the verification of pervasive systems [hk03] u. hustadt, b. konev. trp++ 2.0: a temporal resolution prover. in proceedings of conference on automated deduction (cade-19). pp. 274–278. 2003. [hknp06] a. hinton, m. kwiatkowska, g. norman, d. parker. prism: a tool for automatic verification of probabilistic systems. in proc. 12th international conference on tools and algorithms for the construction and analysis of systems (tacas’06). lecture notes in computer science 3920, pp. 441–444. springer, 2006. [hlmp04] t. hérault, r. lassaigne, f. magniette, s. peyronnet. approximate probabilistic model checking. in proc. 5th international conference on verification, model checking and abstract interpretation (vmcai’04). lecture notes in computer science 2937, pp. 307–329. springer, 2004. [hmv04] j. y. halpern, r. van der meyden, m. y. vardi. complete axiomatizations for reasoning about knowledge and time. siam j. comput. 33(3):674–703, 2004. [hol03] g. j. holzmann. the spin model checker. addison-wesley, 2003. [hru76] m. a. harrison, w. l. ruzzo, j. d. ullman. protection in operating systems. commun. acm 19(8):461–471, 1976. [jhs+96] g. jaeger, a. heuerding, s. schwendimann, f. achermann, p. balsiger, p. brambilla, h. zimmermann, m. bianchi, k. guggisberg, w. heinle. lwb–the logics workbench 1.0. http://lwbwww.unibe.ch:8080/lwbinfo.html, 1996. university of berne, switzerland. [jue06] a. juels. rfid security and privacy: a research survey. ieee journal on selected areas in communications 24(2):381–394, 2006. [klp04] m. kacprzak, a. lomuscio, w. penczek. from bounded to unbounded model checking for temporal epistemic logic. fundam. inform. 63(2-3):221–240, 2004. [kzf09] s. konur, a. a. zahrani, m. fisher. verification of a message forwarding system using prism. in preproc. of ninth international workshop on automated verification of critical systems. pp. 237–239. technical report, university of swansea, 2009. [low97] g. lowe. a hierarchy of authentication specifications. in csfw ’97: proceedings of the 10th ieee workshop on computer security foundations. pp. 31–43. ieee computer society, washington, dc, usa, 1997. [low98] g. lowe. casper: a compiler for the analysis of security protocols. journal of computer security 6(1-2):53–84, 1998. [mcm93] k. l. mcmillan. symbolic model checking. kluwer academic publishing, 1993. [mp92] z. manna, a. pnueli. the temporal logic of reactive and concurrent systems: specification. springer-verlag, new york, 1992. proc. fmis 2009 14 / 15 eceasst [pshc08] e. k. paik, m.-k. shin, j. hwang, j. choi. design goals and general requirements for future network. n13490, korea technology center, 2008. [sb05] q. z. sheng, b. benatallah. contextuml: a uml-based modeling language for model-driven development of context-aware web services development. volume 0, pp. 206–212. ieee computer society, 2005. [sim07] c. simons. cmp: a uml context modeling profile for mobile distributed systems. volume 0, p. 289b. ieee computer society, 2007. [wsre03] s. a. weis, s. e. sarma, r. l. rivest, d. w. engels. security and privacy aspects of low-cost radio. in hutter, d., müller, g., stephan, w., ullman, m., eds.: international conference on security in pervasive computing spc 2003, volume 2802 of lncs, boppard, germany. pp. 454–469. springer-verlag, march 2003. [wzgp04] x. h. wang, d. q. zhang, t. gu, h. k. pung. ontology-based context modeling and reasoning using owl. in context modeling and reasoning workshop at percom 04. pp. 18–22. 2004. [zah09] a. a. zahrani. formal analysis of a message forwarding system using prism. master’s thesis, department of computer science, university of liverpool, 2009. [zha06] n. zhang. acpeg, the access control policy evaluator and generator. july 2006. the tool can be obtained from www.cs.bham.ac.uk/ nxz or www.cs.bham.ac.uk/ mdr/research/projects/05-accesscontrol. 15 / 15 volume 22 (2009) introduction match overview security safety usability some sample properties security formalisation verification at present safety formalisation verification approaches discussion limitations our approach conclusion electronic communications of the easst volume 27 (2010) workshop über selbstorganisierende, adaptive, kontextsensitive verteilte systeme (saks 2010) vorwort / preface 3 pages guest editors: klaus david, michael zapf managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst vorwort das neue jahrtausend brachte die gesellschaft in eine neue ära der vernetzung und kommunikativität. schon seit vielen jahren wird über die vision der im leben allgegenwärtigen informationstechnologie, des ubiquitous computing, sowohl in der faszination ihrer möglichkeiten, als auch in bezug auf neue herausforderungen und auch gefahren diskutiert. in technischer hinsicht stehen wir jedoch erst am anfang, was die beherrschung komplexer, heterogener netze betrifft. statische konfiguration und manuelle steuerung der systeme scheiden in vielen fällen schon heute aus; systeme müssen sich dynamisch anpassen können. autonomie und selbstverwaltung sind hier prägende begriffe, genauso wie die adaptivität der von uns verwendeten systeme und der umgebungen, in denen wir uns bewegen. obwohl die konzepte von selbstorganisation, selbstmanagement, emergenz und anderer phänomene seit jahren intensiv beleuchtet wurden, bleiben noch immer viele fragen offen. gibt es standardverfahren – also methodiken –, die uns im entwicklungsprozess anleiten können? können wir von der natur und ihrer offensichtlich erfolgreichen selbstorganisation lernen? kann uns divide-and-conquer hier noch helfen, oder müssen wir auf eine „emergente“ lösung setzen? können wir adaptivität als aspekt in anwendungen hineintragen, oder muss sie fester bestandteil im entwurfsprozess sein? doch technische fragen alleine können nicht maßgeblich für die durchsetzung einer neuen technologie sein. sind adaptivität und selbstorganisation auch außerhalb unserer prototypen, also im großen maßstab, einsetzbar – können sie alltagstauglich werden? welche chancen eröffnen sich für den einsatz adaptiver und selbstorganisierender it? schließlich, und gerade im technischen kontext viel zu selten betrachtet werden fragen gesellschaftlicher und rechtlicher implikationen des einsatzes solcher systeme. im dem maße, wie wir die kontrolle an das system abgeben, muss das vertrauen in die einwandfreie funktion des systems wachsen. wir verfolgen in der themenwahl für diesen workshop einen betont interdisziplinären kurs, der sich damit von verwandten, eher technikorientierten veranstaltungen abgrenzt. die ersten beiträge befassen sich mit analysen aus dem bereich der wirtschaftsinformatik, während sich die weiteren beiträge technischer und konzeptioneller themen widmen. dieser workshop setzt die reihe der veranstaltungen fort, die mit erfolg in den jahren 2006 in kassel, 2007 an der kivs-tagung in bern, 2008 an der hochschule rhein-main in wiesbaden und 2009 im rahmen der kivs-2009-tagung in kassel stattfand und forschern gelegenheit bot, ihre beiträge zum thema selbstorganisation und adaption vorzustellen. universität kassel, juni 2010 michael zapf klaus david 1 / 3 volume 27 (2010) vorwort/preface preface the new millenium has guided our society into a new era of networking and communication. many discussions have arisen – from the fascinating new chances of new technologies and visions like ubiquitous computing to the challenges and threats that not only researchers but also our society has to face. from the technical point of view we are still close to the beginnings when trying to handle complex, heterogeneous networks. in many cases our traditional approaches like static configurations and manual adaptations do not apply anymore. systems are required to adapt themselves to cope with possibly unexpected changes in their environment. terms of interest in this context are autonomy and self-properties, including adaptability and self-management. however, despite the fact that self-organisation, self-management, emergence, and other phenomena have been subject of thorough research for more than a decade, we are still left with many unanswered questions. are there standard procedures – methodologies – which can guide us in the development of such systems? can we learn from nature which is obviously successful in creating and maintaining complex autonomous systems? do we have to extend or even replace the common divide-and-conquer approach in software engineering? is adaptivity an addon functionality, or do we have to consider it as an aspect to be woven into the complete software creation process? technical questions are not the only issue to solve when we plan to develop and deploy new technologies. for instance, do we really have a significant demand for self-organising systems in the way that we suggest ourselves in research? can they become everyday gadgets? can we expect new chances and opportunities from the wide deployment of such systems? and, most importantly but rarely considered in technical discussions: what societal and legal implications do we have to expect by this new information technology? if we increasingly pass control to the systems we also have to make sure that we can trust those systems. we conceived this workshop as an interdisciplinary event, differing in that respect from many other conferences and workshops in this area. accordingly, the first contributions feature analyses from business informatics, while the remaining articles are of technical and conceptional nature. this workshop continues the saks series, starting in 2006 at the university of kassel, hosted by the kivs conference in bern in 2007, continuing at the university of applied sciences rheinmain in wiesbaden in 2008, and being a workshop of the kivs conference in 2009, again at the university of kassel. university of kassel, june 2010 michael zapf klaus david saks 2010 2 / 3 eceasst organisation klaus david universität kassel michael zapf universität kassel programmkomitee / program committee matthias bäcker universität mannheim uwe baumgarten technische universität münchen christian becker universität mannheim markus bick escp europe campus berlin walter blocher universität kassel thilo böhmann international business school of service management hamburg volker boehme-neßler hochschule für technik und wirtschaft berlin georg borges ruhr-universität bochum klaus david universität kassel kurt geihs universität kassel klaus herrmann universität stuttgart thomas hoeren universität münster bernd holznagel universität münster ralf knackstedt universität münster reinhold kröger fachhochschule wiesbaden winfried lamersdorf universität hamburg jan-marco leimeister universität kassel wolfgang maass hochschule furtwangen university klaus mößner universität surrey (uk) gero mühl universität rostock christian müller-schloer universität hannover andreas polze hasso-plattner-institut alexander roßnagel universität kassel gregor schiele universität mannheim matthias trier technische universität berlin manfred wojciechowski fraunhofer isst michael zapf universität kassel 3 / 3 volume 27 (2010) model transformations to mitigate the semantic gap in embedded systems verification electronic communications of the easst volume 30 (2010) international colloquium on graph and model transformation on the occasion of the 65th birthday of hartmut ehrig (gramot 2010) model transformations to mitigate the semantic gap in embedded systems verification björn bartels, sabine glesner, thomas göthel 15 pages guest editors: claudia ermel, hartmut ehrig, fernando orejas, gabriele taentzer managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst model transformations to mitigate the semantic gap in embedded systems verification björn bartels, sabine glesner, thomas göthel software engineering for embedded systems group www.pes.tu-berlin.de berlin institute of technology (technische universität berlin) abstract: the vates project addresses the problem of verifying embedded software by employing a novel combination of methods that are well-established on the level of declarative models, in particular process-algebraic specifications, as well as of methods that work especially well on the level of executable code. beginning with executable code, we (automatically) extract a model in the form of a processalgebraic system description formulated in communicating sequential processes (csp). for this low-level csp description, we can prove that it refines a high-level csp specification which was previously developed. to relate the (low-level virtual machine) llvm code with the low-level csp model we designed an operational semantics of llvm. in ongoing work we investigate the extraction algorithm with respect to preservation of semantics. thereby, we are finally able to prove that given llvm code formally conforms to its high-level csp-based specification. in this paper we give an overview of results of vates so far and show that this approach has the potential to seamlessly integrate modeling, implementation, transformation and verification stages of embedded system development. keywords: (timed) csp, llvm, model extraction, theorem proving 1 introduction embedded systems are often employed in safety-critical areas. their correctness is therefore extremely important in order not to endanger human lives or risk high financial losses. however, the correctness of these systems is difficult to ensure. a particular challenge is that they are highly concurrent and that non-functional properties such as the satisfaction of real-time constraints play an important role. although there exist well-established techniques to verify abstract specifications of such systems, the verification of their actual implementations, e.g. in c++, is still an open problem. the vates1 project investigates exactly these questions. it starts from the hypothesis that software in embedded systems can be characterized by certain structures (distinguished e.g. by the processes and their pattern of communication) that characterize its mode of operation and that need to be retained when transformed into executable code. we investigate these structures by taking the boss [mbk06] operating system as an example. boss is a relatively small oper1 vates=verification and transformation of embedded systems, funded by the german research foundation (dfg). web: https://group.swt.tu-berlin.de/vates/ 1 / 15 volume 30 (2010) www.pes.tu-berlin.de model transformations to mitigate the semantic gap in embedded systems verification figure 1: the satellite bird ating system that has been developed at the fraunhofer institut first, berlin. it is operational since several years within the satellite bird2 (see figure 1) of the dlr3 designed for early fire detection. it needs to cope with high performance requirements while only featuring small resources. such small satellites are very interesting as they have the advantage to be relatively cheap and nevertheless to be very powerful at the same time. since boss has been designed with the goal of verifying it in mind, it is an ideal case study for the vates project. we propose a novel approach that makes well-established formal verification techniques for declarative process-algebraic specifications applicable to low-level software programs. to this end, we designed an algorithm that extracts a low-level csp model from the llvm compiler intermediate representation [kh09]. on this basis it can be shown that a given low-level model refines a high-level model which is also given in a csp-based formalism. the high-level specification may be investigated using our formalization of timed csp in the isabelle/hol theorem prover. it comprises a formalization of its operational semantics, several variants of bisimulations and an investigation of coalgebraic invariants which can be used to state certain liveness properties. currently, we are using this formalization in the context of so-called parameterized systems to verify infinite-state systems. the semantic gap between the intermediate code and the low-level csp model is closed by an investigation of the extraction algorithm. therefore, we defined a formal operational semantics of the low level virtual machine (llvm) intermediate language [la04]. the semantics is especially well-suited for the verification of embedded systems because it includes a memory model and a notion of non-determinism. furthermore, we establish a bisimulation relation between llvm and csp models. with that, we can prove that a given llvm program is a correct implementation of a given csp model. we plan to verify that our extraction algorithm preserves the semantics of llvm using this bisimulation. the remainder of this paper is structured as follows. in section 2 we briefly introduce timed csp, llvm and the isabelle/hol theorem prover. these constitute the main formalisms and tools that we use in our work. in section 3 we present the main results of the vates project so far: a formalization of timed csp in isabelle/hol, the extraction algorithm giving a lowlevel csp model from a given llvm program and an operational semantics of llvm in the isabelle/hol theorem prover. related work is discussed in section 4. finally, section 5 concludes this paper. 2 bispectral infra-red detection 3 deutsches zentrum für luftund raumfahrt (german aerospace center) proc. gramot 2010 2 / 15 eceasst p := st op | skip | a → p | a : a → pa | p; p | p�p | pup | p ‖ a p | p\a | p4p | p d b p | p4d p | x figure 2: syntax of timed csp 2 used formalisms and tools 2.1 timedcsp the development chain that we consider in the vates project, starts with a specification formulated in the real-time process calculus timed csp. it is an extension of hoare’s csp (communicating sequential processes) [hoa85] with timed process terms as well as timed semantics. besides the specification and verification of reactive and concurrent systems, this also allows for the verification of timeliness. in the following, we present some of the aspects of (timed) csp that are most important for understanding this paper. we refer to [sch99] for a comprehensive introduction to it. the syntax of timed csp is given in figure 2. it shares most of the operators with (untimed) csp: stop is a process which cannot do anything, skip cannot do anything except terminating indicated by the communication of the special event √ , a → p can first communicate a and then behave like process p. more convenient process operators are e.g. �, ‖ and \ denoting choice, parallel composition and hiding (of communication channels). timed csp extends the csp calculus with the timed primitives p d b q (timeout) and p4d q (timed interrupt). intuitively, the meaning of a timeout is that the process p can be triggered by some (external) event within d time units. if this happens, the timeout is resolved in favor of p. if the time expires without p being triggered, process q handles this situation, i.e., the timeout is resolved in favor of q. the timed interrupt construction has a similar meaning. here, p can (successfully) terminate within d time units, otherwise q is started. there exist two main types of semantics which are typically defined in the context of csp: the denotational (timed) failures semantics and the operational semantics which interprets (timed) csp as labeled transition system. for csp there exist well-established fully-automatic verification tools such as fdr [gra05] and prob [lf08]. fdr is well-suited for refinement checking of specifications based on the denotational semantics of csp. prob is well-suited to check temporal properties on csp processes. for timed csp there does not exist comprehensive tool support yet. therefore, we have formalized timed csp in the isabelle/hol theorem prover as briefly explained in section 3.1. 2.2 llvm the llvm compiler infrastructure provides a modular framework that can be easily extended by user-defined compilation passes. it also offers a diverse set of predefined analyses and several optimizations that can be used out of the box. it is designed to meet the needs of the development of custom source code transformation and analysis tools. the heart of the compiler infrastructure project is its intermediate representation (ir). it is a typed assembler-like language [la08], 3 / 15 volume 30 (2010) model transformations to mitigate the semantic gap in embedded systems verification llvm compiler ir csp-based specification c++ extracted csp model manual gcc llvm2csp refinement ≈ (2) (3) (4) (1) figure 3: the vates proof framework which is used internally as the basis for compiler optimizations. the llvm framework provides gcc-based frontends for a variety of programming languages, including c++. the existence of the gcc-based frontend enables us to adapt our approach, which currently focuses on c++, to a couple of other programming languages with little effort because it is source-languageindependent and relies on the llvm ir only. 2.3 isabelle/hol isabelle is a generic interactive proof assistant. it enables the formalization of mathematical models and provides tools for proving theorems that are mechanically checked. isabelle can be instantiated with different so-called object logics. one particular instantiation of it is isabelle/hol [npw02], which is based on higher order logic. the main advantage of hol is its very high expressive power. theorem provers based on hol require a high level of expertise but allow reasoning about models whose state space is too large (or even infinite) to be automatically checked by, say, a model checker. unlike model checking, proving theorems in a theorem prover like isabelle/hol is highly interactive. specifications have to be designed carefully to enable properties about them to be proved. 3 the vates approach the context of our approach is the vates project [ghj07]. its aim is to develop concepts for verifying the correctness of embedded software. our goal is to support the verification of crucial properties on all abstraction levels of such a software system, from the abstract specification down to executable code. the structure of our approach is given in figure 3. we start with a high-level csp-based specification (1) where crucial properties are verified. to this end, we have developed a formalization of timed csp in the isabelle/hol theorem prover and the proof technique of network invariants to verify infinite-state models. this is explained in section 3.1 in more detail. proc. gramot 2010 4 / 15 eceasst since we deal with embedded applications we want to allow manual code optimizations. we therefore assume that a software developer implements this high-level specification in a highlevel programming language such as c++ (2). to support this task we follow a prototyping approach presented in [kb10]. the high-level language can be further translated into the llvm intermediate representation (3), e.g. by using the gcc compiler. we chose to relate the abstract csp model and the intermediate llvm representation by automatically extracting a low-level csp model from it (4). this is done with our tool called llvm2csp which is explained in section 3.2. to show the refinement relation between the high-level and the low-level csp models, our formalization of timed csp or standard tools like fdr2 can be applied. a crucial part in our approach is to show that the extraction algorithm of llvm2csp preserves the semantics of llvm. to this end, we developed an operational semantics of llvm. due to the simplicity of intermediate languages, this is far more easy than defining a comprehensive formal semantics of e.g. c++. furthermore, we defined a variant of bisimulation which enables to semantically compare llvm programs and csp models. this is presented in section 3.3. altogether we are thereby able to formally relate the high-level csp-based specification and its corresponding implementation in llvm. note that following the overall approach we do not have to formalize the semantics of a high-level programming language like c++ which is known to be a complex task in its own. this becomes even more complicated by the introduction of concurrency. since we want to verify the whole development chain, the formalization of some intermediate representation is inevitable in each case. so by considering only the intermediate language layer circumvents the complex task of formally defining the semantics of c++. 3.1 verification with timed csp and network invariants in a previous paper [gg09], we proposed a formalization of the operational semantics of the process calculus timed csp in the isabelle/hol theorem prover [npw02]. this formalization is briefly explained in the following section. thereafter, we give an overview of current work which is based on the verification of infinite-state systems by using network invariants. 3.1.1 formalization of timed csp we combined the advantages of specifying real-time systems concisely and of mechanizing correctness proofs for properties of their specifications. we transfered the coalgebraic notions of bisimulation and of invariants to timed csp. this allows us on the one hand to relate behaviorally equivalent timed csp processes and on the other hand to state invariant behavior of processes. to this end, we formalized the syntax of timed csp as inductive datatype and the operational semantics as inductively defined set of triples. it is convenient to define (greatest) bisimulations and (greatest) invariants with respect to state predicates coinductively. we showed that all the considered kinds of bisimulation (strong, weak and weak timed) fulfill the congruence property with respect to the structure of timed csp processes. furthermore, we showed that coalgebraic invariants are well-suited to express certain liveness conditions and that these special invariants are closed under bisimulations. this property is useful for verification as shown in [gg09] in the context of a (rather simple) satellite system specification. 5 / 15 volume 30 (2010) model transformations to mitigate the semantic gap in embedded systems verification ... scheduler 1thread n 2thread n thread kn figure 4: structure of our scheduler model 3.1.2 parameterized systems and network invariants in ongoing work we extend this theory by so-called network invariants which are suitable to verify parameterized systems. our motivation is boss’s real-time scheduler which we have modeled in timed csp. the main structure of the model is given in figure 4. the overall system includes the scheduler itself and an arbitrarily large number of threads. the scheduler runs in parallel with arbitrarily many processes representing the threads to be managed. each thread is characterized by a name and a priority. in order to verify the scheduler system, the specific details of the threads should have no relevance. the scheduler system should, e.g., be deadlock-free in every case, i.e., for every possible list of threads. thus, an appropriate “induction” on the length of the list should be enough to state the system’s correctness. on a certain level of abstraction, all the csp processes representing threads are homogeneous from the scheduler’s perspective. of only importance is that each thread can communicate with the scheduler (e.g., yield control), and conversely the scheduler with each thread (e.g., give control to a thread). that is why the scheduler system can be seen as a parameterized system. as a consequence, verification of parameterized systems appears to be a promising technique to verify real-time operating systems. parameterized systems, as considered here, have the form: nn = p0 �p�···�p︸︷︷︸ n where the variable n (representing a natural number) is the parameter of the system. p0 is a control process and p�···�p a network of homogeneous processes. the operator � is some kind of parallel composition, which may be equipped with hiding and renaming of communication channels. network invariants can be used to verify parameterized systems by dividing the infinite-state verification problem into several (ideally finite-state) verification problems such that automatic verification tools can be used. in this section we focus on the presentation of the results of [wl90] concerning the inductive verification of parameterized systems as this is sufficient here. we have formalized these in the isabelle/hol theorem prover. we have, however, also formalized the slightly more general results of [km95] in isabelle. the idea of the “appropriate induction” is formalized in network invariants: to verify whether the system nn (regardless of the concrete parameter) implements a specification s, the main idea proc. gramot 2010 6 / 15 eceasst parameterized system network invariant invp0 ¯ p ¯ … ¯ p · s ? 1. p0 · inv 2. inv ¯ p · inv 3. inv · s to show: proof obligations invariant generation figure 5: framework for verifying parameterized systems is to use an appropriate invariant, which overapproximates each instance such that the abstracted system is still contained in the specification s. in [wl90], it is shown how network invariants can be set up in process algebras like ccs and csp. there, a general technique for verifying parameterized systems based on network invariants is presented: if one wishes to show that nn fulfills a certain specification s with respect to a certain implementation relation, i.e., nn ≤ s, it must basically be shown (for some process inv) that p0 ≤ inv, that inv�p ≤ inv and that inv ≤ s. the crucial point is to find an appropriate invariant inv. by induction on n, one can deduce that nn ≤ inv. by proving that the invariant is contained in the specification, i.e., inv ≤ s, one can deduce that nn ≤ s by transitivity of the implementation relation ≤. there are two main tasks that have to be performed when working with network invariants for verification. the first is finding a process which may serve as appropriate “network invariant”. the second task is showing that the found process is indeed a network invariant. in [cgj97], for example, a technique for finding network invariants based on network grammars is presented. in [gl08], the technique of network invariants is used in the context of timed systems. the approach adopted there consists of two steps. first, a safe abstraction is performed on a given timed system. thereby, safe means that ltl formulas are preserved under the abstraction. the abstract system is then used as a network invariant, which allows for the verification of the whole parameterized system. the overall verification flow that we use is given in figure 5. it is subject to current and future work to integrate invariant generation algorithms and automatic verification tools such as fdr2 [gra05] and uppaal [by04] into our existing timed csp formalization in isabelle/hol. in [oua01] and [dhq+08] it is presented how timed csp can be mapped to tock-csp4 or timed automata, respectively. these mappings make the usage of the automatic verification tools fdr2 and uppaal available for the verification of timed csp processes. in two current master theses we are implementing and evaluating these mappings. 3.2 relating low-level models and llvm in this section we give an overview of the parts of a low-level csp model which can automatically be derived from a llvm program using our llvm2csp tool [kh09]. the tool extracts csp models from concurrent programs. besides the behavior of the executed threads, the algorithm also uses information about the actual execution platform as explained in the following subsection. 4 a dialect of (untimed) csp 7 / 15 volume 30 (2010) model transformations to mitigate the semantic gap in embedded systems verification low-level components 1. platformspecific 3. applicationspecific low-level csp model hardware foundation libraries llvm ir of program automatic synthesis parameter synthesis 2. domainspecific manually modeled m figure 6: the three parts of the low-level csp model 3.2.1 synthesizing a low-level csp model the low-level cspm 5 model as depicted in figure 6 not only contains processes, types and channels that are automatically generated from the llvm ir of a program. it also contains two predefined parts which model the platformand domain-specific parts of the system under investigation. the platform-specific part comprises the environment model and hardware details, while the domain-specific part encompasses aspects that are common to a domain of applications, e.g. system startup and scheduling. these are provided as foundation libraries that the program builds on. in the long term, platformand domain-specific models are to be chosen from a library. the two parts are mostly manually modeled but are parameterized so that they can be reused by all applications of the domain they have been designed for. examples of such parameters are typing information for the channels and the set of thread identifiers. the third part is the application-specific one, which describes the behavior of the threads of a multithreaded program with respect to a set of given variable names, function calls and annotations6. we already used the llvm2csp tool successfully to create the low-level model of the scheduler of the boss operating system pico-kernel, which we presented in [kbgg09]. nevertheless we are constantly extending it by further features. 3.2.2 design of the low-level csp model as discussed in the previous section, the low-level csp model is divided into three distinct parts. the domainand platform-specific parts are manually modeled but are parameterized. the parameters and the application-specific part are synthesized from the llvm ir of the program under consideration. since we aim to use fdr2 for establishing the formal refinement relation between the specification and the low-level model, the low-level csp model must be designed in a way such that it can be handled by fdr2 as efficiently as possible. to that end, we followed the rules that are given in the fdr2 manual [gra05], for example, that renaming is to be used in preference to the parameterizing of a process definition. fig. 7 shows an example of modeling memory that stores four bit fields. it is constructed of 5 cspm is a machine readable form of csp extended by concepts from functional programming and is used as input language of the fdr2 refinement checker. 6 annotations can be realized using so-called ghost methods and ghost variables. a ghost variable is a variable that is used for verification purposes only and a ghost method is a method that modifies only ghost variables. ghost code is commonly compiled into the ir for verification purposes but is not part of the final binary. proc. gramot 2010 8 / 15 eceasst channel read1, write1, read2, write2, read3, write3, read4, write4 : {0,1} v1 = let v1’(v) = read1!v -> v1’(v) [] write1?x -> v1’(x) within read1?x -> v1 [] write1?x -> v1’(x) v2 = v1[[read1 [#uses=1] 3 %1 = icmp eq i32 %0, 1 ; [#uses=1] 4 br i1 %1, label %bb, label %bb1 5 bb: ; preds = %entry 6 %2 = load i32* %c, align 4 ; [#uses=1] 7 %3 = sub i32 %2, 2 ; [#uses=1] 8 store i32 %3, i32* %c, align 4 9 %4 = load i32* %c, align 4 ; [#uses=1] 10 store i32 %4, i32* %x, align 4 11 br label %bb2 bb1: ; preds = %entry 12 store i32 5, i32* %x, align 4 13 br label %bb2 bb2: ... figure 8: llvm code instruction that produces externally visible behavior in this case is the store instruction. for the store instruction, we label the edges of the lts with the value %dest ident.s(%source ident), if %dest ident is one of the variables to be tracked and s(%source ident) is its new value. for all other instructions we use the τ label indicating silent internal transitions. the right side of figure 9 shows the part of the labeled transition system that corresponds to the code snippet from figure 8. here, the set v of variables to be tracked is defined as {%i,%x}. first, in line 2 the content of a variable %b, that was marked non-deterministic and that can range over the values 0 and 1 is loaded to the register %0 and compared with the constant 1 in line 3. if the value of %b is equal to 0, the register %1 which holds the boolean value that is evaluated for the following branching condition is set to true. in this case, the execution continues at the block labeled with bb, otherwise the execution continues at label bb1. at label bb in line 6, the content of the variable %c is loaded to register %2, the constant 2 is subtracted in line 7 and the result is stored to variable %c in line 8. afterwards, the content of the variable %c is loaded to register %4 and stored to variable %x in lines 9 and 10. execution then continues at label bb2. at label bb1 in line 12, the constant 5 is stored to variable %x and then execution proceeds at label bb2. a set r of tuples is called a weak bisimulation relation if for every tuple (p,q) ∈ r holds that for every transition from q to some q′ labeled with some α there exists a path from p to some p′ with the same label such that the tuple (p′,q′) is again in r. here, a path consists of arbitrarily many transitions labeled with τ before and after a transition labeled with α . the converse property must also hold, i.e. every transition from p must have a counterpart from q. two states are called weakly bisimilar if there exists some weak bisimulation relation r where the corresponding tuple is in. the transition system shown in figure 9 is the disjoint union of the transition systems of csp and llvm. using the previously defined construction rules for the lts representing the llvm code, we can show that the llvm code in figure 8 is bisimilar to the following process term: p = %i.0 → (%x.5 → skip u%x.7 → skip). 11 / 15 volume 30 (2010) model transformations to mitigate the semantic gap in embedded systems verification p = i.0→ (x.5→skip ∏ x.7→skip) (x.5→skip ∏ x.7→skip) i.0 x.5 x.7 skip s[c=9] s[c=9,i=0] i.0 x.5 x.7 s[c=7,i=0] s[c=7,i=0 x=7] ... ... ... ... tau tau tau tau skip x.5→skip x.7→skip tau tau tau tau tau ... ... s[c=9,i=0, x=5] tau tau tau ... ... ... figure 9: the bisimulation relation between the two lts of csp (left) and of llvm (right) the process specifies that a variable %i is set to 0 and afterwards it is non-deterministically chosen if the variable %x is set to 5 or 7. figure 9 shows the two labeled transition systems and sketches the bisimulation relation. note that for every llvm instruction that does not change any of the variables from the predefined set v , the outgoing edges are labeled with τ . the nodes that are identified by the bisimulation relation are connected by the dashed arrows. in ongoing work we formalize this notion of bisimulation using isabelle/hol to achieve the mechanized verification of the llvm2csp extraction algorithm presented in the previous section. 4 related work the verification of low-level software systems and embedded operating systems has attracted several research projects. spec# [bls04] and vcc [cdh+09] are verification methodologies that translate high-level languages like c# and c to the intermediate language boogiepl. necessary verification information is annotated to the source code. to discharge verification conditions, the automatic theorem prover z3 is used. in contrast to our approach, boogiepl is not a compiler-intermediate representation but a language tailored for verification purposes. furthermore, we focus on refinement and transformation of a high-level specification to executable code rather than direct source-code verification. the avacs [bdf+07] project deals with the verification of complex (real-time) systems. verification is carried out at the specification level. transformations to and the verification of executable code are not considered within that project. another project concerned with the verification of a real-time operating system kernel is the vfiasco project [ht05]. verification is carried out at source code level by defining the denotational semantics for a subset of c++. one of its results is the verification of duff’s device, but proc. gramot 2010 12 / 15 eceasst the techniques were not applied to existing operating system components. the l4.verified project [ekd+07] uses a refinement approach that proves different layers of abstraction to be consistent. the lowest level of abstraction is given by c code, which is shown to be a refinement of a more abstract design. neither of these approaches covers concurrency. furthermore, the transformation to intermediate and executable code is not considered. closely related to our work is the verification of a real-time operating system controlling a space satellite using timed-csp-z [ssc03]. timed-csp-z models are translated into a petrinet-based formalism and the resulting petri-nets are analyzed. the approach focuses on deadlock detection. neither refinement proofs nor transformations to code are within the focus of this work. 5 conclusion and future work in this paper we have summarized the main results of the vates project so far. we briefly explained the formalization of timed csp in the isabelle/hol theorem prover and the potential of verification techniques for parameterized systems, namely network invariants, in the context of real-time operating systems. we presented the idea of the extraction algorithm which computes a csp model for a given llvm program. finally, we presented an operational semantics of llvm and showed how it is possible to formally relate llvm programs and csp models with the semantics based on bisimulations. we are currently working on the integration of timing behavior into the lower levels of our framework. since timing analyses are already possible on the most abstract layer, we need to extend the llvm2csp tool to generate timed csp models. to realize this, it is necessary to augment the llvm syntax and semantics with information about timing behavior. this includes accounting for processor-specific features like pipelining and cache management. since the theory underlying our approach is rather complex we plan to mechanize it entirely using the isabelle/hol theorem prover. thereby we can claim that our transformations are indeed correct. the results obtained so far are very promising. in future work, we will apply our verification approach to more complex systems, starting with the integration of further system components into our model of the boss operating system. we are convinced that our approach has the potential to enable a methodology that seamlessly integrates the modeling, implementation, transformation and verification stages of embedded real-time system development. references [bdf+07] b. becker, w. damm, m. fränzle, e. olderog, a. podelski, r. wilhelm. sfb/tr 14 avacs – automatic verification and analysis of complex systems. it – information technology 49(2):118–126, 2007. [bl05] s. blazy, x. leroy. formal verification of a memory model for c-like imperative languages. in lau and banach (eds.), icfem. lecture notes in computer sci13 / 15 volume 30 (2010) model transformations to mitigate the semantic gap in embedded systems verification ence 3785, pp. 280–299. springer, 2005. [bls04] m. barnett, k. r. m. leino, w. schulte. the spec# programming system: an overview. in cassis 2004. pp. 49–69. springer, 2004. [by04] j. bengtsson, w. yi. timed automata: semantics, algorithms and tools. in lectures on concurrency and preti nets. pp. 87–124. springer, 2004. [cdh+09] e. cohen, m. dahlweid, m. hillebrand, d. leinenbach, m. moskal, t. santen, w. schulte, s. tobies. vcc: a practical system for verifying concurrent c. in theorem proving in higher order logics. tphols-09, august 2009, munich, germany. lecture notes in computer science, lncs 5674, pp. 23–42. springer, 2009. [cgj97] e. m. clarke, o. grumberg, s. jha. verifying parameterized networks. acm trans. program. lang. syst. 19(5):726–750, 1997. [dhq+08] j. s. dong, p. hao, s. qin, j. sun, w. yi. timed automata patterns. ieee transactions on software engineering 34:844–859, 2008. [ekd+07] k. elphinstone, g. klein, p. derrin, t. roscoe, g. heiser. towards a practical, verified kernel. in hotos’07: proceedings of the 11th usenix workshop on hot topics in operating systems. pp. 1–6. usenix association, berkeley, ca, usa, 2007. [gg09] t. göthel, s. glesner. machine-checkable timed csp. in proc. of the first nasa formal methods symposium. pp. 126–135. nasa conference publication, 2009. [ghj07] s. glesner, s. helke, s. jähnichen. vates: verifying the core of a flying sensor. in proc. conquest 2007. dpunkt verlag, 2007. [gl08] o. grinchtein, m. leucker. network invariants for real-time systems. form. asp. comput. 20(6):619–635, 2008. [gra05] m. goldsmith, b. roscoe, p. armstrong. failures-divergence refinement fdr2 user manual. 2005. [hoa85] c. a. r. hoare. communicating sequential processes. prentice hall international, london, 1985. [ht05] m. hohmuth, h. tews. the vfiasco approach for a verified operating system. in proc. 2nd ecoop workshop on programming languages and operating systems. 2005. [kb10] m. kleine, b. bartels. on using csp for the construction of concurrent programs. in international conference on software engineering theory and practice (setp10). orlando, florida, usa, july 2010. in press. proc. gramot 2010 14 / 15 eceasst [kbgg09] m. kleine, b. bartels, t. göthel, s. glesner. verifying the implementation of an operating system scheduler. in 3rd ieee international symposium on theoretical aspects of software engineering (tase ’09). ieee computer society press, tianjin, china, july 2009. [kh09] m. kleine, s. helke. low level code verification based on csp models. in oliveira and woodcock (eds.), brazilian symposium on formal methods (sbmf 2009). springer, 2009. [kle09] m. kleine. using csp for software verification. in mousavi and sekerinski (eds.), proceedings of formal methods 2009 doctoral symposium. pp. 8–13. eindhoven university of technology, 2009. [km95] r. p. kurshan, k. l. mcmillan. a structural induction theorem for processes. inf. comput. 117(1):1–11, 1995. [la04] c. lattner, v. adve. llvm: a compilation framework for lifelong program analysis & transformation. in proceedings of the 2004 international symposium on code generation and optimization (cgo’04). palo alto, california, 2004. [la08] c. lattner, v. adve. llvm language reference manual. http://llvm.org/docs/ langref.html, 2008. [lf08] m. leuschel, m. fontaine. probing the depths of csp-m: a new fdr-compliant validation tool. icfem 2008, 2008. [mbk06] s. montenegro, k. briess, h. kayal. dependable software (boss) for the beesat pico satellite. in dasia2006. data systems in aerospace, berlin. 2006. [npw02] t. nipkow, l. c. paulson, m. wenzel. isabelle/hol — a proof assistant for higherorder logic. lncs 2283. springer, 2002. [oua01] j. ouaknine. discrete analysis of continuous behaviour in real-time concurrent systems. phd thesis, oxford university computing laboratory, 2001. [sch99] s. schneider. concurrent and real time systems: the csp approach. john wiley & sons, inc., new york, ny, usa, 1999. [ssc03] a. m. sherif, a. sampaio, s. cavalcante. specification and validation of the saci1 on-board computer using timed-csp-z and petri nets. in aalst and best (eds.), icatpn. lecture notes in computer science 2679, pp. 161–180. springer, 2003. [wl90] p. wolper, v. lovinfosse. verifying properties of large sets of processes with network invariants. in proceedings of the international workshop on automatic verification methods for finite state systems. pp. 68–80. springer, london, uk, 1990. 15 / 15 volume 30 (2010) http://llvm.org/docs/langref.html http://llvm.org/docs/langref.html introduction used formalisms and tools timedcsp llvm isabelle/hol the vates approach verification with timed csp and network invariants formalization of timed csp parameterized systems and network invariants relating low-level models and llvm synthesizing a low-level csp model design of the low-level csp model verification on the intermediate level operational semantics of llvm bisimulation relation related work conclusion and future work de-/re-constructing model transformation languages electronic communications of the easst volume 29 (2010) proceedings of the ninth international workshop on graph transformation and visual modeling techniques (gt-vmt 2010) de-/re-constructing model transformation languages eugene syriani and hans vangheluwe 14 pages guest editors: jochen küster, emilio tuosto managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst de-/re-constructing model transformation languages eugene syriani and hans vangheluwe mcgill university, school of computer science, montréal, canada {esyria,hv}@cs.mcgill.ca abstract: the diversity of today’s model transformation languages makes it hard to compare their expressiveness and provide a framework for interoperability. deconstructing and then re-constructing model transformation languages by means of a unique set of most primitive constructs facilitates both. we thus introduce t-core, a collection of primitives for model transformation. combining t-core with a (programming or modelling) language enables the design of model transformation formalisms. we show how basic and more advanced features from existing model transformation languages can be re-constructed using t-core primitives. keywords: transformation primitives, multi-paradigm model transformation 1 introduction a plethora of different rule-based model transformation languages and supporting tools exist today. they cover all (or a subset of) the well-known essential features of model transformation [sv09c]: atomicity, sequencing, branching, looping, non-determinism, recursion, parallelism, back-tracking, hierarchy, and time. for such languages, the semantics (and hence implementation) of a transformation rule consists of the appropriate combination of building blocks implementing primitive operations such as matching, rewriting, and often a validation of consistent application of the rule. the abovementioned essential features of transformation languages are achieved by implicitly or explicitly specifying “rule scheduling”. languages such as atl [jk06], fujaba [fntz00], great [akk+06], motif [sv09b], viatra [vb07], and vmts [llmc06] include constructs to specify the order in which rules are applied. this often takes the form of a control flow language. without loss of generality, we consider transformation languages where models are encoded as typed, attributed graphs. the diversity of transformation languages makes it hard, on the one hand, to compare their expressiveness and, on the other hand, to provide a framework for interoperability (i.e., meaningfully combining transformation units specified in different transformation languages). one approach is to express model transformation at the level of primitive building blocks. deconstructing and then re-constructing model transformation languages by means of a small set of most primitive constructs offers a common basis to compare the expressiveness of transformation languages. it may also help in the discovery of novel, possibly in domain-specific, model transformation constructs by combining the building blocks in new ways. furthermore, it allows implementers to focus on maximizing the efficiency of the primitives in isolation, leading to more efficient transformations overall. lastly, once re-constructed, different transformation languages can seamlessly interoperate as they are built on the same primitives. this use of common primitives in turn allows for global as well as inter-rule optimization. 1 / 14 volume 29 (2010) mailto:\protect \t1\textbraceleft esyria,hv\protect \t1\textbraceright @cs.mcgill.ca de-/re-constructing model transformation figure 1: the t-core module we introduce t-core, a collection of transformation language primitives for model transformation in section 2. section 3 motivates the choice of its primitives. section 4 shows how transformation entities, common as well as more esoteric, can be re-constructed. section 5 describes related work and section 6 draws conclusions and presents directions for future work. 2 de-constructing transformation languages we propose here a collection of model transformation primitives. the class diagram in figure 1 presents the module t-core encapsulating model transformation primitives. t-core consists of eight primitive constructs (primitive objects): a matcher, iterator, rewriter, resolver, rollbacker, composer, selector, and synchronizer. the first five are ruleprimitive elements and represent the building blocks of a single transformation unit. t-core is not restricted to any form of specification of a transformation unit. in fact, we consider only preconditionpatterns and postcondiproc. gt-vmt 2010 2 / 14 eceasst tionpatterns. for example, in rule-based model transformation, the transformation unit is a rule. the preconditionpattern determines its applicability: it is usually described with a left-hand side (lhs) and optional negative application conditions (nacs). it also consists of a postconditionpattern which imposes a pattern to be found after the rule was applied: it is usually described with a right-hand side (rhs). ruleprimitives are to be distinguished from the controlprimitives, which are used in the design of the rule scheduling part of the transformation language. a meaningful composition of all these different constructs in a composer object allows modular encapsulation of and communication between primitive objects. primitives exchange three different types of messages: packet, cancel, and exception. a packet π represents the host model together with sufficient information for interand intra-rule processing of the matches. π thus holds the current model (graph in our case) graph, the matchset, and a reference to the current preconditionpattern identifying a matchset. a matchset refers to a condition pattern and contains the actual matches as well as a reference to the matchtorewrite. note that each matchset of a packet has a unique condition, used for identifying the set of matches. a match consists of a sub-graph of the graph in π where each element is bound to an element in graph. some elements (nodes) of the match may be labelled as pivots, which allows certain elements of the model to be identified and passed between rules. a cancel message ϕ is meant to cancel the activity of an active primitive element (especially used in the presence of a selector). finally, specific exceptions χ can be explicitly raised, carrying along the currently processed packet π (πφ is used to represent the empty packet). all the primitive constructs can receive packets by invoking either their packetin, nextin, successin, or failin methods. the result of calling one of these methods sets the primitive in success or failure mode as recorded by the issuccess attribute. cancel messages are received from the cancelin method. next, we describe in detail the behaviour of the different methods supported by the primitive elements. a complete description can be found in [sv09a]. 2.1 matcher algorithm 1 matcher.packetin(π ) m ← (all) matches of condition found in π.graph if ∃〈condition,m′〉∈ π.matchsets then m′ ← m′∪m else add 〈condition,m〉 to π.matchsets end if π.current ← condition issuccess ← m 6= /0 return π the matcher finds all possible matches of the condition pattern on the graph embedded in the packet it receives from its packetin method. the transformation modeller may optimize the matching by setting the findall attribute to false when he a priori knows that at most one match of this matcher will be processed in the overall transformation. the matching also considers the pivot mapping (if present) of the current match of π . after matching the graph, the matcher stores the different matches in the packet as described in algorithm 1. some implementations may, for example, parametrize the matcher by the condition pattern or embed it directly in the matcher. the transformation units (e.g., rules) may be compiled in pre/post-condition patterns or interpreted, but this is a tool implementation issue which we do not discuss here. 2.2 rewriter as described in algorithm 2, the rewriter applies the required transformation for its condition on the match specified in the packet it receives from its packetin method. that match is consumed 3 / 14 volume 29 (2010) de-/re-constructing model transformation algorithm 2 rewriter.packetin(π ) if π is invalid then issuccess ← false exception ← χ(π) return π end if m ←〈condition.pre,m〉∈ π.matchsets apply transformation on m.matchtorewrite if transformation failed then issuccess ← false exception ← χ(π) return π end if set all modified nodes in m to dirty remove 〈condition,m〉 from π.matchsets issuccess ← true return π by the rewriter: no other operation can be further applied on it. some validations are made in the rewriter to verify, for example, that π.current.condition = condition.pre or that no error occurred during the transformation. in our approach, a modification (update or delete) of an element in {m|〈condition.pre,m〉 ∈ π.matchsets} is automatically propagated to the other matches, if applicable. 2.3 iterator the iterator chooses a match among the set of matches of the current condition of the packet it receives from its packetin method, as described in algorithm 3. the match is chosen randomly in a monte-carlo sense, repeatable using sampling from a uniform distribution to provide a reproducible, fair sampling. when its nextin method is called, the iterator chooses another match as long as the maximum number of iterations maxiterations (possibly infinite) is not yet reached, as described in algorithm 4. in the case of multiple occurrences of a matchset identified by π .current, the iterator selects the last matchset. algorithm 3 iterator.packetin(π ) if 〈π.current,m〉∈ π.matchsets then choose m ∈ m m.matchtorewrite ← m remiterations ← maxiterations−1 issuccess ← true return π else issuccess ← false return π end if algorithm 4 iterator.nextin(π ) if 〈π.current,m〉∈ π.matchsets and remiterations > 0 then choose m ∈ m m.matchtorewrite ← m remiterations ← remiterations−1 issuccess ← true return π else issuccess ← false return π end if 2.4 resolver algorithm 5 resolver.packetin(π ) for all condition c ∈{c|〈c,m〉∈ π.matchsets} do if externalmatchesonly and c = π.current then continue end if for all match m ∈ m do if m has a dirty node then if customresolution(π) then issuccess ← true return π else if defaultresolution(π) then issuccess ← true return π else issuccess ← false exception ← χ(π) return π end if end if end for end for issuccess ← false exception ← χ(π) return π the resolver resolves a potential conflict between matches and rewritings as described in algorithm 5. for the moment, the resolver detects conflicts in a simple conservative way: it prohibits any change to other matches in the packet (check for dirty nodes). however, it does not verify if a modified match is still valid with respect to its pre-condition pattern. the externalmatchesonly attribute specifies whether the conflict detection should also consider matches from its match set identified by π.current or not. in the case of conflict, a default resolution function is provided but the user may also override it. 2.5 rollbacker the rollbacker is only used to provide back-tracking capabilities to its transformation rule. consequently, proc. gt-vmt 2010 4 / 14 eceasst it is used as a recovery point that allows backward recovery of packets, e.g., by means of checkpointing. the packetin method establishes a checkpoint of the received packet and the nextin method restores the last checkpoint to roll-back the packet to its previous state. again, a maximum number of iterations can be specified. algorithm 6 rollbacker.packetin(π ) establish(π) remiterations ← maxiterations−1 issuccess ← true return π algorithm 7 rollbacker.nextin(π ) if 〈π.current,m〉∈ π.matchsets and remiterations > 0 then remiterations ← remiterations−1 issuccess ← true return π else if remiterations > 0 then π̂ ← restore() remiterations ← remiterations−1 issuccess ← true return π̂ else issuccess ← false return π end if 2.6 selector the selector is used when a choice needs to be made between multiple packets processed concurrently by different constructs. it allows exactly one of them to be processed further. when its successin (or failin) method is called, the received packet is stored in its success (or fail) collection, respectively. note that, unlike the previous described methods, it is only when the select method in algorithm 8 is called that a packet is returned, chosen from success. the selection is random in the same way as in the iterator. when the cancel method is invoked, the two collections are cleared and a cancel message ϕ is returned where the exclusions set consists of the singleton π.current (meaning that operations of the chosen condition should not be cancelled). 2.7 synchronizer the synchronizer is used when multiple packets processed in parallel need to be synchronized. it is parametrized by the number of threads to synchronize. this number is known at design-time. its successin and failin methods behave exactly like those of the selector. the synchronizer is in success mode only if all threads have terminated by never invoking failin. the merge method “merges” the packets in success, as described in algorithm 9. a trivial default merge function is provided by unifying and “gluing” the set of packets. nevertheless, it first conservatively verifies the validity of the received packets by prohibiting overlapping matches between them. if it fails, the user can specify a custom merge function. this avoids the need for static parallel independence detection. instead it is done at run-time and the transformation modeller must explicitly describe the handler. one pragmatic use of that solution is, for instance, to let the transformation run once to detect the possible conflicts and then the modeller may handle these cases by modifying the transformation model. 5 / 14 volume 29 (2010) de-/re-constructing model transformation algorithm 8 selector.select() if success 6= /0 then π̂ ← choose from success issuccess ← true else if fail 6= /0 then π̂ ← choose from fail issuccess ← false else π̂ ← πφ issuccess ← false exception ← χ(πφ ) end if success ← /0 fail ← /0 return π̂ algorithm 9 synchronizer.merge() if |success|= threads then if custommerge() then π̂ ← the merged packet in success issuccess ← true success ← /0 fail ← /0 return π̂ else if defaultmerge() then π̂ ← the merged packet in success issuccess ← true success ← /0 fail ← /0 return π̂ else issuccess ← false exception ← χ(πφ ) return πφ end if else if |success|+ |fail|= threads then π̂ ← choose from fail issuccess ← false return π̂ else issuccess ← false exception ← χ(πφ ) return πφ end if 2.8 composer the composer serves as a modular encapsulation interface of the elements in its primitives list. when one of its packetin or nextin methods is invoked, it is up to the user to manage subsequent method invocations to its primitives. nevertheless, when the cancelin method is called, the composer invokes the cancelin method of all its sub-primitives. this cancels the current action of the primitive object by resetting its state to its initial state. cancelling happens only if it is actively processing a packet π such that the current condition of π is not in ϕ.exclusions, where ϕ is the received cancel message. in the case of a matcher, since the current condition of the packet may not already be set, the cancelin also verifies that the condition of the matcher is not in the exclusions list. the interruption of activity can, for instance, be implemented as a pre-emptive asynchronous method call of cancelin. proc. gt-vmt 2010 6 / 14 eceasst 3 t-core: a minimal collection of transformation primitives in the de-construction process of transformation languages into a collection of primitives, questions like “up to what level?” or “what to include and what to exclude?” arise. the proposed t-core module answers these questions in the following way. in a model transformation language, the smallest transformation unit is traditionally the rule. a rule is a complex structure with a declarative part and an operational part. the declarative part of a rule consists of the specification of the rule (e.g., lhs/rhs and optionally nac in graph transformation rules). however, t-core is not restricted to any form of specification let it be rule-based, constraint-based, or function-based. in fact, some languages require units with only a pre-condition to satisfy, while other with a preand a post-condition. some even allow arbitrary permutations of repetitions of the two. in t-core, either a preconditionpattern or both a preand a postconditionpattern must be specified. for example, a graph transformation rule can be represented in t-core as a couple of a preand a post-condition pattern, where the latter has a reference to the former to satisfy the semantics of the interface k (in the l ← k → r algebraic graph transformation rules) and be able to perform the transformation. transformation languages where rules are expressed bidirectionally or as functions are supported in t-core as long as they can be represented as preand post-condition patterns. the operational part of a rule describes how it executes. this operation is often encapsulated in the form of an algorithm (with possibly local optimizations). nevertheless, it always consists of a matching phase, i.e., finding instances of the model that satisfy the pre-condition and of a transformation phase, i.e., applying the rule such that the resulting model satisfies the post-condition. t-core distinguishes these two phases by offering a matcher and a rewriter as primitives. consequently, the matcher’s condition only consists of a pre-condition pattern and the rewriter then needs a post-condition pattern that can access the pre-condition pattern to perform the rewrite. combinations of matchers and rewriters in sequence can then represent a sequence of simple graph transformation rules: match-rewrite-match-rewrite. moreover, because of the separation of these two phases, more general and complex transformation units may be built, such as: match-match-match or match-match-rewrite-rewrite. the former is a query where each matcher filters the conditions of the query. the latter is a nesting of transformation rules. in this case, however, overlapping matches between different matchers and then rewrites on the overlapping elements may lead to inconsistent transformations or even non-sense. this is why a resolver can be used from t-core to safely allow match-rewrite combinations. the data structure exchanged between t-core ruleprimitives in the form of packets contains sufficient information for each primitive to process it as described in the various algorithms in section 2. the match allows to refer to all model elements that satisfy a pre-condition pattern. the pivot mappings allow elements of certain matches to be bound to elements of previously matched elements. the pivot mapping is equivalent to passing parameters between rules as will be shown in the example in section 4.1. the matchset allows to delay the rewriting phase instead of having to rewrite directly after matching. packets conceptually carry the complete model (optimized implementation may relax this) which allows concurrent execution of transformations. the selector and the synchronizer both permit to join branches or threads of concurrent transformations. also, having separated the matching from the rewriting enables to manage the matches and the results of a rewrite by fur7 / 14 volume 29 (2010) de-/re-constructing model transformation ther operators. advanced features such as iteration over multiple matches or back-tracking to a previous state in the transformation are also supported in t-core. since t-core is a low-level collection of model transformation primitives, combining its primitives to achieve relevant and useful transformations may involve a large number of these primitive operators. therefore, it is necessary to provide a “grouping” mechanism. the composer allows to modularly organize t-core primitives. it serves as an interface to the primitives it encapsulates. this then enables scaling of transformations built on t-core to large and complex model transformations designs. t-core is presented here as an open module which can be extended, through inheritance for example. one could add other primitive model transformation building blocks. for instance, a conformance check operator may be useful to verify if the resulting transformed model still conforms to its meta-model. it can be interleaved between sequences of rewrites or used at the end of the overall transformation as suggested in [kms+09]. we believe however that such new constructs should either be part of the (programming or modelling) language or the tool in which t-core is integrated, to keep t-core as primitive as possible. 4 re-constructing transformation languages (a) (b) (c) (d) figure 2: combining t-core with other languages allows to re-construct existing and new languages having de-constructed model transformation languages in a collection of model transformaproc. gt-vmt 2010 8 / 14 eceasst tion primitives makes it easier to reason about transformation languages. in fact, properly combining t-core primitives with an existing well-formed programming or modelling language allows us to re-construct some already existing transformation languages and even construct new ones [sv09a]. figure 2 shows some examples of combinations of t-core with other languages. figure 2(a) and figure 2(b) combine a subset of t-core with a simple (programming) language which offers sequencing, branching, and looping mechanisms (as proposed in böhm-jocapini’s structured program theorem [bj66]). we will refer to such a language as an sbl language. the first combination only involves the matcher and its preconditionpattern, packet messages to exchange, and the composer to organize the primitives. these t-core primitives integrated in an sbl language lead to a query language. since only matching operations can be performed on the model, they represent queries where the resulting packet holds the set of all elements (sub-graph) of the model (graph) that satisfy the desired pre-conditions. including other t-core primitives such as the rewriter promotes the query language to a transformation language. figure 2(b) enumerates the necessary t-core primitives combined with an sbl language to design a complete sequential model transformation language. replacing the sbl language by another one, such as uml activity diagrams in figure 2(c), allows us to re-construct story diagrams [fntz00], for example, since they are defined as a combination of uml activity and collaboration diagrams with graph transformation features. other combinations involving the whole t-core module may lead to novel transformation language with exception handling and the notion of timed model transformations when combined with a discrete-event modelling language [sv09a]. we now present the re-construction of two transformation features using the combination of an sbl language with t-core as in figure 2(b). 4.1 re-constructing story diagrams in the context of object-oriented reverse-engineering, the fujaba tool allows the user to specify the content of a class method by means of story diagrams. a story diagram organizes figure 3: the fujaba dosubdemo transformation showing a forall pattern and two statement activities the behaviour of a method with activities and transitions. an activity can be a story pattern or a statement activity. the former consists of a graph transformation rule and the latter is java code. figure 3 shows such a story diagram taken from the dodemo method example in [fntz00]. this snippet represents an elevator loading people on a given floor of a house who wish to go to another level. the rule in the pattern is specified in a uml collaboration diagram-like notation with objects and associations. objects with implicit types (e.g., this, l2, and e1) are bound objects from previous patterns or variables in the context of the current method. the story pattern 6 is a for-all pattern. its rule is applied on all matches found looping over the unbound objects (e.g., p4, and l4). the outgoing transition labelled each 9 / 14 volume 29 (2010) de-/re-constructing model transformation time applies statement 7 after each iteration of the for-all pattern. this activity allows the pattern to simulate random choices of levels for different people in the elevator. when all iterations have been completed, the flow proceeds with statement 8 reached by the transition labelled end. the latter activity simulates the elevator going one level up. figure 4: the three motif rules for the dosubdemo transformation algorithm 10 makechoicec.packetin(π ) π ← makechoicem.packetin(π) if not makechoicem.issuccess then issuccess ← false return π end if π ← makechoicei.packetin(π) if not makechoicei.issuccess then issuccess ← true return π end if π ← makechoicew.packetin(π) if not makechoicew.issuccess then issuccess ← false return π end if π ← makechoicer.packetin(π) if not makechoicer.issuccess then issuccess ← false return π end if issuccess ← true return π we now show how to re-construct this non-trivial story diagram transformation from an slb language combined with t-core. an instance of that combination is called a t-core model. first, we design the rules needed for the conditions of rule primitives. figure 4 describes the three necessary rules corresponding to the three story diagram activities. we use the syntax of motif [sv09b] where the central compartment is the lhs, the compartment on the right of the arrow head is the rhs and the compartment(s) on the left of dashed lines are the nac(s). the concrete syntax for representing the pattern elements was chosen to be intuitively close enough to the fujaba graphical representation. numeric labels are used to uniquely identify different elements across compartments. elements with an alpha-numeric label between parentheses denote pivots. a right-directed arrow on top of such a label depicts that the model element matched for this pattern element is assigned to a pivot (e.g., p4 and l4). if the arrow is directed to the left, then the model element matched for this pattern element is bound to the specified pivot (e.g., this and e1). the t-core model equivalent to the original dosubdemo transformation consists of a composer dosubdemoc. it is composed of two composers loadc and nextstepc each containing a matcher, an iterator, a rewriter, and a resolver. the packetin method of dosubdemoc first calls the corresponding method of loadc and then feeds the returned packet to the packetin method of nextstepc. this ensures that the output packet of the overall transformation is the result of first loading all the person objects and then moving the elevator by one step. makechoicec and nextstepc behave as simple transformation rules. their packetin method behaves as specified in algorithm 10. first, the matcher is tried on the input packet. note that the conditions of the matchers makechoicem and nextstepm are the lhss of rules makechoice and nextstep, respectively. if it fails, the composer goes into failure mode and the packet is returned. then, the iterator chooses a match. subsequently, the rewriter attempts to transform this match. proc. gt-vmt 2010 10 / 14 eceasst algorithm 11 loadc.packetin(π ) π ← loadm.packetin(π) if not loadm.issuccess then issuccess ← false return π end if π ← loadi.packetin(π) while true do if not loadi.issuccess then issuccess ← true return π end if π ← loadw.packetin(π) if not loadw.issuccess then issuccess ← false return π end if π ← loadr.packetin(π) if not loadr.issuccess then issuccess ← false return π end if π ← makechoicec.packetin(π) π ← loadi.nextin(π) end while issuccess ← true return π note that the conditions of the rewriters makechoicew and nextstepw are the rhss of rules makechoice and nextstep, respectively. if it fails, an exception is thrown and the transformation stops. otherwise, the resolver verifies the application of this pattern with respect to other matches in the transformed packet. the behaviour of the resolution function will be elaborated on later. finally, on a successful resolution, the resulting packet is output and the composer is put in success mode. loadc is the composer that emulates the for-all pattern of the example. algorithm 11 specifies that behaviour. after finding all matches with loadm (whose condition is the lhs and the nac of rule load), the packet is forwarded to the iterator loadi to choose a match. the iteration is emulated by a loop with the failure mode of loadi as the breaking condition. inside the loop, loadw rewrites the chosen match and loadr resolves possible conflicts. then, the resulting packet is sent to makechoicec to fulfil the each time transition of the story digram. after that, the nextin method of loadi is invoked with the new packet to choose a new match and proceed in the loop. having seen the overall t-core transformation model, let us inspect how the different resolvers should behave in order to provide a correct and complete transformation. the first rewriter called is loadr and the first time it receives a packet is when a transformation is applied on one of the matches of loadm. therefore each match consists of the same house (since it is a bound node), two levels, an elevator, and the associations between them. on the other hand, loadw only adds a person and links it to a level. therefore the default resolution function of loadr applies successfully, since no matched element is modified nor is the nac violated in any other match. the next resolver is makechoicer which is in the same loop as loadr. there, the house is conflicting with all the matches in the packet according to the conservative default resolution function. note that makechoicem finds at most one match (the bound house element). however, makechoicew does not really conflict with matches found in loadm. we therefore specify a custom resolution function for makechoicer that always succeeds. the same applies for nextstepr. 4.2 re-constructing amalgamated rules figure 5: the transformation rules for the repotting geraniums example in a recent paper, rensink et al. claim that the repotting the geraniums example is inexpressible in most transformation formalisms [rk09]. the authors propose a transformation language that uses an amalgamation scheme for nested graph transformation rules. as we have seen in the previous example, nesting transformation rules is possible in t-core and will be used to solve the problem. it consists of repotting all flowering geraniums whose pots have cracked. figure 5 illustrates the two nested 11 / 14 volume 29 (2010) de-/re-constructing model transformation algorithm 12 basec.packetin(π ) π ← basem.packetin(π) if not basem.issuccess then issuccess ← false return π end if while true do π ← basei.packetin(π) if not basei.issuccess then issuccess ← true return π end if π ← basew.packetin(π) if not basew.issuccess then issuccess ← false return π end if π ← baser.packetin(π) if not baser.issuccess then issuccess ← false return π end if π ← innerc.packetin(π) π ← basem.packetin(π) if not basem.issuccess then issuccess ← true return π end if end while graph transformation rules involved and algorithm 12 demonstrates the composition of primitive t-core elements encoding these rules. basem (with, as condition, the lhs of rule base) finds all broken pots containing a flowering geranium, given the input packet containing the input graph. the set of matches resulting in the packet are the combination of all flowering geraniums and their pot container. from then on starts the loop. first, basei chooses a match. if one is chosen, basew transforms this match and baser resolves any conflicts. in this case, basew only creates a new unbroken pot and assigns pivots. therefore, baser’s resolution function always succeeds. in fact, the resolver is not needed here, but we include it for consistency. the innerc composer encodes the inner rule which finds the two bound pots and moves a flourishing flower in the broken pot to the unbroken one. in order to iterate over all the flowers in the broken pot, the innerc.packetin method has the exact same behaviour as loadc.packetin in algorithm 11, with the exception of not calling a sub-composer (like makechoicec). note that an always successful custom resolution function for innerr is required. after the resolver successfully outputs the packet, the inner rule is applied. then (and also if basei had failed) basem.packetin is called again with the resulting packet. the loop ends when the basem.packetin method call inside the loop fails, which entails basec to return the final packet in success mode. 5 related work the closer work to our knowledge is [vjbb09]. in the context of global model management, the authors define a type system offering a set of primitives for model transformation. the advantage of our approach is that t-core is a described here as a module and is thus directly implementable. we have recently incorporated t-core with an asynchronous and timed modelling language [sv09a] which allowed us to re-implement the two examples in section 4 as well as others. also, the approach described in [vjbb09], does not deal with exceptions at all. nevertheless, their framework is able to achieve higher-order transformations, which we did not consider in this paper. the gp graph transformation language [mp08] also offers transformation primitives. they however focus more on the scheduling of the rules then on the rules themselves. their scheduling (control) language is an extension of an sbl language. our approach is more general since much more complex scheduling languages (e.g., allowing concurrent and timed transformation execution) can be integrated with t-core. although it performs very efficiently, the application area of gp is more limited, as it can not deal with arbitrary domain-specific models. other graph transformation tools, such as viatra [vb07] and great [akk+06], have their own virtual machine used as an api. in our approach, since the primitive operations are modelled, they are completely compatible with other existing model transformation frameworks. proc. gt-vmt 2010 12 / 14 eceasst 6 conclusion in this paper, we have motivated the need for providing a collection of primitives for model transformation languages. we have defined t-core which precisely describes each of these primitive constructs. the de-construction process of model transformation languages enabled us to reconstruct existing model transformation features by combining t-core with, for example, an sbl language. this allowed us to compare different model transformation languages using a common basis. now that these primitives are well-defined, efficiently implementing each of them might lead to more efficient model transformation languages. also, for future work, we would like to investigate how t-core combined with appropriate modelling languages can express further transformation constructs. we would also like to investigate further on the notion of exceptions and error handling in the context of model transformation. bibliography [akk+06] a. agrawal, g. karsai, z. kalmar, s. neema, f. shi, a. vizhanyo. the design of a language for model transformations. sosym 5(3):261–288, september 2006. [bj66] c. böhm, g. jacopini. flow diagrams, turing machines and languages with only two formation rules. communications of the acm 9(5):366–371, may 1966. [fntz00] t. fischer, j. niere, l. turunski, a. zündorf. story diagrams: a new graph rewrite language based on the unified modelling language and java. in ehrig et al. (eds.), theory and application of graph transformations. lncs 1764, pp. 296–309. springer-verlag, paderborn (germany), november 2000. [jk06] f. jouault, i. kurtev. transforming models with atl. in mtip’05. lncs 3844, pp. 128–138. springer-verlag, january 2006. [kms+09] t. kühne, g. mezei, e. syriani, h. vangheluwe, m. wimmer. systematic transformation development. in 3rd international workshop on multi-paradigm modeling (best paper). volume 21. october 2009. [llmc06] l. lengyel, t. levendovszky, g. mezei, h. charaf. model transformation with a visual control flow language. ijcs 1(1):45–53, 2006. [mp08] g. manning, d. plump. the gp programming system. in gt-vmt’08. eceasst, pp. 235–247. budapest (hungary), march 2008. [rk09] a. rensink, j.-h. kuperus. repotting the geraniums: on nested graph transformation rules. in margaria et al. (eds.), gt-vmt’09. easst. york (uk), march 2009. [sv09a] e. syriani, h. vangheluwe. de-/re-constructing model transformation languages. technical report socs-tr-2009.8, mcgill university, school of computer science, august 2009. 13 / 14 volume 29 (2010) de-/re-constructing model transformation [sv09b] e. syriani, h. vangheluwe. discrete-event modeling and simulation: theory and applications. chapter devs as a semantic domain for programmed graph transformation. crc press, boca raton (usa), 2009. [sv09c] e. syriani, h. vangheluwe. matters of model transformation. technical report socs-tr-2009.2, mcgill university, school of computer science, march 2009. [vb07] d. varró, a. balogh. the model transformation language of the viatra2 framework. science of computer programming 68(3):214–234, 2007. [vjbb09] a. vignaga, f. jouault, m. c. bastarrica, h. brunelière. typing in model management. in paige (ed.), theory and practice of model transformations (icmt’09). lncs 5563, pp. 197–212. springer-verlag, zürich (switzerland), june 2009. proc. gt-vmt 2010 14 / 14 introduction de-constructing transformation languages matcher rewriter iterator resolver rollbacker selector synchronizer composer t-core: a minimal collection of transformation primitives re-constructing transformation languages re-constructing story diagrams re-constructing amalgamated rules related work conclusion analyzing fuzzy logic computations with fuzzy xpath electronic communications of the easst volume 64 (2013) proceedings of the xiii spanish conference on programming and computer languages (prole 2013) analyzing fuzzy logic computations with fuzzy xpath jesús m. almendros-jiménez, alejandro luna, ginés moreno and carlos vázquez 19 pages guest editors: clara benac earle, laura castro, lars-åke fredlund managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst analyzing fuzzy logic computations with fuzzy xpath jesús m. almendros-jiménez1, alejandro luna2, ginés moreno3 and carlos vázquez 4 1 jalmen@ual.es dept. of informatics universidad de almería 04120 almería (spain) 2 alejandro.luna@alu.uclm.es 3 gines.moreno@uclm.es 4 carlos.vazquez@uclm.es dept. of computing systems university of castilla-la mancha 02071 albacete (spain) abstract: implemented with a fuzzy logic language by using the floper tool developed in our research group, we have recently designed a fuzzy dialect of the popular xpath language for the flexible manipulation of xml documents. in this paper we focus on the ability of fuzzy xpath for exploring derivation trees generated by floper once they are exported in xml format, which somehow serves as a debugging/analizing tool for discovering the set of fuzzy computed answers for a given goal, performing depth/breadth-first traversals of its associated derivation tree, finding non fully evaluated branches, etc., thus reinforcing the bi-lateral synergies between fuzzy xpath and floper. keywords: xpath; fuzzy (multi-adjoint) logic programming; debugging 1 introduction logic programming (lp) [llo87] is being widely used from several decades ago for problem solving and knowledge representation, thus providing a great amount of foundations and techniques devoted to produce real world applications. some steps beyond, during the last years important research efforts have been performed for introducing inside the lp paradigm some techniques/constructs based on fuzzy logic in order to explicitly treat with uncertainty and approximated reasoning in a natural way. following this trail, several fuzzy logic programming systems have been developed [lee72, ks92, bmp95, voj01, gmv04, vp05, str08, rr10, mcs11], where the classical inference mechanism of sld–resolution has been replaced by a fuzzy variant which is able to handle partial truth in a comfortable way. this is the case too of multi-adjoint logic programming [mov04], malp in brief, where a fuzzy program can be seen as a set of rules each one annotated with its own truth degree (a value of a complete lattice, for instance, the real interval [0,1]). goals are evaluated in two separate computational phases. during the operational phase, admissible steps (a generalization of the 1 / 19 volume 64 (2013) mailto:jalmen@ual.es mailto:alejandro.luna@alu.uclm.es mailto:gines.moreno@uclm.es mailto:carlos.vazquez@uclm.es analyzing fuzzy logic computations with fuzzy xpath classical modus ponens inference rule) are systematically applied by a backward reasoning procedure in a similar way to classical resolution steps in pure logic programming. more precisely, in an admissible step, for a selected atom a in a goal and a rule 〈h←b; v〉 of the program, if there is a most general unifier θ of a and h, then atom a is substituted by the expression (v&b)θ , where “&” is an adjoint conjunction evaluating modus ponens. finally, the operational phase returns a computed substitution together with an expression where all atoms have been exploited. this last expression is then interpreted under a given lattice during what we call the interpretive phase, hence returning a pair 〈truth degree; substitution〉 which is the fuzzy counterpart of the classical notion of computed answer traditionally used in pure logic programming. on the other hand, the extensible markup language (xml) is widely used in many areas of computer software to represent machine readable data. xml provides a very simple language to represent the structure of data, using tags to label pieces of textual content, and a tree structure to describe the hierarchical content. xml emerged as a solution to data exchange between applications where tags permit to locate the content. xml documents are mainly used in databases. the xpath language [bbc+07] was designed as a query language for xml in which the path of the tree is used to describe the query. xpath expressions can be adorned with boolean conditions on nodes and leaves to restrict the number of answers of the query. xpath is the basis of a more powerful query language (called xquery) designed to join multiple xml documents and to give format to the answer. in [alm11, alm12a] we have presented an xpath interpreter (together with a debugger, as documented in [alm12b, alm13]) extended with fuzzy commands which somehow rely on the implementation based on fuzzy logic programming by using floper. whereas in sections 2 and 3 we summarize the main features of both the fuzzy xpath interpreter and the fuzzy logic programming environment floper, respectively, in section 4 we go deeper on the feedbacks between both tools. more exactly we show that, even when floper was used for implementing fuzzy xpath, now this last language is very useful for formulating queries to be executed againts xml documents representing derivation trees depicted by floper, thus becoming into a “debugging” technique which can be embedded into the programming environment for analyzing some interesting details (fuzzy computed answers, tree traversals, partial branches, etc.) about fuzzy logic computations. finally, in section 5 we conclude and present future work. 2 fuzzy xpath in this section we will summarize the main elements of our proposed fuzzy xpath language described in [alm12a, alm11] (the tool can be freely downloaded and tested on-line in http://dectau.uclm.es/fuzzyxpath/). on this flexible dialect of xpath, we have incorporated two structural constraints called down and deep to which a certain degree of relevance is associated. so, whereas down provides a ranked set of answers depending on the path they are found from “top to down” in the xml document, deep provides a ranked set of answers depending on the path they are found from “left to right” in the xml document. both structural constraints can be used together, assigning degree of importance with respect to the distance to the root xml element. secondly, our fuzzy xpath incorporates fuzzy variants of and and or for xpath conditions. crisp and and or operators are used in standard xpath over boolean conditions, and proc. prole 2013 2 / 19 http://dectau.uclm.es/fuzzyxpath/ eceasst enable to impose boolean requirements on the answers. xpath boolean conditions can be referred to attribute values and node content, in the form of equality and range of literal values, among others. however, the and and or operators applied to two boolean conditions are not precise enough when the programmer does not give the same value to both conditions. for instance, some answers can be discarded when they could be of interest by the programmer, and accepted when they are not of interest. besides, programmers would need to know in which sense a solution is better than another. when several boolean conditions are imposed on a query, each one contributes to satisfy the programmer’s preferences in a different way and perhaps, the programmer’s satisfaction is distinct for each solution. we have enriched the arsenal of operators of xpath with fuzzy variants of and and or. particularly, we have considered three versions of and: and+, and, and(and the same for or : or+, or, or-) which make more flexible the composition of fuzzy conditions. three versions for each operator that come for free from our adaptation of fuzzy logic to the xpath paradigm. one of the most known elements of fuzzy logic is the introduction of fuzzy versions of classical boolean operators. product, łukasiewicz and gödel fuzzy logics are considered as the most prominent logics and give a suitable semantics to fuzzy operators. our contribution is now to give sense to fuzzy operators into the xpath paradigm, and particularly in programmer’s preferences. we claim that in our work the fuzzy versions provide a mechanism to force (and debilitate) conditions in the sense that stronger (and weaker) programmer preferences can be modeled with the use of stronger (and weaker) fuzzy conditions. the combination of fuzzy operators in queries permits to specify a ranked set of fuzzy conditions according to programmer’s requirements. furthermore, we have equipped xpath with an additional operator that is also traditional in fuzzy logic: the average operator avg. this operator offers the possibility to explicitly give weight to fuzzy conditions. rating such conditions by avg, solutions increase its weight in a proportional way. however, from the point view of the programmer’s preferences, it forces the programmer to quantify his(er) wishes which, in some occasions, can be difficult to measure. for this reason, fuzzy versions of and and or are better choices in some circumstances. finally, we have equipped our xpath based query language with a mechanism for thresholding programmer’s preferences, in such a way that programmer can request that requirements are satisfied over a certain percentage. the proposed fuzzy xpath is described by the following syntax: xpath := [‘[’deep-down‘]’ ]path path := literal | text() | node | @att | node/path | node//path node := qname | qname[cond] cond := xpath op xpath | xpath num-op number deep := deep=number down := down=number deep-down := deep | down | deep ‘;’ down num-op := > | = | < | <> fuzzy-op := and | and+ | and| or | or+ | or| avg | avg{number,number} op := num-op | fuzzy-op basically, our proposal extends xpath as follows: 3 / 19 volume 64 (2013) analyzing fuzzy logic computations with fuzzy xpath figure 1: fuzzy logical operators &p(x,y) = x∗y |p(x,y) = x + y−x∗y product: and/or &g(x,y) = min(x,y) |g(x,y) = max(x,y) gödel: and+/or&l(x,y) = max(x + y−1,0) |l(x,y) = min(x + y,1) łuka.: and-/or+ – structural constraints. a given xpath expression can be adorned with «[deep = r1; down = r2]» which means that the deepness of elements is penalized by r1 and that the order of elements is penalized by r2, and such penalization is proportional to the distance (i.e., the length of the branch and the weight of the tree, respectively). in particular, «[deep = 1; down = r2]» can be used for penalizing only w.r.t. document order. deep works for //, that is, the deepness in the xml tree is only computed when descendant nodes are explored, while down works for both / and //. let us remark that deep and down can be used several times on the main path expression and/or any other sub-path included in conditions. – flexible operators in conditions. we consider three fuzzy versions for each one of the classical conjunction and disjunction operators (t-norms and t-conorms, respectively [ss83, kmp00]), also called connectives or aggregators, describing pessimistic, realistic and optimistic scenarios, see figure 1. in xpath expressions the fuzzy versions of the connectives make harder to hold boolean conditions, and therefore can be used to debilitate/force boolean conditions. furthermore, assuming two given rsv’s (retrieval status values) r1 and r2, the avg operator is obviously defined with a fuzzy taste as (r1 + r2)/2, whereas its priority-based variant, i.e. avg{p1, p2}, acts as (p1 ∗r1 + p2 ∗r2)/(p1 + p2). figure 2: input xml document in our examples classic literature don quijote de la mancha miguel de cervantes saavedra la galatea miguel de cervantes saavedra los trabajos de persiles y sigismunda miguel de cervantes saavedra la celestina fernando de rojas proc. prole 2013 4 / 19 eceasst figure 3: execution of query «/bib[deep=0.8;down=0.9]//title» document rsv computation don quijote de la mancha la celestina los trabajos de persiles... 0.8000 = 0.8 0.7200 = 0.8∗0.9 0.2949 = 0.85 ∗0.9 figure 4: execution of query «//book[@year<2000 avg{3,1} @price<50]/title» document rsv computation los trabajos de persiles... don quijote de la mancha 1.00 = (3∗1 + 1∗1)/(3 + 1) 0.25 = (3∗0 + 1∗1)/(3 + 1) figure 5: execution of query «/bib[deep=0.5]//book[@year<2000 avg{3,1} @price<50]/title» document rsv computation don quijote de la mancha los trabajos de persiles... 0.25 = (3∗0 + 1∗1)/(3 + 1) 0.0625 = 0.54 ∗(3∗1 + 1∗1)/(3 + 1) in general, a fuzzy xpath expression defines, w.r.t. an xml document, a sequence of subtrees of the xml document where each subtree has an associated rsv. xpath conditions, which are defined as fuzzy operators applied to xpath expressions, compute a new rsv from the rsvs of the involved xpath expressions, which at the same time, provides a rsv to the node. in order to illustrate these explanations, let us see some examples of our proposed fuzzy version of xpath according to the xml document shown of figure 2. example 1 let us consider the fuzzy xpath query of figure 3 requesting title’s penalizing the occurrences from the document root by a proportion of 0.8 and 0.9 by nesting and ordering, respectively, and for which we obtain the file listed in figure 3. in such document we have included as attribute of each subtree, its corresponding rsv. the highest rsvs correspond to the main books of the document, and the lowest rsvs represent the books occurring in nested positions (those annotated as related references). example 2 figure 4 shows the answer associated to a search of books, possibly referenced directly or indirectly from other books, whose publishing year and price are relevant but the year is three times more important than the price. finally, in figure 5 we combine both kinds of (structural/conditional) operators, and the ranked list of solutions is reversed. finally, we can use command «[filter = r]» at the beginning of a query for filtering its final set of solutions in the sense that only those ones with rsv not lower than r will conform the output. 5 / 19 volume 64 (2013) analyzing fuzzy logic computations with fuzzy xpath 3 fuzzy logic programming with malp and floper multi-adjoint logic programming [mov04], malp in brief, can be thought as a fuzzy extension of prolog and it is based on a first order language, l , containing variables, function/constant symbols, predicate symbols, and several arbitrary connectives such as implications (←1,←2,...,←m), conjunctions (&1,&2,...,&k), disjunctions (∨1,∨2,...,∨l ), and general hybrid operators (“aggregators” @1,@2,...,@n), used for combining/propagating truth values through the rules, and thus increasing the language expressiveness. additionally, our language l contains the values of a multi-adjoint lattice in the form 〈l,�,←1,&1,...,←n,&n〉, equipped with a collection of adjoint pairs 〈←i,&i〉 where each &i is a conjunctor intended to the evaluation of modus ponens [ss83, kmp00, mov04]. a rule is a formula “a ←i b with α ”, where a is an atomic formula (usually called the head), b (which is called the body) is a formula built from atomic formulas b1,...,bn (n ≥ 0 ), truth values of l and conjunctions, disjunctions and general aggregations, and finally α ∈ l is the “weight” or truth degree of the rule. the set of truth values l may be the carrier of any complete bounded lattice, as for instance occurs with the set of real numbers in the interval [0,1] with their corresponding ordering �r. consider, for instance, the following program, p, with associated multi-adjoint lattice 〈[0,1],�r,←p,&p〉 (where label p means for product logic with the following connective definitions for implication and conjunction symbols, respectively: “←p (x,y) = min(1,x/y)”, “&p(x,y) = x∗y”, as well as “@aver(x,y) = (x + y)/2”): r1 : oc(x) r0 oc(x) {} r1 and_prod(s(x),agr_aver(f(x),w(x))) {x1/x} r2 and_prod(0.8,agr_aver(f(madrid),w(madrid))) {x/madrid,x1/madrid} r3 and_prod(0.8,agr_aver(0.8,w(madrid))) {x/madrid,x1/madrid} proc. prole 2013 8 / 19 eceasst r4 and_prod(0.8,agr_aver(0.8,0.9)) {x/madrid,x1/madrid} result 0.6800000000000002 {x/madrid,x1/madrid} ... result 0.585 {x/tokyo,x1/tokyo} ... 4 exploring derivation trees with fuzzy xpath in this section we present a very powerful method to automatically exploring the behaviour of a malp program using the fuzzy xpath tool described in section 2. the idea is to use fuzzy xpath over the execution tree generated by floper for a certain program and goal. that tree is obtained through option “tree” using the xml format just explained before in section 3. for instance, an easy but interesting xpath query should be “//node/rule” which lists all the rules exploited along the execution of a goal (in the case of the tree depicted in figure 6, we would obtain the whole set of rules defined in the program p of our running example). assume now that we plan to obtain the whole set of fuzzy computed answers for a given goal and program. this information, always collected in the leaves of execution trees (even when there exists the possibility of finding leaves non containing fuzzy computed answers, as we will see afterwards) as illustrated in figure 7, can be retrieved by means of the fuzzy xpath query “//node[/rule/text()=result]”, meaning that, return each node such that the content of its rule tag is “result”. the xml text shown below figure 7 represents the output of our fuzzy xpath interpreter for that query, where the selected nodes have been highlighted inside a blue cloud into the drawn tree above. note that the resuting xml file contains four solutions (one for each city), where attribute “rsv” indicates how much each city fulfills the original query (in this example, this value is the same in all cases, that is, just the maximum one 1). 9 / 19 volume 64 (2013) analyzing fuzzy logic computations with fuzzy xpath figure 7: executing queries «//node[/rule/text()=result]» and «//node[children[not(text())]]» result 0.6800000000000002 {x/madrid, x1/madrid} result 0.585 {x/tokyo, x1/tokyo} result 0.18000000000000002 {x/istambul, x1/istambul} result 0.105 {x/baku, x1/baku} strongly related with the previous experiment, but not directly focusing now on fuzzy computed answers, query “//node[children[not(text())]]” returns the leaves of the tree. note that, in the case of our current program p and goal “oc(x)”, the corresponding output for this query is, once again, the same than the one reported previously in figure 7 but, as said proc. prole 2013 10 / 19 eceasst figure 8: executing query «[filter=0.5][deep=0.9]//node/goal» oc(x) and_prod(s(x),agr_aver(f(x),w(x))) and_prod(0.8,agr_aver(f(madrid),w(madrid))) and_prod(0.9,agr_aver(f(tokyo),w(tokyo))) and_prod(0.3,agr_aver(f(istambul),w(istambul))) and_prod(0.3,agr_aver(f(baku),w(baku))) and_prod(0.8,agr_aver(0.8,w(madrid))) and_prod(0.9,agr_aver(0.7,w(tokyo))) and_prod(0.3,agr_aver(0.4,w(istambul))) and_prod(0.3,agr_aver(0.2,w(baku))) in the previous paragraph, this is not the general case. in fact, we can formulate a query like “//node[children[not(text())] and rule/text()<>"result"]/goal”, helping us to know whether the tree has any partially evaluated leaf (i.e., non reporting a fuzzy computed answer) since it returns nodes at the end of a branch that are not labeled with the rule tag containing “result”. the important meaning of this query resides on its capability for finding possible sources of infinite loops. so, consider the example of figure 9, where an infinite branch (leaf in orange) is clearly observable between two leaves (in yellow) containing fuzzy computed answers. this figure corresponds to the execution tree (since it is infinite in depth, floper allows us to fix the number of levels to be drawn) for goal “p(x)” w.r.t. program: p(a) with 0.8. p(x) 0.8 and_prod(0.9,and_prod(0.9,and_prod(0.9,and_prod(0.9,and_prod(0.9,p(s(s(s(s(s (s(s(s(s(s(s(s(s(s(s(x))))))))))))))))))))) 0.6 executing query «//node[children[not(text())] and rule/text()<>"result"]/goal» and_prod(0.9,and_prod(0.9,and_prod(0.9,and_prod(0.9,and_prod(0.9,p(s(s(s(s(s (s(s(s(s(s(s(s(s(s(s(x))))))))))))))))))))) executing query «//node[rule/text()="result"]/goal» 0.8 0.6 proc. prole 2013 12 / 19 eceasst figure 10: executing query «[filter=0.5][down=0.7]//node/goal» oc(x) and_prod(s(x),agr_aver(f(x),w(x))) and_prod(0.8,agr_aver(f(madrid),w(madrid))) and_prod(0.8,agr_aver(0.8,w(madrid))) and_prod(0.8,agr_aver(0.8,0.9)) 0.6800000000000002 and_prod(0.9,agr_aver(f(tokyo),w(tokyo))) and_prod(0.9,agr_aver(0.7,w(tokyo))) and_prod(0.9,agr_aver(0.7,0.6)) 0.585 note that, in this figure, the search for nodes with an empty “children” field by using query “//node[children[not(text())]]/goal” returns three solutions, i.e., the three leaves of the tree without distinguishing whether they correspond to fully or partially evaluated goals. query “//node[rule/text()="result"]/goal” allows us to retrieve only the fca’s of the tree, as seen in figure 9. finally, in order to obtain the final node in the central (infinite) branch, we must use the more involved second query shown in the figure, that is, “//node[children[not(text())] and rule/text()<>"result"]/goal”. in order to take advantage of the enrichments introduced in the fuzzy xpath language, the following query makes use of “deep” and “filter” commands in order to perform a partial breadth-first traversal on execution trees as shown in figure 8. in the resulting xml output, 10 nodes have been selected from the execution tree with different “rsv” values, varying from 1 in the case of the original goal (that has not been penalized) till 0.531441 for the fourth row, representing nodes whose depth (“deep-level”) remains above the filter. note that the use of the directive “deep” segregates the nodes of the tree from top to bottom, since lower nodes in 13 / 19 volume 64 (2013) analyzing fuzzy logic computations with fuzzy xpath the tree are represented deeper in the input xml file. figure 11: «node[/goal[contains(text(),“w(”)] aver{1,2} substitution[contains(text(),“istambul”)]]//goal» and_prod(0.3,agr_aver(f(istambul),w(istambul))) and_prod(0.3,agr_aver(0.4,w(istambul))) and_prod(0.3,agr_aver(0.4,0.8)) 0.18000000000000002 and_prod(s(x),agr_aver(f(x),w(x))) and_prod(0.8,agr_aver(f(madrid),w(madrid))) and_prod(0.9,agr_aver(f(tokyo),w(tokyo))) and_prod(0.3,agr_aver(f(baku),w(baku))) and_prod(0.8,agr_aver(0.8,w(madrid))) and_prod(0.9,agr_aver(0.7,w(tokyo))) and_prod(0.3,agr_aver(0.2,w(baku))) analogously, in figure 10 we use “down” instead of “deep” for producing partial depth-first traversals on execution trees. in this case, our query segregates the nodes from left to right in columns, since the more left the node appears in the tree, the upper is it in the xml output and, thus, the less penalized by “down”. as previously, 10 nodes have been selected again with “rsv” ranging from 1 -upper nodes in the xm filein the left column, till 0.7, as shown in the second column. in order to illustrate the high expressive power of the fuzzy xpath language, in the following we try to model queries joining several concepts (for instance, the topics of “weather” and “istambul” modeled in p as predicate “w” and constant “istambul”, respectively). assume that we are firstly interested on nodes informing about “weather”, i.e., focusing on the fourth rows of our execution tree, thus meaning that sub-string “w(” must appear in tag “goal”, while our second preference asks for nodes in the branch containing the word “istambul” in tag “substitution”. proc. prole 2013 14 / 19 eceasst in order to join these two constraints, instead of using crisp “or/and” operators (or even different fuzzy variants of such connectives already implemented in fuzzy xpath), we prefer to use an arithmetical average giving twice importance to the second requirement than to the first one. the fuzzy xpath formulation of our query entitles figure 11, where we graphically show the set of solutions as well as the output in the resulting xml file. we finish this section by commenting some related works. the investigation of fuzzy extensions of the xquery/xpath language for providing flexible mechanisms to xml querying, has provided a wide range of approaches in which the main goal is the handling of crisp information by fuzzy concepts [gt10, cdg+09, dmp07, ffp09, fff10, laae06, dmp08], as our proposal does. but an alternative way focuses on the introduction of fuzzy information in data (similarity, proximity, vagueness, etc) [us12, üyg07, bdw06, bdhh06, ga06, yml09, op08, op10] for which our recent advances described in [jmpv14] (devoted to extend the floper platform with expressive resources to comfortably handle with similarity relations), promise new improvements in the implementation of fuzzy xpath. moreover, in [alm14] we have highlighted the benefits obtained with the filter command used along this paper, for filtering the set of ranked answers in a dynamic way, in order to reduce the runtime/complexity of computations when dealing with large files and connecting our framework with the well-known “top-k ranking problem” (i.e. determining the top k answers to a query without computing the -usually wider, possibly infinitewhole set of solutions) inspired by [bcg02, ch02, cgm04, mbg04, rds07, ibs08]. 5 conclusions and future work in this paper we have shown the mutual benefits between two different fuzzy tools developed in our research group, that is, the floper programming environment and the fuzzy xpath interpreter. initially floper was conceived as a tool for implementing flexible software applications -as it is the case of fuzzy xpathcoded with the fuzzy logic language malp and offering options for compiling fuzzy rules to standard prolog clauses, running goals and drawing execution trees. such trees, once modeled in xml format inside the proper floper tool, can be then analyzed by the fuzzy xpath interpreter -by means of simple xpath queries augmented with fuzzy commandsin order to discover details (such as fuzzy computed answers, possible infinite branches and so on) of the computational behaviour of malp programs after being executed into floper. in this sense, we plan to integrate an option inside the floper menu for allowing the possibility of performing debugging tasks based on fuzzy xpath. on the other hand, in [alm12b, alm13] we have recently presented a fuzzy xpath debugger (beyond the fuzzy xpath interpreter) that, for a given xpath expression, the tool offers a set of alternative queries, each one associated to a chance degree indicating the deviations of each proposal w.r.t. the original query (we use jump, delete and swap operators for covering the main cases of programming errors when describing a path about an xml document). thus, our tool is focused on providing the programmer a repertoire of paths that (s)he can use to retrieve answers. since in this paper we have seen that the fuzzy xpath interpreter might act as a debugger of fuzzy computations developed with floper, for the near future we plan too to study the role that the proper fuzzy xpath debugger should play for helping the design of applications using floper. 15 / 19 volume 64 (2013) analyzing fuzzy logic computations with fuzzy xpath acknowledgements: carlos vázquez and ginés moreno received grants for international mobility from the university of castilla-la mancha (cytema project and “vicerrectorado de profesorado”). this research was also supported by the eu (feder), and the spanish mineco ministry (ministerio de economía y competitividad) under grants tin2013-45732-c4-2-p and tin2013-44742-c44-r, as well as andalusian regional government (spain) under project p10-tic-6114. bibliography [alm11] j. almendros-jiménez, a. luna, g. moreno. a flexible xpath-based query language implemented with fuzzy logic programming. in proc. of 5th international symposium on rules: research based, industry focused, ruleml’11. barcelona, spain, july 19–21. pp. 186–193. springer verlag, lncs 6826, 2011. [alm12a] j. m. almendros-jiménez, a. luna, g. moreno. fuzzy logic programming for implementing a flexible xpath-based query language. electr. notes theor. comput. sci. 282:3–18, 2012. [alm12b] j. m. almendros-jiménez, a. luna, g. moreno. a xpath debugger based on fuzzy chance degrees. in on the move to meaningful internet systems: proceedings otm 2012 workshops, rome, italy, september 10-14. pp. 669–672. springer verlag, lncs 7567, 2012. [alm13] j. almendros-jiménez, a. luna, g. moreno. annotating fuzzy chance degrees when debugging xpath queries. in advances in computational intelligence proc of the 12th international work-conference on artificial neural networks, iwann 2013 (special session on fuzzy logic and soft computing application), tenerife, spain, june 12-14. pp. 300–311. springer verlag, lncs 7903, part ii, 2013. [alm14] j. almendros-jiménez, a. luna, g. moreno. dynamic filtering of ranked answers when evaluating fuzzy xpath queries. in rough sets and current trends in soft computing 2014. pp. 319–330. springer verlag, lnai 8536, 2014. [bbc+07] a. berglund, s. boag, d. chamberlin, m. fernandez, m. kay, j. robie, j. siméon. xml path language (xpath) 2.0. w3c, 2007. [bcg02] n. bruno, s. chaudhuri, l. gravano. top-k selection queries over relational databases: mapping strategies and performance evaluation. acm trans. database syst. 27(2):153–187, 2002. [bdhh06] p. buche, j. dibie-barthélemy, o. haemmerlé, g. hignette. fuzzy semantic tagging and flexible querying of xml documents extracted from the web. journal of intelligent information systems 26(1):25–40, 2006. [bdw06] p. buche, j. dibie-barthélemy, f. wattez. approximate querying of xml fuzzy data. flexible query answering systems, pp. 26–38, 2006. proc. prole 2013 16 / 19 eceasst [bmp95] j. f. baldwin, t. p. martin, b. w. pilsworth. frilfuzzy and evidential reasoning in artificial intelligence. john wiley & sons, inc., 1995. [cdg+09] a. campi, e. damiani, s. guinea, s. marrara, g. pasi, p. spoletini. a fuzzy extension of the xpath query language. journal of intelligent information systems 33(3):285–305, 2009. [cgm04] s. chaudhuri, l. gravano, a. marian. optimizing top-k selection queries over multimedia repositories. ieee trans. knowl. data eng. 16(8):992–1009, 2004. [ch02] k. c.-c. chang, s. won hwang. minimal probing: supporting expensive predicates for top-k queries. in franklin et al. (eds.), sigmod conference. pp. 346–357. acm, 2002. [dmp07] e. damiani, s. marrara, g. pasi. fuzzyxpath: using fuzzy logic and ir features to approximately query xml documents. foundations of fuzzy logic and soft computing, pp. 199–208, 2007. [dmp08] e. damiani, s. marrara, g. pasi. a flexible extension of xpath to improve xml querying. in proceedings of the 31st annual international acm sigir conference on research and development in information retrieval. pp. 849–850. 2008. [fff10] on the expressiveness of generalization rules for xpath query relaxation. 2010. [ffp09] top-k answers to fuzzy xpath queries. 2009. [ga06] a. gaurav, r. alhajj. incorporating fuzziness in xml and mapping fuzzy relational data into fuzzy xml. in proceedings of the 2006 acm symposium on applied computing. pp. 456–460. 2006. [gmv04] s. guadarrama, s. muñoz, c. vaucheret. fuzzy prolog: a new approach using soft constraints propagation. fuzzy sets and systems 144(1):127–150, 2004. [gt10] m. goncalves, l. tineo. fuzzy xquery. in soft computing in xml data management. pp. 133–163. springer, 2010. [ibs08] i. f. ilyas, g. beskales, m. a. soliman. a survey of top-k query processing techniques in relational database systems. acm comput. surv. 40(4), 2008. [jmpv14] p. julián-iranzo, g. moreno, j. penabad, c. vázquez. a fuzzy logic programming environment for managing similarity and truth degrees. in prole’14 (submitted). pp. 1–10. universidad de cádiz, 2014. [kmp00] e. klement, r. mesiar, e. pap. triangular norms. trends in logic, studia logica library. springer, 2000. http://books.google.es/books?id=riyqcjfkmn4c [ks92] m. kifer, v. subrahmanian. theory of generalized annotated logic programming and its applications. journal of logic programming 12:335–367, 1992. 17 / 19 volume 64 (2013) http://books.google.es/books?id=riyqcjfkmn4c analyzing fuzzy logic computations with fuzzy xpath [laae06] h. li, s. aghili, d. agrawal, a. el abbadi. flux: fuzzy content and structure matching of xml range queries. in proceedings of the 15th international conference on world wide web. pp. 1081–1082. 2006. [lee72] r. lee. fuzzy logic and the resolution principle. journal of the acm 19(1):119– 129, 1972. [llo87] j. lloyd. foundations of logic programming. springer-verlag, berlin, 1987. [mbg04] a. marian, n. bruno, l. gravano. evaluating top-k queries over web-accessible databases. acm trans. database syst. 29(2):319–362, 2004. [mcs11] s. muñoz-hernández, v. p. ceruelo, h. strass. rfuzzy: syntax, semantics and implementation details of a simple and expressive fuzzy tool over prolog. inf. sci. 181(10):1951–1970, 2011. [mm08] p. morcillo, g. moreno. programming with fuzzy logic rules by using the floper tool. in al. (ed.), proc of the 2nd. rule representation, interchange and reasoning on the web, international symposium, ruleml’08. pp. 119–126. springer verlag, lncs 3521, 2008. [mmpv10] p. morcillo, g. moreno, j. penabad, c. vázquez. a practical management of fuzzy truth degrees using floper. in al. (ed.), proc. of 4nd intl symposium on rule interchange and applications, ruleml’10. pp. 20–34. springer verlag, lncs 6403, 2010. [mov04] j. medina, m. ojeda-aciego, p. vojtáš. similarity-based unification: a multiadjoint approach. fuzzy sets and systems 146:43–62, 2004. [mv14] g. moreno, c. vázquez. fuzzy logic programming in action with floper. journal of software engineering and applications 7:237–298, 2014. [op08] b. oliboni, g. pozzani. representing fuzzy information by using xml schema. in database and expert systems application, 2008. dexa’08. 19th international workshop on. pp. 683–687. 2008. [op10] b. oliboni, g. pozzani. an xml schema for managing fuzzy documents. soft computing in xml data management, pp. 3–34, 2010. [rds07] c. re, n. n. dalvi, d. suciu. efficient top-k query evaluation on probabilistic data. in chirkova et al. (eds.), icde. pp. 886–895. ieee, 2007. [rr10] m. rodríguez, c. a. romero. a declarative semantics for clp with qualification and proximity. theory and practice of logic programming 10(4-6):627–642, 2010. [ss83] b. schweizer, a. sklar. probabilistic metric spaces. courier dover publ., 1983. http://books.google.es/books?id=8lud6txuu5sc proc. prole 2013 18 / 19 http://books.google.es/books?id=8lud6txuu5sc eceasst [str08] u. straccia. managing uncertainty and vagueness in description logics, logic programs and description logic programs. in reasoning web, 4th international summer school, tutorial lectures. pp. 54–103. springer verlag, lncs 5224, 2008. [us12] p. ueng, s. skrbic. implementing xquery fuzzy extensions using a native xml database. in computational intelligence and informatics (cinti), 2012 ieee 13th international symposium on. pp. 305–309. 2012. [üyg07] e. üstünkaya, a. yazici, r. george. fuzzy data representation and querying in xml database. international journal of uncertainty, fuzziness and knowledge-based systems 15(supp01):43–57, 2007. [voj01] p. vojtáš. fuzzy logic programming. fuzzy sets and systems 124(1):361–370, 2001. [vp05] p. vojtáš, l. paulík. query answering in normal logic programs under uncertainty. in godó (ed.), proc. of 8th. european conference on symbolic and quantitative approaches to reasoning with uncertainty (ecsqaru-05), barcelona, spain. pp. 687–700. springer verlag, lncs 3571, 2005. [yml09] l. yan, z. ma, j. liu. fuzzy data modeling based on xml schema. in proceedings of the 2009 acm symposium on applied computing. pp. 1563–1567. 2009. 19 / 19 volume 64 (2013) introduction fuzzy xpath fuzzy logic programming with malp and floper exploring derivation trees with fuzzy xpath conclusions and future work electronic communications of the easst volume 22 (2009) proceedings of the third international workshop on formal methods for interactive systems (fmis 2009) guest editors: michael harrison, mieke massink managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst preface this volume of the electronic communications of easst contains the proceedings of the third edition of the international workshop on formal methods for interactive systems (fmis 2009). fmis is a forum for the presentation and discussion of research in the interface between formal methods and interactive system design. this subfield, within applied formal methods, provides interesting challenges to the specification and analysis of systems: what features of interactive systems can be specified that contribute to an understanding of their usability? what analytic techniques are appropriate to assessing whether the design represented by the specification has appropriate properties relating to its use? the theme of the workshop has been admirably scoped by the keynote address: “who wants a model and why?” in which muffy calder reflects on the role of models in recent analyses relating to pervasive and uniquitous systems. this year there were 12 submissions of which 5 have been selected for this volume. all papers were evaluated by at least three reviewers who addressed originality and contribution, technical quality, readability, organisation, presentation and references to related work. the selected papers combine traditional concerns of formal methods in hci with novel concerns associated with more recent software applications. bowen and reeves’ paper focuses on the model based development problem and considers the role of testing in relation to the specification of interactive systems addressing traditional concerns. it is encouraging to see continuing development of these themes. several of the papers deal with emerging mainstream application areas including ubiquitous systems in general and techniques for their analysis (arapinis and others, calder and others). these applications require novel analysis from the perspective of human computer interaction. they require focus on interoperability (arapinis and others) and context awareness (calder and others). further papers in this volume focus on particular frameworks and analytic techniques that are required to model and analyse trust-related emotion (bonnefon and others) and the stochastic properties of software based systems (anderson and others). previous workshops in this series were held in macau (october 2006) and lancaster (september 2007). this year fmis was co-located with the 16th international symposium on formal methods and was held on november 2, 2009 in eindhoven, the netherlands. it has been a privilege to be co-located with this international forum for researchers, practitioners and educators in the field of formal methods. we would like to thank all the members of the programme committee and the additional referees for their careful and timely evaluation and discussion of the submitted papers. we are also grateful to the fm2009 conference for hosting fmis 2009 this year and taking care of many organisational aspects, and to fm europe for its financial support. finally, we thank all authors for their submissions without which this workshop could not have taken place, and easst (european association of software science technology) and our home institutions newcastle university and cnr-isti for their support. we hope that you will find this volume interesting and thought-provoking and that it will stimulate further research in this interesting and multi-disciplinary field. december, 2009 michael harrison mieke massink newcastle university cnr-isti fmis09 co-chair fmis09 co-chair 1 / 3 volume 22 (2009) organisation programme committee chairs michael harrison newcastle university, uk mieke massink national research council, cnr-isti, italy programme committee ann blandford ucl interaction center, uk judy bowen university of waikato, new zealand paul cairns university of york, uk josé creissac campos university of minho, portugal antonio cerone uni-iist, macau sar china paul curzon queen mary, university of london, uk alan dix lancaster university, uk gavin doherty trinity college, university of dublin, ireland david duce oxford brookes university, oxford, uk stefania gnesi cnr-isti, pisa, italy michael harrison newcastle university, uk c. michael holloway nasa langley research center, usa chris johnson university of glasgow, uk mieke massink cnr-isti, pisa, italy philippe palanque university of toulouse iii, france luca simoncini university of pisa, italy daniel sinnig concordia university, canada harold thimbleby university of wales swansea, wales external referees alessandro fantechi university of florence, italy proc. fmis 2009 2 / 3 eceasst contents ui-design driven model-based testing judy bowen and steve reeves towards the verification of pervasive systems myrto arapinis, muffy calder, louise dennis, michael fisher, philip gray, savas konur, alice miller, eike ritter, mark ryan, sven schewe, chris unsworth and rehana yasmin tightly coupled verification of pervasive systems muffy calder, phil gray and chris unsworth markov abstractions for probabilistic π -calculus hugh anderson and gabriel ciobanu a logical framework for trust-related emotions. jean-françois bonnefon, dominique longin and manh-hung nguyen 3 / 3 volume 22 (2009) an extension of the inverse method to probabilistic timed automata electronic communications of the easst volume 23 (2009) proceedings of the ninth international workshop on automated verification of critical systems (avocs 2009) an extension of the inverse method to probabilistic timed automata étienne andré, laurent fribourg, jeremy sproston 18 pages guest editor: markus roggenbach managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst an extension of the inverse method to probabilistic timed automata étienne andré1, laurent fribourg1, jeremy sproston2 1 lsv – ens de cachan & cnrs, france 2 dipartimento di informatica, università di torino, italy abstract: probabilistic timed automata can be used to model systems in which probabilistic and timing behavior coexist. verification of probabilistic timed automata models is generally performed with regard to a single reference valuation of the timing parameters. given such a parameter valuation, we present a method for obtaining automatically a constraint on timing parameters for which the reachability probabilities (1) remain invariant and (2) are equal to the reachability probabilities for the reference valuation. the method relies on parametric analysis of a nonprobabilistic version of the probabilistic timed automata model using the “inverse method”. our approach is useful for avoiding repeated executions of probabilistic model checking analyses for the same model with different parameter valuations. we provide examples of the application of our technique to models of randomized protocols. keywords: probabilistic model checking, parametric timed automata, randomized protocols 1 introduction timed automata are finite control automata equipped with clocks, which are real-valued variables which increase uniformly [1]. this model is useful for reasoning about real-time systems, because one can specify quantitatively the interval of time during which the transitions can occur, using the bounds involved in invariants and guards labeling the nodes and arcs of the automaton. an extension of timed automata to the probabilistic framework, where discrete actions are replaced by discrete probability distributions over discrete actions, has been defined in [14, 17]. this model has been applied to a number of case studies [16]. model-checking analysis of probabilistic timed automata normally proceeds by reducing the model to a finite-state probabilistic system and then employing a probabilistic model-checking tool such as prism [12, 23]. the constants used in some timing constraints of a real-time system may not be known, or may be known with some uncertainty. therefore methods for automatically generating values on parameters in timing constraints for which the system behaves correctly are desirable. methods for synthesizing such parameters in timed automata have first been presented in [2]. in [3], the following inverse problem has been considered: given a parametric timed automaton and a reference valuation, which is a particular valuation of the parameters of the model, find a constraint k0 on the parameters which is satisfied by the reference valuation and in which the model behaves in the same manner as in the case of the reference valuation. for example, if the 1 / 18 volume 23 (2009) an extension of the inverse method to probabilistic timed automata reference valuation is known to exhibit good behavior, such as the impossibility of reaching an error state, then our aim is to find a constraint on the parameters within which such good behavior is guaranteed. in particular, this allows the system designer to optimize some parameters of the system. in this paper, we consider the application of the inverse method to probabilistic timed automata models. we aim at synthesizing a constraint such that, for any valuation of the parameters satisfying k0, the model is “time-abstract” equivalent to the model for the reference valuation. in the context of probabilistic timed automata, the computed constraint k0 defines parameter valuations for which, in particular, minimum (resp., maximum) probabilities of satisfying a given property (e.g., reachability of a certain location) are all equal. therefore, given the computation of k0, it suffices to compute a minimum (resp., maximum) probability for a single parameter valuation satisfying k0. in order to infer such a constraint k0, we transform the system into a non-probabilistic timed automaton, and apply the original inverse method of [3] to this timed automaton. as in the method of [18], some attention has to be dedicated to the non-probabilistic model construction so that the results of the inverse method apply to the original probabilistic timed automaton. motivation. this approach is particularly important for probabilistic timed automata for the following reason. as mentioned above, model checking for probabilistic timed automata in practice generally relies on the reduction of the model to a finite-state system. the effectiveness of the discrete-time semantics method most commonly used is sensitive to the timing constants used in the description of the model: more precisely, the greater the timing constants, the larger the state space of the finite-state system obtained from the discrete-time semantics construction, and the more difficult the verification (the zone-based algorithm of [20] does not have this property, but does not always perform better in practice than the discrete-time semantics approach). in case studies it is standard to rescale the time unit used in the model to reduce the magnitude of the timing constraints in order to reduce the size of the resulting finite-state system. this rescaling operation possibly involves rounding lower bounds on clocks downwards, and upper bounds upwards [16], which results in an abstraction in which the computed maximum (minimum, respectively) probabilities may be greater (or less than, respectively) the actual probabilities in the original model. the inverse method presents an alternative to this rescaling approach. by applying the inverse method to obtain the constraint k0, we can choose the parameter valuation satisfying k0 with the lowest possible values for the timing constraints: then, by performing analysis on the model with this parameter valuation, we can obtain the same minimum and maximum probabilities as on the model using the reference valuation of the parameters. hence, as in the rescaling approach, we can obtain discrete-time models of limited size by reducing the magnitude of the timing constants; however, in contrast to the rescaling approach, we can avoid rounding of lower and upper bounds, thereby resulting in a model exhibiting the same probabilities as obtained for the model corresponding to the reference valuation. we note that this motivation also applies when considering discrete-time approaches to timed automata verification, such as in [11, 7, 6]. proc. avocs 2009 2 / 18 eceasst init true transmit true collide y ≤ δ send1 y := 0 send2 y := 0 end1 end2 y ≤ δ send1 y := 0 y ≤ δ send2 y := 0 y ≥ δ busy1 y ≥ δ busy2 cd figure 1: csma/cd medium comparison to related work. in contrast to [21, 9, 10], we do not consider parameters over probabilities, but only over timing constraints. a parametric probabilistic timed automata framework which did not feature non-deterministic choice was considered in [8]. in contrast, the framework we introduce in this paper features both nondeterministic and probabilistic choice. an illustrative example. consider the csma/cd protocol, as studied in the context of probabilistic timed automata in [20]. we consider the case when there are two stations 1 and 2 trying to send data at the same time. the overall model is given by the parallel composition of three probabilistic timed automata representing the medium and two stations trying to send data. the probabilistic timed automaton representing the medium is given in fig. 1. the medium is initially ready to accept data from any station (event send1 or send2). once a station, say 1, starts sending its data there is an interval of time (at most δ ), representing the time it takes for a signal to propagate between the stations. in this interval the medium can accept data from station 2 (resulting in a collision). after this interval, if station 2 tries to send data it will get the busy signal (busy2). when a collision occurs, there is a delay (again at most δ ) before the stations realize there has been a collision, after which the medium will become free (event cd). if the stations do not collide, then when station 1 finishes sending its data (event end1) the medium becomes idle. the probabilistic timed automaton representing a station i (i = 1, 2) is given in fig. 2. station i starts by sending its data. if there is no collision, then, after λ time units, the station finishes sending its data (event endi). on the other hand, if there is a collision (event cd), the station attempts to retransmit the packet, where the scheduling of the retransmission is determined by a truncated binary exponential backoff process. the delay before retransmitting is an integer number of time slots (each of length slot). the number of slots that station i waits after the nth transmission failure is chosen as a uniformly distributed random integer in the range: 0, 1, 2, . . . , 2bci+1 −1, where bci = min(n, bcmax), and bcmax is a fixed upper bound for bci (initially: bci = n = 0). this random choice is depicted in fig. 2 by the assignment backoff i := rand(bci)∗slot. once this time has elapsed, if the medium appears free the station resends the data (event sendi), while if the medium is sensed busy (event busyi) the station repeats this process. 3 / 18 volume 23 (2009) an extension of the inverse method to probabilistic timed automata transmit xi ≤ λ init true done true wait xi ≤ backoff i collide xi = 0 sendi xi := 0 xi = λ endi cd xi := 0 bci := min(bci + 1, bcmax) xi = backoff i sendi xi := 0 xi = backoff i busyi xi := 0 bci := min(bci + 1, bcmax) backoff i := rand(bci)∗slot figure 2: csma/cd station i we consider in the following that bcmax is a constant equal to 1, and that δ , λ and slot are parameters. the reference valuation for these parameters, taken from the ieee standard 802.3 for 10 mbps ethernet, is: δ = 26µ s, λ = 808µ s, and slot = 2δ = 52µ s. the method for inferring a constraint k0 on the parameters, which is satisfied by the reference valuation and in which the behavior of the model remains the same, consists in transforming the system into a non-probabilistic parametric timed automaton. we replace the random choice backoff i := rand(bci)∗slot with a non-deterministic choice, i.e., a set of 2bci+1 transitions associated with assignments of the form backoff i := j ∗slot, for j = 0, 1, 2, . . . , 2bci+1 −1. in the case where bcmax = 1, the application of the inverse method to the non-probabilistic parametric timed automaton (see section 4.1) infers for k0 the following constraint: (0 < δ < slot)∧(15slot < λ < 16slot). in particular, the minimum and maximum probabilities for a message sent by a station to be transmitted (i.e., to reach the location done) after having collided exactly k times with another message (action cd) are the same under the reference valuation and another parameter valuation satisfying k0. this has two practical implications. firstly, in order to compute the aforementioned minimum and maximum probabilities for δ = 26, λ = 808, slot = 52, it suffices to compute the minimum and maximum probabilities for δ = 1, λ = 31, slot = 2 (because both valuations satisfy the constraint (0 < δ < slot)∧(15slot < λ < 16slot) generated by the inverse method). note that the valuation δ = 26, λ = 808, slot = 52 results in a model with 5240 states using the discrete-time semantics construction, whereas the valuation δ = 1, λ = 31, slot = 2 results in a model with 282 states. the second practical implication concerns the case in which the system designer wishes to understand the behavior of the system, in terms of minimum and maximum probabilities, for a number of parameter valuations. the approach of obtaining such information by changing manually the timing parameters and repeating model-checking analysis is potentially time consuming. instead, the application of the inverse method shows that the minimum and maximum probabilities remain invariant for all parameter valuations satisfying the constraint k0. proc. avocs 2009 4 / 18 eceasst plan of the paper. in section 2, we present the definition of parametric probabilistic timed automata. in section 3, we apply the inverse method to probabilistic timed automata in the following way: we construct a non-probabilistic version of the model, which is then subject to the inverse method for parametric timed automata. in section 4, we apply the method to three probabilistic protocols with timing parameters (csma/cd, ieee 1394 root contention, ieee 802.11 wlan). we conclude in section 5. 2 parametric probabilistic timed automata in section 2.1, we review the definition of timed probabilistic systems, as defined in [17], which is a variant of segala’s probabilistic timed automata [22]. in section 2.2, we extend the definition of probabilistic timed automata [17] to the parametric case, and give its semantics in terms of timed probabilistic systems (section 2.3). 2.1 timed probabilistic systems let r≥0 be the set of non-negative real numbers. a (discrete) probability distribution over a countable set z is a function µ : z → [0, 1] such that ∑z∈z µ(z) = 1. we define support(µ) = {z ∈ z | µ(z) > 0}. then for an uncountable set z we define dist(z) to be the set of functions µ : z → [0, 1], such that support(µ) is a countable set and µ restricted to support(µ) is a (discrete) probability distribution. a point distribution is a distribution µ ∈ dist(z) such that µ(z) = 1 for some (unique) z ∈ z. often we write µz for the point distribution such that µ(z) = 1. a timed probabilistic system (tps) is a tuple t = (s, s0, act,⇒) where: s is a set of states, including a set s0 of initial states; act is a finite set of actions (disjoint from r≥0); ⇒⊆ s× r≥0 ×act ×dist(s) is a probabilistic transition relation. a transition s d,a,µ −−−→ s′ is made from a state s ∈ s by first nondeterministically selecting a duration-action-distribution triple (d, a, µ) such that (s, d, a, µ) ∈⇒, and second by making a probabilistic choice of target state s′ according to distribution µ , such that µ(s′) > 0. a path of a tps is a non-empty finite sequence of transitions ω = s0 d0,a0,µ0−−−−→ s1 d1,a1,µ1−−−−→··· dn−1,an−1,µn−1−−−−−−−−→ sn. given a path ω = s0 d0,a0,µ0−−−−→ s1 d1,a1,µ1−−−−→··· dn−1,an−1,µn−1−−−−−−−−→ sn, we let last(ω) = sn. the set of paths of a tps t is denoted by pathtfin. when clear from the context we omit the superscript t and write pathfin. we let pathfin(s) denote the set of paths commencing in the state s ∈ s. a scheduler is a partial function which chooses an outgoing transition in the last state of a path, if a transition from the last state of a path exists. formally, a scheduler of a tps is a partial function σ such that, for each path ω of the tps, we have (1) if σ (ω) = (d, a, µ) then (last(ω), d, a, µ) ∈⇒, and (2) if σ (ω) is undefined then there does not exist any (d, a, µ) such that (last(ω), d, a, µ) ∈⇒. a scheduler resolves the nondeterminism by choosing a transition based on the path executed so far. intuitively, if a tps is guided by scheduler σ and has the path ω as its history, then it will be in state s in the next step with probability µ(s), where σ (ω) = (d, a, µ); alternatively, if there is no available transition from ω , then the system deadlocks, and the choice of the scheduler will be undefined. we denote the set of paths induced by a given scheduler σ to be pathσfin = {ω = s0 d0,a0,µ0−−−−→··· dn−1,an−1,µn−1−−−−−−−−→ sn | σ (ω↓i) = (di, ai, µi) for all i < 5 / 18 volume 23 (2009) an extension of the inverse method to probabilistic timed automata n}, where ω↓i returns the prefix of ω up to length i. then we define pathσfin(s) = path σ fin ∩ pathfin(s). a scheduler σ a tps is said to be admissible if, for all s ∈ s0 and ω ∈ pathσfin(s), there exists some transition (last(ω), d, a, µ) ∈⇒. for each s ∈ s and scheduler σ , we can define the probability measure probσs over measurable sets of paths in the standard way [15]. 2.2 syntax of parametric probabilistic timed automata we now extend the definition of probabilistic timed automata [17] to the parametric case. a clock is a variable xi which takes values in r≥0. all clocks evolve linearly at the same rate. we denote a set of clocks by x = {x1, . . . , xh}. we define a clock valuation as a function w : x → r≥0 assigning a non-negative real value to each clock. we will often identify a valuation w with the point (w(x1), . . . , w(xh )) ∈ rh≥0. for d ∈ r≥0, we write w + d to denote the valuation such that (w + d)(x) = w(x) + d for all x ∈ x . given a clock valuation w and a set ρ ⊆ x of clocks, we denote by ρ(w) the clock valuation such that ρ(w)(x) = 0 if x∈ρ and ρ(w)(x) = w(x) otherwise. let p = {p1, . . . , pm} be a set of parameters. a parameter valuation π is a function π : p → r≥0 assigning a non-negative real value to each parameter. we will often identify a valuation π with the point (π(p1), . . . , π(pm)) ∈ rm≥0. a linear inequality on the parameters p (linear inequality on the clocks x and the parameters p, respectively) is an inequality e ≺ e′, where ≺∈{<,≤}, and e, e′ are two linear terms of the form: ∑ i αi pi + d, ( ∑ i αi pi + ∑ j β jx j + d, respectively) where 1 ≤ i ≤ m, 1 ≤ j ≤ h and αi, β j, d ∈ n. a constraint on the parameters p (constraint on the clocks x and the parameters p, respectively) is a conjunction of inequalities on p (on x and p, respectively). in the sequel, the letter k (c, respectively) denotes a constraint on the parameters (on the clocks and the parameters, respectively). we consider true as a constraint on p, corresponding to the set of all possible values for p. given a parameter valuation π and a constraint c, we denote by c[π] the constraint obtained by replacing each parameter p in c with π(p). likewise, given a clock valuation w, we denote by c[π][w] the expression obtained by replacing each clock x in c[π] with w(x). a clock valuation w satisfies c[π], denoted by w |= c[π], if c[π][w] evaluates to true. we say that π satisfies c, denoted by π |= c, if the set of clock valuations that satisfy c[π] is nonempty. similarly, we say that π satisfies k, denoted by π |= k, if the expression obtained by replacing each parameter p in k with π(p) evaluates to true. the following definition is an extension of the class of probabilistic timed automata to the parametric case. parametric probabilistic timed automata allow the use of parameters in place of constants within guards and invariants, and are based on parametric timed automata [2]. a parametric probabilistic timed automaton (ppta) a is a tuple of the form a = (σ, q, q, x , p, i, prob), where: • σ is a finite set of actions, • q is a finite set of locations with an initial location q ∈ q, proc. avocs 2009 6 / 18 eceasst • x is a finite set of clocks, • p is a finite set of parameters, • i is the invariant function, assigning to every q ∈ q a constraint i(q) on the clocks x and the parameters p, and • prob is the probabilistic edge relation consisting of elements of the form (q, g, a, η), where q ∈ q, g is a constraint on the clocks x and the parameters p, a ∈ σ, and η ∈dist(2x ×q). we make the following assumptions on pptas. determinism on actions: given a location q ∈ q and action a ∈ σ, there is at most one probabilistic edge of the form (q, , a, ) ∈ prob. reset unicity: for any probabilistic edge (q, g, a, η) ∈ prob and location q′ ∈ q, there exists at most one ρ ∈ 2x such that η(ρ, q′) > 0. neither of these assumptions is restrictive, because a ppta not satisfying the assumptions can be transformed into a ppta which does: for determinism on actions, it is necessary to add and rename actions, whereas, for reset unicity, it suffices to add an extra clock and additional locations. the assumptions of determinism on actions and reset unicity are commonly met in practice, and they simplify the proofs of our subsequent results. let a be a ppta. if, for each location q ∈ q, we have that i(q) is a constraint only on clocks, and, for each edge (q, g, a, η) ∈ prob, we have that g is a constraint only on clocks, we say that a is a probabilistic timed automaton (pta). remark. we make use in figure 2 of several forms of syntactic sugar consisting in merging several transitions issued from the same location, using assignments of the form bci := min(bci + 1, bcmax), or backoff i := rand(bci)∗slot, following the conventions used, e.g., in [16]. 2.3 semantics of parametric probabilistic timed automata in this section, we will consider the ppta a = (σ, q, q, x , p, i, prob). given a parameter valuation π = (π(p1), . . . , π(pm)), we denote by a [π] the pta obtained from a by substituting every occurrence of a parameter pi by π(pi) in the guards and invariants. formally, a [π] = (σ, q, q, x , p, i′, prob′), where i′ and prob′ are defined in the following way: for each location q ∈ q, we let i′(q) = i(q)[π], and we let prob′ be the smallest set such that, for each (q, g, a, η) ∈ prob, we have (q, g[π], a, η) ∈ prob′.1 in the following, we consider the pta a [π] resulting from a given valuation π of the parameters. a state of a [π] is a pair (q, w) ∈ q×rh≥0 such that w |= i(q)[π]. informally, the behavior of a [π] can be understood as follows. the model starts in the initial location q with all clocks set to 0. in this, and any other state (q, w), there is a nondeterministic choice of either (1) making a discrete (probabilistic) transition or (2) letting time pass. in case (1), a discrete transition can 1 strictly speaking, a [π] is a pta only when π assigns a natural number (rather than a real) to each parameter, but this does not matter in our context. 7 / 18 volume 23 (2009) an extension of the inverse method to probabilistic timed automata be made according to any probabilistic edge (q, g, a, η) ∈ prob with source location q which is enabled; that is the constraint g is satisfied by the current clock valuation w. then the probability of moving to the location q′ and resetting all of the clocks in ρ to 0 is given by η(ρ, q′). in case (2), the option of letting time pass is available only if the invariant i(q) is satisfied while time elapses. formally, we define the semantics of a pta as an associated infinite-state, infinite-branching tps, defined as follows. the tps (or semantics) associated with a [π] is ta [π] = (s, s0, σ,⇒) with s = {(q, w) ∈ q×(x → r≥0) | w |= i(q)[π]}, s0 = {(q, 0)} where 0(x) = 0 for all x ∈ x , and where ((q, w), d, a, µ) ∈⇒ if both of the following conditions hold : time elapse: w + d |= i(q)[π] ; edge traversal: there exists a probabilistic edge (q, g, a, η) ∈ prob such that w + d |= g[π] and, for each (ρ, q′) ∈ support(η), we have µ(q′, ρ(w + d)) = η(ρ, q′). observe that the rule for discrete transitions is a simplified version of the standard rule [17], and relies on the assumption of reset unicity. the definition of ta [π] also relies on the fact that a and π satisfy the following well-formedness assumption. first, a pta is said to be well-formed if whenever a probabilistic edge is enabled it can be taken, i.e.: all of the probabilistic alternatives (pairs of target location and clock reset) result in states. formally, a pta is said to be wellformed if, for each probabilistic edge (q, g, a, η) ∈ prob and state (q, w) ∈ s such that w |= g[π], we require that (q′, ρ(w)) ∈ s for each (ρ, q′) ∈ support(η). 2 then we say that a ppta is well-formed if, for each parameter valuation, the resulting pta is well-formed. a ppta can be transformed into a well-formed ppta by incorporating the invariant associated to the target location into the guard of each probabilistic edge (along the lines of the transformation in [20]). for the remainder of the paper we assume that all of the pptas we consider are well-formed. note that a (p)pta a for which all probabilistic edges feature point distributions can be interpreted as a (parametric) timed automaton. more precisely, the (parametric) timed automaton differs from a only in the edge relation: we represent a probabilistic edge (q, g, a, η) ∈ prob of a , for which η(ρ, q′) = 1 for some ρ ⊆x and q′∈q (recall that a features point distributions only) by a single edge in the (parametric) timed automaton. networks of pptas can be defined by using parallel composition based on the synchronization of discrete transitions of different components sharing the same action in a similar manner to networks of ptas [19]. given a path ω = (q0, w0) d0,a0,µ0−−−−→ (q1, w1) d1,a1,µ1−−−−→··· dn−1,an−1,µn−1−−−−−−−−→ (qn, wn), we let the timeabstract trace of ω be the sequence of alternating locations and actions q0a0q1a1 ···an−1qn. given a scheduler σ , we let traceσ : pathσfin → (q×σ) ∗ be the function associating the timeabstract trace with each path of pathσfin. then the time-abstract trace distribution of σ and state s ∈ s is the probability measure over traces denoted by tdσs defined according to traceσ and the trace distribution construction of segala [22]. although we do not consider the details of the construction of trace distributions in this paper, we note that, for example, the probability 2 a counter-example of well-formed pta is the following: let (q, w) be a state where w(x) = 2, let (q, x ≤ 2, a, η) be a probabilistic edge such that η(q′, /0) = 12 and η(q ′′, /0) = 12 , and let inv(q ′) = (x ≤ 1) and inv(q′′) = (x ≤ 2). then the invariant of q′ is not satisfied when taking the probabilistic edge (q, x ≤ 2, a, η), followed by the probabilistic selection of (q′, /0), from (q, w). proc. avocs 2009 8 / 18 eceasst assigned by tdσs to traces in which a certain location is reached is defined to be the same as the probability assigned by probσs to the set of paths in which this location is reached. the set of time-abstract trace distributions of the tps ta [π] is denoted by tdist(ta [π]) = {td σ s | σ is a scheduler of ta [π] and s ∈ s0}. we say that a [π] and a [π′] are time-abstract trace distribution equivalent, written a [π] ≈tdist a [π′], if tdist(ta [π]) = tdist(ta [π′]). if a [π] ≈tdist a [π′], we can conclude that the tpss have time-abstract equivalent finite behaviors: for example, they assign the same maximum and minimum probabilities of reaching a certain location [18] (in general, they assign the same maximum and minimum probabilities to linear-time properties on finite traces). finally, we write patha [π]fin for path ta [π] fin . 3 analysis of pptas using the inverse method in this section we consider an application of the inverse method to pptas. our approach consists in applying the inverse method to a non-probabilistic version of the ppta. the constraint output by the inverse method is also a solution to the inverse problem for the ppta and the reference instantiation. ideally, we would like to generate a constraint which is as weak as possible (i.e., satisfied by as many valuations as possible). we first present formally the problem we intend to resolve, then introduce a method for obtaining (non-probabilistic) parametric timed automata from pptas. finally we explain how the results on the inverse method applied to parametric timed automata can be used to infer constraints on parameters of pptas. 3.1 the inverse problem on pptas consider the ppta a = (σ, q, q, x , p, i, prob), which we assume is fixed throughout this section. let π be a valuation of parameters in p, and let ((q, w), d, a, µ) ∈⇒ be a transition of ta [π]. recall that, by reset unicity and the definition of ta [π], for each distinct (q, w), (q ′, w′) ∈ support(µ), we have q 6= q′. we define the distribution loc(µ) ∈ dist(q) over locations in the following way: for each (q, w) ∈ s, we let loc(µ)(q) = µ(q, w). let π′ be a valuation of parameters in p. the path ω = (q0, w0) d0,a0,µ0−−−−→··· dn−1,an−1,µn−1−−−−−−−−→ (qn, wn) of ta [π], is time-abstract path equivalent to the path ω ′ = (q′0, w ′ 0) d′0,a ′ 0,µ ′ 0−−−−→ ··· d′n−1,a ′ n−1,µ ′ n−1−−−−−−−−→ (q′n, w′n) of ta [π], written ω ≡path ω′, if qi = q′i, ai = a ′ i, and loc(µi) = loc(µ ′ i ) for all i = 0, . . . , n. we extend the notion of time-abstract path equivalence to sets of paths: two sets ω and ω′ of paths are time-abstract path equivalent, written ω ≡path ω′, if (1) for each path ω ∈ ω, there exists ω′∈ ω′ such that ω ≡path ω′, and (2) conversely, for each path ω ∈ ω′, there exists ω′ ∈ ω such that ω ≡path ω′. we recall below a result from [18, 19] which allows to relate time-abstract equivalence on paths to time-abstract trace distribution equivalence. proposition 1 let a be a ppta, and let π and π′ be instantiations of parameters p. if patha [π]fin (q, 0) ≡ path patha [π ′] fin (q, 0), then a [π] ≈ tdist a [π′]. 9 / 18 volume 23 (2009) an extension of the inverse method to probabilistic timed automata in this paper, starting from an instantiation π0 of the set p of parameters, we are interested in finding a constraint k0 on the parameters such that π0 |= k0, and for any valuation π of p satisfying k0 we have time-abstract trace distribution equivalence between a [π0] and a [π]. furthermore, we suppose that a [π0] has an admissible scheduler. the problem can be stated as follows. consider a ppta a and a valuation π0 of the parameters such that a [π0] has an admissible scheduler. find a constraint k0 such that : 1. π0 |= k0, 2. a [π] has an admissible scheduler, for all π |= k0, and 3. a [π] ≈tdist a [π0], for all π |= k0. 3.2 non-probabilistic version of a ppta in this subsection, we state formal properties relating a ppta to its non-probabilistic version. as explained in section 2.3, it is straightforward to obtain a non-probabilistic parametric timed automaton from a ppta featuring point distributions only. given a ppta a , an edge generated from (q, g, a, η)∈ prob is a tuple (q, g, a, η, ρ, q′) such that η(ρ, q′) > 0. let edges(q, g, a, η) be the set of the edges generated from (q, g, a, η), and let edges = ⋃ (q,g,a,η)∈prob edges(q, g, a, η) denote the set of all edges of a . the non-probabilistic version of a , written a ∗, is a ppta which agrees with a on all elements apart from the probabilistic edge relation. formally, let a ∗ = (σ, q, q, x , p, i, prob∗) be the ppta for which prob∗ is the smallest probabilistic edge relation such that for every edge (q, g, a, η, ρ, q′) ∈edges, we have (q, g,〈〈q, g, a, η, ρ, q′〉〉, η(ρ,q′)) ∈ prob∗ (recall that η(ρ,q′) denotes the point distribution assigning probability 1 to the element (ρ, q′)). observe that the state sets of ta [π] and ta ∗[π] are equal. as noted in section 2, from a ppta for which all probabilistic edges feature point distributions, we can obtain the corresponding parametric timed automaton. in the following proposition, we use → to refer to a transition of the semantic tps of a [π], and →∗ to refer to a transition of the semantic tps of a ∗[π]. proposition 2 let π be an instantiation of p and (q, w) be a state of ta [π] (and ta ∗[π]). for each step (q, w) d,a,µ −−−→ (q′, w′) of ta [π], there exists the step (q, w) d,〈〈q,g,a,η,ρ,q′〉〉,µ(q′,w′)−−−−−−−−−−−−−→∗ (q′, w′) of ta ∗[π], where (q, g, a, η) ∈ prob is such that µ(q′, w′) = η(ρ, q′), and hence loc(µ)(q′) = η(ρ, q′). conversely, for each step (q, w) d,〈〈q,g,a,η,ρ,q′〉〉,µ(q′,w′)−−−−−−−−−−−−−→∗ (q′, w′) of ta ∗[π], there exists the step (q, w) d,a,µ −−−→(q′, w′) of ta [π] such that µ(q′, w′) = η(ρ, q′), and hence loc(µ)(q′) = η(ρ, q′). proposition 2 allows us to obtain a one-to-one mapping between transitions of a [π] and a ∗[π]. by reasoning inductively, we can extend the proposition to obtain a one-to-one mapping between paths of a [π] and a ∗[π]. note that the probability of the transitions of a [π] is encoded in the actions of the associated transitions of a ∗[π]. this, together with the one-to-one mapping between paths of a [π] and a ∗[π], implies that, for any pair ω∗, ω′∗ of paths such that proc. avocs 2009 10 / 18 eceasst ω∗ ∈ path a ∗[π] fin (q, 0), ω ′ ∗ ∈ path a ∗[π′] fin (q, 0) and ω∗ ≡ path ω ′ ∗, we can generate the paths ω, ω ′, such that ω ∈ patha [π]fin (q, 0), ω ′∈ patha [π ′] fin (q, 0) and ω ≡ path ω ′. together, these facts allow us to show the following. proposition 3 let a be a ppta, and let π and π′ be instantiations of parameters p. if patha ∗[π] fin (q, 0) ≡ path patha ∗[π′] fin (q, 0), then path a [π] fin (q, 0) ≡ path patha [π ′] fin (q, 0). proposition 4 let a be a ppta, and let π and π′ instantiations of parameters p. if patha [π]fin (q, 0) ≡ path patha [π ′] fin (q, 0), then a [π] has an admissible scheduler iff a [π ′] has an admissible scheduler. 3.3 resolution of the inverse problem for pptas in [3], we have presented a method which solves the inverse problem for (the special case of) non-probabilistic parametric timed automata. the inverse problem can be described formally in the following way: given a non-probabilistic parametric timed automaton a and a valuation π0 of the parameters, find a constraint k0 such that π0 |= k0 and path a [π0] fin (q, 0)≡ path patha [π]fin (q, 0) for all π |= k0. a brief explanation of the method is given in the appendix. the following algorithm explains how to use the inverse method in the extended framework of pptas. algorithm inversemethodppta(a , π0) input a : ppta π0 : valuation of the parameters output k0 : constraint on the parameters 1. construct the non-probabilistic version a ∗ of a . 2. construct k0 for a ∗ using the classical inverse method. theorem 1 given a ppta a and a reference valuation π0 such that a [π0] has an admissible scheduler, the constraint k0 returned by inversemethodppta(a , π0) solves the inverse problem, i.e., π0 |= k0, and, for all π |= k0, a [π] has an admissible scheduler, and a [π] ≈tdist a [π0]. proof. since k0 is a solution of the inverse problem for a ∗, we have path a ∗[π] fin (q, 0) ≡ path patha ∗[π0] fin (q, 0) for all π |= k0; hence, we have by proposition 3 that path a [π] fin (q, 0) ≡ path patha [π0]fin (q, 0) for all π |= k0. from proposition 1, we conclude that a [π] ≈ tdist a [π0] for all π |= k0. furthermore, since a [π0] has an admissible scheduler, a [π] has an admissible scheduler, for all π |= k0 (by proposition 4). as a consequence of theorem 1, given the computation of k0 using inversemethodppta(a , π0), the maximum and minimum probabilities of satisfying linear-time properties on finite traces will be the same in a [π] and a [π0]. 11 / 18 volume 23 (2009) an extension of the inverse method to probabilistic timed automata remark. the constraint k0 output by our method is not (in general) the weakest constraint satisfying the inverse problem as defined in section 3.1. one reason for this is that the constraint output by the inverse method defined in [3] for (non-probabilistic) parametric timed automata is always in conjunctive form. in contrast, the weakest constraint may be in disjunctive form (see final remarks of [4]). 4 application of the inverse method to pptas: case studies in this section, we show the interest of the inverse method in the context of three case studies. more precisely, we consider three protocols, each modeled as a ppta, and each with an associated standard reference valuation π0.3 our approach consists of the following two phases: 1. using the tool imitator [5], which implements the inverse method in the nonprobabilistic framework, we generate a constraint k0 for the non-probabilistic version of the protocol. 2. using the probabilistic model-checking tool prism [12, 23], we compute minimum/maximum reachability probabilities for various properties with regard to a number of parameter valuations. for parameter valuations satisfying k0, the probabilities computed by prism are equal (as stated by theorem 1); we also compute the probabilities for some parameter valuations not satisfying k0. 4.1 csma/cd protocol we first apply our method to the csma/cd protocol described in section 1. we consider the three parameters λ , δ and slot as described in [20, 23]. the following instantiation π0 of the parameters is the reference valuation taken from the ieee standard 802.3 for 10 mbps ethernet: λ = 808µ s, slot = 52µ s and δ = 26µ s. as sketched in section 1, the non-probabilistic parametric timed automaton a ∗ is obtained as follows: we compose the (non-probabilistic) medium of fig. 1 with the non-probabilistic version of the station, obtained by replacing in fig. 2 the random choice backoff i := rand(bci)∗slot with a non-deterministic choice (i.e., a set of 2bci+1 transitions associated with assignments of the form backoff i := j∗slot, for j = 0, 1, 2, . . . , 2bci+1 −1). applying imitator to this non-probabilistic model and the reference valuation π0, we obtain the following constraint: k0 : δ < slot ∧ 15slot < λ < 16slot. this constraint is such that a [π] and a [π0] are time-abstract trace-distribution equivalent, for any π |= k0. we consider the following four properties, described also with their associated prism syntax: • prop j, for j ∈{0, 1, 2}: minimum probability that station 1 transmits its message after exactly j collisions, i.e., pmin =?[f(s1 = done & nbcol = j)]. 3 note that we consider acyclic versions of those protocols (roughly speaking, by bounding the maximal number of collisions in section 4.1 and section 4.3, and by bounding the number of rounds in section 4.2). proc. avocs 2009 12 / 18 eceasst name λ slot δ |= k0 prop0 prop1 prop2 prop≤3 same as π0 π0 808 52 26 yes 0 0.5 0.375 0.96875 π1 404 26 13 yes 0 0.5 0.375 0.96875 yes π2 31 2 1 yes 0 0.5 0.375 0.96875 yes π3 47 3 2 yes 0 0.5 0.375 0.96875 yes π4 940 60 59 yes 0 0.5 0.375 0.96875 yes π5 940 60 60 no 0 0 0.1875 0.609375 no π6 832 52 26 no 0 0.5 0.375 0.96875 yes π7 52 52 26 no 0 0.5 0.375 0.96875 yes table 1: minimum probability that station 1 transmits its message • prop≤3: minimum probability that station 1 transmits its message with no more than 3 collisions, i.e., pmin =?[f(s1 = done & nbcol≤3)]. we apply prism to the system with the parameters set to different valuations (including π0). the results are given in table 1. for all π |= k0 (i.e., π0 to π4), the probabilities remain the same. an observation is that, as soon as we violate the constraint k0 by considering the limit case where δ = slot (i.e., π5), the probabilities are different. a further observation is that, even if the value of λ violates k0 (i.e., π6 and π7), the probabilities can remain the same. indeed, the constraint generated by our method is not necessarily the weakest, i.e., we can find valuations π of p (e.g., π6 and π7) s.t. π 6|= k0 but the values of the probabilities remain the same as for π0. 4.2 ieee 1394 root contention protocol this case study concerns the root contention protocol of the ieee 1394 (“firewire”) high performance serial bus, also considered in the parametric framework in [13]. we consider the rescaled instantiation of the parameters given in [19, 23]. this instantiation π0 is as follows4: rc fast max = 85, rc fast min = 76, rc slow max = 167, rc slow min = 159, and delay = 30. applying imitator to a (non-probabilistic) parametric timed automaton version of this model and the reference valuation π0, we obtain the following constraint: k0 : 2delay < rc fast min∧rc fast max + 2delay < rc slow min. note that this constraint is exactly the same as the one synthesized in [13]. we consider the following properties: • prop≤3: minimum probability that a leader is elected after 3 rounds or less: pmin =?[f((nbrounds1≤3) & (((s1 = 8) & (s2 = 7))|((s1 = 7) & (s2 = 8))))]. • prop≤5: minimum probability that a leader is elected after 5 rounds or less: pmin =?[f((nbrounds1≤5) & (((s1 = 8) & (s2 = 7))|((s1 = 7) & (s2 = 8))))]. the results of the application of prism to different parameter valuations are given in table 2 (some parameter names are abbreviated for reasons of space). we notice as expected that, for 4 note that the model given on prism’s webpage allows both values 30 and 360 for delay. moreover, the ieee reference instantiation is given in ns but, due to the rescaling, we omit the unit here. 13 / 18 volume 23 (2009) an extension of the inverse method to probabilistic timed automata name rf max rf min rs max rs min delay |= k0 prop≤3 prop≤5 same as π0 π0 85 76 167 159 30 yes 0.875 0.96875 π1 40 35 80 75 15 yes 0.875 0.96875 yes π2 4 3 8 7 1 yes 0.875 0.96875 yes π3 85 61 167 159 30 yes 0.875 0.96875 yes π4 85 76 167 146 30 yes 0.875 0.96875 yes π5 85 76 167 159 36 yes 0.875 0.96875 yes π6 85 76 167 159 37 no 0.71875 0.841796875 no table 2: minimum probability that a leader is elected within 3 or 5 rounds all π |= k0, the probabilities remain the same. further experiments (including π6) show that, as soon as the value of the parameters violates k0, the probabilities become different from π0. we note that the parameter valuation π0 results in a state space of size 693107, for which prop≤5 could be verified in time 319.512s, whereas π2 results in a state space of size 1393, for which prop≤5 could be verified in time 0.781s. 5 4.3 ieee 802.11 wireless local area network protocol we also applied our method to the ieee 802.11 wireless local area network protocol, considering the following instantiation π0 of the parameters mentioned in [23] after rescaling from [18]6: aslottime = 1 difs = 2 vuln = 1 ttmax = 315 ttmin = 4 ack to = 6 ack = 4 sifs = 1 taking a parametric timed automaton version of the model and the parameter valuation π0 as input, the tool imitator computes the following constraint k0: vuln > 0 ∧ sifs > 0 ∧ ack to + difs < 15aslottime ∧ difs > 0 ∧ aslottime > 0 ∧ ttmin + difs ≤ ttmax ∧ ack ≤ 2difs ∧ difs < ttmin ∧ ack to + difs ≤ ack + ttmin ∧ sifs < ttmin ∧ ttmin ≥ ack ∧ ttmin ≤ ack to ∧ vuln < ack we consider the maximum probability that either station’s backoff counter reaches k, for k = 1, 2, 3, as considered in [18]. the results of the application of prism are given in table 3, where the properties are denoted by propk=i for k = 1, 2, 3. the parameters p1, p2, . . . , p8 stand for aslottime, difs, vuln, ttmax, ttmin, ack to, ack, sifs respectively. note that the real timings originating from the ieee 802.11 standard (viz., in µ s, aslottime = 50, difs = 128, vuln = 48, ttmax = 15, 717, ttmin = 224, ack to = 300, ack = 205, sifs = 28) satisfy themselves the constraint k0. our approach thus provides us with a justification of the abstraction done in [18] consisting in reducing the time scale of the model. also observe that, as expected from the form of k0, the value of probk=i is insensitive to important variations of ttmax, i.e. parameter p4 (provided its value remains greater or equal to ttmin + ttdifs, i.e p4 ≥ p2 + p5). for example, probk=i is equal for π0 and π2, in spite of the fact that p4 is changed from 315 to 6. 5 experiments were performed on an intel core 2 duo with 2gb of ram. 6 note that, due to rescaling, the model given on prism’s webpage allows several values for the parameters, e.g., 2 and 3 for difs. proc. avocs 2009 14 / 18 eceasst name p1 p2 p3 p4 p5 p6 p7 p8 |= k0 propk=1 propk=2 propk=3 same as π0 π0 1 2 1 315 4 6 4 1 yes 1 0.183593 0.017032 π1 1 2 1 150 4 6 4 1 yes 1 0.183593 0.017032 yes π2 1 2 1 6 4 6 4 1 yes 1 0.183593 0.017032 yes π3 1 2 1 315 10 12 4 1 yes 1 0.183593 0.017032 yes π4 1 2 1 12 10 12 4 1 yes 1 0.183593 0.017032 yes π5 2 4 2 630 8 12 8 2 yes 1 0.183593 0.017032 yes π6 2 4 2 315 8 10 7 2 yes 1 0.183593 0.017032 yes table 3: maximum probability of either station’s backoff counter reaching k 5 final remarks in this paper we have shown that the inverse method presented in [3] can be applied, not just to non-probabilistic parametric timed automata, but also to their probabilistic extension, for proving time-abstract properties. the method relies on the conversion of pptas to non-probabilistic parametric timed automata, then on the application of the inverse method of [3]. the method has been shown to be successful in obtaining smaller parameter values, which can be helpful in reducing the size of the integer-time semantic pta models prior to model checking. in certain cases, this makes possible probabilistic verification of systems which cannot be model checked directly, due to the prohibitive size of the constants. since the constraint output by our method is not the weakest in general (see the remark in section 3.3), it is interesting to design methods for weakening it further. in particular, the incremental method sketched in [3] could also be used in the probabilistic framework. let us finally point out that, in [18, 19, 16], another class of properties, named “soft deadline properties”, is treated: for example, the minimum probability of a station delivering a packet within some deadline. such properties are not “time-abstract”, and fall beyond the class of those considered here. we note that soft deadline properties can be reduced to time-abstract location reachability properties, but with the addition of constraints within the model: hence, the inverse problem must be solved on the modified model. we plan to explore this approach in future work. acknowledgement. étienne andré and laurent fribourg are partially supported by the agence nationale de la recherche, grant anr-06-arfu-005, and by institute farman (project simop). jeremy sproston is supported in part by the miur-prin project paco performability-aware computing: logics, models and languages. bibliography [1] r. alur and d. l. dill. a theory of timed automata. tcs, 126(2):183–235, 1994. [2] r. alur, t. henzinger, and m. vardi. parametric real-time reasoning. in proc. stoc ’93, pages 592–601. acm, 1993. 15 / 18 volume 23 (2009) an extension of the inverse method to probabilistic timed automata [3] é. andré, t. chatain, e. encrenaz, and l. fribourg. an inverse method for parametric timed automata. international journal of foundations of computer science, 20(5):819– 836, 2009. [4] é. andré, e. encrenaz, and l. fribourg. synthesizing parametric constraints on various case studies using imitator. research report lsv-09-13, laboratoire spécification et vérification, ens cachan, france, 2009. [5] étienne andré. imitator: a tool for synthesizing constraints on timing bounds of timed automata. in proc. ictac’09, volume 5684 of lncs, pages 336–342. springer, 2009. [6] dirk beyer. improvements in bdd-based reachability analysis of timed automata. in proc. fme’01, volume 2021 of lncs, pages 313–343. springer, 2001. [7] m. bozga, o. maler, and s. tripakis. efficient verification of timed automata using dense and discrete time semantics. in proc. charme’99, volume 1703 of lncs. springer, 1999. [8] n. chamseddine, m. duflot, l. fribourg, c. picaronny, and j. sproston. computing expected absorption times for parametric determinate probabilistic timed automata. in proc. qest’08, pages 254–263. ieee, 2008. [9] conrado daws. symbolic and parametric model checking of discrete-time markov chains. in proc. ictac’04, volume 3407 of lncs, pages 280–294. springer, 2004. [10] t. han, j.-p. katoen, and a. mereacre. approximate parameter synthesis for probabilistic time-bounded reachability. in proc. rtss’08, pages 173–182. ieee, 2008. [11] t. henzinger, z. manna, and a. pnueli. what good are digital clocks? in proc. icalp’92, volume 623 of lncs, pages 545–558. springer, 1992. [12] a. hinton, m. kwiatkowska, g. norman, and d. parker. prism: a tool for automatic verification of probabilistic systems. in proc. tacas’06, volume 3920 of lncs, pages 441–444. springer, 2006. [13] t.s. hune, j.m.t. romijn, m.i.a. stoelinga, and f.w. vaandrager. linear parametric model checking of timed automata. journal of logic and algebraic programming, 2002. [14] henrik ejersbo jensen. model checking probabilistic real time systems. in proc. of the 7th nordic work. on progr. theory. chalmers institute of technology, 1996. [15] j. g. kemeny, j. l. snell, and a. w knapp. denumerable markov chains. graduate texts in mathematics. springer, 2nd edition, 1976. [16] m. kwiatkowska, g. norman, d. parker, and j. sproston. performance analysis of probabilistic timed automata using digital clocks. fmsd, 29:33–78, 2006. [17] m. kwiatkowska, g. norman, r. segala, and j. sproston. automatic verification of realtime systems with discrete probability distributions. tcs, 282:101–150, 2002. proc. avocs 2009 16 / 18 eceasst [18] m. kwiatkowska, g. norman, and j. sproston. probabilistic model checking of the ieee 802.11 wireless local area network protocol. in proc. papm/probmiv’02, volume 2399 of lncs, pages 169–187. springer, 2002. [19] m. kwiatkowska, g. norman, and j. sproston. probabilistic model checking of deadline properties in the ieee 1394 firewire root contention protocol. formal aspects of computing, 14(3):295–318, 2003. [20] m. kwiatkowska, g. norman, j. sproston, and f. wang. symbolic model checking for probabilistic timed automata. information and computation, 205(7):1027–1077, 2007. [21] r. lanotte, a. maggiolo-schettini, and a. troina. weak bisimulation for probabilistic timed automata and applications to security. in proc. sefm’03, pages 34–43. ieee, 2003. [22] roberto segala. modeling and verification of randomized distributed real-time systems. phd thesis, massachusetts institute of technology, 1995. [23] prism web page. http://www.prismmodelchecker.org/. 17 / 18 volume 23 (2009) an extension of the inverse method to probabilistic timed automata algorithm inversemethod(a , π0) inputs a : parametric timed automaton of initial location q π0 : reference valuation of the parameters output k0 : constraint on the parameters variables i : current iteration s : current set of symbolic states (s = ⋃i j=0 post j a (k)({(q, k)})) k : current constraint on the parameters i := 0 ; k := true ; s := {(q, true)} do do until there are no π0-incompatible states in s select a π0-incompatible state (q,c) of s (i.e., s.t. π0 6|= c) select a π0-incompatible j in c (i.e., s.t. π0 6|= j) k := k ∧¬j ; s := ⋃i j=0 post j a (k)({(q, k)}) od %% s is π0-compatible if posta (k)(s) = /0 then return k0 := ⋂ (q,c)∈s(∃x : c) fi i := i + 1 ; s := s∪posta (k)(s) %% s = ⋃i j=0 post j a (k)({(q, k)})}) od figure 3: algorithm inversemethod appendix: the inverse method given a (classical) parametric timed automaton a and a reference instantiation π0 of parameters, the inverse method outputs a constraint k0 such that : 1. π0 |= k0, 2. patha [π0]fin ≡ path patha [π]fin , for all π |= k0. the algorithm inversemethod can be summarized as follows. starting with k := true, we iteratively compute a growing set of reachable symbolic states. a symbolic state of the system is a couple (q,c), where q is a location of a , and c a constraint on the parameters7. when a π0-incompatible state (q,c) is encountered (i.e., when π0 6|= c), k is refined as follows : a π0-incompatible inequality j (i.e., such that π0 6|= j) is selected within c, and ¬j is added to k. the procedure is then started again with this new k, and so on, until no new reachable state is computed (we focus here on acyclic systems: see [3] for details). a simplified version of algorithm inversemethod is given in fig. 3, where the clocks have been disregarded for the sake of simplicity. we denote by postia (s) the set of symbolic states reachable from s in at most i steps of a . there is an implementation of this algorithm, called imitator, which is written in python, and makes use of hytech for the computation of the post operation. the python program contains about 1500 lines of code, and its writing took about 4 man-months of work (see [5]). 7 strictly speaking, c is a constraint on the parameters and the clocks, but the clocks are omitted here for the sake of simplicity. see [3] for more details. proc. avocs 2009 18 / 18 introduction parametric probabilistic timed automata timed probabilistic systems syntax of parametric probabilistic timed automata semantics of parametric probabilistic timed automata analysis of pptas using the inverse method the inverse problem on pptas non-probabilistic version of a ppta resolution of the inverse problem for pptas application of the inverse method to pptas: case studies csma/cd protocol ieee 1394 root contention protocol ieee 802.11 wireless local area network protocol final remarks electronic communications of the easst volume 5 (2006) proceedings of the sixth ocl workshop ocl for (meta-)models in multiple application domains (oclapps 2006) an mda framework supporting ocl achim d. brucker, jürgen doser, and burkhart wolff 18 pages guest editors: dan chiorean, birgit demuth, martin gogolla, jos warmer managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.brucker.ch/ http://www.infsec.ethz.ch/people/doserj http://www.infsec.ethz.ch/people/bwolff http://www.easst.org/eceasst/ eceasst an mda framework supporting ocl achim d. brucker, jürgen doser, and burkhart wolff information security, eth zurich, 8092 zurich, switzerland {brucker,doserj,bwolff}@inf.ethz.ch abstract: we present a model-driven architecture (mda) framework that integrates formal analysis techniques into an industrial software development process model. this comprises modeling using uml/ocl, processing models by model transformations, code generation (including runtime-test environments) and formal analysis using the theorem proving environment hol-ocl. moreover, our frameworks supports the verification of proof obligations that are generated during model transformations. we show the extensibility of our approach by providing a secureuml extension of the framework, which allows for an integrated specification of security properties, their analysis and their conversion to code. keywords: mde, mda, ocl, model transformation, code-generation, verification 1 introduction model-driven engineering refers to the systematic use of models as primary engineering artifacts throughout the development life-cycle of software systems. in the broadest sense, the term “models” is used for descriptions in a machine-supported format, while the term “systematic” refers to machine-supported transformations between models or from models to code. the instance of model-driven engineering based on the uml and defined by the object management group (omg) is called model-driven architecture (mda). in uml, various model elements like classes or state machines can be annotated by logical constraints using the object constraint language (ocl); for this reason, uml can be used as a formal specification language with diagrammatic syntax. for mde in general and mda in particular, a technical framework ranging over several stages of the software development process—requirements analysis, design, code generation—is vital. this holds to an even larger extent if semantic information like formal specifications are processed; for mda, an infrastructure is needed that supports model elements annotated by ocl. in such a framework, model transformations can be implemented that represent data refinements (for example, forward-simulation [wd96]) or retrenchments (for example, replace the integer type by bounded integer [bs05]). necessary side-conditions of such transformations can be represented as proof-obligations in ocl. in another scenario, ocl constraints can be used for generating code for runtime-testing or, if combined with the hol-testgen system [bw04, bw05], for generating test-data for a systematic test of injected, hand-crafted code. in this paper, we present such a framework, comprising a toolchain that guides the development process from modeling in a case tool to code-generation and formal verification. in 1 / 18 volume 5 (2006) http://www.brucker.ch/ http://www.infsec.ethz.ch/people/doserj http://www.infsec.ethz.ch/people/bwolff mailto:\protect \t1\textbraceleft brucker,doserj,bwolff\protect \t1\textbraceright @inf.ethz.ch an mda framework supporting ocl particular, our framework consists of a type-checking component allowing to represent ocl in a structured format which can be imported into our model repository (su4sml). this model repository can serve as a basis for model transformations. moreover, su4sml is the basis for a template-based code generator supporting code-generation for the uml core and state machines, enriched by ocl specifications. this model can be directly transformed into a (formal) model for the theorem proving environment hol-ocl [bw06a]. as a distinguishing feature, su4sml is developed in the functional programming language sml [pau96]. for this reason, implementers of model transformations can profit from several techniques that have proven to be of major importance for symbolic computations occurring naturally in compiler construction or theorem proving: pattern matching allows for direct representations of rules to be performed during transformation, higher-order functions allow for the compact description of searchand replacement strategies, and having a strongly typed language helps to detect many errors at compile time. we also present an implementation of one particular extension of our framework for uml/ocl: namely support for the uml-based language secureuml [bdl06]. secureuml is designed to enrich the business model of a system (represented by class diagrams or statecharts) with a concrete access control model. by a model transformation, class systems and operation specifications are transformed such that a combined model is generated, incorporating security and functional aspects. during the transformation, several proof obligations are generated, making explicit under which conditions the functional model of a system is not interfered by its security model. with the help of our framework, the combined model can be transformed to code, while the proof obligations making this transformation “correct” (in the sense of “no bad interference”) can be proven by hol-ocl. thus, our framework can be seen as a first step towards a uniform framework supporting both semantic and code-generative aspects of uml/ocl specifications. the plan of the paper. after a general overview of the framework, we present its main components: in section 3, we describe the implementation of our model repository, in section 4 we present the template-based code generator and in section 5 we describe the interface to hol-ocl. then, in section 6, we describe the secureuml instance of the framework and in section 7 how model transformations, including support for proof obligation generation, can conveniently be expressed in this framework. finally, we discuss our experiences and observations. 2 our framework: an overview in this section, we give an overview of our framework and present a toolchain in which it can be used. but first, we introduce the tools and technologies our framework is based on. 2.1 background 2.1.1 hol-ocl. hol-ocl [bw06a] (http://www.brucker.ch/projects/hol-ocl/) is an interactive proof environment for uml/ocl. its mission is to give the term “object-oriented specification” a formal proc. oclapps 2006 2 / 18 http://www.brucker.ch/projects/hol-ocl/ http://www.brucker.ch/projects/hol-ocl/ eceasst 1..∗ role class + public method # protected method attribute: type − private method class + public method # protected method attribute: type − private method class + public method # protected method attribute: type − private method argouml ... uml/ocl (xmi) or secureuml/ocl ac config c# +ocl code generator repository model (su4sml) transformation model test harness model−analysis and verification (hol−ocl) validation proof obligations test data figure 1: mda framework and toolchain overview semantic foundation and to provide effective means to formally reason over object-oriented models. on the theoretical side, this is achieved by representing uml/ocl as a conservative, shallow embedding into the hol instance of the interactive theorem prover isabelle [npw02]. we follow the standard [omg03a] as closely as possible, in particular, we prove that inheritance can be represented inside the typed λ -calculus with parametric polymorphism. as a consequence of conservativity with respect to hol, we can guarantee the consistency of the semantic model. on the technical side, this is achieved by automated support for typed, extensible uml data models. moreover, hol-ocl provides several derived proof calculi for uml/ocl that allow for formal derivations establishing the validity of uml/ocl formulae. some automated support for such proofs is also provided, albeit the achieved degree of automation is not yet satisfactory. 2.1.2 secureuml. secureuml [bdl06] is a security modeling language based on rbac [scfy96]. in particular, secureuml supports notions of users, roles and permissions, as well as assignments between them: users can be assigned to roles, and roles are assigned to specific permission. users acquire permissions through the roles they are assigned to. moreover, users are organized into a hierarchy of groups, and roles are organized into a role hierarchy. in addition to this rbac model, permissions can be restricted by authorization constraints (expressed in ocl formulae), which have to hold to allow access. secureuml is generic in the notion of protected actions that can be assigned to permissions. these are specified in a secureuml dialect. 2.2 the toolchain our framework is completed by a toolchain (see figure 1) that consists of a uml case tool with an ocl type-checker for modeling software systems. the framework provides a model repository, model analyzers and various code generators. 3 / 18 volume 5 (2006) an mda framework supporting ocl we use the uml case tool argouml (http://argouml.tigris.org) and combine it with the dresden ocl2 toolkit. the dresden ocl toolkit uses a specialized metamodel combining the uml 1.5 and the ocl 2.0 metamodel. this results in an upward compatible extension of the uml 1.5 metamodel: every uml 1.5 model is still a model of the combined metamodel. models expressed in his specialized metamodel can be exported using the xmi export. at time of writing, our sml-based framework comprises 1. an xmi import supporting the uml 1.4 and 1.5 meta-model (e. g., as used by argouml) and also a metamodel combining uml 1.5 and ocl 2.0 (as used by the dresden ocl2 toolkit), 2. a model repository, su4sml, which supports the various metamodels we are using, e. g., uml, ocl, secureuml, 3. a generic, template-based code generator supporting the uml core (e. g., class diagrams), statemachines, ocl and secureuml, (including the generation of access-control checks for the target languages java and c#), 4. a code generator setup for checking the ocl specifications at runtime. on the first hand, this serves as a validation that the implementations fulfills the specification, and on the other hand it serves as a basis for further testing activities, 5. a code generator setup for generating test harnesses for unit testing, e. g., for junit (http: //www.junit.org/), 6. model transformations that normalize the models in several normal forms; this comprises the conversion of multiplicities into ocl constraints, etc., and 7. an interface to our theorem prover environment, hol-ocl, which allows to do (formal) model analysis and verification of uml/ocl models. the framework is implemented as a set of sml modules that are designed to be easily extensible and also can be used independently. we plan to extend the framework, e. g., by integrating specification based test-generator, i. e., hol-testgen (http://www.brucker.ch/projects/hol-testgen) into hol-ocl. the generated test-data can then be used for driving the unit tests and thus provides an automatic test setup for the validation of the (hand-coded) implementation against the specification. 3 the model repository: su4sml the model repository is the component that stores all the (uml) model information that other parts of the framework depend on. it follows the uml/ocl metamodel in representing the model information as closely as this is sensible in a functional programming language. however, some simplifications where made deliberately. for example, we eliminated many indirections that are inherent in the uml metamodel. we also decided to ignore associations between classifiers as such. we only represent their association ends, as part of the participating classifiers. as our framework aims at code generation and model analysis and verification, we concentrated on those parts of the uml that have a comparatively rich and well-defined semantics: currently, the repository supports the model elements featured in uml class and statechart diagrams, including a typed, structured representation of ocl expressions. ocl expressions are, as usual, used as class invariants, operation preand postconditions, and transition guards in proc. oclapps 2006 4 / 18 http://argouml.tigris.org http://www.junit.org/ http://www.junit.org/ http://www.brucker.ch/projects/hol-testgen eceasst 1 s i g n a t u r e rep_core = s i g type o p e r a t i o n = { name : s t r i n g , p r e c o n d i t i o n : ( s t r i n g o p t i o n ∗ oclterm ) l i s t , p o s t c o n d i t i o n : ( s t r i n g o p t i o n ∗ oclterm ) l i s t , 6 arguments : ( s t r i n g ∗ ocltype ) l i s t , r e s u l t : ocltype , . . . } 11 type a t t r i b u t e = { name : s t r i n g , a t t r _ t y p e : ocltype , i n i t : oclterm o p t i o n , . . . } 16 type a s s o c i a t i o n e n d = { . . . } datatype c l a s s i f i e r = cl ass o f { name : path , p a r e n t : path o p t i o n , 21 a t t r i b u t e s : a t t r i b u t e l i s t , o p e r a t i o n s : o p e r a t i o n l i s t , a s s o c i a t i o n e n d s : a s s o c i a t i o n e n d l i s t , i n v a r i a n t : ( s t r i n g o p t i o n ∗ oclterm ) l i s t , . . . 26 } | i n t e r f a c e o f { . . . } (∗ s i m i l a r t o cla ss ∗) | enumeration o f { . . . } | p r i m i t i v e o f { . . . } end listing 1: su4sml: representing the uml core statemachines. they can, however, also appear as proof obligations, to be then verified in the hol-ocl theorem prover. for illustration purposes, listing 1 and listing 2 show parts of the repository signatures. in addition to datatype definitions for the various model elements, the repository structure supports various model transformations. a simple example is the conversion of association ends into attributes with corresponding type, together with the generation of an invariant expressing the corresponding cardinality constraint. a more complex transformation would be the transformation of secureuml models into pure uml/ocl models (cf., section 6.3 and [bdw06]), together with the generation of the corresponding security proof obligations. 5 / 18 volume 5 (2006) an mda framework supporting ocl s i g n a t u r e rep = s i g i n c l u d e rep_ocltype i n c l u d e rep_oclterm 5 i n c l u d e rep_core i n c l u d e rep_statemachines type model = c l a s s i f i e r l i s t 10 end listing 2: su4sml: the model repository 4 a template-based code generator we developed a generic template-based code generator (gcg) on top of the su4sml repository. template-based means that for each code artifact to be generated there is a template file which contains a skeleton of what has to be generated intertwined with instructions for the codegenerator how to fill out the template. the code generator consists of a generic core and a set of cartridges that can be “plugged” into this core (cf., figure 2). the core part of gcg is independent both with respect to the input as well as the output language, the cartridges are responsible for interpreting the language-dependent instructions in the template files. the template language has at the core just three syntactic elements: an @if statement for branching on boolean predicates, a @foreach statement for iterating over lists, and $variable$ interpolation. in particular, the template language is not turing-complete. for example, the predicates in @if statements come from a fixed (finite) set that is defined by the cartridges that are plugged into the core. example predicates are attribute_ispublic or operation_isstatic. similarly, the lists to iterate over are also defined by the cartridges. example lists are classifier_list, attribute_list, or operation_list. these lists have an implicit notion of hierarchy. the evaluation of attribute_list, for example, depends on the current classifier that one iterates over in the enclosing @foreach statement. finally, the variables that can be interpolated are also defined by the cartridges. typical examples are operation_name or attribute_type, see listing 3 for an example template file. while the generic core parses the template file, the actual evaluation of the statements is delegated to the cartridges. for example, when the core executes the statement @if operation_isstatic, it asks the cartridge for the current value of the predicate operation_isstatic. depending on the answer, the core executes the following statements or not. we build up cartridge chains supporting increasing functionalities. if one cartridge does not support a requested functionality, it passes the request on to the next cartridge, and the result back to the requester.1 as a starting point for this cartridge chain, we implemented a base cartridge that implements the most basic functionalities which one would probably need in most languages anyways, for example, variables like attribute_name or lists like operation_list. the design allows for cartridges to override functionalities of “earlier” cartridges by implementing 1 on the implementation level, the “plugging” of these cartridges is done using sml functors. proc. oclapps 2006 6 / 18 eceasst @/ / example t e m p l a t e f o r java @foreach c l a s s i f i e r _ l i s t @openfile g e n e r a t e d / $ c l a s s i f i e r _ n a m e $ . j a v a package $ c l a s s i f i e r _ p a c k a g e $ ; 5 p u b l i c c l a s s $ c l a s s i f i e r _ n a m e $ @if h a s p a r e n t e x t e n d s $ c l a s s i f i e r _ p a r e n t $ @end 10 { @foreach a t t r i b u t e _ l i s t p u b l i c $ a t t r i b u t e _ t y p e $ $attribute_name$ ; @end @foreach o p e r a t i o n _ l i s t 15 p u b l i c $ o p e r a t i o n _ r e s u l t _ t y p e $ $operation_name$ ( @foreach a r g u m e n t _ l i s t $argument_type$ $argument_name$ , @end ) { } 20 @end } @end listing 3: a simplified template file them themselves. this is sometimes necessary for language-specific cartridges when the language requires certain syntactic properties. in this way, different cartridges can independently implement different functionalities: basic code skeletons for different programming languages, runtime assertion monitoring of the ocl invariants, preand postconditions, test harnesses, deployment infrastructures for different middleware platforms or web-services architectures, etc. 5 a su4sml-based datatype package for hol-ocl the encoding of object-oriented data structures in hol is a tedious and error-prone activity, if done manually. in this section, we give an overview of the su4sml-based datatype package we implemented to automate this process. in the theorem prover community, a datatype package [mel92] is a module that allows one to introduce new datatypes and automatically derive certain properties over them. a (conservative) datatype package has two main tasks: 1. generate all required (conservative) constant definitions, and 2. automatically prove interesting properties over the generated definitions. our datatype package is implemented on top of the isabelle kernel api and exploits its potential to build user-programmed extensions in a logically safe way. in the following, we give a brief overview over the functionality of our datatype package ([bw06a, bw06b] describe more details). the datatype package is implemented on top of two 7 / 18 volume 5 (2006) an mda framework supporting ocl target code target code target code repository model (su4sml) template template template template parser gcg−core cartridge 1 cartridge n base cartridge generic template−driven code generator figure 2: the cartridge chain architecture s i g n a t u r e rep_encoder = s i g type mdr = { t h e o r y : t h e o r y , u n i v e r s e : t y p , c l a s s i f i e r s : c l a s s i f i e r l i s t } 5 v a l a d d _ c l a s s i f i e r s : c l a s s i f i e r l i s t → mdr → mdr end listing 4: the top-level interface of the repository encoder components: the su4sml interface and the programming interface of hol-ocl. our datatype packages encodes the given uml/ocl model into a hol-ocl-representation. this is achieved in an extensible way, i. e., classes can be added later on to an existing theory preserving all proven properties ([bw06b] presents more details). the obvious tasks of the datatype package are: 1. declare hol types for the classifiers of the model, 2. encode the core data model into hol, and 3. encode the ocl specification and combine it with the core data model. however, the most important task is probably not that obvious: the package has to generate formal proofs that the generated encoding of object-structures is a faithful representation of objectorientation (in the sense of the uml standard [omg03b]). to ensure the conservativity (and thus consistency) of our approach we cannot prove these properties “once and for all” on the meta-level. thus, these theorems have to be proven for each model during its encoding phase. among many other properties, our package proves that for each pair of classes a and b where b inherits from a the following fact: self.oclistype(b) self.ocliskind(a) (1) as well as the more complicated property: self.oclisdefined() self.oclistype(b) self.oclastype(a).oclastype(b).oclisdefined() and self.oclastype(a).oclastype(b).oclistype(b) (2) proc. oclapps 2006 8 / 18 eceasst fun c a s t _ c l a s s _ i d c l a s s p a r e n t t h y = l e t v a l pname = name_of p a r e n t v a l cname = name_of c l a s s v a l thmname = " c a s t _ " ^ ( cname ) ^ " _ i d " 5 v a l g o a l _ i = mkgoal_cterm ( const ( i s _ c l a s s _ o f c l a s s , dummyt ) $free ( " o b j " ,dummyt ) ) ( const ( " op = " ,dummyt ) $ ( const ( p a r e n t 2 c l a s s _ o f c l a s s pname , dummyt ) $ ( const ( c l a s s 2 g e t _ p a r e n t c l a s s pname , dummyt ) $free ( " o b j " ,dummyt ) ) ) $ ( free ( " o b j " ,dummyt ) ) ) 10 v a l thm = prove_goalw_cterm t h y [ ] g o a l _ i (λ p ⇒ [ c u t _ f a c t s _ t a c p 1 , (∗ p r o o f s c r i p t ∗) a s m _ f u l l _ s i m p _ t a c ( hol_ss addsimps [ o_def , 15 g e t _ d e f t h y ( p a r e n t 2 c l a s s _ o f c l a s s pname ) , g e t _ d e f t h y ( c l a s s 2 g e t _ p a r e n t c l a s s pname ) ] ) 1 , s t a c ( get_thm t h y (name mk_get_parent ) ) 1 , a s m _ f u l l _ s i m p _ t a c ( hol_ss addsimps [ 20 g e t _ d e f t h y ( i s _ c l a s s _ o f c l a s s ) , get_thm t h y (name ( " i s _ " ^pname^ " _mk_ " ^ ( cname ) ) ) ] ) 1 , s t a c ( get_thm t h y (name ( " get_mk_ " ^ ( cname ) ^ " _ i d " ) ) ) 1 , allgoals ( s i m p _ t a c ( hol_ss ) ) ] ) i n 25 ( f s t ( purethy . add_thms [ ( ( thmname , thm ) , [ ] ) ] ( t h y ) ) ) end listing 5: proving cast and re-cast (simplified) listing 5 presents a simplified version of the sml function cast_class_id that proves the property shown in equation 2. the expression starting in line 5 generates a type-checked instance of the theorem to prove with respect to the current class (and its parent). readers familiar with lcfstyle theorem provers will recognize the “proof script” in lines 10 to 23. finally, the function registers the proven theorem in isabelle’s theorem database. logical rules like those shown in equation 1 or equation 2 or co-induction schemes given by class invariants constitute the objectoriented datatype theory of a given class diagram and represent the basic weapon for proofs over them, in particular verifications of uml/ocl specifications. one could also state these rules by adding corresponding axioms (i. e., unproven facts) during the encoding process, which is definitively easier to implement. instead, our datatype package generates entirely conservative definitions and formally proves these rules from them; this also includes the definition of recursive class invariants, which are in itself not conservative ([bw06a] describes this construction in detail). this strategy ensures two very important properties: 1. our encoding fulfills the required properties, otherwise the proofs would fail, and 2. our encoding is consistent (provided that hol is consistent and isabelle/hol is a correct implementation). 9 / 18 volume 5 (2006) an mda framework supporting ocl figure 3: a hol-ocl session using the isar interface of isabelle one might ask what benefit an end-user will get from conservativity after all. its need becomes apparent when considering recursive object structures or recursive class invariants. stating recursive predicates as axioms can result in logical inconsistency in general. for example: context a inv: not self.ocliskind(a) this invariant requires for all instances of type a not to be of kind a. thus, it is in fact possible to state a variant of russell’s paradox, which leads to "invalid states" in the sense of the standard. our conservative construction requires proofs of side-conditions which will fail in paradoxical situations as the one discussed above (c.f. [bw06a] for details) while admitting the “useful” forms of recursion in class invariants. to get an idea for the amount of work involved, the import of the “company” model (including the ocl specification) presented in the ocl standard [omg03a, chapter 7] generates 1147 conservative definitions and proven theorems, the larger “royals and loyals” model [wk03] generates 2472 conservative definitions and proven theorems. the load process usually proceeds in reasonable times. using hol-ocl (see figure 3) one can now formally prove that a given uml/ocl specification fulfills certain properties. for example, in the case of a secureuml specification one can verify the generated security-related proof obligations, as described in section 7. a simple analysis for class diagrams is shown in figure 3: where the user is about to prove that one invariant of class person implies another one. a more important property of class diagrams one proc. oclapps 2006 10 / 18 eceasst can show is consistency, i. e., there is at least one system state fulfilling all invariants, and there exist functions for all operation specifications satisfying the preand postconditions for legal states. another important property is the refinement relation (e. g., forward-simulation [wd96]) between two class diagrams, stating that one model is a refinement of the other. a further interesting formal technique allows for proving that an implementation (i. e., a “method” in uml terminology) is compliant to a specification (i. e., a pair of preand postconditions). an indepth discussion of these issues is out of the scope of this paper; with respect to the compliance problem, the reader might consult [bw06b]. 6 secureuml support as we want to not only support standard uml/ocl models, but also secureuml models, we have to extend the framework accordingly. in this section, we describe these extensions. 6.1 secureuml support in the model repository we extend the model repository to also contain model information from a secureuml dialect. s i g n a t u r e rep_secure = s i g s t r u c t u r e s e c u r i t y : security_language type model = rep . model ∗ s e c u r i t y . c o n f i g u r a t i o n v a l readxmi : s t r i n g → model 5 end this means, a “secure” model not only contains an “unsecured” model, but also a security “configuration.” the type of this configuration is parametrized by the concrete security language. we currently have one implementation of this signature, corresponding to the secureuml metamodel, i. e., the permissions are given in terms of rbac with additional authorization constraints in ocl. the design allows for other security languages, for example, supporting privacy or usage control policies. the implementation of the security language is responsible for extracting the security model information from a uml/ocl model, where it is usually given by a custom uml profile, i. e., stereotypes and tagged values. the security language is itself parametrized by a design language, i. e., a secureuml dialect. the dialect specifies the actual resources and which actions are possible on these resources, together with corresponding hierarchies over them. we implemented this signature both for the componentuml as well as for the controlleruml dialect of secureuml. 6.2 secureuml support in the code generator the generated code has to ensure that the specified access control policy is actually adhered to. this is in general done by generating access controlled wrapper functions around the sensitive operations. these wrapper functions implement the necessary access control checks by checking the assigned roles of the user and evaluating the associated authorization constraint, throwing an exception in case of no allowed access. in specific cases, for example code generation for certain 11 / 18 volume 5 (2006) an mda framework supporting ocl middleware platforms where the middleware already supports the configuration of access control policies, the code generator can also be used to generate the corresponding configuration files. after the template files are adjusted as just described, we need to define a corresponding cartridge that uses the secured model repository. implementing a cartridge mainly consists of deciding which “features” to support in the template language, i. e., which boolean predicates, which lists, and which variables. as parts of this strongly depend on the secureuml dialect, we implemented a secureuml cartridge that again is parametrized by a secureuml dialect. the secureuml cartridge only knows about the global list of permissions, their assigned roles and constraints, which is information that is independent from the used dialect. the dialect specific cartridges then, e. g., deal with the assignment of actions to permissions. 6.3 secureuml support for hol-ocl at present, our datatype package for hol-ocl supports secureuml indirectly using the model transformation described in the following section. for the future, also first-class secureuml support for hol-ocl is planned. the development of this support requires: • the development of a machine-readable, formal semantics for secureuml, e. g., as an embedding into hol-ocl. similar to the already existing theories covering the uml core and ocl, we have to develop a set of theories covering the secureuml entities and their properties. for example, the development of a generic theory summarizing role-based access control models. • the extension of the existing datatype package with support for the new secureuml theories, i. e., the package must be extended to generate definitions for secureuml entities and, if possible, the generation of proof attempts for security related proof obligations, such as shown below. 7 model transformations in this section, we show how our framework supports the definition of model transformations, and show how hol-ocl can be used to analyze not only uml models, but also secureuml models. namely, we describe a particular model transformation, which converts a given secureuml model into a semantically equivalent pure uml/ocl model: s t r u c t u r e secureuml2holocl : s i g v a l t r a n s f o r m : rep_secureuml_componentuml . model → rep . model end = s t r u c t . . . 5 fun t r a n s f o r m ( design_model , s e c u r i t y _ c o n f ) = l e t v a l t r a n s f o r m e d _ m o d e l = . . . (∗ a d d i t i o n a l o p e r a t i o n s w i t h ∗) (∗ t r a n s f o r m e d p o s t c o n d i t i o n s ∗) v a l auth_env = . . . (∗ c l a s s e s l i k e i d e n t i t y and role ∗) 10 i n t r a n s f o r m e d _ m o d e l @ auth_env end end proc. oclapps 2006 12 / 18 eceasst model element generated operation with ocl constraints class c context c::new():c post: result.oclisnew() and result−>modifiedonly() context c::delete():oclvoid post: self.oclisundefined() and self@pre−>modifiedonly() attribute att context c::getatt():d post: result=self.att context c::setatt(arg:d):oclvoid post: self.att=arg and self.att−>modifiedonly() operation op context c::op_sec(...):... pre: preop post: postop[f() 7→ f_sec(), att 7→ getatt()] table 1: overview of generated operations here rep_secureuml_componentuml is an implementation of the rep_secure signature for the componentuml dialect. the basic idea of this model transformation is to translate every access control requirement in the secureuml model into a postcondition of the corresponding operation that checks whether this operation is allowed or not. in more detail: if an operation is allowed, the postcondition shall remain unchanged (i. e., the system behaviour is identical to the unsecured one), otherwise the transformed postcondition specifies that calling this operation shall have no effect. considering this basic idea, one can deduce certain requirements on the model transformation. for example, the target uml model has to support the specification of ocl constraints that talk about users and their roles. also, every access controlled “action” in the secureuml model has to be represented by an uml operation in the target uml model. the first requirement is quickly dealt with. recall the definition: type rep_secureuml_componentuml . model = rep . model ∗ s e c u r i t y . c o n f i g u r a t i o n for giving the uml model the possibility to talk about users and their roles, we add, corresponding to the security.configuration, appropriate classes like identity and role to the rep.model contained in the secureuml model. role assignments, and role hierarchies are then mapped to invariants of these classes. the second requirement means that a number of operations have to be added to the classes in the uml model. in the secureuml dialect we consider here, the access controlled actions are object creation and object destruction, reading or writing on attribute values, and executing operations. therefore, for each class, attribute and operation in the uml model, the transformation generates operations according to table 1. in the transformation for operations, we do not simply copy the existing postcondition, but transform it by substituting operation and attribute calls with the calls to the likewise generated “secured” operations and accessor functions. this is necessary to ensure the security of the generated system: if the postcondition depends on access controlled information, the access control checks for them have to be fulfilled. otherwise, the system could have a security leak. 13 / 18 volume 5 (2006) an mda framework supporting ocl effect of the security model transformation pre′op 7→ pre ′ op post′op 7→ let auth = authopin if auth then post′op else result.oclisundefined() and set{}−>modifiedonly() endif table 2: overview of transformed constraints in several of the generated postconditions we not only specify what changes, but also that "nothing else" happens during this operation call. using standard ocl this is difficult or even impossible for arbitrary methods: one has to specify that the whole system stays unchanged except for this attribute. therefore, hol-ocl provides an extension of ocl for specifying frame properties within postconditions: set(t)::modifiedonly():boolean. this allows for specifying explicitly the set of object instances that the system can change during a state transition. for details see [bw06a]. the main part, however, of the security model transformation is the generation of the security constraints for the operations generated during the design model transformation. the existing constraints on the generated operations are transformed according to table 2. table 2 applies only to operations generated during the design model transformation. thus, pre′op and post ′ op refer to constraints generated during the transformation described in table 1. as noted above, the pre-existing model elements of the design model are preserved. only the postconditions are changed during this transformation, i. e., the invariants invc for classes c of the design model and the preconditions preop for access-controlled operations stay the same. the transformation wraps the postcondition generated during the design model transformation with an access control check using the authorization expression authop, which evaluates to true if access is granted, and false otherwise. if access is granted, the behavior of this operation will not be changed. otherwise, the transformed postcondition ensures that no result is returned and the system state does not change. the expression authop is built in the following way: let perm1, . . . , permn be the permissions for this operation call, and let rolesi be the set of roles, constri be the authorization constraint associated with permission permi, and constri = (constri[caller7→ctxt.principal.identity.name]) [f() 7→ f@pre(), att 7→ att@pre, aend 7→ aend@pre] be the ocl expression where every occurrence of the non-standard keyword caller in constri is substituted by the expression ctxt.principal.identity.name, which evaluates the name of the current caller using the authorization environment auth_env. note that operation, attribute, and association end calls are substituted by their post-state equivalents. this is necessary because the authorization constraints are evaluated in a postcondition, i. e., after the operation has been called, whereas they have to hold before the operation is called. authop is then defined as the following ocl expression: proc. oclapps 2006 14 / 18 eceasst authop := let perm1:boolean = set{} −>exists(s|ctxt@pre.principal@pre.isinrole@pre(s)) and constr1 −− analogous for perm2 to permn perm:boolean = perm1 or perm2 or ... permn in perm.oclisdefined() and perm this definition explicitly checks the authorization expression for undefinedness, mapping it to false if it is undefined. this is necessary because undefinedness can be caused by user-specified authorization constraints, which form a part of authop. an interesting question to ask now is whether this transformation may turn consistent design models into inconsistent ones, or not. in [bdw06] we answered this question: if the original design model (without security policy) is consistent, and the following security proof obligation spoop holds for all generated operations, then the resulting model is also consistent: spoop := authop implies postop , postop[f() 7→ f_sec(), att 7→ getatt()] the transformation additionally generates these security proof obligations, which can then be proven in hol-ocl. these proof obligations require that whenever someone has access for an operation (authop holds), then the postcondition for this operation does not depend on whether the original attributes and operation calls are used, or the access controlled variants. this essentially requires that the caller also has sufficient access rights to “evaluate” the postcondition. if the postcondition only contains operation calls to other operations, the proof boils down to the check that the caller has sufficient permissions for these operations. however, when the postcondition contains recursive calls to itself, the proof requires an inductive argument. 8 conclusion we have presented a framework for mda comprising ocl support in model transformations, code generation and verification, together with one application of such a combined framework, namely secureuml. in our framework, model transformations can be implemented that produce logical proof-obligations which can be tested or formally verified. in a way, our work can be seen as an approach to extend mde by model-driven formal reasoning. the code generator is a template-based generator which can be easily configured to produce code for various parts of models, target languages and application scenarios that range from runtime-test and injection of security mechanisms, from the generation of web-based services to the infra-structure for distributed component platforms. the techniques in itself are by no means new, but having them integrated into a framework and having access to ocl will, in our view, pave the way for new and up to now unexpected applications. 8.1 related work since code generation is at the heart of model-driven engineering, there is a wealth of similar approaches, e. g., andromda (http://www.andromda.org/), which itself is based on veloc15 / 18 volume 5 (2006) http://www.andromda.org/ an mda framework supporting ocl ity (http://jakarta.apache.org/velocity/). while velocity provides a rich template language with (among others) support for arithmetical, relational and logical operators over user-definable variables, our template language is intentionally simple and restricted, but provides an @eval construct allowing for the execution of arbitrary sml code. another difference lies in our concept of cartridges: velocity supports cartridges only in form of an unstructured merging of the “context” object(s). in contrast, our cartridge concept is hierarchically structured, which is type-checked on the sml module level. there are only few proof environments for ocl; most notably the key tool [abb+05]. it offers a concrete verification method for a java-like language (which hol-ocl does not at present) at the dispense of compliance to the semantic foundations of ocl—the underlying semantics is a two-valued dynamic logic with an axiomatic representation of the data-models resulting from class diagrams. with umlsec [jür04] we share the conviction that security models should be integrated into the software engineering development process by using uml. however, although umlsec provides a formal semantics, it does only provide rudimentary tool support, both for code generation and for (formal) model analysis. 8.2 lessons learned 8.2.1 using functional programming languages. using a functional programming language for an object-oriented data model (e. g., the uml meta model) has advantages and disadvantages: on the one hand, a direct compilation into sml datatypes, leads to a quite substantial duplication of code for the inherited attributes and possibly in the pattern matching based functions processing these data structures. nevertheless, the advantages of type-safe pattern matching over constructors outweigh by far the disadvantages, in particular in comparison to untyped script-like transformation languages such as xslt. we have been very pleased by the degree of abstraction and re-usability that has been achieved in the code generator by using the sml functor concept. to our knowledge, this is the first time that it had been applied to the concept of cartridges, which allows for a type-safe and aspectoriented way to describe the compilation process. 8.2.2 building a toolchain. our toolchain for uml/ocl depends on the common xmi format for tool exchange. this has been the key for re-using work of other research groups in the field. however, in practice, each tool uses slightly different variants of the underlying meta-model, and thus different xmi variants. by having an infrastructure based on a general xml parser and pattern matching-based conversions between an imported xmi and the internal su4sml model repository, it turned out to be a fairly easy routine task to adapt to various xmi dialects. 8.3 future work one obvious limitation of our current implementation is the lack of an xmi export from su4sml allowing re-import into argouml: this would pave the way for a re-interpretation and a reproc. oclapps 2006 16 / 18 http://jakarta.apache.org/velocity/ eceasst visualization of the results of model-transformations done on su4sml. usually, the transformed (and expanded) models are less abstract and lengthy, and modifications of the re-engineered models by hand are not really compatible with the mde methodology which emphasizes a toolbased generation process. it remains the question how to deal with injected, hand-written code which can be part of a model in mde. there are essentially two options: a code-verification approach or a systematic test approach. with respect to the code-verification, a hoare calculus has already been derived for ocl for a simple imperative language [bw06b]. to allow code-verification for programs of at least modest size effectively, however, a verification condition generator has to be added and the degree of automation of tailored proof-tactics must be increased. with respect to the testing approach, it is tempting to adapt a test-case generation system to ocl. two of the authors developed the test-data-generator hol-testgen based on specifications in hol, which has been used for substantial case-studies in black-box unit test [bw04], gray-box unit test [bw05] and sequence test [bw07]. hol-testgen and hol-ocl are both built on the same technical and logical platform, namely isabelle/hol. however, the technical challenge of an adaption of hol-testgen consists in basing its partitioning component (computing symbolically a normal form called tnf; see [bw04] for details) on a three-valued logic such as ocl. references [abb+05] w. ahrendt, t. baar, b. beckert, r. bubel, m. giese, r. hähnle, w. menzel, w. mostowski, a. roth, s. schlager, p. h. schmitt. the key tool. software and system modeling 4:32–54, 2005. doi:10.1007/s10270-004-0058-x [bdl06] d. basin, j. doser, t. lodderstedt. model driven security: from uml models to access control infrastructures. acm transactions on software engineering and methodology 15(1), january 2006. doi:10.1145/1125808.1125810 [bdw06] a. d. brucker, j. doser, b. wolff. a model transformation semantics and analysis methodology for secureuml. in nierstrasz et al. (eds.), models 2006. lncs 4199, pp. 306–320. springer, 2006. doi:10.1007/11880240_22 [bs05] b. beckert, s. schlager. refinement and retrenchment for programming language data types. formal aspects of computing 17(4):423–442, 2005. doi:10.1007/s00165-005-0073-x [bw04] a. d. brucker, b. wolff. symbolic test case generation for primitive recursive functions. in grabowski and nielsen (eds.), formal approaches to testing of software. lncs 3395, pp. 16–32. springer-verlag, 2004. doi:10.1007/b106767 17 / 18 volume 5 (2006) http://dx.doi.org/10.1007/s10270-004-0058-x http://dx.doi.org/10.1145/1125808.1125810 http://dx.doi.org/10.1007/11880240_22 http://dx.doi.org/10.1007/s00165-005-0073-x http://dx.doi.org/10.1007/b106767 an mda framework supporting ocl [bw05] a. d. brucker, b. wolff. interactive testing using hol-testgen. in grieskamp and weise (eds.), formal approaches to testing of software. lncs 3997, pp. 87– 102. springer-verlag, edinburgh, 2005. doi:10.1007/11759744_7 [bw06a] a. d. brucker, b. wolff. the hol-ocl book. technical report 525, eth zürich, 2006. [bw06b] a. d. brucker, b. wolff. a package for extensible object-oriented data models with an application to imp++ . in roychoudhury and yang (eds.), international workshop on software verification and validation (svv 2006). aug. 2006. [bw07] a. d. brucker, b. wolff. test-sequence generation with hol-testgen – with an application to firewall testing. in international conference on tests and proofs. 2007. to appear. [jür04] j. jürjens. secure systems development with uml. springer, 2004. doi:10.1007/b137706 [mel92] t. f. melham. a package for inductive relation definitions in hol. in archer et al. (eds.), the hol theorem proving system and its applications. pp. 350–357. ieee computer society press, 1992. [npw02] t. nipkow, l. c. paulson, m. wenzel. isabelle/hol—a proof assistant for higherorder logic. lncs 2283. springer, 2002. [omg03a] uml 2.0 ocl specification. oct. 2003. available as omg document ptc/2003-10-14. [omg03b] omg unified modeling language specification, v1.5. mar. 2003. available as omg document formal/03-03-01. [pau96] l. c. paulson. ml for the working programmer. cambridge university press, 1996. [scfy96] r. s. sandhu, e. j. coyne, h. l. feinstein, c. e. youman. role-based access control models. ieee computer 29(2):38–47, feb. 1996. doi:10.1109/2.485845 [wd96] j. woodcock, j. davies. using z: specification, refinement, and proof. prentice hall international series in computer science. prentice hall, 1996. [wk03] j. warmer, a. kleppe. the object constraint language: getting your models ready for mda. addison-wesley, 2nd edition, aug. 2003. proc. oclapps 2006 18 / 18 http://dx.doi.org/10.1007/11759744_7 http://dx.doi.org/10.1007/b137706 http://www.omg.org/cgi-bin/doc?ptc/2003-10-14 http://www.omg.org/cgi-bin/doc?formal/03-03-01 http://dx.doi.org/10.1109/2.485845 introduction our framework: an overview background hol-ocl. secureuml. the toolchain the model repository: su4sml a template-based code generator a su4sml-based datatype package for hol-ocl secureuml support secureuml support in the model repository secureuml support in the code generator secureuml support for hol-ocl model transformations conclusion related work lessons learned using functional programming languages. building a toolchain. future work navigating across non-navigable ecore references via ocl electronic communications of the easst volume 36 (2010) proceedings of the workshop on ocl and textual modelling (ocl 2010) navigating across non-navigable ecore references via ocl martin hanysz, tobias hoppe, axel uhl, andreas seibel, holger giese, philipp berger and stephan hildebrandt 6 pages guest editors: jordi cabot, tony clark, manuel clavel, martin gogolla managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst navigating across non-navigable ecore references via ocl martin hanysz1, tobias hoppe1, axel uhl2, andreas seibel1, holger giese1, philipp berger1 and stephan hildebrandt1 1 holger.giese@hpi.uni-potsdam.de, http://www.hpi.uni-potsdam.de/giese/ hasso plattner institute at the university of potsdam prof.-dr.-helmert-str. 2-3, 14482 potsdam, germany 2 axel.uhl@sap.com sap ag, office of the cto dietmar-hopp-allee 16, 69190 walldorf, germany abstract: the eclipse modeling framework (emf) and its meta-meta model ecore support uni-directional and bi-directional references. it is quite common that references are defined uni-directionally only because of saving storage space or separating meta models, which is problematic when implementing object constraint language (ocl) constraints that require navigation against the direction of unidirectional references. this is essential for certain approaches, e.g., incremental evaluation of ocl constraints on models shown by altenhofen et al. that is used in sap’s modeling infrastructure (moin). in this paper, we present an approach that overcomes the aforementioned issue by providing navigation across non-navigable ecore references via ocl. we further discuss different alternative solutions and briefly describe the realization that was outcome of a project in cooperation with the sap ag. keywords: ocl, ecore, emf, navigation 1 introduction the object constraint language (ocl) [obj06b] was originally designed as a formal language to describe invariants and queries on unified modeling language (uml) [obj04] models. nowadays, the application of ocl is more extensive, e.g., it is applied in meta object facility (mof) [obj06a] compliant tools or the eclipse modeling framework (emf) [sbpm08] to constrain emf models that are conform to the meta-meta model ecore. however, in contrast to complete mof (cmof) [obj06a, pp. 45], ecore, which is conceptually equal to essential mof (emof)[obj06a, pp. 31], uses the restricted reference concept of emof. in cmof references (associations) always have association ends, which implies that there is always the possibility to address the opposite of a reference, even if the reference is defined as uni-directional. in ecore references are always uni-directional. a bi-directional reference is realized by explicitly modeling two references as being the opposite of each other. additionally, ecore does not support the concept of association ends. thus, if defining a reference as uni-directional, the opposite of the ecore reference cannot be addressed. defining bi-directional references between elements of different meta models is not supported by emf, because it would result in cyclic 1 / 6 volume 36 (2010) mailto:holger.giese@hpi.uni-potsdam.de http://www.hpi.uni-potsdam.de/giese/ mailto:axel.uhl@sap.com dependencies between these meta models. this is problematic because legacy emf meta models do not always provide bi-directional references (cf. uml2 tools1) to save storage space and meta models may be separated in several meta models (separation of concerns). in both cases, ocl constraints cannot be expressed against navigation direction. this is essential for certain approaches, e.g., incremental evaluation of ocl constraints on models shown by altenhofen et al. in [ahk07] that is implemented in sap’s modeling infrastructure (moin). furthermore, ocl constraints can be optimized by restructuring navigation, which is restricted when references are uni-directional. thus, navigating across non-navigable references via ocl is required to overcome this issue in such cases. in this paper, we present an approach that overcomes this issue with minimal impact to existing applications. it supports navigation across non-navigable references via ocl within and between emf meta models without adding cyclic dependencies. the approach was implemented as a part of a project (see [ber10, hop10, han10, sch10]) in cooperation with the sap ag2. therefore, we first introduce our requirements and design decisions in section 2. in section 3 we give a brief explanation of our approach and finally conclude this paper in section 4. 2 design considerations to support the acceptance of our approach by the emf community, the following requirements have to be satisfied: 1. avoid invalidation of existing technologies 2. avoid impact on current usage of technologies 3. avoid high integration efforts there are several alternatives to provide navigation across non-navigable references in ecore. a straightforward approach is to only use bi-directional references in emf models instead of unidirectional ones. consequently, partitioning of emf models would be restricted due to cyclic dependencies and the partition in two meta models as shown in figure 1 would not be possible. this clearly violates requirement two, because it restricts how emf models can be partitioned. another approach that avoids the dependency cycles a bi-directional reference creates, is to allow the opposite reference to be contained by the original reference. this circumvents the limitations of the aforementioned approach, but yields severals other problems. for example the validation of multiplicity or ordering constraints for the opposite reference becomes a very expensive operation, due to the fact that the list of referenced instances is not stored explicitly. apart from that, the original architecture assumes that a reference is always contained by an element. since this assumption does not hold anymore, existing technologies relying on it might be invalidated. to circumvent those requirement violations, another alternative that avoids to change ecore has been taken into account. it relies on annotations, which are added to uni-directional references in emf models, as shown in figure 1. the example shows a simple situation with two 1 http://www.eclipse.org/uml2/ 2 http://www.sap.com proc. ocl 2010 2 / 6 eceasst figure 1: an example that visualizes the problem of uni-directional references meta models defining two concerns of a company. the annotations contain opposite role names of the references. this solution does not impact the usage of existing technologies, because it can be seamlessly integrated into existing emf models. it also does not impact requirement three since these annotations can be automatically generated. to navigate across non-navigable references using these annotations, we extend the ocl meta model as well as the ocl tooling of emf. our extension of ocl does not invalidate requirement two because it is downward compatible. 3 contribution in this section, we explain how we exploit the annotation concept of ecore and the extensions we have made to the ocl tooling in emf. 3.1 adding annotations to emf models annotations in ecore are defined by the eannotation element, which can be added to any element. eannotation may have a details entry, that maps key to value attributes. in our approach, every uni-directional reference that should be navigated in its opposite direction, represented by an ereference element, is associated with an eannotation element holding a details entry that has a key attribute “property.oppositerolename”. the value attribute contains the name of the opposite role. emf models that should benefit from bi-directional navigability can be modified manually or automatically. 3.2 extending ocl our approach does not come without extending emf’s ocl, but we are using the dot notation for navigation across references to be compatible to legacy ocl constraints. thus, there is no need to introduce an extra notation to make the missing navigability explicit. for example, the expression in figure 2 refers to the annotated opposite role name of the ereference intern. this constraint expresses, that each student must have at least one employee as his advisor. the extensions we have made are in the background and extend ocl’s abstract syntax (meta model), as well as its parser, validator, and evaluator. 3 / 6 volume 36 (2010) c o n t e x t s t u d e n t i n v : s e l f . a d v i s o r . s i z e ( ) > 0 figure 2: an example ocl expression using reverse navigation 3.2.1 abstract syntax of ocl although we did not change the concrete syntax of ocl, we have extended the abstract syntax of ocl to reflect the navigation across non-navigable references. therefore, we extended the navigationcallexp with an oppositepropertycallexp as shown in figure 3. an oppositepropertycallexp describes the navigation of a reference between two elements that are not explicitly connected via an ereference pointing from the source element to the target elements, which avoids cyclic dependencies if elements are defined in different meta models. instead, this association is built by an ereference from the target that defines the opposite navigation direction. the oppositepropertycallexp inherits a navigation source property, which is the element from where the navigation is started. it is also related to a referred opposite property, which contains the opposite role name that is defined in the eannotation of an ereference pointing to the navigation source element. figure 3: extended ocl meta model 3.2.2 ocl parser ocl constraints are handled by means of their abstract syntax. thus, ocl constraints defined in the concrete syntax have to be parsed into the abstract syntax first. the parsing of ocl constraints in emf is performed by an ocl analyzer. we extended the parsing functionality to create oppositepropertycallexp instances when necessary. when the ocl analyzer comes across the dot notation, it tries to resolve the token next to it to a type name, a variable name, a property name, an opposite property name, an association class name, and finally to an undefined name. the resolving of an opposite property name is proc. ocl 2010 4 / 6 eceasst encapsulated in the oppositeendfinder to allow different implementations of it3. the example in figure 2 contains an opposite property after the first dot, since advisor is the annotated opposite role name of the ereference intern. hence, an oppositepropertycallexp is created. 3.2.3 ocl validator after parsing the ocl expression into an abstract syntax, it needs to be validated. throughout the whole ocl tooling of emf, several visitors are used. to make these visitors aware of opposite properties, the common visitor interface has been extended with a visitoppositepropertycallexp() method and the abstractvisitor has been adapted to properly call this method when coming across an oppositepropertycallexp. the visitor used to validate ocl expressions is the validationvisitor and has been modified to implement this method to check if the correctness of the oppositepropertycallexp is given. 3.2.4 ocl evaluator the ocl evaluator actually executes the evaluation of the parsed and validated ocl expression. for this task, the evaluationvisitor is used. it has also been modified to implement the visitoppositepropertycallexp() method and use a modified, opposite property aware version of the evaluationenvironment to perform the navigation. navigating an oppositepropertycallexp results in the set of instances, that reference one of the expression’s source instances via an ereference that is annotated with the given opposite role name. therefore, the evaluation of the expression in figure 2 leads from self to all instances of employee that reference that one instance of student. our approach uses emf’s reflection mechanism for resolving the requires instances to avoid cyclic dependencies between meta models. to find all instances pointing to an eobject via an ereference, emf provides a utility called ecrossreferenceadapter. the cross-referencer iterates through the content tree rooted at the initially passed eobject, resource, or resourceset and checks for each retrieved reference of all objects if it points to the wanted object or not. in case of a positive match, the object is added to the result [sbpm08, pp. 523]. because the cross-referencer is a simple implementation, we may get scalability issues when dealing with large models. thus, we have implemented a modular interface to integrate alternative technologies for resolving oppositepropertycallexps, e.g, model query 2 (mq2)4. mq2 provides an efficient interpreter for resolving queries, which comes with an index structure. in this alternative, mq2 queries are formulated and interpreted to return all objects referencing the source via an ereference with a specific eannotation. 4 conclusions & future work throughout this paper, we presented a solution that overcomes a restriction of ecore. this restriction prohibits navigability through emf models via ocl constraints, because uni-directional 3 currently model query 2 is used to find the properly annotated references 4 http://www.eclipse.org/modeling/emf/?project=query2 5 / 6 volume 36 (2010) references cannot be navigated in reverse. this is problematic, when working with emf models that provide many uni-directional references (cf. uml2 tools). our approach can be seamlessly integrated into existing technologies. it uses the eannotation concepts of ecore. these annotations are used by an extension of emf’s ocl that we have implemented. as future work we plan to evaluate the scalability of our approach by using emf’s crossreferencer, mq2, and other indexing technologies like emf index5. furthermore, multiplicities cannot be expressed via the annotations currently. bibliography [ahk07] m. altenhofen, t. hettel, s. kusterer. ocl support in an industrial environment. in proc. of the workshops and symposia at models 2006, genoa, italy. lncs, pp. 169–178. springer, 2007. [ber10] p. berger. central event manager for the eclipse modeling framework. 2010. http://www.hpi.uni-potsdam.de/giese/gforge/bibadmin/uploads/pdf/ber10 philipp berger bachelorarbeit.pdf. [han10] m. hanysz. instance-based context calculation of ocl expressions. 2010. http://www.hpi.uni-potsdam.de/giese/gforge/bibadmin/uploads/pdf/han10 martin hanysz bachelorarbeit.pdf. [hop10] t. hoppe. synthesis of event filter determining the reevaluation of affected ocl expressions. 2010. http://www.hpi.unipotsdam.de/giese/gforge/bibadmin/uploads/pdf/hop10 tobiashoppe bachelorarbeit .pdf. [obj04] object management group. uml 2.0 superstructure specification. october 2004. document: ptc/04-10-02 (convenience document). [obj06a] object management group. meta object facility. 2.0 edition, january 2006. [obj06b] object management group. object constraint language. 2.0 edition, may 2006. [sbpm08] d. steinberg, f. budinsky, m. paternostro, e. merks. eclipse modeling framework 2.0. addison wesley, 2 edition, december 2008. [sch10] t. schröter. effiziente navigation bei der ocl-auswertung. 2010. http://www.hpi.uni-potsdam.de/giese/gforge/bibadmin/uploads/pdf/schroeter10 thea schroeter bachelorarbeit.pdf. 5 www.eclipse.org/proposals/emf-index/ proc. ocl 2010 6 / 6 introduction design considerations contribution adding annotations to emf models extending ocl abstract syntax of ocl ocl parser ocl validator ocl evaluator conclusions & future work specification and verification of model transformations electronic communications of the easst volume 30 (2010) international colloquium on graph and model transformation on the occasion of the 65th birthday of hartmut ehrig (gramot 2010) specification and verification of model transformations frank hermann, mathias hülsbusch, barbara könig 20 pages guest editors: claudia ermel, hartmut ehrig, fernando orejas, gabriele taentzer managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst specification and verification of model transformations ∗ frank hermann1, mathias hülsbusch2, barbara könig2 1 institut für softwaretechnik und theoretische informatik, technische universität berlin, germany, frank(at)cs.tu-berlin.de 2 abteilung für informatik und angewandte kognitionswissenschaft, universität duisburg-essen, germany, {mathias.huelsbusch,barbara koenig}(at)uni-due.de abstract: model transformations are a key concept within model driven development and there is an enormous need for suitable formal analysis techniques for model transformations, in particular with respect to behavioural equivalence of source models and their corresponding target models. for this reason, we discuss the general challenges that arise for the specification and verification of model transformations and present suitable formal techniques that are based on graph transformation. in this context, triple graph grammars show many benefits for the specification process, e.g. modelers can work on an intuitive level of abstraction and there are formal results for syntactical correctness, completeness and efficient execution. in order to verify model transformations with respect to behavioural equivalence we apply well-studied techniques based on the double pushout approach with borrowed context, for which the model transformations specified by triple graph transformation rules are flattened to plain (in-situ) graph transformation rules. the potential and adequateness of the presented techniques are demonstrated by an intuitive example, for which we show the correctness of the model transformation with respect to bisimilarity of source and target models. keywords: model transformation, behavioural equivalence, verification 1 introduction in the setting of model driven architecture (mda), a system is implemented by first specifying an abstract model, which is subsequently refined to executable code. this is done by model transformations, which transform a source model into a more concrete target model. the object mangaement group has also introduced a standard for model transformations: qvt (query/view/transformation). a special case is refactoring, where only the internal structure of the model or system is changed and potentially optimized. since refactorings are expected not to modify the functional behaviour of the system, the notion of behaviour preservation is crucial: how can we specify and verify that a model keeps its original behaviour after several refactoring ∗ research supported by dfg project behaviour-gt. 1 / 20 volume 30 (2010) specification and verification of model transformations steps? the same question is often relevant for model transformations, in order to show that the implementation matches the original specification. in this paper we will summarize some results on the specification and verification of model transformations. as underlying modelling framework we will use graph transformation, which is well-suited to handle the graph-like structures usually arising in mda and uml. however, many existing model transformations in practice are directly encoded as e.g. xslt-transformations. as a first contribution of this paper we will discuss the main challenges of model transformations and present the main benefits of using graph transformation with respect to technical results and with respect to usability. the main two aims of the paper are the following. first, we introduce recent results on triple graph grammars, a formalism that allows to specify model transformations by constructing source and target models simultaneously and recording correspondences. second, we will describe a technique for verifying that model transformations translate source models into bisimilar target models, using a variation of the borrowed context technique. for this, we will derive in-situ transformation rules from triple graph grammars. both parts of the paper are based on the same example: a model transformation translating network-like models with different types of (bidirectional and unidirectional) links. the structure of the paper is as follows. section 2 describes the various challenges arising in the area of model transformation. sections 3 and 4 subsequently introduce triple graph grammars for the specification of model transformations and describe several results obtained for triple graph grammars (e.g., syntactical correctness and completeness). in section 5 we describe how to verify the example transformation using the borrowed context technique. finally, we will compare with related work in section 6 and conclude (section 7). 2 challenges for model transformations model transformations appear in several contexts, e.g. in the various facets of model driven architecture encompassing model refinement and interoperability of system components. the involved languages can be closely related or they can be more heterogeneous, e.g. in the special case of model refactoring the source language and the target language are the same. from a general point of view, a model transformation mt : vls v vlt between visual languages transforms models from the source language vls to models of the target language vlt . main challenges were described in [sk08] for model transformation approaches based on triple graph grammars. here, we extend this list and also the scope and describe general challenges for model transformations. there are two dimensions, which contain major challenges for model transformations being on the one hand functional aspects and on the other hand non-functional aspects. the first dimension of functional aspects concerns the reliability of the produced results. depending on the concrete application of a model transformation mt : vls v vlt , the following properties may have to be ensured. 1. syntactical correctness: for each model ms ∈vls that is transformed by mt the resulting model mt has to be syntactically correct, i.e. mt ∈ vlt . proc. gramot 2010 2 / 20 eceasst 2. semantical correctness: the semantics of each model ms ∈ vls that is transformed by mt has to be preserved or reflected, respectively. 3. completeness: the model transformation mt can be performed on each model ms ∈ vls. additionally, it can be required that mt reaches all models mt ∈ vlt . 4. functional behaviour: for each source model ms the model transformation mt will always terminate and lead to the same resulting target model mt . the second dimension of non-functional aspects of model transformations concerns usability and applicability. therefore, from the application point of view some of the following challenges are also main requirements. 1. efficiency: model transformations should have polynomial space and time complexity. furthermore, there may be further time constraints that need to be respected, depending on the application domain and the intended way of use. 2. intuitive specification: the specification of model transformations can be performed based on patterns that describe how model fragments in a source model correspond to model fragments in a target model. if the source (resp. target) language is a visual language then the components of the model transformation can be visualized using the concrete syntax of the visual language. 3. maintainability: extensions and modifications of a model transformation should be easy. side effects of local changes should be handled and analyzed automatically. 4. expressiveness: specifications of model transformations should be expressive enough. for instance, special control conditions have to be available in order to handle more complex models, which, e.g., contain substructures with a partial ordering or hierarchies. 5. bidirectional model transformations: the specification of a model transformation should provide the basis for both, a model transformation from the source to the target language and a model transformation in the inverse direction. in the following section we present suitable techniques for the specification of model transformations based on graph transformation. these techniques provide validated and verified capabilities for a wide range of the challenges listed above. 3 specification of model transformations by triple graph grammars a promising and well studied approach for the specification of model transformations is based on triple graph transformation [sch94]. this section presents its main concepts and sec. 4 shows its advantages from the formal and from the application point of view. the most important advantage of triple graph transformation is the combination of both, its intuitive way of specifying 3 / 20 volume 30 (2010) specification and verification of model transformations model transformations and its formal basis, for which correctness and completeness results are available. triple graphs combine three graphs one for the source model, one for the target model and one in between, together with connecting graph morphisms for the specification of the correspondences between the elements in the source and the target model. this extension of plain graphs improves the definition of model transformations. source models are parsed and their corresponding target models are completed without the need of deleting the source model in between. the correspondences between both models are used to guide the transformation process. definition 1 (category triplegraphs) three graphs gs, gc, and gt , called source, connection, and target graph, together with two graph morphisms sg : gc → gs and tg : gc → gt form a triple graph g = (gs ←sg−− gc −tg−→ gt ). g is called empty, if gs, gc, and gt are empty graphs. a triple graph morphism m = (ms, mc, mt ) : g → h between two triple graphs g = (gs ←sg−− gc −tg−→ gt ) and h = (h s ←sh−− hc −th−→ h t ) consists of three graph morphisms ms : gs → h s, mc : gc → hc and mt : gt → h t such that ms ◦sg = sh ◦mc and mt ◦ tg = th ◦mc. it is injective, if morphisms ms, mc and mt are injective. triple graphs and triple graph morphisms form the category triplegraphs. given a triple graph tg, called type graph, the category triplegraphstg of typed triple graphs is given by the slice category triplegraphs\tg. d c dc y tgs tgc tgt x tgt src xy tgt src u node uc figure 1: triple type graph tg = (t gs ← t gc → t gt ) in the examples of this paper we consider a model transformation mt : bididilang v unidilang between communication structure models. the language bididilang contains models with bidirectional and unidirectional links and these models are transformed to models with unidirectional connections only in the language unidilang. each pair of corresponding source and target models is given by a triple graph typed over the triple type graph tg in fig. 1, which extensively uses the concept of labeled nodes, i.e. loops of different edge types. this allows us in sec. 5.2 to merge different node types in a compact type graph in order to verify the semantical correctness of the model transformation. for this purpose, we transform the triple rules into suitable in-situ rules and analyze them with respect to the rules of the mixed semantics, i.e. a semantics for models that simultaneously contain source and target elements. proc. gramot 2010 4 / 20 eceasst in order to improve the intuition of triple graphs typed over tg we present the graphs visually. the source, correspondence and target components of the triple graphs are separated by rectangles. the fill colours additionally improve this separation. elements in the source model are light red while they are blue in the correspondence and yellow in the target model. furthermore, the node types “x”, “d” (directed link), “u” (undirected link), “y”, “c” (connection) as well as “xy”, “dc” and “uc” for the correspondence component will internally be represented by loops at the different nodes and we simplify the presentation by putting the label inside the node rectangle resp. hexagon. tgs xy dc tgc tgt x y d u tgt node c tgt uc src src figure 2: visualization of the triple type graph tg xyx y xyx y u c node node src tgt uc c src tgt uc d srctgt dc c gs gc g t src tgt figure 3: triple graph g with source model gs and target model gt example 1 (triple graph) the triple graph in fig. 3 is typed over tg and shows an integrated model consisting of a source model gs (left) and a target model gt (right), which are connected via the correspondence nodes in the correspondence graph gc. the source model specifies a node with label “x” having a message “m”, a self-referring directed link “d” and an outgoing undirected link “u”. similarly the target model contains two nodes, but labelled with “y”, and instead of one undirected link between both nodes there are two connections “c” defining possibilities for communication in both directions. the corresponding elements of both models are 5 / 20 volume 30 (2010) specification and verification of model transformations related by graph morphisms (indicated by dashed lines) from the correspondence graph (light blue) to the source and target componencts, respectively. a triple graph grammar generates a language of triple graphs, i.e. a language of integrated models consisting of models of the source and the target language and a correspondence structure in between. the triple rules of a triple graph grammar specify the synchronous creation of elements in the source component and its corresponding elements in the target component. therefore, triple rules are non-deleting. the triple rules of a triple graph grammar are the basis for deriving the operational rules of the model transformation from models of one language into the other. definition 2 (triple graph transformation and triple graph grammar) a triple rule tr = l −tr→ r is an injective triple graph morphisms tr from a triple graph l (left hand side) to a triple graph r (right hand side). a triple graph grammar tgg = (tg, s, tr) consists of a triple graph tg (type graph), a triple graph s (start graph) and triple rules tr both typed over tg. given a triple rule tr = (trs,trc,trt ) : l → r, a triple graph g and an injective triple graph morphism m = (ms, mc, mt ) : l → g, called triple match m, a triple graph transformation step (tgt-step) g = tr,m ==⇒ h from g to a triple graph h is given by a pushout in triplegraphs. the triple graph language l of tgg is defined by l = {g| ∃ triple graph transformation s ⇒∗ g}. l = (ls tr �� m s �� lc sloo mc �� tl // t l) mt�� r = (rs rcsr oo tr // rt ) triple rule l m �� tr // r n �� (po) g t // h transformation step model transformations based on triple graph transformation are performed by taking the source model and extending it to an integrated model, where all its corresponding elements in the correspondence and target component are completed. thereafter, this integrated model is restricted to its target component, which is the result of the model transformation. for this reason, triple graph transformation rules are non-deleting. this implies that the first step in the dpo graph transformation approach [eept06] can be omitted, because the creation of elements is performed in the second step. example 2 (triple graph grammar) the triple graph grammar tgg = (tg, /0, tr) for the model transformation mt : bididilang v unidilang contains the triple type graph in fig. 2, the empty start graph and the rules tr in fig. 4. each rule specifies a pattern that describes how particular fragments of the communication structure models shall be related. we present the rules in compact notation, i.e. the left and the right hand side of a rule are shown in one triple graph and the additional elements that occur in the right hand side only are marked by green line colour and a double plus sign. the rule “nodex2nodey” synchronously creates an “x” node in the source model and its corresponding “y” node in the target model. thus, in this case the left hand side of this rule is the empty triple graph, because all elements are created. the rule “directed2connection” creates directed links “d” between two “x” nodes in the source component and their corresponding proc. gramot 2010 6 / 20 eceasst connection “c” between the related “y” nodes in the target component. finally, the rule “undirected2connection” creates an undirected link “u” in the source component and relates it with two connections “c” for the communication in both directions between the “y” nodes that are already related to the “x” nodes in the source component. nodex2nodey ++ ++ ++ xyx y directed2connection ++ ++ xyx y xyx y d c src tgt src tgt dc ++ ++ undirected2connection ++ ++++ ++ ++ xyx y xyx y u c node node src tgt uc ++ ++++ ++ ++ c src tgt ++ ++ ++ uc ++ figure 4: triple rules of the triple graph grammar tgg based on the triple rules of a triple graph grammar, the operational source and forward rules for model transformations from models of the source language to models of the target language are derived automatically [sch94, kw07, eee+07]. the source rules will be used to parse the given source model of a forward model transformation, which guides the forward transformation, in which the forward rules are applied. since triple rules have a symmetric character, the backward rules for backward model transformations from models of the target to models of the source language can be derived as well. definition 3 (derived source and forward rule) given a triple rule tr = (trs,trc,trt ) : l → r the source rule trs : ls → rs is derived by extending the graph morphism trs : ls → rs with empty graphs and empty morphisms for the remaining correspondence and target components, i.e. lcs = l t s = r c s = r t s = /0. the forward rule trf = (tr s f ,tr c f ,tr t f ) is derived by taking tr and redefining the following components: lsf = r s, trsf = id, and slf = tr s ◦sl. l = (ls tr �� tr s �� lc sloo trc �� tl // lt ) trt�� r = (rs rcsr oo tr // rt ) triple rule tr ls = (ls trs �� tr s �� /0oo �� // /0) �� rs = (rs /0oo // /0) source rule trs lf = (rs trf �� id �� lc trs ◦ sloo trc �� tl // lt ) trt�� rf = (rs rcsr oo tr // rt ) forward rule trf example 3 (derived rules) the derived forward rules and one derived source rule of the triple 7 / 20 volume 30 (2010) specification and verification of model transformations nodex2nodeyf ++ ++ xyx y directed2connectionf ++ xyx y xyx y d c src tgt dc ++ undirected2connectionf ++++ ++ xyx y xyx y u c src tgt uc ++ ++ ++ c src tgt ++ ++ ++ uc ++ src node node tgt nodex2nodeys ++ x (source rule) (forward rule) (forward rule) (forward rule) figure 5: some derived source and forward rules graph grammar tgg in fig. 4 are shown in fig. 5. the source rule “nodex2nodeys” creates a single “x” node and will be used to parse all nodes with label “x” in a given source model of a model transformation. based on the found matches the corresponding forward rule “nodex2nodeyf” will be applied and it will insert a “y” node in the target component for each detected ”x“ node. similarly, the other two forward rules specify the completion of the correspondence and target structure for communication links in the source component. directed “d” links are transformed to directed “c” connections between the already translated and corresponding “y” nodes. for undirected “u” links we create two connections in both directions to complete the integrated model fragment. as introduced in [eee+07, ehs09] model transformations can be defined based on source consistent forward transformations g0 =⇒∗ gn via (tr1,f , . . . , trn,f ), short g0 = tr∗f=⇒ gn. source consistency intuitively means that the source model in g0 can be parsed and all its elements are translated exactly once into corresponding fragments in the resulting target model. more precisely, source consistency of g0 = tr∗f=⇒ gn requires that there is a source sequence ∅ = tr∗s=⇒ g0 such that the sequence ∅ = tr∗s=⇒ g0 = tr∗f=⇒ gn is match consistent, i.e. the s-component of each match mi,f of tri,f (i = 1..n) is uniquely determined by the comatch ni,s of tri,s, where tri,s and tri,f are source and forward rules of the same triple rules tri. altogether the forward sequence g0 = tr∗f=⇒ gn is controlled by the corresponding source sequence ∅ = tr∗s=⇒ g0, which is unique in the case of match consistency. definition 4 (model transformation based on forward rules) a model transformation sequence (gs, g0 = tr∗f=⇒ gn, gt ) consists of a source graph gs, a target graph gt , and a source proc. gramot 2010 8 / 20 eceasst consistent forward tgt-sequence g0 = tr∗f=⇒ gn with gs = projs(g0) and gt = projt (gn), where “ pro jx ” is the projection to the x-component of a triple graph for x ∈ {s,c, t}. a model transformation mt : vls0 v vlt 0 is defined by all model transformation sequences (gs, g0 = tr∗f=⇒ gn, gt ) with gs ∈ vls0 and gt ∈ vlt 0. considering the source model in fig. 3 we can construct the following source consistent forward transformation: with gs = gs: (gs ← /0→ /0) = g0 = nodex 2nodeyf ,m1==========⇒ g1 = nodex 2nodeyf ,m2==========⇒ g2 = directed2connectionf ,m3=============⇒ g3 = undirected2connectionf ,m4==============⇒ g4 = (gs ← gc → gt ) and we derive the integrated model g = g4 and the target model gt = gt as shown in fig. 3. 4 results for model transformations based on triple graph grammars there are already many important results for model transformations based on triple graph transformation and in this section we compare the available results with respect to the listed challenges in sec. 2. model transformations based on source consistent forward sequences are syntactically correct and complete with respect to the triple patterns [eehp09], i.e. with respect to the language vl = {g | /0 =⇒∗ g in tgg} containing the integrated models generated by the triple rules. more precisely, each model transformation translates a source model into a target model, such that the integrated model that contains both models can be created by applications of the triple rules to the empty start graph. this means that both models can be synchronously created according to the triple patterns. vice versa, a model transformation can be performed on each source model that is part of an integrated model in the generated triple language vl. for the more formal view on these results we explicitly define the language of translatable source models vls and of reachable target models vlt by vls ={gs | (gs ← gc → gt )∈ vl} and vlt = {gt | (gs ← gc → gt ) ∈ vl}. as shown in [ehs09] and extended in [heog10, hego10] model transformations based on tggs using the control condition source consistency are syntactically correct and complete. theorem 1 (syntactical correctness) each model transformation sequence given by (gs, g0 = tr∗f=⇒ gn, gt ), which is based on a source consistent forward transformation sequence g0 = tr∗f=⇒ gn with g0 = (gs ← /0 → /0) and gn = (gs ← gc → gt ) is syntactically correct, i.e. gn ∈v l. theorem 2 (completeness) for each gs ∈ v ls there exists a model gt ∈ v lt with a model transformation sequence (gs, g0 = tr∗f=⇒ gn, gt ) where g0 = tr∗f=⇒ gn is source consistent with g0 = (gs ← /0 → /0) and gn = (gs ← gc → gt ). functional behaviour of model transformations ensures unique results for any given source model. a powerful as well as efficient technique for analyzing functional behaviour of model transformations based on tggs is presented in [heog10, hego10] based on the generation 9 / 20 volume 30 (2010) specification and verification of model transformations of translation attributes and using the critical pair analysis engine of the tool agg [agg09]. the presented example in this paper already shows functional behaviour for the forward transformation. however, for the backward direction the behaviour is not functional. consider, e.g., two “y” nodes that are connected by two connections “c” in opposite direction. they can be transformed to one unidirectional link or to two directed links. concerning the non-functional properties of model transformations in the second list of challenges in sec. 2 triple graph transformations show a very promising basis providing already most of the requested properties while the existing results above are preserved. in order to define expressive model transformations, the concept of negative application conditions (nacs) is commonly used and allows the modeler to specify complex model transformations [ehs09]. we are currently working on the extension of model transformations based on tggs to the more general nested applications [hp09], which provide the expressive power of first order logic on graphs. furthermore, as shown in [eee+07], information preserving bidirectional model transformations can be characterized by source consistent forward transformations based on triple graph grammars. moreover, the efficiency of executing source consistent model transformations is improved in [eehp09] by defining an on-the-fly construction, for which termination is ensured if the source rules are creating, i.e. each triple rule creates at least one element in the source component. as a second optimization, suitable conditions for parallel independence were defined in [eehp09] in order to perform partial order reductions. the efficiency is further improved in [hego10] using translation attributes and a sufficient condition for avoiding backtracking completely. finally, model transformations based on triple graph transformations are flexible in the sense that new rules can be added without changing the existing rules whenever new structures are introduced into the visual language. coming back to the first list of challenges in sec. 2 we prove in sec. 5.2 the semantical correctness of the model transformation presented in this paper and we show how this approach can be generalized to other model transformations as well. summing up, triple graph grammars are an adequate and promising basis for model transformations and the existing results show its intuitive, expressive, formally well-founded and efficient character. 5 verification of model transformations 5.1 the borrowed context technique in the following we will describe how to verify model transformations, by treating the case study introduced above. the approach we are using here has been described in more detail in [hkr+10b, hkr+10a] for a different case study. we will here omit the technical details and refer the interested reader to [hkr+10a]. before we can even state what behaviour preservation actually means in our setting, it is necessary to introduce an operational semantics, given by graph transformation rules, for both the source and the target model. this operational semantics will equip source as well as target models with labelled transition systems, where transitions correspond to the application of graph transformation rules and are of the form g1 α⇒ g2. note that α is the transition label, which is obtained from the applied production p via a given map-function, i.e., α = map(p). the proc. gramot 2010 10 / 20 eceasst map-function, assigning a global label to every rule, is necessary since we compare different operational rules. now, behaviour preservation in our setting means that the source model and the corresponding target model are bisimilar (with respect to the labelled transitions). we will use the borrowed context technique [ek06, rke08], which refines a labelled transition system (or even unlabelled reaction rules) in such a way that the resulting bisimilarity is a congruence (see also [lm00]). by a congruence we mean a relation over graphs that is preserved by contextualization, i.e., by gluing with a given environment graph over a specified interface. this is a mild generalization of standard graph rewriting in that we consider “open” graphs, equipped with a suitable interface. note that in this section we will not work directly with triple graph grammars, however in the conclusion we will discuss some preliminary ideas on the verification of model transformation based directly on triple graph grammars. instead here we use in-situ transformation rules, where the in-situ rules are derived from the triple rules of sec. 3, in order to be able to exploit the existing congruence results. the derivation of equivalent in-situ transformation rules has been done manually, it is however quite straightforward in this case. we are not using the usual forward transformation rules since they would be larger and quite unwieldy for our purposes. the basic idea behind the borrowed context technique is to describe the possible interactions of a part of the model with the environment, i.e., with the remaining yet unspecified rest of the model. in addition to existing labels, we add the following information to a transition: what is the (minimal) context that a graph with interface needs to evolve? more concretely we have transitions of the form (j → g) α,(j→f←k) =⇒ (k → h) where the components have the following meaning: (j → g) is the original graph with interface j (given by an injective morphism from j to g) which evolves into a graph h with interface k. the label is composed of two entities: the original label α = map(p) stemming from the operational rule p and furthermore two injective morphisms (j → f ← k) detailing what is borrowed from the environment. the graph f represents the additional graph structure, whereas j, k are the two interfaces (of g and h) which are mapped to f via graph morphisms. we will now introduce the necessary definitions. definition 5 (context, cospan) a graph with interface is a graph morphism j → g. a context (also called cospan) consists of two injective graph morphisms j → f ← k. the composition of two cospans is performed by taking the pushout. k }}{{ {{ { !!c cc cc j // 11 f !!c cc cc po e }}{{ {{ { moo mmd definition 6 (rewriting with borrowed contexts) given a graph with interface j → g and a production p : l ← i → r, we say that j → g reduces to k → h with transition label j → f ← k if there are graphs d, g+, c and additional morphisms such that the diagram below commutes 11 / 20 volume 30 (2010) specification and verification of model transformations and the squares are either pushouts (po) or pullbacks (pb) with injective morphisms. in this case a rewriting step with borrowed context exists and is written as follows: (j → g) map(p),(j→f←k) =⇒ (k → h) (in words: j → g reduces to k → h with transition labels map(p) and j → f ← k). d // �� po l �� po ioo // �� po r �� g // po g+ pb coo // h j oo // f oo koo oo ?? after these preliminaries, we can now define the notion of bisimilation and bisimilarity with borrowed context labels. note that under certain conditions and for closed systems this notion specializes to standard bisimilarity, which ignores the borrowed context label. this will be explained later in more detail. definition 7 (bisimulation, bisimilarity) let p be a set of productions. let r be a symmetric relation consisting of pairs of graphs with interfaces of the form (j → g, j → g′), also written (j → g) r (j → g′). the relation r is a bisimulation if whenever we have (j → g) r (j → g′) and a transition (j → g) α,(j→f←k) =⇒ (k → h) can be derived from p, then there exists a morphism k → h′ and a transition (j → g′) α,(j→f←k) =⇒ (k → h′) such that (k → h) r (k → h′). we write (j → g) ∼ (j → g′) whenever there exists a bisimulation r that relates the two morphisms. the relation ∼ is called bisimilarity. we have shown that (strong) bisimilarity defined in transition systems with borrowed context labels is a congruence. this holds also if we enrich the labels with α = map(p) as described above. this extended congruence result was shown to be correct in [hkr+10a]. theorem 3 (bisimilarity is a congruence [ek06, hkr+10a]) bisimilarity ∼ is a congruence, i.e., it is preserved by embedding into contexts as specified in def. 5. 5.2 using the borrowed context technique for the verification of model transformations for an in-situ model transformation within the same language, applications of the borrowed context technique are quite immediate: show for every transformation rule that the left-hand and right-hand sides l, r with interface i are bisimilar with respect to the operational rules. then the source model must be bisimilar to the target model by the congruence result. this idea has been exploited in [rlk+08] for showing behaviour preservation of refactorings. to set up the entire machinery, we first need the operational semantics of the two languages under consideration (bidilang and unidilang). in fig. 6 and fig. 7 we describe the dynamic evolution of a system: in both cases messages can be created and deleted at arbitary moments in proc. gramot 2010 12 / 20 eceasst ← → ← → ← → ← → figure 6: bidilang, rules of the operational semantics ← → ← → ← → figure 7: unidilang, rules of the operational semantics time. furthermore, in language bidilang the node labelled d describes a directed connection over which messages can be passed in only one direction, whereas the node labelled u describes an undirected connection allowing a movement in any direction (note that the two edges leaving the u -node have the same label and are hence undistinguishable). in the second language (unidilang) we have only one type of connection, working similarly to the directed connection in the first language. now, as announced above, in order to reuse the congruence result we are applying in-situ transformation rules (given in fig. 8) which are similar to the triple graph grammar rules given in sec. 3. ← → ← → ← → figure 8: rules for the in-situ model transformation 13 / 20 volume 30 (2010) specification and verification of model transformations note that these in-situ rules will lead to “mixed” (or hybrid) models which incorporate components of both the source and the target model. hence we need a joint type graph (see fig. 9) that contains node and edge types of both languages. x c u y d m src tgt node figure 9: combined type graph tgst for mixed models furthermore, since we generate mixed models but still want to exploit the congruence result, it is necessary to have an operational semantics also for those models, which has to satisfy the following conditions: (i) the mixed rules are not applicable to a pure source or target model; (ii) it is possible to show bisimilarity of left-hand and right-hand sides of all transformation rules. finally, observe that our final aim is to show bisimilarity of closed graphs, i.e., of graphs with empty interface of the form /0 → g. if the operational rules of the source and target languages have connected left-hand sides then such a graph will either borrow nothing or borrow the whole left-hand side. it can be shown that if all left-hand sides are connected, the notion of bisimilarity induced by borrowed contexts coincides with the standard one. hence here we use the mixed operational semantics given in fig. 10. the rules mainly describe message passing in mixed models, where a message is, for instance, passed from an x -node to a y -node over various types of connectors. we are now ready to give the main result of this section, which states the correctness of the model transformation under consideration. this theorem holds in general whenever the mixed semantics satisfies conditions (i) and (ii) above. theorem 4 the three rules of the in-situ model transformation given in fig. 8 form a bisimulation relation r, where each rule l ← i → r is split into a pair (i → l, i → r) of the relation. since bisimilarity is a congruence and borrowed context bisimilarity coincides with standard bisimilarity on source and target models, this implies that whenever a graph gb of the source language is transformed into a graph gu of the target language via the model transformation, then gb is bisimilar to gu . note that in the proof we make heavy use of the up-to-context technique, which allows us to somewhat relax the requirements for bisimulation proofs given in def. 7. more specifically, it is enough if k → h and k → h′ are in relation r after the removal of identical contexts. note also that in more complex scenarios the bisimulation r might contain additional pairs that are not model transformation rules (see [hkr+10a]). in this fairly easy scenario one can obtain the rules of the mixed semantics by applying the transformation rules to the (original) operational semantics of the source or target languages. in the general case, it is however currently not clear to us, how to obtain a correct set of mixed proc. gramot 2010 14 / 20 eceasst ← → ← → ← → ← → ← → ← → ← → ← → ← → figure 10: additional rules of the mixed semantics semantic rules. for small examples, the following heuristics usually gives good results: 1. let s be the set containing all original rules of the the source and target operational semantics. 2. choose any tranformation rule r. 3. apply all rules in s to the left-hand side (respectively right-hand side) of r using the borrowed context technique. this gives us several borrowed context rewriting steps. 4. if there is a matching answer with a rule in s for the right-hand side (respectively left-hand side) of transformation rule r, then do nothing. 5. if there is no such matching answer, create a new “mixed” rule, providing such a valid answer. add this new rule to s and proceed with step 2. 6. if every partial map of every rule in s has been tested on all left-hand and right-hand sides of the transformation rules, s is the mixed semantics we are looking for. using this heuristics one might even create a smaller set of rules for the mixed semantics than by applying the transformation rules to the rules for the operational semantics in every possible way (see [hkr+10a]). 6 related work there are several other approaches based on triple graph transformation, e.g. using constraintpatterns [ogle09]. while these patterns can lead to a more compact specification, there are 15 / 20 volume 30 (2010) specification and verification of model transformations fewer results for several of the listed challenges, e.g. the handling of termination and therefore completeness is more complex and not ensured in general. as mentioned before, there are already suitable techniques for the analysis of functional behaviour of model transformations based on plain graph transformation systems [eel+05]. however, plain graph transformation systems do not show some of the important benefits of triple graph transformation, as, for instance, completeness and the general notion of syntactical correctness with respect to the triple patterns specified by the intuitive triple rules. furthermore, plain graph transformation systems are unidirectional while triple graph transformation systems automatically provide bidirectional model transformations. the work closest to ours for showing the semantical correctness of model transformations in the sense of showing behaviour preservation for a transformation between models of different types is [ggl+06]. they present a mechanised proof of semantics preservation for a transformation of automata to plc-code, based on tgg rules. this proof faced some problems since it was not trivial to present graph transformation within isabelle/hol. as opposed to model transformation between different source and target models, there has been more work on showing behaviour preservation in refactoring. the methods presented in [kckb05, pc07, nk06, gsmd03] address behaviour preservation in model refactoring, but are in general limited to checking a certain number of models. the employment of a congruence result is also proposed in [bhe08] which uses the process algebra csp as a semantic domain. in [beh07] it is shown how to exploit confluence results for graph transformation systems in order to show correctness of refactorings. a number of approaches to showing correctness of refactorings also focus on preserving specific aspects instead of the full semantics (see [mt04]). 7 conclusion in order to provide validated model transformations, which are a major component in model driven architecture (mda), there is a strong need for formal analysis and verification. we have shown that triple graph transformation is an adequate technique providing both, an intuitive way of specification and a formal basis for which several analysis techniques as well promising execution algorithms are available. the two lists of challenges for model transformations in sec. 2 contain many different and important aspects and, depending on the concrete model transformation, there may be some of them that cannot be achieved. even though, the presented approach in sec. 3 based on triple graph transformation shows many capabilities and many of the listed challenges can be achieved or handled adequately, respectively. the available results discussed in sec. 4 include for instance syntactical correctness and completeness and the specification of model transformations is performed in an intuitive and elegant way. while the general analysis of functional behaviour of a model transformation will be a part of future work we have exemplarily shown how the specified model transformation can be analyzed with respect to behaviour preservation and therefore, with respect to semantical correctness. for this purpose we transformed in sec. 5 the model transformation based on a triple graph grammar into an in-situ model transformation based on plain graph grammars. in a next step we introduced a proof technique for showing that a transformation preserves the behaviour of a proc. gramot 2010 16 / 20 eceasst model. a similar method was introduced by us in [hkr+10b, hkr+10a] for a different model transformation. in [hkr+10b, hkr+10a] it was even necessary to work with weak, saturated bisimilarity with negative application conditions due to the higher complexity of the case study. however, the general idea can just as well be presented and understood with the simpler case study presented in this paper. currently we have not yet mechanized the technique, but we have started to work on an implementation. one drawback is the fact that it is necessary to find a suitable mixed semantics, which might become quite large and unwieldy. hence we are currently working on a more straightforward approach that combines triple graph grammars with borrowed contexts, by asking that each borrowed context step of the source model must be answered by a borrowed context step of the target model (and vice versa) in such a way that the labels can be translated into each other via the model transformation rules. however there are some remaining technical difficulties (e.g., what happens if the label can only be partially translated?) yet to be solved. for both approaches it is not yet clear to which extent they will scale. we believe that additional proof techniques will be necessary to treat more realistic examples. note however that the in-situ transformation rules are not without merits: in the case of system migration, where we migrate piece by piece of an evolving system from one version to another, we might well have such mixed intermediate states which have to be handled. think of a heterogeneous lan, where one wants to replace the mail server, the firewall and the file server. the complete system must be in working order all the time, but in many cases the exchange of the components will not happen synchronously. in such a setting we want to show that also the hybrid models preserve the behaviour and the migration does not disrupt the correct working of the system. acknowledgements: we would like to thank arend rensink, maria semenyak, christian soltenborn and heike wehrheim for joint work on a case study, which gave us the ideas on which we based sec. 5. bibliography [agg09] tfs-group, tu berlin. agg. 2009. http://tfs.cs.tu-berlin.de/agg. [beh07] l. baresi, k. ehrig, r. heckel. verification of model transformations: a case study with bpel. in proc. of tgc ’07 (trustworthy global computing). pp. 183– 199. springer, 2007. lncs 4661. [bhe08] d. bisztray, r. heckel, h. ehrig. verification of architectural refactorings by rule extraction. in fase ’08. lncs 4961, pp. 347–361. springer, 2008. [eee+07] h. ehrig, k. ehrig, c. ermel, f. hermann, g. taentzer. information preserving bidirectional model transformations. in dwyer and lopes (eds.), fundamental approaches to software engineering. lncs 4422, pp. 72–86. springer, 2007. http://tfs.cs.tu-berlin.de/publikationen/papers07/eee+07.pdf 17 / 20 volume 30 (2010) http://tfs.cs.tu-berlin.de/agg http://tfs.cs.tu-berlin.de/publikationen/papers07/eee+07.pdf specification and verification of model transformations [eehp09] h. ehrig, c. ermel, f. hermann, u. prange. on-the-fly construction, correctness and completeness of model transformationsbased on triple graph grammars: long version. in schürr and selic (eds.), acm/ieee 12th international conference on model driven engineering languages and systems (models’09). lncs 5795, pp. 241–255. springer, 2009. to appear. http://tfs.cs.tu-berlin.de/publikationen/papers09/eehp09.pdf [eel+05] h. ehrig, k. ehrig, j. de lara, g. taentzer, d. varró, s. varró-gyapay. termination criteria for model transformation. in wermelinger and margaria-steffen (eds.), proc. fundamental approaches to software engineering (fase). lecture notes in computer science 2984, pp. 214–228. springer verlag, 2005. http://tfs.cs.tu-berlin.de/publikationen/papers05/eel+05.pdf [eept06] h. ehrig, k. ehrig, u. prange, g. taentzer. fundamentals of algebraic graph transformation. eatcs monographs in theor. comp. science. springer verlag, 2006. http://www.springer.com/3-540-31187-4 [ehs09] h. ehrig, f. hermann, c. sartorius. completeness and correctness of model transformations based on triple graph grammars with negative application conditions. eceasst 18, 2009. http://eceasst.cs.tu-berlin.de/index.php/eceasst/issue/view/27 [ek06] h. ehrig, b. könig. deriving bisimulation congruences in the dpo approach to graph rewriting with borrowed contexts. mathematical structures in computer science 16(6):1133–1163, 2006. [ggl+06] h. giese, s. glesner, j. leitner, w. schäfer, r. wagner. towards verified model transformations. in 3rd international workshop on model development, validation and verification (modeva). pp. 78–93. le commissariat á l’energie atomique cea, genova, italy, 2006. [gsmd03] p. v. gorp, h. stenten, t. mens, s. demeyer. towards automating source-consistent uml refactorings. in uml 2003. lncs 2863, pp. 144–158. springer, 2003. [hego10] f. hermann, h. ehrig, u. golas, f. orejas. efficient analysis and execution of correct and complete model transformations based on triple graph grammars. technical report, tu berlin, fak. iv, 2010. to appear, available online: http://tfs. cs.tu-berlin.de/publikationen/papers10/hego10b.pdf. [heog10] f. hermann, h. ehrig, f. orejas, u. golas. formal analysis of functional behaviour of model transformations based on triple graph grammars. in proc. int. conf. on graph transformation. 2010. accepted, online available at http: //tfs.cs.tu-berlin.de/publikationen/papers10/heog10.pdf). [hkr+10a] m. hülsbusch, b. könig, a. rensink, m. semenyak, c. soltenborn, h. wehrheim. full semantics preservation in model transformation – a comparison of proof proc. gramot 2010 18 / 20 http://tfs.cs.tu-berlin.de/publikationen/papers09/eehp09.pdf http://tfs.cs.tu-berlin.de/publikationen/papers05/eel+05.pdf http://www.springer.com/3-540-31187-4 http://eceasst.cs.tu-berlin.de/index.php/eceasst/issue/view/27 http://tfs.cs.tu-berlin.de/publikationen/papers10/hego10b.pdf http://tfs.cs.tu-berlin.de/publikationen/papers10/hego10b.pdf http://tfs.cs.tu-berlin.de/publikationen/papers10/heog10.pdf http://tfs.cs.tu-berlin.de/publikationen/papers10/heog10.pdf eceasst techniques. technical report tr-ctit-10-09, centre for telematics and information technology, university of twente, 2010. [hkr+10b] m. hülsbusch, b. könig, a. rensink, m. semenyak, c. soltenborn, h. wehrheim. showing full semantics preservation in model transformation – a comparison of techniques. in proc. of ifm ’10 (integrated formal methods). springer, 2010. lncs, to appear. [hp09] a. habel, k.-h. pennemann. correctness of high-level transformation systems relative to nested conditions. mathematical structures in computer science 19(2):245–296, 2009. [kckb05] m. van kempen, m. chaudron, d. kourie, a. boake. towards proving preservation of behaviour of refactoring of uml models. in saicsit ’05. pp. 252–259. 2005. [kw07] e. kindler, r. wagner. triple graph grammars: concepts, extensions, implementations, and application scenarios. technical report tr-ri-07-284, universität paderborn, 2007. [lm00] j. j. leifer, r. milner. deriving bisimulation congruences for reactive systems. in proc. of concur 2000. pp. 243–258. springer, 2000. lncs 1877. [mt04] t. mens, t. tourwé. a survey of software refactoring. ieee trans. software eng. 30(2):126–139, 2004. [nk06] a. narayanan, g. karsai. towards verifying model transformations. in gtvmt ’06. entcs 211, pp. 185–194. 2006. [ogle09] f. orejas, e. guerra, j. de lara, h. ehrig. correctness, completeness and termination of pattern-based model-to-model transformation. in kurz et al. (eds.), proc. of the 3rd int. conf. on algebra and coalgebra in computer science (calco’09). lecture notes in computer science 5728, pp. 383–397. springer, 2009. [pc07] j. pérez, y. crespo. exploring a method to detect behaviour-preserving evolution using graph transformation. in third international ercim workshop on software evolution. pp. 114–122. 2007. [rke08] g. rangel, b. könig, h. ehrig. deriving bisimulation congruences in the presence of negative application conditions. in amadio (ed.), proc. foundations of software science and computational structures (fossacs’08). lecture notes in computer science 4962, pp. 413–427. springer verlag, 2008. doi:10.1007/978-3-540-78499-9 http://www.springerlink.com/content/e950520638346408/ [rlk+08] g. rangel, l. lambers, b. könig, h. ehrig, p. baldan. behavior preservation in model refactoring using dpo transformations with borrowed contexts. in proc. international conference on graph transformation (icgt’08). lecture notes in computer science 5214. springer verlag, heidelberg, 2008. 19 / 20 volume 30 (2010) http://dx.doi.org/10.1007/978-3-540-78499-9 http://www.springerlink.com/content/e950520638346408/ specification and verification of model transformations [sch94] a. schürr. specification of graph translators with triple graph grammars. in tinhofer (ed.), wg94 20th int. workshop on graph-theoretic concepts in computer science. lecture notes in computer science 903, pp. 151–163. springer verlag, heidelberg, 1994. [sk08] a. schürr, f. klar. 15 years of triple graph grammars. in proc. int. conf. on graph transformation (icgt 2008). pp. 411–425. 2008. doi:10.1007/978-3-540-87405-8 28 proc. gramot 2010 20 / 20 http://dx.doi.org/10.1007/978-3-540-87405-8_28 introduction challenges for model transformations specification of model transformations by triple graph grammars results for model transformations based on triple graph grammars verification of model transformations the borrowed context technique using the borrowed context technique for the verification of model transformations related work conclusion reversing graph transformations electronic communications of the easst volume 2 (2006) proceedings of the workshop on petri nets and graph transformation (pngt 2006) reversing graph transformations1 paweł sobociński 7 pages guest editors: paolo baldan, hartmut ehrig, julia padberg, grzegorz rozenberg managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst reversing graph transformations2 paweł sobociński ecs, university of southampton, united kingdom abstract: in recent work with vincent danos and jean krivine the author introduced a general framework for backtracking in concurrent formalisms, thus allowing modelling of situations where deadlock can arise without the necessity of explicitly encoding the often involved backtracking mechanisms. here we shall discuss how the framework can be applied to the well-known formalism of double-pushout graph transformation. keywords: graph transformation, reversibility, transaction we present an application of the framework developed in [5] to the theory of graph transformation systems. here we say “graph” to mean an object of an arbitrary category with pushouts along monomorphisms where the local church-rosser theorem holds. an example is an adhesive category [10]. of course, the category graph of ordinary graphs is adhesive and in this setting it suffices to require that the interface embeds in both the left and the right hand sides of each production. in order to establish the basic concepts we shall consider a concrete example, working in the category c of directed graphs whose vertices are tagged with the elements of a set; the presheaf topos c = set·→·⇔·. the edges of such graphs will represent physical proximity of entities represented by the vertices. the elements with which vertices may be tagged represent the internal state of the entities. let t be the graph illustrated in fig 1. the graph has two vertices (“philosopher” and “table”) and one edge. the tags are “fork”, “eating”, “thinking” and “fork”. then c/t is the adhesive category [10] of graphs typed over t , in the usual way. one can thus think of the objects in c/t as graphs consisting of two types of vertices, the philosopher vertices and the table vertices. the philosopher vertices, which may be tagged with a set of “fork”, “eating” or “thinking” tags, may be the source of an arbitrary set of edges with targets the table vertices, which themselves may be tagged with a set of “fork” tags. our main example is a graph transformation system over the category c/t and models hoare’s dining philosophers problem [9]. let p be the dpo grammar over c/t with the start graph s as illustrated in fig 2 and the three productions q1, q2 and q3 illustrated in fig 3. note that we only illustrate the left and the right hand sides of the productions, their interface is the obvious one in each case. each thinking philosopher may claim a fork next to her using the production q1. once a thinking philosopher has two forks in her possession, she may start eating via the production q2. finally, an eating philosopher can release her forks at any time and return to thinking using production q3. the dining philosophers problem is famous not least for the fact that it succinctly illustrates the fundamental issue of deadlock in parallel programming. if each of the philosophers picks up the fork to her left then no further productions are possible and the philosophers starve to death. to solve this problem, one could partition the set of productions into reversible and irreversible productions; the idea being that the reversible productions may lead to deadlock and thus should 1 / 7 volume 2 (2006) reversing graph transformations3 fork eating thinking philosopher fork table figure 1: type graph t . thinking philosopher fork table thinking philosopher thinking philosopher thinking philosopher fork table fork table fork table fork table thinking philosopher figure 2: start graph s. be allowed to be (correctly) backtracked. on the other hand, the irreversible productions occur only in the presence of a desired global state possibly reached via the application of a number of the reversible productions. in our particular example one could specify the set of reversible productions r = {q1} and the set of irreversible productions i = {q2, q3}. one may now view of the behaviour of each philosopher as a series of transactions – causal sequences of reversible actions followed by a single irreversible action. each philosopher can perform two possible transactions, the first being two instances of q1 followed by q2 (claiming two forks and starting to eat) and the second being a single instance of q3 (relinquishing the forks and starting to think). in order to avoid deadlock, one specifies that each of the initial actions can be reversed. the correctness of the backtracking means roughly that the behaviour of the resulting system should be precisely the behaviour of the transactions of the original system “up to” reversible moves. the naive solution of simply adding a reversed production q1?, illustrated in fig 4 is unsatisfactory. indeed, a philosopher can now begin by picking up her left fork with q1 and placing it via q1? together with her right fork. this sequence of actions results in states not reachable from the start state by performing the transactions of the original system consider for instance the state illustrated in fig 5. thus although the addition of q1? solves the problem of deadlock, it is proc. pngt 2006 2 / 7 eceasst thinking philosopher fork table thinking fork philosopher table eating philosopher thinking philosopher fork table fork table thinking fork fork philosopher eating philosopher table table ! q1 ! q2 ! q3 figure 3: productions q1, q2 and q3 of p. clearly incorrect. there are several ways to fix the naive solution: for example, one can label the edges out of each philosopher with l and r, replace the rule q1 with two rules q1l , q1r and add their inverses q1l ?, q1r?, thus disallowing the aforementioned errant behaviour. there are two apparent problems with such an ad-hoc solution: firstly, one has to prove that the transactions are indeed modelled correctly (trivial in this case, but not always so); secondly, there is a danger of making the model too complex to be of use. there is a general solution, described and shown to be correct in [5]. it arose by generalising previous work on reversing the process calculus ccs by danos and krivine [3, 4]. it is general in the sense that it applies also to other models for concurrency such as petri nets and process calculi. we briefly outline this solution below, instantiated with the example of graph transformation systems. given a grammar g , let the category of computations cp g be the category with objects those of c (the ambient category of g ) and arrows finite (possibly empty) paths of direct derivations modulo switch-equivalence. the arrows of cp g are thus the concurrent computations of g .4 such categories are natural and have been studied for other models, notably for petri nets [11]. they have also been considered in the setting of graph transformation, see [8, ch 4] for an indepth presentation and a proof that this category also arises as a free construction. in the problem specification, the set of productions p of g is partitioned into sets of reversible 4 note that the description given here is quite concrete since the states are not quotiented by isomorphism – in particular, thinking of the category as a transition system results in infinite branching for trivial reasons since if a state q can do a transition to state q′ then it can do the same transition to any state isomorphic to q′. ways of cutting down the state space by considering only isomorphism classes of states have been considered in the graph transformation literature, see [2] and references therein. 3 / 7 volume 2 (2006) reversing graph transformations5 q1! !thinkingfork philosopher table thinking philosopher fork table figure 4: reversed rule q1?. thinking philosopher table thinking philosopher thinking philosopher thinking philosopher table table fork fork table fork fork fork table thinking philosopher figure 5: a state reachable from the start state after adding {q1}? to the set of productions. productions r and irreversible productions i. recall that in our running example, r = {q1} and i = {q2, q3}. let r be the subcategory of cp(g ) with arrows the derivations consisting of only the reversible productions. let i be the subcategory of cp(g ) consisting of the irreversible computations – roughly, those where the last action in each thread is irreversible. the arrows of i can be considered as paths (of possibly zero length) of transactions modulo concurrency. the category i can actually be defined in a more abstract way using a particular closure construction from the theory of prefactorisation systems of freyd and kelly [6], see [5] for details. it is not difficult to verify that 〈i , r〉 is actually a factorisation system on cp(g ) – each computation can be factorised into a (possibly empty) irreversible component followed by a (possibly empty) reversible component, moreover, such factorisation is essentially unique. notice that to able to factorise computations in such a way is to be able to ascertain exactly which part of a computation history is reversible – it is exactly the reversible component in the irreversible-reversible factorisation. the presence of such a factorisation system is thus closely related to the idea of backtracking and forms an integral part of the general construction. the first step of the construction is the construction of the so-called category of histories. the idea is to obtain a new category of computations h(cp g , r) with the objects being the reversible proc. pngt 2006 4 / 7 eceasst p1 g1 �� f // p2 g2 �� q1 h // q2 figure 6: an arrow in h(cp g , r). p1 f // g1 �� p2 g2 �� q1 h? // q2 figure 7: an arrow in h?(cp g , r). computations (the arrows in r) of the original category cp g . in a graph transformation system this would mean that a state is no longer a particular graph but rather a concurrent computation made up of applications of reversible productions. the computations of the new system also deserve an explanation. the natural choice is that a computation starting from a state (reversible computation) g1 : p1 → q1 is any computation h : q1 → q2, ie h is an arbitrary arrow of cp g . the only question remaining is what is the final state of this computation. the natural choice is to take this to be g2 : p2 → q2 where g2 ◦ f is the 〈i , r〉 factorisation of h◦g1. roughly, the intuition is that g2 consists of the parts of g1 which are causally visible after performing h (ie they were not in the causal history of an application of an irreversible production in h) together with any causally visible reversible components of h. more formally, the objects of h(cp g , r) are arrows in r, while the arrows are commutative diagrams, as illustrated in fig 6, where h is in cp g and f is in i . given a reversible computation g : p1 → q1 (an object of the history category), clearly any computation h : q1 → q2 leads to a (unique up to isomorphism) object g2 : p2 → q2 of h(cp g , r) and irreversible computation f resulting in a map g1 → g2 – here g2 ◦ f is simply the 〈i , r〉-factorisation. the category h(cp g , r) is related to i via an adjunction, see [5] for details. it turns out that all that is missing is the ability to actually “undo” the reversible computations represented by the objects of h(cp g , r). in order to do this, we shall need the notion of a category of fractions [7]. given a set of morphisms r of a category c, the category of fractions c[r−1] is the category resulting from c by “freely” adding inverses to the arrows of r. we obtain a canonical functor φ : c → c[r−1] which sends each arrow in r to an isomorphism. let h?(cp g , r) be the category of reversible histories. it has the same objects as h(cp g , r) but arrows are formal diagrams, as illustrated in fig 7, where h? is in cp g [r−1] and h?φ(g1) = φ(g2 f ). roughly speaking, this category is as h(cp g , r) but histories can be backtracked [5]. note that while we constructed the history categories for our particular category cp g , in fact the constructions rely only on the presence of a factorisation system. interestingly, while the 5 / 7 volume 2 (2006) reversing graph transformations6 description of h?(cp c, r) given here may appear ad-hoc, the result is actually equivalent to the category of fractions obtained by reversing those computations of h(cp c, r) which have a reversible lower component. the main result of [5] states that there is an equivalence of categories h?(cp g , c) ' i . this implies, as we shall explain in more detail, that to correctly capture the transactions for a graph grammar g , one can replace the category of computations cp g with h?(cp g , r). the equivalence of categories result can be seen as a proof of correctness of the “implementation” h?(cp g , c) with respect to the “specification” i . the proof in [5] proceeds to show that the evident functor m? : h?(cp g , c) → i which takes a diagram as in fig 7 to its upper component is an equivalence of categories, thus full, faithful and essentially surjective on objects. the fact that m? is a functor can be understood roughly in process-algebra terminology as a simulation of h?(cp g , c) in i . the fact that the functor is full means that, roughly, the simulation is also a functional bisimulation. in order to concretely implement the solution described in the previous paragraph it is helpful to have a convenient way of representing an arbitrary concurrent computation in g . one possibility is to take some notion of process, for instance as presented in [1]. assuming such a “syntax”, one: (i) replaces the states of a computation; instead of a graph q, a state is a reversible computation g : p → q represented by an appropriate “syntactic” expression; (ii) the original productions of g are allowed to be applied in the usual way, in a way which corresponds to the arrows of h(cp c, r). thus an application of a reversible production simply results in a “larger” state since there is now one more production which may be reversed. on the other hand an application of an irreversible production possibly results in a “smaller” state since it may causally depend on a certain part of the start state – that part of the state then needs to be removed in order to obtain the end state; (iii) add an inverse production q? for each reversible production q ∈ r, such reversed productions are then allowed to be applied precisely when their inverse appears as a final production (in terms of causality) in the state – in other words q? can be applied at state g precisely when there exists a reversible computation g′ such that g = q◦g′. applying the inverse then removes that application of q from the state. the resulting computations are “weakly” (modulo reversible moves) equivalent to the transactions of the original grammar. bibliography [1] p. baldan, a. corradini, t. heindel, b. könig, and p. sobociński. processes for adhesive rewriting systems. in proceedings of fossacs ’06, volume 3921 of lncs, pages 202–216. springer, 2006. [2] a. corradini, h. ehrig, r. heckel, m. lowe, u. montanari, and f. rossi. algebraic approaches to graph transformation part i: basic concepts and double pushout approach. in proc. pngt 2006 6 / 7 eceasst handbook of graph grammars and computing by graph transformation, volume 1, pages 162–245, world scientific, 1997. [3] v. danos and j. krivine. reversible communicating systems. in proceedings of concur’04, volume 3170 of lncs, pages 292–307. springer, 2004. [4] v. danos and j. krivine. transactions in rccs. in proceedings of concur’05, volume 3653 of lncs, pages 398–412. springer, 2005. [5] v. danos, j. krivine, and p. sobociński. general reversibility. in express ’06, electronic notes in theoretical computer science. elsevier, 2006. to appear. [6] p. j. freyd and g. m. kelly. categories of continuous functors, i. journal of pure and applied algebra, 2:169–191, 1972. [7] p. gabriel and m. zisman. calculus of fractions and homotopy theory. springer-verlag, 1967. [8] r. heckel. open graph transformation systems: a new approach to compositional modelling of concurrent and reactive systems. phd thesis, tu berlin, 1998. [9] c. a. r. hoare. towards a theory of parallel programming. in seminar at queen’s university, belfast, northern irelend. academic press, 1972. [10] s. lack and p. sobociński. adhesive and quasiadhesive categories. theoretical informatics and applications, 39(3):511–546, 2005. [11] j. meseguer and u. montanari. petri nets are monoids. information and computation, 88:105–155, 1990. 7 / 7 volume 2 (2006) functorial analysis of algebraic higher-order net systems with applications to mobile ad-hoc networksthis work has been partly funded by the research project eserved@d = *@let@token 2551formanet (see ` `%%%`#`&12_`__~~~) of the german research council. electronic communications of the easst volume 40 (2011) proceedings of the 4th international workshop on petri nets and graph transformation (pngt 2010) functorial analysis of algebraic higher-order net systems with applications to mobile ad-hoc networks ulrike golas, kathrin hoffmann, hartmut ehrig, alexander rein and julia padberg 20 pages guest editors: claudia ermel, kathrin hoffmann managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst functorial analysis of algebraic higher-order net systems with applications to mobile ad-hoc networks∗ ulrike golas1, kathrin hoffmann23, hartmut ehrig2, alexander rein2 and julia padberg3 1 golas@zib.de konrad-zuse-zentrum für informationstechnik berlin, germany 2 hoffmann|ehrig|alex@cs.tu-berlin.de technische universität berlin, germany 3 padberg@informatik.haw-hamburg.de hochschule für angewandte wissenschaften hamburg, germany abstract: algebraic higher-order (aho) net systems are petri nets with place/ transition systems, i.e. place/transition nets with initial markings, and rules as tokens. in several applications, however, there is the need for explicit data modeling. the main idea of this paper is to introduce aho net systems with high-level net systems and corresponding rules as tokens. we relate them to aho net systems with low-level net systems as tokens and analyze the firing and transformation properties of the corresponding net class transformation defined as functors between the corresponding categories of aho net systems. all concepts and results are explained with an example in the application area of mobile ad-hoc networks. from an abstract point of view, mobile ad-hoc networks consist of mobile nodes which communicate with each other independent of a stable infrastructure, while the topology of the network constantly changes depending on the current position of the nodes and their availability. to ensure satisfactory team cooperation in workflows of mobile ad-hoc networks we use the modeling technique of aho net systems. keywords: algebraic higher-order nets, mobile ad-hoc networks, skeleton functor 1 introduction and related work place/transition (p/t) systems and their variants are an established process definition language for the representation, validation and verification of workflow procedures (see, e. g., [vda03] for an overview), where p/t nets represent process schemes and p/t systems describe the behavior of process instances due to their initial markings. the paradigm of nets as tokens has been introduced by valk [val98] where so-called object nets are token within another net, called a system net. in elementary object systems, object nets can move through a system net and interact ∗ this work has been partly funded by the research project for ma`net (see http://tfs.cs.tu-berlin.de/formalnet/) of the german research council. 1 / 20 volume 40 (2011) mailto:golas@zib.de mailto:hoffmann$|$ehrig$|$alex@cs.tu-berlin.de mailto:padberg@informatik.haw-hamburg.de http://tfs.cs.tu-berlin.de/formalnet/ functorial analysis of algebraic higher-order net systems with both the system net and other object nets. this allows to change the marking of the object nets, but not their net structure. in [hme05, ehp+07], the concept of reconfigurable place/transition net systems has been introduced which is most important to model changes of the net structure while the system is kept running. in detail, a reconfigurable p/t net system consists of a p/t net with marking and a set of rules. in these nets, not only the follower marking can be computed but also the structure can be changed by rule application to obtain a new p/t net system that is more appropriate with respect to some requirements of the environment. for rule-based transformations of p/t net systems we use the framework of net transformations [eept06] following the double-pushout (dpo) approach of graph transformation systems and the notation of petri nets as monoids [mm90]. the basic idea behind net transformations is the stepwise development of p/t net systems by given rules. one may think of these rules as replacement systems where the left-hand side is replaced by the right-hand side while preserving a context. in low-level petri nets, the tokens are indistinguishable. the integration of petri nets with data type descriptions has led to high-level nets as powerful specification techniques like algebraic high-level (ahl) nets [per95], which can also be transformed within the dpo approach [pra08]. in [hme05], we have introduced the paradigm nets and rules as tokens by a high-level model with a suitable data type part. the model called algebraic higher-order (aho) net system exploits some form of control not only on the rule application but also on token firing. an aho net system is defined by an ahl net system with net places and rule places, where the marking is given by suitable low-level net systems or rules, respectively, on these places. as shown in [brhm06], this paradigm has been very useful to model applications in the area of mobile ad-hoc networks. mobile ad-hoc networks (manets) consist of mobile nodes forwarding data to other nodes based on the network connectivity independent from a stable infrastructure. the constant change of the network’s topology depends on the current position of the nodes and their availability. a typical example of a complex application is a team communicating using hand-held devices and laptops as in emergency scenarios [phe+07]. in such a scenario, each team member performs specific activities while different teams collaborate through the interleaving of all the different workflows. normally, workflows in mobile environments are not fixed once and for all at design time but are constantly adapted at run time predicting disconnections or reorganizing activities. this requires on the one hand a suitable description of the distributed workflows and on the other hand expressive techniques for the adaption. research on manets [az03] has focused mainly on the infrastructure at the lower levels of the iso/osi-standards. to apply manets in larger operations it is necessary to abstract from the network layer. in [rmpm03], an interface for network services that can be used by applications abstracting from the underlying protocols is suggested. in contrast to approaches using models mainly for the network we propose modeling the application in terms of workflows, such that the adaption of workflows to accommodate the requirements in an ad-hoc setting are met. our experience with the case study in [peh07] has clearly shown the need to integrate data on the level of workflows. the main idea of this paper is to introduce aho net systems with highlevel net systems and corresponding rules as tokens. we relate them to aho net systems with low-level net systems and rules as tokens, and analyze the firing and transformation properties of the corresponding net class transformation defined as functor between corresponding categories proc. pngt 2010 2 / 20 eceasst of aho net systems. this functor is based on the corresponding functor from high-level to lowlevel nets [urb03]. all concepts and results are explained with an example in the area of mobile ad-hoc networks. in contrast to [peh07], where we have used merely low-level net systems, we present now a pipeline emergency scenario where we use data dependent workflows. this paper is organized as follows: in section 2, we introduce as motivating example a pipeline emergency scenario using data dependent workflows. in section 3, we define aho net systems with ahl net systems and rules as tokens as well as their firing behavior and transformations. in section 4, we present the skeleton functor transforming aho net systems with high-level tokens to such with low-level tokens and show that enabling and firing is preserved. finally, in section 5, we give a conclusion and an outlook to future work. 2 motivation: emergency scenario in emergency scenarios, we can obtain an effective coordination among team members constituting a mobile ad-hoc network through the use of net system and rule tokens. in this way, y less 5 = tt notify residents of the evacuation persons assist handicapped the extent possible guide persons to the immediate area evacuate homes in p:tok p’’’:tok l x x p:tok p’’’:tok p’’:tok p’:tok r x x x x x x p:tok p’’’:tok k rl request to control traffic into the area identify the location gas is highest additional reading the gas indicator shut off electricity and gas lines gas company call the reading the gas indicator expand the area of evacuation deny entry stand by p10:nat evacuate homes in the immediate area y y p1:tok p3:tok p4:tok p6:tok p9:tok p12:tok p14:tok p15:tok p13:tok p2:tok p5:tok p7:tok x x x x x x x x x x x x x x x x x x x y x x x p11:tok x x x y geq 5 = tt result >= 5% lel result < 5% lel x x p8:tok x n m : mor cod(m) = n applicable(rl, m) = tt n tσ : trans token firing transform(rl, m) net transformation rl rules : rules (ahon sig, x ), ahl enabled(n,tσ ) =tt net : net fire(n,tσ ) ahlnetsys ahlrule figure 1: algebraic higher-order net system for emergency scenario 3 / 20 volume 40 (2011) functorial analysis of algebraic higher-order net systems cooperative work can be adequately modeled by high-level petri nets with initial markings. the net structure can be adapted to new requirements of the environment during run time by a set of rules, i.e. token firing and net transformation can be interleaved with each other. in contrast to [peh07], where we have used merely low-level net systems, we present a pipeline emergency scenario based on data dependent workflows. this means that we use ahl net systems and corresponding rules as tokens. in this section, we introduce our emergency scenario and illustrate the main idea of algebraic higher-order (aho) net systems using high-level net system and rule tokens, while the detailed definitions can be found in section 3. according to the pipeline emergency scenario1, a natural gas leak of unknown source is detected in a residential area. at the scene, the company officer calls the gas company and requests an additional law enforcement officer to control traffic into the area. upon the arrival of the gas company, the firefighters evacuate the homes in the immediate area, subsequently deny entry to this area and finally stand by with fully charged hose lines. in fact, the firefighter company as well as the gas company collaborate through the exchange of messages to achieve the common goal. y less 5 = tt request to control traffic into the area identify the location gas is highest additional reading the gas indicator shut off electricity and gas lines gas company call the reading the gas indicator expand the area of evacuation deny entry stand by p10:nat evacuate homes in the immediate area y y p1:tok p3:tok p8:tok p4:tok p6:tok p9:tok p12:tok p14:tok p15:tok p13:tok p2:tok p5:tok p7:tok x x x x x x x x x x x x x x x x x x x y x x x p11:tok x x x x x x result < 5% lel result >= 5% lel y geq 5 = tt figure 2: ahlnetsys′ in figure 1, the cooperative workflow enacted by the firefighter company is depicted in the algebraic high-level (ahl) net system ahlnetsys = (ahlnet, m) with ahl net ahlnet and marking m as token on the place net. such an ahl net system token is called object net system. this object net system is coordinated by an aho net system at the system level consisting of the places and transitions in the upper row of figure 1 and the data type part (ahon sig, x , ahl) (see section 3). the aho net system consists of two places net holding ahl net systems and rules holding transformation rules. it allows on the one hand to trigger firing steps and on the other hand to apply rule based transformation steps for the object net system firing the transitions token firing and net transformation as indicated by the net inscriptions fire(n,tσ ) and transform(rl, m), respectively. the execution of the workflow is controlled by firing the transitions on the system level. to start the activities of the firefighter team the transition call the gas company is fired at the object level using the transition token firing at the system level. the result 1 pipeline emergencies home page http://pipeline.mindgrabmedia.com proc. pngt 2010 4 / 20 http://pipeline.mindgrabmedia.com eceasst is the new ahl net system ahlnetsys′ = (ahlnet, m′) shown in figure 2. next we focus on the dynamic changes of the workflow at run time. the firefighters responsible for the evacuation process need more detailed information how to proceed. to introduce the refinement of the evacuate homes-transition into the ahl net system ahlnetsys′ we provide the rule ahlrule in figure 1. y less 5 = tt request to control traffic into the area identify the location gas is highest additional reading the gas indicator shut off electricity and gas lines reading the gas indicator expand the area of evacuation p2:tok gas company call the notify residents of the evacuation persons assist handicapped the extent possible guide persons to deny entry stand by p10:nat y y p3:tok p8:tok p4:tok p6:tok p9:tok p12:tok p14:tok p15:tok p13:tok p5:tok p7:tok x x x x x x x x x x x x x x x y x x x p11:tok x x x x x p1:tok x xx p’’:tok p’:tok x x x x x x result >= 5% lel y geq 5 = tt result < 5% lel figure 3: ahlnetsys′′ the rule ahlrule = (l l← k r→ r) consists of the three ahl net systems l, k, and r, called left-hand side, interface, and right-hand side, respectively. the marking of the ahl net system l demands that the evacuation process is not yet started because there is one token in the pre domain of the evacuate homes-transition. to apply the rule ahlrule to the object net ahlnetsys, the transition net transformation is fired at the system level. the application of the rule refining the evacuate homes-transition is achieved as follows: first, the match morphism m identifies the relevant parts of the left hand side l of the rule ahlrule in the ahl net system ahlnetsys′. as a next step, the evacuate homes-transition is deleted and we obtain an intermediate ahl net system. afterwards, the transitions notify residents, assist handicapped persons, and guide persons together with their (new) environments are added to the intermediate system leading to the new ahl net system ahlnetsys′′ shown in figure 3. thus we obtain the rule based transformation ahlnetsys′ =⇒ ahlnetsys′′ via (ahlrule, m) and the result of firing the transition net transformation at the system level is the replacement of the ahl net system ahlnetsys′ by ahlnetsys′′ on the place net. afterwards, the firefighter company proceeds with its activities. the gas company has entered the area. after the identification of the problem the odor of gas grows stronger and the gas company personnel take an additional reading of the gas indicator. immediately afterwards the gas company personnel inform the company officer about the lower explosive limit (lel) such 5 / 20 volume 40 (2011) functorial analysis of algebraic higher-order net systems that he is able to determine the isolation perimeter. note that these activities depend on the exchange of messages and data concerning the result of reading the gas indicator and the final analysis of these results by the company officer. in this paper, we restrict the initial marking of the ahl net system ahlnetsys to one object net system and one corresponding rule to help the reader focus on the main concepts. in our example, only a predefined refinement of the object net system is applicable. such a situation may be useful for modeling purposes or to show properties of a small object net, which is then transformed using rules that preserve these properties. but in general, different rules are available which are applicable depending on the state of the object net. their application can be further restricted by application conditions on the rule level or additional firing conditions for the transitions on the system level. moreover, new rules may be added at runtime which allow to handle unforeseen events. for a full description of the emergency scenario, more object net systems and rules should be defined as, e. g., those given in [brhm06, phe+07]. 3 aho net systems with highand low-level tokens in this section, we introduce our formal framework for modeling data-dependent workflows in mobile ad-hoc networks as motivated by the emergency scenario in section 2. for this purpose, we introduce algebraic higher-order (aho) net systems which allow algebraic high-level (ahl) net systems and rules as tokens. this extends our approach in [hme05] where we used aho net systems with p/t systems and rules as tokens. ahl net systems resp. p/t systems are nets together with initial markings. these and the corresponding rules are used as tokens to model the interaction of token firing and net transformations. 3.1 review of the categories ptsys and ahlnetsys in the following, we review the category ptsys of p/t systems [hme05] and the category ahlnetsys of ahl net systems [pra08], which are used as tokens for the corresponding aho net systems. we use the notation of petri nets as monoids [mm90], where a p/t net is defined by pt net = (p, t, pre, post) with pre and post domain functions pre, post : t → p⊕. a p/t system is given by pt sys = (pt net, m) with a p/t net pt net and a marking m ∈ p⊕, where p⊕ is the free commutative monoid over the set p of places with binary operation ⊕. moreover, each function f : a → b can be extended to a monoid homomorphism f⊕ : a⊕ → b⊕ with f⊕(∑a∈a kaa) = ∑a∈a ka f (a). note that m can also be considered as a function m : p → n where only for a finite set p′ ⊆ p we have m(p) ≥ 1 with p ∈ p′. we can switch between these notations by defining ∑p∈p m(p)· p = m ∈ p⊕ and m(p) = ap for m = ∑p∈p ap p ∈ p⊕. moreover, for m1, m2 ∈ p⊕ we have m1 ≤ m2 if m1(p) ≤ m2(p) for all p ∈ p. note that the inverse of ⊕ is only defined in m1 m2 if m2 ≤ m1. definition 1 (category ptsys of p/t systems) given p/t systems pt sysi = (pt neti, mi) with pt neti = (pi, ti, prei, posti) for i = 1, 2, a p/t system morphism f : pt sys1 → pt sys2 is given by f = ( fp, ft ) with functions fp : p1 → p2 and ft : t1 → t2 satisfying proc. pngt 2010 6 / 20 eceasst (1) f⊕p ◦ pre1 = pre2 ◦ ft and f ⊕ p ◦ post1 = post2 ◦ ft (2) m1(p) ≤ m2( fp(p)) for all p ∈ p1 moreover, f is called strict if fp and ft are injective and (3) m1(p) = m2( fp(p)) for all p ∈ p1. the category defined by p/t systems and p/t system morphisms is denoted by ptsys where the composition and identities are defined componentwise for places and transitions. p/t systems are called low-level nets due to the fact that the tokens are indistinguishable. in contrast, a high-level net may hold different kinds of tokens and the firing behavior depends on the token kind. in ahl systems, the tokens are data elements and thus distinguishable. definition 2 (category ahlnetsys of ahl net systems) an algebraic high-level (ahl) net system ahlnetsys = (ahlnet, m) with ahlnet = ((sig, x ), p, t, pre, post, cond,type, a) consists of an algebraic signature sig = (sorts, opns) with sorts and operation symbols, additional variables x , sets of places p and transitions t , pre and post domain functions pre, post : t →(tsig(x )⊗p)⊕, firing conditions cond : t →p f in(eqns(sig; x )), a typing of places type : p → sorts, a sig-algebra a, and an initial marking m ∈cp⊕. tsig(x ) is the term algebra with variables over x , tsig(x )⊗p = {(term, p)|term ∈ tsig(x )type(p), p ∈ p}, eqns(sig; x ) are all equations over the signature sig with variables x , and cp = a⊗p ={(a, p)|a∈atype(p), p∈p}. given ahl net systems ahlnetsysi = (ahlneti, mi) with ahlneti = ((sig, x ), pi, ti, prei, posti, condi,typei, a) for i = 1, 2, an ahl net system morphism f : ahlnetsys1 →ahlnetsys2 is given by f = ( fp, ft ) with functions fp : p1 → p2 and ft : t1 → t2 satisfying (1) (id ⊗ fp)⊕◦ pre1 = pre2 ◦ ft and (id ⊗ fp)⊕◦ post1 = post2 ◦ ft , (2) cond2 ◦ ft = cond1 (3) type2 ◦ fp = type1 (4) ∀a ∈ atype1(p1), p1 ∈ p1 : m1(a, p1) ≤ m2(a, f p(p1)) moreover, f is called strict if fp and ft are injective and (5) m1(a, p1) = m2(a, fp(p1)) for all a ∈ atype1(p1) and p1 ∈ p1. the category defined by ahl net systems and ahl net system morphisms is denoted by ahlnetsys where the composition and identities are defined componentwise for places and transitions. for the firing of a transition in an ahl net system, we first have to find a suitable variable assignment such that for the term inscription on the pre arc, tokens on the corresponding predomain places are selected satisfying the firing condition. 7 / 20 volume 40 (2011) functorial analysis of algebraic higher-order net systems definition 3 (firing behavior of ahl net systems) given an ahl net system ahlnetsys = (ahlnet, m) with ahlnet = ((sig, x ), p, t, pre, post, cond,type, a), the set of variables var(t) ⊆ x of a transition t ∈ t are the variables of the net inscriptions in pre(t), post(t), and cond(t). let σ : var(t) → a be a variable assignment with term evaluation σ # : tsig(var(t)) → a, then (t, σ ) is a consistent transition assignment iff cond(t) is valid in a under σ . the set ct of consistent transition assignments is defined by ct = {(t, σ )|(t, σ ) consistent transition assignment}. a transition t ∈ t is enabled in m under σ iff (t, σ ) ∈ ct and prea(t, σ ) ≤ m, where prea : ct → cp⊕ is defined for pre(t) = ∑ni=1(termi, pi) by prea(t, σ ) = ∑ n i=1(σ #(termi), pi), and similarly for posta(t, σ ). then the follower marking is computed by m′ = m prea(t, σ )⊕ posta(t, σ ). intuitively, a pushout in the categories ptsys and ahlnetsys means the gluing of two net systems along an interface system. the pushout object is constructed componentwise for transitions and places in the category set with corresponding pre and post domain functions and initial markings. definition 4 (pushouts in the category ptsys) the pushout (pn2, m2) n→ (pn3, m3) g ← (pn1, m1) of the p/t system morphisms m : (pn0, m0) → (pn1, m1) and f : (pn0, m0) → (pn2, m2), where m is strict, can be constructed as pushout in ptnet [ep04], i.e. component-wise for places and transitions. the marking m3 is defined by 1. ∀p1 ∈ p1 \m(p0) : m3(gp(p1)) = m1(p1) 2. ∀p2 ∈ p2 \ f (p0) : m3(np(p2)) = m2(p2) 3. ∀p0 ∈ p0 : m3(np ◦ fp(p0)) = m2( fp(p0)) for pi being the sets of places of pni for i = 0, 1, 2, 3. definition 5 (pushouts in the category ahlnetsys) the pushout (ahlnet2, m2) n→ (ahlnet3, m3) g ← (ahlnet1, m1) of the ahl net system morphisms m : (ahlnet0, m0) → (ahlnet1, m1) and f : (ahlnet0, m0) → (ahlnet2, m2), where m is strict, can be constructed as pushout in ahlnet [per95], i.e. componentwise for places and transitions. the marking m3 is defined by 1. ∀p1 ∈ p1 \m(p0), a ∈ atype1(p1) : m3(a, gp(p1)) = m1(a, p1) 2. ∀p2 ∈ p2 \ f (p0), a ∈ atype2(p2) : m3(a, np(p2)) = m2(a, p2) 3. ∀p0 ∈ p0, a ∈ atype0(p0) : m3(a, np ◦ fp(p0)) = m2(a, fp(p0)) for pi being the places of ahlneti for i = 0, 1, 2, 3. remark 1 note that items 2 and 3 combined are equivalent to ∀p2 ∈ p2, a ∈ atype2(p2) : m3(a, np(p2)) = m2(a, p2). proc. pngt 2010 8 / 20 eceasst 3.2 aho net systems with ahl net systems as tokens an algebraic higher-order (aho) net system can be considered as an algebraic high-level (ahl) net system modeling the system level. the main difference is that an aho net system contains not an algebra, but a class algebra, i.e. an algebra with classes instead of sets as base sets. this specific class algebra a defines net systems and rules as tokens at the object level. the class algebra a includes domains like anet , which is the class of all net systems of a specific kind of low-level or high-level net systems and cannot be restricted to be a set. in the following, we introduce aho net systems which have ahl net systems and corresponding rules as tokens. first we introduce an algebraic signature for the class algebra of aho net systems which can be used for low-level and high-level net systems as tokens, the enabling and firing of transitions as well as the applicability of rules, and the rule based transformation of net systems. definition 6 (signature for aho net systems) the signature for algebraic higher order (aho) net systems with net systems and rules as tokens is given by: ahon sig = sorts: net, trans, bool, mor, rules opns: undefined :→ net, tt, ff :→ bool, enabled : net ×trans → bool, fire : net ×trans → net, applicable : rules×mor → bool, transform : rules×mor → net cod : mor → net note that the signature ahon sig does not fix the type of net systems which may be used as tokens. this is achieved by the corresponding class algebras ahl for ahl net systems and apt for p/t systems as tokens, which are both class algebras for the signature ahon sig. for ahl, (ahl)net is the class of all ahl net systems ahlnetsys including a special undefined element specified by a constant. in order to model the consistent transition assignments of ahl net systems we define the domain (ahl)trans to be the class sets of all sets. note, however, that only sets s of the form s = {(t, σ )} with (t, σ ) ∈ctahl are relevant, where ctahl is the set of all consistent transition assignments, t ∈ tahl is a transition and σ : var(t) → dahl a corresponding variable assignment of some ahl net system ahlnetsys = ((sigahl, xahl), pahl, tahl, preahl, postahl, condahl,typeahl, dahl, mahl). for the definition of the operations enabledhl and firehl we use the extended pre and post domain functions predahl and postdahl (see definition 3). in order to model the applicability of rules and rule based transformations of ahl net systems [pra08] we use the operations applicablehl and transformhl defined on the domains (ahl)mor of all ahlnetsys-morphisms and (ahl)rules of all rules rl = (l l← k r→ r) for ahl net systems. a rule rl is applicable to ahlnetsys′ via match morphism m : ahlnetsys → ahlnetsys′ if l = ahlnetsys and m satisfies the gluing condition w.r.t. rl, which means that we have a pushout complement ahlnetsys0 in (1) below. in this case, we can construct the pushout (2) leading to ahlnetsys′′. the double pushout (1+2) defines the rule based transformation 9 / 20 volume 40 (2011) functorial analysis of algebraic higher-order net systems ahlnetsys′ ⇒ ahlnetsys′′ via (rl, m). note that due to the fact that pushouts are only unique up to isomorphism, we have to fix a concrete construction for the definition of transformhl selecting a specific pushout for each transformation according the one in definition 5. l m �� (1) k loo r // �� r �� (2) ahlnetsys′ ahlnetsys0oo // ahlnetsys′′ definition 7 (class algebra ahl for ahl net systems as tokens) given the signature ahon sig, the class algebra ahl for ahl net systems and corresponding rules as tokens is given by ahl = ((ahl)net , (ahl)trans, (ahl)bool , (ahl)mor, (ahl)rules, undefinedhl, tthl, ff hl, enabledhl, firehl, applicablehl, transformhl) with (ahl)net = {ahlnetsys | ahlnetsys is an ahl net system}∪{unde f} the class of all ahl net systems including undefined, (ahl)trans = sets the class of all sets, (ahl)bool = {true, false}, (ahl)mor = {m : ahlnetsys → ahlnetsys′ | m ahlnetsys-morphism}, (ahl)rules = {rl = (l l← k r→ r) | l, r strict ahlnetsys-morphisms}, undefinedhl = undef , tthl = true, ff hl = false, enabledhl : (ahl)net ×(ahl)trans → (ahl)bool defined for s ∈ (ahl)trans by enabledhl(undef , s) = false and for ahlnetsys = ((sigahl, xahl), pahl, tahl, preahl, postahl, condahl, typeahl, dahl, mahl) by enabledhl(ahlnetsys, s) =   true if ∃t, σ : s = {(t, σ )},t ∈ tahl, (t, σ ) ∈ctahl predahl (t, σ ) ≤ mahl false else firehl : (ahl)net ×(ahl)trans → (ahl)net with firehl(undef , s) = undef and for ahlnetsys = (ahlnet, mahl) with firehl(ahlnetsys, s) =   (ahlnet, m′ahl) if enabledhl(ahlnetsys, s) = true, s = {(t, σ )}, m′ahl = mahl predahl (t, σ )⊕ postdahl (t, σ ) undef else applicablehl : (ahl)rules ×(ahl)mor → (ahl)bool with applicablehl(rl, m) = { true if l = ahlnetsys∧m satisfies gluing condition w.r.t. rl false else where rl = (l l← k r→ r) and m : ahlnetsys → ahlnetsys′ proc. pngt 2010 10 / 20 eceasst transformhl : (ahl)rules ×(ahl)mor → (ahl)net with transformhl(rl, m) =   ahlnetsys′′ if applicablehl(rl, m) = true and ahlnetsys′ (rl,m) =⇒ ahlnetsys′′ undef else codhl : (ahl)mor → (ahl)net with codhl(m) = ahlnetsys ′ for m : ahlnetsys → ahlnetsys′. now we are able to define aho net systems with ahl net systems and rules as tokens and the corresponding category ahonahl. an aho net system is defined using a “class algebra based” ahl net system, i.e. an ahl net system ahonahl in the sense of definition 2, where the algebra a is allowed to be a class algebra like ahl in definition 7. but note that the carrier set (ahl)net does not include class based ahl net systems like itself to avoid set theoretical problems of self inclusion. definition 8 (category ahonahl of aho net systems) given the signature ahon sig (see definition 6) and the class algebra ahl (see definition 7), an aho net system ahonahl – with ahl net systems and rules as tokens – is a (class algebra based) ahl net system ahonahl = ((ahon sig, x ), p, t, pre, post, cond,type, ahl, mhl) where the signature ahon sig with sufficiently large family of sets x of variables and algebra ahl are fixed. the initial marking mhl ∈(ahl⊗p)⊕ can be represented by mhl : ahl⊗p →n. a morphism f : ahon1ahl → ahon2ahl of aho net systems is an ahlnetsys-morphism. this means that for aho net systems ahoniahl = ((ahon sig, x ), pi, ti, prei, posti, condi, typei, ahl, mihl ) for i = 1, 2, we have f = ( fp : p1 → p2, ft : t1 → t2) with (=) t1cond1 sshhhhh hhhh hhhh h ft �� pre1 // post1 // (=) (tahon sig(x )⊗p1)⊕ (id⊗ fp)⊕ �� p f in(eqns(ahon sig, x )) t2 cond2 kkwwwwwwwwwwwwww pre2 // post2 // (tahon sig(x )⊗p2)⊕ p1 fp �� type1 **ttt tttt ttt (=) sorts(ahon sig) p2 type2 44jjjjjjjjjj and m1hl (a, p1) ≤ m2ahl (a, fp(p1)) for all p1 ∈ p1 and a ∈ (ahl)type1(p1). the category ahonahl of aho net systems based on the class algebra ahl consists of all aho net systems as objects and aho net system morphisms as morphisms. example 1 (aho net system for emergency scenario) the aho net system ahonahl = ((ahon sig, x ), p, t, pre, post, cond,type, ahl, mhl) in figure 1 consists of 11 / 20 volume 40 (2011) functorial analysis of algebraic higher-order net systems • the signature ahon sig (see definition 6), the ahon sig-algebra ahl (see definition 7), and variables xnet = {n}, xtrans = {tσ}, xbool = ∅, xmor = {m}, xrules = {rl}, • the set of places p = {net, rules} with type(net) = net and type(rules) = rules, • the set of transitions t = {token firing, net transformation} with pre and post domain and firing conditions as shown in figure 1, and • the initial marking mhl = (ahlnetsys, net)⊕(ahlrule, rules), where ahlnetsys and ahlrule are shown as marking on the places net and rules, respectively. the data type part of the ahl net systems ahlnetsys and l, k and r in ahlrule is given by the signature and corresponding algebra of natural numbers and boolean values together with a sort tok for black tokens. as shown in [pra08] for algebraic high-level net systems with fixed data type, the category ahonahl is a weak adhesive hlr category where pushouts are constructed componentwise, because the fact that ahl is a class algebra instead of a classical algebra does not affect these properties. 3.3 aho net systems with p/t systems as tokens in order to define a net class transformation from aho net systems with high-level net system and rules as tokens to those with low-level net systems and rules as tokens we briefly introduce the second kind of aho net system. in fact, we can use the same signature ahon sig (see definition 6) but use a different class algebra apt for p/t systems and corresponding rules as tokens. apt = ((apt )net , (apt )trans, (apt )bool , (apt )mor, (apt )rules, undef , true, false, enabledpt , firept , applicablept , transformpt ) the main difference is that (apt )net is the class of all p/t systems (including a constant for undefined) and (apt )mor, (apt )rules as well as applicablept and transformpt are based on ptsys-morphisms instead of ahlnetsys-morphisms (see definition 7). the operations enabledpt and firept are defined for p/t systems pt sys = (pt net, mn ) = (pn , tn , pren , postn , mn ) and a set s ∈ (apt )trans by enabledpt : (apt )net ×(apt )trans → (apt )bool with enabledpt (undef , s) = false, enabledpt (pt sys, s) = { true if ∃t ∈ tn : s = {t} and pren (t) ≤ mn false else firept : (apt )net ×(apt )trans → (apt )net with firept (undef , s) = undef and firept (pt sys, s) =   (pt net, m′n ) if enabledpt (pt sys, s) = true with s = {t} and m′n = mn pren (t)⊕ postn (t) undef else proc. pngt 2010 12 / 20 eceasst this class algebra leads to aho net systems ahonpt with p/t systems and rules as tokens and to the corresponding category ahonpt. note that our class algebra apt is more general than the one in [hme05], where (apt )net is restricted to all p/t systems which are subsystems of a given super net system. definition 9 (category ahonpt of aho net systems) given the signature ahon sig (see definition 6) and the class algebra apt , an aho net system ahonpt with p/t systems and rules as tokens is a (class algebra based) ahl net system ahonpt = ((ahon sig, x ), p, t, pre, post, cond,type, apt , mpt ) with fixed (ahon sig, x ) and apt . together with corresponding ahl net system morphisms we obtain the category ahonpt of aho net systems based on class algebra apt . example 2 an example of an aho net system with p/t systems and rules as tokens is depicted in figure 4, which is analogously defined to the aho net system ahonahl in figure 1, but the ahon sig-algebra is given by apt and the initial marking by mpt = (pt sys, net)⊕ (pt rule, rules), where pt sys is a p/t system and pt rule a p/t system rule. 4 net class transformation for aho net systems since several net classes form different categories, net class transformations are expressed by functors. well-known examples of net class transformations are the concepts of flattening and skeleton as introduced in [urb03]. in this section, the extended skeleton of aho net systems is introduced. it is expressed by the functor fskel : ahonahl → ahonpt based on the skeleton functor skel : ahlnetsys → ptsys. both functors are defined and some interesting properties of the functor fskel are verified. 4.1 extended skeleton functor for aho net systems the functor fskel : ahonahl → ahonpt extends the skeleton functor skel : ahlnetsys → ptsys (see [urb03]) that “forgets” the data type of an ahl net system but preserves the token count on the places and the multiplicity of the edges. definition 10 (functor skel) given the ahl net system ahlnetsys = ((sig, x ), p, t, pre, post, cond,type, a, m) and a morphism f = ( fp, ft ) : ahlnetsys → ahlnetsys′, the skeleton functor skel : ahlnetsys → ptsys is defined by skel(ahlnetsys) = pt sys = (p, t, pre′, post′, m′) skel( f ) = f ′ : skel(ahlnetsys) → skel(ahlnetsys′) with pre′(t) = πp⊕(pre(t)), post ′(t) = πp⊕(post(t)) for all t ∈ t , where πp⊕ : (tsig(x )⊗p)⊕→ p⊕ is a projection, m′(p) = ∑a∈atype(p) m(a, p), and f ′ p(p) = fp(p) and f ′ t (t) = ft (t) for all p ∈ p and t ∈ t . 13 / 20 volume 40 (2011) functorial analysis of algebraic higher-order net systems result < 5% lel request to control traffic into the area identify the location gas is highest additional reading the gas indicator shut off electricity and gas lines gas company call the reading the gas indicator expand the area of evacuation notify residents of the evacuation persons assist handicapped the extent possible guide persons to deny entry stand by p10 evacuate homes in the immediate area p1 4p3p p6 p9 p12 p14 p15 p13 p8 p p’’’ p’’ p’ r p p’’’ k rl the immediate area evacuate homes in p p’’’ l p7 p5 p2 p11 result >= 5% lel n m : mor cod m = n applicable(rl, m) = tt n tσ : trans token firing transform(rl, m) net transformation rl rules : rules (ahon sig, x ), apt enabled(n,tσ ) =tt net : net fire(n,tσ ) ptsys ptrule figure 4: algebraic higher-order net system ahonpt remark 2 the skeleton functor skel : ahlnetsys → pt sys preserves pushouts, doublepushout (dpo) transformations, and also enabling and firing of transitions. the extended skeleton functor fskel for aho net systems “forgets” the data type part of the object net systems using the skeleton functor skel. moreover, this functor replaces the ahon sig-algebra ahl for ahl net systems and the corresponding rules by the algebra apt for p/t systems and the corresponding skeleton rules. definition 11 (functor fskel ) given the aho net system ahonahl = ((ahon sig, x ), p, t, pre, post, cond, type, ahl, mhl) with fixed class algebra ahl (see definition 7) and mhl : ahl ⊗p → n then the extended skeleton functor fskel : ahonahl → ahonpt is given by proc. pngt 2010 14 / 20 eceasst fskel (ahonahl) = ahonpt = ((ahon sig, x ), p, t, pre, post, cond,type, apt , mpt ) with fixed class algebra apt (see subsection 3.3) and mpt : apt ⊗p → n defined by (∗) mpt (apt , p) = ∑ ahl∈(ahl)type(p) ∑ stype(p)(ahl)=apt mhl(ahl, p) for apt ∈ apt , ahl ∈ ahl, and s : ahl → apt defined as family s = [ss : (ahl)s → (apt )s]s∈y for y = {net, trans, bool, mor, rules} is given for a ∈ (ahl)s by ss(a) =   skel(a) for s ∈{net, mor, rules} undef for s = net, a = undef {t} for s = trans and a = {(t, σ )} with t ∈ t a for (s = trans and a 6= {(t, σ )} with t ∈ t ), or s = bool for a morphism f = ( fp, ft ) : ahonahl → ahon′ahl of aho net systems it is defined by fskel ( f ) = f ′ : ahonpt → ahon′pt with f ′ = ( fp, ft ). remark 3 note that s : ahl → apt defined above by the family [ss]s∈y is not an ahonsighomomorphism since it is not compatible with the enable-operations as shown in the introduction of the subsection 4.2. in the following theorem, we show that fskel is a functor and preserves pushouts along strict morphisms and transformations. theorem 1 1. fskel : ahonahl → ahonpt is functor. 2. fskel preserves pushouts along strict morphisms and double pushout transformations. proof. 1. from the definition, it is clear that fskel is compatible with composition and identities. mainly, we have to show that it is well-defined for the marking, i.e. for f : ahon1ahl → ahon2ahl in ahonahl with m1hl (ahl, p) ≤ m2hl (ahl, fp(p)) we have to show that m1pt (apt , p) ≤ m2pt (apt , fp(p)) for fskel ( f ) : fskel (ahon1ahl ) → fskel (ahon2ahl ) in ahonpt. using (*) in definition 11 in section 4 we have that m1pt (apt , p) = ∑ s(ahl)=apt m1hl (ahl, p) ≤ ∑ s(ahl)=apt m2hl (ahl, fp(p)) = m2pt (apt , fp(p)) 15 / 20 volume 40 (2011) functorial analysis of algebraic higher-order net systems 2. first, we show that fskel preserves pushouts along strict morphisms. let ahoniahl = (aniahl , mihl ) for i = 0, 1, 2, 3 and (1) be a pushout in ahonahl (see definition 5) along the strict morphism f1. (an0ahl , m0hl ) f1 // f2 �� (1) (an1ahl , m1hl ) g1 �� (an2ahl , m2hl ) g2 // (an3ahl , m3hl ) (an0pt , m0pt ) f1 // f2 �� (2) (an1pt , m1pt ) g1 �� (an2pt , m2pt ) g2 // (an3pt , m3pt ) applying fskel we obtain ahonipt = (anipt , mipt ) in (2) with anipt obtained from aniahl by replacing ahl by apt . we have to show that (2) is a pushout in ahonpt(see definition 4). according to the pushout construction in ahlnetsys (see definition 5) along the strict morphism f1 in (1) we have that mihl (i = 0, 1, 2, 3) with m3hl (ahl, g1(p1)) = m1hl (ahl, p1) for p1 ∈ p1\ f1(p0) and m3hl (ahl, g2(p2)) = m2hl (ahl, p2) for p2 ∈ p2. by definition of fskel we have mipt (apt , p) = ∑ s(ahl)=apt mihl (ahl, p) for i=0,1,2, 3, where pi are the places of anihl resp. anipt . it remains to show that m3pt (apt , g1(p1)) = m1pt (apt , p1) for p1 ∈ p1\ f1(p0) and m3pt (apt , g2(p2)) = m2pt (apt , p2) for p2 ∈ p2. for p1 ∈ p1\ f1(p0), we have that m3pt (apt , g1(p1)) = ∑ s(ahl)=apt m3hl (ahl, g1(p1)) = ∑ s(ahl)=apt m1hl (ahl, p1) = m1pt (apt , p1) similarly, m3pt (apt , g2(p2)) = m2pt (apt , p2) for all p2 ∈ p2. hence, (2) is a pushout in ahonpt which implies that fskel preserves pushouts along strict morphisms. this also implies that fskel preserves double pushout transformations. proc. pngt 2010 16 / 20 eceasst 4.2 firing properties of the net class transformation in this subsection, we analyze under which conditions the net class transformation fskel : ahonahl → ahonpt preserves enabling and firing of transitions at the system level. as explained above, h : ahl →apt based on the skeleton functor skel : ahlnetsys→ptsys is not a homomorphism because this functor preserves the firing behavior, but in general it does not reflect enabling and firing of transitions. this means that enabledhl(ahlnetsys,{(t, σ )}) = b implies enabledpt (skel(ahlnetsys)),{t}) = b for b = true but not for b = false. definition 12 (firing properties of fskel ) given an aho net system ahonahl = ((ahon sig, x ), p, t, pre, post, cond,type, ahl, mhl) with fskel (ahonahl) = ahonpt we say that fskel preserves 1. consistent transition assignments, if ∀t ∈ t, σ : var(t) → ahl: (t, σ ) ∈ctahl ⇒ (t, σ ′) ∈ctpt for σ ′ = s◦σ 2. enabling, if ∀(t, σ ) ∈ctahl: preahl (t, σ ) ≤ mhl ⇒ preapt (t, σ ′) ≤ mpt = (s⊗idp)⊕(mhl) 3. firing, if for mhl enabled under (t, σ ) ∈ctahl: m′hl = mhl preahl (t, σ )⊕ postahl (t, σ ) ⇒ m′pt = (s⊗idp)(m ′ hl) = mpt preapt (t, σ ′)⊕ postapt (t, σ ′) remark 4 in general, the functor fskel : ahonahl → ahonpt does not preserve consistent transition assignments, especially if cond(t) includes an equation of the form enabled(n,tσ ) = ff (see introduction of subsection 4.2). but fskel preserves consistent transition assignments if cond(t) includes only special equations of the form enabled(n,tσ ) = tt, fire(n,tσ ) = n′, applicable(rl, m) = tt, transform(rl, n) = n′, and cod(m) = n. in this case, skel preserves enabling, firing, pushouts, dpo-transformations (see remark 2), and codomains. theorem 2 (firing properties of fskel ) for an aho net system ahonahl, fskel : ahonahl → ahonpt preserves enabling and firing if it preserves consistent transition assignments. proof. suppose that the arc inscriptions of ahonahl are only variables or sums of variables. if this is not the case, we modify the aho net system by introducing for each term tm in the arc inscriptions a new variable x and an equation x = tm for the corresponding transition. for all t ∈ t , σ : var(t) → ahl we have that (t, σ ) ∈ ctahl implies (t, σ ′) ∈ ctpt for σ ′ = s◦σ . 1. fskel preserves enabling. for (t, σ ) ∈ctahl and preahl(t, σ ) ≤ mhl we have that preapt (t, σ ′) (∗∗) = (s⊗idp)(preahl (t, σ )) ≤ (s⊗idp)(mhl) = mpt 17 / 20 volume 40 (2011) functorial analysis of algebraic higher-order net systems where (**) holds because pre(t) = ∑ni=1(termi, pi) and σ : var(t) → ahl implies preahl (t, σ ) = n ∑ i=1 (σ #(termi), pi) and preapt (t, σ ′) = n ∑ i=1 (σ ′#(termi), pi) = (s⊗idp)( n ∑ i=1 (σ #(termi), pi)) = (s⊗idp)(preapt (t, σ )) note that σ ′ = s◦σ implies σ ′#(termi) = s(σ #(termi)) because by assumption the arc inscriptions termi are only variables. otherwise we would need s : ahl → apt to be an ahon sig-homomorphism which is not true in general. 2. fskel preserves firing. m′pt = (s⊗idp)(m ′ hl) = (s⊗idp)(mhl preahl (t, σ )⊕ postahl (t, σ )) = (s⊗idp)(mhl) (s⊗idp)(preahl (t, σ ))⊕ (s⊗idp)(postahl (t, σ )) = mpt preapt (t, σ ′)⊕ postapt (t, σ ′) example 3 the result of the extended skeleton functor fskel applied to the aho net system ahonahl in figure 1 is the aho net system ahonpt = ((ahon sig, x ), p, t, pre, post, cond,type, apt , mpt ) with p/t system and rule tokens in figure 4. the firing conditions of ahonahl in figure 1 consist only of equations of the form enabled(n, tσ ) = tt, applicable(rl, m) = tt, and cod(m) = n so that consistent transition assignments are preserved by the extended skeleton functor (see remark 4). moreover, by remark 4 we obtain new equations of the form fire(n,tσ ) = n′ and transform(rl, n) = n′ if we replace the arc inscriptions fire(n,tσ ) and transform(rl, n) by n′ and introduce the new equations as conditions for the transitions token firing and net transformation, respectively. according to remark 4, fskel still preserves consistent transition assignments including also there new equations. hence, we can assume without loss of generality that the arc inscriptions of ahonahl in figure 1 on the system level are only variables. thus, due to theorem 2, the enabling and firing of ahonahl in figure 1 is preserved by fskel . in more detail, consider the consistent transition assignment (token firing, σ ) with σ (n) = ahlnetsys and σ (tσ ) be the consistent transition assignment of the object net system ahlnetsys given by the call the gas company-transition and corresponding variable assignment and m′hl be the follower marking of ahonahl (see figure 2). then (token firing, σ ′) with proc. pngt 2010 18 / 20 eceasst σ ′(n) = skel(ahlnetsys) = pt sys, σ ′(tσ ) = call the gas company and pt sys = (pt net, m) is a consistent transition assignment of the aho net system ahonpt (see figure 4). moreover, the transition token firing is enabled in ahonpt under σ ′ and the follower marking is defined by m′pt = (pt sys ′, net)⊕(pt rule, rules) with pt sys′ = (pt net, m′), where m′ is given by the marking of the three places in the post domain of the call the gas company-transition. 5 conclusion and future work in this paper, we have introduced aho net systems, a special kind of algebraic high-level nets with net systems and corresponding rules as tokens. moreover, we have analyzed the skeleton functor fskel : ahonahl → ahonpt relating aho net systems based on ahl net systems to aho net systems based on p/t nets. in [urb03], net class transformations have been introduced to allow a model developer to change the underlying petri net class during the modeling step. this concept has been applied on classes of marked place/transition nets and algebraic high-level nets. in addition to the functor skel : ahlnetsys → ptsys we should analyze the functors f lat : ahlnetsys → ptsys and data : ptsys → ahlnetsys as given in [urb03] leading to corresponding functors ff lat : ahonahl → ahonpt and fdata : ahonpt → ahonahl. the functor f lat : ahlnetsys → ptsys relates ahl net systems to p/t systems as well, but in contrast to skel it preserves the data type information as each possible marking of the ahl net system is considered to be a place in the p/t system. the data type is flattened into the set of places, hence the name. the functor data : ptsys → ahlnetsys lifts a p/t system to an ahl net system by providing a trivial data type that describes the black tokens. this functor preserves the net structure and adds a one-sorted specification and an algebra where the carrier set has only one element, that is the black token. similar to [urb03], the corresponding functors ff lat : ahonahl → ahonpt and fdata : ahonpt → ahonahl formalize net class transformations at the level of tokens of an aho net system. these net class transformations allow changes of the underlying petri net class at the token level. the signature and algebra in this paper are tailored to our needs to represent manets with aho net systems. but the underlying principles including the analysis using the skeleton functor can be transferred to other high-level systems based on additional sorts and operations. a more thorough analysis concerning the properties that are required for the algebra would be an interesting line of future work. bibliography [vda03] w. van der aalst. the application of petri nets to workflow management. journal of circuits, systems and computers 8(1):21–66, 2003. [az03] d. agrawal, q. zeng. introduction to wireless and mobile systems. thomson brooks/cole, 2003. 19 / 20 volume 40 (2011) functorial analysis of algebraic higher-order net systems [brhm06] p. bottoni, f. rosa, k. hoffmann, m. mecella. applying algebraic approaches for modeling workflows and their transformations in mobile networks. journal of mobile information systems 2(1):51–76, 2006. [eept06] h. ehrig, k. ehrig, u. prange, g. taentzer. fundamentals of algebraic graph transformation. eatcs monographs. springer, 2006. [ehp+07] h. ehrig, k. hoffmann, j. padberg, u. prange, c. ermel. independence of net transformations and token firing in reconfigurable place/transition systems. in proc. of atpn 2007. lncs 4546, pp. 104–123. springer, 2007. [ep04] h. ehrig, j. padberg. graph grammars and petri net transformations. in lectures on concurrency and petri nets special issue advanced course pnt. lncs 3098, pp. 496–536. springer, 2004. [hme05] k. hoffmann, t. mossakowski, h. ehrig. high-level nets with nets and rules as tokens. in proc. of atpn 2005. lncs 3536, pp. 268–288. springer, 2005. [mm90] j. meseguer, u. montanari. petri nets are monoids. information and computation 88(2):105–155, 1990. [peh07] j. padberg, h. ehrig, k. hoffmann. formal modeling and analysis of flexible processes in mobile ad-hoc networks. bulletin of the eatcs 91:128–132, 2007. [per95] j. padberg, h. ehrig, l. ribeiro. algebraic high-level net transformation systems. mscs 5:217–256, 1995. [phe+07] j. padberg, k. hoffmann, h. ehrig, t. modica, e. biermann, c. ermel. maintaining consistency in layered architectures of mobile ad-hoc networks. in proc. of fase 2007. lncs 4422, pp. 383–397. springer, 2007. [pra08] u. prange. towards algebraic high-level systems as weak adhesive hlr categories. entcs 203(6):67–88, 2008. [rmpm03] f. rosa, v. martino, l. paglione, m. mecella. mobile adaptive information systems on manet: what we need as basic layer? in proc. of mmis 2003. 2003. [urb03] m. urbášek. categorical net transformations for petri net technology. phd thesis, tu berlin, 2003. [val98] r. valk. petri nets as token objects: an introduction to elementary object nets. in proc. of atpn 1998. lncs 1420, pp. 1–25. springer, 1998. proc. pngt 2010 20 / 20 introduction and related work motivation: emergency scenario aho net systems with highand low-level tokens review of the categories ptsys and ahlnetsys aho net systems with ahl net systems as tokens aho net systems with p/t systems as tokens net class transformation for aho net systems extended skeleton functor for aho net systems firing properties of the net class transformation conclusion and future work on judgements and propositions electronic communications of the easst volume 26 (2010) manipulation of graphs, algebras and pictures essays dedicated to hans-jörg kreowski on the occasion of his 60th birthday on judgements and propositions bernd mahr 20 pages guest editors: frank drewes, annegret habel, berthold hoffmann, detlef plump managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst on judgements and propositions bernd mahr technische universität berlin, germany mahr@cs.tu-berlin.de abstract: this article studies some of the relevant and historically influential conceptions of the notions of ’judgement’ and ’proposition’ and discusses the relationship of these notions in these conceptions. in some detail the conceptions of aristoteles, brentano and twardowski, frege, martin-löf and of epsilon-theory are presented. a comparison of these conceptions shows fundamental differences which, in a way, illuminate the differences found in the architectures and formal appearances of logics. keywords: judgement, proposition, assertion, presentation, interpretation, justification, truth, logic. 1 introduction provoked by the different architectures and formal appearances of logics the question can be asked “what the fundament of logic is that admits the different views on it.” a natural though not obvious answer is that the different approaches to logic are all rooted on conceptions of judgement and proposition. both notions have been a matter of dispute since the beginning of greek philosophy and are still today under debate, and both are closely linked with logic. to study some of these conceptions and to thereby shed some light on the different forms of logic and on their relationship, is the author’s first motivation to write this article. it turns out, however, that this is not easy at all since the notions of judgement and proposition are deeply involved. they touch on and relate fundamental questions of language, ontology, psychology, philosophy and mathematics, and their meaning is far from being common sense. by some authors the notion of proposition is even objected to be meaningful at all, [voq80, pp. 331–401] and the word judgement is taken to express things of the most different kind, from the most elementary relation between the human mind and the world, [kan90] up to what is realised by natural deduction proofs in intuitionistic type theory1. the author’s interest in the notion of judgement also has another reason. in his studies on the general notion of ‘model’2 it was found that the key to resolve the problems, encountered in explaining the notion of ‘model’ in its full generality, is to transform the original question of “what is a model” from ontology to logic and to ask instead “what justifies a judgement, that something is a model.” deeper analysis of this new question naturally leads to the notions of conception (in german auffassung) and context. [mah97] the notion of conception is closely related to the notions of presentation and judgement, which both have been extensively studied 1see for example göran sundholm: proofs as acts and proofs as objects: some questions for dag prawitz, as well as prawitz’ response to these questions, both in [han98, pp. 187–216, 283–337]. 2see for example [mah09]. 1 / 20 volume 26 (2010) mailto:mahr@cs.tu-berlin.de on judgements and propositions in the 19th century and can count as sources of modern mathematics. on the other hand, judgements are based on conceptions. the author’s studies of the notions of conception and context resulted in a ‘model of conception,’ [mah10] which is an axiomatisation of reflexive universes of things relativised by their subject and context dependency. in a recent thesis [wie09] settheoretic realisations of this axiomatisation have been given and its consistency has been proven. judgements and in particular the judgements of model-being have thereby a sound fundament in their prerequisite ‘conception.’ 2 the notions of judgement and proposition in brief by “judgement” one denotes both, the act of judging and the result of this act.3 a judgement, as an act and as the result of this act, is always concerning something, that which is judged, the judged. a conventional though rather imprecise definition states that that which is judged is a proposition, and that a proposition is what is true or false. the traditional views on judgement date from the presocratic philosopher parmenides, [par69] and, among others, from plato in his sophistes, and predominantly from aristoteles. aristoteles developed in his writings4, which were later collectively called organon (in german werkzeug), in the sense of a tool of the mind, the first elaborated and most influential concept of judgement, and laid therewith the ground for what logic is about. it is common to the traditional views on judgement that that, which is judged, is affirmed or denied to exist, and that ‘being,’ ‘the presence of being there,’ [tug03] and later also ‘existence,’ make the grounds for affirmation and denial. judgements under these views concern things and matters in reality, and, accordingly, the notion of judgement under these views is based on reality as a fundament of truth. despite many extensions and modifications much of the essence of these traditional views, namely of aristoteles’ approach to logic, has been maintained through the times until to the mid 19th century. and it can still be found today in the tarski-style of semantics, as it is commonly used in the model-theoretic semantics of logic. major modifications on the traditional views, which finally lead to the formal treatment of logic today, originate from the work of george boole, namely his investigation of the laws of thought on which are founded the mathematical theories of logic and probabilities [boo58] from 1854, from the works of bernhard bolzano5, namely in his wissenschaftslehre from 1837 and franz brentano [bre08] in his psychologie vom empirischen standpunkte from 1874, as well as from the works of brentano’s students kasimir twardowski [twa82], alexius meinong [mei02] and edmund husserl [hus93], namely on their conceptions of judgement. maybe the strongest influence on modern logic had gottlob frege who, with his begriffsschrift [fre07] from 1879, laid the ground for a new understanding of quantification and predication, and developed basic principles of the notion of judgement, which have later been widely adopted in the formal treatment of semantics. influenced 3what actually is denoted by “judgement” depends heavily on what is considered to be an act of judging and what as the result of this act. see for example göran sundholm: proofs as acts and proofs as objects: some questions for dag prawitz, as well as prawitz’ response to these questions, both in [han98]. 4these writings include categoriae, de interpretatione, analytica priora, analytica posteriori, topica and de sophistiis elenchiis. 5[bol81] from 1837, see also [ber92]. festschrift hjk 2 / 20 eceasst from frege’s work and other sources alfred north whitehead and bertrand russell wrote their principia mathematica [wr62] in the years 1910 to 1913 and ludwig wittgenstein responded in his tractatus logico philosophicus [wit73], published in 1921, to frege and to russell’s theory of knowledge [rus92], which russell wrote in 1913 but then, in reaction to wittgenstein’s criticism, abandoned. later, in his philosophical investigations [wit67], written in the time from 1945 to 1949, wittgenstein recalled and criticised many of the thoughts he had put forward in the tractatus on the nature of language. the modern debates on the notion of judgement owe much to the theory of speech acts as it has been developed in the 50th and 60th of the last century first by john l. austin [aus02] and later by john r. searle. [sea08] in the course of this development the notions of judgement and proposition became a subject matter in ontology and philosophy rather than in classical formal logic where they are, so to say, banned to the meta-level of formalisation and only implicitly present in the interpretation of sentences. explicit use of the notion of judgement, however, can be found in per martin-löf’s intuitionistic type theory, published 1984, and in specification frameworks and formalisms inspired by him, like the calculus of constructions, lf, coq or isabelle, developed since 1992. martin-löf insists on a formal distinction between propositions and judgements. [ml84] this distinction he elaborates further in the lectures on the meaning of the logical constants and the justifications of the logical laws, which he published in 1996, and in a recent lecture on assertions, assertoric contents and propositions6 in 2008. martin-löf’s careful considerations also influenced some of the conceptualisations in epsilontheory (see section 9 below), as it is being studied by the author and his co-workers. 3 realistic conceptions of proposition and judgement at the very beginning of his de interpretatione aristoteles explains his view on the relationship between language, mind and reality, which is essential for the understanding of his conception of judgements: “that what is expressed [logos, in german satz, in english sentence] is a symbol of the states of the soul, and that which is written is a symbol of that which is expressed” [...] “that, of which the states of the soul are images, are the things.” [tw04, p. 19] what is to observe here is that the states of the soul, which may be understood as thoughts in the sense of mental states, mediate between reality on the one side, and sentences being expressed and written on the other. in his conception of the notion of judgement aristoteles takes first of all a linguistic view, but combines it with a psychological and an ontological perspective. he describes a judgement as to being a particular type of sentence: “though a sentence is meant to denote, not every sentence is a judgement but only one in which the assertion of truth or falseness is present. it is, however, not present in every sentence since, for example, a wish is a sentence, but it is neither true nor false.” [ari67b, p. 7] today we would say that he distinguishes different kinds of sentences, a distinction which in speech act theory is made by the distinction of illocutionary forces in the acts of ‘expressing’ by means of sentences. as judgements he singles out assertoric 6see [ml96, pp. 11–60]. his recent thoughts on judgements martin-löf presented in the lecture assertions, assertoric contents and propositions, which he gave at the workshop on judgements, assertions, and propositions the logical semantics and pragmatics of sentences at tu berlin on january 11, 2008. 3 / 20 volume 26 (2010) on judgements and propositions sentences and as the criterion for a sentence to be a judgement he states that the sentence is to be grammatically composed of two parts: a subject and a verb. both parts, in his view, have meaning in the sense that they both denote something by convention. and as the criterion for the truth of a judgement he states that in the composition of subject and verb, the copula “is” or a derived form of it, has to reflect the relation of the things the subject and the verb denote: “to affirm [katáphasis] is to express something towards something, and to deny [apóphasis] is to express something away from something”; and concerning truth and falseness of a judgement made, aristoteles writes: “the one, who thinks as being separated what is separated and as being composed what is composed, thinks true; but he thinks false, whose thoughts are contrary to the things.” [ari67c, p. 7] it is to note here that in aristoteles’ view ‘true’ and ‘false’ are not atomic values, as which they are taken by frege, but qualities of thinking. other than logicians today aristoteles restricts his observations to simple judgements of the subject-predicate form. he does not consider complex judgements, which are composed of sub-judgements and logical connectives. for the meaning of simple judgements he follows a simple variant of the principal of compositionality, which postulates that the meaning of composed expressions is the composition of the meanings of the individual expressions. this principle is attributed to frege who applied it in his functional interpretation of sentences.7 a similar principle has also been stated by leibniz in his ars characteristica [krä88, p. 105]. in aristoteles’ view there are two qualities of judgements, namely affirmation and denial, and “every judgement is either a judgement about what there is in reality, what there is by necessity or what there is by possibility”. aristoteles also distinguishes three kinds of judgement: “a judgement [...] is either general, or particular or undetermined. general means that something applies8 to all or none, particular means that something applies to a single, or to a single not, or not to all, and undetermined means that it applies or does not apply without determination of the general or the particular ...” [ari67a] with the concepts of quantification in modern predicate logic, where sentences have a complex structure, the notions of general and particular have become more precisely formulated. 4 formalisation of categorical judgements today we would rephrase aristoteles’ view on judgements as follows: sentences and their written forms refer to thoughts created in a mental act, and these thoughts as mental states, are images of existing things. truth is assigned to thoughts, in the sense of a mental act, and requires the correspondence between that which is thought and the things of which the thoughts, in the sense of mental states, are images. though thoughts, in aristoteles’ sense, correspond to what in speech act theory is called a propositional act, there is also a major difference: aristoteles does not think of thoughts in terms of reference and predication in the way we do, but he insists in, to say it in modern terms, a type theoretical reading of thoughts. take as an example the sentence “all men are mortal,” which, according to his grammatical criterion for judgements and his classification of kinds, is a general judgement. aristoteles’ reading of this sentence can be 7see for example [fre66, pp. 72–91]. 8the english word ‘applying’ is used here to translate the greek word ‘hyparchein.’ festschrift hjk 4 / 20 eceasst formalised as the type proposition (all men) are (mortal) in which the composition of two things is asserted. this sentence is true if in the real world mortality (which is the thing whose image is symbolised by the written expression ‘mortal’) applies to all humans (which is the thing whose image is symbolised by the written expression ‘all men’). the famous ‘problem of universals’ in the middle ages was about the question if things as expressed by the words ‘all men’ and ‘mortal,’ have existence. since frege, motivated by the concept of a mathematical function in arithmetic and higher analysis, proposed predication as a form of function application, which results truth-values, [fre75, pp. 17–39] and since he introduced individual variables for the indication of individuals in quantification, [fre75, p. 33] today’s conventional reading of the respective sentence9 can be expressed in the formalisation ∀x.(men(x) → mortal(x)). if we write atomic predication in the form of a type proposition [mah93], we get ∀x.(x : men → x : mortal) this type propositional formalisation shows, on the one hand, a closer similarity to the aristotelian view, though the sentence as a whole is not a simple judgement anymore. it has a complex structure. it also shows a close similarity to the truth condition for atomic predications in the tarski-style of model-theoretic semantics, which, in a semiformal style, is phrased as for all h it is true that, if (h ∈ amen) then (h ∈ amortal) where h denotes an unspecified individual in the domain of interpretation, and amen and amortal denote subsets of this domain. it is interesting to note that the model-theoretic truth condition expresses the same idea as the truth condition in aristoteles’ view: “the presence of being there.” the only difference is that the aristotelian truth condition concerns things in reality while in the tarski-style of model-theoretic semantics the condition is expressed, relative to a given domain of interpretation, in terms of set-theoretic membership. it is also interesting to note that the (semantic) reading of ∀x. as “for all h, which instantiate x, it is true that” turns the sentence ∀x.(x : men → x : mortal) into a symbolisation of a proposition in which an h-indexed family, not of propositions, but of judgements is expressed. following the conventional model-theoretic interpretation, the above sentence is also true in a world where humans cannot be found, since in this case for every instantiation of x the premise of the implication is false. this property indicates that the use of variables in quantification resolves the difficulty parmenides saw in the notion of ‘non-existence’: he concluded that negation cannot be thought of because “what is not is not, and can therefore not be.” [par69] in the modern understanding of ‘non-existence,’ instead, non-existence is the property of the domain 9see also russell’s on denoting from 1905, which in german translation appeared as [rus00, pp. 3–22]. 5 / 20 volume 26 (2010) on judgements and propositions of interpretation that the thing with the property in question cannot be found in it, i.e. is not there. the ‘logical’ reading [tw04] of a simple judgement as a complex sentence resolves this difficulty because it reads “existence” as “existence with some property.” but this conception of existence as ‘being there’ has the consequence that, before existence can be asserted, there is always a universe needed to be given, which consists of the things that ‘are there’ and are known to fall into defined categories. in conventional logic this is enforced in the inductive definition of formulas and the set-theoretic structures for the interpretation of formulas. if we read, to use an example of quine, the “existence of unicorns” as the “existence of something which unicorns,” the question comes up of what the nature of this something is. at the linguistic level of conventional logic it is a variable and at the semantic level in the tarski-style interpretation it is possibly any element in the domain of interpretation. but what it is in a reality that can hardly be well-defined as a set, and what it is itself if it cannot be given the ontological status of a real thing but only the status of an intentional object, is even today a rather open question.10 5 brentano’s notion of judgement early conceptions of judgement and proposition with a particular emphasis on their roles in science and logic have been studied by bernhard bolzano in his wissenschaftslehre (1837). bolzano laid the ground for further investigations by brentano and by his students. a thorough account of these investigations can be found in the article austrian theories of judgement: bolzano, brentano, meinong, and husserl by robin d. rollinger. [rol08, pp. 233–261] of particular interest here is brentano’s conception of intentionality. it opened a new perspective on judgements. following searle, intentionality is also constituent to speech acts. [sea04, pp. 5–13] searle therefore develops his theory of intentionality as a foundation for his theory of speech acts. speech act theory11 strongly influenced modern conceptions of the linking of mental acts and symbolic presentations, and is therefore fundamental for intuitionistic approaches to the notions of proposition and judgement. in brentano’s psychology from an empirical standpoint (1874), an act of judging is a case of a mental act. according to his classification, all mental acts are either presentations [in german vorstellung], or judgements or volitions, and all contain an object intentionally within themselves. this can be concluded from the following famous citation: “every mental phenomenon is characterised by what the scholastics of the middle ages called the intentional (or mental) inexistence of an object, and what we might call, though not wholly unambiguously, reference to a content, direction towards an object (which might not to be understood here as meaning a thing), or immanent objectivity. every mental phenomenon includes something as object within itself, although they do not all do so in the same way. in presentation something is presented, in judgement something is affirmed or denied, in love loved, in hate hated, in desire desired and so on. this intentional in-existence is characteristic exclusively of mental phenomena. no physical phenomenon exhibits anything like it. we would, therefore, define mental phenomena by saying that they are phenomena, which contain an object intentionally within 10i consider this a serious question. a somewhat unsatisfactory answer is given in [gro92, pp. 106–119]. grossmann considers intentional relations as abnormal relations because their objects need not to have existence. 11for the history of speech act theory see [smi90, pp. 29–61]. festschrift hjk 6 / 20 eceasst themselves.” [bre95, pp. 88–89] what in a judgement is affirmed or denied is, in brentano’s view, the existence of this object. and so we might say that brentano conceives of a proposition as the ‘existence of the object of a judgement,’ which may be the case or not. brentano’s conception of intentionality has strongly influenced modern philosophy, namely logic, ontology, existential philosophy and theories of language and semantics. he not only claims that every mental act is a presentation or rests on a presentation, but also that a distinction has to be made between the object presented and the content of its presentation. bernhard bolzano was convinced that there are presentations, which, though they have content, have no object, [bol81, §67, pp. 304–306] like the presentation of a golden mountain or the presentation of a round square. this conviction, however, has the consequence that such things cannot be judged to not exist. but this appears to be against our intuition as we can think or even have an imagination of things, which, we know, do not exist, and also can judge that they do not exist. we can think of a round square and even imagine unicorns and a flat earth, and we daily have the presentation of a user-friendly computer system. even further, we seem to need a presentation of something before we can assert it to not exist. this observation, it turns out, touches at a major problem, the question of what exactly we mean by a proposition and by a judgement and how we understand the relation between a judgement and ‘its’ proposition. the disputes in analytic philosophy literature show that even today this problem has not yet found a commonly accepted solution. 6 twardowski’s theory of presentations kasimir twardowski, one of brentano’s students in vienna, addressed this problem in his habilitation thesis on the content and object of presentations a psychological investigation [twa77] in 1894. he studied the concept of presentation (in german vorstellung) and focuses on the observation that presentations imply in what they present to the mind, two different objects rather than one: the object towards which a presentation is directed (in german gegenstand), and the object, which is its content (in german inhalt). though the topic of his thesis is the concept of presentation, he also deals with the notion of judgement (in german urteil) and sees a “perfect analogy” [twa77, p. 7] between presentations and judgements. both, he states, imply an act, both concern something, namely what is presented and what is judged, and in both this something, which is presented or judged, is to be subdivided into object and content, the latter of which he calls the intentional object of the act. while one and the same object can be presented as well as being judged, he finds the distinction between presentation and judgement in the intentional object of the act: “when the object is presented and when it is judged, in both cases there occurs a third thing, besides the mental act and its object, which is, as it were, a sign of the object: its mental ‘picture’ when it is presented and its existence when it is judged.”12 here the ‘object’ of a judgement is the object about which the judgement is made, while the ‘subject’ of a judgement is that what is affirmed or denied, the object’s existence. twardowski insists that “presentation and judgement are two separated classes of mental phenomena without intermediate forms of transition.” [twa77, p. 6] 12see [twa77, p. 7]; the conception of ‘existence’ as the content of a judgement is not obvious. see grossmann’s criticism on this conception in: reinhard grossmann: introduction, in [twa77, pp. vii ivxxx, here pp. ix xi]. 7 / 20 volume 26 (2010) on judgements and propositions the distinction between object and content in what is presented or judged is most natural, though the question of what exactly an object is, about which a judgement can be, still remains unanswered. in the beginning of his treatise on objects in §7 of his investigation twardowski gives a partial answer to it: “according to our view, the object of presentations, of judgements, of feelings, as well as of volitions [in german ‘wollungen’], is something different from the thing as such [in german ‘ding an sich’], if we understand by the latter the unknown cause of what affects our senses. the meaning of the word ‘object’ coincides in this respect with the meaning of the word ‘phenomenon’ or ‘appearance,’ whose cause is either, according to berkeley, god, or, according to the extreme idealists, our own mind, or, according to the moderate ‘realidealists’ the respective things as such. what we have said so far about objects of presentation and what will come to light about them in the following investigations is claimed to hold no matter, which one of the just mentioned viewpoints one may choose. every presentation presents something, no matter whether it exists or not, no matter whether it appears as independent of us in our own imagination; whatever it may be, it is insofar as we have a presentation of it the object of these acts, in contrast to us and our activity of conceiving [in german ‘vorstellenden tätigkeit’].” [twa77, p. 33] and at the end of his treatise on objects he writes: “summarizing what was said, we can describe the object in the following way. everything that is presented through a presentation, that is affirmed or denied through a judgement, that is desired or detested through an emotion [in german ‘gemütsthätigkeit’], we can call an object. objects are either real or not real; they are either possible or impossible objects; they exist or do not exist. what is common to them all is that they are or that they can be the object (not the intentional object!) of mental acts [in german ‘psychischer akte’], that their linguistic designation is the name ..., and that considered as genus [in german ‘gattung’], they form a summum genus, which finds its usual linguistic expression in the word ‘something’ [in german ‘etwas’]. everything which is in the widest sense “something” is called “object,” first of all in regard to a subject, but then also regardless of this relationship.” an important term in this citation is the word “through.” it assigns the mental act and its intentional object the role of a mediator: through the act and content of a presentation an object is presented, and, accordingly, through the acts of affirmation or denial of existence an object is judged. every object, now, existing or not, can be seen to be the object of both, a presentation and a judgement. twardowski’s concept of object of a mental act solves the above mentioned problem of judging non-existing objects to not exist, and bolzano’s belief in presentations, which have no object, turns out to be wrong: “the confusion of the proponents of objectless presentations consists in that they mistook the non-existence of an object for its not being presented.” [twa77, pp. 20–29, here p.22] but despite the fact that the general approach to the objects of a judgement seems to be most reasonable, the ontological status of objects in intentional relations is subject to controversies and not at all free from problems. it is therefore heavily debated in the literature. progress has been made with the invention of ‘states of affairs’ and with the conception that judgements concern states of affairs rather than objects.13 it seems that the invention of states of affairs has two sources: predications on the one hand, as they have been used by frege in his begriffsschrift for the purpose of formalising arithmetic and by peano and russell who applied and developed formal description techniques for other parts of 13see grossmann’s introduction to twardowski in [twa77] and [gro92]. festschrift hjk 8 / 20 eceasst mathematics, and “sachverhalte” on the other, as certain types of (intentional) objects, studied by meinong, husserl and reinach [smi89]. this view is later also found in wittgenstein’s tractatus, the first two sentences of which are: “die welt ist alles, was der fall ist. die welt ist die gesamtheit der tatsachen, nicht der dinge” (“the world is everything that is the case. the world is the total of what is the case, not of the things”).14 7 frege’s conception of proposition and judgement an answer of pragmatic value for the questions of what propositions and judgements are and how they are related seems possible only within a prescriptive deductive or semantic framework15. conventional formal logic makes no clear distinction between the two concepts and avoids their conceptualisation at all. and a dedicated formal theory of propositions and judgements has not yet been proposed. however, there are considerations, which aim at clarification. in his article über sinn und bedeutung (1892) gottlob frege discusses the meaning of verbal expressions, like names, denotations and sentences, and draws the well known distinctions between sign (in german zeichen), sense (in german sinn), reference (in german bedeutung), and presentation (in german vorstellung). “a sign is the expression of some sense and it denotes or references its reference.” [fre75, p. 46] a comparison of this distinction with twardowski’s distinction of names, content and object of a presentation shows many similarities, but also major differences: frege’s sense is not part of a mental state or act. it has objectivity. therefore presentations are not senses and therefore twardowski’s content is not the same as frege’s sense, even though they play similar roles in the designation of an object. and names in twardowski’s conception do not designate matters of affairs but objects. in frege’s conception also sentences have a sense and a reference, and the sense of a sentence is what he calls a thought (in german gedanke). frege’s concept of thought is what husserl and (the early) wittgenstein call matter of affairs [tw04, p. 17], and what russell calls proposition for which he later uses the word assertion.16 if a sign is a sentence, the question is what it references. in frege’s view, a sentence references a truth-value, i.e. the value true or false. accordingly, also truth-values are objects (in german gegenstände). since in twardowski’s habilitation there is no citation of frege’s work, we must conclude that frege’s work was not known in vienna at that time. frege’s conception of proposition was later adopted in formal logic, though in the hidden form of the recursive definition of interpretation and validity, which is derived from frege’s principles of compositionality and truth functionality. in view of its pragmatic language use and meaning, however, frege’s notion of sense has been strongly criticised.17 frege also made an important contribution to the conceptualisation of judgement. what is being affirmed or denied in a judgement is that a proposition is true or false, or in other words, that a matter of affairs is a fact or not. frege thereby frees the concept of judgement from its binding to object-existence. he also draws a clear distinction between proposition and judgement 14see [wit73, p. 11], english translation by the author. 15to a certain degree this is done in martin-löf’s intuitionistic type theory and formalisms following him (see below). see also [hhp93, pp. 143–184]. 16see also [ml96, pp. 11–60], where he gives an account on the development of the concepts of proposition and judgement in the light of his intuitionistic type theory. 17see for example [dum82]. 9 / 20 volume 26 (2010) on judgements and propositions by saying that a judgement is not just the affirmation or denial of a proposition, but that the affirmation or denial is asserted. in his begriffsschrift (1879) frege introduces a notation for assertions, the vertical stroke, which he later combined with the horizontal stroke to indicate assigning truth, and the negated horizontal stroke to indicate falseness. so, for example, the assertion that the earth is flat can then be expressed as ` flat (earth) and the assertion that the earth is not flat can be expressed as ` flat (earth) here the symbol ` is to be read as “it is asserted that it is not the case that,” and not as “it is not asserted that it is the case that” which would be the negation of the assertion. frege’s observation that a judgement is more than just the statement of a true or false proposition, because a statement could also mean an assumption, makes the distinction between different kinds of judgements, as it was customary in the traditional views on judgements, meaningless. if we respect this observation, a judgement is always an affirmation. using truth predicates, written in type propositional form, the above assertions may be read as affirmations of the sentences flat (earth) : true and flat (earth) : false frege gives an impressive insight into his style of writing and the purpose and use of formal notations in mathematics in über die wissenschaftliche berechtigung einer begriffsschrift (1882). he motivates the notation of the judgement stroke`with the pragmatic needs in the writing of formal expressions and in the depiction of logical derivations on a sheet of paper. the question of “how can we write?” becomes prominent and the analysis of “what can we write down?” leads to the new view on judgements. frege uses the judgement stroke in a given context of discourse, the context of a given system of axioms and rules or of a given model or theory. it is this context, which justifies the assertion of truth. 8 martin-löf’s conception of judgement and proposition in his intuitionistic type theory, martin-löf makes the following distinction between proposition and judgement: “here the distinction between proposition (ger. satz) and assertion or judgement (ger. urteil) is essential. what we combine by means of the logical operations (falsum, implication, and, or, for all, there is) and hold to be true are propositions. when we hold a proposition to be true, we make a judgement: ((a : proposition) is true) : judgement “in particular, the premises and the conclusion of a logical inference are judgements. the distinction between proposition and judgement was clear from frege to principia. these notions festschrift hjk 10 / 20 eceasst have later been replaced by the formalistic notions of formula and theorem (in a formal system), respectively. contrary to formulas, propositions are not defined inductively. so to speak, they form an open concept. in standard textbook presentations of first order logic, we can distinguish three quite separate steps: 1. inductive definition of terms and formulas 2. specification of axioms and rules of inference 3. semantical interpretation “formulas and deductions are given meaning only through semantics, which is usually done following tarski and assuming set theory. “what we do here is meant to be closer to ordinary mathematical practice. we will avoid keeping form and meaning (content) apart. instead we will at the same time display certain forms of judgement and inference that are used in mathematical proofs and explain them semantically. thus we make explicit what is usually implicitly taken for granted. when one treats logic as any other branch of mathematics, as in the metamathematical tradition originated by hilbert, such judgements and inferences are only partially and formally represented in the so-called object language, while they are implicitly used, as in any other branch of mathematics, in the so-called metalanguage. “our main aim is to build up a system of formal rules representing in the best possible way informal (mathematical) reasoning.” [ml84, pp. 3–4] in martin-löf’s informal reasoning by means of formal rules judgements are not viewed from a language perspective, as aristoteles did and as we still do today, at least in most of the philosophical and formal logic accounts, but are closer to speech acts in the sense of austin’s “how to do things with words.” martin-löf’s informal reasoning is to be seen as a performing of acts of judging, which consist in the writing down of judgements. the writing down of judgements is justified by the rules of the type system, whose premises are again judgements. some rules, however, have no premises. they are axioms. judgements in martin-löf’s type theory have one of the following written forms: a set, a = b, a∈a, or a = b∈a. the last two of these forms correspond closely to the judgements to be made in cantor’s criterion for a set to be ‘well-defined,’ which he phrased in 1882, with the study of powers, when he refined his notion of a set18: “i call an aggregate (a collection, a set) of elements which belong to any domain of concepts [in german begriffssphäre] well-defined, if it must be regarded as internally determined on the basis of its definition and in consequence of the logical principle of the excluded middle. it must also be internally determined whether any object belonging to the same domain of concepts belongs to the aggregate in question as an element or not, and whether two objects belonging to the set, despite formal differences, are equal to one another or not.” all forms of judgement in martin-löf’s type theory propose a natural set-theoretical interpretation. the given system of rules, however, admits also other readings of these forms. one of these readings corresponds to the well known concept of ‘propositions as types,’ also known as 18the criterion is phrased in a letter by cantor to richard dedekind in 1882; see for example [dau79], cited in english from [dau79, p. 83]. 11 / 20 volume 26 (2010) on judgements and propositions the curry-howard isomorphism, and reads the judgement a ∈ a as “a is a proof for the proposition a.” this reading is not only the basis of his system as an intuitionistic theory of types, but is also consistent with an intuitionistic interpretation of his approach as a whole: from a meta-level perspective the written forms of judgements symbolise propositions for which his system lays down what counts as a proof.19 this is the way how he explains semantically these forms of judgements. concerning propositions martin-löf writes: “classically, a proposition is nothing but a truth value, that is, an element of the set of truth values, whose two elements are the true and the false. because of the difficulties of justifying the rules for forming propositions by means of quantification over infinite domains, when a proposition is understood as a truth value, this explanation is rejected by the intuitionists and replaced by saying that a proposition is defined by laying down what counts as a proof of the proposition, and that a proposition is true if it has a proof, that is, if a proof of it can be given. “thus, intuitionistically, truth is identified with provability, though of course not (because of gödel’s incompleteness theorem) with derivability within any particular formal system.” [ml84, p. 11] the conventional conception of formal logic leaves these notions of proposition and judgement out of its consideration. it treats these notions only implicitly in the recursive definitions of interpretation and avoids their explicit notation. 9 logics with propositional variables also classical propositional and predicate logics can be seen as conceptions of propositions. they provide linguistic means, usually in terms of alphabets and inductive definitions, to write sentences, which through interpretation become either true or false. sentences in propositional logic are built up from propositional variables and propositional connectives like ‘and,’ ‘or,’ ‘not,’ and may be others. the interpretation of propositional sentences is based on a given truth-assignment, which assigns truth-values ‘true’ or ‘false’ to propositional variables, and is defined by induction as an evaluation function, which assigns truth-values to propositional sentences. here the principles of compositionality and truth functionality are maintained in their purest form. the ‘architecture’ of (first order) predicate logic is not much different, except that atomic formulas are not propositional variables but predications and equalities, that variables are object-variables taking values from a given semantic domain, and that expressive power and expressiveness of predicate logic are enriched by the use of function symbols for object description, relation symbols for predications and quantifiers ranging over the elements of the carrier sets of the semantic domain.20 sentences in these logics are complex forms, which express, trough their 19the status of a proof in the intuitionistic conception of truth has been a matter of discussion. see for example [sun94], as well as sundholm’s and prawitz’ debate in the above mentioned volume 64 in theoria. [han98] 20see for example [emc+01, pp. 221–455]. festschrift hjk 12 / 20 eceasst interpretation for a given truth-assignment or in a given semantic domain, sense, to use frege’s terminology. they may also be read as formal statements of matters of affairs, which are implicit in their formal interpretation. but these matters of affairs are usually not made explicit and only hidden in the recursive interpretation of sentences. the processes of interpretation then only yield truth-values, and equivalence at the object-level can only be expressed in terms of ‘having the same truth-value,’ rather than ‘stating the same matter of affairs.’ this is, how classical logic with a strict separation of syntax and semantics avoids the notions of proposition, and how it treats judgements only implicitly in its definition of the interpretation process relative to a given truth-assignment and semantic domain. there is a particular logic to explicitly express truth of propositions, quantification over propositional variables and propositional equivalence, which has been developed by werner sträter in [str92] and is called ∈t -logic. one of the motivations for its design was to avoid partial truth predicates and to admit formulations like the liar paradox x ≡ x : false to be treated as contradictions. ∈t -logic grew out of an extensional interpretation of types,21 which reads a type proposition e : t as a statement of membership [[e]] ∈ [[t ]] the type proposition ϕ : true would then be read as a statement of membership with [[ϕ]] denoting a proposition and [[true]] a set of true propositions. ∈t -logic is equipped with propositional constants, variables and connectives, quantification over propositional variables, truth predicates and propositional equivalence. its semantics is defined in the tarski-style, where the semantic domain is a domain of propositions and the interpretation function ensures the natural properties of propositional and of first order logic, as far as they apply. it fulfils the well known tarski biconditionals in the sense that the sentence ∀x.(x : true ↔ x) : true is universally true. ∈t -logic has an impredicative nature and allows for intensional semantics of its sentences. extensions of this logic have been defined and studied by philipp zeitz [zei00], who introduced parameterization, by sebastian bab [bab07], who extended ∈t -logic by modal operators, and by steffen lewitzka [lew09], who studied an intuitionistic variant of ∈t -logic. also frege defines in his begriffsschrift22 a logic with propositional variables. frege’s notations admit the reference to objects and to functions over objects, as well as to functions over functions. they allow for propositional variables ranging over truth-values, which are viewed as being objects like any other object, they admit to write operators, which cover the classical 21see [msu90] and [mah93]. 22see also [her83, pp. ix–xv]. 13 / 20 volume 26 (2010) on judgements and propositions propositional connectives, and they include propositional equality and quantification. the expressiveness of frege’s logic is closely related to a certain instance of parameterized ∈t -logic in the sense of zeitz. however, there is no perfect analogy. the major difference is in the use of quantification, and in the style of semantics. intuitively, there is good reason to also view classical logics as theories of propositions, no matter if in these logics propositions form a distinct and well defined category of entities to be dealt with or not. this is obvious in the case of logics, which admit propositional variables, and it is even more obvious for ∈t -logic and its extensions, which explicitly support propositional quantification and equivalence, and assume propositions as elements of their semantic domains. can the same be said for judgements? classical logics introduce notations for judgements at their meta-level, usually in the form of a sign denoting validity of a sentence under a given interpretation, like for example the validity of ϕ under the truth-assignment b b |= ϕ but they do this in a rather propositional manner, as they also allow to denoting invalidity. b 6|= ϕ they treat judgements as propositions at the meta-level. otherwise there is little difference between these signs and frege’s judgement stroke. frege’s notation is based on the assumption of a given model so that there is no need to indicate the truth assignment or the semantic domain of interpretation. and also the fact that the judgement stroke is written at the object-level of formalisation is not of much relevance, since it is used at this level not as an operator but as an indicator and, in addition, only at the outermost position of the two-dimensional expressions. the judgement stroke can be omitted but it cannot be negated. negation of the judgement stroke would turn it into a propositional operator. this, by the way is the reason why the expression ϕ : true in ∈t -logic cannot reasonably be interpreted as a judgement. the judgement stroke is not subject to interpretation but is a sign, which has a purely pragmatic meaning. it indicates what is an answer to the question “what can i write?” 10 summary to turn to the question of how the notions of judgement and proposition discussed do relate to each other we try to answer the following questions: 1. is there a distinction made between assertion and judgement? 2. is there a distinction made between proposition and judgement? 3. what is that which is expressed by a judgement? 4. how is a judgement justified? 1. in his intuitionistic type theory martin-löf speaks of judgements rather than assertions, and in his recent lecture on assertions, assertoric contents and propositions, [ml08] he speaks of assertions rather than judgements. not fully conform to other festschrift hjk 14 / 20 eceasst naming conventions he uses the term assertion to denote the verbal expression of a judgement, in the form of a spoken or written sentence, and with the use of some language or notational convention. but, as he argues, the interchangeable use of the terms judgement and assertion is justified since in logic both depend on rules, the focus of his interest, and rules are the same for both. following the assumption that assertions are verbal expressions, judgements may be seen as the mental counterparts of assertions. but this view can hardly be maintained since also assertions include an act of judging. aristoteles avoids this problem by distinguishing between mental states on the one side, which stand in an image-relation to the things, and judgements as symbolisations of these states on the other. he assumes, at least implicitly, that there are two acts: the act of thinking, which, as he says, can be true or false, in the sense of right or wrong, and the act of symbolising, which produces a sentence or its written symbolisation. brentano and twardowski discuss judgements solely at the level of mental acts. written forms are out of their interest. in their understanding contents are in the mind while objects are embedded in an intentional relation. the ontological status of objects, however, remains somewhat unclear23. they may be real or mental objects, like thoughts, and may exist or not. frege’s thoughts, instead, are explicitly thought of as being independent from some mind, as they have objectivity and can be shared by several subjects. in ∈t -logic the distinction between judgement and assertion is mostly irrelevant, like in most formal logics with a set-theoretic tarski-style of semantics. sets in a set-theoretic universe of interpretation have the same ontological status as thoughts in the sense of frege. [gro92, pp. 106–119] they are the means by which, through the application of rules of interpretation, sense and reference, in the sense of frege, are being determined as elements of the given universe. 2. not in all the conceptions discussed a distinction between proposition and judgement is being made. in aristoteles’ conception there is an act of thinking, which has all the ingredients of an act of judging, while the forms of sentences, which are called judgements, may be understood as the grammatical forms of propositions, and the mental states to which they refer, may be understood as propositions, which can be true or false. in brentano’s and twardowski’s conception of judgement the concept of proposition is not explicitly named. what a judgement is about is an object and not necessarily something which is true or false, but something which exists or not. only if we read the content of a judgement, which is the existence of the object the judgement is about, as a kind of proposition, we find a conception of proposition with the familiar relation between propositions and judgements. separated from the object to which the judgement refers, is its presentation on which the judgement relies and whose content is a mental image. if the objects of judgements are matters of affairs, [gro92] rather than objects of some other kind, brentano’s and twardowski’s conception of judgement includes much of the conception of judgement we use today. but still then there are major differences to freges conception. frege’s sense has objectivity, while contents of judgements, in brentano’s and twardowski’s sense, are mental images and are therefore of subjective nature. freges sense is a thought, which objectively represents a matter of affairs, but what a judgement refers to is not this matter of affair but a truth-value. the two approaches would be easier to compare, if we could distinguish between that which a judgement is about and that what the sentence expressing the judgement refers to. a judgement would then be about a matter of affairs (frege’s sense and brentano’s and 23see the introduction to [twa77]. 15 / 20 volume 26 (2010) on judgements and propositions twardowski’s content of the presentation underlying the judgement) and refer to a truth-value (frege’s reference and brentano’s and twardowski’s intentional object). this distinction would be rather natural because of matters of affairs it can meaningfully be said that they exist or not, depending on whether they are facts or not, and this distinction would also be closer to what wittgenstein proposes in his tractatus logico philosophicus, [wit73] but it would not be fully consistent with frege’s and brentano’s and twardowski’s original conceptions. in his intuitionistic type theory martin-löf draws a clear distinction between propositions and judgements and gives formal rules for the formation of judgements. in ∈t -logic, however, the notion of judgement remains only implicit, like in other conventional logics. while the elements of the domain of interpretation are explicitly assumed to be propositions, whatever form they have, the notion of judgement, in the sense of martin-löf, is in ∈t -logic only present at the meta-level and not part of the ‘object language.’ it appears that the notion of judgement, other than the notion of proposition, is not fully semantic in its nature, but has also a substantial pragmatic aspect. this pragmatic aspect is that what frege expresses in his judgement stroke and what speech act theory identified as the illocutionary role or force of an assertoric act: the beholding of truth. despite the truth predicates in ∈t -logic and the fact that it obeys the tarski biconditionals, the beholding of truth is not a feature of the language but an element of its use and as such a consequence of the choice of the universe of interpretation. in martin-löf’s intuitionistic type theory this pragmatic aspect, at least in part, belongs to the ‘object language,’ which gives it the pragmatic flavour, expressed in the question “what can i write?” 3. one can generally say that that which is expressed in a judgement is the truth of some form of predication. this is obvious in aristoteles’ conception and in his choice of sentences, which have the valid form of a ‘judgement,’ and also, at least formally, in frege’s conception of a concept (in german begriff ) as a function whose application results a truth-value. in brentano’s conception that which is expressed in a judgement is the existence or non-existence of an object, which in twardowski’s setting is the judgements content. existence of an object, however, can only be seen as a form of predication if the object can be represented as a matter of affairs. the situation in martin-löf’s intuitionistic type theory is different. that what is expressed in a judgement is the provability of a proposition, or, in a different reading, the membership in a set. there is no notion of truth but at the level of judgements in the correctness of the application of the rules. in what is expressed in a judgement, ∈t -logic is not different to conventional formal logics, with the difference that the predications of truth and falseness differ slightly in their form. 4. if we ask, what justifies a judgement, major differences can be found. in aristoteles’ naturalistic conception justification comes objectively from the things and concerns the question of connectedness. truth applies to thoughts as mental states and depends on a proper correspondence to the reality of things. in brentano’s conception justification has an epistemic nature and is obtained either from deductions or from inductive proofs. a different view is taken by frege who sees the justification of a judgement to rest on necessity, which, according to him, corresponds to deduction, or empirical intuition. but truth, in his conception, is found through judgements, a conception, which gives the judgement stroke not only a pragmatic aspect but, other than it appeared at first, turns it at the same time into a constituent of semantics. despite similarities in the role of judgements, frege’s view differs in this respect from the conception of martin-löf, who sees the basis for justification in the system of rules and not in the beholding of truth. the judgement stroke in his conception is part of pragmatics and not of semantics. in festschrift hjk 16 / 20 eceasst a tarski-style of semantics, as it is applied in ∈t -logic and other conventional logics, the justification comes from the choice of the semantic domain in the interpretation and from the correct application of the interpretation rules. this is not much different to frege’s view, since the choice of the semantic domain of interpretation is also a judgement, and therefore not fully free from subjective influence but other than in frege’s conception, it avoids, so to say, the responsibility for this choice to be part of the interpretation. in the view of ∈t -logic and other conventional logics, truth and the conditions for the justification of judgements can be said to be defined. they are only found in a defined context. acknowledgements: this paper is devoted to hans-jörg kreowski on the occasion of his 60th birthday. with hans-jörg i shared an office from the mid seventies to the beginning of the eighties at the automata and formal languages group at tu berlin. what remained from these times is a feeling of friendship and trust. i thank andrea hillenbrand and sebastian bab for discussions and for their support. bibliography [ari67a] aristoteles. analytica priora, i 27. 43 a 25. in adolf trendelenburg, elemente der aristotelischen logik griechisch und deutsch, p. 11 (translation by the author). rowohlt, 1967. [ari67b] aristoteles. de interpretatione, 4.17 a i. in adolf trendelenburg, elemente der aristotelischen logik griechisch und deutsch, p. 7 (translation by the author). rowohlt, 1967. [ari67c] aristoteles. metaphysica, ix 10. 1051 b 3. in adolf trendelenburg, elemente der aristotelischen logik griechisch und deutsch, p. 7 (translation by the author). rowohlt, 1967. [aus02] j. l. austin. zur theorie der sprechakte (how to do things with words). reclam stuttgart, 2002. [bab07] s. bab. ∈µ -logik – eine theorie propositionaler logiken. shaker verlag aachen, 2007. [ber92] j. berg. ontology without ultrafilters and possible worlds an examination of bolzano’s ontology. academia sankt augustin, 1992. [bol81] b. bolzano. wissenschaftslehre, band 1 4. scientia verlag aalen, 1981. [boo58] g. boole. investigation of the laws of thought on which are founded the mathematical theories of logic and probabilities. dover new york, 1958. [bre95] f. brentano. psychology from an empirical standpoint, edited by linda l. mcalister. routledge london, 1995. 17 / 20 volume 26 (2010) on judgements and propositions [bre08] f. brentano. psychologie vom empirischen standpunkte von der klassifikation psychischer phänomene. ontos verlag heusenstamm, 2008. [dau79] j. w. dauben. georg cantor. his mathematics and philosophy of the infinite. princeton university press, 1979. [dum82] m. dummett. wahrheit. reclam stuttgart, 1982. [emc+01] h. ehrig, b. mahr, f. cornelius, m. große-rhode, p. zeitz. mathematischstrukturelle grundlagen der informatik. springer berlin/heidelberg, 2nd edition, 2001. [fre66] g. frege. gottlob frege logische untersuchungen. in patzig (ed.), logische untersuchungen gedankengefüge. pp. 72–91. vandenhoeck und ruprecht göttingen, 1966. [fre75] g. frege. funktion und begriff. in patzig (ed.), funktion, begriff, bedeutung. vandenhoeck und ruprecht göttingen, 1975. [fre07] g. frege. begriffsschrift, eine der arithmetischen nachgebildete formelsprache des reinen denkens. in begriffsschrift und andere aufsätze. georg olms verlag hildesheim, 2007. [gro92] r. grossmann. the existence of the world an introduction to ontology. routledge london, 1992. [han98] s. o. hansson (ed.). theoria a swedish journal of philosophy. volume 64, issues 2–3. wiley interscience, 1998. [her83] h. hermes. zur begriffschrift und zur begründung der arithmetik. in gottlob frege: nachgelassene schriften. meiner verlag hamburg, 1983. [hhp93] r. harper, f. honsel, g. plotkin. a framework for defining logics. journal of the acm 40(1), 1993. [hus93] e. husserl. logische untersuchungen. max niemeyer verlag tübingen, 1993. [kan90] i. kant. kritik der urteilskraft. meiner hamburg, 1990. [krä88] s. krämer. symbolische maschinen die idee der formalisierung in geschichtlichem abriß. wissenschaftliche buchgemeinschaft darmstadt, 1988. [lew09] s. lewitzka. ∈i : an intuitionistic logic without fregean axiom and with predicates for truth and falsity. to appear, 2009. [mah93] b. mahr. applications of type theory. in proceedings of the international joint conference caap/fase on theory and practice of software development. pp. 343–355. springer verlag, 1993. festschrift hjk 18 / 20 eceasst [mah97] b. mahr. gegenstand und kontext eine theorie der auffassung. in k. eyferth and b. mahr and r. posner and f. wysotzki (eds.): prinzipien der kontextualisierung. pp. 101–119. kit report 141, technische universität berlin, 1997. [mah09] b. mahr. die informatik und die logik der modelle, informatik spektrum. volume 32(3), pp. 228–249. springer verlag heidelberg, 2009. [mah10] b. mahr. intentionality and modelling of conception. in bab and robering (eds.), judgements and propositions, logische philosophie bd. 21. logos verlag berlin, 2010. [ml84] p. martin-löf. intuitionistic type theory. bibliopolis napoli, 1984. [ml96] p. martin-löf. on he meaning of the logical constants and the justifications of the logical laws, nordic journal of philosophical logic, volume 1, no. 1. scandinavian university press, 1996. [ml08] p. martin-löf. workshop on judgements, assertions, and propositions the logical semantics and pragmatics of sentences at tu berlin. january 11, 2008. [mei02] a. meinong. über annahmen. johann ambrosius barth leipzig, 1902. [msu90] b. mahr, w. sträter, c. umbach. fundamentals of a theory of types and declarations. forschungsbericht, kit-report 82, technische universität berlin, 1990. [voq80] w. van orman quine. wort und gegenstand. reclam stuttgart, 1980. [par69] parmenides. vom wesen des seienden die fragmente. suhrkamp frankfurt a. m., 1969. [rol08] r. d. rollinger. austrian phenomenology: brentano, husserl, meinong, and others on mind and object. ontos frankfurt, 2008. [rus92] b. russell. theory of knowledge the 1913 manuscript. routledge london, 1992. [rus00] b. russell. über das kennzeichnen. in philosophische und politische aufsätze. reclam stuttgart, 2000. [sea04] j. r. searle. intentionality an essay in the philosophy of mind. cambridge university press, 2004. [sea08] j. r. searle. sprechakte ein sprachphilosophischer essay. suhrkamp frankfurt a. m., 2008. [smi89] b. smith. logic and the sachverhalt. the monist 72(1):52–69, jan. 1989. [smi90] b. smith. towards a history of speech act theory. 1990. [str92] w. sträter. ∈t eine logik erster stufe mit selbstreferenz und totalem wahrheitsprädikat. kit-report 98, 1992. dissertation, technische universität berlin. 19 / 20 volume 26 (2010) on judgements and propositions [sun94] g. sundholm. existence, proof and truth-making: a perspective on the intuitionistic conception of truth. topoi 13:117–126, 1994. [tug03] e. tugendhat. ti kata tinos eine untersuchung zu struktur und ursprung aristotelischer grundbegriffe. alber symposion freiburg/münchen, 4th edition, 2003. [tw04] e. tugendhat, u. wolf. logisch-semantische propädeutik. reclam stuttgart, 2004. [twa77] k. twardowski. on the content and object of presentations a psychological investigation. the hague: martinus nijhoff, 1977. translated and introduced by r. grossmann. [twa82] k. twardowski. zur lehre vom inhalt und gegenstand der vorstellungen eine psychologische untersuchung. philosophia verlag münchen/wien, 1982. [wie09] t. wieczorek. on foundational frames for formal modelling. sets, ε -sets and a model of conception. shaker verlag aachen, dissertation, tu berlin (dezember 2008), 2009. [wit67] l. wittgenstein. philosophische untersuchungen (philosophical investigations). suhrkamp frankfurt a. m., 1967. [wit73] l. wittgenstein. tractatus logico philosophicus. suhrkamp frankfurt a. m., 1973. [wr62] a. n. whitehead, b. russell. principia mathematica. cambridge university press, 1962. [zei00] p. zeitz. parametrisierte ∈t -logik: eine theorie der erweiterung abstrakter logiken um die konzepte wahrheit, referenz und klassische negation. logos verlag berlin, 2000. dissertation, technische universität berlin, 1999. festschrift hjk 20 / 20 introduction the notions of judgement and proposition in brief realistic conceptions of proposition and judgement formalisation of categorical judgements brentano's notion of judgement twardowski's theory of presentations frege's conception of proposition and judgement martin-löf's conception of judgement and proposition logics with propositional variables summary volatile sets: event-driven collections for mobile ad-hoc applications electronic communications of the easst volume 43 (2011) proceedings of the 4th international discotec workshop on context-aware adaptation mechanisms for pervasive and ubiquitous services (campus 2011) volatile sets: event-driven collections for mobile ad-hoc applications dries harnie, elisa gonzalez boix, andoni lombide carreton, christophe scholliers and wolfgang de meuter 12 pages guest editors: gabriel hermosillo, russel nzekwa, michael wagner managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst volatile sets: event-driven collections for mobile ad-hoc applications dries harnie∗, elisa gonzalez boix∗, andoni lombide carreton†, christophe scholliers† and wolfgang de meuter {dharnie,egonzale,alombide,cfscholl,wdmeuter}@vub.ac.be software languages lab vrije universiteit brussel, brussels, belgium abstract: in mobile peer-to-peer applications, a common pattern is to maintain a collection of remotely-hosted objects. traditional approaches require programmers to manually track the connectivity state of these remote objects and add them or remove them from local collections on a per-object basis. because this happens concurrently with the rest of the application code, it hinders the composability of such collections and leads to subtle and hard to find bugs. in this paper, we propose an abstraction called volatile sets that allows the contents of the set to be specified intensionally. additionally, volatile sets offer an event-driven api that signals when remote objects appear, disappear or change. finally, volatile sets can be easily and efficiently composed through traditional set operations. we show how volatile sets ease the development of a collaborative peer-to-peer drawing application. keywords: mobile applications, ambient-oriented programming, distributed collections, language abstractions 1 introduction in recent years we have witnessed a tremendous growth in the number of mobile applications that are being developed. in a keynote at the mobile world congress 2011 eric schmidt announced that the android market has reached 150,000 applications, a threefold growth over the previous year. this growth is driven by the recent advances in wireless technologies and miniaturization of hardware such as increased battery life, more computational power, near field communication (nfc). this paper focuses on developing applications that run on wirelessly interconnected mobile devices. such mobile applications are decentralized by nature and allow the user to communicate and interact with nearby users or devices in their surrounding in an without relying on central infrastructure. the structure of mobile ad hoc applications is very similar to traditional distributed applications: first the application seeks out interesting remote objects to include into the interaction (discovery), then it participates in the interaction itself (maintenance), and finally at a certain moment in time the interaction is stopped and the references to the remote objects are removed from the application’s data structures (garbage collecting). these phases, discovery, mainte∗ funded by the prospective research for brussels program of iwoib-irsib. † funded by a doctoral scholarship of the iwt-flanders, belgium. 1 / 12 volume 43 (2011) mailto:dharnie@vub.ac.be mailto:egonzale@vub.ac.be mailto:alombide@vub.ac.be mailto:cfscholl@vub.ac.be mailto:wdmeuter@vub.ac.be volatile sets: event-driven collections for mobile ad-hoc applications nance and garbage collecting, look very sequential in nature, but they actually run concurrently. most mobile ad hoc network programming middleware provide the programmer with a means to discover objects in the environment. due to the nature of the discovery process, objects are discovered and reported back to the programmer one by one. the programmer will then add each newly discovered object to the application data structures. because this discovery process runs concurrently with the main program, new objects can be added at any time. at the same time, already discovered objects can get disconnected at any time, because the devices that host them can move out of communication range. during the implementation of a number of mobile ad hoc applications, such as flikken [sgdd10] and urbiflock [gls+11], we found ourselves writing recurring code to keep these collections synchronized with context changes in the environment such as disconnections of devices, changes on the properties of the discovered objects, etc. additionally, interactions with one communication partner run concurrently with the garbage collecting of other remote objects. needless to say the concurrent nature of these applications has a huge impact on the application. these issues open up a class of bugs that are hard to reproduce and hard to find. they form the main motivation to explore data structures that represent collections of remote (volatile) objects to allow programmers to abstract from such complexities when writing mobile ad hoc applications. in this paper, we propose volatile sets: an event-driven data structure to maintain an intensionally defined set of objects in the environment, keeps track of changes in these objects, and can be composed with other volatile sets using the standard mathematical set operations. interested remote parties can be notified whenever changes occur to the volatile set or to the individual objects they contain. in the rest of this paper, we will show the problems that led us to explore volatile sets (section 2), how the volatile set abstraction tackles these problems at a high level, and how programmers can use volatile sets to quickly develop mobile applications (section 3). we will explain how volatile sets are implemented (section 4), show a discussion of related work and how we intend to improve volatile sets in the future (section 5). 2 problem statement in mobile ad hoc networks, the number of devices participating in an interaction is not known a priori, but it varies as devices join and leave the network as they move about. typically, applications are interested in communicating only with a specific group of those proximate objects which are discovered at runtime. for example, in a chat application, users can join or leave a chat room at any moment in time. in order to reflect the communication state of the users in the chat room and to allow communication with them, the programmer has to manually maintain a collection of remote objects. such a collection of remote objects that is continuously fluctuating because of the volatile nature of the connections to the devices hosting these objects is what we call a volatile set. at the software level, we have identified two ad hoc ways commonly used to implement volatile sets. a first approach when using an object-oriented distributed programming language is to discover and store the remote objects in an internal data structure. once discovered the programmer must manually iterate over references to these remote objects to communicate with proc. campus 2011 2 / 12 eceasst them by means of remote method invocations or asynchronous message passing. all over the program it is the programmer’s responsibility to make sure that these objects are still connected by making use of try-catch blocks or other failure handling. a second strategy is to use an event-based distributed system such as a publish/subscribe architecture. in this case, volatile sets become groups of objects classified under a topic (topic-based publish/subscribe) and potentially filtered on their content (content-based publish/subscribe) using predicates [efga03]. although this allows subscribing to the appearance and modification of interesting objects intensionally, objects are detached from their publishers: if a publisher goes offline its objects still remain in the network. this obliges programmers to bypass the publish/subscribe middleware periodically to detect whether the publishers are still connected and verify that their published objects are still “live” (i.e. in case of a crash). additionally, the events signaled by the publish/subscribe middleware must still be manually converted to additions and removals on local collections. this hinders straightforward and efficient composition of such volatile sets. as such, both solutions do not deal with the many issues that arise when maintaining and communicating with a collection of volatile objects. in what follows, we detail these issues. p1. time-varying, volatile collections. in a decentralized peer-to-peer setting, applications need to first discover other applications and services running in the environment to interact with them. a natural approach to dealing with this problem is to maintain a set of “currently available” objects in which the application is interested. because devices can appear and disappear at any moment in time, we regard a set of such objects as highly volatile. therefore, specifying the contents of the set extensionally (i.e. on a per-element basis) is problematic as the contents of the set can change at any point in time. a second part of this problem is not the specification of the collections, but the interaction with these collections. to interact with these collections, the programmer must use constructs such as indexes, iterators, associations, etc. these constructs exhibit undefined behavior if the collection changes underneath them and thus do not map well to time-varying, volatile collections. p2. composition of volatile collections. a natural operation on collections of objects is to compose them with other, similar collections, using the standard set operators (union, intersection, difference). composing volatile collections is not an atomic action: volatile sets can grow or shrink several times while their union or intersection is being computed. additionally, as the constituent collections evolve, the composed collection diverges from “the union of these two collections”. this means that programmers have to write additional code to ensure the composed collection remains synchronized with its constituent collections. it also implies that compositions of volatile collections are themselves volatile. this requirement is a serious deviation from the traditional notion of composing collections, where a composed collection does not bear any relationship to its constituents. p3. synchronizing state replicated across several devices. objects residing in a volatile collection are local copies of objects published by a remote device. whenever the owner changes an object, the changes should be synchronized to all the copies spread across the network. this 3 / 12 volume 43 (2011) volatile sets: event-driven collections for mobile ad-hoc applications can be accomplished through a publish/subscribe framework. for example, a user changing her nickname in a chat application should be represented in the other chat applications. volatile collections take this one step further: some changes made to an object can result in it being removed from or added to volatile sets with certain predicates. for example, in a chat application, a user that decides to move to another chat room will change the “current chat room” property. this change will cause some volatile collections to remove her user object from the old chat room, while other collections will add her to the new chat room. thus, remote parties defining a volatile set should have a means to subscribe to changes on properties of already-published objects. programmers find themselves implementing an abstraction to express these volatile collections over and over. in the next section, we introduce a novel abstraction representing such volatile collections named volatile sets which solve the issues outlined above. 3 volatile sets in this section, we explain volatile sets and how they address the problems when maintaining and composing groups of volatile objects. we solve problem p1 by allowing developers to specify an intensional definition of the objects they want to interact with, together with an eventdriven api that signals events whenever an object is added to or removed from the volatile set. composing volatile sets (p2) does not require breaking the abstraction of the sets by looking at their contents at a certain moment in time, but instead can happen using mathematical set operations (intersection, union, difference) that rely only on the intensional definition of these sets. finally, the event-driven api allows these volatile sets to signal modifications that are performed to the elements they contain (p3). we have prototyped volatile sets in the distributed programming language ambienttalk [vmg+07]. the rest of this section describes how each problem is solved by illustrating volatile sets in the context of a concrete application called wescribble. 3.1 the wescribble application in this section we describe how volatile sets are used in the implementation of a collaborative drawing application for the android platform, called wescribble1. the application allows users to dynamically participate in a drawing session with other people nearby, assuming no other infrastructure than mobile android devices and wireless ad hoc connections between these devices. at startup, wescribble presents the user with a list of drawing sessions available in the environment with an indication of the amount of people drawing in each session. the user can then join an existing session or create a new one. a drawing session consists of a number of participants and a shared canvas on which they can draw. when a user joins a drawing session, the application synchronizes the canvas with the existing participants to fetch the drawing elements already drawn and displays them on the screen. then, the user can draw on the canvas of that session. those changes on the canvas are propagated to the other participants of the session who 1 wescribble is available from the android market at http://bit.ly/eoxplg. proc. campus 2011 4 / 12 http://bit.ly/eoxplg eceasst update their canvas accordingly. if a user temporarily disconnects from the network, he or she can keep drawing and those changes will be synchronized with the other users in the session upon reconnection. figure 1: the wescribble application for android. wescribble uses volatile sets for two different purposes: first, a session consists of a volatile set that contains the shapes drawn by users. whenever a user adds a new shape to a session, it will be added to the other participants’ volatile sets and be shown on their screens. the eventdriven interface makes it easy for the wescribble programmer to handle changes published by other people. at the same time, the fact that volatile sets are also plain collections makes both the initial synchronization process and merging after a disconnection relatively painless. 3.2 volatile sets at work in this section we explain how volatile sets tackle the problems listed in the previous section in the implementation of wescribble. s1. intensionally defined volatile collections volatile sets allow developers to discover specific remote objects based on custom criteria. these criteria come in two granularities: objects can be annotated with type tags to coarsely select objects related to the application and predicates to select objects on an individual basis. type tags are a lightweight classification mechanism to categorise remote objects explicitly by means of a nominal type. they can best be compared to a topic in publish/subscribe terminology or marker interfaces in java. programmers can use both type tags and predicates to give an intensional definition of a volatile set. wescribble uses volatile sets to collect all the shapes that belong to a drawing session in which the user is currently participating: 5 / 12 volume 43 (2011) volatile sets: event-driven collections for mobile ad-hoc applications def currentsessionshapes := volatilesetof: shape where: { |s| s.session == mysession }; volatilesetof:where: creates a set of objects tagged with the type tag shape for which the predicate is true. whenever a shape object is discovered in the network, the predicate is first applied to it and if it returns true the shape is added to the volatile set. the predicate given is executed locally and can be arbitrarily complex. this solves one part of problem p1, namely selecting specific objects that meet certain criteria from the ambient. note that a volatile set abstracts the contents of the collection by presenting the set as an opaque data structure. however, sometimes (e.g. for debugging purposes) the current contents of such a volatile set need to be accessed. in this case, developers can take a peek at the contents of the volatile set at a certain moment in time by means of the snapshot() method. to solve the second part of p1 (event-driven notification of changes to the set), we provide developers with a means to react whenever the volatile set changes by registering a listener. the wescribble application registers such a listener to render new drawings on the screen as follows: def listener := object: { def elementadded(shape) { gui.show(shape) }; def elementremoved(shape) { gui.hide(shape) }; }; currentsessionshapes.addlistener(listener); here we assume the existence of a gui object that knows how to render the individual elements in the volatile set, currentsessionshapes. the elementadded method will be invoked whenever an object is discovered that satisfies the intensional definition of the currentsessionshapes volatile set. the elementremoved method will be invoked whenever one of the objects in the set is removed. in general, this can happen due to two different reasons: either the device hosting the removed object disconnected from the network, or the device hosting the object performed some changes on the object such that it no longer satisfies the intensional definition of the volatile set. in wescribble, elementremoved is called when a participant disconnects from the drawing session either due to a network disconnection or because he leaves this drawing session to join another one. this solves the second part the problem p1. s2. composition of event-driven collections as mentioned earlier, one of the problems arising with volatile data structures is that their volatility makes them hard to compose in meaningful structures, because it requires accessing the individual elements of the set. volatile sets provide mathematical set operators to compose volatile sets. the volatile and event-driven nature of volatile sets is at the heart of these set operators. in wescribble, for example, organizing all drawn shapes in a single volatile set makes it difficult to track which user is drawing what. to cater for this issue, wescribble organizes all drawn shapes in volatile sets dedicated to a single user in the session. these volatile sets are specified as follows: def getshapesofuser(user) { volatilesetof: shape where: { |s| s.user == user } }; in the application’s gui, the user can tick other users in a list to choose from whom he wants to display drawings. in response, the user’s screen displays the contents of the volatile set that is proc. campus 2011 6 / 12 eceasst the union of all shapes of all users that the user ticked in the gui. this volatile set is composed using the union: operator as shown below. def unionedset := volatileset.new(); tickedusers.each: { |user| unionedset := unionedset.union: getshapesofuser(user); }; important to note is that the union: operator never requires the programmer to deal with individual set elements, nor does it require applying all the predicates in the intensional definitions of the constituting volatile sets to every single discovered or changed object. instead, it extracts the intensional definitions of the unioned sets and constructs a composed intensional definition for the unioned set, that is applied as a whole to newly discovered or changed objects. s3. synchronizing state replicated across several devices in drawing editors, users can change properties of shapes after creation e.g. color, size, position. those changes are a good example of local changes that need to be synchronized with remote parties. to capture changes to objects belonging to a volatile set, we require developers to publish objects in the network as synchronizing isolates. synchronizing isolates are special objects that have no surrounding lexical scope (i.e. similar to structs, but they can have methods defined on them). this way, they can be easily copied over the network and cached in the volatile sets of subscribed remote peers. this design allows developers to model elements of a volatile set in an object-oriented fashion while the underlying implementation implicitly synchronizes state across the different devices using the volatile set. although every device hosting a volatile set has the illusion that it stores a local copy of the elements in the collection, elements can only be modified by their owner: the device that created them and published them to the network. finally, they allow listeners to be registered on them, such that whenever the original host of a synchronizing isolate modifies it, all parties hosting a copy of this synchronizing isolate are notified and their corresponding listeners are invoked. these notifications are signaled through reliable, asynchronous messages to make sure that intermittent network connectivity does not cause missed updates. below is an example of a rectangle synchronizing isolate that can be used by the wescribble application. def rectangle := syncisolate: { def type := ‘rectangle; def color := ‘blue; def p1 := point.new(10, 10); def p2 := point.new(80, 80); def drawon(canvas) { // draw the rectangle on canvas }; }; publish: rectangle as: shape; the above rectangle can be discovered by a volatile set that collects shape objects. running wescribble applications can redraw such rectangles or other shapes whenever they change (i.e. whenever any of their fields are mutated) by registering a listener that listens for changes to these synchronizing isolate objects in the volatile set, as shown below: 7 / 12 volume 43 (2011) volatile sets: event-driven collections for mobile ad-hoc applications def changelistener := object: { def elementchanged(old, changed) { gui.canvas.remove(old); changed.drawon(gui.canvas); }; }; currentsessionshapes.addlistener(changelistener); here we create a changelistener listener object of which the elementchanged() method is invoked every time an element of the volatile set changes. synchronizing isolates thus solve problem p3. we already briefly hinted how synchronizing isolates are published and discovered and how modifications performed by the publisher are signaled to subscribed parties. in the section below, we further elaborate on the implementation of volatile sets and synchronizing isolates . 4 implementation in this section we will explain how volatile sets are organized internally. as previously mentioned, we have prototyped volatile sets in the distributed object-oriented programming language ambienttalk. they have been built on top of the discovery and communication mechanism already present in ambienttalk. it is possible to implement volatile sets in another language with object discovery and asynchronous communication like java, but the complexity of the implementation is greatly increased. in ambienttalk, applications publish objects to the environment using type tags. other applications can discover these objects by using the type tag. ambienttalk objects are classless and come in two variants: objects and isolates. whenever an object is discovered, the application receives a remote reference to it. any message sent to a far reference that is disconnected is buffered locally until the device hosting the far reference rejoins the network. isolates, on the other hand, are objects that have no surrounding lexical scope and are sent by copy over the network. 4.1 volatile sets a volatile set is implemented2 as an advanced bookkeeping abstraction over an object discovery handler. ambienttalk offers primitive event handlers that are fired whenever objects of a given type tag are discovered in the environment. these event handlers yield far references which are first tested for any property required by the volatile set and then added to a local data structure. additionally, the volatile set installs disconnection and reconnection listeners on each far reference, which are signaled whenever the device hosting the remote object disconnects from the network or reconnects to it. each time a far reference disconnects or reconnects, the far reference is removed from or added to the local data structure and the appropriate event listeners are fired. in a typical environment, several disconnections and reconnections can happen at the same time, which can cause race conditions and other concurrency problems in languages like java or c#. ambienttalk avoids these concurrency problems because its concurrency model is based on event loops (like in javascript) rather than threads. whenever an discovery or disconnection 2 the volatile sets implementation can be downloaded with the ambienttalk distribution at http://tiny.cc/dd8bb. proc. campus 2011 8 / 12 http://tiny.cc/dd8bb eceasst event is triggered, it is reified into a message and inserted into the mailbox of the actor hosting the volatile set. the actor then processes the messages one by one and updates the volatile set. as this effectively serializes these events, no concurrency problems are possible. 4.2 synchronizing isolates an important aspect of volatile sets is that the elements of the volatile set are kept synchronized when the state of remote objects changes. in current state of the art object-oriented distributed systems, objects are passed either by reference or by copy. the elements in a volatile set are passed by copy so that the programmer can locally read the state of the object, but whenever the original object is changed the element in the set should be changed as well. in order to obtain this behavior a new abstraction called synchronizing isolates was created. a device publishing a synchronizing isolate to the network under a certain type tag is called a publisher. a device creating a volatile set for this type tag is called a subscriber for synchronizing isolates published under this type tag. a schematic overview of a number of published and subscribed synchronizing isolates is shown in figure 2. publisher a syncisolateproxy published syncisolate subscribers subscriber a syncisolateproxy subscribers publisher b subscribed syncisolate published syncisolate subscribed syncisolate subscriber b subscribed syncisolate subscribed syncisolate subscriber c subscribed syncisolate subscribed syncisolate asynchronous event message disconnected side effect side effect figure 2: schematic overview of synchronizing isolates. publisher a and b host and publish a synchronizing isolate into the network while subscribers a, b and c are subscribed to some of them. whenever a synchronizing isolate is discovered, the subscriber sends a subscription message with a reference to a listener. whenever the synchronizing isolate is modified, all such listeners are signaled using an asynchronous event. this happens by wrapping the synchronizing isolate object in a proxy object that traps all side effects and transforms them into asynchronous event messages that are signaled to all subscribers associated with the synchronizing isolate. note that developers using a synchronizing isolate are not exposed to all these registrations and will just observe that the discovered objects change from time to time. however, when the programmer wants to be notified of these changes he can also register a custom observer in the 9 / 12 volume 43 (2011) volatile sets: event-driven collections for mobile ad-hoc applications volatile set as shown in the previous section. 5 related work there has been much research into group abstractions for mobile applications in the past, but most of this research focuses on group communication which is not the focus of this work. in this section, we discuss related work that focuses on organizing remote objects in intermittently connected peer-to-peer applications. distributed asynchronous collections (dacs) [egs00] is the closest work to volatile sets. dacs were originally devised as a way to marry publish-subscribe systems to traditional collection frameworks. they allow developers to subscribe to additions and removals that occur in the collections. however, dacs offer no support for tracking the connectivity of publishers that export objects, so the programmer still has to track this manually. tuple spaces [gel85] allow distributed parties to publish tuples to a conceptually shared memory and remove tuples from it. technologies such as lime [mpr01] even allow distinct tuple spaces to merge if users are close to each other and allows programmers to define reactions on the appearance or disappearance of tuples. however, tuple spaces do not support the direct modification of tuples: tuples have to be removed first and new versions reinserted later. this requires application developers to write additional code to watch these remove/insert event pairs individually. additionally, there is no support for creating a data structure from a tuple space, which forces programmers to update the derived collections manually. ambient references [cdm+06] allow discovering and communicating with homogenous groups of references to objects in the environment that change over time. this abstraction takes care of monitoring any disconnections and reconnections in the environment and even allows developers to take a snapshot of the current state. ambient references do not allow programmerss to react on objects, joining, leaving or being modified in the group. additionally, they are not composable. spatialviews [nki04] allow developers to interact with services running on nearby devices that implement the same java interface. developers can write code that iterates over all the services available along two dimensions: space (services entering a certain location are added to the group) and time (services being discovered over a certain timespan are added to the group). if a portion of code requires a service that is not available locally, the running program is moved to a node that hosts this service. spatialviews do not notify client code about services being removed from the group or changes to remote objects. m2mi [kb02] introduces a data type called a handle that is used to denote a dynamic group of remote java objects of the same interface. in m2mi, an omnihandle refers to all proximate objects of a certain interface. such an interface is equivalent to the role of our type tags. applications can send a message to an omnihandle which means, that every object implementing that interface, calls the corresponding method. however, m2mi invocations on objects that are not immediately reachable are lost. this is not the case in volatile sets. the synchronized isolate abstraction ensure that changes on the elements of a volatile set are guaranteed to be reflected. if a device disconnects, all its synchronized isolates will be removed from the existing volatile sets. however, if the device moves back online, its elements will be then added to the corresponding volatile sets reflecting changes on state effectuated while disconnected. proc. campus 2011 10 / 12 eceasst 6 conclusion and future work in this paper we discussed a pattern which is ubiquitous in mobile ad hoc applications, namely discovering and maintaining collections of remote objects that evolve organically over time due to remote events such as user interaction on a remote device. moreover, these remote objects might get disconnected at any moment in time. maintaining these collections requires extra developer effort because developers need to manually reflect changes to the content of the collection or the individual elements. to solve this issues, we proposed volatile sets, a composable collection type which allows developers to react to changes in both the structure and its contents. volatile sets allow programmers to intensionally define a set of remotely hosted objects and be notified upon object addition, removal, modification using an event-driven api. volatile sets can be composed by means of traditional set operators. as future work, we would like to introduce different types of collections that take additional constraints into account, such as the ordering of elements. another improvement could be to batch the signaled change event messages sent to all subscribers in such a way that the amount of events and hence network traffic is reduced. finally, we are investigating decentralized replication and consistency algorithms [tpst98, em97, ck00] such that clients can modify the objects in the volatile sets and the changes are synchronized with the publisher or directly to other peers that have also discovered those objects. bibliography [cdm+06] t. v. cutsem, j. dedecker, s. mostinckx, e. gonzalez boix, t. d’hondt, w. d. meuter. ambient references: addressing objects in mobile networks. in oopsla ’06: companion to the 21st acm sigplan conference on object-oriented programming systems, languages, and applications. pp. 986–997. acm press, new york, ny, usa, 2006. doi:http://doi.acm.org/10.1145/1176617.1176757 [ck00] u. cetintemell, p. keleher. light-weight currency management mechanisms in deno. international workshop on research issues in data engineering 0:17, 2000. doi:http://doi.ieeecomputersociety.org/10.1109/ride.2000.836495 [efga03] p. t. eugster, p. a. felber, r. guerraoui, a.kermarrec. the many faces of publish/subscribe. acm computing survey 35(2):114–131, 2003. doi:http://doi.acm.org/10.1145/857076.857078 [egs00] p. eugster, r. guerraoui, j. sventek. distributed asynchronous collections: abstractions for publish/subscribe interaction. ecoop 2000 – object-oriented programming, pp. 252–276, 2000. [em97] w. k. edwards, e. d. mynatt. timewarp: techniques for autonomous collaboration. in proceedings of the sigchi conference on human factors in computing systems. chi ’97, pp. 218–225. acm, new york, ny, usa, 1997. 11 / 12 volume 43 (2011) http://dx.doi.org/http://doi.acm.org/10.1145/1176617.1176757 http://dx.doi.org/http://doi.ieeecomputersociety.org/10.1109/ride.2000.836495 http://dx.doi.org/http://doi.acm.org/10.1145/857076.857078 volatile sets: event-driven collections for mobile ad-hoc applications doi:http://doi.acm.org/10.1145/258549.258710 http://doi.acm.org/10.1145/258549.258710 [gel85] d. gelernter. generative communication in linda. acm transactions on programming languages and systems 7(1):80–112, jan 1985. [gls+11] e. gonzalez boix, a. lombide carreton, c. scholliers, t. van cutsem, w. de meuter, t. d’hondt. flocks: enabling dynamic group interactions in mobile social networking applications. in proceedings of the 2011 acm symposium on applied computing (sac), taichung, taiwan, march 21–25, 2011. volume 1, pp. 425–432. acm, 2011. [kb02] a. kaminsky, h.-p. bischof. many-to-many invocation: a new object oriented paradigm for ad hoc collaborative systems. in oopsla 2002. pp. 72–73. acm press, 2002. doi:http://doi.acm.org/10.1145/985072.985109 [mpr01] a. murphy, g. picco, g.-c. roman. lime: a middleware for physical and logical mobility. in proceedings of the the 21st international conference on distributed computing systems. pp. 524–536. ieee computer society, 2001. [nki04] y. ni, u. kremer, l. iftode. spatial views: space-aware programming for networks of embedded systems. languages and compilers for parallel computing, pp. 258– 272, 2004. [sgdd10] c. scholliers, e. gonzalez boix, w. de meuter, t. d’hondt. context-aware tuples for the ambient. on the move to meaningful internet systems, otm 2010, pp. 745– 763, 2010. [tpst98] d. b. terry, k. petersen, m. j. spreitzer, m. m. theimer. the case for nontransparent replication: examples from bayou. ieee data engineering bulletin 21(4):12–20, december 1998. [vmg+07] t. van cutsem, s. mostinckx, e. gonzalez boix, j. dedecker, w. de meuter. ambienttalk: object-oriented event-driven programming in mobile ad hoc networks. in inter. conf. of the chilean computer science society (sccc). pp. 3–12. ieee computer society, 2007. proc. campus 2011 12 / 12 http://dx.doi.org/http://doi.acm.org/10.1145/258549.258710 http://doi.acm.org/10.1145/258549.258710 http://dx.doi.org/http://doi.acm.org/10.1145/985072.985109 introduction problem statement volatile sets the wescribble application volatile sets at work implementation volatile sets synchronizing isolates related work conclusion and future work modelling feedback control loops for self-adaptive systems electronic communications of the easst volume 28 (2010) proceedings of the third international discotec workshop on context-aware adaptation mechanisms for pervasive and ubiquitous services (campus 2010) modelling feedback control loops for self-adaptive systems russel nzekwa, romain rouvoy and lionel seinturier 6 pages guest editors: sonia ben mokhtar, romain rouvoy, michael wagner managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst modelling feedback control loops for self-adaptive systems russel nzekwa, romain rouvoy and lionel seinturier adam project-team inria lille – nord europe university of lille 1, lifl cnrs umr 8022 f-59650 villeneuve d’ascq firstname.lastname@inria.fr abstract: feedback control loops (fcls) are the heart of any self-adaptive system. existing engineering approaches for building self-adaptive systems mask fcl by providing abstraction layers that hide the application complexity. in this paper, we investigate a model-driven approach for the engineering of fcls whose architecture is based on the service component architecture (sca) model. our proposal consists in exploiting the data streaming model, to specify the characteristics of the control policies, and to generate fcls of self-adaptive systems deployed in largescale environment. we argue that the use of a data-oriented model for designing self-adaptive systems significantly increases fcl visibility. keywords: modelling, feedback control loop, self-adaptation 1 introduction this last decade, there has been an increasing demand for self-managing systems, achieving desired quality requirements with a reasonable cost. self-adaptive systems (or autonomic systems) are self-managing system that use feedback control loops (fcls) to monitor, analyse, plan, and act according to changes occurring in their environment. existing engineering techniques for building self-adaptive systems hide software complexity behind abstraction layers. however, these layers do not provide support for handling control elements (sensors, actuators, etc.) of the system explicitly. this situation results in fastidious, opaque (there is no explicit view of different politics implemented by the fcl), and not scalable fcls [bsc+09]. in this paper, we introduce a model-driven approach for generating distributed fcls. in particular, this approach exploits the data streaming model [bbd+02] to specify the flow and the deployment of the components implementing fcls. the originality of the proposed approach lies in the use of annotations within models, which are seamlessly processed as specific runtime artefacts. we illustrate the key elements of our approach on a case study, focusing on real-time tracking of a large fleet of trucks. the rest of this paper is organized as follows. after introducing some backgrounds on fcl, we next present an example of a large-scale self-adaptive system, dedicated to the real-time tracking of a fleet of trucks (cf. section 2). then, we introduce our design approach and the associated distributed infrastructure (cf. section 3). after that, we compare our approach with some state-of-the-art related works (cf. section 4). finally, we conclude and discuss the perspectives of this work (cf. section 5). 1 / 6 volume 28 (2010) mailto:firstname.lastname@inria.fr modelling feedback control loops 2 background & scenario this section presents some background on autonomic fcl and a motivation scenario, that we use later to illustrate our modelisation approach for fcls in a self-adaptive systems. 2.1 mape-k loop the reference standard from the ibm autonomic computing initiative, codifies an external, fcl approach in its monitor-analyze-plan-execute (mape) model [ibm06]. monitor analyze plan execute execution environment supporting platform adaptation policy adaptation situation adaptation plan application effectorssensors autonomic manager managed resources knowledge figure 1: overview of the autonomic mape model the monitor part provides the mechanisms that collect, aggregate, filter and report information (such as metrics and topologies) collected from managed resources. the analyze part contains the mechanisms that correlate and model complex adaptation situations. the plan function encloses the mechanisms that construct the actions needed to achieve goals and objectives. the planning mechanism uses adaptation policies information to guide its work. the execute function groups the mechanisms that control the execution of an adaptation plan with considerations for dynamic updates. in the mapek loop model as shown in figure 1, knowledge (symptoms, policies) is the relevant data shared amongst the monitor, analyze, plan and execute activities of the autonomic manager. the run-time knowledge must be complete—i.e., including the whole aspects influencing adaptation decisions—, modifiable—i.e, following the application changes—, and at a high-level of abstraction—i.e, comprising only relevant information. 2.2 motivating scenario we consider a self-adaptive application for the management of the truck fleet (80,000 to 1,000,000 trucks) of a company specialized in the transportation of fragile products. the trucks do not have the same characteristics: some are equipped with good a air conditioning system, while others provide a robust slip system. in the same way, transported goods do not have the same requirements: some are very sensitive to temperature variations, while others need high security systems. the overall objective of the application is to make sure the trucks reach their destination on time. the application must be able to detect stop times, temperature variation inside containers, security violation and truck position. the application is also connected to remote services, like the weather service or the city traffic service. the self-adaptive application must also notify the destination platform about truck arrivals. all the aforementioned information is sent to the central control center, which processes and decides which adaptation process can be triggered. from the analysis of the data exchanged between the nodes (hosts) of the application, proc. campus 2010 2 / 6 eceasst several adaptations can result, such as the frequency of the positioning requests or the number of resources (server node) allocated to process data. 3 feedback control loops engineering this section introduces the design and runtime architecture of fcl for the scenario presented in section 2 using our approach. 3.1 feedback control loop metamodel +name: string node edge #name:string localisation stabilisation security qos * nodetype planner actor analyser sensor property time accuracyencryption +mobile +stable <> hosttype processor +name:string system graph #hosttype: hosttype host from to 0..* * 1..* property figure 2: feedback control loop metamodel one way to provide visibility for fcl in an application, is to find a way of specifying required control features. to meet this goal, we present here a meta-model to express control properties in the application. the presented metamodel allows to express control elements concepts like sensors, processors, or actors which correspond to architectural elements aiming to sense, process, or act on the system respectively. the metamodel characterizes also the process flow between the elements of the system, by offering concepts to express non-functional properties such as stabilization or security. all these concepts can be used at design time by the application architect in order to specify control elements of the system, using annotation artefacts. the following section shows an example of how this metamodel can be used, by presenting a variant of the data processing model for the scenario presented above. 3.2 data-oriented modelling of feedback control loops our model is inspired by the context policy specification of the cosmos context processing framework [rcs08]. concretely, the data processing model that we defined is a connected graph where the nodes reflect processed data, and the edges identify data dependencies. nodes on the left side of figure 3 are raw data sensors, while the right-side nodes describe decision actuators. nodes located in the middle are called processor (analyzer, planner) nodes. the data therefore flows through the nodes, where it is incrementally transformed into information of an higher level of abstraction. figure 3 shows the specification of the real-time truck tracking infrastructure, that we introduced in section 2. the shaded nodes of the graph identify data sensors and effectors of the infrastructure, whose location is statically assigned. for example, the truck position node is shaded to specify that the associated sensor is necessarily deployed in the truck. white nodes represent data processors, whose host is not explicitly identified and can therefore be deployed in any part of the infrastructure. 3 / 6 volume 28 (2010) modelling feedback control loops truck position tolerance distance progression plan out of corridor frequency retrieval illegal stop long period stop corridor report route plan traffic information hatchback status hatchback open hatchback report stop report arrival truck timestamp truck identifier trailer position abnormal distance trailer report progression report truck delay truck ahead checkpoints checkpoint distance tolerance area checkpoint area payment report departure checkpoint report monitor analyse plan execute @qos (encrypted) @qos (data precision) @qos (data precision) @stabilization (fuzzy logic) @stabilization (fuzzy logic) @host(hatchback) @host(trailer) @host(truck) @host(company) @host(company) @host(truck) @host(truck) @host(hatchback) @host(truck) @host(truck) @host(truck) @host(truck) @host(truck) @host(truck) @host(trailer) @qos (encrypted) @qos (dat a precision ) @stabilization (fuzzy logic) @s tab iliz ati on (f uzz y l og ic) figure 3: data processing model of the feedback control loop. trailer truck geo hub customer company internet figure 4: physical infrastructure deployment model. then, the deployment infrastructure shown in figure 4, specifies how the infrastructure is deployed as a network of physical or virtual devices, which can eventually host the data processors. the connections between the devices describe the available communication links. 3.3 deployment and execution of feedback control loops this section describes the runtime part of our approach, which exploits the data-oriented specification of the fcl, to generate a component-based infrastructure that implements it. in particular, during the feedback loop generation process, we convert the previously introduced models into software components, by combining the data processing and the deployment infrastructure models. we can assign the unshaded data processors to the devices of the infrastructure. for each unallocated data processor, the algorithm computes the list of devices which are 0 or 1-hop away from the data dependencies. then, the most relevant device selected for hosting the data processor is the one that minimizes the memory consumption and the communication cost. figure 5 depicts a candidate architecture obtained when applying this algorithm. the resulting architecture is mapped to the service component architecture (sca) [sca] standard by applying the following rules: i) the nodes of the connected graph are mapped into primitive components, ii) local data dependencies are converted into component wires, while remote data dependencies are exposed through bindings, and finally iii) nodes that are located on the same device are grouped within composite components. proc. campus 2010 4 / 6 eceasst customer geohub truck internet trailer company p u s h p u s h p u s h p u s h p u s h p u s h p u s h p u s h p u s h p u s h push push push push push push pull pull push push push push a primitive data component composite component remote sca binding local wire connection hatchback status hatchback open trailer position route plan arrivaldeparture truck position tolerance distance progression plan out of corridor retrieval frequency illegal stop long period stop corridor report traffic information hatchback report stop report truck timestamptruck identifier abnormal distance trailer report progression report truck delay truck aheadcheckpoints checkpoint distance tolerance area checkpoint area payment report checkpoint report figure 5: component-based architecture of the feedback control loop. 4 related work the rainbow [gch+04], entropy [hlm+09], and cappucino [rrs+09] frameworks provide components that fulfill the mape loop (cf. section 2.1) phases to support self-adaptation. nonetheless, these frameworks propose a static or closed infrastructure for managing the adaptation policies. besides that, in terms of autonomic software system, literature abounds of many resources, such as kx (kinesthetics extreme) [kpgv03], astrolabe [brv03], or unity [csww04]. however, as in the case of autonomic frameworks, the lack of transparency in the design and the management of the fcl systems is one of the major limitations to the scalability of such systems. to solve the problem of the opacity and the non-scalability of existing fcl, some recent research works suggest that, “the feedback loops that control self adaptation must become first-class entities.” [bsc+09]. the approach we propose in this paper stands in that perspective. the idea is to generalize the autonomic mape model and to extend the cappucino framework to address very-large-scale environments. in particular, we propose to reify the mape model as a very-large-scale data processing infrastructure, which converts data collected in the environment into real-time reactions. the data processing distribution is driven by the specification of data dependencies [rcs08] in order to maximize the performances of the system and balance the processing load among the nodes available in the environment. 5 conclusion we have outlined in this paper an approach for the engineering of fcls drawing on the data flow model. we argue that, the data flow model comes with additional information that can be crucial for fcl engineering earlier at design time, to understand ongoing control mechanisms, 5 / 6 volume 28 (2010) modelling feedback control loops and later at runtime for an efficient adaptation of the system. we used the truck tracking scenario, to explain how to specify a data-oriented model of a fcl, and how to generate the underlying execution platform with the sca standard. as futur works, we are planning to evaluate the overhead introduced by our approach in a realistic deployment. acknowledgements: the work reported in this paper is partly funded by the anr arpege salty project (http://salty.unice.fr) under contract anr-09-segi-012 and feder project. bibliography [bbd+02] b. babcock, s. babu, m. datar, r. motwani, j. widom. models and issues in data stream systems. in in proceedings of the twenty-first acm sigmod-sigact-sigart symposium on principles of database systems (pods’02). pp. 1–16. acm, new york, ny, usa, 2002. [brv03] k. p. birman, r. v. renesse, w. vogels. navigating in the storm:using astrolabe for distributed self-configuration, monitoring and adaptation. in proceedings of the autonomic computing workshop, 5th international workshop on active middleware services (ams’03). pp. 4–13. 2003. [bsc+09] y. brun, g. d. m. serugendo, h. g. cristina gacek, h. kienle, h. m. marin litoiu, m. pezzè, m. shaw. software engineering for self-adaptive systems (sefsas). lncs 5525, chapter engineering self-adaptive systems through feedback loops, pp. 48–70. springer, 2009. [csww04] d. m. chess, a. segal, i. whalley, s. r. white. unity: experiences with a prototype autonomic computing system. in proceedings of ieee first international conference on autonomic computing. pp. 140–147. may 2004. [gch+04] d. garlan, s.-w. cheng, a.-c. huang, b. schmerl, p. steenkist. rainbow: architecturebased self-adaptation with reusable infrastructure. ieee computer 37(10):46–54, oct. 2004. [hlm+09] f. hermenier, x. lorca, j.-m. menaud, g. muller, j. lawall. entropy: a consolidation manager for clusters. in proceedings of the acm sigplan/sigops international conference on virtual execution environments (vee’09). pp. 41–50. acm, new york, ny, usa, 2009. [ibm06] ibm. an architectural blueprint for autonomic computing. white paper, june 2006. [kpgv03] g. kaiser, j. parekh, p. gross, g. valetto. kinesthetics extreme: an external infrastructure for monitoring distributed legacy systems. in proceedings of the autonomic computing workshop, fifth international workshop on active middleware services (ams’03). pp. 22–30. acm, june 2003. [rcs08] r. rouvoy, d. conan, l. seinturier. software architecture patterns for a context processing middleware framework. ieee distributed systems online (dso) 9(6):12, june 2008. [rrs+09] d. romero, r. rouvoy, l. seinturier, s. chabridon, d. conan, n. pessemier. enabling context-aware web services: methods, architectures, and technologies. chapter enabling context-aware web services: a middleware approach for ubiquitous environments, pp. 113–135. chapman and hall/crc, july 2009. [sca] sca service component architecture. http://www.osoa.org. proc. campus 2010 6 / 6 introduction background & scenario mape-k loop motivating scenario feedback control loops engineering feedback control loop metamodel data-oriented modelling of feedback control loops deployment and execution of feedback control loops related work conclusion coinductive graph representation: the problem of embedded lists electronic communications of the easst volume 39 (2011) graph computation models selected revised papers from the third international workshop on graph computation models (gcm 2010) coinductive graph representation: the problem of embedded lists celia picard and ralph matthes 24 pages guest editors: rachid echahed, annegret habel, mohamed mosbah managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst coinductive graph representation: the problem of embedded lists celia picard and ralph matthes institut de recherche en informatique de toulouse (irit), université de toulouse and c.n.r.s., france abstract: when trying to obtain formally certified model transformations, one may want to represent models as graphs and graphs as greatest fixed points. to do so, one is rather naturally led to define co-inductive types that use lists (to represent a finite but unbounded number of children of internal nodes). these concepts are rather well supported in the proof assistant coq. however, their use in our intended applications may cause problems since the co-recursive call in the type definition occurs in the list parameter. when defining co-recursive functions on such structures, one will face guardedness issues, and in fact, the syntactic criterion applied by the coq system is too rigid here. we offer a solution using dependent types to overcome the guardedness issues that arise in our graph transformations. we also give examples of further properties and results, among which finiteness of represented graphs. all of this has been fully formalized in coq. keywords: coinduction/corecursion, guardedness, theorem proving, dependent types, metamodels 1 the problem: explanation on an example it is recognized that the on-going engineering effort for modeling and meta-modeling has to be backed by rigorous formal methods. in this context, we aim at performing certified model transformations. in a first time, certification should be done by interactive theorem proving. this presupposes the representation of models and metamodels in the language of the theorem prover. we chose to represent models and metamodels as graphs and to use the coq system 1 as a specification and verification tool. the coq system offers a language with a rich notion of inductive and co-inductive types, i. e., data types that arise as least and greatest solutions of fixed-point equations, respectively. this led us to represent node-labeled graphs with co-inductive types (in order to represent the infinite navigability in loops). the idea we had was that each node would have a label (of a type t) and a finite list of sons (graphs themselves). this type can be created through the following constructor: definition 1 (graph, viewed coinductively) mk_graph : t → list (graph t )→ graph t 1 see http://coq.inria.fr/ 1 / 24 volume 39 (2011) http://coq.inria.fr/ coinductive graph representation mk_graph t l constructs a graph from the label t of type t and the list of graphs l. since this is the greatest fixed point, no assumption about finite generation through mk_graph is made. the empty list hides the base case. remark 1 (lists) for lists we use the caml notation: [] for the empty list, [a1; a2;...] for an explicit enumeration and a :: l for the cons operation. remark 2 (rose trees) what we represent here are actually potentially infinite “rose trees” that may have cycles. they can be considered as a dual version of rose trees although the lists are not dualised. finite rose trees form a well-known example for datatypes in the community around the haskell programming language (see [bir01] for example). remark 3 here we deal (at first sight at least) with single-rooted connected graphs because they correspond best to co-inductive types. a more general solution is presented in subsection 4.1, still within the expressive power of coq. remark 4 (notations) in the rest of the paper we will use the following notation: • t,u for types and t for elements of type t , • n, m and k for natural numbers (informally, but also for elements of type nat), • l and q for lists and elements of ilist, defined in section 2 • f for functions, • g for elements of graph, • r for equivalence relations (if r is a relation on type t it has type t → t → prop), • p for predicates (if p is over type t it has type t → prop) • i for elements of fin n, defined in section 2 remark 5 (examples) in all the examples that will be given in this paper, we will use natural numbers as labels of nodes, i. e., t = nat. example 1 (a simple example that does not use co-recursion: just a leaf) leaf n := mk_graph n [] example 2 (example of a finite graph) the graph of figure 1 can be represented as a term of type graph with the following co-recursive definition: finite_graph := mk_graph 0 [mk_graph 1 [finite_graph]] remark 6 this graph is finite but unfolds into an infinite (regular) tree, and thus allows infinite navigation. gcm 2010 2 / 24 eceasst 0 1 figure 1: example of a finite graph example 3 (example of an infinite graph) to represent the graph of figure 2 as a term of type graph, we first define a family of infinite graphs, parameterized by the label of the first node: infinite_graphn := mk_graph n [infinite_graphn+1] the graph of figure 2 corresponds to infinite_graph0. 0 1 2 ... figure 2: example of an infinite graph remark 7 this graph is infinite and unfolds into an infinite irregular tree. the previous definitions and examples are well-defined in coq. however, problems arise when trying to apply a transformation on a graph. for example, it is forbidden to define the following co-recursive function applyf2g :∀ t u, (t →u)→graph t →graph u that applies a function f to each label of a graph: definition 2 applyf2g f (mk_graph t l) := mk_graph ( f t) ( map (applyf2g f ) l ) remark 8 here, map is the usual mapping function that maps a function over all the elements of a list, i. e., map f [a1; a2;...] = [ f a1; f a2;...]. the reason why applyf2g is not accepted by coq is that the guardedness condition on coinductive types is rather restrictive in coq, and in this case, too restrictive. indeed, in coq the guardedness condition is based on productivity [coq93]. technically speaking, it says that a co-recursive call must always be the argument of some constructor of inductive or co-inductive type. here, the co-recursive call is an argument of the map function, which is itself under the constructor. this is too indirect to satisfy the guardedness condition. for more details about the guardedness conditions in coq see [bk08] and [gc07]. 3 / 24 volume 39 (2011) coinductive graph representation basically, the idea of the guardedness condition is to ensure that potentially infinite objects are computable. this means that we can always obtain more information on the structure of the object in a finite amount of time. consider the example of streams that are always infinite. the application of a filter on streams is actually a problem since we cannot ensure that the next “good” element will be found in a finite amount of time. but here the problem is quite different in nature: it is not about finding the next constructor but about the indirection of the co-recursive call through map. however, in the case of map, this indirection is harmless (we would only have to inspect in parallel the elements of that list). so, coq’s guardedness condition forbids us to write semantically well-formed definitions: guardedness restrictions go beyond syntactic well-formedness and normal typing constraints but are still of a syntactic nature and thus only approximate the semantic notion of productivity that guarantees well-definedness. in this article, we offer and study a solution to overcome the problem with the guardedness condition for definitions involving graphs. in section 2 we explain the solution, and we will see how it solves our problem in section 3. finally, in section 4 we present two extensions that bring us closer to a real metamodel representation. even though this article is not written in the formal language of the coq system, all the work presented here has been formally proved in coq (version 8.3). the whole development is available in [pm11]. 2 the solution: ilist we develop here a solution that allows us to bypass the guardedness condition. 2.1 the idea the idea to solve the problem is to use a function that mimics the behaviour of lists (this idea has also been mentioned by chlipala in [chl10]). lists can easily be seen as functions. if t is the type parameter, then a list can be considered as a function that associates to each element of a set of n elements (n being the length of the list) an element of type t. an element of the definition domain represents the position of the associated element in the list. example 4 the list [10 ; 2 ; 5] can be transformed into the function of figure 3. p1 p2 p3 10 2 5 nat figure 3: representation of the function corresponding to the list [10 ; 2 ; 5] gcm 2010 4 / 24 eceasst but to be able to represent such a function, we need to have a set of n elements. 2.2 fin – a family of types for finite index sets it is trivial to get an inductive type with n elements, for n = 0,1,2,... but it is not for an indeterminate n. here we need n to be a parameter of the type. to represent a set of n elements, we have chosen to use the representation that has also been used by altenkirch in [alt93] and by mcbride and mckinna in [mm04]. we actually represent a family of sets parameterized by the number of elements they contain (in our case, the length of the list). this family is called fin. fin has type nat → set. it is defined through the two following constructors: definition 3 (fin, viewed inductively) first n : fin (n + 1) succ n : fin n → fin (n + 1) remark 9 fin is a generalized algebraic data type (gadt). those data types are also available in current implementations of the haskell programming language. remark 10 the first argument n to succ is determined by the type of the second argument. therefore, we tend to omit this first argument. first of all, we want to prove that fin n indeed is a set of n elements. remark 11 we use card to represent the cardinality of the set in an informal way. lemma 1 ∀n, card {i | i : fin n}= n. proof (by induction). [case 0] no constructor allows to create an element of type fin 0. therefore card { i | i : fin 0 } = 0 [case n+1] with the constructor succ, we can construct as many elements of fin (n+1) as there are in fin n. the constructor first allows us to construct one more element of fin (n + 1). therefore, card {i | i : fin (n + 1)} = card {i | i : fin n}+ 1 = n + 1, using the induction hypothesis. remark 12 this informal proof cannot be formalized in coq because there is no such card operation. with the card operation the following result would have been a triviality. lemma 2 ∀n m, n = m ⇔ fin n = fin m. proof. [direction ⇒] the proof here is straightforward, it is only a matter of rewriting and we directly have the property. in informal mathematics this would not even be stated. 5 / 24 volume 39 (2011) coinductive graph representation [direction ⇐] this direction is much trickier than the first one. indeed, the first idea we had was to show that all the elements of fin n are in fin m too, doing a type rewrite on the type of the elements. however, that does not seem to work in coq (at least, we did not find a way to do it). in order to prove this property, we defined the type of segments of natural numbers (let’s call it natseg): natseg n := { m | m < n }. we proved that if there is a bijection between natseg n and natseg n′ then n = n′. the proof is not straightforward, but at least we could do it 2. then we could prove that there is a bijection between fin n and natseg n and that therefore, ∀n m, fin n = fin m ⇒ n = m. remark 13 one may wonder why we did not use directly natseg instead of fin to represent a set of n elements. the reason is that it is much more comfortable to have an inductive type (with concrete finite elements). the elements of natseg n contain a proof of m < n, and we consider fin more elementary. 2.3 ilist implementation using the preceding definition of the domain of the functions to be used, we can define the type of functions itself (let’s call it ilistn). 2.3.1 the type of functions ilistn it has two parameters: the type of the elements of the list and its length. it is defined as follows: definition 4 ilistn t n := fin n → t elements of ilistn “mimic” lists. to each element of a set of n elements, it associates an element of type t. however, one problem remains. indeed, as we said, ilistn needs two parameters. but for a list, the length is not one of its parameters, it is inherent to it. 2.3.2 the list counterpart, ilist to solve this problem, we create a new type that combines the length of the list and the corresponding ilistn. we call it ilist : definition 5 ilist t := σn : nat.ilistn t n here, we use the dependent pair that is generically denoted as σx : a.b(x). elements of this type consist of an element a of type a and an element b of type b(a). the two projection functions on ilist are called lgti (which stands for the length of an element of ilist) and fcti (which stands for the function in an element of ilist). if we note 〈...,...〉 the constructor for elements of type σx : a.b(x), then an element l of type ilist t can be “reconstructed” as 〈lgti l, fcti l〉. 2 we had the confirmation by other members of the coq user community that no simple proof was known yet. gcm 2010 6 / 24 eceasst 2.3.3 an equivalence on ilist it is very useful to be able to compare two elements of the same type. here, of course, we would like to be able to compare two elements of ilist. for fin there was no problem, it is inductive and does not have any type parameter, so leibniz equality is fine. to recall, leibniz equality is the propositional equality that allows the replacement of leibniz-equal elements in any context. in this paper (as in coq), it is denoted by the infix “=” symbol or the prefix eq relation symbol. here, the problem is different. we intuitively see that in order to compare elements of ilist, we will have to compare two different things: the two parts of its definition. the first one, its length, is the easy one: it is a natural number, no problem here. but the second one is trickier. indeed, we have to make sure that the two elements of ilist we are comparing are equivalent elementwise. and we have no insurance that they are comparable w. r. t. leibniz equality (actually, in our graph representation, they are not, they are only comparable through bisimulation). we thus define an inductive proposition (let’s call it ilist_rel because it is the lifting of ilist to relations) that relates two elements of ilist. apart from the elements of ilist we are comparing and the type parameter (let’s call it t ), the proposition needs a given base relation r on type t . then, ilist_rel r has type ilist t → ilist t → prop. intuitively, we would like to define ilist_rel such that: ∀l1 l2 : ilist t,ilist_rel r l1 l2 ⇔ lgti l1 = lgti l2 ∧∀i : fin (lgti l1),r (fcti l1 i) (fcti l2 i) however, this expression is not well-typed. indeed, fcti l2 has type fin (lgti l2) → t and i has type fin (lgti l1). we know that lgti l1 = lgti l2 but the types fin (lgti l1) and fin (lgti l2) are still syntactically different. therefore, we must convert i to type fin (lgti l2) (the hypothesis lgti l1 = lgti l2 and lemma 2 “⇒” ensure that we have the right to do it). in coq, there is a special pattern matching feature that allows us to make this type rewrite. we do not detail it here, for more information see [tcdt, chapter 1.2.13 and 4.5.4]. in a context where h : lgti l1 = lgti l2 and i : fin (lgti l1), we call i′h the result of converting i to type fin (lgti l2). with this we can properly write our definition for ilist_rel: definition 6 (ilist_rel) ∀l1 l2 : ilist t,ilist_rel r l1 l2 ⇔∃h : lgti l1 = lgti l2, ∀i : fin (lgti l1),r (fcti l1 i) (fcti l2 i′h) using advanced dependently typed pattern matching techniques, one can show that ilist_rel r is an equivalence relation if r is one which we assume throughout. remark 14 in the sequel, we will put argument r as an index to ilist_rel, i. e., we will write ilist_relr for ilist_rel r, and we will do so in all similar cases. remark 15 (list_rel) had we worked with lists, we would have needed to be able to compare two lists. however, the commonly used relation on lists is leibniz equality, but this relation supposes that the elements of the lists are comparable through leibniz equality, too. as we will explain in section 3, in our case (graph representation through graph) they are only comparable 7 / 24 volume 39 (2011) coinductive graph representation through bisimulation. therefore, we would have needed to define a relation on lists parameterized by a relation on the type of its elements and prove that it is an equivalence relation (which is rather easy to do). definition 7 (list_rel) ∀(l1 l2 : list t ),list_relr l1 l2 ⇔{ or l1 = []∧l2 = [] ∃ t1 t2 q1 q2, l1 = t1 :: q1 ∧l2 = t2 :: q2 ∧r t1 t2 ∧list_relr q1 q2 it is easy to prove that list_releq l1 l2 ⇔ l1 = l2, but it is not provable for ilist_rel since our type theory is not extensional. 2.3.4 bijection between ilist and lists in order to show that there is a bijection between ilist and lists, we define the two following functions that respectively transform an element of ilist into a list (ilist2list) and a list into an element of ilist (list2ilist). to define ilist2list, we proceed in two steps. first we create a list containing all the “indices” of the ilist (i. e., containing all the elements of fin (lgti l). for example, for lgti l = 2 this list will be [first 1 ; succ (first 0)]). to do so, we write the function makelistfin, that takes as argument a natural number n and that returns the list of all the elements of fin n. then, we apply the function part of the ilist to all the elements of this list. definition 8 (makelistfin) makelistfin 0 : list (fin 0) := [] makelistfin (n + 1) : list (fin (n + 1)) := (first n) :: (map succ (makelistfin n)) it is easy to prove the following lemma on makelistfin: lemma 3 ∀ n,length (makelistfin n) = n. definition 9 (ilist2list) ilist2list t l : list t := map (fcti l) (makelistfin (lgti l)) to define list2ilist, we also proceed in two steps. first we must define a method that gives us the “ith” element of the list. we do not detail it here because the problems that arise are more coq-related (technical) than theoretical. we call this function list2fint . it takes a list l and an element i of fin (length l) as parameters and returns the ith element of l. it is characterized by the following assertions: ∀ t q, list2fint (t :: q) (first (length q)) = t ∀ t q i, list2fint (t :: q) (succ i) = list2fint q i and it is such that the following lemmas are true: gcm 2010 8 / 24 eceasst lemma 4 ∀ (l : list t ) ( f : t →u) (i : fin (length (map f l))), list2fint (map f l) i = f (list2fint l i′h) where h is a proof that length (map f l) = length l, which is trivial. lemma 5 ∀(l : ilist t ) (i : fin (length (makelistfin (lgti l)))), list2fint (makelistfin (lgti l)) i = i′h where h is a proof that length (makelistfin (lgti l)) = lgti l, which is an instance of lemma 3. actually, list2fint is the function part of the ilist we want to create in list2ilist. list2ilist is defined as follows: definition 10 (list2ilist) list2ilist t l : ilist t := 〈length l, list2fint l〉 to show that there is a bijection between ilist and lists, we need to prove that the compositions ilist2list◦ list2ilist and list2ilist◦ ilist2list are both extensionally equal to the identity, i. e., only pointwise and only with respect to ilist_rel when comparing elements of ilist. we first define the following two lemmas to help us with the proofs mentioned above. the proofs of those lemmas are straightforward and not detailed here. lemma 6 ∀ t l, lgti (list2ilist (ilist2list l)) = lgti l. lemma 7 ∀ t l, length (ilist2list (list2ilist l)) = length l. and now we can prove the bijection between ilist and lists. theorem 1 (list2ilist◦ilist2list = id) ∀ t l,ilist_releq l (list2ilist (ilist2list l)). proof. using definition 6 we have that ilist_releq l (list2ilist (ilist2list l)) ⇔ ∃h : lgti l = lgti (list2ilist (ilist2list l)), ∀i : fin (lgti l), fcti l i = fcti (list2ilist (ilist2list l)) i′h we obtain h thanks to lemma 6. therefore, we now only have to prove that: ∀i : fin (lgti l), fcti l i = fcti ( list2ilist (ilist2list l)︸︷︷︸〈length (ilist2list l), list2fint ( ilist2list l︸︷︷︸ map (fcti l) (makelistfin (lgti l)) )〉 ) i′h ︸︷︷︸ list2fint (map (fcti l) (makelistfin (lgti l))) i′h︸︷︷︸ fcti l (list2fint (makelistfin (lgti l)) (i′h) ′ h′︸︷︷︸ i ) where h′ comes from the application of lemma 4, and the last step involves lemma 5. 9 / 24 volume 39 (2011) coinductive graph representation remark 16 obviously, the statement of theorem 1 is then also valid for any other reflexive relation r than eq since ilist_rel is monotone in its relation argument. theorem 2 (ilist2list◦list2ilist = id) ∀ t l,l = ilist2list (list2ilist l). proof (by induction on l). [case []] applying the definitions of ilist2list and list2ilist, we get as goal [] = [], which is true. [case t :: q] the induction hypothesis ih is q = ilist2list (list2ilist q). ilist2list (list2ilist (t :: q)) reduces in the following way: (ilist2list ( list2ilist (t :: q)︸︷︷︸〈length q + 1, list2fint (t :: q)〉 )) ︸︷︷︸ map (list2fint (t :: q)) ( makelistfin (length q + 1)︸︷︷︸ first (length q) :: map succ (makelistfin (length q)) ) ︸︷︷︸ list2fint(t :: q) (first (length q)) :: map ((list2fint (t :: q))◦succ) (makelistfin (length q)) for this last simplification, we have used the following property of map: ∀ l f g, map f (map g l) = map ( f ◦g) l according to the characterization of list2fint , the first expression before :: reduces to t, and the last expression after :: finally reduces to map (list2fint q) (makelistfin (length q)) because the result of applying map f only depends on the extension of f (the pointwise behaviour). we actually only need to prove that: t :: q = t :: map (list2fint q) (makelistfin (length q))︸︷︷︸ ilist2list 〈length q, list2fint q〉︸︷︷︸ list2ilist q︸︷︷︸ q (according to ih) this proves that there is a bijection between lists and ilist, and it validates our definition of ilist. 2.3.5 functions on ilist as we have a bijection between lists and ilist, we can redefine any function f that has lists as parameters and/or lists as result type. in particular that means that all the usual functions (and higher order functions) on lists have their counterpart on ilist. for example, the well-known filter function on lists has an analogue on ilist (for p a predicate on the type of elements): definition 11 ifilter p l := list2ilist (filter p (ilist2list l)) gcm 2010 10 / 24 eceasst and in general, any function f : list t → list t can be translated to ilist as a function f ′ of type ilist t → ilist t . the function f ′ is defined as follows : f ′ := list2ilist◦ f ◦ilist2list however, this is only anecdotal as we embed f into another function and therefore we do not solve the guardedness issue. for example, if we defined an analogue of the map function (let’s call it imap) with this method, we would have: definition 12 (imap, first try) imap : (t →u)→ ilist t → ilist u imap f l := list2ilist (map f (ilist2list l)) but this does not solve our problem since the function f (which in our example is the co-recursive call) would still be embedded into the map function, which as we saw does not work. 2.3.6 imap we have to redefine the map function directly. this is actually quite easy since the part of the ilist that is affected by the map is the function part (ilistn). so in fact, the imap function is little more than a composition of functions. what we have to do is to compose the function part of the ilist with the function we have to apply and then recreate the ilist. the result has the same natural numbers part (lgti l) and a new function part f ◦(fcti l): definition 13 (imap, suitable for guarded definitions) imap f l := 〈lgti l, f ◦(fcti l)〉 here, the function f (and therefore in our example the co-recursive call) is directly under the constructor 〈...,...〉. this satisfies the guardedness restriction and solves our problem. so we see that the use of function spaces is considered less critical than the use of inductive types because they are more primitive. they are even part of the logical framework. this could not have been done on lists since they are defined inductively and so should be the functions that manipulate them. there is no other way than recursion to define map on lists. all such higherorder functions add a layer between the constructor and the function given as a parameter. in the case this function is a co-recursive call, it can create, as we saw, a conflict with the guardedness conditions. as the imap function is not defined recursively, there is no layer added and as we said, in case of a co-recursive call the guardedness condition is satisfied. 2.3.7 universal quantification for further definitions (see section 3) we need to define a property on ilist that expresses that all the elements of an ilist satisfy a predicate p. we call it iall (it is the counterpart to the for_all function in caml). it is defined as follows: definition 14 (iall) iall t p l : prop :=∀i,p (fcti l i) 11 / 24 volume 39 (2011) coinductive graph representation 2.3.8 manipulation of ilist in list fashion what we wanted to do when we created ilist was to have functions that would mimic list behaviour. thus, we want to be able to manipulate ilist in a similar way as we manipulate lists. there are two constructors of list: nil ([]) that allows to create an empty list, and cons (infix ::) that allows to insert an element at the head of a list. thus, we have written the two following functions that allow, respectively, to create an empty ilist and to append an element at the head of an ilist. to define inil, we need an element of ilistn t 0, i. e., a function of type fin 0 → t . as fin 0 is empty, all the ilistn t 0 are equivalent (and are inhabited for all t). let’s call iniln one of those. we define inil the following way: definition 15 (inil) inil t := 〈0, iniln t〉 for the sake of clarity, we will also define the function part of icons separately. definition 16 (iconsn) iconsn : ∀ t n,t → ilistn t n → ilistn t (n + 1) iconsn t n t ln (first n) := t iconsn t n t ln (succ n i′) := ln i′ definition 17 (icons) icons t t l := 〈lgti l + 1, iconsn t (fcti l))〉 the basic notions on lists are the head and the tail. therefore, to be able to manipulate elements of ilist as lists we need functions that allow us to get the head and the tail of an element of ilist. these functions are defined as follows: definition 18 (ihead) in this definition, the parameter t of type t represents the default element returned by ihead in case the ilist parameter is empty. ihead : ∀t,ilist t → t → t ihead t 〈0, ln〉 t := t ihead t 〈n + 1, ln〉 t := ln (first n) definition 19 (itail) in case the ilist parameter is empty, itail returns an empty ilist (inil). itail : ∀t,ilist t → ilist t itail t 〈0, ln〉 := inil t itail t 〈n + 1, ln〉 := 〈n, ln◦succ〉 it is easy to show, in order to validate our definitions, that: ∀ t l t,lgti l > 0 → ilist_releq l (icons (ihead l t) (itail l)) remark 17 (manipulation of lists vs. manipulation of ilist) the functions defined previously allow to manipulate elements of ilist in a list way. however, this manipulation is not really well gcm 2010 12 / 24 eceasst suited for ilist, although one is usually more used to it. indeed, the notions of head and tail, basic for list, are not well adapted for ilist. elements of ilist are basically functions and it is not easier to get the first element than any other. actually, the basic notion on ilist is the notion of ith element while it is not a basic notion on lists. in the same fashion, adding an element to an ilist (icons) is a quite complex operation, while on lists it is done by a constructor. the conclusion of this is that even though lists and ilist are equivalent, the respective natural ways to manipulate them are quite different. remark 18 (notation) in the rest of this paper, we will use list-like notations for elements of ilist . in particular, we will write jk for inil and jx; y; z;...k for successive applications of icons to inil. 3 the refined definition of graph representation now, we can redefine the type graph using ilist and define various functions and properties on it. 3.1 definitions of graph and applyf2g the definition of graph is identical to the previous one, except that lists are replaced by ilist. we define it through the following constructor: definition 20 (graph, viewed coinductively) mk_graph : t → ilist (graph t )→ graph t now we can define the function applyf2g so that it respects the guardedness condition: definition 21 applyf2g f (mk_graph t l) := mk_graph ( f t) ( imap (applyf2g f ) l ) we call label and sons the two functions on graph that return respectively the element of t and the ilist part of a graph. they are such that the following lemma is correct: lemma 8 ∀g, g = mk_graph (label g) (sons g). remark 19 here we have the right to use leibniz equality to compare two elements of graph as they are definitionally equal for any g of the form mk_graph t l (and not only bisimulated). we can redefine example 2 and example 3 with our new definition of graph using the notations introduced in remark 18. example 5 (redefinition of finite_graph) finite_graph := mk_graph 0 jmk_graph 1 jfinite_graphkk example 6 (redefinition of infinite_graphn) infinite_graphn := mk_graph n jinfinite_graphn+1k 13 / 24 volume 39 (2011) coinductive graph representation 3.2 an equivalence on graph we can also define all the other tools we need. in particular, we can define an equivalence relation on graph. indeed, as elements of graph are coinductive, leibniz equality cannot be used here (it is just too fine-grained and cannot be established by coinduction), we need bisimulation. to illustrate this, figure 4 shows a situation where two graphs are not leibniz equal while we want them to be equivalent. indeed, those two graphs are different (graphically this is evident) but they unfold into the same infinite tree. so they actually represent the same element but have different (syntactic) representations. if one wanted to differentiate the 0 (resp. 1) nodes, one would have to use a richer type than only natural numbers. 0 1 (a) example of figure 1 0 1 0 1 (b) example of figure 1 unfolded once figure 4: example graphs that are equivalent but not equal to relate two elements of graph, we need (as we did for ilist) to relate their two parts. the label part is compared through an equivalence relation r on type t . for the sons part, that is represented by an ilist, we will use the equivalence relation defined on ilist: ilist_rel (see subsubsection 2.3.3). as the type parameter for the ilist is itself graph, ilist_rel needs the equivalence relation on graph as argument. so this relation must be defined coinductively. finally, we can define the equivalence relation on graph (let’s call it geq) as follows (defined co-inductively): definition 22 (geq) ∀ t r g1 g2, geqr g1 g2 ⇔ r (label g1) (label g2) ∧ ilist_relgeqr (sons g1) (sons g2) it is possible to show that geq is an equivalence relation using the same style of reasoning as for ilist_rel. example 7 (equivalence of the graphs of figure 4) the graph of figure 4(b) can be defined in our definition of graph as follows: finite_graph_unfolded := mk_graph 0 jmk_graph 1 jmk_graph 0 jmk_graph 1 jfinite_graph_unfoldedkkkk it is easy to show geqeq finite_graph finite_graph_unfolded. the proof is a simple coinduction. the definition of finite_graph only has to be unfolded once. gcm 2010 14 / 24 eceasst remark 20 to be equivalent, two elements of graph have to be constructed in the same way. therefore, the two graphs of figure 1 and figure 5 are not equivalent even though we might wish them to be, if we disregard roots. we are working on the design of a coarser relation for this purpose. 1 0 this graph is represented by the following expression using definition 20: finite_graph′ := mk_graph 1 jmk_graph 0 jfinite_graph′kk figure 5: other representation of the graph of figure 1, disregarding roots 3.3 universal quantification on graph as we did with ilist (see subsubsection 2.3.7), we define a property of universal quantification on graph. it will be useful, in particular in subsection 3.4. this property expresses that a predicate p : graph t → prop on graph is satisfied by an element g of graph and all its descendants (sons, sons of its sons, and so on). as graph is co-inductive, this property must be defined co-inductively too. we call it g_all and it is defined as follows: definition 23 (g_all) ∀ p g, g_all p g ⇔ p g ∧ iall (g_all p) (sons g) 3.4 finiteness of graph another interesting property on graph is finiteness. it would be interesting for example to prove that example 2 and example 3 indeed are respectively finite and infinite. saying that an element g of graph is finite means that it contains a finite number of elements of graph, up to bisimilarity. this can be expressed by the fact that all the elements of graph contained in g can fit into a finite list. this is the way we choose to define the finiteness of a graph. we call the finiteness property g_ finite. to define it, we need a predicate (let’s call it element_of ) to check whether an element g of graph is included in a list of graphs. by included we mean that there is an element of the list that is related through bisimulation (geqr for the chosen r) with g. we use ∈ to say that an element is in a list. definition 24 element_of r l g :=∃y, y ∈ l ∧ geqr g y thanks to it we can define g_ finite. definition 25 (g_ finite) ∀g, g_ finiter g :⇔∃l, g_all (element_of r l) g 15 / 24 volume 39 (2011) coinductive graph representation 3.5 proofs of finiteness and infiniteness we want here to prove that example 2 and example 3 are respectively finite and infinite. the equivalence relation on labels used here is leibniz equality as the labels are natural numbers. first we prove that example 2 is finite. lemma 9 (finite_graph is finite) g_ finiteeq finite_graph. proof (by co-induction). the proof here is quite easy. we must give a list l with all the elements of graph contained in finite_graph and show that they are actually all included in l. there are only two elements of graph contained in finite_graph: finite_graph itself and mk_graph 1 jfinite_graphk. the provided list is: [finite_graph ; mk_graph 1 jfinite_graphk]. now, we only have to prove that finite_graph is contained in the list (but it was designed for it!); that its sons are (it only has one son: mk_graph 1 jfinite_graphk, so it is in the list) and that the sons of its son are in the list too (this is finite_graph itself, so we use the co-inductive hypothesis). similarly, we want to prove that infinite_graphn is not finite. lemma 10 (infinite_graphn is infinite) ∀n, ¬ g_ finiteeq infinite_graphn. to prove this we prove a general lemma that we will then instantiate to say that if the graph is finite then its labels are bounded (lemma 12). the general lemma says that for any function f of type graph t → nat and for any element g of graph, if g is finite then the image of the set of nodes of g by f is bounded. actually, to prove this lemma we need a property that says, basically, that f is a morphism, i. e., that ∀ g1 g2, geqr g1 g2 ⇒ f g1 = f g2. we abbreviate this property morphr( f ). lemma 11 ∀ f g, morphr( f )∧g_ finiter g ⇒∃m, g_all (λ g′. f g′ ≤ m) g. proof. the proof here is based on a simple idea: as g is finite, there exists a list l containing all the nodes of g (see definition 25). therefore, the image of the set of nodes of g by f can actually be represented by map f l (possibly containing duplicates). as l is finite, map f l also is. what is more, map f l has type list nat, therefore, the values contained in it are bounded. we call max the maximum. as all the nodes contained in g are also in l, we can show (by co-induction on g) that g_all (λ g′. f g′ ≤ max) g. now, we can prove the following lemma (for t = nat): lemma 12 ∀g,g_ finiteeq g ⇒∃m, g_all (λ x.label x ≤ m) g. proof. this lemma is actually just an instantiation of lemma 11 with f = label. we directly have the property that ∀ g1 g2, geqeq g1 g2 ⇒ f g1 = f g2 thanks to the definition of geq. now, to prove lemma 10, we only have to prove that the labels of infinite_graphn are unbounded and we will have the result simply using lemma 12. to prove that the labels of infinite_graphn gcm 2010 16 / 24 eceasst are unbounded, we show that ∀m,m ≥ n ⇒ infinite_graphm ⊆ infinite_graphn. remark 21 we informally use the notation ⊆ to say that a graph is included in another. with this, it is easy to show that the labels are unbounded (since the first label of infinite_graphn is n). remark 22 in a similar way, we have that if the number of sons in a graph is unbounded, then the graph is infinite. however, it is also possible to construct elements of graph in which the out-degree of a node is bounded and so are the labels and that are still infinite, see figure 6 for an example. here, the proof of infiniteness is much more difficult (it is part of [pm11]). 0 1 0 0 1 0 0 0 1 ... figure 6: example of an infinite graph with bounded number of sons and bounded labels 3.6 graph in graph we will need to represent the property asserting that an element gin of graph is (strictly) included in another element gout of graph (see subsection 3.7). we split the situation into two different cases: gin is part of sons gout or gin is included in one of gout ’s sons. in coq, the following definition is represented as an inductive property with two constructors. definition 26 (ging) ∀ t r gin gout, gingr gin gout ⇔ { ∃i, geqr gin (fcti (sons gout) i) or ∃i, gingr gin (fcti (sons gout) i) we can prove that gingr is transitive if r is transitive. 3.7 cycles in graph it may also be useful to define a property about the existence of a cycle in an element of graph. to do so, we use the property ging defined above. first of all, we define a property saying that an element g of graph is itself a cycle (i. e., there is a non-empty path from the root to the root). this means that g is itself included in g. therefore the definition of iscycle is straightforward. definition 27 (iscycle) ∀ t r g, iscycler g ⇔ gingr g g using this definition, it is easy to define the property of existence of a cycle in an element g of graph. just as we did for ging, we divide the property into two cases. either g is a cycle or one 17 / 24 volume 39 (2011) coinductive graph representation element of sons g has a cycle. as before, in coq this is defined through two constructors of an inductive definition. definition 28 (hascycle) ∀ t r g, hascycler g ⇔ { iscycler g or ∃i, hascycler (fcti (sons g) i) for a finite element of graph, it is quite easy to prove the existence or non-existence of a cycle (for example, it is straightforward to prove that example 5 has a cycle). however, if there are many nodes, the proof might be long. indeed, the proofs are constructive, that is, one will have to exhibit the cycle to prove that it exists or to look into each different path to show that there is none. this last operation may be tedious. 4 towards metamodel representation as we have explained in section 1, our final goal is to represent metamodels and then perform transformations on these models. until now, we only have shown graph representation. it is a first step towards metamodel representation, but metamodels have other properties that we can not represent with graph as it is. we present here two extensions of our development that bring us closer to metamodel representation. the first one is a representation of non-connected graphs and the second one a representation of multiplicities. another problem that arises and that is not treated here is the representation of inheritance. 4.1 a representation of a wider class of graphs as we have said in remark 3, the type graph only represents single-rooted connected graphs. however, there might be some cases where a more general graph representation could be necessary. for instance, a metamodel may not be connected or not single rooted. we present here a graph representation that allows to represent non-connected and non-single-rooted graphs. the idea is to add fictitious nodes to our previous definition of graph in order to be able to represent in only one structure non-connected graphs. example 8 to illustrate this, and before giving the formal definition, here is an example of what we might want to represent (figure 7(a)) and an example of its representation with fictitious nodes (figure 7(b)). we are going to represent those fictitious nodes with the usual option type of functional languages. when the label associated to a node is of the form some t, the node is a “real” node (and its label is t) and when it is of the form none, it is a fictitious node. therefore, we see that we can actually represent this extension of graph as an instance of graph. definition 29 (allgraph) allgraph t := graph (option t ) example 9 (representation of example 8) the graph of figure 7(b) is represented as follows gcm 2010 18 / 24 eceasst 0 1 2 3 (a) graph to represent 0 1 2 3 (b) symbolic representation figure 7: representation of a non-connected graph with definition 29: let g2 : allgraph nat := mk_graph (some 2) jk in mk_graph none jmk_graph (some 0) jg2k ; mk_graph (some 1) jg2k ; mk_graph (some 3) jkk as we use the previous definition of graph to define allgraph, all the definitions and lemmas on graph are still valid on allgraph. for instance, we can use geq to compare two elements of allgraph, for which we typically lift the relation r on t canonically to a relation on option t . 4.2 multiplicity in this section, we present an extension of ilist to represent multiplicities in metamodels representation. for this, we have extended the concept of ilist to take into account multiplicity, i. e., an interval constraint on the out-degree. remark 23 here we deviate a little from the graph representation of this article. indeed, in graphs (at least as we have represented them here), the labels of all the nodes have the same type. but in metamodel representation, this is not true. that is why we cannot use graph in the rest of this section. 4.2.1 presentation of the problem on an example to illustrate the usefulness of multiplicities, consider the following example of figure 8. to represent this using the tools we currently have at our disposal, we would define a, b and c (simultaneously) as follows (these definitions are to be interpreted co-inductively): mk_ a : ilist b → ilist c → a mk_ b : c → b mk_c : b → b →c here, various problems arise: 19 / 24 volume 39 (2011) coinductive graph representation a b c ∗ 1..10 1 2 figure 8: example of a metamodel with multiplicities • to represent the 1..10 multiplicity of the edge a to c, we might explicitly enumerate all possibilities with increasing numbers of arguments but this is heavy for large numbers and even impossible for indeterminate bounds. since list is not an option, we see no other good choice than using ilist. however, we lose the bounds (taking ilist c is equivalent to a multiplicity ∗) and therefore, information, • the representation is not homogeneous. here, there are two different ways to represent an edge with multiplicity: – an ilist for a variable multiplicity (e. g., ∗ or 1..10) – a sequence of t → t → ...→ t for a fixed multiplicity (e. g., 2) hence, an extension of ilist that allows to take into account multiplicities would solve these two issues. this is what we present now. 4.2.2 implementation of multiplicities first we need a property (let’s call it propmult) to say whether a number is between the two specified bounds of the multiplicity condition. the inferior bound (let’s call it inf ) always exists (it can be 0 but always has a value). therefore it has type nat. on the opposite, the superior bound (let’s call it sup) may not exist (multiplicity “∗”). therefore it has type option nat (constructor some if it exists, constructor none if not). the property is expressed as follows: definition 30 (propmult) ∀ inf sup k, [case sup = some s] k ≥ inf ∧k ≤ s [case sup = none] k ≥ inf thanks to this property we can refine our ilistn (that was the set of functions of type fin n → t ) to keep only the ones whose n satisfies propmult. definition 31 ilistnmult t inf sup n :={ln : ilistn t n | propmult inf sup n} remark 24 elements of ilistnmult are pairs formed by an element of ilistn and a proof of propmult inf sup n, hence the type is empty if propmult inf sup n does not hold. using ilistnmult, the definition of ilistmult (the counterpart of ilist with multiplicity) is straightforward. it is the same as the definition of ilist (see subsubsection 2.3.2) but using ilistnmult. gcm 2010 20 / 24 eceasst definition 32 ilistmult t inf sup := σn : nat.ilistnmult t inf sup n we can define a relation and functions on ilistmult very much the same way as we did on ilist. therefore we do not present them here again. we can also show that there is a bijection between ilistmult t 0 none and list (we do it the same manner we did for ilist, defining ilistmult2list and list2ilistmult and showing that their compositions are extensionally equal to the identity). remark 25 the multiplicities 0 and none are explained by the fact that a list may have no element (empty list, so inf = 0) or a finite but unbounded number of elements (i. e., multiplicity “∗”, so sup = none). combining the lemmas about bijection between lists, ilist and ilistmult, we obtain that there is a bijection between ilist t and ilistmult t 0 none. the important result is that all definitions written with ilist t can be written equivalently with ilistmult t 0 none. in particular, the following definition of graphmult is equivalent to graph: definition 33 (graphmult) mk_graphmult : t → ilistmult graph 0 none → graph with this definition of ilistmult, the example of figure 8 would be represented as follows (a, b and c are still defined simultaneously and co-inductively): mk_ a : ilistmult b 0 none → ilistmult c 1 (some 10)→ a mk_ b : ilistmult c 1 (some 1)→ b mk_c : ilistmult b 2 (some 2)→c these definitions are homogenous and complete (no information is lost). 5 related work and conclusion the work presented here shares concerns with other work. among them, we can cite the work by bertot and komendantskaya in [bk08]. in their paper they treat the problem of representing streams as functions, to overcome guardedness issues in coq. the main difference is that we need a finite definition set (fin n) whereas they can just use nat. recall that our problem was with the embedded inductive type of lists and not the co-inductive streams. in [dam10], dams proposes an alternative solution to our problem in coq. he defines everything co-inductively (so instead of lists, he has streams of sons) and then restricts what needs to be finite by a property of finiteness. in that approach, programming is done with a bigger datatype and the proofs have to be carried out for the “good” elements. in [niq08], niqui describes a general solution for the representation of bisimulation in coq using category theory. however, as we tried to apply his theory, it seemed that only co-inductive embedded types could be treated (streams but not lists) with the given solution. moreover, it did not seem possible to parameterize the bisimulation by an equivalence relation over the types of the elements. coq is not the only proof assistant to have guardedness issues. for example, they are present 21 / 24 volume 39 (2011) coinductive graph representation in agda3, another proof assistant based on predicative type theory. we studied the way guardedness issues are addressed in agda. danielsson describes it in [dan10] (see also the extended case study with altenkirch in [da10]). the solution used is to redefine the types (for example the types of lists) adding a constructor for each problematic function (for example, map). however, this is based on a mixture of inductive and co-inductive constructors for a single datatype definition, which is not admissible in coq and of experimental status even in agda. about graph representation in functional languages, we can mention the work by erwig. [erw01] proposes a way to represent directed graphs using inductive types, where, in the inductive step, a new node is added, together with all its edges to and from previously introduced nodes. being "new" or "previously introduced" is not part of the inductive specification but only of a more refined implementation. moreover, there is no certification of these invariants for graph algorithms, although this might be interesting future work in expressive systems such as coq. however, the main conceptual difference to our work is that in his representation, all nodes are represented at the same level (they are more or less elements of a list) while we actually wanted, for our own needs, to build into the construction navigability through the graph, including its loops. to conclude, in this paper, we have developed a complete solution to overcome coq’s guardedness condition when mixing the inductive type of lists with co-inductive types. the coq development corresponding to this work is available in [pm11]. this framework can be extended with new features as needed. for the results we wanted to obtain, it worked well. clearly, it would have been easier if a more refined guardedness criterion had been available in coq but the last ten years have shown that getting the criterion right is a quite subtle issue. another solution would have been to use another proof assistant instead of coq. nevertheless, for further developments, we needed a system based on type theory. furthermore, despite the guardedness restrictions, coinductive types in coq are quite practical to use. they are an addition to the original cic, hence a part of the kernel. as such, they are subject to discussion about justification and optimization, and there is quite some on-going scientific work around them in the coq community. however, we would now be interested in a more general solution to overcome the guardedness condition with any embedded inductive type (not only lists). but we realized that to do so, we needed to be more abstract. in particular, we think that we could draw inspiration from category theory. the work by niqui in [niq08] might be a good start. moreover, the work we present has to be seen as part of a larger project where we are interested in a co-inductive representation of metamodels (see subsection 4.2). we have solved the problem of multiplicity and non-connected graphs but the problem of inheritance/subtyping remains. this is difficult since we look for an extensible way to represent metamodels (they may vary over time). poernomo’s work on type theory for metamodels in [poe08] is relevant here. the work by boulmé on focal [bou00] that has been realized with coq, will probably help in treating the inheritance problem. finally, and still within the aim of representing metamodels, we are working on the design of a more liberal equivalence relation on graph. acknowledgements: this development was initiated by the original idea of jean-paul bodeveix to use ilist to overcome the guardedness condition. we are grateful for several interesting suggestions by silvano dal zilio and for the careful reading of a preliminary version by martin 3 http://wiki.portal.chalmers.se/agda/pmwiki.php gcm 2010 22 / 24 eceasst strecker. we are grateful for the feedback we got for the preliminary version presented at the workshop gcm’10 [pm10]. bibliography [alt93] t. altenkirch. a formalization of the strong normalization proof for system f in lego. in bezem and groote (eds.), typed lambda calculi and applications, international conference, tlca 1993. lecture notes in computer science 664, pp. 13–28. springer, 1993. [bdd09] s. berardi, f. damiani, u. de’liguoro (eds.). types for proofs and programs, international conference, types 2008, torino, italy, march 26-29, 2008, revised selected papers. lecture notes in computer science 5497. springer, 2009. [bir01] r. s. bird. maximum marking problems. j. funct. program. 11(4):411–424, 2001. [bk08] y. bertot, e. komendantskaya. using structural recursion for corecursion. pp. 220– 236 in [bdd09]. [bou00] s. boulmé. specifying in coq inheritance used in computer algebra. research report, lip6, 2000. available on www.lip6.fr/reports/lip6.2000.013.html. [chl10] a. chlipala. posting to coq club in the thread “is coq being too conservative?”. january 2010. http://logical.saclay.inria.fr/coq-puma/messages/d71fd3954d860d42# msg-285229ea3f28adef [coq93] t. coquand. infinite objects in type theory. in barendregt and nipkow (eds.), types for proofs and programs, international conference, types 1993. lecture notes in computer science 806, pp. 62–78. springer, 1993. [da10] n. a. danielsson, t. altenkirch. subtyping, declaratively. in bolduc et al. (eds.), mathematics of program construction (mpc’10). lecture notes in computer science 6120, pp. 100–118. springer, 2010. [dam10] c. dams. posting to coq club in the thread “is coq being too conservative?”. january 2010. http://logical.saclay.inria.fr/coq-puma/messages/d71fd3954d860d42# msg-7946fd74eb4de604 [dan10] n. a. danielsson. beating the productivity checker using embedded languages. in bove et al. (eds.), proceedings workshop on partiality and recursion in interactive theorem provers. eptcs 43, pp. 29–48. 2010. [erw01] m. erwig. inductive graphs and functional graph algorithms. j. funct. program. 11(5):467–492, 2001. 23 / 24 volume 39 (2011) www.lip6.fr/reports/lip6.2000.013.html http://logical.saclay.inria.fr/coq-puma/messages/d71fd3954d860d42#msg-285229ea3f28adef http://logical.saclay.inria.fr/coq-puma/messages/d71fd3954d860d42#msg-285229ea3f28adef http://logical.saclay.inria.fr/coq-puma/messages/d71fd3954d860d42#msg-7946fd74eb4de604 http://logical.saclay.inria.fr/coq-puma/messages/d71fd3954d860d42#msg-7946fd74eb4de604 coinductive graph representation [gc07] e. giménez, p. castéran. a tutorial on [co-]inductive types in coq. 2007. www.labri.fr/perso/casteran/rectutorial.pdf [mm04] c. mcbride, j. mckinna. the view from the left. j. funct. program. 14(1):69–111, 2004. [niq08] m. niqui. coalgebraic reasoning in coq: bisimulation and the lambda-coiteration scheme. pp. 272–288 in [bdd09]. [pm10] c. picard, r. matthes. coinductive graph representation: the problem of embedded lists. in echahed et al. (eds.), gcm 2010, the third international workshop on graph computation models. pp. 133–147. 2010. online available at the workshop’s website http://gcm2010.imag.fr/. [pm11] c. picard, r. matthes. formalization in coq for this article. 2011. www.irit.fr/~celia. picard/coq/coind_graph/. [poe08] i. poernomo. proofs-as-model-transformations. in vallecillo et al. (eds.), international conference on model transformation, icmt 2008. lecture notes in computer science 5063, pp. 214–228. springer, 2008. [tcdt] the coq development team. the coq proof assistant reference manual. http://coq.inria.fr gcm 2010 24 / 24 www.labri.fr/perso/casteran/rectutorial.pdf http://gcm2010.imag.fr/ www.irit.fr/~celia.picard/coq/coind_graph/ www.irit.fr/~celia.picard/coq/coind_graph/ http://coq.inria.fr the problem: explanation on an example the solution: ilist the idea fin – a family of types for finite index sets ilist implementation the type of functions ilistn the list counterpart, ilist an equivalence on ilist bijection between ilist and lists functions on ilist imap universal quantification manipulation of ilist in list fashion the refined definition of graph representation definitions of graph and applyf2g an equivalence on graph universal quantification on graph finiteness of graph proofs of finiteness and infiniteness graph in graph cycles in graph towards metamodel representation a representation of a wider class of graphs multiplicity presentation of the problem on an example implementation of multiplicities related work and conclusion algebraic model checking electronic communications of the easst volume 26 (2010) manipulation of graphs, algebras and pictures essays dedicated to hans-jörg kreowski on the occasion of his 60th birthday algebraic model checking peter padawitz 22 pages guest editors: frank drewes, annegret habel, berthold hoffmann, detlef plump managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst algebraic model checking peter padawitz tu dortmund, germany abstract: three algebraic approaches to model checking are presented and compared with each other with respect to their range of applications and their degree of automation. they have been implemented and tested in our haskell-based formalreasoning and -presentation system expander2. besides realizing and integrating state-of-the-art proof and computation rules the system admits the co/algebraic specification of the models to be checked in terms of rewrite rules and functional-logic programs. it also offers flexible features for visualizing and even animating models and computations. this paper does not present purely theoretical work. due to the increasing abstraction potential of programming languages like haskell, traditional gaps between specification formalisms and their executable implementations as well as between systems developed in different communities are going to vanish. the topics discussed in this article and the way of their presentation reflect this fact. keywords: model checking, algebra, coalgebra, functional programming, induction, coinduction, fixpoint theorems 1 introduction model checking means proving properties of labelled or unlabelled transition systems (trs). modal, temporal or dynamic logics have been developed to formalize the properties and provide methods for proving them (see, e.g., [4, 14, 29]). in contrast to classical predicate logic, modal logics hide the relations (here: the transition systems) they are talking about. translations of the latter into the former are well-known (see, e.g., [1, 20]), but did not affect very much the direction of research in model checking. with the invention of coalgebraic logics (see, e.g., [15, 28, 16, 11, 2]) the direction of translation is reversed: these logics generalize the ‘relation-hiding’ concept of modal logics from merely unstructured states and transitions to arbitrary destructor-based types and thus open up alternatives to classical predicate-logic-based data type verification. moreover, the use of coalgebraic concepts reveals the intrinsic algebraic flavor of modal logics: their formulas denote (unary) relations; the logical operators (including fixpoint operators!) are functions building relations from relations. this approach is sometimes called “global” in contrast to the “local” one that starts out from a satisfiability relation between states and formulas (see, e.g., [18]). mathematically, both views on the semantics of modal logics are equivalent: the global one just turns the satisfiability relation of the local view into a function from formulas to sets of states. in both cases the data modal logics deal with states and thus with elements of a destructor-based type, or with paths, which also form a destructor-based type. we have investigated and implemented in the prover part of expander2 [22, 23, 24] four approaches to model checking. the first one may be called purely algebraic because the proof of a formula boils down to term evaluation. in the second one, formulas are proved by solving sets of 1 / 22 volume 26 (2010) algebraic model checking regular equations represented by data flow graphs. the third technique uses simplification rules and must accompany the first one if, for instance, the underlying type has infinitely many elements (such as the set of paths of a trs). the fourth method applies co/horn logic, extends the others by powerful inference rules (mainly parallel co/resolution and incremental co/induction) and thus imposes the fewest restrictions on the formulas to be proved. on the other hand, this technique requires more manual control of the proof process than the others. for lack of space the present paper skips the data flow approach. the other methods are illustrated mainly with a couple of axiomatic specifications of small kripke structures and the verification of properties given by state or path formulas. more and larger examples can be found in [25] and the examples directory of expander2. this system has also created all graphics and proof records presented in this paper. to a great extent, expander2 specifications follow the syntax of the functional programming language haskell (see haskell.org) with which we assume a little familiarity. we also use haskell for some definitions that involve data structures like lists or trees. neither a purely set-theoretical notation nor an—unfortunately still prevailing— imperative syntax can cope with the elegance and adequacy of haskell. although it is long ago, the extremely inspiring work with hans-jörg kreowski (and my supervisors hartmut ehrig and dirk siefkes) at the computer science department of the technical university of berlin, lasting from 1974 to 1983, have influenced the direction of my research over the entire subsequent 25 years. we worked in three areas: automata theory, graph grammars and algebraic software specification. in all of them, constructions and methods from universal algebra played the key rôle. my additional work on horn logic and rewrite systems was also led by the algebraic viewpoint. last not least, graph grammar concepts left their mark on the treatment of term graphs in expander2. 2 kripke structures in expander2 since we want to use the same techniques for several variants of transition systems and modal logics, the following definitions take into account deterministic and nondeterministic, labelled and unlabelled systems as well as state and path formulas: a kripke structure k = (q, at, lab,trans,transl, value, valuel) consists of sets q, at, lab of states, at of atoms and lab of labels (actions, input, output, etc.), respectively, transition relations trans : q →℘(q) and transl : q×lab →℘(q) and atom valuations value : at → ℘(q) and valuel : at ×lab →℘(q). usually, either trans or transl and either value or valuel are empty. for an empty transl, the set of paths of k is given by path(k) = {p∈qn |∀ i∈n : pi+1 ∈ trans(pi)}∪ ⋃ n∈n {p∈qn |∀ 1≤ i < n : pi+1 ∈ trans(pi)} and analogously for an empty trans. given a function f : q → p(q), imgsshares(qs)( f )(qs′) = {q ∈ qs | f (s)∩qs′ 6= /0}, imgssubset(qs)( f )(qs′) = {q ∈ qs | f (s) ⊆ qs′} denote the sets of states q ∈ qs such that at least one resp. all f -images of q are in qs′. expander2 admits the specification of kripke structures in terms of rewrite rules as in the following example. festschrift h.-j. kreowski 2 / 22 eceasst -trans defuncts: drawft defined functions fovars: x y first-order variables axioms: states == [0] & initial states (x < 6 & x ‘mod‘ 2 = 0 ==> x -> branch$[x,x+1]) & (x < 6 & x ‘mod‘ 2 =/= 0 ==> x -> x+1) & 6 -> branch$[1..5]++[7..10] & 7 -> 14 & drawft == wtree$fun(sat$x,frame$text$x,x,x) after trans has been parsed, the simplifier of expander2 constructs a kripke model from a list of initial states (here: [0]) and (horn clause) axioms for the built-in binary predicate →. the set of states that are reachable w.r.t. → from the initial ones is assigned to the constant states. the resulting transition relation is presented in fig. 1. trans has no atoms. since we perform modal-logic reasoning within predicate logic, atom valuations are usually represented in terms of predicates on states (like (< 4) in fig. 3) and not in terms of functions as in the definition of a kripke structure. however, if an atom valuation shall be displayed or manipulated, we also need a functional representation of the predicates—as, for instance, in the specification mutex of section 3. fig. 1. the term graph representing the transition relation derived from trans and its interpretation by the matrix interpreter of expander2 branch, wtree, sat, frame and text are built-in constructors. an implicational axiom of the form ϕ ⇒ t → branch[t1, . . . ,tn] means that for all ground instances q of the term (= state pattern) t that satisfy ϕ , the corresponding instances of t1, . . . ,tn are direct successors of q. sat is attached to all nodes of the transition graph that represent states satisfying a given formula (see figs. 3 and 6). a term of the form wtree( f )(t) is simplified into a term with graphical attributes (here: frame and text) at some nodes of t by applying the function f to each node. for instance, in the axiom for drawft, f is given by the term fun(sat$x,frame$text$x,x,x), which represents the λ -abstraction λ n. case n of sat(x) → frame(text(x)) n → x. the attributes are interpreted by the painter module: if a node (term) n has the form sat(t), the subterm t is turned into its text representation and framed by a rectangle, while other nodes do 3 / 22 volume 26 (2010) algebraic model checking not obtain a graphical attribute and thus will be displayed by default. fig. 3 provides an example of a term t and the result of interpreting the simplication of drawft(t). & and | denote conjunction resp. disjunction. equational axioms involving == are used as simplification rules (see below). the apply-operator $ and list functions like concatenation (++), map and filter are defined as usually. the solver module of expander2 always produces resp. transforms term graphs like the one in fig. 1. basically, term graphs are trees, but they may involve additional edges (those with tips). the solver module may display further term representations of a binary or ternary relation: a list of pairs resp. triples and a conjunction of regular equations (equations with a variable on one side). 3 modal logic and algebra we present well-known modal and temporal operators (see, e.g., [14, 29]) in a rigorously algebraic fashion that allows us to model-check finite kripke structures by pure term evaluation. the corresponding implementation in expander2 is illustrated at the specification trans of the previous section and a further one (mutex) based upon [14], example 3.1.1. let var be a set of variables denoting sets of states or paths (sequences of states). the words generated from sf resp. pf by the following context-free rules are called state formulas resp. path formulas: let at ∈ at, lab ∈ lab and x ∈ var. sf → at | true | false | ¬sf | sf ∨sf | sf ∧sf | sf ⇒ sf (1) sf → ex sf | ax sf | 〈lab〉sf | [lab]sf (2) sf → x | µ x.sf | ν x.sf sf → ef sf | af sf | eg sf | ag sf | sf eu sf | sf au sf pf → at | true | false | ¬pf | pf ∨pf | pf ∧pf | pf ⇒ pf (3) pf → next pf | 〈lab〉pf | [lab]pf (4) pf → x | µ x pf | ν x pf pf → f pf | g pf | pf u pf some of the above operators are subsumed by others. this is intended because the user shall be allowed to formalize conjectures as adequately as possible. the reduction to a minimal set of operators should be left to the model checker. ours will turn all formulas into equivalent ones that consist of propositional, next-step ((1) resp. (3)) and fixpoint operators ((2) resp. (4)). like every context-free grammar the one above defines an algebraic signature σ = (ps, s, op) with a set ps of primitive sorts (here: at, lab and x), a set s of further sorts, one for each nonterminal of the grammar, and a set op of operators, one for each rule of the grammar: a rule a→w becomes an operator of type v→a where v is the word consisting of the nonterminals of w (ε → a is the type of a constant). in the above case, σ-terms represent formulas, and proving the latter means evaluating the former with respect to a suitable interpretation of σ, i.e. a σ-algebra, say a. each sort s ∈ ps∪s is interpreted by a ‘carrier’ set sa and each operator f by a function f a whose domain and range comply with the interpretation of the sorts involved in the type of f . the nature of primitive sorts is to have the same interpretation in every σ-algebra a. hence at, festschrift h.-j. kreowski 4 / 22 eceasst lab and x are always interpreted as the given sets at, lab and var of atoms, labels and variables, respectively. the interpretation of sf and pf in a leads to functional domains: sf a = (var → p(q)) → p(q), pf a = (var → p(path(k))) → p(path(k)). in σ, each atom at becomes a constant of sort sf and also a constant of sort pf . both fixpoint operators (µ and ν ) have the types var × sf → sf and var × pf → pf . analoguous binding operators occur in other term languages as well, e.g., the abstraction and least-fixpoint operators λ resp. µ for building higher-order functions or the quantification operators ∀ and ∃ that come with an algebraic view on predicate logic. fixpoint operators are the main model builders. be it single objects (including functions of arbitrary order), types (sets of objects) or relations (predicates) of arbitrary arity, whatever cannot be constructed by simply combining given objects (resp. sets) conjunctiveor disjunctively, is defined as a solution of a system of regular equations between variables on the leftand terms/formulas on the right-hand side, i.e. as a fixpoint of the function induced by the equations. from the classical theory of recursive functions via the semantics of logic programming languages up to domain theory and universal co/algebra, fixpoints provide the link between description, computation and proof in all these approaches. the existence of a fixpoint requires the monotonicity of the functions used in the equations to be solved. its stepwise constructability requires the stronger property of (upward or downward) continuity. in the case of a modal formula ϕ , monotonicity is ensured if each free occurrence of x ∈ var in ϕ has positive polarity, i.e. the number of negations on the path from the binder of x (µ or ν ) to the occurrence is even. continuity is guaranteed if, in addition to the monotonicity requirement, the transition relation is image finite, i.e. for all q ∈ q and lab ∈ lab, trans(q) resp. transl(lab)(q) is finite. hence we assume that q is finite and all free variable occurrences in ϕ have positive polarity so that ϕ can be evaluated in the following extension of a to a σ-algebra, called the modal algebra over k. we omit the interpretation of temporal, i.e. path formula operators because—due to the infinity of path(k)—it cannot be implemented as directly as the interpretation of state formula operators. let s ∈ q, lab ∈ lab, ϕ, ψ ∈ pf a and b : var → p(q). at a(b) =def value(at) truea(b) =def q falsea(b) =def /0 ¬a(ϕ)(b) =def q\ϕ(b) (ϕ ∨a ψ)(b) =def ϕ(b)∪ψ(b) (ϕ ∧a ψ)(b) =def ϕ(b)∩ψ(b) ϕ ⇒a ψ =def ¬a(ϕ)∨a ψ ex a(ϕ) =def imgsshares(q)(sucs)◦ϕ “exists next′′ ax a(ϕ) =def imgssubset(q)(sucs)◦ϕ “always next′′ 〈lab〉a(ϕ) =def imgsshares(q)(sucsl(lab))◦ϕ [lab]a(ϕ) =def imgssubset(q)(sucsl(lab))◦ϕ xa(b) =def b(x) 5 / 22 volume 26 (2010) algebraic model checking (µ x)a(ϕ)(b) =def lfp(ϕ(λ y.b[y/x]))( /0) (ν x)a(ϕ)(b) =def gfp(ϕ(λ y.b[y/x]))(q) f [a/x] denotes an update of (the valuation or substitution) f : f [a/x](x) = a and for all y 6= a, f [a/x](y) = f (y). the functions lfp (least fixpoint) and gfp (greatest fixpoint) are defined (in haskell) as follows: lfp, gfp :: eq a => [a] -> ([a] -> [a]) -> [a] lfp f s = if fs ‘subset‘ s then s else lfp f fs where fs = f s gfp f s = if s ‘subset‘ fs then s else gfp f fs where fs = f s they transform a finite set by repeatedly applying f until it does not change any more. if lfp( f ) is applied to /0 or gfp( f ) to q, the iteration terminates and—by kleene’s fixpoint theorem—returns the least resp. greatest solution of the equation x = ϕ in p(q). all further operators of σ can be reduced to fixpoints, as one knows from the µ -calculus of modal logic (see, e.g., [29, 20]): ef(ϕ) = µ x(ϕ ∨ex (x)) “exists f inally′′ af(ϕ) = µ x(ϕ ∨(ex (true)∧ax (x))) “always f inally′′ eg(ϕ) = ν x(ϕ ∧(ax (false)∨ex (x))) “exists generally′′ ag(ϕ) = ν x(ϕ ∧ax (x)) “always generally′′ ϕ eu ψ = µ x(ψ ∨(ϕ ∧ex (x))) “exists until′′ ϕ au ψ = µ x(ψ ∨(ϕ ∧ax (x))) “always until′′ as demonstrated in section 2, the simplifier of expander2 derives k from a specification like trans. any modal formula ϕ can then be evaluated in the modal algebra over k by applying rule (1) below to the expression sols(ϕ) or rule (2) to the expression solsg(ϕ): (1) sols(ϕ) ϕ a (2) solsg(qs) transition graph of k with each state q ∈ qs replaced by sat(q) fig. 3. results of simplifying solsg$ef(< 4) (left) and graphically interpreting the simplification of drawf t $solsg$ef(< 4) (right) w.r.t. the specification trans of section 2: 0, . . . , 6 are all states from which a state less than 4 is reachable. festschrift h.-j. kreowski 6 / 22 eceasst the kripke structure derived from the following specification mutex models a system of n processes accessing a critical region. the model is specified along the lines of [14], example 3.3.1, where the system is described for two processes. in mutex, procs denotes the actual list of all processes. states are pairs (xs, ys) consisting of the list xs of waiting processes and the list ys of processes in the critical region. given two lists s and s′, s−s′ returns all elements of s that are not in s′. mutex has atoms idle(x), wait(x) and crit(x) for each process x. like transition relations, atom valuations are specified in terms of the built-in binary predicate →: t → branch[t1, . . . ,tn] means that for all ground instances at of the term (= atom pattern) t, the corresponding instances of the terms (= state patterns) t1, . . . ,tn satisfy at. the higher-order predicate atom turns kripke structure atoms into atomic formulas. logical operators are introduced as higher-order predicates and thus applied and composed like and in combination with higher-order functions. for instance, and$map(not.crit)[x, y, z] denotes a ternary predicate that is satisfied by all triples of processes outside the critical region. -mutex constructs: idle wait crit preds: idle wait crit crit’ atom live nonblock noseq /\ \/ ‘then‘ not and or ex ef af ag ‘eu‘ defuncts: procs drawk fovars: xs ys at ats axioms: states == [([],[])] & initial states atoms == map($) $ prodl[[idle,wait,crit],procs] & (xs,ys) -> branch $ map(fun(x,(x:xs,ys))) $ procs-xs-ys & x waits (xs =/= [] ==> (xs,[]) -> (init(xs),[last(xs)])) & last(xs) enters (xs,[x]) -> (xs,[]) & x leaves (idle(x)(xs,ys) <==> x ‘in‘ procs-xs-ys) & (wait(x)(xs,ys) <==> x ‘in‘ xs) & (crit(x)(xs,ys) <==> x ‘in‘ ys) & (atom$idle$x <==> idle$x) & (atom$wait$x <==> wait$x) & (atom$crit$x <==> crit$x) & (at ‘in‘ atoms ==> at -> branch $ filter(atom$at) $ states) & atom valuation (live$x <==> ag $ wait(x) ‘then‘ af$crit$x) & no infinite waiting (nonblock$x <==> ag $ idle(x) ‘then‘ ex$wait$x) & no blocking (noseq$x <==> ag $ ef $ crit(x) /\ (crit(x) ‘eu‘ (not(crit$x) /\ (crit’(x) ‘eu‘ crit$x)))) & no sequencing: a process may leave the critical region and enter it again before another process does so. (crit’$x <==> and(map(not.crit) $ procs-[x])) & 7 / 22 volume 26 (2010) algebraic model checking drawk == wtree $ fun((xs,ys),frame$matrix[wait$xs,crit$ys], sat((xs,ys),ats), frame$matrix[wait$xs,crit$ys,satisfies$ats]) & the graphical attribute matrix causes the elements of its argument list to be displayed as a matrix. drawk works analogously to drawf t defined in trans0 (see section 2). fig. 4. the kripke model derived from mutex for two processes after its transformation performed by drawk fig. 5. the result of simplifying solsg$and$map(live)[0, 1]: all states satisfy live(0) and live(1). 4 model checking by simplification a path formula like ∀ pa : ϕ(pa) quantifies over the infinite set of paths of the underlying kripke structure k and thus cannot be proved by simply evaluating it in the modal algebra over k: the festschrift h.-j. kreowski 8 / 22 eceasst implementation of the fixpoint operators µ and ν with the functions lfp and gfp of section 3 will not terminate. however, as fixpoint operators are ubiquitous in model design, so are the key proof rules expansion, induction and coinduction for properties of a—sometimes more-dimensional— fixpoint, say a = (a1, . . . , an). if a solves the equation (x1, . . . , xn) = t(x1, . . . , xn), expanding a term or formula ϕ means replacing occurrences of a in ϕ by (projections of the value of) t(a). expansion is sound for all solutions of the equation, but induction and coinduction only for the least resp. greatest one. expansion let op be a fixpoint operator, u = (t1, . . . ,tn) and 1 ≤ i ≤ n. op x1 . . . xn.t t[πi(op x1 . . . xn.t)/xi | 1 ≤ i ≤ n] πi(op x1 . . . xn.u) ti[π j(op x1 . . . xn.u)/x j | 1 ≤ j ≤ n] πi, 1 ≤ i ≤ n, denotes the projection of an n-tuple on its i-th component. in the case of unary fixpoints (like the modal operators µ and ν ), projections do not occur and we only need the first rule. in general, non-unary fixpoints arise from mutually recursive definitions of several functions or relations. for reducing the danger of non-termination expander2 applies expansion rules only to formulas that lack redices for other simplification rules. the simplifier traverses a formula tree depthfirst (leftmost-outermost) or breadthfirst (parallel-outermost) when searching for the next rule redex. the strategy of parallel-outermost simplification that postpones expansion steps as far as possible is a fixpoint strategy, i.e. terminates whenever any strategy terminates [17]. this suggests why the evaluation of path formulas in the modal algebra may not terminate: evaluation in an algebra always proceeds bottom-up and thus follows an innermost strategy! expansion rules are applied to the fixpoint itself. the redices of induction and coinduction, however, are implications with the fixpoint as its premise resp. conclusion: induction and coinduction µ x1 . . . xn.ϕ ⇒ ψ ϕ[πi(ψ)/xi | 1 ≤ i ≤ n] ⇒ ψ ⇑ ψ ⇒ ν x1 . . . xn.ϕ ψ ⇒ ϕ[πi(ψ)/xi | 1 ≤ i ≤ n] ⇑ the arrow ⇑ indicates that induction and coinduction are backward (reasoning) rules whose succedents imply the antecedents, but not necessarily vice versa. an important design goal of expander2 is to emphasize the view on proofs as computation sequences. hence our rule syntax reflects the order in which the rules are applied in a proof. even within a backward proof, expander2 may also apply forward rules (whose antecedents imply the succedents)—to subformulas with negative polarity (see section 3). most rules, however, are equivalence transformations, i.e., both backward and forward rules, and thus may be applied to any subformula of the current goal. the problem with pure backward rules is their narrowing effect: the succedent may never reduce to true, although the antecedent would do so if other rules where applied to the redex. in the case of co/induction, this means that the co/induction hypothesis, which is given by ψ , is too weak resp. too strong. ψ must then be generalized, i.e. extended to some δ by adding a factor resp. summand. obviously—and probably accounted for by the incompleteness of second-order logic—the candidates for δ cannot be enumerated. just for seeing the boundaries within which 9 / 22 volume 26 (2010) algebraic model checking δ must be searched for one may generalize co/induction as follows: second-order induction and coinduction µ x1 . . . xn.ϕ ⇒ ψ ∃δ : ((ϕ[πi(δ )/xi | 1 ≤ i ≤ n] ⇒ δ )∧(δ ⇒ ψ)) m ψ ⇒ ν x1 . . . xn.ϕ ∃δ : ((ψ ⇒ δ )∧(δ ⇒ ϕ[πi(δ )/xi | 1 ≤ i ≤ n])) m the soundness of (first-order) co/induction is easy to show: µ x1 . . . xn.ϕ and ν x1 . . . xn.ϕ denote solutions of the equation (x1, . . . , xn) = ϕ in the modal algebra a (see section 3). since the operators of ϕ a are monotone, the fixpoint theorem of knaster and tarski tells us that the least resp. greatest solution of (x1, . . . , xn) = ϕ in a is the least resp. greatest tuple b = (b1, . . . , bn) of sets such that (1) ϕ[bi/xi | 1 ≤ i ≤ n]a ⊆ b or (2) b ⊆ ϕ[bi/xi | 1 ≤ i ≤ n]a, respectively. since ⇒ is interpreted in a by set inclusion, the conclusion of co/induction is valid iff (1)/(2) with bi replaced by πi(ψ)a holds true. consequently, the rule antecedent follows from the minimality resp. maximality of b with respect to (1)/(2). since co/induction is part of the simplifier of expander2, the system takes care of not destroying co/induction redices. for instance, the following simplification rules are applied only to formulas that are not co/induction redices: implication splitting suppose that ϕ and ψ are simplified. ϕ ⇒ ψ1 ∧···∧ψn ϕ ⇒ ψ1 ∧ . . . ∧ ϕ ⇒ ψn m ϕ1 ∨···∨ϕn ⇒ ψ ϕ1 ⇒ ψ ∧ . . . ∧ ϕn ⇒ ψ m since generalizing a co/induction hypothesis ψ means adding a factor resp. summand to ψ , the co/inductive provability of the antecedent of implication splitting does not imply the co/inductive provability of the succedent! on the other hand, if implication splitting does not interfere with co/induction, it should be applied because it brings the redex closer to its disjunctive normal form. more crucial than such boolean trasnformations is the handling of quantified variables. here the simplifier shifts quantifiers towards existentially quantified conjunctions of equations and universally quantified disjunctions of inequations. these are then treated separately by term replacement, atom splitting and atom removal, which often reduces the number of variables or even deletes all of them. when simplifying a formula, expander2 first treats it as a term, i.e., evaluates it in a suitable algebra, say a, which involves a couple of built-in types including the modal algebra over the derived kripke structure (see section 3)—if there is any. as to the formula’s logical operators, a is a term algebra consisting of a kind of normal forms. for instance, an existential quantifier is merged with subsequent ones, distributed over subsequent implications and disjunctions and restricted to variables with free occurrences in the quantified formula. after having been evaluated in this way, the simplifier applies rules like the ones presented here or given by the equational or equivalence axioms of user-defined specifications. in contrast to the preceding (bottom-up) evaluation these rules are applied only to outermost redices. hence this level of simplification provides a possibility to model-check path formulas, which—due to the infinity of paths—cannot be evaluated in the modal algebra. so the following specification ltls introduces the temporal operators f , g, u and .tail (“next”) as higher-order predicates festschrift h.-j. kreowski 10 / 22 eceasst on (a coalgebraic specification of) streams, which represent the (infinite) paths of an arbitrary kripke structure k. k is derived from an extension of ltls such as micros (see below) via the built-in predicate → in the way kripke structures were derived from trans and mutex (see section 2). later proofs use the axioms of ltls as simplification rules along with expansion and co/induction. -ltls constructs: blink the stream 010101... preds: true false not /\ \/ ‘then‘ f g ‘u‘ p q fovars: at s hovars: x p q higher-order variables axioms: head$blink == 0 coalgebraic specification of blink & tail$blink == 1:blink dto. & (true$s <==> true) & (false$s <==> false) & (not(p)$s <==> not(p$s)) & ((p/\q)$s <==> (p$s & q$s)) & ((p\/q)$s <==> (p$s | q$s)) & ((p‘then‘q)$s <==> (p$s ==> q$s)) & (f$p <==> mu x.(p\/x.tail)) ‘‘finally’’ & (g$p <==> nu x.(p/\x.tail)) ‘‘generally’’ & ((p‘u‘q) <==> mu x.(q\/(p/\x.tail))) ‘‘until’’ the functions head and tail, which provide the destructors of a coalgebraic specification of streams, are defined as usually. the formula atom(at)$s checks whether the head of the path s satisfies at ∈ at (see section 2). the conjecture s = blink | s = 1:blink ==> g(f$(=0).head)$s (1) says that the streams blink and 1 : blink are fair insofar as they contain infinitely many zeros. by the g-axiom of ltls, (1) simplifies to: s = blink | s = 1:blink ==> nu x.(f((=0).head)/\x.tail)$s (2) (2) is an instance of the antecendent of coinduction (see above). applying the rule yields: all s:(s = blink | s = 1:blink ==> (f((=0).head)/\(rel(s,s=blink|s=1:blink).tail))$s) (3) rel is the λ -operator for predicates: rel(s, s = blink|s = 1 : blink) denotes the function that assigns to s the formula s = blink|s = 1 : blink. 47 further simplification steps including three expansion steps turn (3) into true. the entire proof goes through automatically. a further sample proof refers to a specification of a microwave controller [4]: -micros specs: ltls imported specification constructs: start close heat error 11 / 22 volume 26 (2010) algebraic model checking preds: start close heat error atom fovars: ats axioms: states == [1] & atoms == [start,close,heat,error] & 1 -> branch[2,3] & 2 -> 5 & 3 -> branch[1,6] & 4 -> branch[1,3,4] & 5 -> branch[2,3] & 6 -> 7 & 7 -> 4 & (atom$start <==> start) & (atom$close <==> close) & (atom$heat <==> heat) & (atom$error <==> error) & (start$x <==> x ‘in‘ [2,5,6,7]) & (close$x <==> x ‘in‘ [3,4,5,6,7]) & (heat$x <==> x ‘in‘ [4,7]) & (error$x <==> x ‘in‘ [2,5]) & (at ‘in‘ atoms ==> at -> branch$filter(atom$at)$states) atom valuation & drawk == wtree$fun(sat(x,ats), frame$matrix[x,satisfies$ats]) fig. 6. the kripke model derived from micros for two processes after its transformation performed by drawk festschrift h.-j. kreowski 12 / 22 eceasst the conjecture g(error.head)$s ⇒ g(not(heat).head)$s says that paths consisting of error states do not contain heat states. by the g-axiom of ltls, it simplifies to: nu x.((error.head)/\(x.tail))$s ==> nu x.((not(heat).head)/\(x.tail))$s applying the coinduction rule yields: all s:(nu x.((error.head)/\(x.tail))$s ==> ((not(heat).head)/\ (rel(s,nu x.((error.head)/\(x.tail))$s).tail))$s) 41 further simplification steps lead this formula to true. three expansion steps are needed, and the entire proof goes through automatically. 5 model checking within co/horn logic both evaluation (section 3) and simplification (section 4) regard modal formulas as representations of data, namely (tuples of) sets. that’s why we call this kind of model checking algebraic: the logical operators denote functions that create or transform data. fixpoint operators are no exception. they map the left-hand sides of regular equations to the equations’ solutions (see section 3). first-order predicate logic as well as logic programming follow a different view. their formulas do not denote data, but propositions or statements about data. set membership takes us from the sets-as-data view to the propositional one, set comprehension back from the propositional to the data view. so where is the difference? it comes with the fixpoint property that cannot be expressed within first-order logic. instead, we axiomatize co/predicates in terms of (generalized) co/horn clauses and fix their interpretation as least resp. greatest relations satisfying the axioms. details of this approach and its connection with relational and functional programming can be found in [19, 20, 23, 24]. here we apply it to modal logics by specifying modal and temporal operators in terms of co/horn axioms: -ctl preds: ex ef af ‘eu‘ ‘au‘ p q predicates copreds: ax eg ag copredicates fovars: st st’ hovars: p q axioms: (ex(p)$st <=== st -> st’ & p(st’)) & (ax(p)$st ===> (st -> st’ ==> p(st’))) & (ef(p)$st <=== p$st | ex(ef(p))$st) & (af(p)$st <=== p$st | ax(af(p))$st) & (eg(p)$st ===> p$st & ex(eg(p))$st) & (ag(p)$st ===> p$st & ax(ag(p))$st) & ((p‘eu‘q)$st <=== q$st | p$st & ex(p‘eu‘q)$st) & ((p‘au‘q)$st <=== q$st | p$st & ax(p‘au‘q)$st) -ltl preds: f ‘u‘ p q predicates copreds: g copredicates 13 / 22 volume 26 (2010) algebraic model checking fovars: s hovars: p q axioms: (f(p)$s <=== p$s | f(p)$tail$s) & (g(p)$s ===> p$s & g(p)$tail$s) & ((p‘u‘q)$s <=== q$s | p$s & (p‘u‘q)$tail$s) the direction of the implication arrow (<=== or ===>) determines whether the axiom is a horn or a co-horn clause and whether the leading relation symbol r is a predicate or a copredicate to be interpreted as the least resp. greatest relation satisfying all axioms for r. within a derivation, a co/horn clause is always applied from left to right. it may start with a guard γ that confines redices to formulas that unify with the left-hand side (premise resp. conclusion) and satisfy γ (see the co/resolution rules given below). expander2 accepts five types of formulas as axioms: let p be a predicate (including ->), q be a copredicate and t1, . . . ,tn be terms. (1) γ ==> (p(t1,...,tn) <==> ϕ) equivalence used for simplification (2) γ ==> (t1 == t2 <==> ϕ) equation used for simplification (3) γ ==> (p(t1,...,tn) <=== ϕ) horn clause used for resolution upon p (4) γ ==> (f(t1,...,tn) = u <=== ϕ) horn clause used for narrowing, i.e., functional resolution, upon f (5) γ ==> (q(t1,...,tn) ===> ϕ) horn clause used for coresolution upon q in all five cases, the axiom is applicable if the term/formula the axiom shall be applied to unifies with—in cases (1) and (2): matches—its redex and if the corresponding instance of the guard γ simplifies to true. here are (simplified versions of) the main rules for processing co/predicates. for lack of space we omit those that handle functions specified in terms of horn clauses (see above). parallel resolution upon the predicate p p(t)∨k i=1∃zi : (ϕiσi ∧~x =~xσi) m where γ1 ⇒ (p(t1) ⇐= ϕ1), . . . , γn ⇒ (p(tn) ⇐= ϕn) are the (horn) axioms for p. parallel coresolution upon the copredicate p p(t)∧k i=1∀zi : (~x =~xσi ⇒ ϕiσi) m where γ1 ⇒ (p(t1) =⇒ ϕ1), . . . , γn ⇒ (p(tn) =⇒ ϕn) are the (co-horn) axioms for p. ~x is a tuple of “new” variables and for all 1 ≤ i ≤ n, zi = var(ti)∪var(ϕi), σi is a unifier of t and ti and γiσi simplifies to true. like co/induction as simplication (see section 4), incremental coinduction can only be applied to implications with a predicate (the first-order analog of a variable bound by µ ) in the premise or a copredicate (the first-order analog of a variable bound by ν ) in the conclusion. in contrast to co/induction as simplification, we may now start a proof with the original conjecture and generalize it later—when simplification rules are no longer applicable and generalization festschrift h.-j. kreowski 14 / 22 eceasst candidates have emerged from preceding proof steps. incremental coinduction is also called circular [7, 12] and has recently been used to prove bisimilarities (behavioral equalities) induced by non-deterministic transition systems with structured states representing processes [27]. suppose that the formulas ψ and δ do not contain the co/predicate p. axp denotes the set of co/horn axioms for p. incremental induction upon the predicate p p(x) ⇒ ψ(x)∧ p(t)⇐ϕ∈axp (ϕ[p ′/p] ⇒ ψ(t)) ⇑ p′(x) ⇒ δ (x)∧ p(t)⇐ϕ∈axp (ϕ[p ′/p] ⇒ δ (t)) ⇑ p′ is a “new” copredicate that starts with the axiom p′(x) ⇒ ψ(x). when the second rule is applied, the co-horn clause p′(x) ⇒ δ (x) becomes a further axiom for p′. incremental coinduction upon the copredicate p ψ(x) ⇒ p(x)∧ p(t)⇒ϕ∈axp (ψ(t) ⇒ ϕ[p ′/p]) ⇑ δ (x) ⇒ p′(x)∧ p(t)⇒ϕ∈axp (δ (t) ⇒ ϕ[p ′/p]) ⇑ p′ is a “new” predicate that starts with the axioms p′(x) ⇐ ψ(x) and—only if p is behavioral equality—horn clauses establishing p′ as an equivalence relation. when the second rule is applied, the horn clause p′(x) ⇐ δ (x) becomes a further axiom for p′. co/resolution and co/induction complement each other in the way axioms work together with conjectures in proof: co/resolution applies axioms to conjectures and the proof proceeds with the modified conjectures, while co/induction applies conjectures to axioms and establishes the modified axioms as new conjectures. generalizations of co/resolution and co/induction for simultaneously proving properties of several co/predicates specified by mutual recursion and thus representing more-dimensional fixpoints are straightforward. for further details an co/horn logic and its implementation in expander2, consult [19, 20, 23, 24, 25]. incremental coinduction allows us to start a proof that the stream blink is fair (see section 4) with the original conjecture ψ = g(f $(= 0).head)$blink and derive within the proof of ψ the additional factor g(f $(= 0).head)$1 : blink of the conjecture (1) in section 4. indeed, incremental coinduction of ψ returns the goal all p s:(p = f((=0).head) & s = blink ===> p(s) & g0(p)$tail$s) (1) g0 is the “new” predicate p′ of incremental coinduction (see above). its first axiom is given by: g0(z0)$z1 <=== z0 = f((=0).head) & z1 = blink (ax1) six simplification steps transform (1) into: f((=0).head)$blink & g0(f((=0).head))$(1:blink) (2) parallel resolution upon f as specified in ltl (see above) and subsequent simplification steps remove the first factor of (2). the second factor is a redex for the second rule of incremental coinduction that turns (2) into: 15 / 22 volume 26 (2010) algebraic model checking all p s:(p = f((=0).head) & s = 1:blink ===> p(s) & g0(p)$tail(s)) (3) a second axiom for g0 is created: g0(z2)$z3 <=== z2 = f((=0) . head) & z3 = 1:blink (ax2) five simplification steps transform (3) into: f((=0).head)$(1:blink) & g0(f((=0).head))$blink (4) three resolution and subsequent simplification steps turn (4) into true. the conjecture g(error.head)$s ==> g(not(heat).head)$s of the specification micros in section 4 can also be proved within co/horn logic. once the imported specification ltls of micros has been replaced with ltl above, incremental coinduction turns the conjecture into: all s p:(g(error.head)$s & p = (not(heat).head) ===> p(s) & g0(p)$tail(s)) (1) g0 is the “new” predicate p′ of incremental coinduction. its first axiom is given by: g0(z0)$s <=== g(error.head)$s & z0 = (not(heat).head) coresolution upon g and simplification steps turn (1) into: all s:(g(error.head)$s ==> g0(not(heat).head)$tail(s)) (2) (2) admits both coresolution upon g and resolution upon g0. coresolution would lead into a cycle because the only axiom for g (see ltl) is recursive, i.e., g occurs on both sides of the axiom. the (above) axiom for g0, however, is non-recursive—as axioms for the “new” predicate p′ always are. hence we resolve upon g0 and obtain: all s:(g(error.head)$s ==> g(error.head)$tail(s)) (3) coresolution upon g and subsequent simplification steps turn (3) into true. 6 beyond model checking model checking can only be applied to individual kripke structures. even if built up from several transition systems communicating with each other, it is always a single structure one reasons about (see, e.g., [3, 4]). systems like mutex, however, are parameterized by certain components involved. indeed, mutex specifies many kripke structures, one for each (finite) number of processes. modal proofs must be carried out for each number of processes separately because kripke structures for different numbers of processes differ considerably from each other. among the three methods presented in this paper, it is only the last one that allows us to perform a single proof for all instances of a parameterized kripke structure. even then the underlying specification often needs to be revised, in order to capture all instances simultaneously. in the case of mutex, we came up with the following reformulation: festschrift h.-j. kreowski 16 / 22 eceasst -mutexco specs: ctl preds: idle wait crit enabled safe noseq >> copreds: others constructs: c defuncts: request enter leave posi maxwait weight fovars: xs ys xs’ ys’ axioms: (st >> st’ <==> weight(st) > weight(st’)) & weight(xs,ys) == (length(xs)-posi(c)(xs++ys), maxwait-length(xs),length$ys) & posi(x)$x:s = 0 & (posi(x)$y:s = suc$posi(x)$s <=== x =/= y) & (st -> f$st <=== enabled(f)$st) & (enabled(request$x)(xs,ys) <=== idle(x)(xs,ys) & maxwait > length$xs) & enabled(enter)(x:xs,[]) & enabled(leave)(xs,[x]) & request(x)(xs,ys) == (x:xs,ys) & enter(xs,ys) == (init$xs,[last$xs]) & leave(xs,ys) == (xs,[]) & (wait(x)(xs,ys) <==> x ‘in‘ xs) & (crit(x)(xs,ys) <==> x ‘in‘ ys) & (idle(x)(xs,ys) <==> x ‘notin‘ xs & x ‘notin‘ ys) & safe(xs,[]) & safe(xs,[x]) & (noseq$x <==> ef $ crit(x) /\ (crit(x) ‘eu‘ (not(crit$x) /\ (others(not.crit)(x) ‘eu‘ crit$x)))) & (others(p)(x)$st ===> (x =/= y ==> p(y)$st)) conjects: (c ‘in‘ xs | c ‘in‘ ys no infinite waiting ==> af(crit$c)(xs,ys)) (proof by noetherian induction w.r.t. >>) (idle(x)(xs,ys) & length$xs < maxwait no blocking ==> ex(wait$x)(xs,ys)) & (proof by resolution upon ex) (safe$st ==> ag(safe)$st) & safety of the critical region (proof by coinduction upon ag) again, states are pairs consisting of the lists of actually waiting resp. working processes. the transition relation is specified in terms of the “methods” request, enter and leave and the “attributes” idle, wait and crit. obviously, attributes correspond to atoms of a kripke structure. but they are more general because they may assign a value of arbitrary type to a each state, not just a boolean one. in the terminology of coalgebraic specifications, methods and attributes are destructors, like head and tail in ltls (see section 4). 17 / 22 volume 26 (2010) algebraic model checking parameterization by a natural number (here: the number of processes) suggests verification by noetherian induction. at least, the first conjecture of mutexco, which says that each waiting or working process c will work eventually—no matter which path the system takes—, could be proved by noetherian induction, but only with respect to a rather sophisticated lexicographic ordering on states that takes into account the position of c in the waiting list and the lengths of the waiting and working lists, respectively. the proof of “no blocking” is straightforward. a parameterized proof of “no sequencing” (see mutex in section 3) has not yet been tried. we close the section with the complete expander2 protocol of its proof of the last conjecture of mutexco: there is at most one process in the critical region. expander2 records each interactive proof in this way and also generates a proof term consisting of commands whose execution repeats the proof automatically. safe(st) ==> ag(safe)$st adding (ag0(z0)$st <=== safe(st) & z0 = safe) & (notag0(z0)$st ===> not(safe(st)) | z0 =/= safe) to the axioms and applying coinduction w.r.t. (ag(p)$st ===> p(st) & ax(ag(p))$st) at position [] of the preceding formula leads to all st:(safe(st) ==> ax(ag0(safe))$st) the reducts have been simplified. narrowing the preceding formula (1 step) leads to all st st’:(safe(st) & st -> st’ ==> ag0(safe)$st’) the axioms were matched against their redices. the reducts have been simplified. narrowing the preceding formula (1 step) leads to all st st’:(safe(st) & st -> st’ ==> safe(st’)) the axioms were matched against their redices. the reducts have been simplified. narrowing the preceding formula (1 step) leads to all st’ xs:((xs,[]) -> st’ ==> safe(st’)) & all st’ xs x:((xs,[x]) -> st’ ==> safe(st’)) festschrift h.-j. kreowski 18 / 22 eceasst the reducts have been simplified. narrowing the preceding formula (1 step) leads to all xs f:(enabled(f)(xs,[]) ==> safe(f(xs,[]))) & all st’ xs x:((xs,[x]) -> st’ ==> safe(st’)) the reducts have been simplified. narrowing the preceding formula (1 step) leads to all xs x0:(x0 ‘notin‘ xs & maxwait > length(xs) ==> safe(x0:xs,[])) & all xs0 x0:safe(init(x0:xs0),[last(x0:xs0)]) & all st’ xs x:((xs,[x]) -> st’ ==> safe(st’)) the reducts have been simplified. narrowing the preceding formula (1 step) leads to all xs0 x0:safe(init(x0:xs0),[last(x0:xs0)]) & all st’ xs x:((xs,[x]) -> st’ ==> safe(st’)) the reducts have been simplified. narrowing the preceding formula (1 step) leads to all st’ xs x:((xs,[x]) -> st’ ==> safe(st’)) the reducts have been simplified. narrowing the preceding formula (1 step) leads to all xs x f:(enabled(f)(xs,[x]) ==> safe(f(xs,[x]))) the reducts have been simplified. narrowing the preceding formula (1 step) leads to all xs x x3: (x3 ‘notin‘ xs & x3 =/= x & maxwait > length(xs) ==> safe(x3:xs,[x])) & all xs:safe(xs,[]) the reducts have been simplified. narrowing the preceding formula (1 step) leads to all xs:safe(xs,[]) the reducts have been simplified. 19 / 22 volume 26 (2010) algebraic model checking narrowing the preceding formula (1 step) leads to true the reducts have been simplified. number of proof steps: 12 7 conclusion we have shown a way of integrating kripke structures into algebraic specifications, presented three methods for proving their properties and illustrated their implementation and joint use in expander2. all three methods admit structured states represented as functional terms. moreover, the models may involve a labelled or unlabelled transition system (also called a kripke frame), a labelled or unlabelled atom valuation or a mixture thereof. the first method consists in evaluating modal formulas in an algebra where logical operators come as functions taking sets of states to sets of states. the evaluation procedure is part of the simplification component of expander2. some logical operators compute fixpoints. hence model checking by evaluation requires models with a finite set of states. the second technique extends the modal algebra of the first one by simplification rules, in particular by expansion, induction and coinduction. this allows us to prove not only state, but also path formulas and to verify kripke models with an infinite state space. due to the selection of only outermost rule redices, expander2’s strategy of applying expansion, co/induction and other simplification rules is complete: it terminates whenever any strategy terminates. the third approach is based on our work on co/horn logic [19, 20, 23, 24] where co/horn clauses axiomatize least resp. greatest relational fixpoints and parallel co/resolution provides the counterpart of expansion in the second approach. the co/induction rules of the second approach are replaced by incremental co/induction that admits the automatic—and often inevitable— generalization of a conjecture. incremental coinduction is also called circular [7, 12] and has recently been used to prove bisimilarities induced by non-deterministic transition systems with structured states [27]. proof assistants offering coinduction are clam [5], isabelle [6, 26] and pvs [10, 13]. we claim that the simplification version presented in section 4 and the incremental version of section 5 are the most general coinduction rules so far. the first one has been integrated into a formula/term simplifier, which applies it automatically. the second one can be used for checking any relation with a greatest-fixpoint semantics and not only bisimulations or other equalities. moreover, incremental induction does not seem to have been mentioned anywhere else. however, the restriction of previous approaches to coinduction and equalities only applies to the incremental rules. the simplification version of co/induction has many forerunners, also in a more general, non-logical context where an arbitrary partial order replaces the implication (see, e.g., [17, 9, 6, 26]). mainstream model checkers hide their logical background by translating both kripke models and the formulas to be proved into bit representations that a deterministic proof algorithm can process efficiently without manual intervention. at least at the present stage of development, festschrift h.-j. kreowski 20 / 22 eceasst the methods presented in this paper do not compete against established model checkers. instead, the methods resulted from questions like: what are the characteristics, benefits and drawbacks of kripke structures if compared with coalgebraic models in general? which models and modal logics are adequate for describing and verifying which kind of systems? how does the complexity or generic nature of a system affects its formalization and the degree of proof automation? bibliography [1] j. van benthem, j. bergstra, logic of transition systems, j. logic, language and information 3 (1995) 247-283 [2] c. cirstea, a. kurz, d. pattinson, l. schröder, y. venema, modal logics are coalgebraic, the computer journal, to appear [3] e.m. clarke, o. grumberg, s. jha, verification of parameterized networks, acm toplas 19 (1997) 726-750 [4] e.m. clarke, o. grumberg, d.a. peled, model checking, the mit press 1999 [5] l.a. dennis, a. bundy, i. green, making a productive use of failure to generate witnesses for coinduction from divergent proof attempts, annals of mathematics and artificial intelligence 29, springer (2000) 99-138 [6] j. frost, a case study of co-induction in isabelle, report, computer laboratory, university of cambridge 1995 [7] j. goguen, k. lin, g. rosu, conditional circular coinductive rewriting with case analysis, proc. wadt’02, springer lncs 2755 (2003) 216-232 [8] j. goguen, g. malcolm, a hidden agenda, theoretical computer science 245 (2000) 55-101 [9] a.d. gordon, bisimilarity as a theory of functional programming, theoretical computer science 228 (1999) 5-47 [10] h. gottliebsen, co-inductive proofs for streams in pvs, report, queen mary, university of london 2007 [11] i. hasuo, modal logics for coalgebras a survey, report, tokyo institute of technology (2003) [12] d. hausmann, t. mossakowski, l. schröder, iterative circular coinduction for cocasl in isabelle/hol, proc. fase’05, springer lncs 3442 (2005) 341-356 [13] u. hensel, b. jacobs, coalgebraic theories of sequences in pvs, j. logic and computation 9 (1999) 463-500 21 / 22 volume 26 (2010) algebraic model checking [14] m. huth, m. ryan, logic in computer science: modelling and reasoning about systems, 2nd ed. cambridge university press 2004 [15] b. jacobs, j. rutten, a tutorial on (co)algebras and (co)induction, eatcs bulletin 62 (1997) 222-259 [16] a. kurz, specifying coalgebras with modal logic, theoretical computer science 260 (2001) 119-138 [17] z. manna, mathematical theory of computation, mcgraw-hill 1974 [18] m. müller-olm, d.a. schmidt, b. steffen, model-checking: a tutorial introduction, proc. sas’99, springer lncs 1694 (1999) 330-354 [19] p. padawitz, proof in flat specifications, in: algebraic foundations of systems specification, ifip state-of-the-art report, springer (1999) 321-384 [20] p. padawitz, swinging types = functions + relations + transition systems, theoretical computer science 243 (2000) 93-165 [21] p. padawitz, dialgebraic specification and modeling, in preparation, fldit-www.cs.tudortmund.de/∼peter/dialg.pdf [22] p. padawitz, expander2: a formal methods presenter and animator, fldit-www.cs.tudortmund.de/∼peter/expander2.html [23] p. padawitz, expander2: towards a workbench for interactive formal reasoning, in: formal methods in software and systems modeling: essays dedicated to hartmut ehrig, springer lncs 3393 (2005) 236-258 [24] p. padawitz, expander2: program verification between interaction and automation, proc. 15th workshop on functional and (constraint) logic programming, elsevier entcs 177 (2007) 35-57 (more recent version: fldit-www.cs.tudortmund.de/∼peter/expander2/prover.pdf) [25] p. padawitz, algebraic model checking and more, in preparation, fldit-www.cs.tudortmund.de/∼peter/haskellprogs/ctl.pdf [26] l.c. paulson, mechanizing coinduction and corecursion in higher-order logic, j. logic and computation 7 (1997) 175-204 [27] a. popescu, e.l. gunter, incremental pattern-based coinduction for process algebra and its isabelle formalization, proc. fossacs 2010, springer lncs 6014 (2010) 109-127 [28] j. rutten, universal coalgebra: a theory of systems, theoretical computer science 249 (2000) 3-80 [29] c. stirling, modal and temporal logics, in: handbook of logic in computer science, clarendon press (1992) 477-563 festschrift h.-j. kreowski 22 / 22 introduction kripke structures in expander2 modal logic and algebra model checking by simplification model checking within co/horn logic beyond model checking conclusion on the need of user-defined libraries in ocl electronic communications of the easst volume 36 (2010) proceedings of the workshop on ocl and textual modelling (ocl 2010) on the need of user-defined libraries in ocl thomas baar 10 pages guest editors: jordi cabot, tony clark, manuel clavel, martin gogolla managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst on the need of user-defined libraries in ocl thomas baar akquinet tech @ spree gmbh bülowstraße 66, d-10783 berlin, germany thomas.baar@akquinet.de abstract: reuse is a fundamental concept of efficient software development. objectoriented implementation languages offer reuse on different levels of granularity: method, class, library. while encapsulation of implementation code within methods and classes enables reuse within a project, user-defined libraries are widely used to share implementation code among different projects. the specification language ocl offers language concepts like defined attributes and defined operations to enable reuse within a project. however, reuse among different projects is not possible since ocl does not support the concept of user-defined libraries. there is no standardized way to import user-defined ocl constraints into another project. in this paper, we argue on the need of a standardized mechanism to make reuse of ocl specifications within a different context possible. keywords: software reuse, library management, oo programming, ocl, java 1 motivation one indicator for the success of an implementation language is the number of libraries made available. a high number of available libraries is a sign of an active community. many members of the community are willing to share the achievements they made. a library of an implementation language usually addresses one recurring programming problem, such as or-mapping, graph rendering, or logging. by using the library, a programmer can build on top of abstractions provided by the library, what can help to cut down development costs and to improve the quality of the developed system. uncontrolled publication of libraries, however, can confuse the community; a well-known example from java are different logging frameworks such as log4j or sun’s logging api. fortunately, some powerful mechanisms can avoid the proliferation of different libraries for the same purpose. in the java world, many of the widely adopted libraries are authored by organizations whose name became a synonym for high-quality software, e.g. apache software foundation (asf), eclipse foundation, mozilla, jboss. important libraries can become an official standard1 or part of important library bundles, such as java ee (enterprise edition). these mechanisms as well as training and certification programs ensure a widespread dissemination and usage of important java libraries today. the current version of the object constraint language (ocl 2.2 [omg10a]) does not support the concept of user-defined libraries. this has both positive and negative consequences. on the 1 the stardardization process is defined by the java community process (jcp), see [ora10] for details. 1 / 10 volume 36 (2010) mailto:thomas.baar@akquinet.de on the need of user-defined libraries in ocl positive side, one could argue that there is no need for the ocl community to think about a process to control the lifecycle of libraries, i.e. there is no need to invent something like the ocl community process. furthermore, ocl users are prevented from the pain of having to choose the most suitable library from a set of competing libraries targeting the very same problem. on the negative side, there is no standardized means to share ocl constraints between different projects. consequently, there is no market of user-defined ocl libraries where different authors try to convince the ocl community that their library is the most elegant solution for an identified problem. the contribution of this paper is to stress the point that ocl’s current mechanisms for reuse are not sufficient. we argue on the need of user-defined libraries and propose an architecture for ocl libraries. a support of user-defined libraries would result in a much more flexible usage of ocl, since the users are not bound to the limited set of data structures and operations offered by the ocl standardized library. we illustrate our arguments using a small example, which is discussed from the perspective of both ocl and java. the paper is organized as follows. in section 2 we formulate requirements for a system to be built. this system will serve as a running example for the rest of the paper. in section 3 the informally described functionality of the running example is both specified using ocl and implemented in java. we compare the effort for writing both ocl specification and java implementation. we draw already the conclusion that writing the ocl specification would be less painful, if ocl had a support for user-defined libraries. section 4 presents a possible architecture for library support in ocl and discusses its merits and limitations. while section 5 reports on alternative approaches found in the literature and gives further examples that underpin the need of user-defined libraries in ocl, section 6 summarizes the paper and draws conclusions. 2 running example suppose, you develop an analysis tool for java code. the ultimate goal of the tool is to find dead code. more precisely, the tool should detect classes, whose methods are never invoked if the system is started via the main-method of the start class. the analysis tool works in two phases. in the preparation phase, information about the control flow is extracted from the java source code and a call graph is built. the call graph shows method invocations as (directed) call dependencies between the calling class and the called class. the underlying data structure of call graphs is modeled by a uml class diagram as shown in figure 1. a call graph (represented by callgraph) consists of java classes (javaclass) and call dependencies (calldep). the two associations between javaclass and calldep indicate, which java classes are actually connected by a call dependency. finally, an integrity constraint makes the model more comprehensible. this constraint says that a call dependency belongs to the same call graph as the java classes it connects. the constraint is formulated in ocl in the comment box in figure 1. we assume for the rest of the paper that the preparation phase has already been implemented correctly, i.e. that the call graph is available. in the analysis phase, the analysis tool is supposed to provide two kinds of dead code analysis. the first kind of analysis detects all classes that are never invoked by other classes. in the call proc. ocl 2010 2 / 10 eceasst figure 1: data structure of call graph graph, such classes are isolated in the sense that they do not have any incoming call dependency. in the example given in figure 2a, the classes cisolated1 and cisolated2 are isolated according to this definition. the second kind of analysis detects orphan classes. orphan classes are classes that can have incoming call dependencies from other orphan classes, but no path of call dependencies exists from the start class to an orphan class. since orphan classes are not reachable from the start class, their code is never executed. in the example given in figure 2b, the classes corphan1 and corphan2 are orphan classes. (a) isolated classes (b) orphan classes figure 2: two kinds of analysis. the start class of the analyzed system is colored in gray 3 current solutions in java and ocl how can the expected behavior of the analysis tool be specified/implemented? the tool’s functionality is adequately represented by the two query methods isisolated():boolean and isorphan(javaclass startclass):boolean on class javaclass. the method call o.isisolated() returns true, iff o represents an isolated java class. analogously, the method 3 / 10 volume 36 (2010) on the need of user-defined libraries in ocl o.isorphan(start) returns true, iff o represents an orphan class wrt. start, i.e. there is no path of call dependencies from start to o. in the sequel, we will try to realize these two methods both in java and ocl. 3.1 implementation in java 3.1.1 isisolated() the implementation of isisolated() is very simple provided that the associations between classes javaclass and calldep are implemented for each direction by a reference. in this case, the implementation looks as in listing 1. listing 1: java implementation of isisolated() public boolean isisolated(){ return incoming.isempty(); } 3.1.2 isorphan() the implementation of isorphan(javaclass startclass) requires to compute the transitive closure of the call dependency relationship. the computation of the transitive closure is a well-known graph problem. fortunately, graph problems have been tackled by numerous java libraries. for example, the open-source library jgraph [jgr10] provides a class mxgraphanalysis, whose methods implement some frequently needed algorithms on directed graphs. the computation of the transitive closure is basically done in mxgraphanalysis.getconnectioncomponents(). figure 3: implementation of running example when using library jgraph proc. ocl 2010 4 / 10 eceasst figure 3 shows the architecture when using the library. on the right hand side of the figure, the classes of the jgraph library are shown (marked by a dark gray background). on the left hand side, one finds the classes of our application (white background), which use the library classes. in the middle, there are some mapping classes (light gray background). following the architecture of figure 3, the main challenge when using jgraph is to keep the data structure of the application (left hand side) with the data structure of the library (right hand side) in sync. whenever objects of classes javaclass and calldep are created, it must be ensured that corresponding objects of the library classes vertex and edge together with objects of the mapping classes vertexpair and edgepair are created as well. the same effort of synchronization is necessary when objects of javaclass and calldep change or when they are deleted. once the synchronization of application and library objects is done, the implementation of isorphan() is a simple delegation as shown in listing 2. listing 2: java implementation of isorphan() public boolean isorphan(javaclass start){ graph graph = this.getvertexpair().getvertex().getgraph(); return mxgraphanalysis.getconnectioncomponents(graph). differ(this.getvertexpair().getvertex(), start.getvertexpair().getvertex()); } 3.2 specification in ocl 3.2.1 isisolated() the specification of method isisolated() in ocl is as simple as the corresponding implementation in java. the specification is shown in listing 3. listing 3: ocl specification of isisolated() context javaclass::isisolated():boolean post: result = incoming->isempty(); 3.2.2 isorphan() for the specification of method isorphan() we would like to reuse a library similar to jgraph. unfortunately, ocl does not support user-defined libraries. interestingly, there has been attempts to add a transitive closure operator to ocl2, but, at times of writing this paper, this operator is not a part of ocl. listing 4 shows the definition of isorphan if ocl had already support for the transitive closure operator. note that in listing 4 2 see request http://www.omg.org/issues/issue13944.txt 5 / 10 volume 36 (2010) on the need of user-defined libraries in ocl we use tc as a concrete syntax representation of the transitive closure operator. this, however, is just a ’private notation’, because no decision of the omg, the standardization committee for ocl, has been yet taken on whether and in which form the transitive closure operator will be made available in ocl. listing 4: ocl specification of isorphan() using transitive closure operator tc context javaclass::isorphan(start:javaclass):boolean post: result = not start.tc(outgoing)->includes(self) it should be noted that there would be no need to integrate the transitive closure operator into ocl (and, by doing this, to give up the goal to have a loose semantics for standard ocl, see also [baa03]), if (1) ocl had support for user-defined libraries and (2) if there would be an ocl library analogously to jgraph available. 4 a proposal for ocl libraries in the last section, we tried to find an ad-hoc solution for the problems illustrated by the running example. as a serious source of problems we identified the missing support for user-defined libraries. in this section, a proposal for an architecture of user-defined ocl libraries is presented. 4.1 overview figure 4 shows a possible architecture of ocl libraries using an example. as example we have chosen the library-based solution for specifying isorphan(). the core idea is to have libraries both for ocl specifications and for underlying uml models3. the upper part of figure 4 shows the library layer lib. this layer comprises both ocl constraints (right part) and the underlying uml model (left part). for our running example, an appropriate library would define concepts like graph, node, edge in order to represent graphs. ocl constraints (right part) can fix the intended meaning of the defined concepts, e.g. integrity constraints, and they can specify operations such as graph::isconnected() for the purpose of reuse. note that the layer lib itself is nothing but an ordinary uml/ocl model. the bottom part of figure 4 shows the reuse of lib within the application layer app. the uml model uml-app imports uml-lib by using uml’s package import. in our example, the concepts of the application domain (javaclass, calldep) must be mapped to the imported concepts, what is achieved by additional mapping associations with multiplicity 1-1. furthermore, the constraints of ocl-lib have to be imported. finally, the operation isorphan() can be specified by a constraint that simply delegates to graph::isconnected() as shown in ocl-app. 4.2 obstacles for realizing this proposal the following obstacles must be taken into account when realizing this proposal: 3 ocl constraints can also refer to non-uml models, e.g. to dsl models. the problems for uml/ocl libraries discussed here apply analogously also to non-uml/ocl libraries. proc. ocl 2010 6 / 10 eceasst figure 4: proposal for an architecture of ocl libraries different uml-imports uml defines different kinds of package import: import, access, merge. each kind has its own semantics with direct consequences on the usage of imported elements within ocl expressions. furthermore, it must be possible to change the library after its import. in our example, the library concepts node, edge became endpoints of the mapping associations. ocl-import ocl does not support an import-statement. the semantics of such ocl-import must correspond with the different kinds of import of the underlying uml models. customization of imports for uml, ocl when reusing libraries in object-oriented programming languages, flexibility is considerably improved by the possibility to redefine and adapt imported entities towards the needs of the importing context. for uml/oclimports, comparable kinds of customization are imaginable, e.g. merge of model elements and (de)selection of constraints. 7 / 10 volume 36 (2010) on the need of user-defined libraries in ocl 5 related work the problem of missing library support in ocl has been recently recognized and addressed by chimiak-opoka in [co09]. her tool ocl editor [st10] implements an import-statement for ocl, which enables reuse of ocl constraints. currently, chimiak-opoka and her team are extending ocl editor in a way that it can process the running example presented in this paper. according to cabot et al. [cmpt09], statistical functions play an important role in certain domains. they describe in their paper how statistical functions such as max(), avg(), which compute the maximum and average value of a given ocl collection, could be formally defined in terms of ocl functions. they conclude that these functions should become a part of the ocl standard library, but this would be a rather long and laborious process, since the omg as the standardization authority had to be convinced on the general usefulness of statistical functions. if ocl had already support for user-defined libraries, cabot et al. could have published an ocl library containing all the functions discussed in the paper. consequently, everybody could straight away reuse the functions described in [cmpt09] in every ocl tool, propose extensions, give feedback, etc. all this without having to wait for the outcome of a long-winded standardization process. in [ahm06], akehurst et al. discuss an interesting approach to generalize the idea of libraries in ocl. they start with the observation that ocl is used as a constraint language not only for uml but for many mof-based modeling languages. to make these modeling languages amenable to ocl constraints, these languages have to provide certain interfaces. some of these interfaces, however, are purely related to the ocl standard library, e.g. the modeling language has to provide interfaces for primitive ocl types such as string and real. akehurst et al. propose to let a modeling language not only implement interfaces for primitive types, but to let the modeling language completely or partially implement the ocl standard library. analogously, the modeling language could implement any other user-defined library for ocl. such an ocl library could be reused at least by any other user of the same modeling language, because the library is now part of the modeling language. since we use for the java implementation of the running example the java library jgraph, it will be tempting to name the corresponding ocl library oclgraph. however, one has to be aware that for the scheduling and planning community, oclgraph denotes a generator for planning graphs [sml00]. these planning graphs take object representations for entities of the planning domain into account. these objects are formalized using the object-centred language [mp97], which provides concepts such as sort hierarchy, predicates, sub-state class definitions, invariants, operators. while these concepts play also an important role for the object constraint language, the object-centred language is a different language. to make the confusion perfect, both object constraint language and object-centred language are abbreviated by ocl. 6 conclusions specification languages such as ocl are supposed to work on a higher level of abstraction compared with implementation languages. a higher abstraction level means less details to deal with and to use much simpler data structures. proc. ocl 2010 8 / 10 eceasst at the level of implementation languages, sharing useful abstractions among projects is done by publishing a library. successful libraries must have a managed lifecycle, i.e. they are specified and reviewed prior to publication and change. ocl does not yet support the concept of user-defined libraries. ocl standard library is the only available library in ocl. sometimes, this library does not offer the data structures one would wish. today, the only possibility to share new abstractions among different projects is to add them to the ocl standard library. however, adding a new element to ocl standard library is comparable to adding a new element to the java.util package. this is, however, not an appropriate solution in most cases. as discussed in subsection 3.2, there is currently an open request to the omg to include the transitive closure operator to ocl. this request would become superficial if ocl had support for user-defined libraries and if a library similar to jgraph would be made available in ocl. note that the latter variant would be a much more general solution and would alleviate also many other problems indicated by other authors, e.g. [cmpt09]. for these reasons, we propose — in a first step — to extend the ocl language definition by mechanisms for defining and importing ocl libraries. note that these mechanisms have to be supported by each ocl tool. this could pave the way for a so far missing market of ocl libraries. once a vivid market of reusable ocl libraries has emerged, the ocl community could agree — in a second step — on mechanisms to avoid proliferation of libraries. one possible action in this direction is the adoption of a library management process similar to the java community process. bibliography [ahm06] d. h. akehurst, w. g. j. howells, k. d. mcdonald-maier. uml/ocl detaching the standard library. pp. 205–212 in [dcgw06]. [baa03] t. baar. the definition of transitive closure with ocl – limitations and applications. in proceedings, andrei ershov fifth international conference, perspectives of system informatics, novosibirsk, russia. lncs 2890, pp. 358–365. springer, july 2003. [co09] j. chimiak-opoka. ocllib, oclunit, ocldoc: pragmatic extensions for the object constraint language. pp. 665–669 in [ss09]. [cmpt09] j. cabot, j.-n. mazon, j. pardillo, j. trujillo. towards the conceptual specication of statistical functions with ocl. pp. 7–12 in [yer09]. [dcgw06] b. demuth, d. chiorean, m. gogolla, j. warmer (eds.). ocl for (meta-) models in multiple application domain, workshop co-located with models 2006, genova, italy, october, 2006. proceedings. technical reports tud-fi06-04. technische universität dresden, fakultät informatik, 2006. [jgr10] jgraph ltd. jgraph, version 1.4.0.8. nov 2010. available from http://www.jgraph.com. 9 / 10 volume 36 (2010) on the need of user-defined libraries in ocl [mp97] t. l. mccluskey, j. m. porteous. engineering and compiling planning domain models to promote validity and efficiency. artif. intell. 95(1):1–65, 1997. [omg10a] omg. object constraint language, version 2.2. feb 2010. available from http://www.omg.org/spec/ocl/2.2. [omg10b] omg. omg unified modeling language (omg uml), infrastructure, version 2.3. may 2010. available from http://www.omg.org/spec/uml/2.3. [omg10c] omg. omg unified modeling language (omg uml), superstructure, version 2.3. may 2010. available from http://www.omg.org/spec/uml/2.3. [ora10] oracle. java community process (jcp). nov 2010. available from http://www.jsp.org. [puk00] proceedings of the 14th workshop ”new results in planning, scheduling and design” (puk2000), berlin, 21-22 august 2000. 2000. [sml00] r. m. simpson, t. l. mccluskey, d. liu. ocl-graph: exploiting object structure in a plan graph algorithm. in [puk00]. [st10] squam-team. squam framework / ocl editor. nov 2010. available from http://squam.info/. [ss09] a. schürr, b. selic (eds.). model driven engineering languages and systems, 12th international conference, models 2009, denver, co, usa, october 4-9, 2009. proceedings. lecture notes in computer science 5795. springer, 2009. [yer09] e. yu, j. eder, c. rolland (eds.). proceedings of the forum at the caise 2009 conference, amsterdam, the netherlands, 8-12 june 2009. 2009. proc. ocl 2010 10 / 10 motivation running example current solutions in java and ocl implementation in java isisolated() isorphan() specification in ocl isisolated() isorphan() a proposal for ocl libraries overview obstacles for realizing this proposal related work conclusions the pattern instance notation: a simple hierarchical visual notation for the dynamic visualization and comprehension of software patterns electronic communications of the easst volume 25 (2010) proceedings of the workshop visual formalisms for patterns at vl/hcc 2009 the pattern instance notation: a simple hierarchical visual notation for the dynamic visualization and comprehension of software patterns jason mcc. smith 12 pages guest editors: paolo bottoni, esther guerra, juan de lara managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst the pattern instance notation: a simple hierarchical visual notation for the dynamic visualization and comprehension of software patterns jason mcc. smith1 1 jason.smith@tsri.com, tsri, inc, kirkland, wa abstract: design patterns are a common tool for developers and architects to understand and reason about a software system. visualization techniques for patterns have tended to be either highly theoretical in nature, or based on a structural view of a system’s implementation. the pattern instance notation is a simple visualization technique for design patterns and other abstractions of software engineering suitable for the programmer or designer without a theoretical background. while based on a formal representation of design patterns, using pin as a tool for comprehension or reasoning requires no formal training or study. pin is hierarchical in nature, and compactly encapsulates abstractions that may be spread widely across a system in a concise graphical format, while allowing for repeated unveiling of deeper layers of complexity and interaction on demand. it is designed to be used in either a dynamic visualization tool, or as a static representation for documentation and as a teaching aid. keywords: design patterns, visualization, education, comprehension 1 introduction design patterns[ghjv95] are a common and useful mechanism for software developers and designers to document, understand, and reason about the abstractions that are used to create software systems. notations for visualizing design patterns, however, have required either a very strong background in design theory, or an adherence to the particular structure of an implemented design. the former causes issues with developers who are not trained in the subtleties of abstraction research, while the latter causes issues when considering a design independent of a specific implementation. the pattern instance notation is a formal visualization technique for representing design patterns and other abstractions. pin provides a simple box-and-line approach that is familiar to most software engineers and designers, yet offers a unique hierarchical abstraction that mirrors the concepts of patterns closely. pin is suitable for use as a static diagramming notation, but is also intended as a dynamic system for direct interaction by a user investigating a design. it is not intended to be a full replacement for, or formal form of, design pattern definitions. the goal is a pragmatic, simple notation that conveys the underlying connections and relationships in an abstract view of software to assist developers and designers in comprehending and reasoning about the abstractions expressed in their software. i will discuss the limitations of current graphical systems for pattern description, and then 1 / 12 volume 25 (2010) mailto:jason.smith@tsri.com the pattern instance notation briefly describe the underlying formalisms that inspired the pin. next, i will provide a definition of the pin in its three modes collapsed, simple, and expanded, and show how each can be used as an adjunct to a standard uml diagram, or as a standalone diagram. finally, i will discuss ways in which these modes can be utilized in an interactive system for program discovery and understanding. 2 background the pattern instance notation has its roots in the system for pattern query and recognition project[ss03, ss07]. spqr is a comprehensive system of abstraction formalization, detection, and reporting tools that detects instances of known design patterns and other abstractions directly from source code in a language independent manner. pin was created because the existing graphical notations were often found to be too abstract or too complex to be readily useful for the average practitioner, or too closely tied to the structure of code to properly represent the abstractions that are inherent in patterns, independent of the source code implementation. this latter point is important because a pattern can be instantiated in a multitude of ways in implementation. spqr was designed to find those instances that were expressed in a non-direct manner, with relationships being created through transitive chains of interaction, instead of immediate and direct expression. an example of this is a chain of method calls that ultimately leads to a relationship between the first method, and the nth method in the chain. this relationship may be precisely what fulfills a design pattern requirement, but it is not directly found in the source code. in these cases, the pieces of a pattern are often scattered across the system in a way that has little to no congruence with the physical or structural view. spqr’s rho-calculus[smi05] creates an alternative to the rigid physical locality constraints found in most pattern description work, and transforms the source code into a space defined by the conceptual relationships between the fundamental entities of object-oriented programming. it is these conceptual relationships, or reliances, that form the basis of a hierarchical pattern language, the elemental design patterns, or edps[ss02]. the edps are the core building blocks of object-oriented software design, and through well-formed composition and combination, naturally and quickly lead to the more familiar design patterns from the literature. further, as shown in [smi05], all object-oriented systems can be broken down into a collection of interacting edps, and design patterns are necessarily comprised of edps combined in familiar forms. pin was created to address these needs: simplicity, pragmatism, non-physical locality of pattern expression, and explicit hierarchical information. 2.1 previous work while several graphical notations for pattern description have been suggested, they can be organized roughly into two groups: structural, and abstract. structural notations are those that mimic the structures found in software as artifacts. this is a natural way of thinking about software, and the ubiquity and success of the unified modeling language[rjb04] acts as an example of how this approach is useful in many instances. not surprisingly, most suggested pattern notations are designed to be used as an extension of uml[dyz07, bt06, vli98]. these systems proc. vffp 2009 2 / 12 eceasst tend to be fairly simple, and are generally easy for a developer to use, being based closely on preconceptions of ‘how software exists’. for pragmatism, these notations do well, but they have a fundamental mismatch with the role-based view of design patterns and abstraction in general. the core issue with notations that follow the structural view of software is that they impose the physical locality mentioned above on the view. the most straightforward example of this is the pattern:role annotation originally developed to augment uml diagrams with basic design pattern concepts[vli98]. a class, method or field is tagged with a pattern name and a role, as shown in figure 1. the roles associated with a particular pattern may be scattered around a uml diagram, making it difficult to see the conceptual interactions. the pieces of the pattern instance are spread across the structural uml notation, and it is up to the viewer to create their own connections in their head. this is an odd burden to place on the user of a visual notation, but is common to all in this group, with the exception of uml collaboration annotations[rjb04] which does place the collaboration, or pattern instance, as a first-class entity. collaboration annotations, however, are limited in their abilities. they represent a named abstraction, and provide role names, but do not scale well to finer or coarser granularities that are often useful, as we will see in section 3. algorithm() physicalobject algorithm() algorithma algorithm() algorithmb algorithm() algorithmc strategy:concretestrategy strategy:concretestrategy strategy:concretestrategy strategy:strategy figure 1: pattern:role annotation tags in uml despite this, these annotations are adequate for cases where a single instance of a particular pattern exists in the diagram, such as when teaching students how a design pattern may map to an implementation. this approach quickly breaks down, however, in real world systems, when multiple instances of a pattern exist, as in even the simple diagram in figure 2. while both the uml collaboration notation and the stereotypes described in [dyz07] do allow for multiple instances, the lack of flexibility in the former and the lack of treating patterns as first class visual entities in the latter make them more difficult to use than necessary. this adds an additional goal for pin: dealing with multiple instances. the other group of pattern visual descriptions can be described as abstract notations. these, such as lepus[ede01], dpml[mhg02], and rbml[kfgs03], correctly identify the main criteria of design patterns as non-structural abstractions, and are aimed appropriately at the theoretician or researcher. as tools for the average practitioner, however, these have had limited adoption. a complete representation of a formalism for design patterns represents a significant learning curve to a developer who is unused to thinking about software as abstract roles and fragments. rich metamodels that capture the detailed and nuanced inner workings of an abstraction theory require understanding that theory before being truly useful. if this were a simple body of work to understand, every developer would be a theoretician as well. 3 / 12 volume 25 (2010) the pattern instance notation algorithm() physicalobject1 algorithm() algorithm2() librarya algorithm() algorithm2() libraryb algorithm() algorithm2() libraryc algorithm2() physicalobject2 strategy:concretestrategy strategy:concretestrategy strategy:concretestrategy strategy:concretestrategy strategy:concretestrategy strategy:concretestrategy strategy:strategystrategy:strategy figure 2: pattern:role annotation tags in uml multiple instances pin is designed to straddle these two realms, striking a balance between the simplicity of a direct modeling notation, and the richness of a concept-based notation, while avoiding the physical locality issues seen in most structural notations, and refraining from the complexity of complete metamodels. 3 pattern instance notation definition the goals for pin as listed above are: pragmatic simplicity for the average developer, support for multiple instances in a single diagram, and a concept-based approach with a clear hierarchical expression. by starting with a basic box-and-line notation, we can add support for these goals in stages, to define the full pin. first, however, a brief conceptual formalization of pin can be provided. as in the rho-calculus which inspired this notation, patterns or other abstractions are described as a series of conceptual roles. this can be expressed as a simple tuple of the form pattern(role1,role2,role3...). such a tuple is the product of reduction rules describing the subpatterns and primary entities and relationships that form it. the recursive nature of the definitions ultimately results in the relationships defined by the denotational semantics of rhocalculus. as an example, the definition for the decorator pattern is given in equation 1. instances of the subpatterns, object recursion and extend method, are explicitly listed, and the occurrence of the same name in multiple role slots, such as decorator, means that whatever implementation feature fulfills that role in one subpattern fulfills the other ones as well. for further details on the rho-calculus and the full pattern definition catalog, see [smi05]. pin captures this hierarchy of concepts cleanly and effectively when appropriate, and encapsulates the detail when necessary. objectrecursion(component,decorator,concretecomponent,any) extendmethod(decorator,concretedecorator,operation) decorator(component,decorator,concretecomponent,concretedecorator,operation) (1) proc. vffp 2009 4 / 12 eceasst 3.1 collapsed the most basic form of pin fulfills the first two goals, pragmatic simplicity and multiple instances, by using the most common diagramming elements: boxes and lines. pinboxes, as shown in figure 3 are simple rectangles, with rounded corners and an optional slightly shaded or thick border. this is to distinguish them from the right-angle corner rectangles used in uml when the two notations are blended, as described later in subsection 4.2. each pinbox represents a separate instance of a pattern, and is labeled internally with the name of the pattern or abstraction. it is suggested that the name placement be centered along both axes. pattern figure 3: collapsed pin instance unidirectional arrows are used to connect instances to entities in uml. an arrow indicates that the instance at the tail end of the arrow uses, or relies on, the uml entity at the head end of the arrow. there is no cardinality associated with the arrows, as each pattern instance is illustrated separately. the relationship here has a different basis than the uses relationship of uml, and should not be confused with it. the more accurate term, adopted from the terminology of rhocalculus, would be relies on. figure 4 shows an example of this connection, where the instance of pattern has a reliance on the class entity class name. pattern operation operation attribute attribute class name figure 4: collapsed pin connection this seemingly informal connection still makes immediate sense in many cases. for instance, a singleton pattern has an obvious single class it is connected to; a decorator pattern can usually be hinted at by a single arrow to the operation in the base class being decorated; an abstract factory may only need a single connection to the factory class, and so on. each pattern or abstraction represented by a pinbox will have one or two primary concepts that link to an implementation diagram such as uml as an annotation. these concepts can be tagged in a formal definition of the pattern if desired for tool manipulation. the intent is simply to give the reader of the collapsed pinbox a hint or quick reminder of the concepts at work in the implementation notation. 5 / 12 volume 25 (2010) the pattern instance notation this collapsed pin format is suitable for quickly connecting a pattern instance graph, or as a shorthand for demonstrating the abstractions in a uml diagram. it has no detail, however, and is most commonly used for sketching out a rough design or as a lightweight mnemonic. 3.2 standard the standard pin notation expands on the next of our intended goals: a concept-based approach. following on the role-based formalisms of rho-calculus, a pattern is defined as having certain roles that are fulfilled by the programmatic entities of a system. for instance, from a reading of the common definition[ghjv95], a decorator instance has roles of component, concretecomponent, decorator, concretedecorator, and operation. each of these required class types and methods is fulfilled by a specific entity in the implementation. we saw a simplified version of this in the collapsed pin form, where only the critical primary roles were connected to their implementations. now we build on that to show all the roles, and which classes, objects, attributes or operations they are fulfilled by. it is somewhat analogous to the uml collaboration annotation[rjb04], but unlike the uml variant, can be used to show design interactions independent of a uml, or implementation-oriented, representation. pin demonstrates this role-based view by providing ‘sockets’ around the edge of the instance pinbox, which are then connected to their fulfilling entities in either other pin instances, or uml entities. figure 5 shows this role ring. n roles are represented by n boxes around a central name label. because experience with spqr has shown that the number of formal roles in most patterns is less than 6, this is manageable, and demonstrates a clear concept of external connection from the pattern instance. roles may be arranged around the core in any order, as necessary for clean graph connection. text may be rotated parallel with the core edges as desired for compactness. as with the collapsed form, shading is often used to visually clarify the role ring, but is optional. rigidity of form is not the goal here, but a clear expression that a pattern instance, as named in the core, has a number of roles that must be fulfilled by external means. pattern a role 1 role 2 role 5 role 4 role 6 pattern b role 2role 1 role 3 figure 5: standard pin roles solid lines between external roles of instances indicate that these roles are tied to the same implementation entity, and have a shared purpose in the design. the shared implementation entity isn’t necessarily shown in such cases, since it can be considered as a fulfillment regardless of how or where it is implemented. this is used as in figure 6 to show collaboration between design instances and roles without exposing implementation details. pattern a:role 3 and pattern b: role 1 are implemented by the same entity, even though the conceptual roles and the pattern abstractions may be very different. in this diagram, the two pattern instances are interacting in a proc. vffp 2009 6 / 12 eceasst specific well-formed manner. this is a way of focussing on a design’s conceptual relationships without being distracted by the implementation. pattern a role 2role 1 role 3 pattern b role 1 role 2 role 3 figure 6: standard pin role connections 3.3 expanded with the pinbox supporting roles, we can meet our final goal: hierarchical expression of pattern composition. just as the role ring expressed the external needs of the pattern instance, the expanded pinbox shows the internal conceptual relationships of the instance. as in figure 7, the basic instance box of the standard notation is physically expanded, by increasing the size of the core box. this provides a canvas on which to draw the sub-patterns that compose the external pattern, as further pinbox instances. roles of the sub-patterns are connected to other roles, both internally to other sub-patterns, and externally to the main role ring of the primary pattern, using the solid lines described above. the role ring, particularly when shaded, visually conveys its function as an encapsulation technique, translating the internal conceptual complexity to a simple external interface. the expansion ability of any non-elemental pattern means that this process can continue exposing deeper layers of the hierarchy. as new instances are revealed, they can be similarly expanded, until only the elemental design patterns are left, and the full conceptual hierarchy is exposed. since this is done on a per-instance basis, some portions of a diagram can be deeply exposed, with other portions left in the standard encapsulated form. with multiple levels of expansion or contraction, a viewer can find the right balance of abstraction and detail for a specific purpose. this is a highly useful device as a teaching tool, making the conceptual connections tangible to the student. it is also, in a dynamic visualization environment, a powerful tool for the developer or designer wishing to more fully understand a software system. as a final note, it should be stated what pin is not. pin is not a metamodel. pin does not attempt to describe behavior. the design pattern explanations already in the literature fulfill this need through prose and other notations. pin is not a notation for executable models. there are 7 / 12 volume 25 (2010) the pattern instance notation role 1 role 2 role 5 role 3 role 4 pattern subpattern a role 2role 1 role 3 subpattern b role 1 role 2 role 3 figure 7: expanded pin instance existing notations in this space, and existing formalisms that are appropriate. pin fulfills the needs of the practitioner, not the theorist, while maintaining a strong theoretical foundation. pin is simple, concise, and flexible, and applicable to a number of use cases. 4 example uses in this section i will discuss the prime uses of pin, as both a standalone notation and as an adjunct to other more familiar notations, such as uml. 4.1 standalone pin is appropriate for displaying the conceptual design of a system, independent of implementation constructs such as classes, methods, or fields. it allows a more ‘pure’ view into the design of a system, and lets the developer or designer consider only the abstractions of interest to them at a particular point in time. expanding instances allows a designer to see further detail of a system, and consider implementation details that may be hidden at higher levels of encapsulation. in teaching environments, a pin diagram can show the collaboration and interaction between known abstractions, providing a template for the student that is not tied to a specific implementation language or code structure. for instance, figure 8, shows that the decorator pattern from equation 1 has five roles that need to be fulfilled by an implementation, and is composed of two subpatterns as described in spqr. further, this shows the student that these concepts connect in a very specific way. given a familiarity with bobby woolf’s object recursion[woo98] pattern, and the extend method edp [ss02], discussing the decorator as a recursive object structure that extends a method in a subclass becomes natural, which is precisely what the diagram shows. proc. vffp 2009 8 / 12 eceasst concrete decorator component operation concrete component decorator decorator object recursion recurserterminator handler extend method original behavior operation extended behavior figure 8: pin diagram of design pattern definition 4.2 uml partnership used in conjunction with uml, pin takes on a function as an explanatory tool. it allows design to be treated orthogonally to implementation, and the same design in pin can be mapped to a number of implementations in various languages. the external roles of the instances are connected to the uml diagram via the arrow notation introduced in subsection 3.1. figure 9 shows a very simple example in pin standard from, with a single instance of the decorator pattern. the decorator instance can be collapsed and connected to one or more uml entities based on what the user thinks is the proper level of clarity. in figure 10, a single connection to the class fulfilling the decorator role of the decorator pattern is enough to provide guidance to the viewer. most patterns have one or two roles that are considered primary, and a practitioner familiar with the design patterns literature will frequently only need a shorthand pointer to the implementation entities in a uml structure diagram to provide understanding. draw() window draw() tinteddecorator draw() simplewindow window window.draw() decoratedwindow::draw(); drawscrollbar(); draw() decoratedwindow draw() drawscrollbar() scrollbardecorator decorator component concretecomponent operation decorator concretedecorator figure 9: pin instance used with uml 9 / 12 volume 25 (2010) the pattern instance notation draw() window draw() tinteddecorator draw() simplewindow window window.draw() decoratedwindow::draw(); drawscrollbar(); draw() decoratedwindow draw() drawscrollbar() scrollbardecorator decorator figure 10: collapsed pin instance used with uml expansion can be done here as well, and an additional aspect of pin can be used: peeling. peeling is related to expansion in that the outer layers of the expanded pinbox are removed. this promotes the inner subpatterns to primary patterns, and the previous connections from the uml entities to the outer role ring are instead extended through to the roles of the previous inner subpatterns. a small tab is added to an edge of the subpatterns to indicate that they are part of a larger pattern instance. this tab is not intended to specify which instance, but instead is just a reminder of their original non-primary status. figure 11 shows the above example, expanded and peeled. draw() window draw() tinteddecorator draw() simplewindow window window.draw() decoratedwindow::draw(); drawscrollbar(); draw() decoratedwindow draw() drawscrollbar() scrollbardecorator object recursion terminatorhandler recurser extend method original behavior extended behavior operation figure 11: peeled pin instance used with uml a more concise notation in figure 12 demonstrates the expressive power of such a simple notation. by collapsing the above two subpatterns and connecting them to the minimal entities needed to point the developer in the right direction, they still provide the necessary information: “the decoratedwindow class in involved in an object recursion, and it is also the base class for an extend method on method draw(), which is extended in the scrollbardecorator class.” that is perhaps the most concise description of the essence of a decorator pattern. proc. vffp 2009 10 / 12 eceasst draw() window draw() tinteddecorator draw() simplewindow window window.draw() decoratedwindow::draw(); drawscrollbar(); draw() decoratedwindow draw() drawscrollbar() scrollbardecorator object recursion extend method figure 12: peeled and collapsed pin instance used with uml 4.3 dynamic notation pin is useful when used as a static notation, but the flexible expansion and peeling become much more so when implemented in a dynamic environment, such as a gui based tool. not only can the expansion and peeling be done on demand, but instances from previously peeled patterns can now be dynamically reconstituted into their original form. the tab annotation to indicate membership in a larger abstraction is an obvious user action trigger for this. when used in this manner, the diagram can be adjusted on the fly to best match the developer’s needs. this interactivity supports a natural process of discovery of the concepts in a system, and lets the developer or designer act on the design and the implementation quite separately, and reveal or encapsulate the design at the appropriate level of granularity. at that point a static representation can be saved for later use. 5 conclusion the pattern instance notation was created to support software developers and designers in documenting and understanding software systems in a concise and simple format that uses a conceptbased approach to provide a cleaner view of design patterns. while firmly rooted in a formal abstraction semantics of software design, it reduces the complexities of a theoretical metamodel down to a system that is natural and intuitive. a flexible notation centered around a single visual entity, the pinbox, provides multiple levels of detail within a single notation, and is suitable for static and interactive visualizations, either on its own, or as an adjunct to more traditional uml or other structurally-based notations. using pin to visualize software design results in a flexible system that mirrors the needs of developers and designers in industry, as well as the casual needs of the theoretician or patterns researcher. acknowledgements: many thanks to my reviewers and colleagues for highly useful feedback. this work was initiated at ibm watson research, and the result of very enjoyable collaborations. 11 / 12 volume 25 (2010) the pattern instance notation bibliography [bt06] h. byelas, a. telea. visualization of areas of interest in software architecture diagrams. in softvis ’06: proceedings of the 2006 acm symposium on software visualization. pp. 105–114. acm, new york, ny, usa, 2006. doi:http://doi.acm.org/10.1145/1148493.1148509 [dyz07] j. dong, s. yang, k. zhang. visualizing design patterns in their applications and compositions. ieee trans. software eng. 33(7):433–453, 2007. [ede01] a. h. eden. formal specification of object-oriented design. in proc. int’l. conf. multidisciplinary design in engineering csme-mde. nov 2001. [ghjv95] e. gamma, r. helm, r. johnson, j. vlissides. design patterns. addison wesley, 1995. [kfgs03] d.-k. kim, r. france, s. ghosh, e. song. a role-based metamodeling approach to specifying design patterns. in compsac ’03: proceedings of the 27th annual international conference on computer software and applications. p. 452. ieee computer society, washington, dc, usa, 2003. [mhg02] d. mapelsden, j. hosking, j. grundy. design pattern modeling and instantiation using dpml. in crpit ’02: proceedings of the fortieth international conference on tools pacific. pp. 3–11. australian computer society, inc., darlinghurst, australia, australia, 2002. [rjb04] j. rumbaugh, i. jacobson, g. booch. the unified modeling language reference manual. addison-wesley professional, 2nd edition, 2004. [smi05] j. m. smith. spqr: formal foundations and practical support for the automated detection of design patterns from source code. phd thesis, university of north carolina at chapel hill, dec 2005. [ss02] j. m. smith, d. stotts. elemental design patterns: a formal semantics for composition of oo software architecture. in proc. of 27th annual ieee/nasa soft. engineering workshop. pp. 183–190. dec 2002. [ss03] j. m. smith, d. stotts. spqr: flexible automated design pattern extraction from source code. in 18th ieee intl conf on automated software engineering. pp. 215– 224. oct 2003. [ss07] j. m. smith, d. stotts. design pattern formalization techniques. chapter 7, intentoriented design pattern formalization using spqr, pp. 123–155. idea group, inc, 2007. [vli98] j. m. vlissides. notation, notation, notation. c++ report, pp. 48–51, apr 1998. [woo98] b. woolf. the object recursion pattern. in harrison et al. (eds.), pattern languages of program design 4. addison-wesley, 1998. proc. vffp 2009 12 / 12 http://dx.doi.org/http://doi.acm.org/10.1145/1148493.1148509 introduction background previous work pattern instance notation definition collapsed standard expanded example uses standalone uml partnership dynamic notation conclusion electronic communications of the easst volume 24 (2009) guest editors: j. cabort, j. chimiak-opoka, f. jouault, m. gogolla, a. knapp managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 proceedings of the workshop the pragmatics of ocl and other textual specification languages at models 2009 declarative models for business processes and ui generation using ocl jens brüning, andreas wolff 16 pages eceasst 2 / 16 volume 24 (2009) declarative models for business processes and ui generation using ocl jens brüning, andreas wolff university of rostock, department of computer science, albert-einstein-str.21, 18059 rostock, germany {jens.bruening, andreas.wolff}@uni-rostock.de abstract: this paper presents an approach to model business processes and associated user interfaces in a declarative way, relying on constraints. an uml-based meta-model to define processes, activities and user-interface objects is proposed. connecting activities and user interface objects in an integrated model allows expressing interdependencies and mutual effects. flexible execution logic for workflows and ui control flows are specified by ocl invariants. the model is constructed for the uml tool use. using object snapshots, use can animate and validate business scenarios. snapshots represent states of a process and a ui at specific times. such animation enables business process and ui designers to discuss sensible scenarios on basis of the flexible declarative models. the intention is to create validated concrete process models in connection with ui elements that will provide a basis for the system implementation. keywords: declarative process modeling, ui modeling, ui generation, uml, ocl, constraints 1 introduction this paper is divided into two parts. the first one is about the declarative business process modeling approach and the connection to the user interface objects. these objects will provide relevant data for activities in the business process. constraints will use them to make statements about the process logic in connection with provided data. the meta-model for the declarative approach is presented and thereafter its usage is illustrated with a case study. the process will be animated with the uml tool use. the second part of the paper goes into detail of the user interface aspect and discusses how to use the models of part 1 for a more detailed ui modeling and then to generate a concrete ui out of it. problems of connecting the ui to the declarative process execution logic will be discussed here. 1.1 motivating the declarative approach declarative process models are more flexible, because all execution paths of the activities in the process model are allowed if they are not forbidden explicitly by constraints [19, 14]. in traditional graph based process modeling languages like bpmn [1] or uml activity diagrams [2] sequence relationships between activities are frequently used. those models represent concrete processes in companies or organizations. workflow management systems declarative business process models using ocl proc. ocl 2009 3 / 16 (wfms) can use such models to guide the employee through the process by instantiating and interpreting them. the sequence relationship between activities is not the standard relationship in declarative process models. by default the activities are concurrent and constraints restrict the possible activity executions. thus, they are less adequate to guide the employees through the process because they leave too many execution possibilities up to them. besides, the declarative modeling approach enables the process designer to model additional temporal relations between activities that are not possible to express by the traditional graph based modeling languages. section 2.3 will give an example for that. furthermore, by using the declarative approach not only temporal relations between activities can be described by constraints, also dependencies from activities to data in user interface objects can be defined. the execution logic is not only dependent on execution states of certain activities but also from data of ui-objects, which may have an impact on the process execution. 1.2 describing the case study for the case study in this paper we use an examination process for an undergraduate informatics course at our university. so it is about an administrational business process in an organization and not in a company. the examination process in the abstact datatype lecture [3] will be modeled and is as follows. the student gets exercise sheets that he has to solve at home. this homework period includes iterations for each sheet and is running until the last exercise is done. further on, the student has to do three written tests during the lecture. because of that we consider a test as an iterated activity. the period of homework begins earlier and runs longer than the test period. these two partial examinations are preconditions to write the final written examination test. 2 concept of declarative process models using ocl first of all we describe the meta-model for declarative business processes in general. thereafter, a concrete process is described by a case study about the lecture examination process that was textually described in section 1.2. the business process logic is described declaratively by ocl-invariants in section 2.3. dependencies of activities in the business process to the data from the user interface are also described by ocl-invariants in the section thereafter. at last the case study is animated by a concrete scenario in the uml tool use. that way the declarative process model can be tested. also suitable diagrams to analyze the scenarios are shown in section 2.5. 2.1 meta-model for declarative processes in figure 1 the process meta-model is presented. the model introduced in [4] is extended with iterations here. eceasst 4 / 16 volume 24 (2009) fig. 1. the meta-model for the declarative business process modeling approach the class process has an attribute name and contains a set of activities which is described by the association includes between process and activity. atomic actions and actions that occur iteratively in the process are expressed by the class activity. they have a name that describe the actions and a state in which the activity is currently in. possible states for the activities are described in the enumeration state. the process state is derived from the states of the included activities and is calculated by the operation getstate in the class process. further on, the operation getactivity returns the requested activity instance and is needed by the subsequent invariants presented in section 2.3 which describe the business logic. it is coded in ocl [8] as follows and will be interpreted by the uml tool use [5]: getactivity(n:string):activity = activity->any(a|a.name=n) an activity can have a set of iterationactivity that describes the action in every iteration cycle. the following invariant expresses the relationship between the parent activities to its iteration instances. if the parent activity is in the state done the iteration instances have to be done as well. context activity inv iterationactivities: self.state=#done implies self.iterationactivity->forall(a|a.state=#done) at last, there are two associations to the class uio that provide the connection to the uiobjects. thereby, constraints can describe dependencies between business process and data in the ui-object. dependencies from the direction of the process to the ui-objects will be described in section 2.4. constraints that describe effects from the ui to the busine ss process will be part of section 3. also, details of the ui models and special interface types will be introduced there. the lifecycle of the activities is important for the business process logic described by ocl invariants in section 2.3. it is shown in figure 2. the activities are initialized to the state waiting. after invoking the operation start on an activity instance, the state will be changed to running. the activity instance can terminate in the states done, skipped or failed. declarative business process models using ocl proc. ocl 2009 5 / 16 fig. 2. the state chart models the life cycle of instances of the class activity in the meta-model the behavior specified in the state chart will be modeled by ocl preand post-conditions for all of the operations listed in the class activity in the uml tool use. for example the precondition of the operation start specifies that the corresponding activity is in the state waiting and the post-condition states that it has changed to running. in ocl this is expressed as follows and the conditions of the further operations are specified analogously. context activity::start() pre iswaiting: state=#waiting post isrunning: state=#running 2.2 concrete process level the concrete process level is achieved by inheritance relationships between the meta-class and the modeled subclasses which can be seen in figure 3. the process lectureadt represents the concrete process in there. it is connected with 3 activities that are described by the concrete activity classes homeworkperiod, testperiod and exam. the homeworkperiod and testperiod are iteration activities that include the activities homework and test. process definition invariants are specified for the subclass lectureadt. first of all the names of the included activities are expressed in the first invariant. then the second invariant ensures that selected activities are of the corresponding types. further on, the iteration activities can be connected to the period activities in an analogous way so that these invariants are omitted here. context lectureadt inv lectureexamination: self.activity.name = bag{'testperiod','homeworkperiod','writeexam'} context lectureadt inv specialoperations: self.getactivity('testperiod').oclistypeof(testperiod) and self.getactivity('homeworkperiod').oclistypeof(homeworkperiod) and self.getactivity('writeexam').oclistypeof (exam) eceasst 6 / 16 volume 24 (2009) fig. 3. the relationship between the meta level and the concrete modeling level. concrete process, activities and ui-objects are represented by different classes in the concrete level. 2.3 business process logic described by invariants the process logic is described by ocl invariants. there are several well known temporal relationships between activities like the sequence relationship or the iteration that can be described in that way. these relationships are often used in the typical process modeling languages. in the examination process of our case study there is a sequence relationship between homeworkperiod and exam. it is described in the invariant homework_exam_sequence which can be seen beneath. the same relationship exists between testperiod and exam and can be specified in a similar way. with our declarative process modeling approach we can describe additional temporal relationships that cannot be expressed by the common process modeling languages [4] and are not part of the workflow patterns [6]. the invariant testperiod_in_ homeworkperiod is an example for that. it expresses that the test-period has to be during the homework-period with no further temporal limitation. context lectureadt inv homework_exam_sequence: self.getactivity('writeexam').state=#running implies self.getactivity('homeworkperiod').iterationactivity->forall(a|a.state=#done) context lectureadt inv testperiod_in_homeworkperiod: self.getactivity('testperiod').state=#running implies self.getactivity('homeworkperiod').state=#running the ocl constraints for expressing the temporal relationships are quite verbose. to make this approach more practicable, the meta-model can be extended with more subclasses derived from the class activity that have particular properties expressed by predefined constraints similar to the class iterationactivity introduced in section 2.1. for example subclass sequenceactivity can be derived from the class activity and an association is connecting the declarative business process models using ocl proc. ocl 2009 7 / 16 activities that are subsequent in the process logic. at design time the process modeler only has to specify which activities have to be connected instead of writing the verbose constraints. to support the process modeler while designing the process models, invariants for the declarative process models could be generated out of a graphical oriented modeling tool similar to the declare designer [18]. so, such a modeling tool would be wishful also for the approach presented here. more complicated relationships can be added by specifying explicit ocl constraints afterwards. 2.4 dependencies of activities to user interface objects an advantage of our declarative process modeling approach is the access to the ui elements and the data in there. we can describe specific states of the business process by referencing the states of including activities and then make constraints to the expected data from the user interface. the invariant examonlyif_homeworkpassed describes that if the exam is running the tests written before have to be passed with a rate better than 50 percent. for the successful passing of the homework also 50 percent of the maximal points have to be collected. this issue is proven with the invariant examonlyif_homeworkpassed. context exam inv examonlyif_testspassed: let percents:bag(integer) = self.process. getactivity('homeworkperiod').iterationactivity.uio.oclastype(homeworkuio).getvalueasint() in self.state=#running implies percents->sum() / percents->size() > 50 context exam inv examonlyif_homeworkpassed: let homeworks:set(activity) = self.process.getactivity('testperiod').iterationactivity in self.state=#running implies (homeworks.uio.oclastype(homeworkuio).getvalueasreal()->sum() / homeworks->collect(a|a.oclastype(homework).maxpoints)->sum()) * 100 > 50 a further aspect for the whole process state can be expressed by referencing data from the corresponding ui-object. by overwriting the operation getstate() of the meta-class process in the concrete process lectureadt we have the possibility to express that the whole examination process is only done if all included activities are done and the ui-object of the exam has a grade better than 5 which means successfully passed in germany. if it would have been a 5 the examination process would have failed. the other two possible process states are running and waiting. the operation getstate(), to calculate the applicable state, can be seen in its following ocl-specification. getstate():state= if activity->forall(a|a.state=#done) then if getactivity('writeexam').uio.oclastype(examuio).getvalueasint() < 5 then #done else #failed endif else if activity->exists(a|a.state=#running) then #running else #waiting endif endif eceasst 8 / 16 volume 24 (2009) 2.5 process animation in use the process can be instantiated and animated in use in connection with assl (a snapshot sequence language) [5, 7]. use interprets the assl procedures and commands take effect on the object model like creating, deleting or changing objects or links. the model of figure 3 is specified for use and an assl process instantiation procedure will create the process instance. fig. 4. a snapshot of the process instance with activities and corresponding ui objects the assl commands in that procedure will result out of the process definition invariants of section 2.2 that have already specified which activities are included in the process. for example in invariant lectureexamination the activity “writeexam” is defined and its type exam is assigned by the invariant specialoperations. further, the initial state waiting of the activities are set in the assl instantiation procedure and the ui-objects will be created and linked to the corresponding activities as well. figure 4 is showing such a process instance. having the process instance, activities can be started, finished, skipped or failed. these commands can also be expressed in assl procedures. an assl procedure invocation is executed only if no invariant is violated after the execution of the procedure run. otherwise use informs the user that no valid state is found and the assl commands will not take effects on the object model. the invariants are checked and monitored at runtime by use. by that a constraint controlled execution of the process model is guaranteed. figure 4 is showing a snapshot of a process after instantiating it and invoking some start() and finish() operations on several activities that have not violated any constraints. the invocation sequence of the operations will be logged in the sequence diagram in use and can be seen in figure 5. declarative business process models using ocl proc. ocl 2009 9 / 16 fig. 5. a sequence diagram showing the scenario until the snapshot of figure 4 is taken the assl operations for starting and finishing the activities have to be invoked at the console in use. for validating the process definition by animating and simulating process instances, it would be wishful to have a process view in use where process executions can be visually animated and the assl procedure-invocations for starting and finishing activities are provided by a gui. 3 models for ui 3.1 user interface modeling modeling user interfaces (ui) is a well investigated research topic. for more than twenty years user interfaces are specified in terms of instances of meta-models. approaches differ in levelof-detail and abstraction, domain, interface modalities and target devices. yet, most common and among the earliest, were model-based systems for text-based interfaces and typical window-icon-menu-pointer (wimp) style graphical user interfaces. in model driven user interface development (md-uid), as well as in model-driven software development, a distinction is made between platform independent (pim) and platform specific models (psm) [13]. a platform in md-uid is considered to be a certain device or rather the interface source code itself. interface source code is not necessarily source code of eceasst 10 / 16 volume 24 (2009) certain, more or less well known, programming languages. more and more interfaces are described in a markup language. a very well known example is html. closely related to model-based user interface development are any types of xml-based ui-languages. their main advantage is an available well-defined grammar and their hierarchical structure. because of these characteristics the definition of an mof like metamodel is comparatively easy. two xml-based ui languages can be considered wide-spread: xaml, which is used throughout microsofts .net framework, and xul [9] of the mozilla corporation, used in the firefox web browser and other products. other xml-ui languages were developed for research purposes and are mostly used in academic context. these include for example usixml, uiml and ximl. md-uid concepts are often based on at least three interrelated models. those models are found in early systems like e.g. mastermind [15] as well as current systems as e.g. zhao’s [17]. one of these models is a task model which describes the activity a user wants to accomplish in terms of goals, sub-goals and temporal relationships. a presentation model defines layout, interaction objects and control flow. and the domain model which describes the application domain, i.e. its objects or other environmental constraints. using declarative modeling to describe user interfaces is also a well-known concept in md-uid, fuse [16] of 1995 was an early system dedicated to formal definition of user interfaces. those models are found in our approach as well, though not as explicit models. the invariants of section 2.3 define temporal relations and goal decomposition very similar to a task model. we consider the concrete process model as our domain model. obviously, this is not the best solution one can think of. we had some discussion whether to introduce a specific data model, but eventually decided not to. the major reason was brevity and that domain modeling is not the core of the approach presented here. the remainder of this paper describes the presentation model of our approach. in the meta-model for the business process modeling approach we use a very concise user interface model. it basically consists of the abstract class uio and the interfaces valueinterface, textinterface and eventinterface. the name uio is short for user interface object which is a generic expression for any element on any kind of human-computer interface. class uio does not specify any attributes or operations. its main purpose is to serve as super type within an inheritance hierarchy. the interfaces mentioned before are intended to define fixed and in particular typed methods of accessing internal state and value information of concrete user interface objects. every concrete user interface object has to be an instance of a subclass of uio and should implement one or more of the interfaces, whichever is appropriate. figure 6 shows the user interface part of our workflow meta-model. we consider those four types as sufficient to specify a platform independent model of an user interface. as platform specific model for uis we decided to use xul. one reason for this decision was the availability of an advanced rendering engine, which is open-source and independent of the underlying operating system. furthermore we already have a visual editor for xul at our disposal. and more over, xul is also used as main ui-language in our other research. declarative business process models using ocl proc. ocl 2009 11 / 16 fig. 6. types for linking to user interfaces in meta-model to use xul as psm for uis within our approach we first had to define a mof-based metamodel for it. so we developed an emf ecore [11] model for this purpose. we chose an ecore model over a use model because we found the support for large models in use insufficient. this is mainly because use does not offer packages or interfaces. using freely available sources it is possible to construct a xml schema definition (xsd) for xul. having a schema definition, a first ecore model for xul was easily generated. the generated model had a number of disadvantages, e.g. many numbered or anonymous types, and we found it was unnecessarily complicated. so we manually refined and restructured the model. figure 7 visualises the basic hierarchy within the xul ecore model. many types, either representing concrete user interface elements or used to structure the model, were omitted to not waste space. to give an idea about the size: the model consists of 31 data types, 151 classes and interfaces with 443 attributes in total. xulelement is the root element of the type hierarchy; it has a lot of attributes which are valid for every xul tag. every attribute is initialized with a sensible default value or remains unset if no value is required explicitly. templatecontrol is the root type for any xul tag that controls the template engine. infoelement is the super type of every tag that is not displayed but defines actions, key bindings and such. any type that implements containerchild can be placed into a visual container. most implementors are concrete visibletype objects, some are visual containers themselves. containerelement is a marker class for all elements which are able or require containing subelements. a genericcontainer object is a visual container that includes children of type containerchild. an example could be a group box, which is a bordered box that has a caption, which has some labels and buttons in it. radiotype is a radio-button, buttontype a plain button, labeltype a label and textboxtype a textbox. those four types are the only concrete classes of figure 7. each such type represents a concrete user interface object. eceasst 12 / 16 volume 24 (2009) fig. 7. section from xul meta model the xul meta-model we developed can be used as a descriptive model for xul user interfaces. beside it’s usage in the context of this paper, it is the foundation for a number of tools we are currently working on in md-uid. 3.2 coupling workflow modeling and user interfaces section 3.1 presented two kinds of meta-models. now we would like to show how the combination of both can be used to connect user interface objects to a workflow. it was mentioned that the workflow model of section 2 includes references to platform independent user interface objects. those are specified in a platform independent manner using the type uio. to obtain concrete user interface objects we merge the xul meta-model and the ui model of the workflow meta-model. to achieve this multiple inheritance is used. every user interface object of an activity or a process object must be a member of a concrete class. such class has to inherit from class uio and from its representing xul metatype class. if needed, it also would inherit or implement the appropriate value type interface. to give an example: the workflow activity homework might be presented using a textbox to input the points a student achieved in this particular assignment. therefore a user interface object is needed that provides such an input and is able to disclose the point count to any stakeholder or constraint. for this purpose the class homeworkuio is defined within our concrete workflow model. it inherits from uio, from textboxtype and implements valueinterface. the attribute uio of type homework in our concrete workflow is able to hold references to homeworkuio objects. when generating code one would implement the method getvalueasreal() with an implementation like: return parsefloat(this.value). the value attribute is an xul attribute of textboxes and it is available in homeworkuio through inheritance from textboxtype. declarative business process models using ocl proc. ocl 2009 13 / 16 often one would like to group similar user interface objects within a visual container. as we decided to keep our ui-pim most concise, the uio does not provide any mechanism to specify parent/child relations or containment associations. this was a deliberate decision, which was made to keep the focus on the declarative workflow aspects in our meta-model. nevertheless containment relations can still be modeled through the platform specific model. we consider grouping as an important layout problem, but not as a crucial part of a platform independent workflow ui model. for specifying parent/child relations we can easily use genericcontainerelement’s containment association children. in continuation of the example for the homework activity we may want to group all homeworkuio into a certain screen area. the activity type homework was specified as an iterativeactivity and its instances are repeated within a homeworkperiod object. we would now define a class homeworkperioduio that inherits from uio and groupboxtype. groupboxtype is a subtype of genericcontainerelement and also of containerchild. this means that a xul groupbox contains child elements and also may be a child in another container. we do not implement any of the value conversion interfaces, because there is no sensible value or state to report to anybody. in an instantiated workflow homeworkuio objects may now be placed as children of a homeworkperioduio object. in fact any uio object of the workflow instance that implements containerchild may be placed in this group. if such freedom is unwanted, restrictions can be introduced by appropriate constraints. we do not intend to describe the whole user interface of a workflow declaratively. but nevertheless it seems sensible to define some constraints on the psm level of a ui. other sample constraints might be the requirement that the uio of a process is a containerelement or that every visual container needs to have children. of special interest in the context of this paper are constraints that take effect on the workflow. by integrating the uio into the workflow meta-model we provided a mean of bidirectional control. that is we can control the ui via workflow and vice versa. we assume that constraints from the user interface will mostly be based on the internal state of a certain uio. once again the value and state interfaces with their typed methods are used. an example of a constraint that affects the workflow can be defined in the context of homeworkuio. we may define that the homework activity which is connected to a certain homeworkuio can never be in the state of ‘done’ if there is no text entered into the uio’s textbox. this constraint might be defined as follows: context homeworkuio inv assignmentpoints: self.value.oclisundefined() implies self.activity.state<>#done more complex constraints are of course conceivable, e.g. for a homeworkuio a constraint which is composed over all its child-uio’s. however, almost all constraints will probably declare implications for the state of a certain activity object. eceasst 14 / 16 volume 24 (2009) 3.3 runtime user interface the ui model which we specified using the methods presented in section 3.2 is sufficient to generate a functional user interface. unfortunately the tool chain we use is not. for the time being use does not provide a feasible method of interaction with other tools. a plug-in interface is under development, but not available right now. we do need such an interface to create an adapter or proxy between our selected ui renderer and use. in our case the renderer of the psm ui-model could be any instance of the gecko rendering engine of the mozilla corporation, as for example the firefox web browser. some of the features of use are available within the eclipse platform and emf as well. to bridge the time gap until use becomes fully usable to us, we attempt to validate our approach within emf. the rest of this section describes how concrete user interface can be generated from our meta-model and what kinds of checks to the ui model are still possible. as mentioned earlier, our target ui language is xml based. the task to convert the instantiated concrete workflow ui model into a valid xul file is assigned to a template engine. we decided to use openarchitectureware [10] (oaw) xpand. one reason was that xpand’s template is polymorphy-aware; also it provides functional extensions and a model validation mechanism. before generating any user interface code we have to specify all uio types, instantiate a workflow, create the required number of activity and uio instances and associated them among each other. figure 3 shows all uio classes specified for the workflow of our lecture example. table 1 gives the type definitions for all five concrete uio types after inheriting from the xul and workflow meta-models. type supertypes lectureadtuio uio, windowtype homeworkperioduio uio, groupboxtype testperioduio uio, groupboxtype homeworkuio uio, textboxtype, valueinterface testuio uio, textboxtype, valueinterface table 1. effective supertypes of concrete uio types an instance of our concrete workflow contains the appropriate amount of objects of each type. the instantiated concrete workflow is available as ecore model and should include the concrete uio objects. figure 8 depicts such an example. the next step towards the generation of a xul file is model validation. openarchitectureware includes a dedicated language, named check, to specify validation constraints. we use it to do some consistency checks. for example we check that no uio is assigned to a process and an activity. this check is necessary since the meta-model specifies those two associations as xor, which is a constraint that cannot be directly mapped to an ecore model. all other reference constraints that stem from the workflow meta-model are checked by the emf validation framework itself, i.e. for example 1:1 relations. besides those constraints there are rules which originate from the platform specific ui model and requirements towards the merging of business logic and user interface. for example declarative business process models using ocl proc. ocl 2009 15 / 16 there is a requirement that all uio need to have an id and another is that a groupbox has to have a caption defined. after the model validation was successfully completed the source code generation is run. in our case xpand’s template engine is started with the root process object and some appropriate templates [12] and functional extensions. those extensions are specified in xtend, another oaw language, and generate certain names and default xul attributes for the source code. in figure 8 the resulting xul ui is depicted on the right side. left is the source ecore model. as a slight deviation from the use meta-model a root container type, named workflow, was introduced within the emf meta-model. the reason was purely technical. to reduce effort we always planned to use the generic emf editor for our ecore models. with that editor we needed a container object where to create the uio instances. instead of bending the workflow meta-model we decided to introduce a container class on top. an import aspect to note about the user interface we created is that its layout is static in the first place. when the coupling to a runtime environment is eventually implemented we will be able to have the user interface become more dynamic. in a first step we will enable or disable certain components depending of the state of their associated activity. also we might reveal certain uio’s only if their activity was started. xul in combination with a script language has the ability to this. fig. 8. ecore model and generate user interface 4 conclusion in this paper we have connected two fields that are relevant for the development of businesses process oriented software: business process modeling and ui modeling and generation. in the first part a declarative approach was presented to model flexible business process logic. the essential temporal relations of activities are expressed by that. a meta-model to support this approach was developed and presented. using this meta-model a concrete process eceasst 16 / 16 volume 24 (2009) was specified, animated and visualized in the uml tool use. necessary constraints were presented and explained. in the second part of the paper the ui aspect of workflows was covered. to develop a visible prototype of the ui it was useful to use existing technologies. the models of part 1 have been adapted to the emf technology. model to model and model to text transformations have been used to derive a ui mockup from an instantiated workflow process. this user interface prototype was specified using xul. problems of connecting the use implementation of declarative process models to ui modeling and generation have been discussed. both parts of the paper have been connected by using the same uml models and a throughout case study. bidirectional dependencies of the business process and the user interface have been defined by ocl constraints. references 1. omg bpmn specification 1.1: http://www.omg.org/docs/formal/08-01-17.pdf (visited july 19, 2009) 2. omg uml superstructure specification v.2.1.2: http://www.omg.org/docs/formal/07-11-02.pdf, pp.295-418 (visited july 19, 2009) 3. lecture of abstract data types, university of rostock: http://wwwswt.informatik.unirostock.de/lehre/vorlesungen/vadt.html (visited may 9, 2009) 4. brüning, j.: declarative workflow modeling with uml class diagrams and ocl. in: bpsc2009, lni-p 147, pp. 227-228, 2009. 5. a uml-based specification environment, university of bremen: http://www.db.informatik.unibremen.de/projects/use/ (visited july 19, 2009) 6. van der aalst, w., ter hofstede, a., kiepuszewski, b., barros, a.: workflow patterns: distributed and parallel databases, 14(3): 5-51, july 2003. http://www.workflowpatterns.com/documentation/documents/wfs-pat2002.pdf (visited july 19, 2009) 7. gogolla, m, bohling, j., richters, m.: validating uml and ocl models in use by automatic sn apshot generation, journal on software and system modeling, 4(4):386-398, 2005. http://www.db.informatik.unibremen.de/publications/gogolla_2005_sosym.ps.gz (visited july 19, 2009) 8. omg ocl specification: http://www.omg.org/docs/ptc/03-10-14.pdf (visited may 9, 2009) 9. xul, xml user interface language, http://developer.mozilla.org/en/xul (visited july 19, 2009) 10. openarchitectureware http://www.openarchitectureware.com/ (visited may 9, 2009) 11. eclipse modeling framework technology, http://www.eclipse.org/modeling/emft/ (visited july 19, 2009) 12. wolff, a., forbrig, p.: deriving user interfaces from task models. mddaui '09, proc. of the iui'09 workshop on model driven development of advanced user interfaces, ceur workshop proc. 439. ceur-ws.org, 2009. 13. stahl, t., völter, m.: modellgetriebene softwareentwicklung techniken, engineering, management, dpunkt.verlag, 2005 14. pesic, m., schonenberg, m.h., sidorova, n., van der aalst, w., et.al.: constraint-based workflow models: change made easy. in: otm 2007, lncs 4103, pp. 77–94, berlin, springer, 2007. 15. lonczewski, schreiber; the fuse system: an integrated user interface design environment; 1996 16. szekely, p., sukaviriya, p., castells,p., muthukumarasamy, j., salcher, e.; declarative interface models for user interface construction tools: the mastermind approach; ehci'95 17. zhao, x., zou, y., hawkins, j., madapusi, b.; a business-process-driven approach for generating ecommerce user interfaces; models 2007, nashville 18 pesic, m., van der aalst, w.; declare: full support for loosely-structured processes, proceedings of edoc 2007, ieee computer society, annapolis, 2007 19 schonenberg, m.h., mans, r.s., russell, n.c., et.al.; towards a taxonomy of process flexibility (extended version), bpm center report bpm-07-11, 2007 http://is.tm.tue.nl/staff/wvdaalst/bpmcenter/reports/2007/ bpm-07-11.pdf (visited july 19, 2009) a workbench for preprocessor design and evaluation: toward benchmarks for parity games electronic communications of the easst volume 23 (2009) proceedings of the ninth international workshop on automated verification of critical systems (avocs 2009) a workbench for preprocessor design and evaluation: toward benchmarks for parity games michael huth, nir piterman, and huaxin wang 15 pages guest editor: markus roggenbach managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst a workbench for preprocessor design and evaluation: toward benchmarks for parity games michael huth, nir piterman, and huaxin wang department of computing, imperial college london abstract: we describe a prototype workbench for the study of parity games and their solvers. this workbench is aimed at facilitating two activities: to aid in the design, validation, and evaluation of preprocessors for parity game solvers; and to aid in the generation of benchmark parity games that are meaningful for a wide range of solvers. our workbench allows for easy composition of preprocessors, can populate databases with games and their meta-data, offers a query language for generating games of interest, and has already found potentially hard games. keywords: parity games. preprocessors. benchmarks. solvers. 1 introduction parity games are determined 2-player games with memoryless winning strategies. these games are of fundamental interest in formal verification. their natural decision problem, whether a particular node is won by a particular player, is equivalent to that of local model checking for the modal mu-calculus (whether a state s in a kripke structure satisfies formula φ ) [sti95]. therefore, any algorithm for solving parity games (referred to as “solver” subsequently) can serve as a model checker for the modal mu-calculus. also, these decision problems therefore have the exact same complexity – whose determination is a longstanding open problem with the best known upper bound being up∩coup [jur98]. parity games (often referred to simply as “games” subsequently) have applications beyond model checking, e.g., in the synthesis of reactive systems from specifications [pr89] and in the determinization of automata [ms95]. thus the design and evaluation of solvers is an important activity with impact beyond the area of model checking. formally, a parity game g is a pair ((vg, eg), χg) where (vg, eg) is a directed graph1 (the game graph of g) such that vg is partioned by finite sets v g0 and v g 1 of nodes owned by player 0 and 1, respectively; and χg : vg →{0, 1, . . .} assigns colors χg(v) < ∞ to nodes. we now explain how these games are played. a play in game g starts at some node v in vg. the player who owns v then chooses some v′ with (v, v′) in eg as next node. the play continues from v′ in the same manner and thus generates an infinite sequence of nodes (as our game graphs have no deadlocks). now consider the largest color k of those nodes that occur in that sequence infinitely often. if k is even, player 0 wins that play, otherwise player 1 wins it. a strategy for player σ is a partial function π from v g σ into vg such that (v, π(v)) ∈ eg whenever π(v) is defined. a play is consistent with strategy π if all choices made by player σ in that play are made according to π . strategy π is winning at node v (for player σ ) if all plays beginning in v 1 without loss of generality, we assume that there is no v in vg with (v, v) ∈ eg (no self-loops), and that for all w in vg there is some w′ with (w, w′) in eg (no deadlocks). 1 / 15 volume 23 (2009) workbench for preprocessors of parity games figure 1: an 8-node parity game with 9 edges, and its solution. nodes have canonical names, e.g. v0. squared nodes are owned by player 1, circled ones are owned by player 0. colors χg(v) are written within square brackets in nodes. all nodes are won by player 1, and so the solution consists only of her strategy, indicated by boldface edges. and consistent with π are won by player σ . a central, well-known result is that each parity game g has a partition w0 and w1 of vg and both players σ have strategies πσ winning for all nodes in wσ (see e.g. [zie98]). winning regions and winning strategies constitute a solution of that game. figure 1 shows a very simple parity game. throughout the paper square nodes (set v g1 ) are owned by player 1, circled nodes (set v g0 ) are owned by player 0. the color χg(v) is written within node v in square brackets. nodes have canonical names v0, v1, etc. edges display eg. nodes colored green are won by player 0 (there are none in this game), nodes colored red are won by player 1. boldface edges incidate moves of winning strategies. the winning strategy for player 1 moves to node v4 whenever it can. otherwise, it moves to v7 or to v3, which it owns and from which it can move to v7. this strategy is winning for all nodes since it traps player 0 into cycles through v4, all of which player 0 loses. the parity game in figure 6(b) shows a non-trivial partition into winning regions. player 0 wins nodes v2, v4, and v7 whereas player 1 wins all other nodes. solvers partition, on input game g, set vg into nodes won by player 0 and 1, respectively; and supply winning strategies for those winning regions. existing solvers may be sub-exponential in the number of nodes (e.g. [jpz08]) but they either have exponential worst-case running times in the index of the game g (the largest color in g plus 1: index(g) = 1 + maxv∈vg χg(v)) or it is not known whether they have polynomial running time. given two solvers, it is not at all clear how to compare them. the worst-case input for one solver, e.g., may well be trivial as input for the other solver. and comparing solvers on a set of games is only meaningful in as much as these games can be claimed to be hard to solve for any solver. this situation is reminiscent to that of sat solvers, where one has a set of benchmarks (formulae of propositional logic) whose satisfiability checks are known to be challenging for existing sat solvers – e.g. a propositional logic encoding of an elementary pigeon hole principle, that n pigeons cannot be placed into n−1 proc. avocs 2009 2 / 15 eceasst pigeon holes without sharing. another motivation for this paper is subject to future work: while current research focuses on complete algorithms (that decide the winners of all nodes), we want to consider incomplete algorithms (that decide winners of only some nodes) that work well in practice. an, at first sight unrelated, issue is the design and evaluation of preprocessors for parity games. by a preprocessor we mean any tool that simplifies a parity game before it passes the simplified game on to a parity-game solver. the nature and extend of these simplifications can vary from trivial conversions to the solution of an “easy” part of the parity game. one form of preprocessing is that one can transform the game g into one that is free of selfloops (edges (v, v) ∈ eg from a node v to itself) and deadlocks (nodes v that don’t have outgoing edges), without changing the solution of the original game. this form of preprocessing is so basic, and unhelpful for the task of finding benchmarks, that we only consider games without self-loops and deadlocks in this paper. at the other end of the spectrum we have solvers, which are unhelpful for generating benchmarks that are meaningful for a whole class of solvers: a set of games that is hard for one solver may not be hard at all for another solver. aim of work reported here. the idea of this paper is therefore to explore the middle of that spectrum, algorithms that perform non-trivial simplifications of games and can be interpreted both as preprocessors (since they don’t solve all games) and as solvers (since they may solve a substantial portion of the game, leaving a computationally hard core behind). the overall aim of this work is therefore to develop a workbench in which an entire spectrum of such preprocessors (including solvers) can be expressed, implemented, and evaluated. this workbench is meant to support the generation of a database of games and their meta-information, so that users or automated search processes can submit queries that may return games of interest, and may validate preprocessors and solvers as well as their optimizations. related work. it is widely recognized that no meaningful set of benchmarks for parity games is presently available. experimental work for solvers by and large focuses on the optimization of the underlying algorithms and their data structures. such optimizations improve performance but make fair comparisons between solvers harder, even if good benchmarks were to be available. the work in [ach09] developed preprocessors a1, a2, a3, and probe[n](a) mentioned in this paper. but that work provided no preprocessor algebra, no query language, and no implementation work. the aforementioned preprocessors and zielonka’s solver [zie98] were implemented as a desktop application in [wan07], where also first statistics were run on the preprocessing of parity games. in [fl09] the authors propose to use a generic solver that first does some preprocessing, then uses optimized solvers on special residual games (e.g. one-player games and decomposition into strongly connected components), and then only uses an input solver on residual games that cannot be further optimized. experimental results show that this approach can procude vast speed-ups and that zielonka’s recursive algorithm [zie98] performs surprisingly well. outline of paper. in section 2 we define an algebra for composing preprocessors for parity games, impose requirements on terms from that algebra, and give some examples of preprocessors generated in that algebra. syntax and semantics of a query language for a database of parity games are provided in section 3. a prototype of our workbench, implementing an instance of the above algebra and the query language, is described in section 4. some implementation issues 3 / 15 volume 23 (2009) workbench for preprocessors of parity games are discussed in section 5. in section 6 we illustrate how the workbench can be used to design, validate or evaluate preprocessors – and how it can generate games of interest. future work and our conclusions are stated in section 7. 2 algebra of preprocessors we now provide a simple specification language for preprocessors that abstracts away low-level programming details and focuses on how to compose preprocessors out of more basic ones. algebra and its informal meaning. the preprocessors we consider are generated as regular expressions p ::= a | p; p | p+ | f (p) (1) where a ranges over a set of atomic preprocessors (which can thus accommodate any externally supplied preprocessors), p1; p2 denotes the sequential composition of preprocessors p1 and p2 in that order, p+ denotes the iteration of the preprocessor p, and f (p) is the “lifting” of preprocessor p by a function f . atomicity and sequential composition are natural concepts for constructing preprocessors. the meaning of the other clauses is best explained by means of examples, where we write res(g, p) to denote the game output by preprocessor p on input game g, also called the residual game of g under p. two color-simplifying atomic preprocessors. let a1 be an atomic preprocessor that checks on game g, only once for each node v with χg(v) ≥ 2, whether there is any cycle in the game graph through v and through some node w with χg(w) = χg(v)−1. if there is no such cycle (in particular, if there is no cycle through v at all), a1 updates χg(v) by subtracting 2 from it. in the game in figure 1, e.g., a1 could decrement color 5 at node v2 to 3, since there is no node with color 4 in any cycles through v2. then a1 could decrement color 2 at node v5 to 0, since v2 isn’t on any cycle, etc. preprocessor a2 similarly explores each node v with χg(v) > 0 once. if all cycles through v have a node w with χg(v) < χg(w), then a2 updates χg(v) to 0. in the game in figure 1, e.g., this could reset the color of node v6 from 2 to 0, since all cycles through v6 also go through v2 which has color 5. iteration. preprocessor a1 is not idempotent: running it twice may get a simpler game than running it once (e.g., the first run may change a 5 into a 3, which then allows a 6 that was “blocked” by that 5 to change to 4). for input game g, preprocessor a+1 keeps applying a1 until reaching a fixed point. preprocessor a+1 preserves the initial game graph and terminates on all games, as seen through the well-founded ordering g ≺a1 g ′ iff ∑v∈vg χg(v) < ∑v∈v ′g χg′(v). for any preprocessor p, iteration p+ is well defined iff there is a well-founded ordering ≺p on games such that for all games g with g 6= res(g, p) we have res(g, p) ≺p g. a preprocessor p is idempotent iff p; p and p have the same effect on all games g. then p+ is well defined with discrete well-founded ordering. generally, all well defined p+ are idempotent preprocessors. a preprocessor using index-3 abstraction. atomic preprocessor a3 operates on game g as follows. it generates a sequence of index-3 games that have the same game graph as g and whose winning regions for one player σ are also won for that player in g. any such winning proc. avocs 2009 4 / 15 eceasst regions are deleted from g (technically, closed up under σ -attractors), and a new such sequence of index-3 games is generated on the resulting game until the game no longer simplifies. for example, if g initially has index 5, one such index-3 abstraction turns color 4 into color 2, colors 3 and 5 into 1, and all other colors into 0. any node v won by player 1 in this modified game, can ensure that any path from v in g has either infinitely many colors 3 or 5, and only finitely many colors 4. any such node is thus certain to be won by player 1 in g. the game in figure 1, e.g., is solved completely by the composed preprocessor a1; a3. a preprocessor transformation. the lifting clause f (p) has as intuition that f is a device that lifts the effectiveness of preprocessor p. we give an example, lft, such that lft(a3) acts on g as follows. it considers each node v of g with at least two outgoing edges in turn: for all pairs of such outgoing edges, it creates two subgames (which implement only one of these edges and remove all other outgoing edges of v), and runs a3 on these subgames. if a3 decides for some node z in vg a different winner in each subgame, node v is won in g by the player who owns it (since a3 correctly classifies winners of deleted nodes in input games and since nodes not won by their owner cannot display such observable differences), and no further pairs of subgames for v need to be considered. thus lft(a3) also correctly classifies winners of nodes it deletes. the residual game res(g, lft(a3)) is obtained from g by removing all nodes v (and their edges) whose winners are decided in this manner. by induction, this is also sound for higher-order lifts lftk(a3) with k ≥ 1, where f 1(p) is defined as f (p) and f n+1(p) as f ( f n(p)). we note that f k(p) generally does not have the same effect as the k-fold sequential composition of f (p) with itself. requirements on preprocessors. although our algebra for preprocessors is very general, we impose four requirements on all preprocessors implementable in our workbench: 1. the game graph of res(g, p) is a sub-graph of the game graph of g 2. the preprocessor p decides (correctly) the winners of all nodes of g that are no longer nodes in res(g, p) 3. for each node v on the game graph of res(g, p), its winner is the same in both games g and res(g, p) and 4. for each node of res(g, p), its color in res(g, p) is no larger than its color in g. the first requirement limits the effect that preprocessors have on the game graph to the deletion of nodes and edges. the only preprocessors that we know to violate this requirement are those that eliminate self-loops and deadlocks (which we don’t consider). if one wishes, one can actually drop this requirement without affecting the overall working of our framework. the next two requirements require little explanation: it only makes sense to remove a node from considerations when it has been decided which player wins it; and residual games have to be consistent with the original game in terms of which player wins residual nodes. the last requirement may also be relaxed but then the iteration of preprocessors may diverge. we therefore adopt this requirement as a static constraint that, in conjunction with the other requirements, ensures that iterations converge. specifically, preprocessors p meeting these four requirements have well defined p+: this is certainly true if p acts as the identity; otherwise, p has a well founded order g ≺ g′, defined as rank(g) < rank(g′) for the rank function rank(g) = |vg |+|eg |+ ∑v∈vg χg(v). 5 / 15 volume 23 (2009) workbench for preprocessors of parity games as michael goldsmith pointed out at the workshop, one can define a choice operator p⊕q for preprecessors that is implicitely dependent on a well founded order ≺. for a game g, residual game res(g, p⊕q) equals res(g, p) if res(g, p) ≺ res(g, q); otherwise, it equals res(g, q). a composition pattern. we illustrate the utility of our algebra for composing preprocessors. let p1, . . . , pn be preprocessors for which p + i is well defined, and π a permutation of {1, . . . , n}. then 〈p1, . . . , pn〉π is defined to be (p+π 1; . . . ; p + π n) +. this is well defined since each pi has a well-founded ordering ≺pi and so their lexicographical ordering is a well-founded ordering for 〈p1, . . . , pn〉π . for example, for n = 3, for pi being ai, and for π being (2, 3, 1) this yields the preprocessor (a+2 ; a + 3 ; a + 1 ) +. 3 database of games we can leverage the algebra for preprocessors to a query language over a set of games. query language. the query language is a fragment of first-order logic where formulae are closed and contain only a single and top-most quantification. the grammar for queries is given by q ::= ∀g : b | ∃g : b (2) where g is a fixed variable that ranges over all games in a specified set of games d (a database), and b is the yet unspecified body that can only mention variable g, which binds to games g. the grammar for b is extensible. for now, we will freely use relational and functional symbols within b in examples. figure 2 depicts examples of queries. query (3) asks whether there is a game in the database that is resilient to preprocessor p, since the equality g = res(g, p) means that p cannot simplify anything in game g. if p happens to be a very powerful preprocessor, a witness game g for the truth of this query may then be a good benchmark for solvers. query (4) asks whether preprocessors p and q have the same effect on all games of the database. if so, this does of course not necessarily imply that they have the same effect in general. this pattern has many uses, we mention two: firstly, for q being p; p, e.g., we can test whether p is idempotent on games from our database. secondly, if q is an optimization of p, we can test whether this optimization is correct for games in our database (a form of regression testing). for an example of the second kind, let p be a; lft(a) and q be lft(a). query (4) then tests on our database whether lft might be monotone in that it also does all the simplifications done by its argument a. this is not generally true as lft(a) only uses a conditionally, to probe whether certain nodes are won by certain players; it does not use a directly on the input game. in query (5), sol(g, p, 0) denotes those nodes, if any, that preprocessor p classifies as being won by player 0 in game g. if p is a solver or a preprocessor that does decide the winners of some nodes, this query therefore checks whether p is correctly implemented (relative to the trusted implementation of some solver). query semantics. we explain the semantics of query evaluation informally. a model is a database d . evaluating query ∃g : b on d either returns an empty list (saying that no game proc. avocs 2009 6 / 15 eceasst ∃g : g = res(g, p) (3) ∀g : res(g, p) = res(g, q) (4) ∀g : sol(g, p, 0) ⊆ sol(g, trustedsolver, 0) (5) figure 2: example query patterns, instantiable with preprocessors p and q. satisfying b is in the database) or returns a game g from d satisfying b. dually, the evaluation of ∀g : b either returns the empty list (saying that all games in the database satisfy b) or a game g from d that does not satisfy b. both of these evaluations require the evaluation of b on a game g in d , returning a boolean truth value. that evaluation uses the interpretations of relational and functional symbols in b and the standard semantics of propositional logic to determine whether g satisfies b. in particular, we interpret equality g1 = g2 between games as structural identity: both games have the same game graph and colors of nodes. example 1 let index(g) evaluate to the index of game g. a game g satisfies (index(g) > 5)∧¬(g = res(g, a+1 )) iff g has index greater than 5 and is not resilient to the preprocessor a+1 . similarly, query ∃g : (index(g) > 5)∧¬(g = res(g, a + 1 )) might return the game in figure 1 from our database; its index is 6 and it can be simplified by a+1 as already discussed. our implementation has explicit mechnisms for controlling the choice of database for the evaluation of queries. we do not show these mechanisms in this paper for sake of brevity. 4 implementation our prototype workbench is a fusion of a parity game solver component, a very scalable online storage facility for parity games supporting simple interfaces, a client component which talks to data servers, and a query component for analyzing results stored on the servers or derived from further computations performed on games. software architecture. the distributed and highly extensible architecture of our platform for query execution is shown in figure 3. it is comprised of three parts: • at its center, directly interfacing with users, the query server actively maintains registration of game servers and query execution processes, manages parsing and interpreting user queries at runtime, and merges computation results after query executions return from the query execution group. • on the right, we have a collection of game servers. each game server stores a particular class of parity games and other computed results related to each game instance. the game server provides a uniform interface for access of generic information. by default, queries will be directed to computations about games in all game servers. but users can specify in the query to only look at results from a particular game server. users can also easily inspect data recorded in each server through a web browser. 7 / 15 volume 23 (2009) workbench for preprocessors of parity games figure 3: overall architecture of the query engine for our workbench. and the typical sequence of interactions between user and tool. • the query execution group contains a collection of parallel processes responsible for processing a submitted query. the query execution group, implemented using jgroup, is self balanced. when a process node is shut down for whatever reason or when a new process node becomes available in the group, the group will rebalance itself evenly throughout. therefore, process nodes in the group could, in principle, reside on different machines and so facilitate parallelized query execution. user session. figure 4 shows a typical user session in our workbench. this session takes place on the query server, by that time all the games are already loaded into the process nodes. the user first enters a query as specified by the implemented query language, the server will then send the interpreted query to all query process nodes for local processing. local results will be merged back at the query server. if the result is positive for a universally quantified query, the server will just return true and no witness is provided; if a contradiction is found, the server will return false and the associated witness. an existentially quantified query will return true and the witness if a positive example is found, and returns only false otherwise. the witness will be shown in both the dot description format and as a graph. in this particular session the query asked whether, for all games, all nodes that are deleted by a1;a2;a3; p(a1;a2;a3) are also deleted by a2;a3; p(a2;a3). this is not true, and the witness produced is displayed. (the meaning of the lifting p will be explained below.) implemented algebra. the following preprocessors are implemented in our prototype workbench: a1 implements a+1 , a2 implements a + 2 , and a3 implements a + 3 . preprocessor composition p; q is implemented as first running p on g and then running q on res(g, p). the iteration p+ is implemented as a repeat-statement that initially runs p on g and then keeps executing p on the resulting game until a fixed point is reached. two types of functions are currently implemented. function l is a more complex version of proc. avocs 2009 8 / 15 eceasst figure 4: a typical user session on the query server, (1) the user enters a query; (2) the database of games is searched for a witness; (3) the interface then displays a game that refutes a universally quantified query or verifies an existentially quantified query (if applicable). function lft described already on page 5 (we refrain from sketching the details here). function p is a similar, less efficient transformation of predecessors that is based on our existing work in [ach09, wan07]. in the sequel, we write probe[n](a) for the preprocessor that initially runs a, then runs p(a), etc., and stops after it has run the n-th nesting of p on a. for example, probe[2](a1;a2;a3) expands in this manner to the term ((a1;a2;a3;p(a1;a2;a3);p(p(a1;a2;a3)) implemented query language. the query language we currently support is seen in figure 5. there are three groups in the query language. the first group specifies that formulae have a single quantification and a body built from an adequate set of propositional connectives: not, and, or. the second group lists supported predicates, that allow reasoning about the game for its solutions, nodes, edges, strategies, and colors. for example, solution(g, a, x) returns those nodes of the game that preprocessor a decides to be won by player x – our keyboard encoding for player 0; player 1 is encoded by y. the third group specifies preprocessors and their functions, here l and p. apart from the three aforementioned preprocessors, this supports exp which implements a solver based on zielonka’s algorithm [zie98]. we give two further examples of how to write queries in this language: all g : (nodes(residual(g, l(a1;a2;a3))) subset nodes(residual(g, l(a2;a3)))) stipulates that all nodes, in all games, that are solved by l with preprocessor a1;a2 are also solved by the same lifting function with preprocessor a1;a2;a3. query 9 / 15 volume 23 (2009) workbench for preprocessors of parity games querylanguage := querytype gvar : constraints querytype := all | some constraints := (constraint) | (not constraints) | (constraints and constraints) | (constraints or constraints} constraint := fragment == fragment | number >= number | number <= number | number > number | number < number | nodes subset nodes | edges subset edges | colors subset colors fragment := game | nodes | edges | number | colors game := gvar | residual(game, prep) nodes := solution(game, prep, player) | nodes(game) edges := edges(game) number := count(nodes) | count(edges) | count(colors) colors := colors(game) player := x | y prep := atom | prep; prep | l(prep) | p(prep) atom := a1 | a2 | a3 | exp figure 5: implemented query language of our prototype workbench. all g : (nodes(residual(g, c(l(l(a2;a3))))) subset nodes(residual(g, exp))) states that all games are fully solved by iterating two nestings of l when applied to preprocessor a2;a3. this is so since res(g, ex p) is the “empty” game for any complete solver exp. 5 discussion we discuss some implementation issues that have relevance to the overall aims of the workbench. data model. an essential type of object on the game server is a scratchpad, given in the form of key/value pair. resources, another essential object of our implementation, may be associated with multiple scratchpads. for example, for a scratchpad associated with a game a key may be the name of the game and the value the description of the game. games may also have associated scratchpads that record solutions, solver statistics, etc. the system is agnostic of how scratchpads are being manipulated. information submitted and accessed through a registered user account on the system is therefore interpreted by users or agents at the client side. this data model allows our workbench to be smoothly extended to work with other types of games, e.g. stochastic parity games [cjh04], with similar work flow requirements. populating databases. at present, we populate databases with randomly generated games and precompute and store the effects of many basic compositions of preprocessors. although the reliance on random games does have inherent limitations, our workbench supports the specification and storage of any kind of game, e.g. known worst-case examples for specific solvers. non-random games need to be entered manually and so we can expect to only support a limited database of such games. at present, the generation of random parity game data takes place outside of the workbench, via a command line java executable. after a game is generated, it is automatically populated to the specified server. several other processes, also invoked from the command line, pick up games from the game server and prepare and attach solutions on to the game servers. proc. avocs 2009 10 / 15 eceasst we now describe how we generate random games. for a game g with |g| = n, the index of vg can be at most n, and |eg | ranges from n to n ·(n−1) – since we have no self-loops and no deadlocks. for each possible value i of |eg | in that range, we generate (i ·n)2 different games at random. a random seed is selected. for each possible value of i, the owners of the n nodes as well as their colors are decided based on random sequences generated from that random seed. such a sequence is also used to decide which edges should be present, ingoring self-loops and avoiding deadlocks until i edges are found. in this manner, we generated 100, 352 random games with 8 nodes each. comparing preprocessors or solvers. probably the most involved analyses are performance comparisons between solvers, as head-to-head comparisons on implemented solvers. such comparisons may be tainted by implementations that optimize data structures for specific solvers. therefore, the solver package offered in this platform decouples the data structure and the algorithms, by having the latter work on an abstract parity-game interface. researchers can build their solver algorithm for this interface and use the default parity game data structure implementation provided to compare against other implemented algorithms running on the same data structure. alternatively, different data structures can be used to implement the same interface and one target algorithm can be tested for performance when applied to different data structures. a more straightforward analysis is a scalability analysis where the interest is merely in finding out how an algorithm implemented in another language and context performs over a very large data set or on very large games. this is achieved by using the connector client to download the parity game data from the data servers in batches and to solve the games locally. run-time statistics can then be compared to results from other solvers that ran on the same platform. parser and query optimization. the query parser and processor are rapid prototypes written in java. there are many issues with this choice. • it currently does not share common sub-expressions and so the meaning of such shared expressions is re-computed for each game. • it is difficult to define pattern matching rules and query optimization paths in java. this could be easily implemented in prolog. • prolog would also allow us to guide search, so that less expensive sub-expressions get evaluated first and so expensive sub-expressions may not have to be evaluated, as in a conjunction expensive and cheap. • the current version of the query language only supports a very limited set of operations because they are cumbersome to implement correctly in java. for example, we may want to query for a game with a node having n outgoing edges to nodes owned by its opponent. prolog would make it much easier to build such queries. • a potential problem with migrating parsing and executing queries from java to prolog is the need of call-backs from the prolog to the java process. we are currently evaluating the performance impact of such a need. memory footprint. because all data about all parity games are loaded into the memory in uncompressed format, the combined required memory for all process nodes can be huge. assuming each game only occupies 10kb in memory, a dataset of 10 million games requires around 11 / 15 volume 23 (2009) workbench for preprocessors of parity games 100gb of memory footprint. the ability to distribute process nodes over machines will help, but won’t achieve scalability in and of itself. two additional solutions suggest themselves. firstly, we might store boolean matrices that record values of atomic query expressions for games. the complete witness information could then be recomputed for the chosen witness. secondly, we might generate games on a hierarchy of game server arrays that would act like a sieve so that games pass through to higher level servers only if they “survive” specified queries. initial experiments suggest that this can eliminate at least 95 percent of randomly generated games. 6 using the workbench we now illustrate how one can use the current workbench prototype to evaluate and validate preprocessors and solvers. in doing so, we also generate some games that may serve as a first generation of benchmarks for solvers. figure 6 shows four interesting games, found on a database populated with more than 100, 000 random 8-node games. witness (a) is fully solved by probe[0](a2;a3) but not by probe[2](a3). that is to say, the game is fully solved by a2;a3 but not by a3; p(a3); p(p(a3)). this is perhaps surprising since the latter incrementally nests a lifting function whereas the former does not lift at all. but the latter uses a slightly weaker preprocessor and this weakness is not being compensated for in this witness game. witness (b) is solved by a2;a3 but not by a1;a2;a3. this seems counter-intuitive since the initial application of a color reduction preprocessor appears to harm the effectiveness of subsequent preprocessing. but a1 may close some “color gaps” in the game and those very gaps may enable a2 to reduce some color to 0. witness (c) is solved by a2;a3 or by l(a2;a3) but not by l(l(a2;a3)). this means that the non-idempotent lifting function l is not always more powerful than its previous nesting version. witness (c) can in fact not be solved by any further nestings of l applied to a2;a3 (we refrain from sketching the argument here). applying the iteration operator c to each function call of l would make higher nestings more powerful than lower ones. finally, witness (d) shows an 8-node game that is resilient to probe[3](a3), i.e. the preprocessor leaves the game unchanged. we also experimented with generating datasets for 64-node and 128-node games. fig. 7 shows a 64-node, 320-edge game whose subgame of grey nodes is resilient to probe[5](a2;a3). this residual game is therefore resilient to the application of p to a2;a3, for any nesting up to level 5, suggesting it is reasonably complex to solve in general. 7 future work and conclusions in future work, we mean to address the identified implementation issues and extend the query language with some features that our use of the tool revealed as being desired. the identification of further preprocessors and their implementation are also planned. in the medium term, we mean to implement plain-vanilla versions of the most prominent solvers so that we can begin with evaluating them on generated benchmarks. hopefully this will allow us to assess the utility of specific preprocessors for generating benchmarks. we also mean to create a database that proc. avocs 2009 12 / 15 eceasst figure 6: specific 8-node games found using the query server. witness (a) is solved by probe[0](a2;a3) but not by probe[2](a3); witness (b) is solved by a2;a3 but not by a1;a2;a3; witness (c) is solved by a2;a3 or by l(a;2a3) but not by l(l(a2;a3)); witness (d) is resilient to probe[3](a3). 13 / 15 volume 23 (2009) workbench for preprocessors of parity games figure 7: a 64-node game with 320 edges. its sub-game of grey nodes is resilient to probe[5](a2;a3). proc. avocs 2009 14 / 15 eceasst stores known worst-case games for specific solvers. we also mean to determine whether the workbench can be used to design and immediately test novel solvers. our workbench currently represents games explicitly. we mean to investigate how symbolic representations of games can be incorporated so that symbolic algorithms can be supported as well. at the more theoretical end, we mean to investigate whether our query language is presentable in a logic for which the synthesis problem is known to be decidable (this may not be straightforward due to the presence of counting primitives). the hardness of games under specific preprocessors may also be related to the descriptive complexities of such games. such connections between the expressiveness of fixed-point logics and descriptive set theory have been identified, e.g. in [bra03]. we summarize. in this paper we argued the utility of a workbench that can generate and store parity games with two ends in mind: to aid in the design, validation, and evaluation of preprocessors for parity game solvers; and to aid in the generation of benchmark parity games that are meaningful for a wide range of solvers. we sketched a framework that supports easy composition of preprocessors, offers a query language on a database of games for generating games of interest, and supports scalable query evaluation. a prototype implementation of this framework has been described and example interactions with that workbench were provided to demonstrate its potential in relation to the aforementioned two ends. acknowledgements: this research was, in part, supported by the uk epsrc project “complete and efficient checks for branching-time abstractions”(ep/e028985/1). bibliography [ach09] a. antonik, n. charlton, m. huth. polynomial-time under-approximation of winning regions in parity games. electronic notes in theoretical computer science 225:115–139, january 2009. [bra03] j. c. bradfield. fixpoints, games and the difference hierarchy. ita 37(1):1–15, 2003. [cjh04] k. chatterjee, m. jurdzinski, t. a. henzinger. quantitative stochastic parity games. in proc. of soda’04. pp. 121–130. 2004. [fl09] o. friedmann, m. lange. solving parity games in practice. in proc. of atva’09. springer, 2009. to appear. [jpz08] m. jurdzinski, m. paterson, u. zwick. a deterministic subexponential algorithm for solving parity games. siam j. comput. 38(4):1519–1532, 2008. [jur98] m. jurdzinski. deciding the winner in parity games is in up ∩ co-up. inf. process. lett. 68(3):119–124, 1998. [ms95] d. e. muller, p. e. schupp. simulating alternating tree automata by nondeterministic automata: new results and new proofs of the theorems of rabin, mcnaughton and safra. theor. comput. sci. 141(1&2):69–107, 1995. [pr89] a. pnueli, r. rosner. on the synthesis of a reactive module. in proc. of popl’89. 1989. [sti95] c. stirling. lokal model checking games. in proc. of concur’95. pp. 1–11. springer, 1995. [wan07] h. wang. framework for under-approximating solutions of parity games in polynomial time. master’s thesis, department of computing, imperial college london, june 2007. [zie98] w. zielonka. infinite games on finitely coloured graphs with applications to automata on infinite trees. theor. comput. sci. 200(1-2):135–183, 1998. 15 / 15 volume 23 (2009) introduction algebra of preprocessors database of games implementation discussion using the workbench future work and conclusions electronic communications of the easst volume 34 (2010) proceedings of the 6th educators’ symposium: software modeling in education at models 2010 (edusymp 2010) teaching ocl standard library: first part of an ocl 2.x course joanna chimiak–opoka, birgit demuth 13 pages guest editors: peter j. clarke, martina seidl managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 eceasst teaching ocl standard library: first part of an ocl 2.x course joanna chimiak–opoka1, birgit demuth2 1 university of innsbruck, austria, joanna.opoka@uibk.ac.at 2 technische universität dresden, germany, birgit.demuth@tu-dresden.de abstract: our aim is to provide a complete set of materials to teach ocl. they can be used in bachelor or master programs of computer science curricula and for training in an industrial context. in this paper we present the first part of the course related to the ocl standard library. this part provides model independent examples to teach ocl types and their operations. it enables users to gain a basic understanding of the ocl standard library, which can be used as a starting point to write model constraints (ocl specifications) or model queries. additionally, to the content of the paper, we provide a set of ocl packages, exercise proposals and lecture slides. keywords: teaching material, ocl types, model independent ocl expressions 1 introduction the object constraint language (ocl) is crucial in precise modeling [wk03]. despite its usability it is far less frequently used in the industrial context [amb04] than the unified modeling language. we consider three main reasons for this fact: weakness of standardisation, basic tool support, and lack of social acceptance. the ocl standard, also the recent 2.2 version [omg10], has several known inconsistency and incompleteness issues, as discussed in the recent ocl workshop [ccg+09]. a crucial problem is the discrepancy between the syntax and the semantics of the language specification. the provided syntax is for 2.2 version, but the semantic is based on [ric02] and was defined for 1.3 version. the attempt to partially bridge the gap in the formalisation of ocl 2.1 was proposed in [bkw09]. the inconsistencies in the standard cause difficulties in understanding and implementing ocl. fortunately, regardless of this fact there are many tools supporting ocl. currently there is a collection of ocl tools and uml tools with ocl support1. developers of the tools struggle with weaknesses of the standard and have to introduce their own interpretation what leads to slight differences between implementations [gkb08]. overcoming weaknesses of the standard in the academic context resulted in putting correctness of the implementation in the main focus and neglecting a user friendly front–end. in the commercial context ocl is rather neglected and it seems to be only an add–on to modeling tools. to partially address pragmatics of ocl tools we proposed requirements for a user friendly integrated development environment for ocl [cdsr09]. 1 list of tools at ocl portal: http://st.inf.tu-dresden.de/oclportal/ ocl software, comparison of tools by jordi cabot: http://www.jordicabot.com/research/oclsurvey/index.html 1 / 13 volume 34 (2010) teaching ocl standard library the last issue, the social acceptance of ocl, results from the previous ones. there exists a belief that it is hard to use, learn and teach ocl. it has been shown, e.g. [ack01], that in general, it is a difficult, error–prone and time–consuming task for practitioners to define ocl expressions. moreover, ocl expressions are often unnecessarily hard to read [vj00], uml/ocl models may be difficult to understand and evolve, particularly when constraints containing complex or duplicate expressions are present [cwo07]. additionally, difficulties with teaching ocl were reported in [mr09]: introducing it to non software developers is almost impossible and the professional programmers usually do not like it: it looks like a programming language, but it is not; it has first order logic semantics, but it does not look like it. our aim is to support learning and teaching of ocl. based on our teaching experience we designed a complete ocl course material. the course consists of several parts introducing basic types and operations, model and meta model specifications, model constraints and queries. this paper presents the first part of the course with the basic concepts. it focuses on the ocl standard library teaching its types by model–independent ocl expressions, however it is required to define an empty model context. according to our knowledge, our course is the first resource focusing on the core of the ocl (section 6.2). in our opinion teaching the core of the language is important to its successful application in context of modeling and model transformation. understanding of model–independent ocl expressions and proficiency in writing them is a prerequisite of an efficient specification of model constraints or model queries. these skills enable focusing on the content instead of on the form of the ocl expressions when writing large specification in ocl, qvt2 or other extensions of ocl. a modular teaching approach should reduce the learning effort of newcomers to the language, as noticed in [azh08]. in the first line we assume the course to be used in the academic context in a computer science curricula. an initial version of the course was successfully taught at the university of innsbruck in model engineering course in the master program3. in dresden, ocl is one of the topics in a course about advanced software engineering and is planned as part of a future course about model–driven software engineering. the improved version of the course will be taught at the university of innsbruck and at tu dresden. in both cases, students have strong basic skills in object–oriented software development (analysis, design including design patterns and java programming). additionally, the course will be freely available to academic teachers, students, professional software developers and modelers with basic skills in object–oriented software development. we provide two variants of the ocl specifications: standard and extended one. the standard tu dresden variant is suitable for language purists and for easier tool interoperability as the following constraint shows: 1 c o n t e x t model i n v a d d r e a l r e a l : 3 l e t v 1 : r e a l = 1 . 0 i n l e t v 2 : r e a l = 1 . 0 i n 5 v 1 + v 2 = 2 . 0 it can be used with different tools, however due to inconsistencies in implementations we can only grant the proper usage with the tools we tested. the extended university of innsbruck variant incorporates libraries, tests and documentation comments [co09]. it is intended to make 2 qvt: query/view/transformation http://www.omg.org/spec/qvt/ 3 http://st.inf.tu-dresden.de/oclportal/ courses / academic courses / specifying constraints with ocl proc. edusymp 2010 2 / 13 eceasst learning ocl easier by enriching it with techniques used in programming such as the following analogous ocl test example shows: 1 m o d e l i n s t a n c e n o n e t e s t t a d d r e a l r e a l : 3 l e t v 1 : r e a l = 1 . 0 i n l e t v 2 : r e a l = 1 . 0 5 e x p e c t e d v 1 + v 2 = 2 . 0 teachers have to decide what variant is the most appropriate one in their didactic context. the remainder of the paper is structured as follows: section 2 provides basic concepts crucial for teaching ocl. sections 3–5 succesively introduce ocl types: special, primitive and composite ones. in section 6 we describe teaching resources of our course and list alternative ones. and finally, section 7 gives a conclusion and future work. 2 overview in this section we give remarks on ocl as a typed specification language with a hybrid nature. it is important to notice, that ocl is neither a typical programming language, a formal specification language, nor a modeling language. as mentioned in [mr09]: it looks like a programming language, but it is not. ocl may be confused with programming language because of its concrete textual syntax, object–oriented paradigm and navigation style notation. on the other hand, it follows the declarative paradigm, which makes it harder to understand and to debug. moreover, it has first order logic semantics, but it does not look like it [mr09]. it may make difficult to see the paradigm shift to the logic and lead to confusing ocl with a programming language. ocl is a modeling language as it is related to model engineering activities, but it is not a stand–alone language. ocl has a hybrid nature, i.e. expressions are defined on a underlying metamodel and evaluated for models (instances of the metamodel). for the purpose of this paper we will only consider the basic part of ocl, which is independent of any model. in fig. 1 we present basic types, omitting types related to modeling, such as model element, enumeration, unlimited natural, ocl message and ocl state. for didactic purposes we introduced several additional elements to the type hierarchy to make it easier to understand. the elements (type, primitivetype, oclspecialtype, compositetype) are defined as abstract and depicted in orange in fig. 1. please notice that they are not defined in the standard, at least not this way. furthermore, it is important to understand that ocl is a typed language. that means that types and operations must match when constructing complex ocl expressions. type conformance rules are defined for pairs of types. a conformance of two types means that type1 conforms to type2 if an instance of type1 can be substituted at each place where an instance of type2 is expected [wk03]. for example, boolean is a subtype of oclany and therefore conforms to oclany. this should be intuitively grasped by students with java programming experience. in the following sections we describe three type sub–hierarchies: ocl special types (section 3), primitive types (section 4) and composite types (section 5). examples and exercises for all described ocl types and issues are provided within our course material (section 6.1). 3 / 13 volume 34 (2010) teaching ocl standard library type oclspecialtype compositetypeprimitivetype oclany oclvoidoclinvalid invalid : oclinvalid null : oclvoid orderedset collection sequence stringrealboolean integer tuple bagset * 1 ´«instanceof´» ´«instanceof´» figure 1: hierarchy of basic types according to the ocl 2.2 standard specification. 3 ocl special types we consider three ocl special types: oclany (section 3.1), oclinvalid, and oclvoid (section 3.2). below we give definitions of each type and point out special characteristics of them. 3.1 oclany type oclany behaves as a supertype for all the types, except composite types. features of oclany are available on each object in all ocl expressions [omg10]. it is also important to stress that oclany is a supertype of all primitive types and ocl special types, but not of composite types. notice that some ocl parsers enable calling oclany’s operations on collection types but this is not standard conform. in principle oclany plays the role that object plays in the java language. thus oclany offers several reflection operations. for the oclany type comparison two operations are defined: = and <>. however, it is not really clear how equality (=) is defined. the ocl specification defines it by object identity (same object). some ocl tools indeed implement equality by equality of values [scc10]. furthermore, several checks for concrete types are defined: ocltype() returns the type of which self is an instance. oclistypeof(···) checks if self is of the given type (but not a subtype of it), ocliskindof(···) checks if the type of self conforms to the given type (self is of the given type or a subtype of it), oclisundefined() checks if the type of self is of type oclundefined (self is equal to null), and oclisinvalid() checks if the type of self is of type oclinvalid (self is equal to undefined).4 additionally, there is a method for type casting: oclastype(···). in ocl it is possible to specify static (or class) features (attributes and operations) that are similar in java or other object–oriented languages applicable to types themselves instead to their instances. regarding the type system of the standard library there is only one static operation: allinstances(). this operation results in a set of all instances of that type, including all instances of its subtypes. however, the use of allinstances() is explicitly discouraged because it is difficult to find all instances of a type. in the ocl standard library type hierarchy allinstances() can only 4 there are two additional checks oclisnew(), oclisinstate() but they are related to model elements. proc. edusymp 2010 4 / 13 eceasst be applied for the enumeration types boolean, oclinvalid and oclvoid. as oclany is an abstract type, it can be used in a declaration (variable, operation parameters and return type) but there are no direct instances of it. to teach operations defined in oclany values of concrete types must be used. 3.2 oclvoid and oclinvalid types the type oclvoid is a type that conforms to all other types except oclinvalid. it has one single instance, identified as null. similarly, the type oclinvalid is a type that conforms to all other types except oclvoid. it has one single instance, identified as invalid. any property call applied on null or invalid results in oclinvalid except for the operation oclisundefined() and oclisinvalid() [omg10]. the semantics of both types is not yet completely specified in the current ocl specification and can be seen as problematic because that means that they conform to one another, resulting in a generalization cycle. conceptually, there are still some issues to be solved for the next ocl 2.3 specification.5 for basic understanding of these concepts it is useful to make a programming language metaphor5. null in ocl can be understood similarly to null in java. operation invocations on null values or operation invocations having null values as parameters result in invalid. this situation can be compared with exceptions in java (nullpointerexception).6 there are several special cases when dealing with null and invalid. basically, handling of null and invalid in logical operations results in a four–valued logic (section 4.1). it is important to make students aware of being careful when working with undefined and invalid values. • conversion to a collection type from null leads to an empty collection. • collections may contain null values but not invalid values. if a collection contains an invalid value it is invalid as a whole. • the specification does not specify how to deal with comparison operations: equality and non–equality. however, for practical reasons, it should be possible to apply them on null and invalid values. • invocation of oclisundefined() on invalid results in false and in particular cases it can lead to false conclusions. e.g. 10.div(0).oclisundefined() evaluates to true although the result is not null but invalid instead. • handling of null and invalid in logical operations results in a four–valued logic (section 4.1). as oclvoid and oclinvalid conform to oclany, both types inherit all operations from oclany (section 3.1). the only specific operations are operations that redefine the oclany type comparison operation (=) for oclvoid and oclinvalid. 5 a discussion on treatment of ocl undefined and ocl invalid at the ocl group at linkedin provides insights on the practical solution used in dresden ocl (claas wilke) and omg ocl 2.2 revisions (ed willink). 6 thus, invalid can be considered as some sort of exception or throwable. unfortunately, invalid in ocl is not typed, and thus, it is not possible to find out what went wrong nor catch specific subtypes of exceptions — from the discussion on treatment ... 5 / 13 volume 34 (2010) teaching ocl standard library 4 primitive types in this section we describe how to deal with primitive types in ocl: boolean, real, integer and string. in this part there are a few issues to be careful about, especially four–valued logic (section 4.1) and a weak support of advanced arithmetical (section 4.2) and text operations (section 4.3). in section 4.4 we show how to overcome weaknesses of ocl. 4.1 boolean values and logical operations basically ocl users work with the boolean values true and false that are the instances of the boolean type. for these standard boolean values boolean algebra and de morgan’s laws are applied. additionally we have to, as explained in section 3.2, handle two special oclany values (null and invalid) in logical operations resulting in a four–valued logic (4vl). as the boolean algebra is a logical calculus of truth tables, the ocl specific 4vl is also represented in a truth table (tab. 1). logical operations can be written both using operators by reserved keywords (such as a and b) and by infix operators (such as a.and(b)). ocl provides the basic logical operations and, or, not as well as the derived operations xor and implies. conflicting reserved keywords and property names can be solved by using the (underscore) prefix. for future ocl specifications it is proposed that the above mentioned example is written as a. ’and’(b). table 1: a truth table for the four–valued logic in ocl. note that the truth table in the current standard [omg10] contains errors which will be removed in the next ocl version (2.3). the presented truth table is the already updated one. a b not a a or b a and b a implies b a xor b false false true false false true false false true true true false true true false null true invalid false true invalid false invalid true invalid false true invalid true false false true false false true true true false true true true false true null false true invalid invalid invalid true invalid false true invalid invalid invalid null false invalid invalid false invalid invalid null true invalid true invalid invalid invalid null null invalid invalid invalid invalid invalid null invalid invalid invalid invalid invalid invalid invalid false invalid invalid false invalid invalid invalid true invalid true invalid invalid invalid invalid null invalid invalid invalid invalid invalid invalid invalid invalid invalid invalid invalid invalid proc. edusymp 2010 6 / 13 eceasst 4.2 numbers and arithmetical operations there are two types to express numbers in ocl: real and integer, where integer is a subtype of real. the basic arithmetical (+, −, /, ∗, abs(), min(···), max(···)) and comparison operations (>, <, >=, <=) are defined for numbers. two types of conversion from real to integer are provided (floor(), round()) and additionally, in ocl 2.2, a conversion to string was introduced (tostring()). there are two operations defined for the integer type only: integer division (div(···)) and modulo (mod(···)). 4.3 strings and text operations text operations, especially string comparison, are a weakness of ocl. the latest ocl specification [omg10] provides several new operations on strings. in ocl 2.2, it is possible to access single or all characters of a given string: at(···) which queries the character at given position and characters() which obtains the characters of the string as a sequence. additionally, to case conversion (tolowercase(), touppercase()) an explicit operation to compare strings under case–insensitive collation was introduced: equalsignorecase(···). another useful operation is indexof(···) which queries the index in self at which a given substring occurs in a string or zero if the substring does not occurs in the string. it can be used as a check if a given substring occurs in a string. 4.4 extensions additionally, to the standard library we show two mechanisms for extending expressiveness of ocl: one within ocl (definition mechanism) and another outside of ocl (black box implementations). the black box implementations are used in qvt to allow complex algorithms to be coded in any programming language. additional definitions can be used for advanced text operations and complex arithmetical algorithms, whereas back box extensions for regular expressions. 5 composite types in this section, we motivate and explain the introduced abstract composite type with the subtypes for collections and tuples (fig. 1). tuples and all collections are composite because they contain elements conform to any concrete subtype of the root type type. the term element is used for an object in a collection. the type type of the elements are designated in the ocl specification as template type ’t’ in all collection operations. the elements in a tuple are understood as attributes of the tuple each attribute consisting of a name and a type. students should be made aware that this type hierarchy is designed based on the composite design pattern. although the type hierarchy in the ocl specification is not exactly defined as in this paper we found this representation from a conceptual and didactic point of view more comprehensible. note that the ocl specification uses the term part to explain what a tuple is. but we prefer for orthogonal notions the term element to motivate the composite pattern. 7 / 13 volume 34 (2010) teaching ocl standard library 5.1 collection types ocl collection types can be explained based on the multiplicityelement from the uml specification [omg09]. besides the definition of the bounds of an actual multiplicity the multiplicityelement also includes specifications of whether the values in a instantiation of this element must be unique or ordered. if the upper bound of the specified interval of a multiplicity is greater than one we have an association end that results in a collection. the uml specification defines based on the boolean properties isunique (default value = true) as well as isordered (default value = false) of a multiplicityelement different kinds of a collection (set, bag, sequence, and orderedset). collection types in ocl are the same and therewith their definitions conform to the uml specification. tab. 2 shows the mapping of the properties to the collection types. a discussion on the collection types hierarchy may be found in [bgh+09]. table 2: classification of collection types based on their properties. properties isordered not isordered isunique orderedset set not isunique sequence bag during a course it should be explained that there are two kinds of operations for each collection type: (basic) operations (e.g. size()) and predefined iterator expressions (e.g. forall(···)). in [wk03] basic operations are classified by their meaning basically into following groups: • equals(=) / notequals (<>) operations, • including / excluding operations, • the flatten() operation, • transformation operations (asset(), assequence(), asbag(), asorderedset()), • typical set operations (union(···), intersection(···), difference (−), symmetricdifference(···)), • order related operations (first(), last(), at(···), indexof(···), insertat(···), subsequence(···), suborderedset(···), append(···), prepend(···), reverse()). for better comprehension we recommend presenting a matrix of operations with their signatures and owning types. due to space limitations, we refer to our teaching materials (section 6.1). a sensible issue is the difference between includes() and including() as well as excludes() and excluding(). it should be carefully explained on their signatures and examples. the including operation results in a new collection with one element added to the original collection [wk03]. the include operation results in true if the parameter object is an element in the collection. another issue is the incompleteness of the list of all collection operations7. in particular it is generally recognized that some of the above listed collection operations are missing for the orderedset type in the ocl 2.2 specification. iterator expressions loop over the elements in a collection and have an ocl expression as parameter. because iterator expressions are complex to write, often recurring iterator expressions are predefined (exists(···), forall(···), isunique(···), any(···), one(···), collect(···), 7 see the omg ocl discussion mailing list at http://www.omg.org/issues/ocl2-rtf proc. edusymp 2010 8 / 13 eceasst collectnested(···), sortedby(···), select(···), reject(···)). basically it is possible to add new iterator expressions in the ocl standard library. students should study the mapping of the predefined iterator expressions to the iterate construct and learn by a few examples to write iterator expressions themselves. 5.2 tuples the tupletype (informally known as record type or struct) combines different types into a single aggregate type. as explained above, the elements of a tupletype are described by its attributes each having a name and a type. the type names are optional, and the order of the elements is unimportant. according to the composite pattern there is no restriction on the kind of types that can be used as elements of a tuple. each element is uniquely identified by its name. it is possible to compose several values into a tuple. a tuple consists of named parts, each of which can have a distinct type. the values of the parts may be given by arbitrary ocl expressions. the tuple type is crucial for the power of ocl as a query language. before introducing this type, ocl (1.x) was not equivalent to the relational calculus [mc99]. however, there are no additional operations defined for the tuple type. the elements are accessed by their names and the ocl dot notation. it is very important to teach how to deal with single tuples and collections of tuples. 6 teaching resources in this section we provide information about resources we provide for the afore described course (section 6.1) and we compare it with other available resources for teaching ocl (section 6.2). 6.1 course on ocl standard library the course package8 contains lecture slides, source files with tasks for students and ocl expressions tested with the squam ocl editor and dresden ocl. lecture slides provide an extended version of diagrams for all types, their definitions and issues to be careful about. the slides, with the project and the set of ocl expressions, can be used as self–learning material. the project consists of 16 packages with over 250 ocl expressions. in the basic part, expressions correspond to particular ocl types (fig. 1 in section 2). the advanced part consists of explicit definitions of predefined iterator expressions (section 5.1) and complex method definitions for numbers and strings (section 4.4). there are, in total, over 100 exercises to test or extend existing ocl expressions or to write new one. the source files are provided in two variants: standard and extended [co09]. the overview of available versions in given in tab. 3. please note that there are unfortunately differences in the semantics how different tools evaluates ocl expressions. a benchmark provided in [gkb08] is dedicated for an older ocl specification. it points out important issues, however the ocl specific 4vl with the invalid value is not considered there. when teaching and learning ocl, 8 http://squam.info/ocleditor/doc/oclcourse/ 9 / 13 volume 34 (2010) teaching ocl standard library figure 2: a screen–shot from the squam ocl editor with ocl course resources. at the left side: the project’s structure in the project explorer can be seen. at the top–right side: project statistics with number of elements and lines of code. at the bottom–right side: exercises for students denoted in the ocl files with ’– todo task: ...’ and navigable from the task view. teachers and students should be aware of differences between standard specification and its implementations. table 3: overview of ocl resources with corresponding ocl versions and tool configurations. version variant ocl editor ocl parser ocl 2.0 extended squam ocl editor galileo eclipse mdt/ocl ocl 2.1 extended squam ocl editor helios eclipse mdt/ocl ocl 2.2 standard dresden ocl 2.2 editor dresden ocl 2.2 parser tool webpage dresden ocl http://dresden-ocl.sourceforge.net/ squam ocl editor http://squam.info/ocleditor/ eclipse mdt/ocl http://wiki.eclipse.org/mdt/ocl 6.2 alternative examples as far as we know, our course is the only one focusing on model–independent expressions and covering the semantics and newest methods introduced in ocl 2.2. however, there are other valuable teaching resources we would like to mention here. the well–known and most extensively used example in ocl teaching is the ”royal and loyal” system example introduced and used in ocl text books as in [wk03]. the example provides an extensive set of model–dependent ocl expressions for earlier versions of ocl (up to 2.0). ocl expressions for this example are provided with several tools, among others with proc. edusymp 2010 10 / 13 eceasst dresden ocl9, eclipse mdt/ocl10, and itp/ocl11. several ocl courses (scripts, slides, ocl expressions) are available from the ocl portal12. they are provided by the following teachers (tools): heinrich humann, birgit demuth, jurriaan hage (dresden ocl), lothar schmitz (use), and joanna chimiak–opoka (ocle). additionally, further examples of ocl expressions are provided by martin gogolla together with use13 and as teaching materials14 including uml and ocl in conceptual modeling15 and exercises for teaching ocl constraints16. uml tools which support ocl typically also provide ocl examples for documentation or evaluation such as papyrus17. screencasts and videos can also be helpful to learn how to use ocl in a development environment. magicdraw uml18 and borland together19 provide such online tutorials. for further references, we will constantly update the list of ocl software and tutorials at the ocl portal. at the same time we are looking for support of the ocl community to add their knowledge to the portal. besides uml model examples, students can study ocl usage for models based on other metamodels than uml, such as the java metamodel, xsd (xml schema), and emf ecore20. 7 conclusion teaching ocl is a challenging task because of an imprecise and incomplete standard specification [omg10]. this fact has, over the years, caused confusion about the nature of ocl and differences in its semantics and implementations. as a result there is a resistance to teaching and to learning this language. our intention was to help to overcome this resistance by providing a solid course on the core part of ocl. we provided instructions for teachers and learning materials which include ocl expressions tested with ocl tools developed at our universities. the course presented in this paper is the first part of a larger ocl course we plan to provide. it will be integrated into and distributed with our ocl tools to give users a comprehensive example set of them. the second part of the planned ocl course will present examples how to specify business rules by ocl constraints on the model layer. ocl constraints for the specification of well–formed rules on the metamodel layer as well as model queries will be subject of the third part of the planned course. additionally, we plan to adapt ocl expressions to be usable as a benchmark extending [gkb08] with new methods introduced in ocl 2.2 and the four–valued logic. 9 http://dresden-ocl.sourceforge.net/4eclipse usage.html 10 http://wiki.eclipse.org/mdt/ocl/faq 11 http://maude.sip.ucm.es/itp/ocl/examples.html 12 http://st.inf.tu-dresden.de/oclportal/ courses 13 http://www.db.informatik.uni-bremen.de/projects/use/use-documentation.pdf 14 http://www.db.informatik.uni-bremen.de/teaching/courses/ss2010 eis/ 15 http://www.db.informatik.uni-bremen.de/teaching/courses/ss2010 eis/bookconceptualmodelling.pdf 16 http://www.iem.pw.edu.pl/edusymp08/m.gogolla ocl.pdf 17 http://www.papyrusuml.org 18 http://www.magicdraw.com/files/viewlets/md viewlets validation viewlet swf.html 19 http://www.borland.com/de/products/together/ 20 http://dresden-ocl.svn.sourceforge.net/viewvc/dresden-ocl/trunk/ocl20foreclipse/doc/pdf/manual.pdf, p. 112 11 / 13 volume 34 (2010) teaching ocl standard library acknowledgements: the research herein is partially conducted within the competence network softnet austria (www.soft-net.at) and funded by the austrian federal ministry of economics (bm:wa), the province of styria, the steirische wirtschaftsfoerderungsgesellschaft mbh. (sfg), and the city of vienna in terms of the center for innovation and technology (zit). we would like to thank our colleagues for their support in conceptual and technical aspects of our teaching project, especially colin atkinson, hannes mösl, claas wilke, and kevin church. bibliography [ack01] j. ackermann. fallstudie zur spezifikation von fachkomponenten. in turowski (ed.), 2. workshop modellierung und spezifikation von fachkomponenten. pp. 1–66. bamberg, deutschland, 2001. (in german). [amb04] s. ambler. the object primer third edition agile model-driven development with uml 2.0. cambridge, cambridge, uk, 2004. [azh08] d. akehurst, s. zschaler, g. howells. ocl: modularising the language. in proceedings of the workshop ocl4all: workshop at models 2007. volume 9. electronic communications of the easst, 2008. http://www.easst.org/eceasst [bgh+09] f. büttner, m. gogolla, l. hamann, m. kuhlmann, a. lindow. on better understanding ocl collections or an ocl ordered set is not an ocl set. pp. 276–290 in [gho10]. [bkw09] a. d. brucker, m. p. krieger, b. wolff. extending ocl with null-references. pp. 261–275 in [gho10]. [ccg+09] j. cabot, j. chimiak-opoka, m. gogolla, f. jouault, a. knapp. ninth international workshop on the pragmatics of ocl and other textual specification languages. pp. 256–260 in [gho10]. [cdsr09] j. chimiak-opoka, b. demuth, d. silingas, n. f. rouquette. requirements analysis for an integrated ocl development environment. electronic communications of the easst: the pragmatics of ocl and other textual specification languages 2009 24, 2009. (presented at ocl workshop). [co09] j. chimiak-opoka. ocllib, oclunit, ocldoc: pragmatic extensions for the object constraint language. in schuerr and selic (eds.), model driven engineering languages and systems, 12th international conference, models 2009, denver, colorado, usa, october 4-9, 2009, proceedings. lncs 5795. pp. 665–669. springer verlag, 2009. (slides). [cwo07] a. l. correa, c. werner, m. de oliveira barros. an empirical study of the impact of ocl smells and refactorings on the understandability of ocl specifications. in proc. edusymp 2010 12 / 13 eceasst engels et al. (eds.), models. lecture notes in computer science 4735, pp. 76–90. springer, 2007. [gho10] s. ghosh (ed.). models in software engineering, workshops and symposia at models 2009, denver, co, usa, october 4-9, 2009, reports and revised selected papers. lecture notes in computer science 6002. springer, 2010. [gkb08] m. gogolla, m. kuhlmann, f. büttner. a benchmark for ocl engine accuracy, determinateness, and efficiency. in models ’08: proceedings of the 11th international conference on model driven engineering languages and systems. pp. 446– 459. springer-verlag, berlin, heidelberg, 2008. [mc99] l. mandel, m. v. cengarle. on the expressive power of ocl. in wing et al. (eds.), world congress on formal methods. lecture notes in computer science 1708, pp. 854–874. springer, 1999. [mr09] s. moisan, j.-p. rigault. teaching object–oriented modeling and uml to various audiences. pp. 40–54 in [gho10]. [omg09] omg. omg unified modeling languagetm (omg uml), superstructure. version 2.2. february 2009. http://www.omg.org/spec/uml/2.2/superstructure/pdf. [omg10] omg. object constraint language. omg available specification. version 2.2. feb. 2010. [ric02] m. richters. a precise approach to validating uml models and ocl constraints. phd thesis, universität bremen, 2002. biss monographs no. 14. [scc10] a. sterritt, s. clarke, v. cahill. precise specification of design pattern structure and behaviour. in kuehne et al. (eds.), modelling foundations and applications, 6th european conference, ecmfa 2010. lncs 6138. springer, 2010. [vj00] m. vaziri, d. jackson. some shortcomings of ocl, the object constraint language of uml. in li et al. (eds.), tools (34). pp. 555–562. ieee computer society, december 2000. http://dblp.uni-trier.de/db/conf/tools/tools34-2000.html#vazirij00. [wk03] j. warmer, a. kleppe. the object constraint language: getting your models ready for mda, second edition. addison-wesley, 2003. 13 / 13 volume 34 (2010) electronic communications of the easst volume 2 (2006) proceedings of the workshop on petri nets and graph transformation (pngt 2006) petri nets and matrix graph grammars: reachability. pedro pablo pérez velasco, juan de lara 16 pages guest editors: paolo baldan, hartmut ehrig, julia padberg, grzegorz rozenberg managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/� eceasst petri nets and matrix graph grammars: reachability. pedro pablo pérez velasco1, juan de lara1 1 (pedro.perez, jdelara)@uam.es escuela politécnica superior universidad autónoma de madrid (spain) abstract: this paper attempts to contribute in two directions. first, concepts and results of our matrix graph grammars approach [vl06b, vl06a] such as coherence and minimal initial digraph are applied to petri nets, especially to reachability criteria and to the state equation. second, the state equation and related petri nets techniques for reachability are generalized to cover a wider class of graph grammars. keywords: graph transformation, petri nets, reachability, boolean matrix algebra. 1 introduction in this paper analysis techniques from matrix graph grammars (mggs) [vl06a, vl06b] are applied to petri nets [mur89] and vice-versa. in mggs, simple digraphs are represented using a boolean matrix for edges and a boolean vector for nodes. rules are also represented with matrices and vectors, specifying the left hand side graph together with the elements that should be added and removed. therefore graph rewriting can be represented using boolean operations only. we have developed some analysis techniques for mggs, for example, to check whether a sequence of productions is applicable a priory (assuming a certain identification of nodes and edges between the rules), which we call coherence; to find if a permutation of a coherent sequence remains coherent; to verify if two sequence permutations yield the same result; or to calculate the minimal graph necessary in order to be able to apply a sequence (called minimal initial digraph). the main motivation of this work is to take advantage of the similar basis of mgg and the algebraic view of petri nets. in the first part of the work, some of the mgg concepts we have developed are applied to petri nets. in particular it is possible to investigate for example which is the minimum marking that enables the firing of a certain transition sequence, and express the reachability problem in mgg terms (using coherence and the minimal initial digraph). on the other hand, by using tensor algebra the state equation of petri nets has been extended for graph grammars (i.e. by replacing the incidence matrix by an incidence tensor). both the cases of dpo-like and spo-like graph grammars have been considered. the paper is organized as follows. section 2 gives a brief introduction to mggs. section 3 introduces some algebraic analysis techniques for petri nets, in particular the state equation. in this section we discuss why the equation gives a necessary (but not sufficient) condition for reachability. section 4 applies mgg techniques to the analysis of petri nets. section 5 extends the state equation for dpo-like graph grammars. section 6 deals with the case of spo-like graph 1 / 16 volume 2 (2006) mailto:(pedro.perez, jdelara)@uam.es� matrix grammars grammars. section 7 compares with related work, and finally section 8 ends with the conclusions and future work. 2 matrix graph grammars in this section we review the mgg concepts which are relevant to petri nets reachability results. for an extensive presentation, the reader is referred to [vl06a, vl06b]. the proof of the theorems can be found in [vl06b]. in our approach, we work with simple digraphs, which can be represented as a tuple (m, n) with m a boolean matrix for edges and n a boolean vector for nodes. the latter is necessary as in the rewriting nodes can be added and deleted. figure 1(a) shows an example of a graph representing a network of three clients and a server, where messages are depicted as self-loops. note how we can check for well-formedness of graphs (i.e. no dangling edges) by verifying that∥∥(m ∨mt )¯n ∥∥ 1 = 0, where ¯ is the boolean matrix product (like the regular matrix product, but with and and or instead of mutiplication and addition), and ‖·‖1 being an operation that results in the or of all the components of the vector. we call this property compatibility. (a) (b) figure 1: (a) simple digraph example. (b) “localsend” rule. in our framework we can assign a type to each node by a function from the set of nodes v to a set of types t , type : v → t . in figure 1(a), types are represented as an additional column in the matrices. for edges we use the types of their source and target nodes. a production, or grammar rule, p : l → r is a partial injective morphism of simple digraphs. using a static formulation, we can represent a rule by two boolean matrices and two vectors p = ( le , re ; ln , rn ) , (where e stands for edges and n for nodes) to characterize the left and right hand side simple digraphs (lhs and rhs). production p is the morphism which identifies nodes (resp., edges) on the lhs with nodes (resp., edges) on the rhs. the main actions that can be performed by a rule are deletion and addition of elements. therefore using a dynamic formulation a rule can be represented by p = ( (le , ln ); ee , re ; en , rn ) , where ee and en are the deletion boolean matrix and vector, while re and rn are the addition boolean matrix and vector. the output of rule p can be calculated by r = r ∨ e l, where the formula applies both to nodes and edges. superindices e and n shall be omitted if the formula applies to both cases. moreover, we usually omit the ∧ (and) symbol. figure 1(b) shows a rule and its associated matrices. in order to operate graphs of different sizes, an operation called completion adds extra rows proc. pngt 2006 2 / 16 eceasst and columns with zero elements and rearranges rows and columns so that the identified edges and nodes of the two graphs match. given a collection of productions {p1, . . . , pn}, the notation sn = pn; pn−1; . . . ; p1 defines a sequence of productions establishing an order in their application, starting with p1 and ending with pn. note that we may have the same production in different places of the sequence. a concatenation is said to be coherent if actions carried out by one production do not prevent the application of those coming afterwards. note that we assume a certain identification of nodes and edges between productions (i.e., the matrices have been completed in some way, which assumes an overlapping of the rules in the matching in the host graph). therefore, coherence is calculated with respect to the given identification. theorem 1 (sequence coherence) the sequence sn = pn; . . . ; p1 is coherent if n∨ i=1 ( ri 5ni+1 (ex ry)∨li 4i−11 (ey rx) ) = 0 (1) where 4t1t0 (f(x, y)) = t1∨ y=t0 ( t1∧ x=y (f(x, y)) ) ;5t1t0 (g(x, y)) = t1∨ y=t0 ( y∧ x=t0 (g(x, y)) ) coherence allows the grammar designer to check dependencies between rules, and to realize possible conflicts, some of which can be solved if the initial host graph provides enough edges and nodes. this is related to the notion of minimal initial digraph, which is a graph containing the necessary nodes and edges for a sequence to be applicable. theorem 2 (minimal initial digraph) for a coherent concatenation of productions sn = pn; . . . ; p1, its minimal initial digraph is given by the equation mn = 5n1 (rxly) (2) as in previous theorem, assume we have the coherent concatenation sn with minimal initial digraph mn, then its image is given by: sn (mn) = n∧ i=1 (eimn)∨4n1 (ex ry) (3) see [vl06b] for a proof. to continue our analysis of finite sequences of productions, another useful operation is composition [vl06b]. the main difference between concatenation and composition is the generation of intermediate states in the former. if a concatenation is coherent, then its composition can be defined. next, we state the conditions under which a permutation of a coherent sequence remains coherent. in particular, we focus on advancement of the last production to the front and vice-versa. theorem 3 (production advance and delay) consider coherent sequences tn = pα ; pn; pn−1; . . . ; p2; p1 and sn = pn; pn−1; . . . ; p2; p1; pβ and permutations φn and δn. 3 / 16 volume 2 (2006) matrix grammars 1. φn+1 (tn) is coherent if: eeα 5n1 ( rex l e y ) ∨reα 5n1 ( eex r e y ) = 0 2. δn+1 (sn) is coherent if: leβ 4n1 ( rex e e y ) ∨reβ 4n1 ( eex r e y ) = 0 where φn advances (i.e. moves to the right inside the concatenation) one production n − 1 positions, i.e., has associated permutation φn = [ 1 n n − 1 . . . 3 2 ]. this is a notation for permutation cycles that means that rule 1 (the left-most one) is sent to position n, then rule in position n is moved to position n − 1, and similarly until rule 3, which is moved to position 2, and this one to position 1. operator δn delays one production n − 1 positions, i.e., has δn = [ 1 2 . . . n−1 n ] as associated permutation cycle (i.e. each rule is moved to the right, and rule n to position 1). g-congruence guarantees that two coherent concatenations have the same minimal initial digraph g. the conditions to be fulfilled are known in [vl06b] as congruence conditions (cc). the key point is that a coherent concatenation sn and a coherent permutation of it, σ (sn), which besides have the same minimal initial digraph g (i.e., which are g-congruent) are sequential independent. next theorem present the congruence conditions for advancement and delay of productions. theorem 4 (g-congruence) given sequence sn, the congruence conditions for rule advance (φn−1) and delay (δn−1) are given by: ccn (φn−1, sn) = ln∇n−11 (ex ry)∨rn∇n−11 (rx ly) = 0 (4) ccn (δn−1, sn) = l1∇n2 (ex ry)∨r1∇n2 (rx ly) = 0 (5) 3 algebraic techniques for petri nets: the state equation algebraic techniques for petri nets are based on the representation of the net with an incidence matrix a in which columns are transitions (element aij is the number of tokens that transition i removes – negative – or adds – positive – to place j). one of the problems that can be analyzed using algebraic techniques is reachability. given an initial marking m0 and a final marking md , a necessary condition to reach md from m0 is to find a solution x for the equation md = m0 + ax, which can be rewritten as a linear system m = ax (6) solution x – known as parikh vector – specifies the number of times that each transition should be fired, but not the firing order. identity (6) is known as the state equation [mur89]. the state equation introduces a matrix, which conceptually can be thought of as associating a vector space to the dynamic behaviour of the petri net. it is interesting to graphically interpret the operations involved in linear combinations: addition and multiplication by scalars, as depicted in figure 2. the addition of two transitions is again a transition tk = ti + t j for which input places are the addition of input places of every transition and the same for output places. if a place proc. pngt 2006 4 / 16 eceasst appears as input and output place in tk, then it can be removed. multiplication by −1 inverts the transition, i.e., input places become output places and viceversa, which in some sense is equivalent to disapplying the transition. figure 2: linear combinations in the context of petri nets. one important issue is that of notation. linear algebra uses an additive notation (addition and substraction) which is normally employed when an abelian structure is under consideration. for non-commutative structures, such as permutation groups, the multiplicative notation (composition and inverses) is preferred. the basic operation with productions is the definition of sequences (concatenation), for which historically a multiplicative notation has been chosen, but substituting composition “◦” by the concatenation “;” operation.1 from a conceptual point of view, we are interested in relating linear combinations and sequences of productions.2 note that, due to commutativity, linear combinations do not have an associated notion of ordering, e.g., linear combination pv1 = p1 + 2 p2 + p3 coming from parikh vector [1, 2, 1] can for example represent sequences p1; p2; p3; p2 or p2; p2; p3; p1, which can be quite different. the fundamental concept that deals with commutativity is precisely sequential independence. following this reasoning, we can find the problem that makes the state equation a necessary but not a sufficient condition: some transition can temporarily owe some tokens to the net. the parikh vector specifies a linear combination of transitions and thus, negatives are temporarily allowed (substraction). proposition 1 suffiency of the state equation can only be ruined by transitions firing without being enabled (i.e., temporarily borrowing tokens from the petri net). this proposition does not provide any criteria based on the topology of the petri net, as theorems 16, 17, 18 and corollaries 2 and 3 in [mur89], but contains the essential idea in their proofs: the hypothesis in previously mentioned theorems guarantee that cycles in the petri net will not 1 this is the reason why [vl06b] introduces “;” to be read from right to left, contrary to the literature. composition “◦” has the effect of simultaneous application, which is different to sequential application. this is important for example to differentiate sequential and parallel application. 2 linear combinations are the building blocks of vector spaces, and the structure to be kept by matrix application. 5 / 16 volume 2 (2006) matrix grammars ruin coherence. 4 using matrix graph grammars techniques for petri nets given a petri net, we shall consider it as the initial host graph in our matrix graph grammar. one production is associated to every transition in which places and tokens are nodes and there is an arrow joining each token to its place. in fact, we represent places for illustrative purposes only, as they are not strictly necessary, including tokens alone is enough. figure 3 shows an example in which each production corresponds to a transition. the firing of a transition corresponds to the application of a rule. figure 3: petri net with related production set. thus, petri nets can be considered a proper subset of graph grammars with two important properties: 1. there are no dangling edges when applying productions (firing transitions). 2. every production can be applied only in one part of the host graph. properties (1) and (2) somehow allow us to safely “ignore” matchings as introduced in [vl06a]. in addition, we consider petri nets with no self-loops (i.e., so called pure petri nets), that is, one production either adds or deletes nodes of a concrete type, but there is never a simultaneous addition and deletion of nodes of the same type. this agrees with the expected behaviour of mgg productions with respect to nodes (which is the behaviour of edges as well, see [vl06b]) and will be kept throughout the present work, mainly because rules in spo-like grammars are adapted depending on whether a given production deletes nodes or not (refer to section 6). hence, it is necessary that elements in matrices are not relative integers, i.e., a number four must mean that production x adds four nodes of type t and not that x adds four nodes more than it deletes of type t. if we had one such production p, a possible way to proceed is to split p into two, one owning the addition actions, pr, and the other the deletion ones, pe. sequentially, p should be decomposed as p = pr; pe. proc. pngt 2006 6 / 16 eceasst minimal marking. the concept of minimal initial digraph can be used to find the minimum marking able to fire a given transition sequence. for example, figure 4 shows the calculation of the minimal marking able to fire transition sequence t5; t3; t1 (from right to left). notice that (r1l1)∨(r1l2)(r2l2)∨···∨(r1ln)···(rnln) is the expanded form of equation 2. figure 4: minimal marking firing sequence t5; t3; t1. reachability. the reachability problem can also be expressed using mgg concepts, as the following definition shows. definition 1 (reachability) given a grammar g = (m0,{p1, . . . , pn}), a state md is called reachable starting in state m0, if there exists a coherent concatenation made up of productions pi ∈ g with minimal initial digraph contained in m0 and image in md . 5 reachability: dpo-like matrix graph grammars in this and next sections we shall be concerned with the generalization of the state equation to wider types of grammars. by a dpo-like matrix graph grammar we understand a grammar as introduced in [vl06b], but in which rule applications do not generate dangling edges. that is, in any reachable graph from the initial one, no rule application can generate a dangling edge (i.e. the dangling condition in classical double pushout graph grammars [eept06] can be safely ignored as it can never happen). property 2 in section 4 of petri nets is relaxed because now a single production may eventually be applied in several different places of the host graph. however, following the discussion in previous section, we restrict to dpo rules in which nodes (or edges) of the same type are not rewritten (deleted and created) in the same rule. in order to perform an a priori analysis it is mandatory to get rid of matches. to this end, either an approach as proposed in [vl06a, vl06b] is followed (as we did in this paper in section 4), or types of nodes are taken into account instead of nodes themselves. here, we take this second alternative, therefore productions, initial state and final state are transformed such that types of elements are considered, obtaining matrices with elements in z. tensor notation [sok51] will be used in the rest of the paper to extend the state equation. 7 / 16 volume 2 (2006) matrix grammars though it shall be avoided whenever possible, four index may be used simultaneously, e0 a i j. top left index indicates whether we are working with nodes (n) or edges (e). bottom left index specifies the position inside a sequence, if any. top right and bottom right are contravariant and covariant indices, respectively. definition 2 let g = (0m,{p1, . . . , pn}) be a dpo-like graph grammar and m the number of different types of nodes in g. the incidence matrix for nodes na = ( aik ) where i ∈ {1, . . . , n} and k ∈ {1, . . . , m} is defined by the identity aik = { +r if production k adds r nodes of type i −r if production k deletes r nodes of type i (7) it is straightforward to deduce for nodes an equation similar to (6): n d m i = n0 m i + n ∑ k=1 naikx k (8) the case for edges is similar, with the peculiarity that edges are represented by matrices instead of vectors and thus the incidence matrix becomes the incidence tensor eaijk. again, only types of edges, and not edges themselves, are taken into account. two edges e1 and e2 are of the same type if their starting and final nodes are of the same type. initial nodes of edges will be assumed to have a contravariant behaviour (index on top, i) while terminal nodes (first index, j) and productions (second index, k) will behave covariantly (index on bottom). see diagram in the center of figure 6. example.¤some rules for a simple client-server system adapted from [vl06a] are defined in figure 5. there are three types of nodes: clients (c), servers (s) and routers (r). messages (selfloops in clients) can only be broadcasted. in the mgg approach, this transformation system will behave spo or dpo-like depending on the initial state. note that production p4 adds and deletes edges of the same type (c,c). by now, the rule will not be split into its addition and deletion components as suggested in 4. see section 6.1 for an example. figure 5: rules for a client-server broadcast-limited system. incidence tensor (edges) for these rules can be represented componentwise, each component being the matrix associated to the corresponding production. eaij1 =   0 0 0 c 0 0 1 r 0 1 0 s   ; eaij2 =   0 −2 0 −2 0 −1 0 −1 0   ; eaij3 =   0 2 0 2 0 0 0 0 0   ; eaij4 =   1 0 0 0 0 0 0 0 0   proc. pngt 2006 8 / 16 eceasst for space limitations, only in eaij1 we have specified which type each row belongs to. columns follow the same ordering. ¥ lemma 1 with notation as above, a necessary condition for state d m to be reachable from state 0m is d m− 0m = em = emij = n ∑ k=1 eaijkx k j = n ∑ k=1,p=k ( ea⊗x )ip jk (9) where i, j ∈ {1, . . . , m}. proof ¤consider the construction depicted in the center of figure 6 in which tensor aijk is represented as a cube. a product for this object is informally defined in the following way: every vector in the cube perpendicular to matrix x acts on the corresponding row of the matrix in the usual way, i.e., for every fixed i = i0 and j = j0 in (9): e d m i0 j0 = e0 m i0 j0 + n ∑ k=1 eai0j0kx k j0 (10) figure 6: matrix representation for nodes, tensor for edges and their coupling. every column in matrix x is a parikh vector as defined for petri nets. its elements specify the amount of times that every production must be applied, so all rows must be equal and hence, equation (10) needs to be enlarged with some additional identities    mij = n ∑ k=1 eaijkx k j xkp = x k q (11) with p, q ∈{1, . . . , m}. this uniqueness together with previous equations provide the intuition to raise (9). informally, we are enlarging the space of possible solutions and then projecting according to some restrictions. to see that it is a necessary condition, suppose that there exists a sequence sn such that sn (0m) = d m and that equation (10) does not provide any solution. without loss of generality we may assume that the first column fails (the one corresponding to nodes emerging 9 / 16 volume 2 (2006) matrix grammars from the first node), which produces an equation completely analogous to the state equation for petri nets, deriving a contradiction. ¥ example (cont’d).¤let’s test whether it is possible to move from state s0 to state sd (see figure 7) with the productions defined in previous example. figure 7: initial and final states for productions in fig.5. matrices for the states (edges only) and their difference are: es0 =   1 0 0 c 0 0 0 r 0 0 0 s   ; esd =   3 1 0 c 1 0 1 r 0 1 0 s   ; es = esd −es0 =   2 1 0 c 1 0 1 r 0 1 0 s   the proof of proposition 2 poses the following matrices: eai1k =   0 0 0 1 c 0 −2 2 0 r 0 0 0 0 s   ; eai2k =   0 −2 2 0 c 0 0 0 0 r 1 −1 0 0 s   ; eai3k =   0 0 0 0 c 1 −1 0 0 r 0 0 0 0 s   these matrices act on matrix x = ( xpq ) , p ∈ {1, 2, 3, 4}, q ∈ {1, 2, 3} to obtain es1 = 4 ∑ k=1 ea1kx k 1 =   x41 −2x21 + 2x31 0   es2 = 4 ∑ k=1 ea2kx k 2 =   −2x22 + 2x32 0 x12 −x22   es3 = 4 ∑ k=1 ea3kx k 3 =   0 x23 −x33 0   recall that x must satisfy x11 = x 1 2 = x 1 3; x 2 1 = x 2 2 = x 2 3; x 3 1 = x 3 2 = x 3 3; x 4 1 = x 4 2 = x 4 3. a contradiction is derived for example with equations x22 = x 3 2, −2x21 + 2x31 = 1, x21 = x22 and x31 = x 3 2. ¥ it is straightforward to derive a unique equation for reachability which considers both nodes and edges, i.e., equations (8) plus (9). this is accomplished extending the incidence matrix m from m : e → e to m : e ×n → e (from mm×m to mm×(m+1)), where column m + 1 corresponds to nodes. proc. pngt 2006 10 / 16 eceasst definition 3 (incidence tensor) given a grammar g = (0m,{p1, . . . , pn}), the incidence tensor aijk with i ∈{1, . . . , m} and j ∈{1, . . . , m+1} is defined by (9) if 1 ≤ j ≤ m and by (8) if j = m+1. note that top left index in our notation works as follows: na refers to nodes, ea to edges and a to their coupling. an immediate extension of lemmata 1 is: proposition 2 (state equation for dpo-like matrix grammars) with notation as above, a necessary condition for state d m to be reachable (from state 0m) is m j i = n ∑ k=1 aijkx k (12) notice that equation (12) is a generalization of the state equation (6) for petri nets. 6 reachability: spo-like matrix graph grammars our intention now is to relax the second property of petri nets and allow production application even though some dangling edge might appear (see [vl06a, vl06b]). the plan is carried out in two stages which correspond to the subsections that follow, according to the classification of ε -productions in [vl06a]. in our approach, if applying a production p0 causes dangling edges, the production can be applied but a new production (a so-called ε -production) is created and applied first. in this way, we obtain a sequence p0; pε 0, with the restriction that pε 0 is applied at a match that includes all nodes deleted by p0 that produce dangling edges. production pε 0 deletes the dangling edges produced by p0, and then p0 can be applied, without producing dangling edges (see [vl06a] for details). inside a sequence, a production p0 that deletes an edge or node can have an external or internal behaviour, depending on the identification carried out by the match. following [vl06a], if the deleted element was added or used by a previous production, we shall label the production as internal (according to the sequence). on the other hand, if the deleted element is provided by the host graph and it is not used until p0’s turn, then p0 is an external production. in some sense, their properties are complementary: while external ε -productions can be advanced and composed to eventually get a single initial production which adapts the host graph to the sequence, internal ε -productions are more static3in nature. on the other hand, internal ε -productions depend on productions themselves and are somewhat independent of the host graph, opposite to external ε -productions. note however that internal nodes can be unrelated if, for example, matchings identify them in different parts of the host graph, thus becoming external. 6.1 external ε -productions the main property of external ε -productions, with respect to internal ε -productions, is that they act only on edges that appear in the initial state, so their application can be advanced to the beginning of the sequence. in this situation, the first thing to know for a given matrix graph 3 maybe it is possible to advance their application but, for sure, not to the beginning of the sequence. 11 / 16 volume 2 (2006) matrix grammars grammar g = (0m,{p1, . . . , pn}) with at most external ε -productions when applied to 0m, is the maximum number of edges that can be erased from its initial state. the potential dangling edges (those with any incident node to be erased) are given by: e = n∨ k=1 ( n k e⊗ nk e ) (13) proposition 3 given a grammar g = (0m,{p1, . . . , pn}) with external ε -productions only, a necessary condition for state d m to be reachable (from state 0m) is mij = n ∑ k=1 ( aijkx k ) + bij (14) with the restriction 0me ≤ bij ≤ 0. note that equation (12) in proposition 2 is recovered from (14) if there are no external ε productions. according to [vl06a], all ε -productions can be advanced to the beginning of the sequence and be composed to obtain a single production, adapting the initial digraph before applying the sequence, which in some sense interprets matrix b as the production number n + 1 in the sequence (i.e. the first to be applied). because it is not possible to know in advance the order of application of productions, all we can do is to provide bounds for the number of edges to be erased. example. consider the initial and final states shown in figure 8. productions of previous examples are used, but two of them are modified (p2 and p3). figure 8: initial and final states with amendments to some productions of fig. 5. in this case there are sequences that transform state 0s in d s, for example, s4 = p4; p1; p′3; p ′ 2. note that the problem is in edge (1 : s, 1 : r) of the intial state: router 1 is able to receive packets from server 1, but not to send them. next, matrices for the states and their difference are calculated. the first three columns correspond to edges (first to clients, second to routers and third to servers), fourth to nodes and fifth specifies types. 0s =   1 1 0 3 c 2 0 0 2 r 0 2 0 1 s   ; ds =   2 1 0 3 c 3 0 1 2 r 0 2 0 1 s   ; s = ds−0s =   1 0 0 0 c 1 0 1 0 r 0 0 0 0 s   proc. pngt 2006 12 / 16 eceasst the incidence tensors for every production (recall that p2 and p3 are as in figure 8) have the form aij1 =   0 0 0 0 0 0 1 1 0 1 0 0   ; aij2 =   0 0 −1 0   ; aij3 =   0 1 0 0 1 0 0 0 0 0 0 0   ; aij4 =   1 0 0 0 0 0 0 0 0 0 0 0   though it does not seem to be strictly necessary here, more information is kept and calculations are more flexible if production p4 is split in the part that deletes messages and the part that adds them, p4 = p4r; p4e. see comments about this in section 4 aij4e =   −1 0 0 0 c 0 0 0 0 r 0 0 0 0 s   ; aij4r =   2 0 0 0 c 0 0 0 0 r 0 0 0 0 s   as in the example of section 5, the following matrices are more appropriate for calculations: ai1k =   0 0 0 −1 2 0 0 1 0 0 0 0 0 0 0  ; ai2k =   0 0 1 0 0 0 0 0 0 0 1 0 0 0 0  ; ai3k =   0 0 0 0 0 1 0 0 0 0 0 0 0 0 0  ; ai4k =   0 0 0 0 0 1 −1 0 0 0 0 0 0 0 0   if (12) is directly applied, we obtain x1 = 0 and x1 = 1 (third row of ai2k and second of a i 3k) deriving a contradiction. the variations permitted for the initial state are given by the matrix 0me =   0 α 12 0 0 α 21 0 0 0 0 α 32 0 0   (15) with α 12 ∈ {0,−1}, α 21 , α 32 ∈ {0,−1,−2}. setting b12 = −1 and b32 = −1 (one edge (s, r) and one edge (c, r) removed) the system to be solved is   1 1 0 0 1 0 1 0 0 1 0 0   =   −x4 + 2x4 x3 0 0 x3 0 x1 x1 −x2 0 x1 0 0   with solution x1 = x2 = x3 = x4 = 1, s4 being one of its associated sequences. note that the restriction in proposition 3 is fulfilled, see (15). in previous example, as we knew a sequence (s4) answer to the reachability problem, we have fixed matrix b directly to show how proposition 3 works. although this will not be normally the case, the way to proceed is very similar: relax matrix m by substracting b, find a set of solutions {x, b} and check whether the restriction for matrix b is fulfilled or not. 13 / 16 volume 2 (2006) matrix grammars 6.2 internal ε -productions internal ε -productions delete edges appended or used by productions preceding it in the sequence. in this subsection we first limit to sequences which may have only internal ε -productions and, by the end of the section, we shall put together proposition 3 from subsection 6.1 with results derived here to state theorem 5 for spo-like matrix graph grammars. the way to proceed is completely analogous to that of external ε -productions. the idea is to allow some variation in the amount of edges erased by every production, but this variation is constrained depending on the behaviour (definition) of the rest of the rules. unfortunately, not so much information is gathered in this case and what we are basically doing is ignoring this part of the state equation. define hijk = [ aijk (e⊗ik) ] + = max (a(e⊗i), 0), where ik = [1, . . . , 1](1,k).4 proposition 4 given a grammar g = (0m,{p1, . . . , pn}) with internal ε -productions only, a necessary condition for state d m to be reachable (from state 0m) is mij = n ∑ k=1 ( aijk + v ) xk (16) with the restriction hijk ≤ v ijk ≤ 0. in some sense, external productions are the limiting case of internal productions and can be seen almost as a particular case: as ε -productions do not interfere with previous productions they have to act exclusively on the host graph. the full generalization of the state equation for matrix graph grammars is: theorem 5 (state equation) with previous notation, a necessary condition for state d m to be reachable (from state 0m) is mij = n ∑ k=1 ( aijk + v ) xk + bij (17) bij must satisfy restrictions specified in proposition 3 and v those in proposition 4. strengthening hypothesis, formula (5) becomes those already studied for spo with internal ε -productions (b = 0), with external ε -productions (v = 0), dpo-like (from multilinear to linear transformations) or petri nets, fully recovering the original form of the state equation. 7 related work concerning our mgg approach to graph rewriting, in [val98] an implementation of the dpo categorical approach to graph transformation was implemented using mathematica. in that work, (simple) digraphs were represented with their boolean adjacency matrices. this is the only similarity with our work, as our goal is to develop a theory for (simple) graph rewriting based on 4 e⊗i(k) defines a tensor of type (1,2) wich “repeats” matrix e k times. proc. pngt 2006 14 / 16 eceasst boolean matrix algebra. other somehow related approach is the relational approaches of [mk95] and [kah02]. however, they rely on using category theory for expressing the rewriting. the recent work [vve+06] shows a means to encode a graph transformation system into a petri net. then algebraic approaches based on the state equation can be used for analysis. the approach is similar to ours, as they perform the same abstraction (taking node and edge types). however, on the one hand, they consider negative application conditions in rules. on the other hand, we consider both dpo and spo-like grammars, and we extend the state equation using tensors, instead of first encoding the transformation system as a petri net. 8 conclusions and future work. the starting point of the present paper is the study of petri nets as a particular case of mggs. next, reachability and the state equation have been reformulated and extended with the language of this new approach, trying to provide tools for grammars as general as possible. the objective is almost fulfilled, bearing in mind that the more general the grammar, the less information the state equation provides. for example, equation (12) is more accurate as long as the rate of the amount of types of nodes with respect to the amount of nodes approaches one. hence, in general, it will be of little practical use if there are many nodes but few types. nevertheless, we are in a much better position than we were before. although the use of vector spaces (as in petri nets) and multilinear algebra is almost straightforward, many other algebraic structures are available to improve the results herein presented. for example, lie algebras seem a good candidate if we think of the lie bracket as a measure of commutativity (recall subsection 3 in which we saw that this is one of the main problems of using linear combinations). other concepts and techniques from petri nets such as invariants, boundedness, liveness, reversibility, persistence, etc., can also be extended to more general grammars. besides, it is possible as well to get a better insight and understanding of matters by applying matrix graph grammars techniques (as those in [vl06a, vl06b] and the present paper) to petri nets. we are also extending our matrix graph grammars approach to work with multi-graphs. a first line of attack is to model edges as special nodes (with exactly one incoming and outgoing edge). acknowledgements: this work has been sponsored by the spanish ministry of science and education, project mosaic (tsi2005-08225-c07-06). the authors would like to thank the referees, the workshop participants and alejandro pérez velasco for their useful suggestions. references [eept06] h. ehrig, k. ehrig, u. prange, g. taentzer. fundamentals of algebraic graph transformation. monographs in theoretical computer science, an eatcs series. springer, berlin, heidelberg, new york, 2006. [kah02] w. kahl. a relational algebraic approach to graph structure transformation. technical report 2002-03, universitat der bundeswehr munchen, 2002. 15 / 16 volume 2 (2006) matrix grammars [mk95] y. mizoguchi, y. kuwahara. relational graph rewritings. theoretical computer science 141:311–328, 1995. [mur89] t. murata. petri nets: properties, analysis and applications. proceedings of the ieee 77(4):541–580, april 1989. [sok51] i. s. sokolnikoff. tensor analysis, theory and applications. applied mathematics series. john wiley and sons, new york, 1951. [val98] g. valiente. grammatica: an implementation of algebraic graph transformation on mathematica. in proc. sixth workshop on theory and application of graph transformations. pp. 261–267. 1998. [vl06a] p. p. p. velasco, j. de lara. matrix approach to graph transformation: matching and sequences. in proc. icgt’06. lecture notes in computer science 4178, pp. 122–137. springer-verlag, 2006. [vl06b] p. p. p. velasco, j. de lara. towards a new algebraic approach to graph transformation: long version. technical report, universidad autónoma de madrid, 2006. http://www.ii.uam.es/jlara/investigacion/techrep 03 06.pdf [vve+06] d. varro, s. varro-gyapay, h. ehrig, u. prange, g. taentzer. termination analysis of model transformations by petri nets. in proc. icgt’06. lecture notes in computer science 4178, pp. 260–274. springer-verlag, 2006. proc. pngt 2006 16 / 16 http://www.ii.uam.es/jlara/investigacion/techrep_03_06.pdf� pattern catalogs using the pattern language meta language electronic communications of the easst volume 25 (2010) proceedings of the workshop visual formalisms for patterns at vl/hcc 2009 pattern catalogs using the pattern language meta language andreas wolff, peter forbrig 11 pages guest editors: paolo bottoni, esther guerra, juan de lara managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst pattern catalogs using the pattern language meta language andreas wolff1, peter forbrig2 1 andreas.wolff@uni-rostock.de 2 peter.forbrig@uni-rostock.de http://wwwswt.informatik.uni-rostock.de universität rostock, germany institut für informatik abstract: this article focuses on the pattern language plml. some enhancements and corrections to it are proposed to make use of plml in pattern catalogs. additionally, a textual domain specific language as human-readable variant of plml is proposed. supporting editors, textual and graphical, which were developed using model-based techniques are presented. keywords: hci pattern, pattern language, model-based editor 1 introduction object-oriented design patterns, as introduced by gamma et al. [ghjv02], are considered a valuable aid in software development. patterns were identified in many other domains of computer science. one such domain is human computer interaction (hci). hci patterns do exist for many different aspects of the user interface of an application. for example for navigation through an interface, its layout, input modalities or presentation. a number of pattern catalogs has been compiled by the hci community. well known examples are the catalogs of tidwell [tid] and van welie [vw]. on examining hci patterns in those catalogs one soon discovers certain problems: • there is no consistent naming of patterns across those collections. multiple entries for what is essentially the same pattern are likely. • intra-catalog references are rare, cross-catalog references almost non-existant. • aspects of a pattern that are detailed in a pattern entry differ. this is not only in naming but also in extent. (e.g. a problem or solution description is omitted) • the abstraction level differs from pattern to pattern. • the pattern solution is given very informal, mostly text accompanied by pictures for illustration purposes. of course, the findings above are not novel. there are approaches to standardize pattern catalogs. the xml dialect plml [fin03] is such an attempt. it was developed to define a common base of how to describe patterns. plml defines a pattern language and an exchange format. it was constructed to cover generic patterns, not for hci patterns in particular. without having a specific domain as boundary, it was not possible to restrict the language elements beyond very 1 / 11 volume 25 (2010) mailto:andreas.wolff@uni-rostock.de mailto:peter.forbrig@uni-rostock.de http://wwwswt.informatik.uni-rostock.de pattern catalogs using the pattern language meta language task model user model business object model domain model ' & $ % dialog graph abstract ui class diagram (analysis) class diagram (design) application model ui model ' & $ % relation transformation pattern based figure 1: general view on a transformational model-based development process basic constraints. therefore plml itself does not overcome the lack of formalization problem mentioned earlier. section 2 of this paper presents plml in some detail and also introduces some enhancements proposed by us. in our research we develop a pattern-based approach to model-driven user interface engineering. therein we consider software development as a sequence of transformations of models. figure 1 shows the source and target models and the in-between transformations of our approach. further details of this process are described for example in [wfdr05]. more important, than the details of our approach, for the scope of this paper is the ubiquitous use of pattern-based transformations. one consequence of this was the need to specify those transformations. our goal always was to create a semi-automatic human-controlled overall process, which will be supported by appropriate tools for every transformation step. therefore we had to store patterns in a machine readable manner. the current focus of our research is the lower part of figure 1, the generation of user interfaces (ui). we attempt to represent hci-patterns for uis in a suitable way so they can be used within our mda process. this is done by transforming the pattern idea into a so-called pattern instance component (pic). such a pic is basically an attributed template that may include some programming logic. it is called instance component, since we consider the template to be already an instance of the pattern that is described through this component. we are aware of the fact that, due to their nature, not all known hci patterns can be treated as or translated into an algorithm or a pic. comparable work has been done for the original gamma patterns by arnout [arn04], who proc. vffp 2009 2 / 11 eceasst investigated and, where possible, created usable components of design patterns for the eiffel programming language. the language used for our pattern instance components is domain specific to user interfaces, it was outlined in [rwf06]. nevertheless, it is a xml-based language and therefore it is possible to contain it in or link to it from most existing pattern languages. as our whole approach is model-based, we developed a pattern language that also is based on models. it is compliant to plml and able to hold pics. also it is possible to store pattern descriptions of patterns whose solution cannot be specified using a pic. the rest of this paper presents this pattern language. section 3 shows a textual domain specific language (dsl) as interface to our catalog. in section 4 a possile graphical interface is discussed and generated as model-based graphical editor. 2 pattern language meta language 2.1 overview plml the pattern language meta language plml was developed by a group of stakeholders during a workshop. the idea behind, was to formalize the description of patterns to eventually merge all existing pattern languages or at least to have a general interchange format. it was designed to be able to describe patterns on any abstraction level and of any domain. beside the pure pattern description a number of identifying meta data became standardized.� � � � listing 1: dtd of the plml standard [plm] listing 1 shows the document type definition of plml, official version 1.1.2. every element that is not explained in further detail is of type #pcdata or any. table 1 has a short description for all pattern related language elements. the meta-data elements of management seem to be self 3 / 11 volume 25 (2010) pattern catalogs using the pattern language meta language element description patternid collection-unique id of a pattern name name, as short as possible alias alternative names illustration picture that illustrates a particularly good pattern instance problem design situation which the pattern addresses context conditions when application of a pattern is most useful forces forces which are resolved by application of the pattern solution instructions to follow the idea of the pattern synopsis summary of the pattern idea diagram schematic visualization of the pattern, sketched or formal evidence justification that a pattern actually is a pattern by: example known uses rationale principled reasons, axioms, common sense or the like confidence star rating whether the entry is a true pattern (0 to 2 stars) literature references to related work implementation code or fragments of code or other technical documentation related-pattern container for connections to other patterns pattern-link connection to other pattern: type kind of connection, either of is-a, is-contained-by, contains patternid connection endpoint collectionid connection endpoint in collection named collectionid label descriptive text of connection table 1: summarization of the meanings of plml’s language elements [fin03] explanatory. as mentioned before, the degree of freedom listing 1 permits was modeled deliberately. however, some aspects that are discussed in the workshop report [fin03] were not put into the standard. additionally there is a lack of meta-data storage area if plml is used to actually build a pattern catalog. subsection 2.2 outlines our enhancements to plml and provides a rationale for each amendment. 2.2 enhancing plml building a pattern catalog using plml, as defined in section 2, quickly reveals a first problem. there is no root element to attach the entries to. also no xml-tags are reserved to describe the catalog itself, i.e. its authors, revision or certain dates. listing 2 introduces such a catalog root element to meet these basic requirements. attributes are provided to name a catalog and assign a global identificator to it. the latter feature is needed for cross-catalog pattern-links. other, catalog describing, meta-data is stored using the already existing element management.� � � � listing 2: introducing catalog meta information into plml the plml explanation in [fin03] explains that the confidence, whether an entry is a true pattern, is expressed using a star rating. it is possible to include this into the document type definition of plml. listing 3 defines an attribute level for the element confidence and limits its value space to one of the three entries. the element confidence is redefined to not contain content any more. through this amendment the notation of confidence levels is fixed and therefore easy to parse.� � � � listing 3: narrowing the value space of confidence information the plml standard often refers to illustrations to describe certain aspects of a pattern. nevertheless, there was little support to actually integrate pictures or at least resource locators of pictures in a catalog. while it is possible to include pictures as binary data in an xml document, we resorted to annotate urls of pictures in our pattern entries. listing 4 defines optional url attributes for three plml elements.� � � � listing 4: annotating picture urls to certain elements another notable change to the original standard was to allow pattern-link only as subelements of related-pattern. also there were minor changes to the representation of management meta-data. 3 plml as textual dsl plml was designed as storage and interchange format, human-readability was not of primary concern. but, when writing and maintaining a catalog it is sometimes inconvenient and errorprone to edit in xml structures. there are different ways to cope with this situation. one solution is to use dedicated xml editors or to develop a specialized editor. since we work in a model-based context we decided to create a dedicated plml editor using model-based technology. we defined a grammar for a textual domain specific language (dsl) resembling plml. from this grammar we generate a fully featured text editor and a meta-model of plml. having a proper meta-model enables us to easily include the patterns of the catalog within our software engineering approach of figure 1. the meta-model also is a prerequisite to keep our pattern catalog compliant to plml standard. using the model it is very straightforward to generate valid plml from our modified pattern language and thus adhere to the interchangeability concept of plml. the grammar of our textual dsl is a xtext [ev] grammar. xtext is a model-based framework for such dsls. it is a plugin to the eclipse rich client platform. provided a grammar, xtext 5 / 11 volume 25 (2010) pattern catalogs using the pattern language meta language generates a text editor and an emf ecore [emf] meta-model. through simple customizations this text editor supports: • syntax highlighting, keywords or structuring elements are emphasized • syntax completion, there is an editing help which offers keyword completion within the text editor • error checking, the text is permanently checked against the language grammar and violations are marked within the editor. • a structured outline view provides an overview and simple navigation through the catalog. a xtext grammar is context-free and its notation is ebnf-like. nonterminal symbols start with a capital letter, terminal symbols are in quotation marks. several syntax elements and predefined types were introduced through xtext to derive better meta-models.� � relatedpatterns: ”relatedpattern” ”{” (references+=patternlink)∗ ”}”; patternlink: type=patternlinktype ”id=” targetid=string (hascollection?=”collection=” collection=id)? (haslabel?=”label=” label=string)?; enum patternlinktype: isa=”is−a”|containedin=”is−contained−by”|contains=”contains”;� � listing 5: grammar for a pattern-link entry listing 5 is an excerpt from the xtext grammar of plml. it shows the specification of pattern relations. a pattern-link is specified using the nonterminal patternlink. patternlinks occur within the nonterminal relatedpatterns. relatedpatterns is defined as starting with the terminal (or string) ”relatedpattern” followed by zero-to-many patternlinks included in curly braces within the text. in the meta-model every patternlink will be stored in the references aggregation of the relatedpatterns type. hascollection and haslabel are simple markers, they are interpreted as boolean values to easily check whether a collection or label value was set at all. the enumeration type patternlinktype restricts the value space of the patternlink type to one of the three values, this is very much like in listing 3 for confidence level stars. the xtext framework parses the grammar into an antlr grammar. antlr [ant] is an object oriented parser generator. xtext uses antlr to generate parser and lexer for the text editor. � � catalog samplecatalog masterdata { author ”andreas wolff” creationdate 2008−12−31 revision 1.0.2 } pattern ync ”yes−no−cancel” { proc. vffp 2009 6 / 11 eceasst alias ”feedback” collection hcipatterns problem ”decide a binary question or cancel the current operation” evidence { rationale ”a user should be able to cancel an operation, not only decide between two possibly undesired consequences” } confidence ∗∗ relatedpattern { contains id=”yn” } masterdata { author ”andreas” creationdate 2009−02−15 revision 1.0 } }� � listing 6: catalog containing one pattern entry using our textual dsl in listing 6 a sample catalog can be seen. this catalog contains only a single pattern description, the ”yes-no-cancel” pattern [pet] which got the id ”ync” assigned. the confidence in ”ync” being a pattern is high and it is related to a pattern ”yn” within the same catalog. ”ync” is also known as the pattern ”feedback” in another catalog which has the id ”hcipatterns”. a problem description and a rationale for this pattern are given textually, no illustration or diagrams are used. listing 6 is a minimum example to illustrate the idea. figure 2 shows the meta-model which was derived from the grammar. again, to reduce complexity, it is only an excerpt of the complete model. type management is actually not an empty class. catalog management data has been left out too. the enumeration patternlinktype which consists of three constant values is also not displayed. while the pattern catalog itself is a plain-text file, the data it contains is accessed via instances of the meta-model. xtext parses the catalog text file and builds such instances from the textual entries. the root class of the model is the type pattern, whose objects have an association to an object of class patterndescription. patterndescription is a container class where most aspects of a pattern are defined by creating aggregrations to their respective types. 4 graphical representation of plml the meta-model of plml is a useful tool. it can be used to generate a graphical editor or viewer for plml based catalogs. there is another model-based framework to construct such editors from emf ecore models, the eclipse graphical modeling framework (gmf) [gmf]. gmf provides runtime components and a generator framework to build graphical editors, these editors are generated as eclipse plugins. a number of auxiliary models are necessary within this process: • gmfgraph is the model to define figures. the appearance of any diagram element is 7 / 11 volume 25 (2010) pattern catalogs using the pattern language meta language figure 2: overview of the meta-model of plml described here. • gmftool describes the various menus, toolbars and the palette of an editor. • ecore is the underlying meta-model of the application domain. • genmodel is for generating source code for access and modification of the model instances. • gmfmap merges above four models. the mapping model defines how meta-model elements are mapped on diagram nodes or connections. other mappings include the connection between menu entries and diagram nodes. • gmfgen is the basis for editor generation. it is derived from the mapping model gmfmap. as it is the very last step before generating the actual editor, a lot of fine tuning can be executed here. an important decision for every meta-model class and attribute is whether and how to display it in an editor. basically every such element can be a free-form figure or a connection link or a label or a composed figure or have no figure at all. property sheets are assigned to every class figure. this way properties that are not displayed as a figure are editable anyway. in gmf-editors we can also choose to display elements as container, i.e. that they can have children within their graphical representation. for the initial plml meta-model we map the classes pattern, patterndescription and management onto graphical containers. pattern will be the root container of pattern description and its associated master data. patternlinks will be editable as connections and have labels about their type attached. attributes of type string are mapped to labels and can be edited in place. they are arrange into their appropriate category, either management or pattern description data. boolean attributes and the link type of a pattern relation can only be edited using the property proc. vffp 2009 8 / 11 eceasst figure 3: graphical plml editor in eclipse sheet. after all mappings are done gmf generates a complete graphical editor as eclipse plugin. figure 3 is a screenshot of such an editor. for this specific editor the master data of the catalog itself was mapped to an own graphical element. two patterns are defined in this catalog and a bi-directional relation exists between them. the lower pattern node (yes-no-cancel) is the result of the textual definition in listing 6. the other pattern node for a yes-no pattern is defined very similar. only the containment relation was reversed and the confidence for yes-no to be a pattern was set to 1-star. in figure 3 the pattern relation ”contains” between yes-no-cancel and yes-no was selected within the editor window. the property sheet below shows all attributes of this relation. changing the attribute values here directly effects the content of the editor. the property sheet of the link reveals two attributes which are not defined in the meta-model of figure 2. attributes source and target were introduced while preparing the gmfmap mapping model, both are of type pattern. they were specified to be derived and transient, i.e. their value is a direct consequence of other attribute values and they therefore need not to be serialized. the value of target for example is the pattern object whose id equals the targetid of the patternlink. another notable difference is in confidence. the meta-model declares three boolean attributes, this is a direct result from xtext’s grammar to model transformation. i.e. these attributes are a technical necessity, but somewhat impractical. to visualize the true confidence level a starlike labeling was desired. so again an transient derived attribute label was introduced whose value is displayed instead of the booleans. of course, the concrete values of target, source and label need to be calculated somewhere. to achieve this we had to leave the model level and actually write some source code. through 9 / 11 volume 25 (2010) pattern catalogs using the pattern language meta language modification of the meta-model edit code, which was generated using the genmodel, getting and setting the value of the derived attributes also modifies the underlying data attributes. using gmf for the graphical editors enables us to quickly modify the editors. since most of the editors source code is generated from the models we can easily try out many kinds of visualizations. this is not only about the layout or form or color of a certain diagram node. through changes in the mapping model we could pursue a completely different idea of graphical containment. but of course, all such editors would only be different views on the very same data. the catalog data itself will always be serialized using the textual dsl of section 3. 5 conclusion this paper describes the pattern language plml. it is a xml-based language which can be used to define pattern catalogs. certain modifications to its original standard were proposed in the paper to repair some issues with applying plml in a real catalog. plml is used as the pattern container in an integrated model-based environment. therefore the pattern language was backed with model-based editing tools. a textual dsl has been presented that makes it easy to edit the pattern catalog using standard text editors. at the same time this dsl is the meta-model or rather forms the foundation of an emf ecore meta-model of the pattern language. two separate editors for the dsl where derived from models. the first is an advanced text editor, that supports typical developer features like syntax highlighting and auto-completion. a second editor is a graphical editor that was developed using the eclipse graphical modeling framework. it was shown that such generated editors are highly flexible in terms of the graphical representation of the language elements. bibliography [ant] antlr another tool for language recognition. http://www.antlr.org, last visited 6th june 2009. university of san francisco. [arn04] k. arnout. from pattern to components. phd thesis, eth zurich, 2004. [emf] eclipse modeling framework project. http://www.eclipse.org/modeling/emf/? project=emf, last visited 6th june 2009. eclipse foundation. [ev] s. efftinge, m. voelter. oaw xtext: a framework for textual dsls. http://eclipsesummit.org/summiteurope2006/presentations/ ese2006-eclipsemodelingsymposium12 xtextframework.pdf, last visited 6th june 2009. [fin03] s. fincher. perspectives on hci patterns: concepts and tools (introducing plml). in workshop at chi 2003. sept. 2003. [ghjv02] e. gamma, r. helm, r. johnson, j. vlissides. design patterns elements of reusable object-oriented software. addison-wesley, 24th edition, 2002. proc. vffp 2009 10 / 11 http://www.antlr.org http://www.eclipse.org/modeling/emf/?project=emf http://www.eclipse.org/modeling/emf/?project=emf http://eclipsesummit.org/summiteurope2006/presentations/ese2006-eclipsemodelingsymposium12_xtextframework.pdf http://eclipsesummit.org/summiteurope2006/presentations/ese2006-eclipsemodelingsymposium12_xtextframework.pdf eceasst [gmf] eclipse graphical modeling framework project. http://www.eclipse.org/modeling/ gmf/, last visited 6th june 2009. eclipse foundation. [pet] r. petrasch. model based user interface design: model driven architecture und hci patterns. http://pi.informatik.uni-siegen.de/stt/27 3/03 technische beitraege/ mda hci patterns petrasch short.pdf, last visited 6th june 2009. [plm] dtd of plml. http://www.hcipatterns.org/tiki-download file.php?fileid=7, last visited 6th june 2009. [rwf06] r. rathsack, a. wolff, p. forbrig. using hci-patterns with model-based generation of advanced user-interfaces. in pleuss et al. (eds.), proceedings of the models’06 workshop on model driven development of advanced user interfaces. genova, oct. 2006. http://sunsite.informatik.rwth-aachen.de/publications/ceur-ws/vol-214/ [tid] j. tidwell. pattern library. http://www.designinginterfaces.com, last visited 6th june 2009. [vw] m. van welie. pattern library. http://www.welie.com/patterns/index.php, last visited 6th june 2009. [wfdr05] a. wolff, p. forbrig, a. dittmar, d. reichart. development of interactive systems based on patterns. in workshop on mapping user needs into interaction design solutions at interact. rome, italy, sept. 2005. 11 / 11 volume 25 (2010) http://www.eclipse.org/modeling/gmf/ http://www.eclipse.org/modeling/gmf/ http://pi.informatik.uni-siegen.de/stt/27_3/03_technische_beitraege/mda_hci_patterns_petrasch_short.pdf http://pi.informatik.uni-siegen.de/stt/27_3/03_technische_beitraege/mda_hci_patterns_petrasch_short.pdf http://www.hcipatterns.org/tiki-download_file.php?fileid=7 http://sunsite.informatik.rwth-aachen.de/publications/ceur-ws/vol-214/ http://www.designinginterfaces.com http://www.welie.com/patterns/index.php introduction pattern language meta language overview plml enhancing plml plml as textual dsl graphical representation of plml conclusion methodologies and tools for oss: current state of the practice electronic communications of the easst volume 33 (2010) proceedings of the fourth international workshop on foundations and techniques for open source software certification (opencert 2010) methodologies and tools for oss: current state of the practice zulqarnain hashmi, siraj a. shaikh and naveed ikram 11 pages guest editors: luis s. barbosa, antonio cerone, siraj a. shaikh managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst methodologies and tools for oss: current state of the practice zulqarnain hashmi1, siraj a. shaikh2 and naveed ikram1 1 zulqarnain@iiu.edu.pk, naveed.ikram@iiu.edu.pk department of software engineering, faculty of basic and applied sciences, international islamic university, islamabad, pakistan 2 s.shaikh@coventry.ac.uk department of computing and the digital environment, faculty of engineering and computing, coventry university, coventry, united kingdom abstract: over the years, the open source software (oss) development has matured and strengthened, building on some established methodologies and tools. an understanding of the current state of the practice, however, is still lacking. this paper presents the results of a survey of the oss developer community with a view to gain insight of peer review, testing and release management practices, along with the current tool sets used for testing, debugging and, build and release management. such an insight is important to appreciate the obstacles to overcome to introduce certification and more rigour into the development process. it is hoped that the results of this survey will initiate a useful discussion and allow the community to identify further process improvement opportunities for producing better quality software. keywords: open source, testing, debugging, release management, peer review. 1 introduction open source software (oss) is becoming popular both in business communities and academic sectors. the oss movement has proved its worth with notable products such as linux, apache, mysql and mozilla, to name a few. oss development is typically initiated by a small group of people [sff+06] and can be distinguished from traditional development in terms of volunteers involved in the development of software dictated by their need and interest, as opposed to a dedicated team of paid developers guided by some (usually profit-making) commercial product. such volunteers choose when and what they want to work on with typically a very loose heirarchy, as opposed to their paid counterparts. the expectation of most oss projects is that there is less support in terms of development tools, no or very less formal design, improper project development planning, a fixed list of deliverables is not available and finally no structured testing or quality assurance of the final product. oss projects are also less likely to be supported by project management, metrics, estimation and scheduling tools as there is no need for strict deadlines and balancing budgets [rfl05, rob02]. oss projects have been criticised for lack of clear and open detail of development processes. studies on apache and mozilla [mfh99, mfh02, rm02] usually give an informal description 1 / 11 volume 33 (2010) mailto:zulqarnain@iiu.edu.pk mailto:naveed.ikram@iiu.edu.pk mailto:s.shaikh@coventry.ac.uk the eceasst document class of development processes which cannot be usefully replicated. our observation discovers that sources of information on the community, project history, work roles and task prescription provided on several oss project websites appear mind-numbing and ambiguous. a need for standard and clear development practices has been acknowledged [sca03]. sharing clear and open description of development processes, with a view to further improvisation and reuse is certainly of great interest to the wider oss community [mic05, rm02]. our effort is aimed at better understanding some of the development processes and behaviour within a set of oss projects. we present a survey of oss developers. the survey is essentially descriptive in nature and lies in cross-sectional time dimensional category. the top 250 oss projects from a variety of domains were selected from sourceforge [sou09] and launchpad [lau09] on the basis of downloading ratings. the sampling ensured that each member of the population has an equal probability of being selected. download rates do not convey quality or success but certainly offers a measure of fitness for purpose as users of oss have actively downloaded it; it is essentially an objective measure independent of our influence [mic05]. the hope is that this work will allow the wider community to identify process improvement for better quality and critical software. the importance of quality in oss due to development practices has already been acknowledged [sc09]. such an insight is important to appreciate the obstacles to overcome to introduce certification and more rigour into the development and testing processes. moreover, attempts to introduce the use of formal modelling and verification within oss developmen practices has also been suggested [cs08], though challenges have also been identified as to who and where to initiate such changes within the oss community; addressing such challenges is of interest to us in this paper and is essentially the next step. 1.1 rest of this paper the rest of this paper is organised as follows. section 2 describes some of the related work. some past observations and the relevant trends observed are brought to attention. section 3 discusses the methodology adopted for this effort with particular emphasis on the choice of oss projects targeted for the survey. this is helpful in setting the results in the overall context. section 4 presents the results of the survey. some trends of interest are highlighted though the majority of the results serve to affirm traditional perceptions of the oss community. section 5 concludes the paper and promises some future work. 2 related work organisational structures, technical roles and career opportunities within the oss community have been widely studied [sca07, yk]. traditionally software engineers have been restricted to roles like requirements analyst, software designer, programmer or code tester. in the oss community, roles and progression (or movement) is more sundry: volunteering roles can move up and down amongst different paths much more gracefully, with the possibility of lateral movements as well. some of the recognised roles in oss include project leader, core developer or member, active developer, passive or peripheral developer, bug fixer, bug reporter, reader/active user and proc. opencert 2010 2 / 11 eceasst passive user, with the likely possibility of overlap. not all of these types of roles exist in all oss communities, and some communities may use different names. for example, some communities refer to core members as maintainers. the difference between bug fixer and peripheral developer is also rather small as peripheral developers are likely to be engaged in fixing bugs. several developers and users examining the source code is one of the fundamental principles that underlies oss. some reports show that peer review on some oss has been performed by millions of developers [gbbz03]. such code reviews are mostly done before and after any source code is committed to the repository [hs02], performed in a distributed, asynchronous manner. they are certainly more extensively acknowledged and accepted as part of the organisational culture in oss than in traditional development. the developers more likely to perform them without any directions, which although not vital, may be a sign of commitment to quality within oss projects. it is useful in detecting flaws, defects and quality of oss, and is well recognised in software engineering generally for its crucial role [ema01, hs02]. in a survey [sta02], about 9% of oss developers claimed the peer review of the entire source code, whereas peer review of most of the code was pointed out by 50% of the developers. although the team members vary but the main emphasis is to maximize the ability to find bugs. the actual task is classified to be either ad-hoc or based on some checklist. the former signifies that the reviewers team has to examine in a perfect manners to dig out imperfections without any guidance. in order to guide and facilitate reviewers in examining all defect forms, standardized checklist of frequent faults is considered. there is good evidence that checklist-based techniques tend to find more defects than ad-hoc techniques [drw03]. testing is an essential part of the software development life cycle. recent studies establish the uniqueness of the oss development model with exceptionally high user involvement and structured approach for flaw/bug handling process, in the context of testing for oss [omk08]. unit testing is the most frequent in oss development. pre-release testing on broader perspectives is less common, with the idea being that the released candidate is dealt with by the users and its flaws reported. pre-release testing is not commonly demonstrated and formal testing is even not implemented for most of the oss development [hs02, ga04]. with confidence in code peer reviewed, many oss developers are content with only minor testing [sta02]. some other sources go as far as to claim that over 80% of oss developers dont have any plans of testing [ze00]. there is no specific evidence with regards to automated tools but debuggers are widely acknowledged [ze00]. for regression tests, about 48% of oss projects follow baseline testing, whereas proportion is relatively higher in mega projects [ze03]. a study conducted on the apache project revealed that no system testing or regression was performed [mfh02]. further analysis reports that while regression test suites were available for apache they were not actually mandatory [ere03]. this complements with suggestions that improvement is required in quality assurance practices, applied processes and project success criteria [omk08]. release management is a vital part in oss development. michlmayar [mic07] presents a comparative study on release management to find that it can be categorised into three types, with respect to the concerned audience and the effort required to deliver the release: developer release for interested developers and experienced users requiring less or no effort, major or stabilised releases for end users requiring more effort to deliver with considerable new features and functionality, bugs fixed and tested, and minor releases or updates for existing users requiring a slight 3 / 11 volume 33 (2010) the eceasst document class effort for stabilised release [mhp07]. more generally, a feature-based strategy is adopted in which certain criteria or goals have to be fulfilled, or, a time-based strategy with particular dates set for release and used as orientation for release. 3 research design the research method used in this study is essentially a survey which is most common for generating primary data. this survey is descriptive in nature and lies in cross-sectional time dimensional category. the unit of analysis is essentially individuals and oss developers are the respondents for this survey. the main objectives of the survey are to determine the development processes and developmental tools being used in oss projects. our population is open source developers and targeted populations are developers of recognised oss initiatives. the most important source to collect information about the development processes and tools used in oss projects are oss communities such as those accessed through sourceforge and launchpad, where thousands of oss projects are hosted across several domains. our selected domains are business intelligence and performance management, digital archiving, cms systems, crm, e-commerce, erp, email client, frameworks, message boards, project management, scheduling, site management, social networking, ticketing systems and wiki. we selected the top 250 oss projects from these domains on the basis of downloading ratings from sourceforge [sou09] and launchpad [lau09]. we have chosen a systematic sampling method where each member of the population has an equal probability of being selected. note that we use the download rate to define success. downloads do not convey quality or success of oss but certainly offers a measure of fitness for purpose as users of oss have actively downloaded it. downloads do provide the advantage as a measure as it is objective and dependent on the users [mic05]. we designed an online questionnaire consisting of 33 questions in total. we drew inspiration from [kenu07] for questions relating to peer review and testing of software. validity and reliability are the main priorities in surveys. there is a need of for pilot testing to assess the questionnaire clarity, understandability, comprehensiveness and acceptability. surveys should be adequately pre-tested to check that the respondents understand the meaning of the questions or statements and to gauge whether test items are at an appropriate level of difficulty. we validated our questionnaires by faculty members and oss industry experts and their reliability was determined by getting few responses from the population. participants were given an opportunity to offer comments on the structure of the questions including clarity, relevance to the objectives of the study, level of difficulty and length of the survey. several changes were made to improve the experience as per the feedback. a detailed search was undertaken to identify projects which existed with the same name under different domains. 250 projects were identified after eliminating duplications. once the list of oss projects was decided, names and contact details of the respective developers were collected (from their hosting websites). some developers were also involved in more than one project, which were also excluded for duplication. we restricted answers in our questionnaire for a proc. opencert 2010 4 / 11 eceasst specific project. 4 results and analysis this section presents the results of our survey. section 4.1 discusses the profile of projects and individuals who responded to the survey. this sets the context for the following sections which delve into peer review practices in section 4.2, testing strategies in section 4.3, release management in section 4.4 and the use of tools in section 4.5. section 4.6 provides a brief analysis on the results commenting on the aspects that are of particular interest. 4.1 developer and project profile over 58% of the total developers surveyed have more than 5 years of experience working with oss. of the rest, over 18% have 3 to 5 years, over 17% have 1 to 3 years and just under 5% of the developers have less than one year of experience working with oss. over 3% preferred not to answer. over 36% of the total developers who responded claimed a graduate degree, with over 25% holding a masters degree and just under 12% holding a doctoral degree. over 31% of the total respondents identified themselves as project leader, over 25% as core developer, over 10% as active developer and over 9% as passive developer. just over 7% claimed project management and over 3% bug reporter roles. just under 12% fell in the other category, which included translator and community manager roles. out of the total respondents, over 61% of the developers participate only part-time participation whereas over 24% are as dedicated full-time. a small percentage, just over 14%, described their participation as either in free time, voluntarily or occassional. when asked about information provision and dissemination for their oss projects, over 96% of the respondents claimed that their project has a dedicated website. of other similar resources, over 91% identified announcements, over 87% provide some form of user documentation and just over 81% mentioned a feature list advertised for the project. mailing lists, tutorials and to-do lists were also identified by well over 50% of the respondents. some other avenues for communications identified included code collaborator, repositories, forums and case studies provided for the users. for internal communication a variety of resources were identified including mailing lists (by over 76%), threaded discussion forums (60%), irc/chat/instant messaging (over 55%), newsgroups (over 17%), community digests (just under 13%) and other resources such as xmpp, bug trackers, wiki sites and micro blogging (over 16%). the authority to commit code varies from project to project, with the majority allowing core developers (just under 92%) to commit. over 60% mentioned active developers and over a quarter mentioned passive developers with the ability to commit. 4.2 peer review the survey reveals that software testing and release management are far more prevalent than code review, with over 87% confirming that some form of testing and release management is carried out on the oss project they are involved in. only over 61% of the respondents claimed 5 / 11 volume 33 (2010) the eceasst document class any code review for the software they are involved with. this is somewhat surprising as almost 40% of the respondents did not claim any code review on their projects. of those who did affirm code review, over a third claimed that reviews are performed before any source code is committed to the code base. around 30% also confirmed that some review is performed randomly and before product release. an important element of code review is inspection of code written by others. over a quarter of those surveyed affirmed that they regularly review other’s code with just over 30% claiming occasional review of other’s code. ony under 10% said they have never reviewed source code written by others. this reflects very well highlighting a strong ethos of evaluation and selfregulation amongst the section of the oss community. 4.3 testing there is strong evidence that developers have the primary responsibility for testing according to the 93% of the respondents. testing is also left to users on over half of the projects. dedicated individuals for quality and assurance are also identified by over 27% of the respondents. over 42% of the projects are said to have some formal testing procedure. the type of testing carried out is of interest here: nearly 45% of the respondents identified a black box approach to testing, with a similar 40% identifying a white box approach. for unit tests, over 35% of the developers mentioned statement testing, over 21% mentioned path/branch testing, over 17% mentioned loop testing and just under 6% claiming mutation testing. a range of testing techniques are adopted by oss projects. when offered to identify multiple techniques, survey respondents affirmed functional testing is adopted by over 67% of the projects, with some form of system testing by over 42%, regression testing by over 42%, integration testing by just under 39% and acceptance testing by under 19%. over two-thirds of the projects affirmed a continuous schedule for testing, with over a third also claiming pre-release testing. post-release testing was also highlighted by around 10% of the projects. only under a quarter of the projects keep any form of statistical testing for future use and analysis. 4.4 release management clear and consistent release procedures are important if an oss project is to provide a coordinated and timely delivery. our survey reveals over half of the project leaders to have complete release authority with under 20% of the projects also allowing core developers to have authority over release. some projects also identified dedicated release or product managers having release authority. of the projects surveyed, just under 30% release every six months, with 11% releasing every quarter and a similar percentage every year. nearly half of the projects release when ready, with just over 15% releasing on fixed dates, a similar number releasing often and early and only under 10% releasing for fixed features. the decision to release is as important as the frequency: over 55% of our respondents affirmed that core team consensus is the basis for release. almost a third also rely on single release authority’s decision, with a similar number also citing market demands, committers’ consensus proc. opencert 2010 6 / 11 eceasst and zero bug reporting in beta release also as contributing factors. 4.5 tools in this section the most commonly tools identified by the survey respondents are highlighted. this is helpful as it offers some insight into the choice of tools for oss. 4.5.1 version control version control systems are undoubtedly crucial for oss development as they allow management of changes to source code and documents. our survey reveals subversion as the most common version control system used, followed by git and cvs. some other choices are mercurial, bazaar and darcs. only git and mercurial are distributed systems as in providing no central source base and different branches holding different parts of the code. tortoisesvn is the most popular client for those who have affirmed the use of subversion. rapidsvn, textmate svn and kdesvn are some of the other clients identified. 4.5.2 issue tracking issue tracking systems allow individual or groups of developers to keep track of outstanding bugs or issues effectively. mantis, bugzilla and trac are the most popular issue tracking systems identified in our survey. issue trackers provided by sourceforge, google, codeplex and launchpad are also identified. other similar systems mentioned include jira, fogbugz, roundup, zentrack and youtrack, demonstrating a very wide variety of systems in use. 4.5.3 testing tools a huge variety of tools supporting testing are identified in our survey including junit, easymock, phpunit, ctest, dunit, litmus, nosetests, python unittest, qunit, selenium, hudson, buildbot, nunit, mstests, resharper, testdriven, ncover, zope unit testing, ruby unit test, squish (froglogic), nunit, mbunit, gnu autotools, pootle, scalacheck, maven invoker plugin, mytap and gtest. there is no clear pattern for a single most popular tool, perhaps due to the nature of the activity involved. 4.5.4 peer review smart bear code collaborator, fisheye, bugzilla, eclipse and pootle are some of the most popular tools identified. 4.5.5 build system a wide variety of build systems are identified including ant, make, automake, cmake, gnu autotools, tinderbox, hudson, bamboo, nant, msbuild, maven, sbt (scala-based simple build tool), xcode, python setuptools, buildout, buildbot, module::build, rake (ruby), teamcity, pear (php extension and application repository) and eclipse. 7 / 11 volume 33 (2010) the eceasst document class 4.5.6 documentation system the most common documentation system identified in the survey is doxygen, which offers support for both on-line and off-line documentation from a set of source files. other tools identified include epydoc and sphinx (for generating api documentation for python), javadoc (for generating api documentation in html format from source code), sandcastle, docproject, delphicodetodoc, phpdocumentor (phpdoc) and rdoc. 4.5.7 integrated development environment eclipse has been recognised as the most common development platform amongst the community surveyed. other notable tools mentioned include codelite, visualstudio, resharper, quanta html editor, textmate, kate, delphi, lazarus, komodo ide, notepad++, qt creator, vim, emacs, xcode, netbeans, eclipse-pydev and pypapi. 4.6 analysis with over half the respondents having over 5 years of experience with oss, our survey is informed by an extensively experienced group of individuals. with nearly a two-third of the community contribution being as part-time, this reflects on the voluntary yet dedicated nature of participation by the sampled oss community. a majority of the respondents were either project leaders or core developers with a graduate degree. needless to say, most projects claim to have some procedure in place for controlling changes to software and supporting document. most of them allow core developers to commit code with nearly two-third also allowing active developers to commit. this is critical because it implies that any significant changes that need to be brought in to improve developmental processes, would not only require a consent on behalf of the core developers of the project but also depend on their adoption of new practice as well. when it comes to testing, unit testing is most common with a strong focus on functional testing. nearly 50% of the projects are also using some form of documented test cases. this sends a strong hint as to where more rigour and assurance measures could be incorporated in oss development in general. strict and specific testing for critical functionality could be the key here to associate any standard evaluation of the software and any certification that may follow. note that projects that have adopted some formal testing procedure are also the ones where release management is an integral part of the project. it is interesting to observe that nearly all oss projects use an wide range of communication tools and strategies with nearly all having a dedicated website. feature lists, mailing lists, user and developer documentation are some of the other most common mechanisms in use. this demonstrates the need for effective and efficient communication that the disparate set of users employ to contribute to the success of oss. for the purposes of change of developmental practices and adoption of more rigorous means, our survey results offers to identify a starting point. it is the experienced members of the community that are best placed to bring about this change. this may appear counterintuitive as developers who are in set their ways are least likely to be agents of change. the results, however, reveal that it is indeed the most experienced (those with over 5 years of experience) of developers proc. opencert 2010 8 / 11 eceasst who perform peer review, and are responsible for testing on their projects, and have the ability to commit code and authority to release. of those with lesser experience, a very small proportion fall in this category. 5 conclusion the work presented in this paper came out of a desire to understand the oss developer community better and the state of current development practices. the accuracy of the survey results presented in this paper is undoubtedly subject to the survey design and the target population. it serves however to provide a snapshot which is both useful and indicative of further inquiry. the motivation behind this work follows from earlier work [cs08] that encourages a more rigorous approach to software development and testing within the oss community. any such change therefore has to be brought about carefully. the results of this paper serve to highlight a prevailing structure of oss projects, which should be taken advantage of. the leadership for any such initiative should also ideally come from within the community. this will facilitate adoption and better stands to influence the younger and future generations of developers who are to follow. 5.1 future work the target population for this survey has provided with a rich sample of the community some of whom could be targeted for further inquiry. following the survey, we are currently in the process of setting up a shorter follow-up survey to explore the perceptions of formal methods and more rigorous methods alike for adoption by the community. aspects of software modelling and verification, assurance and certification will be explored. we hope to report on the results of this follow-up survey soon. these results will undoubtedly provide us with a platform for more concrete proposals for change. acknowledgements: the authors would like to thank shahida bibi at international islamic university for her assistance with data collection for this paper. bibliography [cs08] a. cerone, s. a. shaikh. incorporating formal methods in the open source software development process. in international workshops on foundations and techniques bringing together free/libre open source software and formal methods (floss-fm 2008) & 2nd international workshop on foundations and techniques for open source software certification (opencert 2008). unu-iist research report 398, pp. 26–34. 2008. [drw03] a. dunsmore, m. roper, m. wood. the development and evaluation of three diverse techniques for object-oriented code inspection. ieee transactions on software engineering 29(8):677–686, 2003. 9 / 11 volume 33 (2010) the eceasst document class [ema01] k. e. emam. software inspection best practices. agile project management advisory service 2(9), 2001. [ere03] j. r. erenkrantz. release management within open source projects. proceedings of the third workshop on open source software engineering, portland, oregon, 2003. [ga04] c. gacek, b. arief. the many meanings of open source. ieee software 21(1):34– 40, 2004. [gbbz03] s. greiner, b. boskovic, j. brest, v. zumer. security issues in information systems based on open source technologies. eurocon, 2003. [hs02] t. halloran, w. scherlis. high quality and open source software practices. 2nd workshop on open source software engineering, international conference on software engineering, pp. 19–25, 2002. [kenu07] g. koru, k. e. emam, a. neisa, m. umarji. a survey of quality assurance practices in biomedical open source software projects. journal of medical internet research 9(2):e8, may 2007. [lau09] launchpad home page. https://launchpad.net/, 2009. https://launchpad.net/ [mfh99] a. mockus, r. fielding, j. herbsleb. a case study of open source software development: the apache server. proceedings of the 22nd international conference on software engineering (icse), los angeles, ca, pp. 263–272, 1999. [mfh02] a. mockus, r. fielding, j. d. herbsleb. two case studies of open source software development: apache and mozilla. acm transactions on software engineering and methodology 11(3):309–346, 2002. [mhp07] m. michlmayr, f. hunt, d. probert. release management in free software projects: practices and problems. ifip international federation for information processing, open source development, adoption and innovation 234:295–300, 2007. [mic05] m. michlmayr. software process maturity and the success of free software projects. software engineering: evolution and emerging technologies 130:3–14, 2005. [mic07] m. michlmayr. quality improvement in volunteer free and open source software projects – exploring the impact of release managemen. phd thesis, university of cambridge, uk, 2007. [omk08] t. otte, r. moreton, h. d. knoell. applied quality assurance methods under the open source development model. ieee 32nd international computer software and applications conference (compsac), pp. 1247–1252, 2008. proc. opencert 2010 10 / 11 https://launchpad.net/ https://launchpad.net/ eceasst [rfl05] j. robbins, h. fitzgerald, s. lakhani. adopting open source software engineering (osse) practices by adopting osse tools. perspectives on free and open source software, pp. 245–264, 2005. [rm02] c. r. reis, r. p. de mattos fortes. an overview of the software engineering process and tools in the mozilla project. workshop on oss development, newcastle upon tyne, uk, pp. 162–182, 2002. [rob02] j. e. robbins. adopting oss methods by adopting oss tools. 2nd workshop on open source software engineering (co-located with 24th international conference on software engineering) orlando, florida, 2002. [sc09] s. a. shaikh, a. cerone. towards a metric for open source software quality. in barbosa et al. (eds.), foundations and techniques for open source certification 2009. electronic communication of the european association of software science and technology (eceasst) 20. 2009. [sca03] w. scacchi. issues and experiences in modeling open source software development processes. in in proceedings of the 3rd icse workshop on open source software engineering. pp. 121–125. 2003. [sca07] w. scacchi. free/open source software development : recent research results and emerging oppurtunities. proceedings of the the 6th joint meeting of the european software engineering conference and the acm sigsoft symposium on the foundations of software engineering, 2007. [sff+06] w. scacchi, j. feller, b. fitzgerald, s. hissam, k. lakhani. understanding free/open source software development processes. software process: improvement and practice 11(2):95–105, 2006. [sou09] sourceforge home page. http://sourceforge.net/, 2009. http://sourceforge.net/ [sta02] j. stark. peer reviews as a quality management technique in open-source software development projects. european conference on software quality, pp. 340–350, 2002. [yk] y. ye, k. kishida. toward an understanding of the motivation open source software developers. proceedings of the 25th international conference on software engineering, pp. 364–374. [ze00] l. zhao, s. elbaum. a survey on quality related activities in open source. acm sigsoft software engineering notes, pp. 53–57, 2000. [ze03] l. zhao, s. elbaum. quality assurance under the open source development model. the journal of systems and software 66:65–75, 2003. 11 / 11 volume 33 (2010) http://sourceforge.net/ http://sourceforge.net/ introduction rest of this paper related work research design results and analysis developer and project profile peer review testing release management tools version control issue tracking testing tools peer review build system documentation system integrated development environment analysis conclusion future work fmis2011huang_et_al_ref electronic communications of the easst volume 45 (2011) guest editors: judy bowen, steve reeves managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 proceedings of the fourth international workshop on formal methods for interactive systems (fmis 2011) capturing the distinction between task and device errors in a formal model of user behaviour h. huang, r. rukšėnas, m.g.a. ament, p. curzon, a.l. cox, a. blandford, d. brumby 16 pages eceasst 2 / 17 volume 45 (2011) capturing the distinction between task and device errors in a formal model of user behaviour h. huang1 (huayih@eecs.qmul.ac.uk), r. rukšėnas1, m.g.a. ament2, p. curzon1, a.l. cox2, a. blandford2, d. brumby2 1queen mary university of london school of electronic engineering and computer science 2university college london, ucl interaction centre abstract: in any complex interactive human-computer system, people are likely to make errors during its operation. in this paper, we describe a validation study of an existing generic model of user behaviour. the study is based on the data and conclusions from an independent prior experiment. we show that the current model does successfully capture the key concepts investigated in the experiment, particularly relating to results to do with the distinction between task and device-specific errors. however, we also highlight some apparent weaknesses in the current model with respect to initialisation errors, based on comparison with previously unpublished (and more detailed) data from the experiment. the differences between data and observed model behaviour suggest the need for new empirical research to determine what additional factors are at work. we also discuss the potential use of formal models of user behaviour in both informing, and generating further hypotheses about the causes of human error. keywords: human error, formal models of human behaviour, cognition. 1 introduction in the complex daily working environment of medical professionals, errors are occasionally made. often these have only minor consequences, but sometimes much more costly outcomes result. recent research, particularly in the field of human-computer interaction, has promoted a shift away from the perspective where blame is attached entirely to the individual when mistakes are inevitably made. this change in perspective has been partly motivated by the realisation that people are not, and cannot reasonably be expected to be, completely infallible. this is especially true in high-stress environments such as the hospital workplace. it is also in these situations that the costs of errors, both financially and in human terms, are often the highest. one way of systematically detecting the potential for these somewhat rare but costly errors is by using plausible models of human cognition. however, the frame problem [mh69] must be dealt with when modelling people. in terms of logical models, this relates to the need to include additional ‘common-sense’ axioms in order to generate plausibly realistic patterns of inference. in the context of modelling cognition in general, it relates to the precise scope, form and amount of common-sense knowledge necessary for a cognitively plausible model. also, when constructing a model of reality hard decisions have to be taken about which aspects of reality are abstracted over and which are represented with relatively high fidelity. to enable the construction of a useful model of human cognition, we need to be clear from the outset about the problem we are trying to solve with the model. here we try to detect systematic medical device errors. in particular the class of errors that may be rare, but are also not completely random. the errors of interest are ones which at least in principle could be capturing the distinction between task and device errors proc. fmis 2011 3 / 17 predicted, a priori, to plausibly occur or reoccur in the future due to systematic cognitive causes. we are concerned most with those errors that have high-cost consequences associated with them. our ultimate aim is to have a system that can highlight design flaws that may lead to such preventable errors. for the purposes of this paper, we define an error simply as an action that deviates from some prescribed sequence for achieving the intended outcome. however, this is only one of several plausible definitions. hollnagel [hol05] gives a more detailed discussion of some of these alternative definitions of error. 1.1 related work in the past, a variety of experimental work has identified some of the causes of human error, such as byrne and bovair’s work demonstrating the effect of working memory on post completion errors (byrne & bovair, [bb97]). here we focus on task and device errors based on the experiments of ament et al. [acbb10]. this particular distinction dates back to various earlier works such as that of cox & young [cy00], kirschenbaum et al. [kgem96] and hiltz et al. [hbb10]. the work presented in this paper is not specifically concerned with generating new experimental results but in supporting such work, as well as creating predictive formal tools that allow deeper explanations for observed human behaviour. in terms of using formal modelling to support empirical work we build on ruksenas et al. [rbcb09] where model checking was used to help understand experimental results about human error and whether all relevant concepts were included in the explanations given. su et al. [sbb07, sbbw09] adopt a similar idea using formal models of low level cognitive concepts related to the attentional blink phenomena. their work differs to ours in being based on lower level aspects of human cognition and on simulation-based model exploration. a simple approach to the modelling of plausible user behaviours involves writing both a formal specification of the device and task models for that device, to support reasoning about the behaviour of the interactive system [md95, fie01]. task models, however, describe only a small fraction of real user behaviour in particular they do not really deal with human fallibility. an alternative approach is to specify users as they are (butterworth et al. [bbd00]). this is the idea underlying alternative approaches to formal user modelling [dd99, dbmd95]. by modelling the user ‘as is’, we can gain many insights into how and why specific user behaviour are generated/observed. to reason about the behaviour of an interactive system, a formal user model is combined with a formal specification of the device. both models are then considered as central components of the whole integrated system in an approach known as syndetic modelling [dbdm98]. ruksenas et al. [rbcb09] present one example of this approach. they model human cognition as a set of production rules expressed in higher-order logic. the generation of the next plausible user-behaviours then involves computing an ‘overall salience value’ for each possible user-action expressed in the model. a key difference between their model and most simulation-based models of human cognition is the underlying assumption of nondeterministic user behaviour throughout. their model operates based upon sets of cognitively plausible user-actions at each point in the interaction. this allows for simultaneous exploration of the consequences of all of the plausible user-actions that could be taken at each point. this contrasts with most simulation-based approaches where only a single path of potential useractions is explored at once. eceasst 4 / 17 volume 45 (2011) ruksenas et al. [rbcb09] also describe a case study based on a fire engine dispatch scenario using their generic user model (gum). we present here a follow-on case study to further validate the model, investigating the behaviour and performance of the model using a different scenario and therefore under a different instantiation. as part of the process, we also gained valuable practical experience and insight into the utility of the iterative model-refinement method suggested by ruksenas et al. [rbcb09]. 1.2 choice of scenario we based this study on the experiment of ament et al. [acbb10]. it presents experimental data about the effect of memory load on device and task based errors. it is based on an experimental micro-world concerned with a doughnut-making task. this context provides a good proving ground for validation and further refinement of the gum as it involves both an independent setting, and the investigation of a different aspect of human error. furthermore the kind of errors considered (device and task based slip errors) fall within the intended scope of the generic model, but were not explicitly designed into it. as noted earlier, the class of errors that we are interested in are systematic deviations from a prescribed action-sequence as a result of slips, rather than say lack of skill or knowledge. in the case of ament et al. [acbb10], the intended outcome was to fulfil orders for doughnuts through following a single prescribed sequence of actions. the errors investigated were deviations from that sequence despite the participants being trained and having demonstrated their knowledge of, as well as ability to do the task. 1.3 research questions and contribution the first question that we address in this paper is whether the gum is currently expressive enough to encapsulate all the concepts relating to human cognition as presented in ament et al. [acbb10]. we investigate the completeness and appropriateness of the current conceptspace as defined in the gum with respect to the concepts addressed in the experiment. our second question concerns the model-checking approach adopted for the gum implementation and whether it agrees with the results of the experiment, assuming the particular conceptual mappings modelled. our initial hypothesis was that the model would be able to replicate the results of the experiment as published concerning the link between device/task-errors and load. the initial aim was thus to provide evidence to further validate the model against these new results, and if it could not, to investigate how the model needed to be improved to capture the underlying behaviour. finally we consider the potential of this model-checking approach to generate both suggestions for further refinement of the model, and to motivate further empirical investigations. the contributions of this paper are essentially two-fold. we explore the results of validating the generic user model on an independent set of experiments not directly designed for this validation. we also demonstrate how the use of formal methods, and model checking in particular, can generate ideas for model refinement and further experimental investigation. 1.4 overview of the paper here we give a brief overview of the rest of the paper. we start by describing the experiment used for validation (section 2) as well as the key concepts of the generic user model (section 3). we then, in section 4, specify the way in which we interpreted the experimental conditions outlined in ament et al. [acbb10]. in particular, we note the assumptions made as part of this capturing the distinction between task and device errors proc. fmis 2011 5 / 17 interpretation process. in section 5, we compare the behaviour of the model with the findings in ament et al. [acbb10], and show that the model demonstrates good agreement with the experiment in terms of distinguishing between task and device errors, as well as distinguishing between initialisation and post completion errors (a sub-categorisation of device errors). we then show, based on previously unpublished results from the experiment, that the model does not however predict initialisation errors correctly at the level of the individual steps. in section 6, model checking is then used to further explore the discrepancies to understand the reasons for the observed model behaviour, leading to suggestions for further experiments. finally, we draw conclusions in section 7. 2 the doughnut machine experiment we first present a brief overview of the experiment used in this validation. due to space constraints we only include the minimum details for understanding the rest of this paper. interested readers should refer to ament et al. [acbb10] for more details. they investigated how working memory load effects task and device-specific actions by using a doughnut-making task. in their paper, a task-specific action is defined as one that is central to the task. in particular it is an action that is perceived to move the participant closer to the completion of the main task. in contrast, a device-specific action is defined as specific to a particular device, and is not typically common to different devices used for carrying out the same task; device actions are not perceived to move participants closer to main-task completion. there were two independent variables in the experiment, memory load which can take values of high or low, and type of action which can be either device or task specific. the four combinations of these two independent variables affected the dependent variable – which was the rate of error for each of the different steps in the action sequence. memory load was varied between participants, and the step-type, either device or task, was varied within participants. each step in the sequence was pre-defined as either a task or device action. on the next page, a screenshot of the main interface is given in figure 2.1, with the corresponding hierarchical task decomposition of the correct sequence of actions for the doughnut task given in figure 2.2. figure 2.2 also indicates the distinction between task and device specific actions used in the experiment. with the coloured rectangles and arrows (6 in all) denoting the steps of the task which were designated device actions, with the rest designated as task actions. the device actions consist of the five initialisation steps (i.e. steps 2.2.1.1.1, 2.2.2.1.1, 2.2.3.1.1, 2.2.4.1.1, 2.2.5.1.1) and a final post-completion step (2.4.1). in this figure, rectangles represent actual actions taken on the device. to successfully complete the task of making the doughnut, the user had to work through the five data entry areas in the prescribed order, shown by subtasks 2.2.1 to 2.2.5 with similar sub-steps for each (corresponding to the five outer areas in figure 2.1, with the user having to select the appropriate radio button from the ‘selector’ area on the right hand side of figure 2.1 before being able to enter the relevant data for each of these subtasks each time). apart from step 2.4.1 (click ‘clean’), mistakes at any of the other steps were immediately pointed out and corrected by the experimenter. the results from the experiments suggest that error rates for device actions are significantly higher than for task actions under both load conditions. additionally, while error rates on the eceasst 6 / 17 volume 45 (2011) task-steps remained low under a high memory load, the error-rates for device-steps increased significantly under a higher memory load as shown in figure 2.3. figure 2.1: the main interface of the doughnut machine. figure 2.2: a hierarchical task decomposition of the actions involved in fulfilling an order (taken from ament et al. [acbb10]). capturing the distinction between task and device errors proc. fmis 2011 7 / 17 figure 2.3: error rates across different working memory load and type of step conditions. error bars represent the standard error of the mean (taken from ament et al. [acbb10]). 3 the generic user model – key concepts in this section we present a short overview of the key concepts in the generic user model of ruksenas et al. [rbcb09]. the idea behind this approach is to try to encapsulate cognitive principles that are common to all device interactions within a generic parameterisable framework, which can be instantiated for particular scenarios. the ultimate aim is to create a predictive model that enables us to reason about plausible user behaviour with any arbitrary device. the generic user model consists of five principal parameters, as described below. procedural cueing: this parameter primarily deals with the idea of habitual cueing, i.e. that of a particular action following from the previous one. it also includes other kinds of unconscious or ‘learnt’ sequences of behaviour due to past experience. in general, this kind of cue could be either due to prior instruction from a third party, and/or due to past usage or experimentation by the user; it deals primarily with the (unconscious) sequential ordering of task-steps. cognitive cueing: this parameter deals with actions that spring to mind due to the importance of the action for successful task completion. for example, an action central to the successful completion of the main task would typically have a relatively high cognitive cue. sensory cueing: this parameter represents cueing derived from sensory sources. it currently represents the combined influence of all of the five senses. examples of relevant sensory cues include visual interface aspects such as using colour to highlight particular actions (like a big red button for aborting the task for example), or the use of sound to draw attention to an action. intrinsic load: this parameter is related to the inherent ‘difficulty’ of a task or action. for example, doing difficult mathematical calculations as a task-step would have a much higher intrinsic load than multiple-choice check boxes. extraneous load: this parameter covers ‘external’ influences of the context in which the task is taking place. this includes concepts relating to memory load, and other interfering aspects of the external environment, such as from a visually or acoustically complex environment. eceasst 8 / 17 volume 45 (2011) salience to determine the next set of actions taken by the model at some specific point in an unfolding scenario, the five ‘raw’ parameters outlined previously are ‘summed’ via a production-rule system to derive an associated salience value for each of the potential next user-actions. for details of the actual rules see curzon et al. [crb10]. figure 3.1 shows the functional relationship between these cues and loads, and the overall salience. for example, in the current model, procedural salience is affected only by procedural cueing and the intrinsic load of a task or action. intermediate ‘grouping’ concepts (procedural, cognitive and sensory salience) give a way for the model to be at a relatively high level of abstraction. it also improves the ease with which the model may be understood conceptually. in addition, these three intermediate concepts are used as a means for the model to be context-sensitive. figure 3.1: how the ‘raw’ parameters influence the overall salience of a user-action, via the three intermediate concepts. the arrows show the direction of influence. 4 interpreting the experimental conditions in terms of the gum in this section, the way in which we interpreted the experimental conditions is described. we discuss the rationale behind our particular interpretation, as well as stating the assumptions made. 4.1 concept mapping of the five principal parameters in order to carry out a detailed comparison between the experimental data and the gum instantiation, it was necessary to decide precisely how to map concepts from the experiment to our instantiation. we now present in detail our interpretation of the concepts and experimental context discussed in ament et al. [acbb10]. note that these five principal parameters in the gum are currently assigned values from a binary range. procedural cueing was assumed to be initially present (i.e. set with a ‘high’ value) between all pairs of actions in the prescribed (‘correct’) action sequence only. this reflected the fact that each of the users had prior instruction, as well as a period of guided exploration before the actual experiment. data from a small number of users was also excluded from the analysis presented in ament et al. because they had not learnt the task well enough, reinforcing the fact that those whose data was used were indeed trained to follow the correct sequence. in both the paper and the modelling presented here, we are interested only in slip errors with an capturing the distinction between task and device errors proc. fmis 2011 9 / 17 identifiable underlying cognitive cause, not ones occurring as a result of lack of knowledge or skill. all other pairs of actions were assigned ‘low’ procedural cueing values. the task/device-action distinction of ament et al. was represented by the cognitive cueing parameter of the generic user model. a weak value was given to the device-specific actions whilst a strong one was given to task-specific actions; actions relating specifically to the task at hand were deemed to have a higher cognitive salience than ones that are only incidental actions required by the specific device. we mapped this concept according to their task/device classification observed in the hierarchical task decomposition presented in figure 2.2. due to the relatively bland nature of the doughnut machine interface, the values set for sensory cueing were based essentially on only positioning and size. only two kinds of actions were defined with strong sensory cues. the steps that involved filling in data (steps 2.2.1.2.1 in figure 2.2, for example) were given strong sensory cueing due to their relatively large size. we, and ament et al. both group the individual interface elements where the data was actually entered holistically into one atomic action. secondly, the final confirmation step (after the doughnuts were made) was given high sensory cueing, as this was a typical popup modal dialog box, which allowed the user to proceed with other actions only after its dismissal. all other actions were defined with a weak sensory cue. for intrinsic load, only the subtasks involving some mental arithmetic were assigned a high load value. this was due to the relatively more complex data entry steps within the dough-port and fryer-port subtasks (see figure 2.1). all other subtasks were defined with a low intrinsic load. the variation in memory load was reflected in the model instantiation by varying the values for extraneous load. a high value (rather than a low one) corresponded to the high memoryload situation, where the user was required to actively monitor additional secondary information fading in and out on the horizontal panel near the bottom of the screen whilst carrying out the main task (see bottom of figure 2.1). 4.2 concept mapping – task grouping the gum provides a facility for grouping individual user-goals into larger collections of mini-tasks. for our instantiation, the three steps taken within each port (i.e. activate / fill / confirm) were grouped into mini-tasks, one for each of the five ports. the remaining user actions were grouped into a sixth collection. these groupings have some influence on the selection process for the next set of actions at each step – mainly by affecting cognitive cue levels. however this is not a major aspect of the model. although we had decided on the groupings reasonably independently, the configuration eventually chosen do roughly match the hierarchical task-decomposition presented in figure 2.2. 4.3 other assumptions several other assumptions were made. we modelled the system as though there was no potential for errors or mismatches relating to the user’s direct perception of the effects of visible device actions. we also assumed that there were no misinterpretations in their perception of the effects of their actions on the device. this does not rule out all misunderstandings of a user, it simply means that we model that when they press a button, that button is always actually pressed according to expectations, and perceived as such. however, the user model can still potentially end up with ‘misconceptions’ relating to the internal state of the device. the assumption about the user’s perception was deemed appropriate because the eceasst 10 / 17 volume 45 (2011) doughnut machine is quite a simple device and the participants were trained in its use, so there is unlikely to be misunderstandings about the role of each interface element. a further assumption was that once defined for the instantiation, the particular pattern of parameter assignments would not be subject to arbitrary dynamic alterations. this reflects the fact that the experiment was carried out under strictly controlled circumstances – so there were no unexpected mid-experiment perturbations to the environment, caused by events such as disruptions etc. we also assumed that in general, users would try to make full use of what few interface cues were available. we therefore took a strictly minimalist position with respect to the necessity of adding extra ‘memory variables’ for the user model, assuming no additional complexity regarding user-memory unless absolutely necessary. 5 results in this section, an analysis of the behaviour obtained with this instantiation of the gum is presented. we start in section 5.1 by comparing with the experimental data in terms of task and device-specific actions only, and determine whether the results of the model match the conclusions of ament et al. [acbb10]. in section 5.2 we look in more detail at the two specific kinds of device errors observed, notably initialisation and post-completion errors. this is followed by a more detailed step-by-step analysis in section 5.3 comparing the results from the model against more detailed, previously unpublished data from the experiment. this allowed a more fine-grained analysis of the model’s performance. all results presented here were obtained by following the interpretation of experimental concepts and conditions outlined in section 4. 5.1 task versus device errors the original research question we set out to answer was whether our model replicates the behaviour as exemplified in the conclusions of ament et al. [acbb10]. their primary conclusion was that error rates were significantly higher for device actions than task actions. we address this first. the gum is intended to predict only errors that are systematic, i.e. errors that have some underlying cognitive cause, and are not random, one-off errors. furthermore the model is an abstraction of the actual underlying causes. it therefore works at a certain level of detail. the idea is for the model to highlight plausible situations where design error is likely to be the cause. it is essentially a binary threshold model however, so does not rank erroneous actions in terms of probabilistic estimates of likelihood. rather, either the model can make an error in a given situation or it cannot. ament et al. [acbb10] found that under both memory load conditions, device errors were significantly higher than task errors. therefore the model ought to (in the first instance) be able to correctly predict that these errors are possible in systems such as the doughnut machine. the results of the model checking are summarised in table 5.1. we can see that the model makes device errors under both load conditions and makes task errors in neither. thus it predicts that device errors will be made, and predicts that a significant number of task step errors will not be made. this matches the main conclusion of ament et al. [acbb10]. the threshold nature of the model means that it does not make the further distinction as drawn by ament et al. that a higher memory load leads to more errors. whatever the load, devices errors capturing the distinction between task and device errors proc. fmis 2011 11 / 17 are made, so a predictive tool needs to highlight this. for a real system (rather than an experimental one as in this case), the system design ought to then be fixed accordingly. figure 5.1: our interpretation of the behaviour to expect from the model. task-specific actions device-specific actions low load no error made by model √ some errors made by model √ high load no error made by model √ some errors made by model √ table 5.1: comparison of the model’s behaviour with the experimental results (√ indicates model behaviour matches experimental result) 5.2 initialisation errors and post completion errors the previous section shows that our model can indeed capture the device and task distinction, and make the appropriate predictions at this level of granularity. however, this categorisation potentially groups together a number of different kinds of errors. those errors are actually made due to different rules of the model activating. in particular, both initialisation errors and post completion errors fall under the grouping of ‘device-specific’ errors. ideally, as well as predicting the potential for error, the model should suggest how the system design might be fixed. it is therefore important not just that the model can match the results in general, but that it is able to also accurately predict the particular kind of device errors made. we therefore now focus on a more fine-grained analysis with respect to the specific kinds of device errors made, to gain a more detailed understanding of the validity of the behaviour of our model. the device errors identified by ament et al. [acbb10] compose of post completion, as well as initialisation steps. they put the overall error rate for initialisation steps at just over 27%; the post completion error rate was also found to be high at over 21%. ideally the model should therefore predict both post completion errors and initialisation errors, not just one or the other, allowing them both to be predicted and fixed. post-completion step initialisation steps all load conditions error made by model √ some errors made by model √ table 5.2: the model’s behaviour for post completion errors and initialisation errors (√ indicates model behaviour matches experimental result) as indicated in table 5.2 the model does predict both that post completion error and initialisation errors will be made. thus at the level of the kind of device error made, the model’s behaviour does match the behaviour as seen in the experimental data. however, as eceasst 12 / 17 volume 45 (2011) will be discussed in the next section, the model does not predict initialisation errors in detail as might be expected. further work is needed to investigate the underlying causes of those errors and how they may be modelled. it is also important to note here that what is meant by an ‘initialisation’ step in table 5.2 is any one of the five selection steps before filling in the data for each of the five areas shown in figure 2.1. this is the same concept as the ‘selector errors’ described in hiltz et al. [hbb10]. 5.3 a step-by-step analysis whilst the previous results show the model does match the experiment at the level of deviceerror types, there are actually several points in the experiment for initialisation errors to be made. in the paper a distinction is made for the error rate for the first initialisation step (with an error rate of about 27% and the later ones with a combined error rate of about 7%). this does not correspond to the pattern predicted by the model checker as we now discuss. the analysis in this section is based on previously unpublished data from the experiment that gives error rates for each individual step in the doughnut scenario. whilst conducting this more detailed analysis, it was observed that the model demonstrated the same pattern of behaviour under both low and high extraneous load, given the particular way in which we interpreted the experimental conditions for our model. we therefore do not further consider the effect of load here. more detailed investigation of this is left for further work. figure 5.2 gives the step-by-step error rates, showing the correspondence between the steps and the specific actions available on the device as given in the hierarchical task-decomposition of figure 2.2. the distinction between device and task errors here is that adopted by ament et al. [acbb10]. the data available groups some steps. for example the four individual actions in the task hierarchy relating to obtaining a new order are grouped together (i.e. subtask 1 in figure 5.2). figure 5.2: step-by-step error rates for the task. this shows a much more nuanced picture of the position and magnitude of initialisation errors. all task errors have very low error rates largely justifying the results of the previous capturing the distinction between task and device errors proc. fmis 2011 13 / 17 sections. three goal steps are, while still low, noticeably higher. the first step to get the order for example is just below 5%. however, this may be explained by the fact that it combines four steps. the step to enter the data when doing the ‘operate doughport’ part of the task also has an error rate of around 5% as does the step between subtasks 2.2.1 and 2.2.2 (this step is simply being patient enough to wait for a progress bar to fill). looking at the initialisation errors a more intriguing pattern emerges. there are 5 opportunities for initialisation errors. however the errors are not spread evenly between them. the initialisation step for the first ‘operate doughport’ activity is much higher than the others with a 35% error rate. the other initialisation steps all do have errors but these are at much lower levels of between 5% and 10%. thus in some cases the error rate is barely above the level that might be expected if the errors were stochastic. clearly, from error rates alone, there is little to distinguish between the later initialisation steps (which the model predicts to be error prone) and the other task based steps (which the model does not predict to be error prone). furthermore the model, with the settings we gave, only predicts initialisation errors on the first step of subtask 2.2.2. it does not predict errors on the first or later initialisation steps despite the first initialisation step having an extremely large error rate in the experiment. this suggests either problems in the model or our understanding of the experimental conditions and how they should be mapped to our model. the model ought to at least predict that the first initialisation step is error-prone, and possibly the later ones too. given the discrepancy with the data in figure 5.2, perhaps the model needs a more sophisticated mechanism to determine when initialisation errors occur. further investigation is needed to better understand the underlying causes of these error steps. we use the formal user model to explore these issues in more detail in the next section. 6 further exploration of the results in this section, we further explore the formal model and its relation to the experimental results. the particular examples investigated were motivated by the mismatch in behaviour between model and experimental data, as described at the end of the previous section. we deal first with the mismatch at the second of the five initialisation steps (section 6.1), and then investigate the mismatch at the first of these steps (section 6.2). finally we discuss some issues raised by this extended investigation (section 6.3). 6.1 presence of errors at the activate-puncher step but not at the other initialisation steps first we investigate the reasons behind the model making an omission error at the activatepuncher step (the ‘operate puncher’ activity’s initialisation step) but not at the other initialisation steps. the activate-puncher step corresponds to the first step of subtask 2.2.2 in figure 2.2. some errors were made at all initialisation steps but mostly at a low level, suggesting that the underlying causes for an error here were weak compared to the first initialisation step, at least within the conditions of the experiment as modelled. we suspected that the reason that the model demonstrated this behaviour was due to the high level of intrinsic load at the previous step prior to the activate puncher step – i.e. when the confirm-doughport step was executed by the user. the previous subtask was set to a high intrinsic load as the user had to do a series of simple, but different arithmetical calculations to determine the values to actually enter. it was not entirely clear at the outset whether this was complex enough to be considered as a high load or not, though in the original instantiation of eceasst 14 / 17 volume 45 (2011) the scenario we decided to set these kinds of steps to high. intrinsic load for the other subtasks were low. giving the previous subtask a high intrinsic load caused a reduction in the procedural cueing for the ‘activate-puncher’ step, and therefore reduced the overall salience of this initialisation step. this meant that both the ‘activate’ and ‘fill’ steps of the puncher port ended up with the same level of overall salience in the model. as such they were both plausible actions for the model to choose next at this point of the doughnut task. this understanding was confirmed formally by using linear temporal logic properties to model-check a slightly adjusted instantiation. the only change from the initial interpretation of settings was the assignment of a low rather than a high intrinsic load value to the subtask prior to activating the puncher-port. as expected, there were now no errors for this step of the model under the new setting. this same model behaviour was observed under both high and low extraneous loads. 6.2 no error at the activate-doughport step the second, and more major issue given that it had by far the highest error rate, is why the model did not predict errors at the activate-doughport step. this was the very first sub-activity initialisation step (the first step of subtask 2.2.1). this seemed likely to be due to the strong influence of procedural cueing upon whether an action is considered plausible or not when, as in this scenario, the sensory cueing for most cues is set to neutral values. in this case sensory cueing effectively did not contribute towards determining model behaviour. when we verified this formally by removing the procedural cueing between the initial buttonpress to get the next order, and the activate-doughport step, we found that the model demonstrated the same kind of behaviour as initially seen for the activate-puncher step (again under both high and low extraneous load, refer to section 6.1 for details). without procedural cueing the model predicts the potential for an omission error at this step. this would bring the model-behaviour into closer correspondence with the experimental results. 6.3 discussion from the more detailed results described in sections 6.1 and 6.2, we see that the model does not exactly match the experimental data with respect to initialisation errors with the initial settings we chose, though the model could have done so with different settings. in the experiment initialisation errors were made at every initialisation step, though the error rates differed. except at the first, rates were relatively low. the original experiment was not explicitly set up to explore the causes behind differing error rates at the initialisation steps of the activities, so this was an unexpected result. given the low error rates, further experimentation explicitly designed to determine the causes of such errors is needed. the model checking work however suggests interesting areas for further work. the most obvious failure of the model checking was that it did not predict an error on the first initialisation step when in fact the error rate at this point was extremely high. further exploration and verification of the model shows that by removing the procedural cueing between each of the major activities (as indicated in the task hierarchy) the model would predict initialisation errors at each step. if the task hierarchy is an arbitrary structure imposed as a way to describe the task, there doesn’t seem to be any strong motivation to do this instead of the original interpretation of a single procedural chain for the prescribed sequence. however, the fact that errors are made at each step, even if at a low level for most, suggests that the way a person mentally breaks a task into activities as guided by training and/or the capturing the distinction between task and device errors proc. fmis 2011 15 / 17 interface may play a role. including procedural cueing only within major activities according to likely conceptual models of users would be one solution. however, there is clearly something distinctly different about the first activation step compared with the other four activation steps. there is clearly some kind of discrepancy here. amongst other possibilities, it could mean there is some sort of concept representing interactivity cueing that is not expressed in either the current model or the experimental concepts presented in ament et al. [acbb10]. in fact, in parallel to the work described here, we have been developing a more nuanced version of the gum based around activities and resources, where a new kind of cueing between activities, weaker than the procedural cueing within activities, is explicitly modelled. this will allow us to explore the potential for such a mechanism to model these results. further experimental evidence to give more detailed insight into the precise scope and nature of the phenomena observed is needed too. as the model checking shows, the model predicts initialisation errors when the previous activity was of high intrinsic load, but not, all else being equal, when the previous load was low. an issue was how complex the activity needed to be for the load to trigger initialisation errors. for this kind of modelling to be useful in a purely predictive sense, guidance on how to make such decisions would be needed. this suggests an alternative way to use the model, however. where one could take a scenario-based approach – modelling various load levels and exploring, for a given design, the effects of those different load levels on the errors that occur in the model. this could suggest crunch points where designers should aim to keep intrinsic load levels low, or the design changed to avoid offering device-specific actions at those points. the results of this study suggest that the abstraction needed for modelling of intrinsic loads of various actions is perhaps not quite as straightforward as thought from previous empirical data. experiments to investigate this kind of load in more detail and its interaction with procedural cueing are needed to clarify its effect in a wider variety of situations. in addition, for the model having a high (instead of low) intrinsic load at a prior step with procedural cueing from it has the same effect as having a low intrinsic load without procedural cueing. it would be interesting to find out whether this correlation does indeed hold in reality. further experimentation is also needed to explore the causes behind the relatively small number of task step errors. if these also had a common cognitive cause that could be determined, then the model could be expanded accordingly to also take those causes into account. 7 conclusions we have presented a study that aimed to further validate an existing generic user model, based on new experimental data that was not related to the original development of the model. we also aimed to investigate how model checking can help explore issues that arise, helping to suggest areas for further empirical data collection. the work in this paper suggests that the generic user model is conceptually complete with respect to the experiment as presented in ament et al. [acbb10]. we were able to map naturally all of the concepts presented in the empirical investigation into concepts in the gum. there were no ‘leftover concepts’ from the empirical experiment that needed to be somehow ‘fitted’ to a concept in the model in an awkward or superficial way. secondly, taking the initial interpretation of the experimental settings, we arrive at a situation where the model also demonstrates a definite distinction between task and action steps. in terms of the gum, we obtain errors on device-specific actions and no errors for task-specific eceasst 16 / 17 volume 45 (2011) actions. in terms of the empirical experiments, we see a result that demonstrates both the predominance of device errors over task-specific ones, as well as a greatly increased sensitivity to memory load for device-specific error rates. the presence of a clear difference between task and device-actions in both cases provides some positive evidence for the general approach assumed for the gum, and also gives some additional justification for the utility of classifying user-actions according to task and device-specific actions. more detailed analysis however suggests that some concepts are perhaps missing from the description in ament et al. [acbb10] and the generic user model. in particular, the specific pattern of errors observed on a step-by-step basis, especially with respect to initialisation errors, is apparently subtler than currently expressible using only concepts from the experiment. further work the results from our study indicate that it would be useful to further investigate the precise relationship between intrinsic load and procedural cueing. in particular, in the generic user model they have opposite effects. the same local space of plausible actions could be achieved either by inhibiting the effect of procedural cueing from the previous step (with a high intrinsic load from the previous step), or by simply having no procedural cueing at all at that point in the action sequence. further collaboration between experimentalists and modellers to investigate this issue is needed. for example, interesting plausible parameter sets could be determined initially by experimenting with the generic user model, and then used for further investigation via empirical experimentation. alternatively, if the experimenters were unclear about whether to investigate some particular value of a parameter, the gum could be used to offer some rational suggestions about whether those values are likely to have a significant effect on the overall user-behaviour. while the classification of actions into task and device-specific types is relatively uncontested in this paper, the particular choice of assignments to be used still depends very much on context. for example, hiltz et al. [hbb10] explores how giving them an alternative initial brief can change people’s perceptions about which actions are task-orientated and which are more device-orientated. instead of talking about making doughnuts as their main task, another group of subjects were told that their main job was to instead test the virtual doughnut machine. as a result, these participants demonstrated significantly less errors on the initialisation steps compared with the group operating under the original ‘making a doughnut’ brief, most probably due to their reconceptualising of previous ‘device-specific’ steps now as task-specific. a potentially very useful follow-up to the study presented in our paper would be to investigate the degree of agreement between model and data under these two alternative perceptual schemas based on concepts and data from hiltz et al. [hbb10]. in summary, this paper has investigated the validity of an existing generic formal model of cognitively plausible behaviour against data from an independent experiment that was not designed with our model in mind. we have shown that the model does sufficiently capture the concepts described in ament et al. [acbb10], and agrees with its conclusions with respect to device and task errors in general. at a more detailed level however, some behaviours demonstrated by the model do not match the experimental results regarding initialisation errors and the effect of procedural cueing and load. the resulting analysis suggests that additional concepts are needed in the model, as well as further experimental work to determine more precisely the fundamental principles behind the behaviours observed. our work also suggests capturing the distinction between task and device errors proc. fmis 2011 17 / 17 that model checking based on a formal model of cognitively plausible behaviour may help both to explore the results from empirical investigations, as well as generate further research questions of interest. acknowledgements this work is supported by the epsrc grants on ‘extreme reasoning’ (ep/f02309x/1) and ‘chi+med: safer medical devices’ (ep/g059063/1). references [acbb10] m. ament, a. cox, a. blandford, d. brumby. working memory load affects device-specific but not task-specific error rates. in ohlsson and (eds.) catrambone (eds.), cogsci10, 32nd annual conference of the cognitive science society. pp 91–96, 2010. [bb97] m. d. byrne, s. bovair. a working memory model of a common procedural error. cognitive science 21(1):31–61, 1997. [bbd00] r. butterworth, a. blandford, d. duke. demonstrating the cognitive plausibility of interactive system specifications. formal aspects of computing 12(4):237–259, 2000. http://eprints.ucl.ac.uk/5127/(accessed 22-9-2011) [crb10] p. curzon, r. rukšėnas, j. back. the hum generic user model: an informal overview of the main features. chi+med working paper no. 9, 2010. http://dms.chi-med.ac.uk/knowledgetree/browse.php?ffolderid=30(accessed 22-9-2011) [cy00] a. l. cox, r. m. young. device-oriented and task-oriented exploratory learning of interactive devices. in proceedings of iccm 2000: third international conference on cognitive modeling. pp 70–77, universal press, 2000. [dbdm98] d. duke, p. barnard, d. duce, j. may. syndetic modelling. human-computer interaction 13(4):337–393, 1998. doi: 10.1207/s15327051hci1304_1 [dbmd95] d. duke, p. barnard, j. may, d. duce. systematic development of the human interface. second asia-pacific software engineering conference, pp 313-321, computer society press, 1995. doi: 10.1109/apsec.1995.496980 [dd99] d. duke, d. duce. the formalization of a cognitive architecture and its application to reasoning about human computer interaction. formal aspects of computing 11(6):665-689, 1999. http://dblp.uni-trier.de/db/journals/fac/fac11.html#duked99(accessed 22-9-2011) [fie01] r. e. fields. analysis of erroneous actions in the design of critical systems. phd thesis, university of york, york, 2001. [hbb10] k. hiltz, j. back, a. blandford. the roles of conceptual device models and user goals in avoiding device initialization errors. interacting with computers 22(5):363-374, 2010. doi: 10.1016/j.intcom.2010.01.001 [hol05] e. hollnagel. the elusiveness of ‘human error’. technical report, based on hollnagel, e. & amalberti, r. the emperors new clothes, or whatever happened to “human error”? invited keynote at the 4th international workshop on human error, safety and system development, 2005. http://www.ida.liu.se/~eriho/humanerror_m.htm(accessed 229-2011) [kgem96] s. s. kirschenbaum, w. d. gray, b. d. ehret, s. l. miller. when using the tool interferes with doing the task. in conference companion on human factors in computing systems: common ground. chi ’96, pp. 203–204. acm, new york, usa, 1996. doi: 10.1145/257089.257281 [md95] t. moher, v. dirda. revising mental models to accommodate expectation failures in human-computer dialogues. in design, specification and verification of interactive systems (dsv-is’95). pp 76-92, 1995. [mh69] j. mccarthy, p. j. hayes. some philosophical problems from the standpoint of artificial intelligence. in machine intelligence. volume 4, pp 463–502, edinburgh university press, 1969. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.85.5082(accessed 22-9-2011) [rbcb09] r. rukšėnas, j. back, p. curzon, a. blandford. verification-guided modelling of salience and cognitive load. formal aspects of computing 21(6):541-569, 2009. doi: 10.1007/s00165-008-0102-7 [sbb07] l. su, h. bowman, p. barnard. attentional capture by meaning: a multi-level modelling study. in proceedings of the 29th annual meeting of the cognitive science society (cogsci 2007), lawrence erlbaum associates, nj, pp 1521-1526, 2007. http://www.cs.kent.ac.uk/pubs/2007/2594(accessed 22-9-2011) [sbbw09] l. su, h. bowman, p. barnard, b. wyble. process algebraic modelling of attentional capture and human electrophysiology in interactive systems. formal aspects of computing 21(6):513-539, 2009. doi: 10.1007/s00165008-0094-3. preface electronic communications of the easst volume 3 (2006) proceedings of the third workshop on software evolution through transformations: embracing the change (setra 2006) preface jean-marie favre, reiko heckel and tom mens 2 pages guest editors: jean-marie favre, reiko heckel, tom mens managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst preface jean-marie favre1, reiko heckel2 and tom mens3 1 universite grenoble 1, france, jean-marie.favre@imag.fr 2 university of leicester, uk, reiko@mcs.le.ac.uk 3 université de mons-hainaut, belgium, tom.mens@umh.ac.be abstract: transformation-based techniques such as refactoring, model transformation and model-driven development, architectural reconfiguration, etc. are at the heart of many software engineering activities, making it possible to cope with an ever changing environment. this workshop, held as satellite event of the 3rd international conference on graph transformation (icgt 2006) in natal, rio grande do norte, brazil on 22nd september 2006, provided a forum for discussing these techniques, their formal foundations and applications. keywords: software evolution, model and program transformation, graph transformation, term rewriting since its birth as a discipline in the late 60ies software engineering had to cope with the breakdown of many of its original assumptions. today we know that it is impossible to fix requirements up front, the design of the system is changing while it is being developed, the distinction between design time and run-time is increasingly blurred, a system’s architecture will change or degrade while it is in use, and technology will change more rapidly than it is possible to re-implement critical applications. this recognition of lack of stability in software means that we have to cope with change, rather than defending against it. processes, methods, languages, and tools have to be geared towards making change possible and cheap. transformations of development artifacts like specifications, designs, code, or run-time architectures are at the heart of many software engineering activities. their systematic specification and implementation are the basis for a wide range of tools, from compilers and refactoring tools to model-driven case tools and formal verification environments. the workshop provides a forum for the discussion transformation-based techniques in software evolution. papers present in these proceedings cover a range of artifacts and formalisms of transformations, from program to model transformation and from xslt to term and graph rewriting. they address activities like model-driven development, model and code refactoring, model merging and consistency management, requirements evolution, and run-time evolution of web service processes. an invited presentation by michael löwe addressed the refactoring information systems using techniques based on graph transformation and category theory. the final discussion focused on the pros and cons of graphand tree-based models for the transformation of programs, which are not obviously graphical in structure. 1 / 2 volume 3 (2006) mailto:jean-marie.favre@imag.fr mailto:reiko@mcs.le.ac.uk mailto:tom.mens@umh.ac.be preface acknowledgements: the workshop was supported by the european research training network segravis on syntactic and semantic integration of visual modelling techniques, the integrated project sensoria on software engineering for service-oriented overlay computers, and the ercim working group on software evolution. we are indebted to the following program committee for assisting us in reviewing and selection of papers. • luciano baresi, politecnico di milano, italy • thaı́s batista, federal university of rio grande do norte, brazil • paulo borba, universidade federal de pernambuco, recife, brazil • artur boronat, universidad politécnica de valencia, spain • christiano de oliveira braga, universidad complutense de madrid, spain • andrea corradini, università di pisa, italy • mohammad el-ramly, university of leicester, uk • jean-marie favre, universite grenoble 1, france [co-chair] • reiko heckel, university of leicester, uk [co-chair] • dirk janssens, university of antwerp, belgium • tom mens, université de mons-hainaut, belgium [co-chair] • anamaria martins moreira, universidade federal do rio grande do norte, natal, brazil • leila silva, universidade federal de segipe, brazil • german vega, universite grenoble 1, france february 2007 jean-marie favre, reiko heckel and tom mens organisers proc. setra 2006 2 / 2 a visual language for temporal specifications based on spider diagrams electronic communications of the easst volume 41 (2011) proceedings of the tenth international workshop on graph transformation and visual modeling techniques (gtvmt 2011) a visual language for temporal specifications based on spider diagrams paolo bottoni, andrew fish 14 pages guest editors: fabio gadducci, leonardo mariani managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst a visual language for temporal specifications based on spider diagrams paolo bottoni1, andrew fish2 1 dipartimento di informatica, “sapienza” università di roma, italy, 2school of computing, engineering and mathematics, university of brighton, uk abstract: spider diagrams are a well-established visual language to specify sets, their relationships, and constraints on their cardinalities. however, they do not support evolution of specifications, where one wants to state that under certain circumstances a specification becomes invalid and a new one must be used, nor transformation of specifications, where one needs operators to manipulate specifications. in this paper, we attack the first problem by developing a new system of timed spider diagrams which allow modellers to indicate the temporal range of validity of a specification. the approach is illustrated with examples of policies for library management. keywords: visual constraint language, time based systems, spider diagrams. 1 introduction spider diagrams (sds) are a diagrammatic logical specification and reasoning system built on top of euler diagrams (eds), suitable for expressing monadic first order logic with equality statements [stht04]. constraint diagrams [ken97, ffh05] are an extension of sds which are more expressive (introducing explicit syntax for the expression of quantification and relations), but come with the trade-off of more complexity in interpretation. they were proposed as a means for expressing constraints within software system modelling, potentially as a replacement for the textual object constraint language (ocl) within the unified modeling language (uml). these diagrams can be used to specify static constraints over the model such as a system invariant, or behavioural specifications in the form of pre and post-condition contracts. an advantage of using diagrammatic constraint languages is that users become able to display a logical proof as a sequence of diagrams, thereby enhancing confidence in its correctness. however, these languages lack an explicit model of system evolution, as no notion of dynamics has been incorporated within them. in particular, time is not a primitive notion in sds, so that time-dependent specifications are not directly definable. we develop here a diagrammatic system, called timed spider diagrams that incorporates temporal constraints expressed as intervals over a time model based on calendars with reference to some granularity layering, e.g. hours, days, weeks. intervals can span between some exact moments in calendar time, or define a duration from an onset. this facilitates the specifications of time-related policies, where some system state is required to last for some specific time and to be followed by some other state, again possibly with some specified duration. in particular, we develop the framework for a diagrammatic system, called timed spider diagrams that enables the visualisation of temporal 1 / 14 volume 41 (2011) timed spider diagrams constraints by annotating spider diagrams with temporal constraints on their validity, and discuss its properties. we provide a semantics for timed sds based on a natural representation of the evolution of the state of a system over an interval as a sequence of snapshots and use such a representation to check the consistency of policies specified through several diagrams, possibly presenting overlapping intervals. besides developing the basis for such definitions, we use them to check if a diagram over an interval in a timed-sd-sequence is a valid instance of a model, or if it is a valid deduction from some such instance (exploiting standard inference figures for sd, as for example those in [hst05]). the proposed model can also be used to derive transformation rules from policies, to simulate the behaviour of processes complying with them, thus allowing both a static and a dynamic analysis of a specification. this opens new avenues of research, such as: (i) the expansion of diagrammatic logic results into a temporal setting; (ii) the translation of the underlying model of the temporal constraint language into a graph transformation setting. in what follows, section 2 introduces new notions of sd-specifications and instances used for modelling, their interpretations and the notion of an sd-instance satisfying a sd-specification. we introduce concepts related to intervals and interval specifications in section 3, and introduce timed-sds in section 4, providing a notion of sd-stories and semantics of timed-sds in terms of sd-stories. finally, section 5 discusses related work, whilst section 6 draws conclusions. 2 specialisation of sds for modelling purposes we adopt a variant to a standard definition of sds and of their interpretation (see [hmt+01, hst05]), providing a more direct relation of sds to modeling in object-oriented terms. a (concrete) ed is a collection of (labelled) simple closed curves in the plane, called contours, decomposing it into connected minimal regions. a zone is a region inside one set of contours and outside all the other ones; zones may be shaded. a (concrete) sd is an ed together with extra syntax for spiders. these are trees whose vertices (called feet) are placed in zones, with no two vertices of the same tree lying within the same zone. all diagrams have a “boundary contour”, drawn as a rectangle and labelled by u (the universe of discourse); all regions are then inside u . a concrete diagram represents logical statements according to the following intuitive semantics. the interior of a contour represents a set (corresponding to the label) and the regions formed by taking intersection, union and complement of regions represent the result of the corresponding set operations. spiders represent elements in the sets determined by their habitat (the smallest region containing the spider). distinct spiders represent distinct elements. shading places upper bounds on the cardinality of sets: there are no more elements in the set represented by a shaded zone than the number of spider feet touching that zone; a shaded zone without feet touching it represents an empty set. a single diagram is called unitary. unitary systems can be extended to compound systems, allowing standard logical connectives between diagrams. figure 1 shows an example of two unitary spider diagrams used for static constraint specification; taking the two diagrams in conjunction would yield a compound diagram. together they state that the set of users of a library is formed of individuals of two different types: reader and admin. a reader can be in a state of active, suspended or banned and active readers may be in only two states: either they have some loan in place, or they are considered idle. a different type of user, the administrator, is always active, without ever being in a state withloan or isidle. proc. gtvmt 2011 2 / 14 eceasst active admin suspended banned reader withloan isidle active reader admin figure 1: an example of two sd-specifications, stating two policy rules for a library. definition 1 let c and s be disjoint sets of labels. a unitary spider diagram d on l = c ∪s is a tuple (c,z,sh,s,h) such that: c is a set of curve labels drawn from c , with u ∈c; z is a set of zones, each of which is defined as z = (x,y ), where the sets x and y form a partition of c (with u ∈ x and y possibly empty). x is referred to as the inside set of curves, and y is the outside set; sh : z →b is a shading function assigning a boolean value to each zone. a zone z for which sh(z) = true is said to be shaded and z∗ ⊂ z denotes the set of shaded zones; s is a set of spider labels drawn from s ; h is a habitat function h : s → p(z) that records the set of zones that each spider touches. each unique pair (s,z) ∈ s×z s.t. z ∈ h(s) is called a foot of spider s, and we call f the set of all feet. a compound spider diagram, d, is any unitary sd or any construct with unitary sds as primitives and allowing the unary logical negation operator not, and the binary logical conjunction and disjunction operators ∧ and ∨ as connectives. we provide a standard notion of interpretations and models (in a logic sense); see [hst05]. definition 2 let d be a sd on l . an interpretation of d is a pair (u,ψ), where u is a set and ψ is a function that assigns subsets of u to each curve. the map ψ naturally extends to zones, and is also extended to spiders by mapping them to singleton subsets1 of u . an interpretation is a model for d if it satisfies the semantics predicate, which states that: missing zones represent the empty set; each spider represents a unique element in the set represented by its habitat; shaded zones have cardinality at most the number of spiders touching that zone. we distinguish between sds used for system (invariant) specification and sds used as model instances. however, we use the same syntax, with restrictions on the form of the labels. we situate sds within object oriented specifications, with reference to a type system, assuming access to types, classes, and instances via labels. we interpret sd-specifications and sd-instances by specialising definition 2, varying the interpretation of ψ on spiders in the two cases: for sdspecifications a spider represents a set of objects of a given type, whilst in an sd-instance a spider represents the singleton set containing the named object of a given type. thus, sd-specifications place global constraints on a model (in a software engineering sense) instance. definition 3 an sd-specification is an sd, where c is drawn from the set of class or state names of the system and s from the set of types. an sd-instance is an sd, where c is drawn from the set of class or state names of the system, and s are pairs of object names and types. with d an sd-specification and d′ an sd-instance, an interpretation of d or d′ is a pair (u,ψ) 1 for ease of exposition, we view singleton sets of u and the individual elements as interchangeable. 3 / 14 volume 41 (2011) timed spider diagrams where u is restricted to be a set of objects of the system, and ψ maps curves to the set of objects of u of a certain class (as determined by the curve label). for an interpretation of d, ψ maps each spider to the set of objects of type indicated by its label. for an interpretation of d′, ψ maps each spider to the singleton set containing the object with name and type specified by its label. 2.1 satisfaction for an sd-instance to satisfy an sd-specification, the spiders in the instance must only inhabit zones corresponding to those inhabited by spiders of that type in the specification, and no constraint on zone cardinality can be violated. parts of the specification may be not relevant to the check, e.g. curves not present in the instance. hence, a projection of a diagram d onto a set c, of abstract curves produces a diagram dc with all curves not in c removed. this operation, besides redefining zones and their shading, modifies accordingly the habitat of spiders, coherently with the adopted semantics for these pieces of syntax. in figure 2 (top) an sd-specification d combines the two policies in figure 1. on the bottom left, an sd-instance d′ indicates that the instance john of type reader is suspended. the bottom right shows the projection d{u,suspended} of d onto the curve set of d′. as d′ has a correctly typed individual (john and susan) in an admissible zone for each type in d{u,suspended}, we say that d′ satisfies d. active suspended withloan isidle banned admin reader suspended john: reader model instance combined policy specification suspended admin reader projection of specification susan: admin figure 2: an example of an sd-instance. definition 4 let c ⊆ c be a set of curves, with u ∈c, and let z = (x,y ) ∈ z be a zone. the projection of z with respect to c, zc, is the pair (x ∩c,y ∩c). this extends to the projection of z with respect to c, denoted by zc. let d be a sd with curve set c′, where c ⊆ c′. if s is a spider in d with habitat h(s), then the projection of s with respect to c is spider sc with habitat h(sc) ⊆ zc such that z ∈ h(s) =⇒ zc ∈ h(sc) and z′ ∈ h(sc) =⇒ ∃z ∈ h(s) such that z′ = zc. proc. gtvmt 2011 4 / 14 eceasst the projection of d with respect to c is the diagram, denoted dc, obtained from d as follows: (1) we replace each zone of d, and each spider of d, by their projection with respect to c; (2) if z ∈ z(dc) then z is shaded if and only if every zone z′ ∈ z(d) such that (z′)c = z is shaded. when considering an sd-instance satisfying an sd-specification, we allow multiple spiders of the same type in the sd-instance, but insist that they all satisfy the constraints from the sdspecification. we also insist that in the sd-instance there is at least one spider of each type present in the sd-specification; moreover, given a spider in the sd-instance, its habitat is contained in the projection of the habitat of the spider for that type in the sd-specification. definition 5 let d1 be an sd-specification and let d2 be an sd-instance2. we say that d2 satisfies d1, denoted d2 |= d1, if: 1) c2 ⊆ c1; 2) z2 ⊆ (z1)c2 ; 3) z∗2 ⊆ (z ∗ 1) c2 ; 4) (z∗1) c2 ∩(z2 \ z∗2) = /0; 5) π2(s2) = s1, where πi takes the i-th component of a tuple and is extended to sets; 6) ∀s2 ∈ s2[∃s1 ∈ s1[π2(s2) = s1 ∧h2(s2)∩zc21 ⊆ h(s1) c2]]. 3 interval specifications we extend sds to enable temporal specifications, associating temporal annotations with the elements of a sd or with a whole sd, to indicate the time over which the associated constraint/situation holds. while several models of time could be utilised, we choose to use a model based on calendar time, where consecutive integer indexes are used to indicate contiguous timeintervals each with a duration defined by a granule or time-unit. the intervals we associate with diagrams have integer endpoints and are interpreted as the sequence of consecutive granules indexed by the integers within the interval, including the endpoints. we are interested in the meet, during, and overlap relations of allen’s interval algebra [af94], and they are adapted for use with the intervals associated with the diagrams. one can do this by considering allen’s relations for the actual time-intervals that are the union of the time-intervals of the consecutive integers in the interval associated to the diagram. the simple set-up presented here essentially combines the model of [af94] with the calendar model adopted in [bbf01]. we use n to denote the set of natural numbers and n0 for n∪{0}. for the granularity of intervals we consider standard time units e.g. seconds, hours, days, with the usual layering among them. hence, each granule can be decomposed into finer sub-granules up to some undecomposable granule (i.e. our time model is ultimately a discrete one). however, we consider that significant specifications are expressed with respect to decomposable granules. time 0 refers to the system starting time for the model at hand. definition 6 given a time unit u, let a,b ∈ n0 and a ≤ b. we call [a,b]u the time interval in u, i.e. the ordered sequence of granules indexed by all natural numbers between and including a and b. the set of all time intervals in u is denoted by iu. with i1 = [a1,b1]u,i2 = [a2,b2]u ∈ iu, we say: 1) i1 meets i2, denoted by i1 ui2, iff a2 = b1 + 1; 2) i1 during i2, denoted by i1 v i2 iff 2 for simplicity we assume here that these are unitary diagrams and that the sd-instance does not contain curves that are not present in the sd-specification. 5 / 14 volume 41 (2011) timed spider diagrams a1 ≥ a2, b1 ≤ b23; 3) i1 overlaps i2, denoted by i1ti2, iff a1 < a2 ≤ b1 < b2. if none of the above occurs, we say that i1 and i2 are disjoint, with the two cases i1 < i2 and i1 > i2. for non disjoint i1 and i2, we define their merge i1 �i2 as the interval i = [min(a1,a2),max(b1,b2)]. example 1 we have [0,2]d u [3,6]d ; they merge to give [0,6]d . in this case we use days as granules, so the interval specifies the 7 consecutive days of a week; the interval [1,1]d , with the same start and end point, is interpreted as the second day of the week, starting counting at 0. we also have [1,2]d v [1,4]d , and [1,2]d � [1,4]d = [1,4]d ; [1,3]d t [2,4]d and [1,3]d � [2,4]d = [1,4]d ; [1,2]d is disjoint from [4,5]d . besides simple intervals, we have interval specifications involving expressions on variables. definition 7 given a time unit u, an interval specification in u is a construct [ex p1,ex p1 + ex p2]u, where ex p1 and ex p2 are two linear expressions including natural numbers and variables (with integer coefficients other than zero) that can be evaluated over n0. var(ex p) denotes the set of variables appearing in ex p and var(i) the cumulative set of variables from ex p1 and ex p2. a valuation val(ex p) is a set of assignments to natural numbers for each variable in var(ex p), so that each occurrence of the same variable name is assigned the same value. analogously val(i) denotes the simultaneous valuation of ex p1 and ex p2. the value of ex p according to val(ex p) is denoted ‖val(ex p)‖. the interpretation of an interval specification ts pec = [ex p1,ex p1 + ex p2]u is the set of intervals int(ts pec) ={[a,b]u ∈iu |∃val(ts pec),s.t.‖val(ex p1)‖= a,‖val(ex p2)‖ = b−a}. we denote by i ′u the set of interval specifications in u. example 2 consider an interval specification i = [x + 1,x + 1 + 2y]u. then var(x + 1) = {x}, var(2y) ={y}, and var(x+1+2y) ={x,y}= var(i) are sets of variables. suppose that we have valuation functions val(x+1) such that x 7→3, and val(2y) such that y 7→1. then x 7→3,y 7→1 is an assignment of natural numbers to variables in var(i). the values of the expressions according to these assignments are: ||val(x + 1)|| = 4, ||val(2y)|| = 2, ||val(x + 1 + 2y)||= 6, ||val(i)|| = [4,6]u. the interpretation of [x+1,x+1+2y]u is the set of all intervals [a,b]u s.t. a ≥ 1 and b−a is an even number (possibly 0). note that each valuation of an interval specification, i, fixes it to be a specific interval. in the following, we omit the indication of the unit where no ambiguity arises, and deal only with specifications ts pec s.t. int(ts pec) 6= /0, ruling out specifications such as [x,x−(2x + 1)]. two non disjoint intervals i1,i2 in a set of intervals i can be naturally decomposed into a sequence of at most three contiguous intervals (i.e. meeting and not overlapping) as follows: 1) if i1 ui2 do nothing; 2) if i1 v i2 (and it is not the case that i1 starts, finishes or is equal to i2, hence a1 > a2 and b1 < b2) then build the sequence [a2,a1 −1],[a1,b1],[b1 + 1,b2] (the other cases being easily derivable); 3) if i1ti2, then build the sequence [a1,a2−1],[a2,b1],[b1 + 1,b2]. this procedure can be iterated on any set of intervals (s.t. no interval is disjoint from all the others) until each non disjoint pair of intervals meet. it can be proved that the resulting collection of intervals is unique. note that this does not create new end or start points other than those in the set {a2 −1,...,an −1,b1 + 1,...,bn−1 + 1}. also note that some intervals can be reduced to a 3 for our purposes, we include in this the special cases defining the relations finishes, starts, or equal in [af94]. proc. gtvmt 2011 6 / 14 eceasst unitary interval, e.g if a2 −1 = a1 for case 2) above. we extend the decomposition concept to interval specifications. definition 8 let i ={i1,...,in} be a finite set of intervals, for ii = [ai,bi]∈i , s.t. ⊙ i∈{1,... n} ii is defined and equal to [min(ai),max(bi)] for i ∈{1,...,n}. a non overlapping cover of i is a finite set of intervals j ={j1,...,jm}, with jk = [ck,dk], s.t.: 1) ⊙ i∈{1,...,n} ii = ⊙ j∈{1,...,m} j j; 2) for each k ∈{1,...,m−1}, jk meets jk+1 (i.e. ck+1 = dk +1). j is the canonical non overlapping cover if its set of intervals coincides with the one derived from the procedure described above. let i′ = {i′1,...,i ′ n} be a finite set of interval specifications, and let val be a valuation function for i′ (i.e. for all of the interval specifications in i′). then a (canonical) non overlapping cover of i′ w.r.t. val is a finite set of interval specifications j′ ={j′1,...,j ′ m} s.t. ‖val(j′)‖ is a (canonical) non overlapping cover of ‖val(i′)‖. example 3 suppose that i = {i1 = [1,5],i2 = [4,5],i3 = [2,9]}. then ⊙ i∈{1,2,3} ii = [1,9]. let j = {j1 = [1,1],j2 = [2,3],j3 = [4,5],j4 = [6,9]}, so ⊙ k∈{1,2,3,4} jk = [1,9] and j is the canonical non-overlapping cover of i. on the contrary, j′ = {[1,2],[3,4],[5,6],[7,9]} is another non-overlapping cover, which is not canonical as can be easily seen since 7 is an endpoint of j′ not in the set {1,2,3,4,5,6,9}. 4 timed spider diagrams we introduce timed sds as associations of sds with specifications of admissible time intervals for elements in a diagram and with constraints on variables appearing in the specifications. they can express fairly complex temporal relations and we wish to facilitate operations such as the combination of compatible timed-sds (e.g. stating two parts of a same policy). figure 3 shows a compound diagram and introduces variables in sd-specifications. variables are used to specify intervals which can start at any time, so that a designated variable is instantiated to define the onset of the interval. variables are bound to natural numbers, and subject to constraints. the figure refines the library policy: a user who stays in the suspended state for a whole period of 30 days (for example for not paying a fine) becomes banned. in this case the designated variable x can be instantiated at any time, in correspondence with the moment where a user enters the suspended state, while the use of k and of the associated constraint indicates that being in this state may cease at any time before the deadline of 30 days4. we consider time-valid diagrams where elements are present only if elements on which they depend are also present, e.g. a foot can be in a zone only during the existence interval for that zone. definition 9 a timed sd is a construct dt = (d,ω,x), where d = (c,z,sh,s,h) is an sd, ω : c∪z∪(z×b)∪s∪f → i ′ is a function assigning an interval specification to each object5 in d, and x is a set of linear constraints on the valuations for the specifications assigned by ω , where all instances of variables with the same name receive the same value. let val(ω) be a valuation function that consistently evaluates every variable in the image of ω . a valuation 4 for simplicity, we omit here the indication of the time unit. 5 f is the set of feet as derived from h : s → p(z). 7 / 14 volume 41 (2011) timed spider diagrams suspended [x,x+k] {k <30} active [x+k+1,…] suspended banned reader [x+31,…] [x,x+30]  reader figure 3: a user either exits from suspension within 30 days or becomes banned. ‖val(ω(x))‖ = [a,b] satisfies x , denoted ‖val(ω(x))‖ |= x , if no assignment in val violates a constraint in x , and a ≤ b. we say that dt is time-valid if ∃val(ω) s.t.: 1. ∀x ∈c∪z ∪(z ×b)∪s∪f[‖val(ω(x))‖ |= x ]. 2. the following general constraints hold: • ∀ f = (s,z)∈ f[‖val(ω( f ))‖v‖val(ω(s))‖]; • ∀ f = (s,z)∈ f[‖val(ω( f ))‖v‖val(ω(z))‖]; • ∀z ∈ z[‖val(ω(z,sh(z)))‖v‖val(ω(z))‖]; • ∀z ∈ z,c ∈c[‖val(ω(z))‖v‖val(ω(c))‖]. given an interval specification [ex p1,ex p1 + ex p2], if there exists a variable x ∈ var(ex p2)\ var(ex p1), s.t. no constraint is explicitly given for x, then we say that ex p1 + ex p2 is unlimited and write [ex p1,...]. in the following, we only deal with time-valid diagrams, and rule out inadmissible sets of specifications, such as i ={[x,x+y],[z−y,x−z−1]} with x ={y = z,z = 2x}. elements in a diagram are present during the specified time-intervals, with any non-assigned element being assigned [0,...] by default. we interpret that for any interval i disjoint from the image of a diagram element, that element is not present during i. note that associating an interval with a pair in z×b allows for modifications over time of the property of being shaded for a zone. a timed-sd (d,ω) can represent a complex time-based set of constraints. however, this can be reduced to a collection of basic timed sds where each diagram is associated with a single interval. this construction is possible if ω is well-defined for every element of d and the image of any such element under ω is a single interval. hence, for each time-valid timed sd there is an equivalent sequence of basic timed sds, where the intervals of consecutive diagrams are contiguous. in definition 10, we first define these concepts for sds, permitting specialisation to sd-specifications and sd-instances, and then we make use of specialisations by providing semantics to the timed sd-specifications. definition 10 (1) a basic timed-sd is a tuple (d,i,x), where d is an sd, i ∈ i ′ and x is a set of linear constraints on var(i). (2) let 〈d〉= 〈(d1,i1,x1),...,(dn,in,xn)〉 be a sequence of basic timed-sds. we say that 〈d〉 is contiguous w.r.t. a joint valuation function val over all interval specifications i1,...,in, if ||val(i j)||u||val(i j+1)|| for all j ∈{1,...,n−1}. proc. gtvmt 2011 8 / 14 eceasst a timed sd encapsulates complex temporal constraints. for purposes such as to allow modularisation of the constraints according to some time-line, as well as defining the semantics of timed sd-specifications, we provide a conversion from timed-sds to sequences of contiguous basic timed-sds. the following can be applied to sd-specifications or sd-instances. definition 11 let dt = (d,ω,x) be a time-valid timed sd w.r.t. a valuation function val(ω). let 〈d′〉 = 〈(d′1,j1,y1) ,..., (d ′ m,jm,ym)〉 be a sequence of basic timed sds, and val′ a joint valuation function over the ji’s s.t.: (i) 〈d′〉 is contiguous w.r.t. val′; (ii) for each subinterval i of ‖val′(ji)‖, d′i consists of exactly the diagram elements x of d for which i v‖val(ω(x))‖. then d′ is a time-decomposition of dt . if m is minimal subject to (i) and (ii), then d′ is a canonical time-decomposition of dt . algorithm 1 let dt = (d,ω,x) be a time-valid timed sd, and let val be a valuation function over ω . then: 1) let i be the set of all of the interval specifications obtained as ω(x), for any x ∈c∪z ∪(z ×b)∪s∪f . 2) construct j = {j1,...,jm}, the canonical non overlapping cover of i w.r.t val. 3) construct 〈(d1,j1,y1),...,(dm,jm,y1)〉, where di is the sd consisting of the set of diagram elements x, for all x ∈c∪z∪(z×b)∪s∪f for which ‖val(ji)‖ is not disjoint from ‖val(ω(x))‖. theorem 1 let dt = (d,ω,x) be a time-valid timed-sd, and let val be a valuation function over ω . then the construct 〈(d1,j1,y1),...,(dm,jm,y1)〉 from algorithm 1 is a canonical timedecomposition of dt . proof. post-valuation, one can consider the set of intervals associated to each diagram element, and decompose this into a sequence of contiguous intervals which collectively merge to yield the whole timeline. then, for each interval in this decomposed timeline, there is a single corresponding diagram (comprising all and only the diagram elements of d that are present within that interval); each of these is a well-defined diagram since dt is time-valid. these diagrams together with associated intervals constitute a contiguous sequence of basic timed-sds. it follows that they form a canonical time-decomposition of dt , due to the construction. the argument lifts from intervals to interval specifications. 4.1 satisfaction and semantics of timed-sds we extend the notion of satisfaction of an sd-specification by an sd-instance to timed sds. that is, we define what it means for a timed sd-instance to satisfy a timed sd-specification. we do this by first translating both specification and instance into distinct contiguous sequences of basic timed sds. then we provide a definition of satisfaction of a sequence of contiguous basic timed sd-specifications by a contiguous sequence of basic timed sd-instances. this is done by checking that over every interval of the sequence of basic sd-instances, the sd-instance satisfies the sd-specification during that interval. a sequence of contiguous basic timed sd-instances satisfying a contiguous sequence of (basic) timed sd-specifications is called a story and the semantics of a timed sd-specification is defined to be the set of all of its stories. this could also be viewed as the set of all possible snapshot sequences that satisfy all of the constraints for the corresponding intervals. 9 / 14 volume 41 (2011) timed spider diagrams definition 12 let 〈d〉 = 〈(d1,i1,x1),...,(dn,in,xn)〉 be a contiguous sequence of basic timed sd-specifications, and let 〈d′〉= 〈(d′1,j1,y1),...,(d ′ m,jm,ym)〉 be a contiguous sequence of basic timed sd-instances. then, for a common valuation function val, over i1,...,in,j1,...,jm and an interval k, we say that: (i) 〈d′〉 |=k 〈d〉, if for i, j s.t. k,‖val(ii)‖, and ∩ ∥∥val(j j)∥∥ are jointly overlapping, d′j |= di; (ii) 〈d ′〉 satisfies d, denoted 〈d′〉 |= 〈d〉, if ∀ji ∈{j1,...,jm}, we have 〈d′〉 |=ji 〈d〉. let dt = (d,ω,x) be a time-valid timed-sd-specification (w.r.t. val) and let 〈d′′〉 = 〈(d′′1 ,k1,z1) ,..., (d ′′ p,kp,zp)〉 be a time-decomposition of dt (w.r.t. val′′). then, for a common valuation function val′ over k1,...,kp,j1,...,jm, 〈d′〉 satisfies dt if 〈d′〉 satisfies 〈d′′〉. definition 13 let dt = (d,ω,x) be a time-valid timed-sd-specification. let 〈d〉=〈(d1,i1,x1), ..., (dn,in,xn)〉 be a contiguous sequence of basic timed sd-instances, s.t. for each valuation function val of ω , there is an extension of val to val2, a valuation of ω,i1,...,in with 〈d〉 |= dt , w.r.t. val2. then 〈d〉 is called a dt -story and the semantics of dt is the set of all dt -stories. we also speak of sd-stories when dt is implicit. suspended [x,x+k]{k <30} reader active [x+k+1,...] reader banned [x+31,...] reader suspended [x,x+30] reader figure 4: (a) alternative cases which are contiguous basic timed sd-specifications for the timed sd-specification of figure 3. suspended [21/3/2009, 21/3/2009 + 30] john: reader suspended [21/3/2009 + 31, 21/3/2009 + 34] john: reader figure 4: (b) a contiguous sequence of basic timed sd-instances which is not an sdstory for the specification of figure 3. figure 4(a) shows examples of two contiguous sequences of basic timed sd-specifications that encapsulate the alternative cases of the timed sd-specification of figure 3. figure 4(b) shows an example of contiguous sequence of basic timed sd-instances which does not satisfy either of the sequences in figure 4(a), and is not an sd-story for figure 4(a); note that if the suspended state in the second diagram were changed to a banned state, then this would by a story for the sd-specification in figure 4(a). any sd-instance satisfying a canonical time decomposition of a timed sd-specification is an sd-story. there could be many of these sd-instances, but there is at least one. the canonical time decomposition of a timed-sd exists and is unique, provided we place certain restrictions on the valuation function. proc. gtvmt 2011 10 / 14 eceasst theorem 2 let dt = (d,ω,x) be a time-valid timed sd-specification, w.r.t. val, a valuation function over ω . let 〈d′〉 = 〈(d′1,i1,x1), ..., (d ′ n,in,xn)〉 be a contiguous sequence of basic timed sd-instances that satisfies a canonical time decomposition of dt . then 〈d′〉 is an sd-story (called a canonical sd-story). proof. satisfaction of a canonical time decomposition of dt implies satisfaction of dt . corollary 1 each time-valid timed sd-specification dt = (d,ω,x) has a non-empty semantics. proof. since dt is time-valid, there is a canonical time decomposition of dt . any sd-instance which realises the spider types of this canonical time decomposition as appropriate (name,type) pairs is an sd-story, as required6. definition 14 an initialised canonical time decomposition of dt is a canonical time decomposition of dt , w.r.t. a valuation function ival, which assigns the minimal admissible value to iex p1, with j1 = [iex p1,iex p1 + iex p2]. an initialised left-minimal canonical time decomposition is an initialised canonical time decomposition with valuation ilmval such that the lengths of each ji is minimal over all ival valuations, miminizing in order of increasing index i. theorem 3 let dt = (d,ω,x) be a time-valid timed sd, and let val be a valuation function over ω . then there exists a unique initialised left-minimal canonical time decomposition. proof. existence derives from theorem 2, uniqueness from the minimization process. theorem 4 let dt be a timed-sd specification. then the time-validity of dt is decidable. proof. the interval specification constraints reduce to a system of linear diophantine equations (relating end-points to start-points) under a set of constraints. that the solution, without constraints, is decidable is a classical result. 5 related work several models of time have been proposed for formal specifications, both in relation to realtime [gb03, ad94] or hybrid [hen96] behaviours. time-based extensions have been also proposed for calculi or specification languages of concurrent processes (see [fop09] or [bw03]). in general, these models deal with intervals to model uncertainty about the actual occurrence of an event. in statemate, also a clock-synchronous semantics is provided where events can only occur when a clock ticks [ejw02]. this view was adopted also in [gvh03] to integrate time in graph transformations, by introducing a specific attribute updated by clock messages to processes. in uml, a simple model of time is adopted, based on a notion of observation, and able to express durations and deadlines [omg10], whereas in the profile for real-time applications, effects connected with latencies in observation can be taken into account [omg05]. in both cases, ocl constraints can incorporate conditions on time expressions. 6 we assume the set u has sufficient elements for such a realisation. 11 / 14 volume 41 (2011) timed spider diagrams in general, we are interested here in the persistence in a state over a period as dictated by time-dependent policies, rather than in modeling the occurrence of specific transitions triggered by any type of events. as a consequence, the model of time adopted here is connected to the notion of calendar time, as adopted in the area of temporal databases and temporal rule based access control. in particular, we adopt a model analogous to that bertino et al. [bbf01], based on a formalism proposed by niezette and stevenne [ns92], which however considered intervals of fixed length, repeated after some time. in bertino’s model a calendar is a set of contiguous intervals, each with its own duration, containing all the instants between its extreme granules, from the start of the first granule to the end of the second one. based on this, they introduce periods to express that some roles have to be granted specific access rights at recurring times. ning et al. exploit the notions of calendars and granules to define a calendar algebra, where operations allow the grouping of intervals or the subdivision of granules [nwj02]. of interest here is the notion that the intervals covered by distinct granules (at the same level) cannot be interleaved. others consider calendar times as corresponding to an instant, rather than a granule [kö95]. a vast examination of the problems related to the use of different granularities is in [em05]. the field of multimedia is another area in which the modeling of time is relevant, in particular as sequential media (typically audio and video) may have to be synchronised with the presence of static documents for some time. in many cases one is therefore interested in considering durations of intervals which can start at any point in time, rather than at specific instants. as an example, bowman et al. have defined a formalism in which, once a starting point for the system is set, reasoning can be performed on the occurrence, within the current interval, of a state, based on the lengths of the current and previous intervals [bckt03]. in addition to considering intervals, in the approach presented in the paper, the use of instants in the specification of rules can provide a weak form of clock-synchronous specification, associated with the triggering of a time-dependent transition. in the field of sds, to our knowledge this is the first attempt to integrate time-related aspects in the formalism. moreover, we draw a more precise correspondence with object-oriented modeling, by distinguishing specifications from instance models and providing two distinct interpretations for spiders, as types and as typed individuals. a relation can be drawn with the construction of parallel models in z for constraint diagrams in [hs05]. the idea of representing system dynamics through sequences of eds was introduced in [bf10], to follow the evolution of sets (rather than the state of individuals) under the effect of a reaction systems [er07], and colour was used to assist in tracking families of sets through the sequences. 6 discussion and conclusions we have proposed an extension of sds which enables them to express time-dependent policies, in which curves indicate the permanence of individuals, modeled by spiders, in some state, over some interval. stories of individual evolution can then be checked against these specifications to assess conformance to the policy, so that the semantics of a policy specification is the set of stories conformant to that specification. we adopt a simple model of time, related to measurement units rather than system clocks. the model is suitable to the expression of requirements and constraints on system configurations, rather than of real-time behaviours. proc. gtvmt 2011 12 / 14 eceasst however, a limited form of dynamics can be provided by the use of rules enforcing modifications in the state of individuals according to a policy. in this case, we could specify rules over timed specifications, to produce dynamic views of a specified system. to this end, we could use rules triggered by the onset or offset of an interval (in this case making reference to the mapping of intervals onto the fundamental granule layer). for example, given a collection of specifications 〈(d1,ω1),...,(dn,ωn)〉 annotated with contiguous interval specifications, one can derive a collection of rules as pairs ((di,ωi),di+1), together with some mapping µ from elements of di to elements of di+1. the interpretation of such a rule would be that if a system has been described by an sd instance satisfying di over an interval given by a valuation of ωi, then at the end of this interval it moves to a state described by an sd instance, related to the previous one via µ , which is a model for di+1. we plan to extend this work in a number of directions. firstly, standard notions and results from the theory of (static) sds have to be reviewed and lifted to timed sds, taking into account the distinction between spiders at the different levels. secondly, the extension to real-time may require a different basis for time, considering open intervals over the reals. thirdly, we plan to consider different types of dynamics, integrating event-based and time-dependent specifications, exploiting the mapping of sds to typed attributed graphs, called spider graphs, presented in [bfp10], possibly following the approach in [gvh03]. bibliography [ad94] r. alur, d. l. dill. a theory of timed automata. tcs 126(2):183–235, 1994. [af94] j. f. allen, g. ferguson. actions and events in interval temporal logic. j. log. comput. 4(5):531–579, 1994. [bbf01] e. bertino, p. a. bonatti, e. ferrari. trbac: a temporal role-based access control model. acm trans. inf. syst. secur. 4(3):191–233, 2001. [bckt03] h. bowman, h. cameron, p. king, s. thompson. mexitl: multimedia in executable interval temporal logic. formal methods in system design 22:5–38, january 2003. [bf10] p. bottoni, a. fish. coloured euler diagrams: a tool for visualizing dynamic systems and structured information. in proc. diagrams 2010. lnai 6170, pp. 39–53. 2010. [bfp10] p. bottoni, a. fish, f. parisi-presicce. preserving constraints in horizontal model transformations. gtvmt-2010, eceasst 29:1–14, 2010. [bw03] v. bulitko, d. c. wilkins. qualitative simulation of temporal concurrent processes using time interval petri nets. artificial intelligence 144(1-2):95 – 124, 2003. [ejw02] r. eshuis, d. n. jansen, r. wieringa. requirements-level semantics and model checking of object-oriented statecharts. requir. eng. 7(4):243–263, 2002. [em05] j. euzenat, a. montanari. chapter 3 time granularity. in m. fisher and vila (eds.), handbook of temporal reasoning in artificial intelligence. foundations of artificial intelligence 1, pp. 59–118. elsevier, 2005. 13 / 14 volume 41 (2011) timed spider diagrams [er07] a. ehrenfeucht, g. rozenberg. events and modules in reaction systems. tcs 376:316, 2007. [ffh05] a. fish, j. flower, j. howse. the semantics of augmented constraint diagrams. jvlc 16:541–573, 2005. [fop09] m. falaschi, c. olarte, c. palamidessi. a framework for abstract interpretation of timed concurrent constraint programs. in proc. ppdp ’09. pp. 207–218. acm, 2009. [gb03] h. giese, s. burmester. real-time statechart semantics. technical report tr-ri-03239, university of paderborn, 2003. [gvh03] s. gyapay, d. varro, r. heckel. graph transformation with time. fundamenta informaticae 1:1–22, 2003. [hen96] t. a. henzinger. the theory of hybrid automata. in lics. pp. 278–292. 1996. [hmt+01] j. howse, f. molina, j. taylor, s. kent, j. gil. spider diagrams: a diagrammatic reasoning system. jvlc 12(3):299–324, 2001. [hs05] j. howse, s. schuman. precise visual modelling. sosym 4:310–325, 2005. [hst05] j. howse, g. stapleton, j. taylor. spider diagrams. lms journal of computation and mathematics 8:145–194, 2005. [ken97] s. kent. constraint diagrams: visualizing invariants in object oriented modelling. in proc. oopsla97. pp. 327–341. acm press, october 1997. [kö95] a. kurt, z. m. özsoyoglu. modeling and querying periodic temporal databases. in proc. dexa workshop. pp. 124–133. 1995. [ns92] m. niezette, j. stevenne. an efficient symbolic representation of periodic time. in proc. cikm 1992. pp. 161–168. 1992. [nwj02] p. ning, x. s. wang, s. jajodia. an algebraic representation of calendars. annals of mathematics and artificial intelligence 36(1-2):5–38, 2002. [omg05] omg. uml profile for schedulability, performance, and time specification, version 1.1. technical report formal/05-02-06, omg, 2005. http://www.omg.org/cgibin/doc?realtime/05-02-06.pdf. [omg10] omg. omg unified modeling language (omg uml), superstructure version 2.3. technical report formal/2010-05-05, omg, 2010. http://www.omg.org/spec/uml/2.3/superstructure. [stht04] g. stapleton, s. thompson, j. howse, j. taylor. the expressiveness of spider diagrams. j. of logic and computation 14(6):857–880, december 2004. proc. gtvmt 2011 14 / 14 introduction specialisation of sds for modelling purposes satisfaction interval specifications timed spider diagrams satisfaction and semantics of timed-sds related work discussion and conclusions electronic communications of the easst volume 33 (2010) proceedings of the fourth international workshop on foundations and techniques for open source software certification (opencert 2010) preface 4 pages guest editors: luis s. barbosa, antonio cerone, siraj a. shaikh managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst preface over the past decade, the open source software (oss) phenomenon has had a global impact on the way software systems and software-based services are developed, distributed and deployed. widely acknowledged benefits of oss include reliability, low development and maintenance costs, as well as rapid code turnover. linux distributions, apache and mysql stand, among many other examples, as a testimony to its success and resilience. in the meantime companies understood that integrating oss into commercial products, through liberal oss licenses, reduce development costs while offering high-quality, extensively tested components. furthermore, governments became aware of the growing dependence of their administrations on proprietary formats and software, and start regarding oss as a warranty of technological independence. however, state-of-the-art oss, by the very nature of its open, unconventional, distributed development model, make software quality assessment, let alone full certification, particularly hard to achieve, raising important challenges both from a technical, methodological or managerial perspective. this makes the use of oss, and, in particular, its integration within complex industrial-strength applications, with stringent security requirements, a risk. and, simultaneously an opportunity and a challenge for rigorous, mathematically based, methods in software analysis and engineering. in such a context, the aim of the opencert series of workshops is to bring together researchers from academia and industry who are broadly interested in the quality assessment of open source software projects, ultimately leading to the establishment of coherent certification processes, at different levels. the 1st international workshop on foundations and techniques for open source software certification (opencert 2007) was held on 31 march 2007 in braga, portugal, as a satellite event of etaps 2007 (the 10th european joint conferences on theory and practice of software). in the following year, on 10 september, opencert 2008 was held in milan, italy, jointly with the international workshop on foundations and techniques bringing together free/libre open source software and formal methods (floss-fm 2008), as a satellite event of oss 2008. the proceedings of the workshop were published as technical report no. 398 of the united nations university international institute of software technology (unu-iist). in 2009, opencert was again co-located with etaps and held on 28 march 2009 in york, united kingdom. postproceedings appeared as volume 20 of the electronic communications of the easst. this volume contains the post-proceedings of the 4th international workshop on foundations and techniques for open source software certification (opencert 2010) held from 17 to18 september 2010, in pisa, italy, as a satellite event of the 8th ieee international conference on software engineering and formal methods (sefm’10). the volume includes a total of eleven regular papers spanning from security certification, source code analysis and tools to discussion of empirical studies and educational concerns. two invited contributions are also included: one by panagiotis katsaros and ioannis stamelos, from aristotle university of thessaloniki, greece, on component certification as a prerequisite for widespread oss reuse, and another by mario fusani and eda marchetti, from cnr-isti, italy, on damages and benefits of certification: a perspective from an independent assessment body. the organizers are most grateful for both invited lectures. 1 / 4 volume 33 (2010) preface this gratitude extends to all members of the program committee for their hard work on reviewing and selecting submissions, and, of course, to all authors without whom opencert 2010 would not have been possible. a final word of thanks is due to sefm 2010 organizing committee, with a particular mention to maurice ter beek, who served as satellite events chair, and all staff at pisa, for providing such a smooth and pleasant workshop venue. pisa, september, 2010. luis s. barbosa, minho university, portugal antonio cerone, united nations university, macau sar china siraj ahmed shaikh, coventry university, united kingdom proc. opencert 2010 2 / 4 eceasst committees steering committee • bernhard aichernig, technische universität graz, austria • antonio cerone, unu-iist, united nations university, macau sar china • martin michlmayr, university of cambridge, uk • david von oheimb, siemens corporate technology, germany • josé nuno oliveira, di-cctc, universidade do minho, portugal program committee • bernhard aichernig, technische universität graz, austria • admir abdurahmanovic, primekey, sweden • luis soares barbosa, di-cctc, universidade do minho, portugal (co-chair) • andrea capiluppi, university of east london, uk • antonio cerone, unu-iist, united nations university, macau sar china (co-chair) • gabriel ciobanu, faculty of computer science, a.i. cuza university, romania • ernesto damiani, universit di milano, italy • jim davies, university of oxford, uk • roberto di cosmo, universit paris diderot / inria, france • fabrizio fabbrini, isti-cnr, italy • maria joão frade, di-cctc, universidade do minho, portugal • jesus arias fisteus, universidad carlos iii de madrid, spain • dan ghica, university of birmingham, uk • tomasz janowski, unu-iist, united nations university, macau sar china • paddy krishnan, bond university, australia • paolo milazzo, dipartimento di informatica, universit di pisa, italy • josé miranda, multicert, portugal • john noll, lero, ireland 3 / 4 volume 33 (2010) preface • alexander k. petrenko, isp, russian academy of science, russian federation • simon pickin, universidad carlos iii de madrid, spain • siraj shaikh, coventry university, uk (co-chair) • sulayman k. sowe, unu-merit, united nations university, the netherlands • ralf treinen, pps, universit paris diderot, france • joost visser, software improvement group, the netherlands • david von oheimb, siemens corporate technology, germany • tanja vos, universidad politcnica de valencia, spain • anthony wasserman, carnegie mellon silicon valley, us proc. opencert 2010 4 / 4 a termination criterion for graph transformations with negative application conditions electronic communications of the easst volume 30 (2010) international colloquium on graph and model transformation on the occasion of the 65th birthday of hartmut ehrig (gramot 2010) a termination criterion for graph transformations with negative application conditions paolo bottoni, francesco parisi presicce 13 pages guest editors: claudia ermel, hartmut ehrig, fernando orejas, gabriele taentzer managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst a termination criterion for graph transformations with negative application conditions paolo bottoni, francesco parisi presicce dipartimento di informatica, ”sapienza” università di roma, italy abstract: termination of graph transformations is in general undecidable, but it is possible to prove it for specific systems by checking for sufficient conditions. in the presence of rules with negative application conditions, the difficulties increase. in this paper we propose a different approach to the identification of a (sufficient) criterion for termination, based on the construction of a labelled transition system whose states represent overlaps between the negative application condition and the right hand side that can give rise to cycles. keywords: graph transformations, termination, labelled transition system 1 introduction model transformations are an essential component of the model-driven approach to software development. graphs are a natural and intuitive way to describe models (e.g., class diagrams in uml) and graph transformations provide a rule-based approach to their modifications. sometimes a particular transformation needs to be applied to the target graph/model as long as matchings of its left hand side can be found. in such cases, it is necessary to be able to determine that such a repeated application will eventually reach a state where the transformation is no longer applicable. more generally, the term termination refers to the problem of determining whether a set of rules can generate a graph/model to which none of the rules is still applicable. ad hoc methods have been applied to show termination of specific rewriting systems (e.g. [khe03]). termination properties can be (and have been) studied for specific rewriting systems, following the classical approach – given by dershowitz and manna in [dm79] – of proving termination by constructing a monotone measure function on some multiset associated to the object to be rewritten, and showing that the value of this function decreases with each application of the rule. further termination criteria use polynomial orderings, recursive path orderings, etc. [der87]. in a previous paper [bhpt05], we have identified an abstract notion of termination criterion for high-level replacement (hlr) systems, i.e. algebraic rewriting systems operating on objects and morphisms in adhesive hlr categories [epph06], in which rewriting is guided by control expressions. the approach is based on a generic measure function f : g → ℕ, called a termination criterion if it satisfies the property f (a +c b) = f (a)+ f (b)−f (c) for morphisms c → a and c → b in a specific subclass m . a termination criterion for a rule p : l ← k → r is such a function with f (l) > f (r). however, we have subsequently shown in [bhp06] how the extension of this notion to rules with negative application conditions (nacs) encounters several difficulties. in particular, we have presented examples of pairs of rules for which no application criterion can differentiate between a terminating and a non-terminating rule. volume 30 (2010) termination criterion in this paper, we propose a different approach to the identification of a (sufficient) termination criterion for the repeated application of a single rule with a nac, based on the construction of a labelled transition system, where the states correspond to classes of matches of a rule with respect to all the possible intermediate graphs between the left-hand side of a rule and the negative application condition. in the following, we give formal definitions for the adopted model of graphs in section 2, and present motivations for the approach through a number of cases in section 3. section 4 presents the main result of the paper, showing the construction of the transition system, and section 5 discusses related work. finally, section 6 draws conclusions and points to future work. 2 formal background we use the dpo (double pushout) approach to graph transformation [eept06] a graph g = (v,e,s,t) consists of a finite set of nodes v = v (g), a finite set of edges e = e(g), a source and a target total functions, s,t : e →v . in a type graph t g = (vt ,et ,st ,t t ), vt and et are sets of node and edge types, while the functions st : et → vt and t t : et → vt define source and target node types for each edge type. a typed graph on t g = (vt ,et ,st ,t t ) is a graph g = (v,e,s,t) equipped with a graph morphism type : g → t g, composed of two functions typev : v →vt and typee : e → et , preserving the source st and the target t t functions, i.e. typev (s(e)) = st (typee(e)) and typev (t(e)) = t t (typee(e)). a dpo rule consists of three graphs, called leftand right-hand side (l and r), and interface graph k. two injective morphisms1 l : k → l and r : k → r model the embedding of k (containing the elements preserved by the rule) into l and r. figure 1 shows a dpo direct derivation diagram. square (1) is a pushout modeling the deletion from g of the elements of l not in k, while pushout (2) models the addition to g of the elements present in r but not in k. if l = k the rule is called non-deleting, while if k = r the rule is called deleting. figure 1 illustrates the notion of negative application condition (nac), of the form n : l → n that a match m : l → g must satisfy. a rule is applicable with match m : l → g if there is no morphism q : n → g such that q∘n = m. n q ,, ∕= l noo m �� (1) k (2) loo r // k �� r m∗ �� g dfoo g // h figure 1: dpo direct derivation diagram for rules with nac. 3 a naive approach in this section we analyze a few examples of simple rules which exhibit different behaviors despite appearing very similar. the same examples will be used later on to illustrate the different 1 in this paper, except for the typing morphisms type : g → t g, all morphisms are total and injective. proc. gramot 2010 eceasst cases of our main result. we consider here only non-deleting rules: the case of the repeated application of a deleting rule, i.e., a rule where l has at least one more item (node or edge) than k and k = r, is easier to handle. if the original graph is finite, and every application removes at least one item, eventually a graph is produced where the rule is no longer applicable. in non-deleting rules, we omit the k component of rules and write a rule with a single nac as p : n ← l → r, (not to be confused with a generic rule with l as interface). when dealing with rules equipped with nacs, the first (only partially incorrect) thought that comes to mind is that the rule cannot be applied again if it produces, in the rhs, the nac, i.e., if n ⊂ r. in fact, figure 2 shows a rule for which the existence of an injection of n into r is sufficient to prevent the repeated application of the rule (on the same pair of nodes). figure 2: a terminating rule, with n ⊂ r. however, the existence of an injection of n into r is not sufficient to guarantee the nonapplicability of the same rule and to discriminate between a terminating and a non-terminating rule, as the example in figure 3 shows. p l rn 1 11 1 figure 3: a rule which does not terminate, with n ⊂ r. it is important to observe how for the examples in figure 2 and figure 3 no single function f from graphs to natural numbers, which is a termination criterion for rules without nacs, could be used to discriminate between the two cases. the difference between the two cases is in fact that in the rule of figure 3, the number of matches increases, whereas in figure 2 it decreases. maybe we should reverse the direction of the inclusion, and consider rules where r ⊂ n. again, this condition is neither sufficient nor necessary for termination, as the following two examples show. volume 30 (2010) termination criterion figure 4: a terminating rule, with r ⊂ n. a rule which must terminate is presented in figure 4, where no more than two loops can be added to each node in the graph. this is not the case for the rule in figure 5, where again r ⊂ n, but the rule may terminate or not, depending on whether we choose a different match after applying the rule or the same match (the nac n does not prohibit several loops on the same node). figure 5: a rule which may terminate, with r ⊂ n. while the examples presented here are simple enough that an ad-hoc analysis is sufficient to determine whether we have termination or not, for the general case we need criteria that will distinguish the cases seen above. in the next section we show how to extract this information from labelled transition systems associated with these rules. 4 a termination criterion we study here the termination of single non-deleting rules with a single nac; we will mention in the last section how to extend the results to the case of one rule with multiple nacs, of a set of rules with nacs, and of rule sequences. consider the simple example in figure 6. the rule is a non-deleting rule, so it is not clear how to apply the standard approach based on the ’consumption’ of some finite quantity. nevertheless, proc. gramot 2010 eceasst the rule can only be applied a finite number of times to a finite graph (the rule can be applied no more than twice to each pair of nodes of g). what decreases after each application is, in a sense, the ”distance” between the left hand side l of the rule and the negative application condition n. figure 6: a simple terminating rule. consider now the slightly different rule in figure 7 and notice that it is no longer true that its application must always terminate. after the first application, if the roles of the 2 nodes are reversed in the matching, the remaning part of the negative application condition is generated. but it is also possible to continue adding edges from node 1 to node 2, without ever generating the (rest of the) nac to prevent further applications. notice that these additional edges do not affect the applicability of the rule. figure 7: a simple non terminating rule. in both cases, the rule generates a graph ’between’ the left hand side and the nac. we now abstract from the specific examples to describe this ’approaching’ the nac as a path on a labelled transition system. let p : n n← l r→ r be a rule. let h p = {h p1 ,...,h p k } be the set of all graphs (up to isomorphism w.r.t. the image of l)and m p = {hij : h p i → h p j } be the set of associated morphisms (if they exist) s.t. the following are jointly verified: ∙ for each i = 1,...,k, there exist morphisms l hli→ h pi hin→ n. ∙ for each i, j = 1,...,k, if hij exists, then h l j = h l i ∘h i j and h n i = h i j ∘h n j . the indexing of the set h p is irrelevant, but we can assume that it is compatible with the volume 30 (2010) termination criterion partial order induced by morphisms, so that l = h p1 and n = h p k . this also indicates that this set is not empty. the set m p is not empty either, as it contains at least h1k = n and all the identity morphisms. moreover, both sets are finite since our morphisms are all total and injective, including n : l → n. (we will indicate in section 6 how to relax this condition and allow non-injective n : l → n while keeping the set finite). let vl be the set of nodes in l, and ml = {m1,...,mr} the set of matches mi : vl →vl of vl into itself, including the identity idvl = m1. we construct a labelled transition system l p = (s,λ,−→) as follows: 1. s contains a state si for each graph h p i ∈ h p. each si induces a classification function ci for matches of p such that ci(ml) = true iff ml can be extended to a match on h p i , but not to a match on any other h pj ∈ hp ∖({h p 1 ,h p i }∪{h p t ∣∃hti : h p t → h p i }), i.e. h p i is the biggest graph to which ml can be extended. 2. λ contains a label pi, i = 1,...,r for each morphism in ml. 3. the transition relation −→⊂ s×λ×s is such that (si, pl,s j) ∈−→ (denoted by si pl −→ s j) if applying p with match ml on graph h p i produces a graph for which c j(ml) = true. going back to the examples earlier in this section, the labelled transition system of the rules in figure 6 and figure 7 constructed as above are illustrated in figure 8 and figure 9, respectively (ignore, for now, the labels on the arcs of the transition systems). nopair onepair twopairs p p |nopair|=@|nopair|-1 |onepair|=@|onepair|-1 1 1 p2 l rn p 1 2 22 11 figure 8: a terminating rule. we say that p: ∙ should terminate simply if there exists a chain from s1 to sk in l p with all transitions labelled with p1. ∙ may terminate simply if for all chains from s1 to sk in l p, at least one label is different from p1. proc. gramot 2010 eceasst noedge oneedge twoedges p p |noedge|=@|noedge|-1 |oneedge|=@|oneedge|-1 1 1 p2 l rn p 1 2 22 11 figure 9: a rule which may terminate. ∙ does not terminate simply if there is no chain from s1 to sk in l p. in the definition above, by chain we mean a path which does not contain the same state twice. referring to the examples above, in the first case, there is a path from s1 to sk and the rule should terminate. in the second case, the rule may terminate, as the path from the initial to the final state presents different labels (corresponding to the changing of the roles between the two nodes). however, the presence of a loop on the middle node indicates that the application may not terminate (corresponding to the nodes maintaining their original roles in the match). in these figures, and in the following ones, we have only indicated the states reachable from h p1 after applying the first match, assumed as m1. unfortunately, the presence of a unique path as in figure 8 allows only a ”should” and not a ”must”, as the example in figure 10 illustrates. this is the case of a rule which should terminate simply, as there is a path which consumes the possibility of rule application on the original match, but does not terminate, as the number of matches for the rule increases at each application of p. in order to consider the variation on the number of possible matches induced by the application of p on the minimal context for a given state, let @ ∣ ⋅ ∣: s → ℕ be a function which associates with each state si the number of matches for p on the graph h p i prior to application of p and with ∣ ⋅ ∣: s →ℕ the function defining the number of matches on h pi after the application of p. we use these functions to identify the effect of each transition from a path in l p on the number of matches in the resulting graph and obtain in theorem 1 the first result on termination of p starting on a graph isomorphic to l, i.e. on the minimal context in which p is applicable. theorem 1 [termination on minimal context.] given a graph g isomorphic to l, we have the following: 1. a sufficient condition for the termination of aslongaspossible p end starting on g is that p is of type should terminate simply and on all transitions si p1→ s j the number of matches classified by ci decreases, the number of matches classified by c j can increase at most of volume 30 (2010) termination criterion l rn p 1 2 22 11 |nopair|=@|nopair|+1 |onepair|=@|onepair|-1 |nopair|=@|nopair|+2 nopair onepair twopairs p p 1 1 p2 figure 10: a rule which should terminate simply, but does not terminate. 1, and the number of matches classified by cl , l ∕= i, j does not increase. 2. a sufficient condition for the non-termination of aslongaspossible p end starting on g is that p is of type does not terminate simply or that for each path from s1 to sk there is at least one state si s.t. ∣ si ∣≥ @ ∣ si ∣, for a transition starting from state si, or a state s j s.t. ∣ s j ∣ > @ ∣ s j ∣ for a transition reachable from s j. proof. [sketch] the proof derives from a straightforward counting argument, where the decreasing number of matches prevents the application of a rule on parts of the graph generated by the right hand side, while the ’simply terminating’ condition prevents the repeated application using the same match. more formally, we have: 1. as g is isomorphic to l, we can assume w.l.o.g. that the first application of the rule is for match m1. moreover, for all states si ∕= s1, we have ∣ si ∣= 0. hence, the first application will be associated with a transition s1 p1→ s j, while the difference in the number of matches will follow the laws ∣ s1 ∣< @ ∣ s1 ∣, ∣ s j ∣≤ @ ∣ s j ∣ +1, ∣ si ∣= 0, for si ∕= s1,s j. at each subsequent application on the same match, this match will follow the whole path from si to sk, without ever creating new matches for other states. hence, any chosen match will eventually be forbidden by the nac, while no new matches are created in any intermediate step. as a consequence, p can be applied at most r×k times. 2. if p is of type does not terminate simply, any path starting from s1 will eventually reach a state sl for which there is a loop, i.e. a transition sl p1→ sl . moreover, if there is a state si as described in the hypothesis, each application of the rule will create new matches. as such a state must be reached on any path from s1 to sk, new matches will be formed at each application of the rule on a match on this state. we now generalise this analysis so that it can be applied to any arbitrary graph g, as shown in theorem 2. in particular, we need to consider the possibility of completing partial matches. hence, we extend the construction of l p to include states corresponding to the intermediate states between the empty graph and the state corresponding to l. we label these states as sai proc. gramot 2010 eceasst to distinguish them from those in the original set. we can then integrate the definition of the transitions on the original l p, with the study of the variations in the number of matches for these new states. we now say that p: ∙ must terminate if it should terminate simply and for all transitions si pl→ s j and all states sh ∕= si,s j,sk, we have ∣ si ∣ < @ ∣ si ∣, ∣ s j ∣≤ @ ∣ s j ∣+1 and ∣ sh ∣≤ @ ∣ sh ∣. ∙ may terminate if it may terminate simply and for all states on the path the same condition on matches as above applies. ∙ does not terminate if (it does not terminate simply and for all states from which sk is reachable, there is a state for which the number of matches increases for some transition leading to sk increases) or (it should or may terminate simply, but there is at least one state si on a path from s1 to sk for which ∣ si ∣ ≥ @ ∣ si ∣, for a transition reachable from state si). theorem 2 [main result: termination on arbitrary graphs.] let @ ∣ ⋅ ∣: s → ℕ and ∣ ⋅ ∣: s → ℕ be counting functions as defined above, let p be a rule and g be a finite graph. then the following holds: 1. if rule p is of type must terminate, then the application of aslongaspossible p end on the starting graph g terminates after a finite number of steps. 2. if p is of type does not terminate then the application of aslongaspossible p end on the starting graph g does not terminate. proof. [sketch] 1. let p be a rule of type must terminate and suppose that the iteration of p starting on g does not terminate. this can happen only if there is a chain of transformations g ⇒ g1 ⇒r ⋅⋅⋅⇒r gn such that ∣ {m : l(r) → gn}≥{m : l(r) → g} but now this cannot happen, as each match m : l(r) → g can be used only at most k times because of the condition that the rule should terminate simply. moreover, the second condition states that the number of matches in the state for which the match was chosen can only decrease, so that only the matches originally contained in g can be used. moreover, no new match can be created, as the only way the number of matches in a state s j ∕= sk can increase is by transferring a match from a state si following a transition si → s j. finally, if matches are created in sk, they are immediately forbidden. 2. if the rule is of type does not terminate simply, then the final state sk can be reached only from states not reachable from s1. hence, starting from a match in a state reachable from s1, we will reach a state where the application of the rule can be iterated indefinitely on the same match. in the case that g hosts matches classified in states from which sk can be reached, the remaining sub-conditions in the definition of does not terminate, the application of p on such matches will eventually lead to the creation of new matches. volume 30 (2010) termination criterion this result explains the behavior of the examples seen earlier in this section. in particular, it shows why the rules in figures 8 and 10 behave differently. we are now able to formalize the observations made in section 3 on those simple rules. figures 11–13 show the labelled transition systems for the rules in figures 2–4 (repeated here for convenience), respectively. noedge oneedge p |noedge|=@|noedge|-1 p 1 l rn 1 2 22 11 1 figure 11: a terminating rule, with n ⊂ r. noloop oneloop p |noloop|=@|noloop|+1 p l rn 1 11 1 figure 12: a rule which should terminate simply, but does not terminate, with n ⊂ r. noloop oneloop p |noloop|=@|noloop|-1 threeloop p |oneloop|=@|oneloop|-1 twoloop |twoloop|=@|twoloop|-1 p p l rn 1 11 1 figure 13: a terminating rule, with r ⊂ n. proc. gramot 2010 eceasst there are several cases between the two extremes of the main result, for rules which are of type may terminate. for these rules, depending on the classification of the matches hosted by a graph g, and the choice of the matches to use the application of the rule, one can statically define if a certain sequence of matches will make the rule terminate or not. this is the case of the rule in figure 5 whose labelled transition system is shown, with labels indicating the number of matches, in figure 14. noloop oneloop p p p |noloop|=@|noloop|-1 twoloops p |oneloop|=@|oneloop|-1 1 1 2 l rn 1 2 22 11 1 figure 14: a rule which may terminate, with r ⊂ n. 5 related work termination of (string) rewriting systems has been studied for over 30 years (see [dm79] for example). much more recent is the interest in termination of graph transformation systems. one of the earliest applications is to program optimization and can be found in [ass00], (submitted for publication a few years earlier) where termination criteria are defined for 2 specific types of rules. one kind is a deleting rule, which must remove at least one item from a specific subgraph: since graphs are finite, the removal must eventually stop. the other kind is a nondeleting rule that must add at least one edge incident to a node with a specific label: since no pair of nodes can have more than one edge with the same label, the addition must eventually stop and so is the applicability. the general problem of termination for graph rewriting has been tackled by detlef plump in [plu98], where he proves that it is an undecidable problem. although the framework deals only with ’plain’ transformation rules (i.e., without application conditions), we expect the result to hold in general, for example by using trivial conditions always satisfied. ad hoc sufficient conditions have been analyzed for special cases. in layered graph transformation systems [eed+06] the different types of rules are grouped, establishing an application order. in each of the 2 kinds of layers (deleting and non-deleting) there are no infinite derivation sequences with injective matchings. each rule in a deletion layer must delete at least one item, but not a newly created one. each rule in a non-deletion layer cannot delete items, cannot be applied twice with the same match and cannot use a newly created item for the match. a finite number of layers and a finite initial graphs guarantee termination. volume 30 (2010) termination criterion more recent research [vve+06] uses a similar idea to the one presented here. a graph transformation system is abstracted by ignoring certain structure in a graph and used to define a petri net to represent the number of elements of a certain type. transitions correspond to rule application with ’consumption’ of elements (and reduction of tokens). termination of the gts corresponds then to the petri net exhausting its tokens. 6 concluding remarks we have discussed an approach to analyze termination properties of specific kinds of graph transformations. we have focused on the termination of a single rule p given by an expression of the form aslongaspossible p end, for a non-deleting rule p. termination of plain transformation rules (i.e., rules without application conditions) usually depends upon a function which measures the consumption of a finite commodity and whose value decreases at each application of the rule. when application conditions are present, we can also measure the (hopefully decreasing) distance between the context and the negative application condition. this is what the steps in the labelled transition system represent. the only morphisms used in this paper are total and injective. we can relax this condition, especially for the nac n : l → n by allowing a non-injective one, and then by requiring that for each i = 1,...,k, the morphisms l hli→ h pi hin→ n are such that hli is injective and h i n satisfies the gluing condition with respect to hli . this allows us to avoid taking into account all the intermediate graphs which differ only by an arbitrary number of copies of spurious elements, generated at each application and then collapsed in n. the examples presented in this paper are necessarily small. what we have not investigated (yet) is the feasibility of the approach to real problems, and in particular the complexity of the labelled transition system relatively to the size of the negative application conditions and a systematic way to construct it. the next step is to extend the approach to multiple negative application conditions. some preliminary results are encouraging and we expect to be able to adapt the approach to several rules, each with a single nac. the case of a rule with several nacs can then be reduced to that of a set of rules, all sharing the same morphism but with different nacs. we are also investigating the termination problem for rule sequences using the interaction of the components. although the discussion and the examples are stated in terms of graphs, no specific properties of graphs are used, but only (mono)morphisms and their extensions. the approach can easily be extended to model transformations in high-level replacement (hlr) systems, i.e. algebraic rewriting systems operating on objects and morphisms in adhesive hlr categories [epph06]. bibliography [ass00] u. assmann. graph rewrite systems for program optimization. acm trans. program. lang. syst. 22(4):583–637, 2000. doi:http://doi.acm.org/10.1145/363911.363914 proc. gramot 2010 http://dx.doi.org/http://doi.acm.org/10.1145/363911.363914 eceasst [bhp06] p. bottoni, k. hoffmann, f. parisi-presicce. termination of algebraic rewriting with inhibitors. in karsai and taentzer (eds.), proc. gramot 2006. eceasst 4. 2006. [bhpt05] p. bottoni, k. hoffmann, f. parisi-presicce, g. taentzer. high-level replacement units and their termination properties. journal of visual languages and computing 16:485–507, 2005. [der87] n. dershowitz. termination of rewriting. journal of symbolic computation 3(1& 2):69–115, 1987. corrigendum: 4,3 (dec. 1987), 409-410. [dm79] n. dershowitz, z. manna. proving termination with multiset orderings. commun. acm 22(8):465–476, 1979. doi:http://doi.acm.org/10.1145/359138.359142 [eed+06] h. ehrig, k. ehrig, j. delara, g. taentzer, d. varro, s. varro-gyapay. termination criteria for model transformation. in proc. fase 2005. lncs 3442, pp. 49–63. springer, 2006. [eept06] h. ehrig, k. ehrig, u. prange, g. taentzer. fundamentals of algebraic graph transformation. springer, 2006. [epph06] h. ehrig, j. padberg, u. prange, a. habel. adhesive high-level replacement systems: a new categorical framework for graph transformation. fundamenta informaticae 74(1):1–29, 2006. [khe03] j. m. küster, r. heckel, g. engels. defining and validating transformations of uml models. in proc. hcc 2003. pp. 145–152. ieee computer society, 2003. [plu98] d. plump. termination of graph rewriting is undecidable. fundamenta informaticae 33(2):201–209, 1998. [vve+06] d. varro, s. varro-gyapay, h. ehrig, u. prange, g. taentzer. termination analysis of model transformations by petri nets. in proc. icgt 2006. lncs 4178, pp. 260–274. springer, 2006. volume 30 (2010) http://dx.doi.org/http://doi.acm.org/10.1145/359138.359142 introduction formal background a naive approach a termination criterion related work concluding remarks towards theorem proving graph grammars using event-bpartially supported by cnpq/brazil. electronic communications of the easst volume 30 (2010) international colloquium on graph and model transformation on the occasion of the 65th birthday of hartmut ehrig (gramot 2010) towards theorem proving graph grammars using event-b leila ribeiro, fernando luís dotti, simone andré da costa and fabiane cristine dillenburg 16 pages guest editors: claudia ermel, hartmut ehrig, fernando orejas, gabriele taentzer managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst towards theorem proving graph grammars using event-b∗ leila ribeiro1, fernando luís dotti2, simone andré da costa3 and fabiane cristine dillenburg4 1 leila@inf.ufrgs.br 4 fabiane.dillenburg@inf.ufrgs.br instituto de informática universidade federal do rio grande do sul, brazil 2 fernando.dotti@pucrs.br faculdade de informática pontifícia universidade católica do rio grande do sul, brazil 3 simone.costa@ufpel.edu.br institudo de física e matermática universidade federal de pelotas, brazil abstract: graph grammars may be used as specification technique for different kinds of systems, specially in situations in which states are complex structures that can be adequately modeled as graphs (possibly with an attribute data part) and in which the behavior involves a large amount of parallelism and can be described as reactions to stimuli that can be observed in the state of the system. the verification of properties of such systems is a difficult task due to many aspects: the systems in many situations involve an infinite number of states; states themselves are complex and large; there are a number of different computation possibilities due to the fact that rule applications may occur in parallel. there are already some approaches to verification of graph grammars based on model checking, but in these cases only finite state systems can be analyzed. other approaches propose overand/or underapproximations of the state-space, but in this case it is not possible to check arbitrary properties. in this work, we propose to use the event-b formal method and its theorem proving tools to analyze graph grammars. we show that a graph grammar can be translated into an event-b specification preserving its semantics, such that one can use several theorem provers available for event-b to analyze the reachable states of the original graph grammar. the translation is based on a relational definition of graph grammars, that was shown to be equivalent to the single-pushout approach to graph grammars. keywords: graph grammars, theorem proving, event-b ∗ partially supported by cnpq/brazil. 1 / 16 volume 30 (2010) mailto:leila@inf.ufrgs.br mailto:fabiane.dillenburg@inf.ufrgs.br mailto:fernando.dotti@pucrs.br mailto:simone.costa@ufpel.edu.br towards theorem proving graph grammars using event-b 1 introduction graph grammars [ehr79, roz97] are a formal description technique suitable for the specification of distributed and reactive systems. the basic idea of this formalism is to model the states of a system as graphs and describe the possible state changes as rules (where the leftand righthand sides are graphs). the operational behavior of the system is expressed via applications of these rules to graphs depicting the current states of the system. graph grammars are appealing as specification formalism because they are formal and based on simple, but powerful, concepts to describe behavior. at the same time they also have a nice graphical layout that helps even non-theoreticians to understand a specification. at the same time they also have a nice graphical layout that helps even non-theoreticians to understand a specification. the verification of graph grammar models through model-checking is currently supported by various approaches. although model checking is an important analysis method, it has as disadvantage the need to build the complete state space, which can lead to the state explosion problem. much progress has been made to deal with this difficulty, and a lot of techniques have increased the size of the systems that could be verified [cgj+01]. baldan and könig proposed [bk02] approximating the behavior of (infinite-state) graph transformation systems by a chain of finite underor overapproximations, at a specific level of accuracy of the full unfolding [bcmr07] of the system. however, as [dhr+07] emphasizes, these approaches that derive the model as approximations can result in inconclusive error/verification reports. besides model checking, theorem proving [rv01, cw96] is another well-established approach used to analyze systems. theorem proving is a technique where both the system and its desired properties are expressed as formulas in some mathematical logic. a logical description defines the system, establishing a set of axioms and inference rules. the verification process consists in finding a proof of the required property from the axioms or intermediary lemmas of the system. in contrast to model checking, theorem proving can deal directly with infinite state spaces and it relies on techniques such as structural induction to construct proofs over infinite domains. the use of this technique may require interaction with a human; however, via this interactive process the user often gains very useful perceptions into the system or the property being proved. each verification technique has arguments for and against its use, but we can say that modelchecking and theorem proving are complementary. most of the existing approaches use model checkers to analyze properties of computations, that is, properties over the sequences of steps a system may engage in. properties about reachable states are handled, if at all possible, only in restricted ways. in this work, our main aim is to provide a means to prove properties of reachable graphs using the theorem proving technique. in previous work [cr09a] we proposed a relational approach to graph grammars, providing an encoding of graphs and rules into relations. this enabled the use of logic formulas to express properties of reachable states of a graph grammar. this encoding was shown to be equivalent to the single-pushout approach to graph grammars, and was inspired by courcelle’s research about logic and graphs [cou97]. courcelle investigates in various papers [cou94, cou97, cou04] the representation of graphs and hypergraphs by relational structures as well as the expressiveness of their properties by logical languages. in [cou94] the description of graph properties and the transformation of graphs proc. gramot 2010 2 / 16 eceasst in monadic second-order logic is proposed. however, these works are not particularly interested in effectively verifying the properties of graph transformation systems (gtss). since theorem provers, in general, works efficiently with specifications in relational style, we extended the relational representation of graphs to graph grammar models and use such representation for the formal analysis of reactive systems through the theorem proving technique. other authors have investigated the analysis of gtss based on relational logic or set theory. baresi and spoletini [bs06] explore the formal language alloy to find instances and counterexamples for models and gtss. with alloy, they only analyze the system for a finite scope, whose size is user-defined. strecker [str08], aiming to verify structural properties of gtss, proposes a formalization of graph transformations in a set-theoretic model. his goal is to obtain a language for writing graph transformation programs and reasoning about them. nevertheless, the language has only two statements, one to apply a rule repeatedly to a graph, and another to apply several rules in a specific order to a graph. until now, the work just presents a glimpse of how to reason about graph transformations. in this paper we use event-b to analyze properties of graph grammars. event-b [ah07] is a state-based formal method closely related to classical b [abr05]. it has been successfully used in several applications, and there is tool support for both model specification and analysis. there are a series of powerful theorem provers that can be used to analyze event-b specifications[abhv06, dep]. due to the similarity between event-b models and graph grammar specifications, specially concerning the rule-based behavior, in this paper we propose to translate graph grammar specifications in event-b structures, such that it is possible to use the event-b provers to demonstrate properties of a graph grammar. this translation is based on the relational definition of graph grammars. the paper is organized as follows. section 2 presents the relational approach of graph grammars. section 3 briefly introduces the event b formalism. section 4 shows how a graph grammar can be translated into an event-b program. section 5 contains some final remarks. 2 relational approach to graph grammars graph grammars are a generalization of chomsky grammars from strings to graphs suitable for the specification of distributed, asynchronous and concurrent systems. the basic notions behind this formalism are: states are represented by graphs and possible state changes are modeled by rules, where the leftand right-hand sides are graphs. we use a relational and logical approach for the description of graph grammars: graphs and graph morphisms are described as relational structures [cr09a, cr10], that is, they are defined as tuples formed by a set and by a family of relations over this set. proofs about the welldefinedness of these definitions were detailed in [cr09b]. definition 1 (relational structures) let r be a finite set of relation symbols, where each r∈r has an associated positive integer called its arity, denoted by ρ(r). an r-structure is a tuple s = 〈ds,(rs)r∈r〉 such that ds is a possible empty set called the domain of s and each rs is a ρ(r)-ary relation on ds, i.e., a subset of d ρ(r) s . r(d1,...,dn) holds in s if and only if (d1,...,dn)∈ rs, where d1,...,dn ∈ ds. 3 / 16 volume 30 (2010) towards theorem proving graph grammars using event-b a relational graph |g| is a tuple composed of a set, the domain of the structure, representing all vertices and edges of |g| and by two finite relations: a unary relation, vert g, defining the set of vertices of |g| and a ternary relation incg representing the incidence relation between vertices and edges of |g|. the uniqueness edge condition assures that the same edge doesn’t connect different vertices. definition 2 (relational graph) let rgr ={vert,inc} be a set of relations, where vert is unary and inc is ternary. a relational graph is a rgr-structure |g|= 〈dg, (rg)r∈rgr〉, where: • dg = vg ∪eg is the union of sets of possible vertices and edges of |g|, respectively (we always assume that vg ∩eg = ∅); • vertg ⊆vg, with vertg(x) iff x is a vertex of |g|; • incg ⊆ eg ×vg ×vg, with incg(x,y,z) iff x is a directed edge that links vertex y to vertex z in |g|. such that the following condition is satisfied: • uniqueness edge condition. ∀x,y,z,y′,z′, [incg(x,y,z)∧incg(x,y′,z′)⇒ y = y′∧z = z′]. a relational graph morphism |g| from a relational graph |g| to a relational graph |h| is obtained through two binary relations: one to relate vertices (gv ) and other to relate edges (ge ). the type consistency conditions state that if two vertices are related by gv then the first one must be a vertex of |g| and the second one a vertex of |h|, and if two edges are related by ge , then the first one must be an edge of |g| and the second one an edge of |h|. the (morphism) commutativity condition assures that the mapping of edges preserves the mapping of source and target vertices. definition 3 (relational graph morphism) let |g| = 〈vg ∪ eg,{vertg,incg}〉 and |h| = 〈vh ∪eh,{verth,inch}〉 be relational graphs. a relational graph morphism |g| from |g| to |h| is defined by a set |g|={gv ,ge} of binary relations where: • gv ⊆vg ×vh is a partial function that relates vertices of |g| to vertices of |h|; • ge ⊆ eg ×eh is a partial function that relates edges of |g| to edges of |h|; such that the following conditions are satisfied: • type consistency conditions. ∀x,x′, [gv (x,x′)]⇒ vertg(x)∧verth(x′); and [ge(x,x′)]⇒∃y,y′,z,z′[incg(x,y,z)∧inch(x′,y′,z′)]; • morphism commutativity condition. ∀x,y,z,x′,y′,z′, [ge(x,x′)∧incg(x,y,z)∧inch(x′,y′,z′)⇒ gv (y,y′) ∧ gv (z,z′)]. |g| is called total/injective if relations gv and ge are total/injective functions. a relational typing morphism is a relational graph morphism that has the role of typing all elements of a graph |g| over a graph |t|. proc. gramot 2010 4 / 16 eceasst definition 4 (relational typing morphism) let |g| and |t| be relational graphs. a relational typing morphism from |g| over |t| is defined by a total relational graph morphism |t g| = {t gv ,t g e } from |g| to |t|. a relational typed graph is defined by two relational graphs together with a relational typing morphism. a relational typed graph morphism between graphs typed over the same graph is defined by a relational graph morphism. a (typed morphism) compatibility condition assures that the mappings of vertices and edges preserve types. definition 5 (relational typed graph, relational typed graph morphism) a relational typed graph is given by a tuple |gt| = 〈|g|,|t g|,|t|〉 where |g| and |t| are relational graphs and |t g| = {t gv ,t g e } is a relational typing morphism from |g| over |t|. a relational (typed) graph morphism from |gt| to |h t| is defined by a relational graph morphism |g|={gv ,ge} from |g| to |h|, such that the typed morphism compatibility condition is satisfied: • (typed morphism) compatibility condition. ∀x,x′,y, [gv (x,x′)∧t gv (x,y)⇒ t h v (x ′,y)]; and [ge(x,x′)∧t ge (x,y)⇒ t h e (x ′,y)]. a relational rule specifies a possible behaviour of the system. it consists of a left-hand side |lt|, describing items that must be present in a state to enable the application of the rule and a right-hand side |rt|, expressing items that will be present after the application of the rule. we require that rules do not collapse vertices or edges (are injective) and do not delete vertices. definition 6 (relational rule) a relational rule α is given by a tuple 〈|lt|,|α|,|rt|〉 where: • |lt|= 〈|l|,|t l|,|t|〉 and |rt|= 〈|r|,|t r|,|t|〉 are relational typed graphs; • |α| = {αv ,αe} is an injective relational typed graph morphism from |lt| to |rt|, such that αv is a total function on the set of vertices. a relational graph grammar is composed by a relational type graph, characterizing the types of vertices and edges allowed in a system, an initial relational graph, representing the initial state of a system and a set of relational rules, describing the possible state changes that can occur in a system. definition 7 (relational graph grammar) let rgg = {vertt , inct , vertg0,incg0, t g0v , t g0 e , (vertli, incli, t liv , t li e ,vertri,incri, t ri v , t ri e , αiv , αie )i∈{1,...,n}} be a set of relation symbols. a relational graph grammar is a rgg-structure |gg|= 〈dgg,(r)r∈rgg〉 where • dgg = vgg ∪egg is the set of vertices and edges of the graph grammar, where: vgg ∩ egg = ∅, vgg = vt ∪vg0 ∪(vli ∪vri)i∈{1,...,n} and egg = et ∪eg0 ∪(eli ∪eri)i∈{1,...,n}. • |t|= 〈vt ∪et ,{vertt ,inct}〉 defines a relational graph (the type of the grammar). • |g0t| = 〈|g0|,|t g0|,|t|〉, with |g0| = 〈vg0 ∪eg0,{vertg0,incg0}〉 and |t g0| = {t g0v ,t g0 e }, defines a relational typed graph (the initial graph of the grammar). 5 / 16 volume 30 (2010) towards theorem proving graph grammars using event-b • each collection (vertli, incli, t liv , t li e , vertri,incri, t ri v , t ri e , αiv , αie ) defines a rule: – |lit|= 〈|li|,|t li|,|t|〉, with |li|= 〈vli∪eli,{vertli,incli}〉 and |t li|={t liv ,t li e }, defines a relational typed graph (the left-hand side of the rule). – |rit| = 〈|ri|,|t ri|,|t|〉, with |ri| = 〈vri ∪eri,{vertri,incri}〉 and |t ri| = {t riv ,t ri e }, defines a relational typed graph (the right-hand side of the rule). – 〈|lit|,|αi|,|rit|〉, with |αi|={αiv ,αie}, defines a relational rule. given a relational rule and a state, we say that this rule is applicable in this state if there is a match, that is, an image of the left-hand side of the rule in the state. the operational behaviour of a graph grammar is defined in terms of applications of the rules to some state graph. definition 8 (relational match) let 〈|lt|,|α|,|rt|〉 be a relational rule, with |lt| = 〈|l|,{t lv , t le},|t|〉 and |r t|=〈|r|,{t rv ,t r e},|t|〉. let |g t|=〈|g|,|t g|,|t|〉 be a relational typed graph with t g = {t gv ,t g e }. a relational match |m| of the given rule in |g t| is defined by a total relational typed graph morphism |m|={mv ,me} from |lt| to |gt|, such that the following conditions are satisfied: • me is injective; • match compatibility condition. ∀x,x′,y [mv (x,x′)∧t lv (x,y)⇒ t g v (x ′,y)], [me(x,x′)∧t le(x,y)⇒ t g e (x ′,y)]. since we restrict our approach to injective rules that can not delete vertices and matches that can no identify edges, the application of a given rule to a match in a state essentially removes from the state all elements that are in the left-hand side of the rule that are not mapped to the right-hand side, and creates in the state all new elements of the right-hand side of the rule. the rest of the state remains unchanged. given a rule 〈|lit|,|αi|,|rit|〉 of a graph grammar and a corresponding match |m|={mv ,me} in the initial state of the graph grammar, formulas θvertg′ , θincg′ , θt g′v , θt g′e described below define the graph resulting of the rule application. the elements that satisfy the stated formulas θrel are those that define the relations rel of the resulting typed graph |g′t|. table 1 presents the explanations for the notation used in θ specifications. θvertg′(x) = vertg0(x) ∨ nvertri(x) θincg′(x,y,z) = nincg0(x,y,z) ∨ nincri(x,y,z). θt g ′ v (x,t) = nvertg0(x,t) ∨ [ nvertri(x) ∧ t riv (x,t) ] . θt g ′ e (x,t) = nt g0e (x,t) ∨ t ri e (x,t). this construction is described by a first-order definable transduction (i.e., by a tuple of firstorder formulas) on relational structures associated to graph grammars. details can be found in [cr09a]. proc. gramot 2010 6 / 16 eceasst table 1: formulas used in θ specifications notation formula intuitive meaning vertg0(x) vertg0(x) x is a vertex of graph |g0|. t riv (x,y) t ri v (x,y) x is a vertex of |ri| of type y. t rie (x,y) t ri e (x,y) x is an edge of graph |ri| of type y. nvertri(x) vertri(x)∧@y ( αiv (y,x) ) x is a vertex of graph |ri| created by rule |αi|. nincg0(x,y,z) incg0(x,y,z)∧@w ( me(w,x) ) x is an edge of graph |g0| that is not image of the match. n(r,y) { ∃v ( αiv (v,r)∧mv (v,y) ) if r 6= y @v αiv (v,r) if r = y n relates vertices r and y if (i) r = y and r is created by rule |αi|, or (ii) there is a vertex v preserved by the rule whose images in ri and g0 are r and y, resp. nincri(x,y,z) ∃r,s [ incri(x,r,s)∧n(r,y)∧n(s,z) ] x is an edge created by rule |αi| (connecting existing or newly created vertices. nvertg0(x,t) vertg0(x)∧t g0v (x,t) x is a vertex of |g0| of type t. nvertri(x,t) vertri(x)∧t riv (x,t) x is a vertex of |ri| of type t. nt g0e (x,t) ∃y,z ( incg0(x,y,z) ) ∧ @w ( me(w,x) ) ∧ ∧ t g0e (x,t) x is an edge of graph |g0| of type t that is not image of the match. 7 / 16 volume 30 (2010) towards theorem proving graph grammars using event-b 3 event-b event-b [ah07] is a state-based formalism closely related to classical b [abr05] and action systems [bs89]. definition 9 (event-b model, event) an event-b model is defined by a tuple ebmodel = (c,s,p,v, i,ri,e) where c are constants and s are sets known in the model; v are the model variables1; p(c,s) is a collection of axioms constraining c and s; i(c,s,v) is a model invariant limiting the possible states of v s.t. ∃c,s,v ·p(c,s)∧i(c,s,v) i.e. p and i characterise a nonempty set of model states; ri(c,s,v′) is an initialisation action computing initial values for the model variables; and e is a set of model events. given states v,v′ an event is a tuple e = (h,s) where h(c,s,v) is the guard and s(c,s,v,v′) is the before-after predicate that defines a relation between current and next states. we also denote an event guard by h(v), the before-after predicate by s(v,v′) and the initialization action by ri(v′). an event-b model is assembled from two parts, a context which defines the triple (c,s,p) and a machine which defines the other elements (v,i,ri,e). model correctness is demonstrated by generating and discharging a collection of proof obligations. the model consistency condition states that whenever an event on an initialisation action is attempted, there exists a suitable new state v′ such that the model invariant is maintained i(v′). this is usually stated as two separate proof obligations: a feasibility (i(v)∧h(v)⇒∃v′ ·s(v,v′)) and an invariant satisfaction obligation (i(v)∧ h(v)∧ s(v,v′) ⇒ i(v′)). the behaviour of an event-b model is the transition system defined as follows. definition 10 (event-b model behaviour) given ebmodel = (c,s,p,v,i, ri,e), its behaviour is given by a transition system bst = (bstate,bs0,→) where: bstate = {〈v〉|v is a state}∪ u nde f , bs0 = u nde f , and →⊆ bstate×bstate is the transition relation given by the rules: start ri(v′)∧i(v′) u nde f →〈v′〉 transition ∃(h,s)∈ e ·i(v)∧h(v)∧s(v,v′)∧i(v′) 〈v〉→〈v′〉 according to rule start the model is initialized to a state satisfying ri ∧i and then, as long as there is an enabled event (rule transition), the model may evolve by firing an enabled event and computing the next state according to the event’s before-after predicate. events are atomic. in case there is more than one enabled event at a certain state, the choice is non-deterministic. the semantics of an event-b model is given in the form of proof semantics, based on dijkstra’s work on weakest preconditions [dij76]. an extensive tool support through the rodin platform makes event-b especially attractive [dep]. an integrated eclipse-based development environment is actively developed, and open to third-party extensions in the form of eclipse plug-ins. the main verification technique is 1 for convenience, as in [abr05], no distinction is made between a set of variables and a state of a system. proc. gramot 2010 8 / 16 eceasst theorem proving supported by a collection of theorem provers, but there is also some support for model checking. 4 verification of graph grammars using event-b the behavior of an event-b model is similar to a graph grammar: there is a notion of state (given by a set of variables in event-b, and by a graph in a graph grammar) and a step is defined by an atomic operation on the current state (an event that updates variables in event-b and a rule application in a graph grammar). each step should preserve properties of the state. in event-b, these properties are stated as invariants. in a graph grammar, the properties that are inherently guaranteed to be preserved are related to the graph structure (only well-formed graphs can be generated). now, we present a way to model each structure of a graph grammar gg in event-b such that it is possible to use the event-b provers to demonstrate properties of a graph grammar. we will use an example to describe how graphs, typed graphs and rules can be defined in event-b. the example is depicted in figure1. vertex1 vertex2 edge2 edge1 (a) type graph t vertex2 edge2 edge1 g t tg 1 1 vertex1 (b) start graph gt e1_r1v1_r1v1_l1 e1_l1 v2_r1 (c) rule α 1 figure 1: example of graph grammar graphs: according to def. 2 and def. 7, sets vgg and egg contain all possible vertices and edge names that may appear in graphs of this relational structure. we will define these sets as vgg = vertt ∪n, where vertt is the set of names used as vertex types in gg (we assume 9 / 16 volume 30 (2010) towards theorem proving graph grammars using event-b that vertt ∩n = ∅); egg = edget ∪n, where edget is the set of names used as edge types in gg (we assume that edget ∩n = ∅). moreover, we assume that vertt ∩edget = ∅. the type graph t is defined in an event-b context as described in figure 2, where we define all vertex and edge types as constants. in the axioms, we define these sets explicitly (for example, axiom axm1 means that vertt = {vertex1,vertex2}). we also define the functions sourcet and targett that respectively designate the source and target vertex of each edge. text after a // is a comment. here, instead of using the ternary inc relation we used a set of edges and two binary relations (source and target) to define the edges of a graph. this is an equivalent formulation that is convenient to use in event-b because it eases the proof of some proof obligations. context ctx_gg sets vertt // (type graph ) vertices edget // (type graph ) edges constants vertex1 vertex2 edge1 edge2 sourcet // (type graph ) source function targett // (type graph ) target function axioms axm1 : partition(vertt,{vertex1},{vertex2}) axm2 : partition(edget,{edge1},{edge2}) axm3 : sourcet ∈ edget →vertt axm4 : partition(sourcet,{edge1 7→ vertex1},{edge2 7→ vertex1}) axm5 : targett ∈ edget →vertt axm6 : partition(targett,{edge1 7→ vertex1},{edge2 7→ vertex2}) end figure 2: event-b type graph instances of vertices and edges that appear in graphs representing states will be described by natural numbers. it is not necessary to have distinct numbers for vertices and edges: a graph may have a vertex with identity 1 as well as an edge with identity 1, these elements will be different because one will be mapped to a vertex type and the other to an edge type. a graph typed over a type graph t is modeled by a set of variables describing its set of vertices, set of edges, source, target and typing functions. it is possible to state the compatibility conditions of types and source and target of edges (stated in def. 3) as invariants. however, since we will always generate well-formed graphs (the start graph is well-formed and events implement the single-pushout construction), we will skip these invariants (each invariant that is used generates proof obligations and therefore it is advisable to use only the necessary ones). figure 3 shows the definition of a graph g typed over t . invariants proc. gramot 2010 10 / 16 eceasst are used to define the types of the variables (for example, tg_v is a total function from vertg to vertt and tg_e is a total function from edgeg to edget ). machine mch_gg sees ctx_gg variables vertg // (graph) vertices edgeg // (graph) edges sourceg // (graph) source function targetg // (graph) target function tg_v // typing of vertices tg_e // typing of edges invariants inv_vertg : vertg ∈p(n) inv_incg : edgeg ∈p(n) inv_sourceg : sourceg ∈ edgeg→vertg inv_targetg : targetg ∈ edgeg→vertg inv_tg_v : tg_v ∈ vertg→vertt inv_tg_e : tg_e ∈ edgeg→edget events initialisation begin act1 : vertg :={10} act2 : edgeg :={20} act3 : sourceg :={20 7→ 10} act4 : targetg :={20 7→ 10} act5 : tg_v :={10 7→ vertex1} act6 : tg_e :={20 7→ edge1} end figure 3: event-b graph g there is special event in an event-b model that is executed before any other. this is the initialization event. in our encoding, this event will be used to create the start graph of a graph grammar. this is done by assigning initial values to the variables that correspond to graph g (see figure 3). within an event, the order in which attributions occur in nondeterministic. rules: leftand right-hand sides of rules are graphs, and thus will have representations as defined previously. additionally, we have to define the partial morphism (αv ,αe) that maps elements from the leftto the right-hand side of the rule. the event-b enconding of ule α 1 depicted in figure 1 is shown in figure 4. since rules do not change during execution, their structures will be defined as constants. the behavior of a rule is described by an event (for the example, by event al pha1 in figure 5). whenever there are concrete values for variables mv , me, newv and newe that satisfies the guard conditions, the event may occur. guard conditions grd1, grd2 and grd5 to grd7 assure that the pair (mv,me) is actually a match from the left-hand side of the 11 / 16 volume 30 (2010) towards theorem proving graph grammars using event-b sets vertl1 edgel1 vertr1 edger1 constants v1_l1 // vertex of lhs e1_l1 // edge of lhs v1_r1 v2_r1 // vertices of rhs e1_r1 // edge of rhs sourcel1 targetl1 sourcer1 targetr1 tl1_v // (rule 1) typing vertices of lhs tl1_e // (rule 1) typing edges of lhs tr1_v // (rule 1) typing vertices of rhs tr1_e // (rule 1) typing edges of rhs alpha1v // (rule 1) rule morphism: mapping vertices alpha1e // (rule 1) rule morphism: mapping edges axioms // graph l1: axm7 : partition(vertl1,{v1_l1}) axm8 : partition(edgel1,{e1_l1}) axm9 : sourcel1 ∈ edgel1→vertl1 axm10 : partition(sourcel1,{e1_l1 7→ v1_l1}) axm11 : targetl1 ∈ edgel1→vertl1 axm12 : partition(targetl1,{e1_l1 7→ v1_l1}) axm13 : tl1_v ∈ vertl1→vertt axm14 : partition(tl1_v,{v1_l1 7→ vertex1}) axm15 : tl1_e ∈ edgel1→edget axm16 : partition(tl1_e,{e1_l1 7→ edge1}) // graph r1: axm17 : partition(vertr1,{v1_r1},{v2_r1}) axm18 : partition(edger1,{e1_r1}) axm19 : sourcer1 ∈ edger1→vertr1 axm20 : partition(sourcer1,{e1_r1 7→ v1_r1}) axm21 : targetr1 ∈ edgel1→vertr1 axm22 : partition(targetr1,{e1_r1 7→ v2_r1}) axm23 : tr1_v ∈ vertr1→vertt axm24 : partition(tr1_v,{v1_r1 7→ vertex1},{v2_r1 7→ vertex2}) axm25 : tr1_e ∈ edger1→edget axm26 : partition(tr1_e,{e1_r1 7→ edge2}) // rule morphism alpha1: axm27 : alpha1v ∈ vertl1→vertr1 axm28 : partition(alpha1v,{v1_l1 7→ v1_r1}) axm29 : alpha1e ∈ edgel1 7→edger1 axm30 : alpha1e = ∅ end figure 4: event-b rule strucure proc. gramot 2010 12 / 16 eceasst rule to the state graph g (see def. 8). guard conditions grd3 and grd4 assure that newv and newe are new fresh elements (a new vertex and a new edge identifier, not belonging to graph g). the actions update the state graph (graph g) according to the rule. in this example one loop edge is deleted and a new vertex and a new edge are created. a vertex newv with type vertex2, and an edge newe with type edge2 are generated. the source of this new edge is the image of the only vertex in the left-hand side of the rule in g and the target is the newly created vertex. the relational operators2 used in the definition of the actions implement the formulas that define rule application in sect. 2. this is an encoding of rule α 1, there is a concrete choice for identifiers of elements created by the rule (newv and newe). for this reason and to obtain a more efficient encoding, we did not use explicitly the functions sourcer1, targetr1, al pha1v and al pha1e to define this event (but they were implicitly used to define the actions). for example, to obtain the set of vertices of the resulting graph we used the existing set of vertices vertg and added a set containing newv , instead of taking a vertex of r1 that was not in the image of al pha1v (there is a vertex of r1 that is not in the image of al pha1v , that is v2_r2, and by giving it the name newv in the generated graph we assure that this name did not occur already in vertg). note that this choice of representation was dependent on the event-b language, if we were to translate graph grammars to a different language, other encodings of the relational representation might be more suitable. proving properties: once the start graph and all rules are represented in the event-b model, the property to be proved can be stated as an invariant. for example, we could add the invariant card(edgeg)≤ 2, meaning that no reachable graph can have more than 2 edges. for the given example, this property is true, and this can be easily proven automatically by the rodin platform. 5 final remarks in this paper we have defined an event-b model that faithfully describes the behavior of a given graph grammar. to define this model, we used the relational definition of graph grammars, that was proven to be equivalent to the spo approach. now, it is possible to use the existing theorem provers for event-b to prove properties of graph grammars, for example, using the rodin platform. this is an initial work in using event-b to help proving properties of graph grammars. besides implementation, case studies are necessary to evaluate and improve the proposed approach. another interesting topic for further research is to investigate to which extent the theory of refinement, that is very well-developed in event-b, can be used to validate a stepwise development based on graph grammars. 2 the relational operators used to define this event are: \ (minus), ∪ (union), c− (domain subtraction). 13 / 16 volume 30 (2010) towards theorem proving graph grammars using event-b events event alpha1 =̂ any mv me newv newe where grd1 : mv ∈ vertl1→vertg // total on vertices grd2 : me ∈ edgel1�edgeg // total and injective on edges grd3 : newv ∈n\vertg // newv is a fresh vertex name grd4 : newe ∈n\edgeg // newe is a fresh edge name grd5 : ∀v·v ∈ vertl1⇒tl1_v(v) = tg_v(mv(v)) // vertex type compatibility grd6 : ∀e·e ∈ edgel1⇒tl1_e(e) = tg_e(me(e)) edge type compatibility grd7 : ∀e·e ∈ edgel1⇒mv(sourcel1(e)) = sourceg(me(e))∧mv(targetl1(e)) = targetg(me(e)) source/target compatibility then act1 : vertg := vertg ∪{newv} act2 : edgeg := (edgeg\{me(e1_l1)})∪{newe} act3 : sourceg := ({me(e1_l1)}c−sourceg)∪{newe 7→ mv(v1_l1)} act4 : targetg := ({me(e1_l1)}c−targetg)∪{newe 7→ newv} act5 : tg_v := tg_v ∪{newv 7→ vertex2} act6 : tg_e := ({me(e1_l1)}c−tg_e)∪{newe 7→ edge2} end end figure 5: event-b rule event proc. gramot 2010 14 / 16 eceasst bibliography [abhv06] j.-r. abrial, m. j. butler, s. hallerstede, l. voisin. an open extensible tool environment for event-b. in liu and he (eds.), icfem. lecture notes in computer science 4260, pp. 588–605. springer, 2006. [abr05] j. r. abrial. the b-book: assigning programs to meanings. cambridge university press, 2005. [ah07] j.-r. abrial, s. hallerstede. refinement, decomposition, and instantiation of discrete models: application to event-b. fundam. inform. 77(1-2):1–28, 2007. [bcmr07] p. baldan, a. corradini, u. montanari, l. ribeiro. unfolding semantics of graph transformation. inf. comput. 205(5):733–782, 2007. doi:http://dx.doi.org/10.1016/j.ic.2006.11.004 [bk02] p. baldan, b. könig. approximating the behaviour of graph transformation systems. in proceedings of icgt ’02 (international conference on graph transformation). lncs 2505, pp. 14–29. springer, 2002. [bs89] r.-j. back, k. sere. stepwise refinement of action systems. in snepscheut (ed.), proceedings of the international conference on mathematics of program construction, 375th anniversary of the groningen university. pp. 115–138. springer, london, uk, 1989. [bs06] l. baresi, p. spoletini. on the use of alloy to analyze graph transformation systems. in corradini et al. (eds.), icgt. lncs 4178, pp. 306–320. springer, 2006. [cgj+01] e. m. clarke, o. grumberg, s. jha, y. lu, h. veith. progress on the state explosion problem in model checking. in informatics 10 years back. 10 years ahead. pp. 176–194. springer, london, uk, 2001. [cou94] b. courcelle. monadic second-order definable graph transductions: a survey. theoretical computer science 126(1):53–75, 1994. [cou97] b. courcelle. the expression of graph properties and graph transformations in monadic second-order logic. pp. 313–400 in [roz97]. [cou04] b. courcelle. recognizable sets of graphs, hypergraphs and relational structures: a survey. in calude et al. (eds.), developments in language theory. lncs 3340, pp. 1–11. springer, 2004. [cr09a] s. a. da costa, l. ribeiro. formal verification of graph grammars using mathematical induction. electronic notes theoretical computer science 240:43–60, 2009. doi:http://dx.doi.org/10.1016/j.entcs.2009.05.044 [cr09b] s. a. da costa, l. ribeiro. relational and logical approach to graph grammars. technical report 359, porto alegre: instituto de informática/ufrgs, 2009. 15 / 16 volume 30 (2010) http://dx.doi.org/http://dx.doi.org/10.1016/j.ic.2006.11.004 http://dx.doi.org/http://dx.doi.org/10.1016/j.entcs.2009.05.044 towards theorem proving graph grammars using event-b [cr10] s. a. da costa, l. ribeiro. formal verification of graph grammars using mathematical induction. science of computer programming, 2010. doi:http://dx.doi.org/10.1016/j.scico.2010.02.006 [cw96] e. m. clarke, j. m. wing. formal methods: state of the art and future directions. acm computing surveys 28(4):626–643, 1996. doi:http://doi.acm.org/10.1145/242223.242257 [dep] deploy. event-b and the rodin platform. http://www.event-b.org/ (last accessed 16 march 2010). rodin development is supported by european union ict projects deploy (2008 to 2012) and rodin (2004 to 2007). [dhr+07] m. b. dwyer, j. hatcliff, r. robby, c. s. pasareanu, w. visser. formal software analysis emerging trends in software model checking. in fose ’07: 2007 future of software engineering. pp. 120–136. ieee computer society, 2007. doi:http://dx.doi.org/10.1109/fose.2007.6 [dij76] e. dijkstra. a discipline of programming. prentice-hall international, 1976. [ehr79] h. ehrig. introduction to the algebraic theory of graph grammars. in 1st international workshop on graph grammars and their application to computer science and biology. lecture notes in computer science 73, pp. 1–69. springer-verlag, germany, 1979. [roz97] g. rozenberg (ed.). handbook of graph grammars and computing by graph transformations, volume 1: foundations. world scientific, 1997. [rv01] j. a. robinson, a. voronkov (eds.). handbook of automated reasoning (in 2 volumes). elsevier and mit press, 2001. [str08] m. strecker. modeling and verifying graph transformations in proof assistants. electronic notes in theoretical computer science 203(1):135–148, 2008. doi:http://dx.doi.org/10.1016/j.entcs.2008.03.039 proc. gramot 2010 16 / 16 http://dx.doi.org/http://dx.doi.org/10.1016/j.scico.2010.02.006 http://dx.doi.org/http://doi.acm.org/10.1145/242223.242257 http://dx.doi.org/http://dx.doi.org/10.1109/fose.2007.6 http://dx.doi.org/http://dx.doi.org/10.1016/j.entcs.2008.03.039 introduction relational approach to graph grammars event-b verification of graph grammars using event-b final remarks electronic communications of the easst volume 24 (2009) proceedings of the workshop the pragmatics of ocl and other textual specification languages at models 2009 specifying ocl constraints on process instantiations peter killisperger, markus stumptner, georg peters and thomas stückl 6 pages guest editors: j. cabot, j. chimiak-opoka, f. jouault, m. gogolla, a. knapp managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 eceasst specifying ocl constraints on process instantiations peter killisperger1, markus stumptner1, georg peters2 and thomas stückl3 1 advanced computing research centre, university of south australia 2 department of computer science and mathematics, university of applied sciences münchen 3 system and software processes, siemens corporate technology email: mst@cs.unisa.edu.au abstract: due to the variety of concerns affecting software development in large organisations, processes have to be adapted to project specific needs to be effectively applicable in individual projects. we describe a project aiming to provide tool support for this individualised instantiation of reference processes, based on an ocl-based specification of instantiation operations. the aim is not only to execute instantiation decisions made by humans but to automatically ensure correctness of the resulting process, potentially resulting in followup actions being executed or suggested. keywords: process instantiation, adaptation, reference process, correctness preserving 1 introduction explicitly defined software processes for the development of software are used by most large organizations. at siemens, business units define software processes within a company-wide siemens process framework (spf). because of their size and complexity, they are not defined for projects individually but in a generic way as reference processes for application in any software project of the particular business unit. due to the individuality of software development, reference processes have to be instantiated to be applicable in specific projects [ost87]. that is, the generic description of the process is specialized and adapted to the needs of a particular project. until now, reference processes are used as general guideline and are instantiated only minimally. a more far reaching instantiation is desirable, because manual instantiation is error-prone, time consuming and thus expensive due to the complexity of processes and due to constraints of the spf. siemens defined an improved instantiation to comprise tailoring, resource allocation and customization of artifacts. the latter is the individualization of general artifacts for a project and their association with files implementing them. while structured adaptation approaches have been proposed, they are usually restricted to only a subset of adaptation operations, as in the case of configurable epcs (c-epcs) [ra07], which merely allow activities to be switched on/off, gateways to be replaced, and dependencies of adaptation decisions to be defined. the provop approach [abr08] uses change operations which are grouped in options. options have to be predefined and can be used to adapt processes, but do not guarantee correctness. due to their dependencies on very limited metamodels and 1 / 6 volume 24 (2009) specifying ocl constraints on process instantiations figure 1: software engineering framework. an essentially informal representation, none of the existing approaches was found to offer a complete and at least semi-automatable method for instantiating siemens processes. in order to reduce effort for instantiation considerably, tool support has to be extended. we have developed a flexible architecture for systems that execute instantiation decisions made by humans and automatically restore correctness of the resulting process. we define a process to be correct when it complies with the restrictions on the process defined in a method manual. a method manual is a meta model defining permitted constructs in a process, derived from organizational restrictions (e.g. the spf). in this paper we describe the framework developed for instantiation of processes, specify process properties by ocl constraints, and discuss the implementation options and how the constraints are used to maintain (restore) correctness of instantiations. 2 constraints in the software engineering framework on the basis of information collected in interviews with practitioners at siemens ag, a software engineering framework (sef) is being developed (figure 1) with the aim of improving the instantiation and application of software processes [kpss08]. the sef consists of a reference process, gradual instantiation by high level and detailed instantiation and an implementation of the instantiated process. high level instantiation is a first step towards a project specific software process by adapting the reference process on the basis of project characteristics and information that can already be defined at the start of a project and is unlikely to change. such characteristics can be, e.g., the size of a project (a small project will only use a subset of the process) or high reliability of the software product (requiring certain activities to be added). high level instantiation is followed by detailed instantiation which is run frequently during the project for the upcoming activities. a step by step approach is proposed, because it is often unrealistic to completely define a project specific process already at the start of a project. the resulting instantiated process can be used in projects in different ways including visualproc. ocl 2009 2 / 6 eceasst m a n u a l a c t i v i t y a u t o m a t i c a c t i v i t y a n d s p l i t a n d j o i n x o r s p l i t x o r j o i n o r s p l i t o r j o i n s t a r t e v e n t e n d e v e n t m i l e s t o n ea r t i f a c t h u m a n p a r t i c i p a n t s y s t e m c o n t r o l f l o w i n f o r m a t i o n f l o w r e s o u r c e c o n n e c t i o n e x e c u t e s r c r e s p o n s i b l e r c c o n t r i b u t e s r c i n p u t i f u p d a t e i f o u t p u t i f e l e m e n t + n a m e : s t r i n g + i d : s t r i n g + i n c o m i n g c f [ ] : c o n t r o l f l o w + o u t g o i n g c f [ ] : c o n t r o l f l o w + i n p u t i f [ ] : i n p u t i f + u p d a t e i f [ ] : u p d a t e i f + o u t p u t c f [ ] : o u t p u t i f + e x e c u t e s r c [ ] : e x e c u t e s r c + r e s p o n s i b l e r c [ ] : r e s p o n s i b l e r c + c o n t r i b u t e s r c [ ] : c o n t r i b u t e s r c f l o w + i d : s t r i n g + s o u r c e : e l e m e n t + t a r g e t : e l e m e n t a c t i v i t y r e s o u r c e e v e n t s p l i t j o i n figure 2: classes of process entities and their relationship. ization of the process and management of project artifacts. although instantiation in the sef is split into two distinct stages, it is advantageous if both are based on the same principles. a set of elemental basic instantiation operations (bio) have been defined which are used for both stages. examples are: ”deleting an activity” or ”associating a resource with an activity”. in high level instantiation, bios are executed on process elements as batch (i.e. predefined process adaptations depending on e.g. the project type) and in detailed instantiation individually. using the same principles enables flexible definition and adaptation of predefined instantiation batches. existing tools (as mentioned in the introduction) allow performing those changes but they do not guarantee compliance with constraints. that is, current tools do not automatically correct a process when constraints on the process are violated due to instantiation decisions. the reference processes of particular business units cover the whole lifecycle of a software product. they can be seen as being similar to workflows but their focus is on being read and understood by humans. (it is significantly harder to capture the details of design processes in a rigid workflow format than standard business processes.) figure 2 gives an overview of the allowed classes of elements in our process metamodel. the process used in this article is simplified because of space limitations. the constraints imposed on these processes are derived from process modeling languages and organizational modeling policies such as the spf. examples are: a manual activity has to have at least one human participant executing the activity or an artifact has to be created by an activity before it can be input of an activity. a method manual has been defined that can incorporate generic constraints on the reference process and specific regulations of the business units. it describes restrictions on classes and their relationship by using ocl [omg06]. the choice of ocl was made for several reasons: lowering of the hurdle for developers not fluent in formal notations who could still work with the intended ocl semantics; past experience by some of the 3 / 6 volume 24 (2009) specifying ocl constraints on process instantiations authors in establishing formal semantics for ocl subsets; the integration with uml/mof. the operations required for instantiation of the reference process were defined by experts of the business unit. for example, the operation creating a resource connection is defined as follows: an existing resource (res) is associated with an existing activity (act) by a resourceconnection (rc) of the type executesrc, responsiblerc or contributesrc. the user has to select the resource (res), activity (act) and the type of the resourceconnection (rc). we give several example constraints taken from the the method manual that affect the relevant classes: context executerc inv: (self.source.ocliskindof(human) and self.target.ocliskindof(manualactivity)) or (self.source.ocliskindof(system) and self.target.ocliskindof(automaticactivity)) context responsiblerc inv: self.source.ocliskindof(human) inv: self.target.ocliskindof(activity) context contributesrc inv: self.source.ocliskindof(human) inv: self.target.ocliskindof(manualactivity) in case of an executerc entity, human can only be associated with manualactivity and system only with automaticactivity. in case of responsiblerc and contributerc, only human can be associated with manualactivity or automaticactivity. most of the constraints involved are of a very simple nature, typically referring to existence requirements for particular relationships. (they cannot be expressed as cardinalities in the process metamodel since they include conditions that are checked as preconditions for change operations.) 3 architecture and implementation in order to reduce the effort of instantiation and to guarantee adherence of constraints we have developed an architecture for executing instantiation decisions made by humans which automatically restores correctness of the resulting process. the way a process is instantiated and what constraints are to be met by the process depends on the organization and on the process modeling language used. the architecture of an instantiation system must support differing method manuals since organizations impose different constraints their processes have to meet. constraints may also change over time. a process can be instantiated by running basic instantiation operations (bios) which adapt the process in a predefined manner. if the resulting process violates constraints, the system is expected to provide a list of further changes that will restore consistency. existing public domain ocl implementations turned out to be either too restricted in the types of constraints checked, or to produce the occasional runtime failure. therefore it was decided to initially develop a purpose-built validation and repair module to show the viability of the approach. how a violation is to be corrected depends on the environment in which the entities causing the violation are settled in the process. it might be possible to correct a violation not only in one particular way but in a variety of ways depending on properties and relationships of entities in the proc. ocl 2009 4 / 6 eceasst process. the way a violated constraint is corrected also affects what following violations occur and how they can be corrected. consider an example where the project manager decides to adapt a purely sequential process by running the bio inserting a parallel / alternative path which is defined as follows: the user selects two control-flows from where the new path diverges / rejoins and specifies the type of split and join for diversion / rejoin. both control-flows are deleted by the system and a split and a join of the chosen type is created. by itself, this definition results in an insufficiently connected process, and the options of completing the missing control flow connections have to be examined. we implemented a systematic search mechanism that avoids potential live-lock situations, duplicated processes, and loops. the user is presented with a list of potential amended processes satisfying the constraints which he can accept or edit. the system prototype, written in java, was tested on process descriptions for a particular business unit. xpdl export functions were implemented as part of the tool for exchanging process definitions with the existing aris toolset. the business unit uses a process comprising 23 types of entities including phases (composite activities consisting of a sub process), milestones and control flows. the method manual comprises furthermore several subtypes of activities, resources, artifacts, splits, joins, events, information-flows and associations of resources with activities (called resource connections). from the textual method manual, 135 constraints were identified on types of entities of the meta model and classified in roughly ten different types of constraints for which repair methods were been defined. the reference process used for testing comprises about 3800 instances of entities. the 135 constraints defined on types of entities result in about 14000 constraints on instances of entities which have to be checked and, if necessary, corrected when violated during instantiation. 15 bios (defined by experts) necessary for instantiation of the reference process of the business unit were implemented. the operations are as elementary as possible in order to reduce complexity and avoid dependencies with other operations. because of this simplicity, it might be necessary to execute more than one bio to accomplish a complex adaptation step. the implementation was tested on representative editing sessions on the sample process and found viable for interactive use. to give an indication of performance, when running the bio “inserting a parallel/alternative path” as described above (one of the least constrained operations with a resulting large potential search space), the unoptimised prototype provided the correct suggestion in about 2.5 seconds. 4 conclusion we have described a current research effort to improve software process related activities at siemens. part of these efforts is the development of a system that supports project managers in instantiation of reference processes subject to an explicit constraint representation. the system aims not only to execute decisions but to restore correctness of the resulting process. since the implementation of such a system is organization-specific and depends on the permitted constructs in the process, a flexible architecture has been developed and described in this paper. the approach was applied to a reference process of a business unit and its feasibility was verified by the implementation of a prototype. further work is planned to include an implementation that replaces the dedicated repair5 / 6 volume 24 (2009) specifying ocl constraints on process instantiations oriented algorithm with a generic constraint satisfaction implementation, as used in our service composition work [ts07], in which ocl is used as the specification language for pre-and postconditions. this will both provide a more flexible computational architecture for reasoning about process instantiation and a formal semantics for the ocl constraints in our domain instead of the carefully crafted but essentially ad hoc semantics built into the repair operators of the current implementation. we also plan to adapt past work on behavior-based consistency criteria for refinement of object lifecycles to the process instantiation scenario [ss02, ss00], which will incorporate ocl consistency requirements. acknowledgement this work was partially supported by a daad postgraduate scholarship. bibliography [abr08] a. allerbach, t. bauer, m. reichert. managing process variants in the process life cycle. in proceedings of the tenth international conference on enterprise information systems. volume isas-2, pp. 154–161. 2008. [kpss08] p. killisperger, g. peters, m. stumptner, t. stückl. instantiating software processes. in proceedings 17th international conference on information systems development (isd’08). 2008. [omg06] omg. object constraint language v 2.0. url: http://www.omg.org/spec/ocl/2.0/ (accessed 15.11.2008), 2006. [ost87] l. j. osterweil. software processes are software too. in icse. pp. 2–13. 1987. [ra07] m. rosemann, w. van der aalst. a configurable reference modelling language. information systems 32(1):1–23, 2007. [ss00] m. stumptner, m. schrefl. behavior consistent inheritance in uml. in proceedings of the international conference on conceptual modeling (er). pp. 527–542. springer-verlag, 2000. [ss02] m. schrefl, m. stumptner. behavior-consistent specialization of object life cycles. acm transactions on software engineering and methodology 11(1):92–148, 2002. [ts07] r. thiagarajan, m. stumptner. service composition with consistency-based matchmaking: a csp-based approach. in proceedings of the ieee european conference on web services (ecows). pp. 23–32. 2007. proc. ocl 2009 6 / 6 modeling a service and session calculus with hierarchical graph transformation research supported by the eu fp6-ist ip 16004 sensoria. electronic communications of the easst volume 30 (2010) international colloquium on graph and model transformation on the occasion of the 65th birthday of hartmut ehrig (gramot 2010) modeling a service and session calculus with hierarchical graph transformation roberto bruni, andrea corradini, and ugo montanari 17 pages guest editors: claudia ermel, hartmut ehrig, fernando orejas, gabriele taentzer managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst modeling a service and session calculus with hierarchical graph transformation∗ roberto bruni, andrea corradini, and ugo montanari [bruni,andrea,ugo]@di.unipi.it dipartimento di informatica, università di pisa, italy abstract: graph transformation techniques have been applied successfully to the modelling of process calculi, for example for equipping them with a truly concurrent semantics. recently, there has been an increasing interest towards hierarchical structures both at the level of graph-based models, in order to represent explicitly the interplay between linking and containment (like in milner’s bigraphs), and at the level of process calculi, in order to deal with several logical notions of scoping (ambients, sessions and transactions, among others). in this paper we show how to encode a sophisticated calculus of services and nested sessions by exploiting a suitable flavour of hierarchical graphs. for the encoding of the processes of this calculus we benefit from a recently proposed algebra of graphs with nesting. keywords: hierarchical graphs, service oriented architecture, process calculi, caspis 1 introduction the use of graphs or diagrams of various kinds is pervasive in computer science, as they are very handy for describing in a two-dimensional space the logical or topological structure of systems, models, states, behaviors, computations, metamodels, and several other entities of interest; well-known examples are the graphical presentations of data structures (like lists and trees), of entity-relationship diagrams, of various kinds of automata and labeled transition systems, of static and behavioral uml diagrams (like class, message sequence and state diagrams), of computational formalisms like petri nets, and so on. the advantage of drawing graphs or diagrams, rather than using their underlying set-theoretical definition or some term-like linear syntax, lies in the fact that graphs emphasize relevant topological features of the systems or models they describe, like adjacency and connectivity of components, sharing of data and structures, causal dependencies, hierarchical structuring, among others, making such features easily understandable and detectable also to non-specialists. in several cases graphs provide a representation of models or systems at the “right” level of abstraction: for example, as drawings are always understood “up to isomorphism”, the order in which nodes and arcs are drawn is typically irrelevant (unless some tacit drawing convention is enforced) and if the concrete identity of certain entities is irrelevant (e.g., the names of the states of a finite state automata), it is sufficient to omit them in the drawing. the use of graphs as a domain for the visualization of algebraically-specified systems, in general, and process calculi, in particular, has been pursued in a vast literature of which it is not possible ∗ research supported by the eu fp6-ist ip 16004 sensoria. 1 / 17 volume 30 (2010) mailto:[bruni,andrea,ugo]@di.unipi.it modeling a service and session calculus with hierarchical graph transformation to give a comprehensive account here (see, e.g., [bl05] and references therein), but one striking example is the research on “optimal” implementations for functional calculi [ag98]. here we restrict the attention to the analysis of the concurrent behavior of process calculi with name passing, in the style of [mp95, gad03, bmm06]. to this aim, there are several “graphical specification frameworks” which provide general techniques and/or tools for the graphical description of systems and, possibly, of their behavior, including graph transformation [roz97], bigraphical reactive systems [mil06] and synchronized hyperedge replacement [fhl+06]. recently, there has been an increasing interest towards hierarchical structures both at the level of graph-based models, in order to represent explicitly the interplay between linking and containment (like in milner’s bigraphs), and at the level of process calculi, in order to deal with several logical notions of scoping (ambients, sessions, and transactions, among others). the goal of the work summarized in this paper is to show how to encode both the static aspects and the dynamics of caspis, a sophisticated calculus of services and nested sessions [bbdl08], by exploiting a suitable flavor of hierarchical graphs and corresponding transformation rules. following a methodological approach that has been applied recently to provide a graphical encoding of the static aspects of a variety of formalisms (including process calculi, workflow languages, entity relationship diagrams and others, see [bgl10b, bgl10a]), we will not present the graph encoding of caspis processes directly, but we will exploit instead as an intermediate language a recently proposed algebra of hierarchical diagrams, which allows to reduce the representation distance between the considered formalisms. roughly, such diagrams are typed (hyper)graphs whose (hyper)edges can contain other sub-diagrams. this way, edges can be seen as representing some sort of interfaces of their enclosed graphs. we call them designs, because they have been first introduced to model recurrent design patterns in software architectures [blmt08]. the algebra is defined by an equational signature, whose operator symbols are interpreted as operations on graphs, and where the axioms formalize suitable properties of such operators. therefore the terms of the initial algebra can be interpreted as graphs, and the axioms can be shown to be sound and complete with respect to the interpretation, in the sense that two terms are equivalent if and only if they denote the same graph (up to isomorphism). the interesting fact is that the interpretation of the terms of the algebra can be given over different kinds of graphs, resulting in different layouts. as a typical example, the nested structure of designs can be interpreted adequately in a class of truly hierarchical graphs, where subgraphs can be encapsulated in hyperedges, or also can be rendered by over-imposing a tree of locations representing the hierarchy to a standard, flat hypergraph. therefore, the advantages of the use of an intermediate algebra for the encoding are twofold: • the algebra provides explicit operators for parallel composition, nesting of components, names representing shared resources, local and global restriction, as well as aliasing mechanisms: the richness of such operators makes the encoding of process algebras like caspis quite intuitive, less error-prone and easy to understand; • the various interpretations of the terms of the algebra as different kinds of graphs can be defined once and for all, and reused for the encoding of several other formalisms. in the next sections we shall first account for the algebra of hierarchical graphs, sketching, only at the informal level, how it can be interpreted over both hierarchical graphs and term graphs. proc. gramot 2010 2 / 17 eceasst next we introduce the syntax and the reduction semantics of (a significant fragment of) caspis, and show how the static aspects of caspis can be encoded in the algebra. as far as the dynamics of caspis processes is concerned, the work is still ongoing, but some interesting aspects will be discussed. in particular, as the caspis reduction semantics allows for reactions in (static) contexts of arbitrary depth, the standard notion of graph transformation rule, which has a local effect only, is not sufficient to model it. we will sketch some possible approaches to overcome this problem. some preliminary work on the graphical encoding of caspis and its behavioral semantics has been presented in [ter08]. 2 an algebra of hierarchical graphs we introduce here our algebra of (typed) hierarchical graphs that we call designs. the algebraic presentation of designs is inspired by our previous work on architectural design rewriting [blmt08] (hence the name) and by the graph algebra of charm [cmr94]. definition 1 (design) a design is a term of sort d generated by the grammar d ::= lx[g] g,h ::= 0 | x | l〈x〉 | g |h | (ν x)g | d〈x〉 where l and l are drawn from disjoint vocabularies e and d of edge and design labels, respectively, x is taken from a global set n of nodes, and x ∈ n ∗ is a list of nodes. as a matter of notation, in the following, we let bxc denote the set of elements of a list x and overload |·| to denote both the length of a list and the cardinality of a set. terms generated by g and d are meant to represent hierarchical graphs and “edge-encapsulated” hierarchical graphs, respectively. the syntax has the following informal meaning: 0 represents the empty graph, x is a discrete graph containing a single node named x (node names are global), l〈x〉 is a graph formed by an l-labeled (hyper)edge attached to nodes x (the i-th tentacle to the i-th node in x, sometimes denoted by x[i]), g | h is the graph resulting from the parallel composition of graphs g and h (their disjoint union, but nodes with the same name in both graphs are identified), (ν x)g is the graph g after hiding the name of node x (therefore the node cannot be shared with other graphs in case of parallel composition; borrowing nominal calculus jargon we say that the node x is restricted), and d〈x〉 is a graph formed by attaching design d to nodes x (the i-th node in the interface of d to the i-th node in x). a term lx[g] is a design labeled by l, with body graph g whose nodes x are exposed in the interface. to clarify the exact role of the interface of a design, we can use a programming metaphor: a design lx[g] is like a procedure declaration where x is the list of formal parameters. then term lx[g]〈y〉 represents the application of the procedure to the list of actual parameters y; of course, in this case x and y must have the same length. restriction (ν x)g acts as a binder for x in g and similarly lx[g] binds bxc in g, leading to the usual notion of free nodes fn(d) and fn(g), defined inductively as follows: fn(lx[g]) = fn(g)\bxc fn(0) = /0 fn(x) ={x} fn(l〈x〉) =bxc fn(g |h) = fn(g)∪fn(h) fn((ν x)g) = fn(g)\{x} fn(d〈x〉) = fn(d)∪bxc 3 / 17 volume 30 (2010) modeling a service and session calculus with hierarchical graph transformation without loss of generality, we can assume that for any design lx[g] it holds bxc⊆ fn(g). the algebra includes the structural graph axioms of [cmr94] such as associativity and commutativity for | with identity 0 (axioms da1–da3 in definition 2) and restricted nodes (da4–da6). in addition, it includes axioms to α -rename bound nodes (da7–da8), an axiom for making immaterial the addition of a node to a graph where that same node is already free (da9) and another one ensuring that free nodes are not localized within hierarchical edges (da10). definition 2 (≡d) the structural congruence ≡d over well-formed designs and graphs is the least congruence satisfying the axioms in fig. 1, where in axiom (da7) the substitution is required to be a function (to avoid node coalescing). g |h ≡d h |g (da1) g | (h | i) ≡d (g |h) | i (da2) g | 0 ≡d g (da3) (ν x)(ν y)g ≡d (ν y)(ν x)g (da4) (ν x)0 ≡d 0 (da5) g | (ν x)h ≡d (ν x)(g |h) if x 6∈ fn(g) (da6) lx[g] ≡d ly[g{y/x}] if byc∩fn(g) = /0 (da7) (ν x)g ≡d (ν y)g{y/x} if y 6∈ fn(g) (da8) x |g ≡d g if x ∈ fn(g) (da9) lx[z |g]〈y〉 ≡d z | lx[g]〈y〉 if z 6∈ bxc (da10) figure 1: structural congruence axioms for designs it is immediate to observe that structural congruence respects free nodes, i.e. g≡d h implies fn(g) = fn(h) for any g,h. moreover, being ≡d a congruence, it is closed w.r.t. all operators; in particular, we have lx[g]≡d lx[h] whenever g≡d h. two different classes of models have been studied for our design algebra, as summarized in the next two subsections: these are in straight analogy with two common visual representations of file systems. in the icon view each folder is a window recursively containing files and folders, like a global view of the system taken “from the top”. in the tree-like view the whole hierarchy is presented as a tree whose nodes can be contracted and expanded and where containment is rendered, for example, through indentation, like some sort of “side-view” of the system. 2.1 top-view models several notions of hierarchical graphs have been introduced along the years in various domains, often as a useful structuring mechanism to cope with the modelling of systems of realistic size. one of the earliest proposals are harel’s higraphs [har88], used first for modelling database structures and next as a basis for statecharts. several other such models have been proposed since then, for modelling database systems, object-oriented systems and hyper-media applications, among others (see, e.g., the recap in section 7 of [bkk05]). in [bgl] we have proposed an original notion of hierarchical graphs with interfaces: roughly proc. gramot 2010 4 / 17 eceasst figure 2: the hierarchical graphs corresponding to some terms of the graph algebra they extend ordinary hyper-graphs with the possibility to embed (recursively) a hierarchical graph within each edge, thus inducing a layered structure of nodes and edges. differently from the similar definition proposed in [dhp02], the nodes defined in one layer are also visible below in the hierarchy (but not above). the main result of [bgl] shows that the encoding of design terms in hierarchical graphs is surjective and that the axiomatization of the design algebra is sound and complete w.r.t. the encoding. moreover, in presence of the extrusion axiom, which is introduced later (see definition 3), the encoding can be slightly modified in order to preserve the validity of the main results. the set-theoretical presentation of hierarchical graphs is quite heavy and out of the scope of this paper: we refer the interested reader to [bgl] for all technical details. the following example gives a better intuition of the algebra and of the model of hierarchical graphs. for this purpose we use an informal, appealing visual notation. example 1 let a,b ∈ e , a ∈ d , u,v,w,x,y ∈ n . figure 2 includes the graphs corresponding to the following terms: g = a〈u,w〉 | b〈w,v〉 (top-left), au,v[(ν w)g]〈x,y〉 (bottom-left), and (ν w)(au,v[g]〈x,y〉 | au,v[g]〈y,x〉) (right). nodes are represented by circles and free nodes are annotated with their name. edges are represented by rounded boxes, annotated inside with the edge label. each design is represented by a rectangular box with the label in a top bar, and encapsulating the body graph. instead of numbering the tentacles of edges and designs, we use different kinds of lines and arrows: in this example the first tentacle of an edge is represented by a plain line, while the second one is denoted by a standard arrow. to simplify the drawings, the interface nodes of a design are drawn as small black boxes on its border, and tentacles connected to them are prolonged to the corresponding nodes which the design is attached to. in the rightmost graph of fig. 2, note the difference among the tentacles connected to x and y, and those pointing to the restricted node in the middle. the formers cross the border of the designs, reaching x or y through the exposed interface nodes, while the latters access the restricted node directly, as it is available globally. the hierarchical graphs in fig. 2 show a global view as taken from the top. another possibility is to take a side-view, where containment is represented by dependencies between items in different layers. in many situations, the side-view can be more convenient in order to reuse classical graph transformation techniques, because it relies on ordinary graphs (nesting is implicit). 5 / 17 volume 30 (2010) modeling a service and session calculus with hierarchical graph transformation figure 3: hierarchical structures as gs-graphs 2.2 side-view models in [bcg+] we have followed the tree-like analogy to define a second interpretation of the design algebra, over a class of graphs called gs-graphs [fm00]. roughly, gs-graphs are an extension of term-graphs [beg+87] tailored to many-sorted hyper-signatures. in fact, it is known that the term-graphs over a standard one-sorted signature σ can be generated freely from σ itself by closing it with respect to the axioms of gs-monoidal theories (see [cg99]). the same construction works in the many-sorted case as well, and even if the operators in σ can deliver an arbitrary, finite number of results, instead of exactly one: in this case the result of the construction is the set of all gs-graphs over σ. for the interpretation of the design algebra, we therefore fix a (many-sorted, hyper-) signature σd with one sort ◦ for nodes and an additional one, denoted •, to represent locations. assuming that the labels in e ∪d have fixed ranks (see the next subsection), σd includes an operator l : •◦k → ε for each edge label l ∈ e of rank k, where ε denotes the empty list of sorts, and an operator l : •◦k →•◦k for each design label l ∈ d . intuitively, all labels have as arguments one location (where the edge/design is placed) and k nodes (which the edge/design is connected to); furthermore design labels offer as results a new location (the interior of the design) and k nodes (the inner formal parameters), while edge labels do not return anything. finally, σd contains one operator nu: •→◦ used to encode the (localized) restriction. then, the results in [bcg+] define a sound and complete encoding of design terms in gsgraphs over σd.1 again, we skip all technical details and we just sketch in fig. 3 the gsgraphs corresponding to the hierarchical graphs in fig. 2: g = a〈u,w〉 | b〈w,v〉 on the left, 1 actually the construction in [bcg+] is carried out for a slightly different algebra of designs/graphs, but it is there discussed how to extend the results to the algebra considered here. proc. gramot 2010 6 / 17 eceasst au,v[(ν w)g]〈x,y〉 in the middle, and (ν w)(au,v[g]〈x,y〉 |au,v[g]〈y,x〉) on the right. each drawing is decorated with an external dashed line enclosing the gs-graph and emphasizing its boundary, on which the names of the available free nodes are placed; furthermore some dotted lines suggests the correspondence between actual and formal parameters of a-labeled edges. such decorations are not part of the formal definition and have the only purpose of making easier the intuitive correspondence with fig. 2. note that locations are structured in a tree-like fashion, while names can be referred more liberally, across the hierarchy. 2.3 well-typedness and extrusion in practice, it is very frequent that one is interested in disciplining the use of edge and design labels so to be attached only to a specific number of nodes (possibly of specific sorts) or to contain graphs of a specific shape. to this aim it is typically the case that: 1) nodes are sorted, in which case their labels take the form n : s for n the name and s the sort of the node; and 2) each label of e and d has a fixed rank, which in the general case is a finite sequence of sorts. when this is the case, we say that a design (or a graph) is well-typed if for each sub-term lx[g] we have that the (lists of) sorts of x and l coincide, and similarly for sub-terms d〈x〉 and l〈x〉. in addition to the axioms of fig. 1, another axiom that has been considered in the literature is the so-called extrusion axiom. definition 3 (extrusion axiom) the extrusion axiom is ly[(ν z)g]〈x〉≡ (ν z)ly[g]〈x〉, for any l ∈ d , where z 6∈ bxc∪byc. the presence of the extrusion axiom implies that restriction of nodes is global, i.e., orthogonal to nesting: like free nodes (see axiom da10), also restricted nodes can cross the boundary of a design. instead its absence implies that restriction is located to a design.2 concerning the sideview encodings using gs-graphs sketched in section 2.2, the extrusion axiom is easily captured by replacing operator nu: •→◦ with nu: ε →◦, meaning that restriction does not take a location as argument. our encoding of caspis requires the presence of the extrusion axiom, and the different side-view encodings of restriction can be grasped by comparing the nu-labeled edges of fig. 3 with the nu-labeled edge of fig. 6. 3 a calculus with nested structures and communication: caspis this section recalls the basics of caspis [bbdl08], a session-centered calculus. we have chosen this calculus since it represents a non-trivial example of the interplay between nesting and linking in presence of nested sessions, pipelines and communication. while referring the interested readers to [bbdl08] for an exhaustive description of caspis, we remark that we focus here on the “close-free” fragment of the calculus and we present a slightly simplified syntax (without summation and pattern-matching). both decisions are for the sake of a convenient and clean presentation only, and constitute no limitation on expressiveness. caspis is based on the following key computing entities: (i) service definitions s.p and 2 a different approach is taken in [bcg+], where two distinct restriction operators are introduced. 7 / 17 volume 30 (2010) modeling a service and session calculus with hierarchical graph transformation invocations s.q, whose synchronization establishes (ii) a fresh session name r shared by the two partner session sides r . p and r . q, where respective interaction protocols can interact in both directions by executing (iii) intra-session (synchronous) output 〈u〉 and input (?x) prefixes. moreover, (iv) session sides can be nested, and (v) a children side can execute an (extra-session) return prefix 〈u〉↑ for making u available to its parent session side. finally, (vi) on-site computation can be achieved using the pipeline operator p > (?x)q, which redirects each output 〈u〉 from p to activate a corresponding new instance q{u/x} of q. notably, any such instance will run in parallel with p > (?x)q. summarizing all the above, each caspis process can be thought of as running in an environment providing him different means of communication: one channel for “standard” input (expecting values from the partner session side), one channel for “standard” output (either directed to the partner session side or to an in-side pipeline) and one channel for returning values one level up (according to the nesting of session sides). definition 4 (caspis syntax) let s a set of service names, r be a set of session names, v ⊇ s a set of value names (disjoint from r), and x ⊆ v a set of value variables. the set p of caspis processes is the set of all the terms p generated by the grammar below p,q,r ::= 0 | r . p | p > q | (ν w)p | p | q | a.p a ::= s | s | (?x) | 〈u〉 | 〈u〉↑ where s ∈ s , r ∈ r, u ∈ v , w ∈ (v ∪r)\x and x ∈ x . as usual, we omit trailing 0, i.e. we write a as a shorthand for a.0. the restriction operator (ν w)p binds w in p, and similarly (?x).p binds x in p, leading to straightforward definition of free names fn(p) of a process p. albeit the syntax allows for more general forms of pipelines, for simplicity we only consider pipelines of the form p > (?x)q: these match a standard pattern that, for example, is written as p > x > q in the orc programming language [kcm06]. moreover, we assume that in any process p at most two session sides are present for the same session name and that the binary relation ≺+p over session names is irreflexive, where we write r ≺p r′ whenever in p a session side r′ appears nested within a session side r, and ≺+p denotes the transitive closure of ≺p. the operational semantics is defined in terms of reduction rules over processes taken up to a suitable structural congruence, that we introduce next. definition 5 (≡c) the structural congruence for caspis processes is the relation ≡c⊆ p ×p, closed under process construction, inductively generated by the axioms in fig. 4. the reduction rules that we will present make use of contexts; a context c[·] is simply a process term in which there is a single occurrence of a process variable x , called the hole of the context. with c[p] we denote the process obtained by filling the hole of the context with the process p (i.e. we substitute x with p). we can easily generalize such definition to n holes: instead of a single process variable x , we will have n process variables x1,...,xn. definition 6 (static and dynamic operators) the operators a.[·] and p > [·] are dynamic. the remaining operators (r . [·], [·] > p, (ν n)[·], p|[·] and [·]|p) are static. proc. gramot 2010 8 / 17 eceasst p | (q | r) ≡c (p | q) | r (ca1) p | q ≡c q | p (ca2) p | 0 ≡c p (ca3) (ν n)(ν m)p ≡c (ν m)(ν n)p (ca4) (ν n)0 ≡c 0 (ca5) p | (ν n)q ≡c (ν n)(p | q) if n 6∈ fn(p) (ca6) ((ν n)q) > p ≡c (ν n)(q > p) if n 6∈ fn(p) (ca7) r .(ν n)p ≡c (ν n)r . p if n 6= r (ca8) (ν n)p ≡c (ν m)(p{m/n}) if m 6∈ fn(p) (ca9) (?x).p ≡c (?y).(p{y/x}) if y 6∈ fn(p) (ca10) figure 4: structural congruence axioms for caspis. intuitively the dynamic operators, like the prefixes in the π -calculus or in ccs, do not allow a transition to take place in their argument. we can now define the contexts in which the various kinds of action prefixes are ready to be executed. definition 7 (static and “immune” contexts) a context c[·] is static if its hole does not occur in the scope of a dynamic operator. a static context is session-immune if the hole does not appear in the scope of a session operator r .[·]. a static context is pipeline-immune if the hole does not appear in the scope of a pipeline operator [·] > p. session-immune contexts are guaranteed not to interfere with inputs and returns of the process in their hole, while contexts that are both sessionand pipeline-immune are also guaranteed not to interfere with outputs. in the latter case the hole can only appear under restriction and parallel composition. we are ready now to present the reduction semantics of caspis. definition 8 (reduction rules of caspis) given two caspis processes p and q we have p ⇒ q if and only if one of the five cases in fig. 5 holds, for some static contexts c[·], c[·,·], some static session-immune contexts s0[·] and s1[·], some processes p′,p′′,r and some names r,r′,u and x. the first rule models the invocation of a service: there is a definition of service s (s.p′) and a request of invocation of such service (s.r) located somewhere else in the system. then a new session r is created with the protocols p′ and r of the server and of the client respectively. note that differently from [bbdl08], here services are persistent: they are not discarded once invoked and thus they can serve other requests. rule (sessionsync) allows session partners to exchange messages, through a output action 〈u〉.p′′ and an input action (?x).r. technically, the output 〈u〉 can appear in an arbitrary sessionand pipeline-immune context within the session operator, but since restrictions can be moved outside the session operator by structural congruence, this is equivalent to require that the output is in parallel with an arbitrary process p′, as indicated in the rule. instead the input (?x) can be at an arbitrary depth in the syntax tree, for example in the left-side of a pipeline, but not in a nested session operator: for this reason we use a static session-immune context s0[·]. the next rule (sessionsyncret) can be used for returning a value computed by a nested session side to the 9 / 17 volume 30 (2010) modeling a service and session calculus with hierarchical graph transformation (1) p ≡c c[ s.p′ , s.r ] q ≡c (ν r)c[ s.p′ |r . p′ , r . r ] with r fresh for p′,c[·],r (servicesync) (2) p ≡c (ν r)c[ r .(p′ |〈u〉.p′′) , r . s0[(?x).r] ] q ≡c (ν r)c[ r .(p′ |p′′) , r . s0[r{u/x}] ] with r not appearing in c (sessionsync) (3) p ≡c (ν r′)c[ r′.(p′ |r . s0[〈u〉↑.p′′]) , r′. s1[(?x).r] ] q ≡c (ν r′)c[ r′.(p′ |r . s0[p′′]) , r′. s1[r{u/x}] ] with r′ not appearing in c (sessionsyncret) (4) p ≡c c[ (p′ |〈u〉.p′′) > (?x).r ] q ≡c c[ r{u/x} | ((p′ |p′′) > (?x).r) ] (pipelinesync) (5) p ≡c c[ (p′ |r . s0[〈u〉↑.p′′]) > (?x).r ] q ≡c c[ r{u/x} | ((p′ |r . s0[p′′]) > (?x).r) ] (pipelinesyncret) figure 5: possible cases for p ⇒ q session partner. one can view this rule as composed of two steps: first the value computed in session r is passed to the enclosing session side r′, then such session side sends the value to its partner. the pipeline rule (pipelinesync) shows that a value computed by the left-hand side p′|〈u〉.p′′ can trigger a new instance r{u/x} of the right-hand side (?x)r. finally the rule (pipelinesyncret) describes the situation where a pipe can be activated through a value returned by a nested session side of the process on the left side of the pipeline. example 2 to show some applications of reduction rules, consider for example the process k |(c > (?y).p) consisting of a fresh-key generator service k = key.(ν k)〈k〉, a client c = key.(?x).〈x〉↑ and a generic process p. then the above process can evolve as illustrated below: k |(c > (?y).p)⇒ k |(ν r)(r .(ν k)〈k〉 | ((r .(?x).〈x〉↑) > (?y).p)) by (servicesync) ≡c k |(ν r)(ν k)(r .〈k〉 | ((r .(?x).〈x〉↑) > (?y).p)) by ca8 and ca6 ⇒ k |(ν r)(ν k)(r . 0 | ((r .〈k〉↑) > (?y).p)) by (sessionsync) ⇒ k |(ν r)(ν k)(r . 0 | ((r . 0) > (?y).p) | p{k/y}) by (pipelinesyncret) note that, as r . 0 is clearly inert and therefore also (r . 0) > (?y).p is inert, then the process (ν r)(ν k)(r . 0 | ((r . 0) > (?y).p) | p{k/y}) behaves essentially as (ν k)p{k/y}. proc. gramot 2010 10 / 17 eceasst 4 encoding caspis into the algebra of designs in [bgl10b, bgl] we have provided a sound and complete encoding of caspis processes to our algebra of designs, exploiting the fact that reduction rules can then be directly interpreted over and applied to graphs instead of terms. unfortunately, this way an interleaving semantics is obtained, not a truly concurrent one, because the whole graph is rewritten at each step (no standard notion of “preserved” nodes/edges is available). here we pursue a different objective, by establishing an encoding for which ordinary graph rewriting techniques can be used to recover the dynamics. in particular, as rewrites are forbidden under dynamic contexts of caspis, we will expand dynamic operators only by need. this means that for each term p having a dynamic top operator, we introduce a corresponding edge label, sorted according to the free names of p, which are needed as parameters in the rewrite rule that will expand p to the corresponding graph after a reaction. instead, the static contexts will be encoded in nested designs corresponding to the session and left-pipeline operators, while restriction operators will be encoded directly as restrictions of the algebra of designs. in the following we assume that a standard total order on names is available, and for a set of names x we denote by dxe the list of names in x ordered accordingly. moreover, we assume the existence of a canonical set of totally ordered fresh names c disjoint from v ∪r, together with a canonical (order preserving) renaming σx : x → c for any x ⊆ v ∪r such that whenever |x|= |y| then σx (x) = σy (y ). we denote by can(p) the term pσfn(p) obtained by renaming the free names of p according to σfn(p), and we write p for one chosen standard representative of the equivalence class [can(p)]≡c . names (of services, sessions, etc.) are encoded as nodes of the algebra, thus we assume that the set of nodes is sorted accordingly, even if we do not make this formal. the set of edge labels is { a.p }, i.e. it includes all standard representatives for processes of the form a.p. the tentacles of a.p are sorted according to fn(a.p). the set of design labels includes ses for session sides (exposing an anonymous session name ), and one standard representative x > q for each static context of the form [·] > (?x)q, exposing n = |fn(q)\{x}| canonical fresh variables σfn(q)\{x}(fn(q)\{x}). to make the encoding easier to parse, we introduce the following abbreviation for the terms in our algebra: if byc∩fn(g) = /0 and h is (the discrete graph) obtained as the parallel composition of (all and only) the node names in byc, then we write l[g]〈x〉 as a shorthand for ly[h|g]〈x〉. definition 9 (caspis encoding) the interpretation of caspis operators over the design algebra (with extrusion, i.e., with global restriction) is given by j0k def= 0 ja.pk def= a.p〈dfn(a.p)e〉 jr . pk def= ses[ jpk ]〈r〉 jp > (?x)qk def= x > q[ jpk ]〈dfn(q)\{x}e〉 jp | qk def= jpk | jqk j(ν w)pk def= (ν w)jpk it is worth stressing that if one is interested in analyzing a finite set of caspis processes through the encoding to the algebra of designs and the transformation of the corresponding graphs, then 11 / 17 volume 30 (2010) modeling a service and session calculus with hierarchical graph transformation the resulting algebra will have a finite number of edge and design labels, determined by the set of sub-processes of those of interest. instead, to be able to accommodate the encoding of all possible caspis processes, denumerable sets of labels are needed. notably, structural congruence amounts to design equivalence, i.e. equivalent processes are mapped into isomorphic graphs. proposition 1 for any q,r ∈ p we have p ≡c q iff jpk ≡d jqk. 4.1 transformation rules for caspis reduction semantics given the encoding of caspis processes as terms of the algebra of designs, and any suitable model of the algebra in terms of a class of graphs (like those presented in sections 2.1 and 2.2), it is natural to try to lift the reduction semantics of caspis, through these encodings, to a corresponding notion of transformation over the resulting graphs. ideally, we would like to translate the reduction rules of definition 8 to ordinary graph transformation rules, in order to exploit the rich theory of graph transformation and the corresponding analysis and verification tools, also accounting for concurrency aspects. however, this is not possible in a direct way. in fact, the reduction rules of caspis include suitable contexts in the leftand right-hand sides, which can be instantiated in arbitrary ways to match a subterm of the process to be reduced. in other words, each reduction rule can be considered as a rule schema, summarizing the common shape of infinitely many similar rules, obtained by consistently replacing the contexts with suitable terms. quite obviously, if we are interested in reducing a single process (or a finite set of processes), we need to consider only a finite set of instances of the rules. in figures 6, 7 and 8 we depicted the graph transformation rule schemata corresponding to the reduction rules (servicesync), (sessionsync) and (pipelinesync) of fig. 5. for each reduction rule, the corresponding graphical rule is obtained by encoding (with some liberality) the leftand right-hand sides as terms of the design algebra, according to definition 9, and then representing the designs according to the side-view discussed in section 2.2. a gray area identifies in each rule the edges and nodes that are preserved. for example, the left-hand side of fig. 6 is a system containing processes s.p′ and s.r, represented by edges with the depicted labels; these processes can be in arbitrary locations (the edges are attached to different black nodes), and each of them is attached to a list of nodes representing the free names, which necessarily include s. this graph encodes the left-hand side process c[ s.p′ , s.r ] of rule (servicesync): note that the generic static context c under which the interacting redexes are found is omitted, because the left-hand side of a graph transformation rule can always be applied in larger graphs. correspondingly, the right-hand side of fig. 6 encodes process (ν r)c[ s.p′ |r . p′ , r . r ]: the static context c is omitted again, the service definition s.p′ is preserved, and two session sides are generated, one for the server and one for the client, sharing a ν -restricted fresh name. the dotted edges located under the session sides informally represent the subgraphs obtained by encoding processes p′ and r, respectively. comparing the other graphical rule schemata with the corresponding reduction rules in fig. 5, we note that not only we can omit the static top level context c, but also, for the same reason, we can omit safely any other idle item that runs in parallel, like process p′ from rules proc. gramot 2010 12 / 17 eceasst figure 6: rule (servicesync) figure 7: rule (sessionsync) figure 8: rule (pipelinesync) 13 / 17 volume 30 (2010) modeling a service and session calculus with hierarchical graph transformation (sessionsync) and (pipelinesync) in fig. 5. however, we must still account for the presence of any admissible static session-immune context s0 in rules (sessionsync), (sessionsyncret) and (pipelinesyncret), because it constrains the applicability of the rule (in general js0k can be a chain of pipeline-labeled boxes of arbitrary length, possibly 0). even if we did not work out the corresponding definitions, we identified a few graph transformation frameworks which can provide the means to turn such rule schemata into collections of graph rewrite rules, whose overall effect would be the expected one when applied to a graph representing a caspis process. synchronized hyperedge replacement. in the shr approach [fhl+06], the parallel application of a set of rules to a graph is controlled by a synchronization mechanism which requires a consistency check among the redex boundaries of the involved rules. this mechanism can be used to build (standard) rules with unbound left-hand sides, starting from a finite set of rules. therefore a caspis rule schema could be implemented by a set of shr rules, which should be able to induce the set of all its instantiations. graph transactions. the notion of graph transaction proposed in [bcd+08] is based on a notion of “unstable” graph items. a transaction is a minimal derivation starting and ending in graphs not containing unstable items, up to shift equivalence, and the operational semantics of a transactional graph transformation system includes only derivations that are made of transactions. therefore a caspis rule schema could be translated into a collection of rules which simulate the navigation of the process in order to identify an occurrence of the left hand side. this can be done by generating unstable items in the graph: their presence conceptually inhibits the application of other rules in parallel. when the left pattern is recognized and the effect of the rule is applied, such unstable elements are deleted, resulting in the commitment of the transaction. several other graph transformation approaches provide features that could be useful to represent the caspis rule schemata, including mechanisms to control the application of rules (ranging from various kinds of application conditions to explicit control structures, as in the progres specification language [swz99]), or the inclusion in rules of multiple nodes which can match an arbitrary number of nodes (as in adaptive star grammars [dhj+06], where the application of a rule may cause the cloning of some items of the rewritten graph). the study of the possible translations of caspis rule schemata into one or more of the mentioned approaches is an interesting topic for future research. 5 conclusions in this paper we have shown the main issues regarding the graphical encoding of a sophisticated process calculus with inherently hierarchical features. the encoding of processes can be written quite smoothly by exploiting a recently proposed algebra of graphs with nesting (see definition 9), and it can be shown to preserve and respect the structural congruence of processes. on the other hand, the encoding of reduction rules as ordinary graph transformation rules requires some proc. gramot 2010 14 / 17 eceasst ingenuity, because the redexes can require the traversal/inspection of an unbound number of nesting levels due to the presence of static session-immune contexts in the rules of fig. 5. the main methodological innovation of the paper, with respect to other proposals of encoding process algebras into graph transformation systems, resides in the identification of an intermediate algebra of designs, which bridges the gap between the syntax of the process calculus and the set theoretical definition of the graphs. a direct translation of caspis processes to, for example, gs-graphs, would be possible but more cumbersome. furthermore, a sound and complete interpretation of the algebra into a class of graphs can be reused for different process calculi. for example, besides the topand side-view graphs discussed in the paper, another natural graph model for the algebra are milner’s bigraphs [mil06], which are naturally endowed with a notion of embedding and of linking. the ultimate motivation in equipping caspis with a graph transformation operational semantics is to exploit the rich theory of graph transformation and corresponding tools for the analysis and verification of relevant properties of caspis processes. the intermediate design algebra provides one additional framework for such analysis, which could be performed by exploiting tools directly based on the algebra, which are currently under development (see http://www.albertolluch.com/ adr2graphs/). acknowledgements: we want to thank fabio gadducci, alberto lluch lafuente, daniele terreni and liang zhao for many interesting discussions and exchanges of ideas regarding the graphical encoding of caspis. bibliography [ag98] a. asperti, s. guerrini. the optimal implementation of functional programming languages. cambridge university press, 1998. [bbdl08] m. boreale, r. bruni, r. de nicola, m. loreti. sessions and pipelines for structured service programming. in barthe and de boer (eds.), fmoods 2008. lncs 5051, pp. 19–38. springer, 2008. [bcd+08] p. baldan, a. corradini, f. dotti, l. foss, f. gadducci, l. ribeiro. towards a notion of transaction in graph rewriting. in bruni and varró (eds.), international workshop on graph transformation and visual modeling techniques (gt-vmt 2006). entcs 211. elsevier, 2008. [bcg+] r. bruni, a. corradini, f. gadducci, a. lluch lafuente, u. montanari. on gsmonoidal theories for graphs with nesting. in festschrift for manfred nagl (65th birthday). lncs. springer. to appear. [beg+87] h. barendregt, m. van eekelen, j. glauert, j. kennaway, m. plasmeijer, m. sleep. term graph reduction. in parle’87. lncs 259, pp. 141–158. springer, 1987. 15 / 17 volume 30 (2010) http://www.albertolluch.com/adr2graphs/ http://www.albertolluch.com/adr2graphs/ modeling a service and session calculus with hierarchical graph transformation [bgl] r. bruni, f. gadducci, a. lluch lafuente. an algebra of hierarchical graphs and its application to structural encoding. scientific annals of computer science. to appear. [bgl10a] r. bruni, f. gadducci, a. lluch lafuente. an algebra of hierarchical graphs. in hofmann et al. (eds.), tgc 2010. lncs 6084, pp. 205–221. springer, 2010. [bgl10b] r. bruni, f. gadducci, a. lluch lafuente. a graph syntax for processes and services. in su and laneve (eds.), ws-fm 2009. lncs 6194, pp. 46–60. springer, 2010. [bkk05] g. busatto, h.-j. kreowski, s. kuske. abstract hierarchical graph transformation. mathematical structures in computer science 15(4):773–819, 2005. [bl05] r. bruni, i. lanese. on graph(ic) encodings. in koenig et al. (eds.), proceedings of dagstuhl seminar n. 04241, graph transformations and process algebras for modeling distributed and mobile systems. pp. 23–29. 2005. [blmt08] r. bruni, a. lluch lafuente, u. montanari, e. tuosto. style based architectural reconfigurations. bulletin of the european association for theoretical computer science (eatcs) 94:161–180, february 2008. [bmm06] r. bruni, h. melgratti, u. montanari. event structure semantics for nominal calculi. in baier and hermanns (eds.), concur 2006. lncs 4137, pp. 295–309. springer, 2006. [cg99] a. corradini, f. gadducci. an algebraic presentation of term graphs, via gsmonoidal categories. applied categorical structures 7:299–331, 1999. [cmr94] a. corradini, u. montanari, f. rossi. an abstract machine for concurrent modular systems: charm. theoretical computer science 122(1-2):165–200, 1994. [dhj+06] f. drewes, b. hoffmann, d. janssens, m. minas, n. v. eetvelde. adaptive star grammars. in corradini et al. (eds.), icgt. lecture notes in computer science 4178, pp. 77–91. springer, 2006. [dhp02] f. drewes, b. hoffmann, d. plump. hierarchical graph transformation. journal on computer and system sciences 64(2):249–283, 2002. [fhl+06] g. l. ferrari, d. hirsch, i. lanese, u. montanari, e. tuosto. synchronised hyperedge replacement as a model for service oriented computing. in boer et al. (eds.), fmco 2005. lncs 4111, pp. 22–43. springer, 2006. [fm00] g. l. ferrari, u. montanari. tile formats for located and mobile systems. information and computation 156(1-2):173–235, 2000. [gad03] f. gadducci. term graph rewriting for the pi-calculus. in ohori (ed.), aplas 2003. lncs 2895, pp. 37–54. springer, 2003. [har88] d. harel. on visual formalisms. communication of the acm 31(5):514–530, 1988. proc. gramot 2010 16 / 17 eceasst [kcm06] d. kitchin, w. r. cook, j. misra. a language for task orchestration and its semantic properties. in baier and hermanns (eds.), concur 2006. lncs 4137, pp. 477–491. springer, 2006. [mil06] r. milner. pure bigraphs: structure and dynamics. information and computation 204(1):60–122, 2006. [mp95] u. montanari, m. pistore. concurrent semantics for the pi-calculus. electr. notes theor. comput. sci. 1, 1995. [roz97] g. rozenberg (ed.). handbook of graph grammars and computing by graph transformation, volume 1: foundations. world scientific, 1997. [swz99] a. schürr, a. winter, a. zündorf. the progres approach: language and environment. in engels et al. (eds.), handbook of graph grammars and computing by graph transformations, volume 1: applications, languages and tools. pp. 487–550. world scientific, 1999. [ter08] d. terreni. computational models based on hierarchical graphs: bigraphs and cogsgraphs. master’s thesis, dipartimento di informatica, università di pisa, 2008. 17 / 17 volume 30 (2010) introduction an algebra of hierarchical graphs top-view models side-view models well-typedness and extrusion a calculus with nested structures and communication: caspis encoding caspis into the algebra of designs transformation rules for caspis reduction semantics conclusions certifying assembly with formal cryptographic proofs: the case of bbs electronic communications of the easst volume 23 (2009) proceedings of the ninth international workshop on automated verification of critical systems (avocs 2009) certifying assembly with formal cryptographic proofs: the case of bbs reynald affeldt, david nowak and kiyoshi yamada 15 pages guest editor: markus roggenbach managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst certifying assembly with formal cryptographic proofs: the case of bbs reynald affeldt, david nowak and kiyoshi yamada research center for information security, aist, japan abstract: with today’s dissemination of embedded systems manipulating sensitive data, it has become important to equip low-level programs with strong security guarantees. unfortunately, security proofs as done by cryptographers are about algorithms, not about concrete implementations running on hardware. in this paper, we show how to perform security proofs to guarantee the security of assembly language implementations of cryptographic primitives. our approach is based on a framework in the coq proof assistant that integrates correctness proofs of assembly programs with game-playing proofs of provable security. we demonstrate the usability of our approach using the blum-blum-shub (bbs) pseudorandom number generator, for which a mips implementation for smartcards is shown cryptographically secure. keywords: hoare logic, assembly language, coq, prng, provable security 1 introduction with today’s dissemination of embedded systems manipulating sensitive data, it has become important to equip low-level programs with strong security guarantees. however, despite the fact that most security claims implicitly assume correct implementation of cryptography, this assumption is never formally enforced in practice. the main problem of formal verification of embedded cryptographic software is that, in the current state of research, formal verification remains a major undertaking: (a) most cryptographic primitives rely on number theory and their pervasive usage calls for efficient implementations. as a result, we face many advanced algorithms with low-level implementations in assembly language. this already makes formal proof technically difficult. (b) security guarantees about cryptographic primitives is the matter of cryptographic proofs, as practiced by cryptographers. in essence, these proofs aim at showing the security of cryptographic primitives by reduction to computational assumptions. formal proofs of such reductions also involve probability theory or group theory. in addition, formal verification of embedded cryptographic software is even more challenging in that it requires a formal integration of (a) and (b). in fact, to the best of our knowledge, no such integration has ever been attempted so far. in this paper, we address the issue of formal verification of cryptographic assembly code with cryptographic proofs. as pointed out above, formal verification of cryptographic assembly code and formal verification of cryptographic proofs are not the same matter, even though both deals with cryptography. as an evidence of this mismatch, one can think of a cryptographic function such as encryption: its security proof typically relies on a high-level mathematical description, 1 / 15 volume 23 (2009) certifying assembly with formal cryptographic proofs: the case of bbs but when laid down in terms of assembly code such a function exhibits restrictions due to the choice of implementation. we are therefore essentially concerned about the integration of these two kinds of formal proofs. we do not question here the theoretical feasibility of such an integration; rather, we investigate its practical aspects. indeed, various frameworks for formal verification of cryptography using proof assistants based on proof theory already exist ([am06, mg07] for cryptographic assembly code, [atm07, bbu08, bgz09, now07] for cryptographic proofs), but it is not clear how to connect them in practice. whatever connection is to be provided, it has to be developed in a clear way, both understandable by cryptographers and implementers, and in a reusable fashion, so that new verification efforts can build upon previous ones. our main contribution is to propose a concrete approach, supported by a reusable formal framework on top of the coq proof assistant, for verification of assembly code together with cryptographic proofs. as a concrete evidence of usability, we formally verify a pseudorandom number generator written in assembly for smartcards with a proof of unpredictability. this choice of application is not gratuitous: this is the first step before verifying more cryptographic primitives, since many of them actually rely on pseudorandom number generation. to achieve our goal, we integrate two existing frameworks: one for formal verification of assembly code, and another for formal verification of cryptographic primitives. more precisely, our technical contributions consist in the following: • we propose an integration in terms of game-playing [sho04], a popular setting to represent cryptographic proofs. we introduce a new kind of game transformation to serve as a bridge between assembly code and algorithms as dealt with by cryptographers. this allows for a clear integration, that paves the way for a modular framework, understandable by both cryptographers and implementers. • we extend the formal framework for assembly code of [am06] to connect with the formal framework for cryptographic proofs of [now07]. various technical extensions are called for, that range from the natural issue of encoding mathematical objects such as arbitrarily-large integers into computer memory, to technical issues such as composition of assembly snippets to achieve verification of large programs. all in all, it turns out that it is utterly important to provide efficient ways to deal with low-level details induced by programs being written in assembly. here, we explain in particular how we deal with arbitrary jumps in assembly. concretely, we provide a formalization of the proof-carrying code framework of [su07], that allows us to verify assembly with jumps through standard hoare logics proofs. • we provide the first assembly program for a pseudorandom number generator that is formally verified with a cryptographic proof. the generator in question is the blum-blum-shub pseudorandom number generator [bbs86] that we implement in the smartmips smartcard assembly. alternative approaches and related work our approach is oriented towards practical application, and this goal includes formal verification of hand-written assembly. for this purpose, extension of [am06] is appropriate because it already provides much material for reasonably short proof scripts. one may think of alternative approaches to verify cryptographic assembly code, such as proof-producing compilation or refinement from a functional specification. however, a proof-producing compiler (such as the one of [msg09]) would need to be extended with custom support for cryptography-specific instructions in order to produce efficient code. regarding the approach by refinement from a functional specification, the application to cryptographic proc. avocs 2009 2 / 15 eceasst assembly code in [mg07] does not seem to lead to shorter proof scripts and compact assembly code. addressing these issues would still be not enough for our overall goal, for hol (the proof assistant used in [msg09] and [mg07]) lacking a framework for formal cryptographic proofs. the two existing frameworks ([am06] and [now07]) that we integrate in this paper turn out to be a good fit for they are both based on shallow encodings. on the one hand, shallow encoding is used in [am06] to encode hoare logic assertions, and on the other hand, it is used in [now07] to represent games. therefore, algorithms written as coq functions can simply appear in hoare logic assertions, making for an easy integration. in contrast, games in [bbu08, bgz09] are represented as deep-encoded code. in addition, our use-case directly relies on properties of arithmetic (including an encoding of the quadratic residuosity problem) an originality of [now08]. outline in sect. 2, we introduce the bbs algorithm and provide an assembly implementation. in sect. 3, we explain how we integrate formally proofs of functional correctness for assembly code with game-based cryptographic proofs. in sect. 4, we explain our formalization of the proof-carrying code framework of [su07], that facilitates formal proof of functional correctness of assembly code. in sect. 5, we explain the formal proof of functional correctness of bbs and the lemmas relevant to the integration with its cryptographic proof. in sect. 6, we comment on technical aspects of the coq formalization. we conclude and comment on future work in sect. 7. 2 the bbs pseudorandom number generator 2.1 the bbs algorithm the blum-blum-shub pseudorandom number generator [bbs86] (hereafter, bbs) exploits the quadratic residuosity problem. this problem is to decide whether integers have square roots in modular arithmetic. this is believed to be intractable for multiplicative group of integers modulo m where m is the product of two distinct odd primes. bbs exploits the quadratic residuosity problem in the particular case of m being a blum integer, i.e., the product of two distinct odd primes congruent to 3 modulo 4. here follows an implementation of bbs as a coq function. it performs iteratively squaring bbs(len ∈ n, seed ∈ z∗m) =def bbs rec(len, seed2) bbs rec(len ∈ n, x ∈ qrm) =def match len with | 0 ⇒ [] | len′ + 1 ⇒ parity(x) :: bbs rec(len′, x2) end modulo and outputs the result of parity tests. the input is the desired number of pseudorandom bits (len) and a random seed (seed) for initialization. z∗m is the multiplicative group of integers modulo m and qrm is the set of quadratic residues modulo m. bbs is one of the rare pseudorandom number generators that is cryptographically secure, i.e., it passes all polynomial-time statistical tests (no polynomial-time algorithm can distinguish between an output sequence of the generator and a truly random sequence). this strong property is not required of most applications of pseudorandom numbers, except cryptography. in practice, bbs can be proved left-unpredictable (hereafter, “unpredictable”) under the assumption that the quadratic residuosity problem is intractable (this is equivalent to prove that bbs passes all polynomial-time statistical tests [yao82].) 3 / 15 volume 23 (2009) certifying assembly with formal cryptographic proofs: the case of bbs 2.2 implementation of bbs in assembly the assembly code bbs asm in fig. 1 implements bbs. it is written with mips instructions (actually, we use smartmips, a superset of mips32 with additional instructions for smartcards [mips]). it consists of a loop with a nested loop. each iteration of the nested loop produces bbs asm =def 0: addiu i gpr zero 016 (* init counter for outer loop *) 1: addiu l l 016 (* init pointer to result *) 2: beq i n 240 (* repeat n times *) 3: addiu j gpr zero 016 (* init counter for inner loop *) 4: addiu w gpr zero 016 (* init word of temporary storage *) 5: beq j thirtytwo 236 (* repeat 32 times *) 6: mul mod k x x m . . . (* compute x 2 (mod m) *) 222: lw w′ 016 x (* load least significant word *) 223: andi w′ w′ 116 (* extract parity bit *) 224: sllv w′ w′ j (* shift parity bit to jth position *) 225: cmd or w w w′ (* store parity bit in temporary storage *) 226: addiu j j 116 (* increment inner loop counter *) 227: jmp 5 (* end of the inner loop *) 228: sw w 016 l (* store the last 32 parity bits in memory *) 229: addiu l l 416 (* increment pointer to result *) 230: addiu i i 116 (* increment outer loop counter *) 231: jmp 2 (* end of the outer loop *) 232: figure 1: the blum-blum-shub pseudorandom number generator in assembly one word of pseudorandom bits by performing a square modulo, extracting the parity bit (of the least significant word), and storing this bit in a temporary word of storage in an appropriate position using bitwise operations. these temporary words of storage are then stored in memory contiguously by the outer loop so as to produce a pseudorandom number. the names of registers (in italic font) are parameters; only the null register gpr_zero is hardwired in the program. magic numbers are indexed with their length in bits (e.g., 016 stands for 0 represented as a half-word). mul mod is an inlined assembly program explained in the next section. 2.3 implementation of modular multiplication in assembly we implement multi-precision square modulo using the montgomery multiplication [mon85]. this is not the fastest way to implement multi-precision square modulo but, still, this is reasonable: like the natural multi-precision multiplication/division, it has a quadratic complexity. moreover, we already have a formal proof for an optimized version of the montgomery multiplication [am06], whereas, to the best of our knowledge, such a formal proof for multi-precision division does not exist yet. using montgomery, modular multiplication is performed as follows. given three k-word integers m, x ,y , the montgomery multiplication computes a k + 1-word integer z such that proc. avocs 2009 4 / 15 eceasst β kz = x .y (mod m) and z < 2m (β = 232). this is almost a multiplication modulo except for the parasite value β k and because z 6< m in general. to turn it into a genuine multiplication modulo, one needs (1) an additional subtraction to reduce z by m when necessary and (2) two passes to eliminate the parasite value. the second pass requires as an additional input a k-word a = β 2k (mod m); given z such that β kz = x .y (mod m), it suffices to compute z′ such that β kz′ = z.a (mod m): if m is odd (this is generally the case for cryptographic applications), one obtains as desired z′ = x .y (mod m). the assembly code mont mul strict init in fig. 2 implements the montgomery multiplication extended with comparison and subtraction. it makes use of the functions montgomery (the mont mul strict init =def 6: multi zero ext k z z (* output initialization *) 13: mflhxu gpr_zero (* multiplier inialization *) 14: mthi gpr_zero 15: mtlo gpr_zero 16: montgomery k alpha x y z m one ext int x y m z quot c t s 54: beq c gpr_zero 79 (* is the output k + 1-word long? *) 55: addiu t t 416 56: sw c 016 t 57: addiu ext k 116 58: multisub ext one z m z m int quot c z x y x 78: jmp 114 79: multi lt prg k z m x y int ext z m 91: beq int gpr_zero 94 (* is the output bigger than the modulus? *) 92: skip 93: jmp 114 94: multisub k one z m z ext int quot c z x y x 114: mul mod =def 6: mont mul strict init k alpha x x y m one ext int x b2k y m quot c t s 114: mont mul strict init k alpha y b2k x m one ext int x b2k y m quot c t s 222: figure 2: the montgomery multiplication extended with comparison and subtraction function verified in [am06]), (in-place) subtraction multi sub (derived from [am06]), multiprecision comparison multi lt and an initialization function multi zero (see [code] for the details). the assembly code mul mod in fig. 2 perform a square modulo by using twice mont mul strict init, provided we assume that the register b2k points to the pre-computed k-word a = β 2k (mod m). 3 game-based proofs for assembly cryptographic proofs usually apply to algorithms without any consideration for implementation. in order to prove unpredictability directly on assembly code, we propose to lift a standard definition borrowed from game-playing [sho04]. game-playing is a methodology to write cryptographic proofs that are easier to verify; it lends itself well to formalization [atm07, bbu08, 5 / 15 volume 23 (2009) certifying assembly with formal cryptographic proofs: the case of bbs bgz09, now07]. a security property is modeled as a game (a program) to be solved by an attacker, the latter being modeled as some probabilistic procedure. a cryptographic proof consists in showing that any attacker has only little advantage over a random player, by (1) stating the security property for the cryptographic primitive to be verified, and (2) reducing it to a computational assumption through game transformations. regarding unpredictability for a function f , the game unpredictability( f ) is defined as follows [now08]: a seed is picked at random in the set of seeds g (z∗n in the case of bbs); a sequence of bits [b0, . . . , blen] is computed by f ; this sequence, deprived of its first bit b0, is passed to the attacker a; the latter returns its guess b̂0. the result of the game is whether the guess is right or not. to define unpredictability for assembly code, one needs to lift the previous definition because it applies to mathematical functions without any consideration for their implementation. this makes a difference because, contrary to mathematical functions, assembly code does not work as intended for arbitrary input, due to restrictions imposed by the choice of implementation. the basic idea is thus to extract from the assembly code its semantics in terms of a mathematical function and to inject it into the definition of unpredictability: unpredictability assembly(c) =def unpredictability(jck). for jck to be well-defined, the assembly code c has to be deterministic and terminating, and, more importantly, one needs to make clear under which restrictions the assembly code behaves as intended (the correctness property). the advantage of the lifting explained above is that it makes clear how to organize formal verification of assembly code with cryptographic proofs. games for assembly connect to standard games through implementation steps, that are justified formally by ensuring determinism, termination, and correctness. since implementation steps come in addition to the other game transformations [sho04], this makes it easier to develop a formal framework for verification of assembly with cryptographic proofs: pick up a formal framework for game-based proofs and a formal framework for assembly, and add the machinery for implementation steps. 4 verification of functional correctness of assembly to perform cryptographic proofs of an implementation, we need in particular to prove its functional correctness. this is technically difficult for assembly because handling of jumps results in non-standard logics, usually verbose, and thus less practical than standard hoare logic. to overcome this difficulty, we formalize the proof-carrying code framework of [su07] that provides not only a compositional operational semantics and hoare logic for assembly with jumps, but also shows that derivations for this non-standard operational semantics and this hoare logic can be obtained from standard operational semantics and standard hoare logic by compilation. the following is an overview of our formalization of [su07]; it includes a formalization of standard separation logic that is actually a revision of [am06] recalled for the sake of self-containedness. 4.1 operational semantics formalization of states a state is a pair of a store and a heap: state =def store × heap. a store is a collection of registers containing integers of finite size. let intn be the type of machine integers encoded with n bits. most registers contain values of type int32 (the exception is the proc. avocs 2009 6 / 15 eceasst extended accumulator of type intn with n ≥ 8). we have the following notations: jrks is the value of register r in store s; s{v/r} is the store resulting from updating register r with value v in store s. a heap is a finite map from locations to integers of type int32. the heap is tailored to word-accesses because most memory accesses in our applications are word-aligned. we have the following notation: h[l] is the contents of location l of the heap h; it is none when the location is undefined. states are extended with a label (that represents the value of the program counter of the instruction being currently executed) and can be error states (because some instructions may trap). we distinguish error states using an option type, hence the definition of labelled states: lstate =def option (label × state). one-step, non-branching instructions the semantics of non-branching mips instructions is a predicate noted s − i −→ s′ where i is a mips instruction, s (resp. s′) is the state before (resp. after) its execution. when formalizing the semantics of instructions, we need to express conditions such as word-alignment, absence of arithmetic overflow, etc. these conditions require manipulations such as sign-extending int16 integers to int32 integers, checking for divisibility by 4, etc. for this purpose, we introduce various operators: (v)int16→int32 sign-extends the value v from 16 to 32 bits, (v)int32→n interprets the value v as an unsigned integer, etc. figure 3 illustrates the semantics of mips instructions with the rules for the instruction lw (“load word”). there are two rules depending on whether the memory access is word-aligned and the accessed location is defined. (the notation +h is the addition of finite-size integers.) ( jbaseks +h (off )int16→int32 ) int32→n = 4 × p h[p] = some z some (s, h) − lw rt off base −→ some (s{z/rt}, h) exec0 lw ∀p. ( jbaseks +h (off )int16→int32 ) int32→n 6= 4 × p ∨ h[p] = none some (s, h) − lw rt off base −→ none exec lw error figure 3: semantics of lw big-step operational semantics of assembly with jumps following [su07], an assembly program is formalized as a set of labelled instructions. the latter are either labelled mips instructions or jump instructions (unconditional jumps jmp l or conditional jumps cjmp b l). conditional jumps comprise mips instructions such as bne (“branch if not equal”), etc; these instructions are parameterized by conditions noted b. dom(c) is the set of the labels of the instructions of the assembly program c. labelled instructions are assembled using ⊕. the operational semantics of assembly programs is a predicate noted s � c _ s′ where c is a set of labelled instructions, s (resp. s′) is the state before (resp. after) its execution. it is defined inductively by the rules of fig. 4. these rules are a generalization of [su07] with more instructions and with error states. the originality of this semantics can be appreciated by looking at the two rules for sequences using ⊕; intuitively, they are a mix of the rules for sequence and while-loops of traditional hoare logic. 7 / 15 volume 23 (2009) certifying assembly with formal cryptographic proofs: the case of bbs some s − i −→ some s′ some (l, s) � l : i _ some (l + 1, s′) some s − i −→ none some (l, s) � l : i _ none l 6= l′ some (l, s) � l : jmp l′ _ some (l′, s) jbks l 6= l′ some (l, s) � l : cjmp b l′ _ some (l′, s) ¬jbks some (l, s) � l : cjmp b l′ _ some (l + 1, s) l ∈ dom(c1) some (l, s) � c1 _ s′ s′ � c1 ⊕ c2 _ s′′ some (l, s) � c1 ⊕ c2 _ s′′ l ∈ dom(c2) some (l, s) � c2 _ s′ s′ � c1 ⊕ c2 _ s′′ some (l, s) � c1 ⊕ c2 _ s′′ none � c _ none l /∈ dom(c) some (l, s) � c _ some (l, s) figure 4: big-step operational semantics of assembly with jumps 4.2 hoare logics the non-standard operational semantics of the previous section gives rise to a non-standard hoare logic for assemblies with jumps. we now formalize the hoare logics from [su07] (actually, extensions known as separation logic [rey02]). assertions properties of states are specified using a shallow-encoding of the logical connectives of separation logic, i.e., assertions are functions from states to the type prop of propositions in coq: assertion =def store � heap � prop. the satisfiability of an assertion can depend on the value of the current label: assn =def label � assertion. standard separation logic a triple in this logic is noted {p}c{q} where p and q are assertions and c is an assembly program with while-loops instead of jumps. let us introduce a function that computes the weakest precondition of one-step, non-branching mips instructions. here is an excerpt of this function for the “load word” instruction: wp i q =def match i with | lw rt off base ⇒ λ s, h.∃p. ( jbaseks +h (joff ks)int16→int32 ) int32→n = 4×p ∧ ∃z.h[p] =some z ∧ q s{z/rt} | . . . end using the above function, the standard separation logic is defined by the following rules: {wp i q}i{q} {p}c1 {r} {r}c2 {q} {p}c1;c2 {q} {λ s, h.p ∧jbks}c{p} {p}while b c{λ s, h.p ∧¬jbks} {λ s, h.p ∧jbks}c1 {q} {λ s, h.p ∧¬jbks}c2 {q} {p}if b then c1 else c2 {q} p � p′ { p′ } c { q′ } q′ � q {p}c{q} proc. avocs 2009 8 / 15 eceasst this logic is formally proved sound and complete w.r.t. standard big-step operational semantics, where assembly code with while-loops is built out of mips instructions (sect. 4.1), sequences (c1;c2), structured branching (if b then c1 else c2), and while-loops (while b c): none − c _ none s − c −→ s′ s − c _ s′ s − c1 _ s′′ s′′ − c2 _ s′ s − c1;c2 _ s′ jbks some (s, h) − c1 _ s′ some (s, h) − if b then c1 else c2 _ s′ ¬jbks some (s, h) − c2 _ s′ some (s, h) − if b then c1 else c2 _ s′ jbks some (s, h) − c _ s′ s′ − while b c _ s′′ some (s, h) − while b c _ s′′ ¬jbks some (s, h) − while b c _ some (s, h) separation logic based on the compositional hoare logic of [su07] a triple in this logic is noted [p] c [q] where p and q are labelled assertions (type assn) and c is an assembly program with jumps. we introduce predicate transformers that enforce assertions to be satisfiable for labels inside (resp. outside) a domain: p|d =def λ l.p l ∧l ∈ d, p|d =def λ l.p l ∧l /∈ d. using above predicate transformers and the above weakest-precondition function, we formalize the rules for the compositional hoare logic below. this logic is formally proved sound and complete w.r.t. the big-step operational semantics of sect. 4.1. [ λ pc.λ s. pc = l ∧(p j s ∨ j = l) ∨ pc 6= l ∧p pc s ] l : jmp j [p] [ λ pc.λ s. pc = l ∧(¬jbks ∧p (l + 1) s ∨jbks ∧(p j s ∨ j = l)) ∨ pc 6= l ∧p pc s ] l : cjmp b j [p] [p] nop [p] [ λ pc.λ s. pc = l ∧wp c (p (l + 1)) s ∨ pc 6= l ∧p pc s ] l : c [p] [ p|dom(c1) ] c1 [p] [ p|dom(c2) ] c2 [p] [p] c1 ⊕ c2 [ p|dom(c1⊕c2) ] ∀l.p l � p′ l [p′] c [q′] ∀l.q′ l � q l [p] c [q] 4.3 compilation from standard semantics and hoare logic [su07] shows that derivations for the previous non-standard operational semantics and hoare logic can also be obtained from standard operational semantics and hoare logic through compilation. this is a result of interest because it allows us to work with standard operational semantics and hoare logic (that are more practical to deal with formally) while still being able to recover formal proofs for assembly with jumps (these are the formal proofs that we really want, for example for shipping in a proof-carrying code scenario). the compilation procedure turns if-then-else’s and while-loops into conditional and unconditional jumps. the compilation of program c with while-loops to an assembly program c′ with jumps is noted c l ↘l′ c′ where l (resp. l′) is the start (resp. end) label of the compiled program: 9 / 15 volume 23 (2009) certifying assembly with formal cryptographic proofs: the case of bbs i l ↘l+1 l : i c1 l1+1 ↘l2 c ′ 1 c2 l+1 ↘l1 c ′ 2 if b then c1 else c2 l ↘l2 l : cjmp b (l1 + 1)⊕((c ′ 2 ⊕ l1 : jmp l2)⊕ c ′ 1) c1 l ↘l1 c ′ 1 c2 l1 ↘l2 c ′ 2 c1;c2 l ↘l2 c ′ 1 ⊕ c ′ 2 c l+1 ↘l1 c ′ while b c l ↘l1+1 l : cjmp (¬b) (l1 + 1)⊕(c ′ ⊕ l1 : jmp l) through compilation, derivations of operational semantics can be compiled from the standard one to the non-standard one of sect. 4.1, and, similarly, proofs in separation logic can be compiled from the standard one to the non-standard one of sect. 4.2: lemma preservation of evaluations : for all c s l c′ s′ l′, if c l ↘l′ c′ and some s − c _ some s′, then some (l, s) � c′ _ some (l + card(dom(c′)), s′). lemma preservation hoare : for all p, q, c such that {p}c{q} and for all l, c′, l′ such that c l ↘l′ c′ then [λ pc.λ s. pc = l ∧p s] c′ [λ pc.λ s. pc = l′ ∧q s] . 5 extraction of the semantics of bbs in assembly 5.1 the functional correctness of bbs in assembly let us provide two functions encode and decode such that: encode (n, k, seed, m) builds a state from the requested number n of pseudoramdom 32-bits words, the number k of 32-bits words reserved for the encoding of the seed and the modulus, the seed, and the modulus m; and decode (s) is the list of pseudorandom bits stored in the state s. these functions impose a specific memory layout depicted in fig. 5. besides the encoding of the seed (in memory area x ) and the modux 032 m 032 l y 032 β 2kmemory before execution: k+1 words k+1 words n words k+1 words k words n, k, seed, m encode x′ 032 m 032 l′ y ′ 032 β 2kmemory after execution: [b0, . . . , b32n−1] decode � bbs asm _ figure 5: encoding and decoding of input/output lus (in m) as multi-precision integers, and initialization of the list of pseudorandom bits (in l) to an appropriate length, encode provides additional storage (y , β 2k, trailing words initialized to 032) specific to our implementation (this stems from our montgomery multiplication). note proc. avocs 2009 10 / 15 eceasst that, as long as 4(4k + n + 2) < 232, n and k can be very large, k effectively covering lengths for which the quadratic residuosity problem is indeed believed to be intractable. this is one desirable side-effect of our approach to precisely pinpoint the range of k. using above functions, the verification goal is stated as follows: 4(4k + n + 2) < 232 →[ λ pc.λ s. pc = 0 ∧ encode (n, k, seed, m) = s ] bbs asm [ λ pc.λ s. pc = 232 ∧ decode (s) = bbs fun(32×n, seed, m) ] starting from an appropriate encoding of the inputs, the execution of bbs asm leads to a final state from which one can extract the intended list of pseudorandom bits (see [code] for details). it is here that the restrictions imposed by the choice of implementation mentioned in sect. 3 appear, for the above triple cannot be proved for arbitrary values of n and k. in practice, we conduct formal proof using standard separation logic and obtain the triple above by applying the lemma preservation hoare of sect. 4.3. the effort therefore concentrates on the following triple where the assembly program with jumps has been replaced by its “decompiled” version with if-then-else’s and while-loops (manual decompilation proved correct w.r.t. the compilation predicate of sect. 4.3): 4(4k + n + 2) < 232 → {λ s. encode (n, k, seed, m) = s}bbs asm decompile{λ s. decode (s) = bbs fun(32×n, seed, m)} (1) note that we are dealing with a generalized version of the bbs algorithm (bbs fun takes the modulus m in z, whereas bbs in sect. 2.1 uses the types z∗m and qrm): bbs fun(len ∈ n, seed ∈ z, m ∈ z) =def bbs fun rec(len, seed2 (mod m), m) bbs fun rec(len ∈ n, x ∈ z, m ∈ z) =def match len with 0 ⇒ [] | len′ + 1 ⇒ parity(x) :: bbs fun rec(len′, x2 (mod m), m) end this is a sound generalization because the information that z∗m is a cyclic group is not needed in the proof of functional correctness (only in the cryptographic proof). 5.2 extraction of the semantics of bbs in assembly first, we prove that bbs asm is terminating and deterministic, i.e., for all n, k, seed and m, there exists a unique state s′ such that some (0, encode (n, k, seed, m)) � bbs asm _ s′. from the separation logic triple of the previous section, we derive by soundness of separation logic: lemma correctness : if some (0, encode (n, k, seed, m)) � bbs asm _ some (l′, s′) and 4(4k + n + 2) < 232, then l′ = 232 and decode (s′) = bbs fun(32×n, seed, m) then comes the proof of termination. first, we prove that there is a final state, without proving whether it is an error state or not: lemma execution bbs asm : if 4(4k + n + 2) < 232, then there exists s′ s. t. some (0, encode (n, k, seed, m)) � bbs asm _ s′ 11 / 15 volume 23 (2009) certifying assembly with formal cryptographic proofs: the case of bbs this is proved by induction on the variant of the outermost loop, and then on nested loops. second, by the triple (1), we derive the fact that this final state cannot be an error state. the lemmas above allow us to define a function execbbs asm that maps a number n of 32 bits words, a number k of 32 bits words, a seed and a modulus m to a state from which one can extract the desired pseudorandom bits, so that the semantics of bbs asm can be written as a mathematical function: jbbs asmk =def prefixlen+1 ( decode ( execbbs asm (⌈ len + 1 32 ⌉ ,dlog232 (m)e, seed, m ))) since bbs asm always return a number of pseudorandom bits that is a multiple of 32, we need to take a prefix of its output; len + 1 is the length requested by the unpredictability game. putting it all together the figure below summarizes how we organize the complete gamebased proof of bbs in assembly. bbs_encode_decode.v contains the encode/decode functions and the formal proof of correctness and termination, derived from the formal proof of the separation logic triple for bbs asm. bbs_asm_cryptoproof.v contains the game-based proof, making use of the correctness and termination lemmas and of the cryptographic proof of the bbs algorithm provided by bbs.v, taken directly from [now08]. framework for assembly [am06] � � � � � � � � framework for games [now08] bbs prg.v (sect. 2.2) uukkk k **uuu uu bbs.v yy bbs triple.v (sect. 5.1) ))sss ss bbs termination.v (sect. 5.2) ttiiii i bbs encode decode.v (sect. 5.2) 33 bbs asm cryptoproof.v (sect. 3) 6 technical aspects of the coq formalization the formalization of assembly programs, operational semantics, separation logic, as well as all supporting lemmas is the result of a revision of our previous work [am06]. this revision was made necessary to address scalability issues. we do not comment extensively about this revision except to say that we used ssreflect [gm07], a recently publicized coq extension, that favors a proof style that naturally led to shorter proof scripts (for illustration, proof scripts of experiments in [am06] shrank by 70% in terms of lines of code). the new aspect of our framework is the formalization of the proof-carrying code framework of [su07], that we instantiate to separation logic and mips instructions and extend to deal with error-states. table 1 makes it clear what is formalized w.r.t. [su07]. in brief, what we do not do: we do not formalize section 5 of [su07] and we formalize only the so-called “non-constructive proofs” of theorems 17 and 18 (indeed, for these two theorems, the proofs come in two flavors). the formal proof of the separation logic triple of sect. 5.1 is technically the most demanding part of the proof effort. our assembly program of bbs is large (at least by the current standards proc. avocs 2009 12 / 15 eceasst reference in [su07] reference in [code] and status proof script size section 2 file goto.v 462 lines figure 1, lemma 1, 3 done lemma 2 particular cases only section 3 file sgoto.v 747 lines section 3.1: figure 2, lemmas 4–5, done theorems 6–8, corollary 9 section 3.2: figure 3, theorem 10, done lemma 11, theorem 12 section 4 file compile.v 1279 lines section 4.1: figure 5, done lemmas 13–14, theorems 15–16 section 4.2: theorems 17–18 done section 4.3 done, file sgoto_hoare.v 369 lines section 5 not done appendix a done (revision of [am06]) file mips_biple.v 927 lines file mips_cmd.v 710 lines file mips_hoare.v 783 lines appendix b theorems 6–7, 15–18 done (spread over above files) table 1: formalization of [su07] of proof assistant-based verification [am06, mg07]): 239 instructions that spread over several snippets of code. table 2 makes it precise which snippets are used and their respective size. function reference in [code] program size bbs bbs_prg.v 14 commands montgomery strict (fig. 2) mont_mul_strict_prg.v 9 commands montgomery raw ([am06]) mont_mul_prg.v 36 commands multi-precision subtraction multi_sub_prg.v 18 commands multi-precision comparison multi_lt_prg.v 11 commands array initialization multi_zero_prg.v 6 commands table 2: the assembly code of bbs in coq table 3 summarizes the size of proof scripts used in the proof of the separation logic triple of bbs. it is always difficult to comment about the size of proof scripts because we are lacking good metrics for comparison. yet, looking at related work, it is fair to claim that our framework for formal proof of assembly programs allows for short proof scripts: this can be appreciated by looking at several similar experiments in common among the work in this paper and [am06, mg07] (verification of multi-precision arithmetic, montgomery multiplication, but also montgomery exponentiation, not used in this paper though). 13 / 15 volume 23 (2009) certifying assembly with formal cryptographic proofs: the case of bbs function reference in [code] size bbs bbs_triple.v 845 lines montgomery strict mont_{mul,square}_strict_init_triple.v 608 lines montgomery raw mont_{mul,square}_triple.v 1198 lines multi-precision subtraction multi_sub_inplace_left_triple.v 439 lines multi-precision comparison multi_lt_triple.v 408 lines array initialization multi_zero_triple.v 129 lines total 3627 lines table 3: formal proof of the separation logic triple of bbs 7 conclusion we addressed the problem of formal verification of assembly code with cryptographic proofs. we proposed an approach that extends game-based proofs to integrate formal proofs of functional correctness with formal cryptographic proofs in a clear way, understandable by both cryptographers and implementers. our proposition is supported by a concrete framework developed in the coq proof assistant. as an illustration, we provided the first assembly program for a pseudorandom number generator that is certified with a cryptographic proof. future work the cryptographic proof of bbs on which we rely is asymptotic: the probability that an attacker predicts the next bit can be made arbitrarily small, but it does not give any concrete value for the security parameter. a possible extension of our approach would be to link our assembly implementation of bbs to a cryptographic proof of the concrete security of bbs. our certified implementation of bbs could be used as the source of pseudorandomness in the implementation of further cryptographic primitives. indeed, even though it is probabilistic, such a primitive is still deterministic in the sense that for any two equal inputs it outputs the same distribution; one can thus extract its semantics as a mathematical function and inject it into the appropriate standard definition of security (such as semantic security in the case of elgamal). acknowledgements: this work was partially supported by kakenhi 21700048 and 21500046. the authors are grateful to an anonymous reviewer for his/her comments. bibliography [atm07] affeldt, r., tanaka, m., marti, n.: formal proof of provable security by gameplaying in a proof assistant. int. conf. on provable security. lncs, vol. 4784, pp. 151–168. springer (2007). [am06] affeldt, r., marti, n.: an approach to formal verification of arithmetic functions in assembly. annual asian computing science conference, dec. 2006. lncs, vol. 4435, pp. 346–360. springer, heidelberg (2008). [bbu08] backes, m., berg, m., unruh d.: a formal language for cryptographic pseudocode. int. conf. on logic for programming, artificial intelligence, and reasoning. lncs, vol. 5330, , pp. 353–376. springer (2008). proc. avocs 2009 14 / 15 eceasst [bgz09] barthe, g., grégoire, b., zanella, s.b.: formal certification of code-based cryptographic proofs. acm sigplan-sigact symp. on principles of programming languages, pp.90–101. acm press. [br04] bellare, m., rogaway, p.: code-based game-playing proofs and the security of triple encryption. cryptology eprint archive, report 2004/331, 2004. [bbs86] blum, l., blum, m., shub, m.: a simple unpredictable pseudo random number generator. siam journal on computing, 15(2):364–383. society for industrial and applied mathematics, 1986. [code] affeldt, r., nowak d., yamada k.: certifying assembly with cryptographic proofs: the case of bbs. http://staff.aist.go.jp/reynald.affeldt/bbs [gm07] gonthier, g., mahboubi, a.: a small scale reflection extension for the coq system. technical report 6455, dec. 2007. inria. [mips] mips technologies. mips32 4ks processor core family software user’s manual mips technologies, inc., 1225 charleston road, mountain view, ca 94043-1353. [mon85] montgomery, p.l.: modular multiplication without trial division. mathematics of computation, 44(170):519–521, 1985. [mg07] myreen, m.o., gordon, m.j.c.: verification of machine code implementations of arithmetic functions for cryptography. theorem proving in higher order logics: emerging trends proceedings. internal report 364/07, aug. 2007. department of computer science, university of kaiserslautern. [msg09] myreen, m.o., slind, k., gordon, m.j.c.: extensible proof-producing compilation. int. conf. on compiler construction. lncs, vol. 5501, pp. 2–16. springer (2009). [now07] nowak, d.: a framework for game-based security proofs. int. conf. on information and communications security. lncs, vol. 4861, pp. 319–333. springer (2007). [now08] nowak, d.: on formal verification of arithmetic-based cryptographic primitives. int. conf. on information security and cryptology, dec. 2008. lncs, vol. 5461, pp. 368-382. springer (2009). [rey02] reynolds, j.c.: separation logic: a logic for shared mutable data structures. ieee symp. on logic in computer science, pp. 55–74 (2002). invited lecture. [su07] saabas, a., uustalu, t.: a compositional natural semantics and hoare logic for lowlevel languages. theoretical computer science 373(3), 273–302. elsevier (2007). [sho04] shoup, v.: sequences of games: a tool for taming complexity in security proofs. cryptology eprint archive, report 2004/332, 2004. [yao82] yao, a.c.: theory and applications of trapdoor functions. ieee annual symp. on foundations of computer science. pp. 80–91. ieee (1982). 15 / 15 volume 23 (2009) http://staff.aist.go.jp/reynald.affeldt/bbs introduction the bbs pseudorandom number generator the bbs algorithm implementation of bbs in assembly implementation of modular multiplication in assembly game-based proofs for assembly verification of functional correctness of assembly operational semantics hoare logics compilation from standard semantics and hoare logic extraction of the semantics of bbs in assembly the functional correctness of bbs in assembly extraction of the semantics of bbs in assembly technical aspects of the coq formalization conclusion on teaching logic and algebraic specification electronic communications of the easst volume 26 (2010) manipulation of graphs, algebras and pictures essays dedicated to hans-jörg kreowski on the occasion of his 60th birthday on teaching logic and algebraic specification till mossakowski 19 pages guest editors: frank drewes, annegret habel, berthold hoffmann, detlef plump managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst on teaching logic and algebraic specification till mossakowski till.mossakowski@dfki.de, http://www.dfki.de/sks/till/ german research center for artificial intelligence (dfki gmbh), bremen, germany sfb/tr 8 spatial cognition, universität bremen, germany abstract: we discuss teaching experiences with courses on first-order logic and on algebraic specification, with an emphasis on software tools that can be used by students and that illustrate the meaning of logical notions. in particular, we discuss language, proof and logic and the heterogeneous tool set. moreover, we claim that structuring constructs like those of the common algebraic specification language can be better digested when starting with applying them to propositional logic. keywords: first-order logic, algebraic specification, structured specification, teaching courses on algebraic specification and logic have been important cornerstones of teaching theoretical computer science for many years. moreover, algebraic specification and logic are applied not only in areas like software specification and verification, but also in ontologies and weak artificial intelligence1, and other areas. during my studies, i myself was greatly influenced by courses on algebraic specification and logic. the logic courses mainly provided a very abstract and dry introduction to the formalities of logic — the motivation for logic was expected to have arisen independently of the course. by contrast, hans-jörg kreowski always has carefully motivated his courses on algebraic specification (and other subjects), has brought spirit into concepts by using a graphic and descriptive style of presentation, and activated students by insisting on letting them answer questions, discuss points and solve exercises, with room for developing own ideas (especially within so-called student projects, a specialty of bremen university). this teaching greatly influenced my choice of research subject. in this work, i will report on some research and some teaching i have done in the context of the common algebraic specification language (casl [bm04, cof04]). casl is a common language for algebraic specification that has been initiated by the ifip working group 1.3 “foundations of systems specification” (see also the report [akk99]), which was founded and initially lead by hans-jörg kreowski. 1 first-order logic basically, i regularly teach a course about logic that is quite popular (attended by roughly 100 students) and a course on more specialised subjects usually attended only by smaller groups of students. 1here, weak ai is used for systems that solve tasks in specialised domains using heuristics or learning, as opposed to strong ai, which aims at passing the turing test. 1 / 19 volume 26 (2010) mailto:till.mossakowski@dfki.de http://www.dfki.de/sks/till/ on teaching logic and algebraic specification figure 1: evaluating first-order sentences with the program tarski’s world. 1.1 language, proof and logic for teaching first-order logic, i use the book “language, proof and logic” [be02], abbreviated lpl. the most striking feature of lpl is the use of software tools supporting the students with their own exercises and experiments in logic. this goes as far that a server in stanford can automatically evaluate some of the students’ exercises and give detailed feedback, such that students can revise their solutions. this allows a far better activation of students than with lectures alone — in a lecture using ex-cathedra teaching in front of 100 students, only a small portion of them can actually participate. however, the usefulness of the software tools should also not be overestimated: it is still very important to have handwritten exercises that are corrected by the teacher, as well as explanations of the students and discussions within the lecture. in my view, the most important insight of lpl is the following: the notion of first-order festschrift h.-j. kreowski 2 / 19 eceasst figure 2: sample proof with the program fitch. 3 / 19 volume 26 (2010) on teaching logic and algebraic specification structure (or model) is an advanced topic!1 (the same holds for the notion of algebra used in algebraic specification.) instead, lpl largely uses a fixed interpretation of first-order logic in a blocks world (see figure 1 showing a screenshot of the program tarski’s world). of course, with using a fixed domain of interpretation (carrier set) and fixed interpretation of predicates, one loses much of the “loose specification” approach used in both algebraic specification and logic. however, the essential gain over the traditional approach is that a fixed interpretation is much easier to grasp. indeed, a useful didactic will proceed from the concrete to the abstract (and not vice versa), and the abstractness of the concept of (carrier) set (and of function and relation) is often underestimated — even if illustrated with useful example carrier sets from computer science like lists, strings or trees.2 moreover, fixing the carrier set and interpretation of predicates is not as harmful as it looks: in a blocks world, it is still possible to obtain some degree of looseness by using different configurations of the blocks. students can then inspect the effect of different configurations on the evaluation of sentences, and use a game, a so-called henkin-hintikka game, to understand the evaluation in more detail. some looseness of course is also essential to understand the concept of logical consequence — another concept that is surprisingly difficult to grasp for many students. the most difficult part to understand is that logical consequence does not imply the truth of the premises — it also holds in cases where the premises are always false. here, the interplay of tarski’s world with fitch greatly helps: fitch is a program that can be used for the construction of a natural deduction proof, in case that a logical consequence actually holds — in the other cases, tarski’s world can be used to construct counter-models. a sample proof with fitch is shown in figure 2. it uses a subproof for proving a universally quantified implication. fitch does not construct such proofs, it only checks them and sometimes provides the resulting formula for a step (if a proof rule and formulas supporting its application have been selected appropriately). fitch also checks if restrictions set up by the instructor have met, e.g. that the built-in first-order prover must not be used, or that a certain conclusion has to be reached. the feedback that fitch gives allows students to try out and play around with proof construction. moreover, lpl offers a great deal of motivation and explanation of the natural deduction calculus (and fitch) in terms of common natural language arguments. lpl also discusses strategies to find proofs; e.g. a simple strategy is to look at the main connectives of the premises and try corresponding elimination rules, or try the introduction rule corresponding to the main connective of the conclusion. however, it must be noted that students much more often have difficulties with fitch than with tarski’s world. the reason seems to be again the level of abstraction: while tarski’s world is about a blocks world that is still close to everyday experience, fitch is about proofs that follow certain rules which are quite common in mathematical arguments, but not in everyday experience. moreover, students often have difficulties with finding suitable rules to apply in a given situation, or with the development of a proof strategy. therefore, the development of proof strategies is explicitly discussed in the lecture and supported with numerous exercises. however, i think that this still does not suffice. an interactive dialogue suggesting different 1first-order structures are only treated in part iii of the book (covering advanced topics). 2let me further illustrate this point with some anecdotes about the concept of function. vladimiro sassone told me that he taught a course on recursive functions. after several weeks, he spent one lecture on students’ questions. the first question was: “what is a function?”. michael kohlhase regularly poses this question in his oral exams, and in spite of him announcing this question, only about 60% of students know the answer. festschrift h.-j. kreowski 4 / 19 eceasst figure 3: sample proof with hets and spass. 5 / 19 volume 26 (2010) on teaching logic and algebraic specification strategies or heuristics might help to stimulate more experiments also for those students that do not grasp natural deduction so quickly. probably, also more exercises requiring the judgement of given fitch proofs would be useful. 1.2 hets and state-of-the-art provers this also brings me to another point: the relation of fitch to state-of-the-art automated and interactive theorem provers. some students are motivated to conduct larger proofs, but fitch is not suited for this, since it is not possible to prove lemmas and theorems for later re-use. here, i use casl and the heterogeneous tool set hets [mml07, mos05], which offers the connection to a selection of resolution provers (spass, vampire) and tableau provers (isabelle), as well as to sat solvers (zchaff, minisat) — all tools that are used in current research. however, these tools of course do not offer the special proof rule provided by fitch that can be used to derive facts that are specific to the blocks world (this rule is called “anacon”). actually, the rule anacon is not explained in the book. however, it can be simulated with a suitable first-order axiomatisation of the blocks world. such an axiomatisation is begun in the lpl book. we have (together with students) developed a much more complete first-order axiomatisation of the blocks world in casl.1 then proofs can be conducted e.g. with the automated resolution prover spass [wbh+02], see fig. 3. a drawback is that the output format of resolution proofs is still rather cryptic, since the problem is first translated to clause form. a translation from resolution proofs to natural deduction (using tools like tramp [mei00] or metis [mqp06]) could help here in the future, but one should be careful not to provide an automatic tool that completely discourages students to build their own natural deduction proofs. 2 structured specification while research in algebraic specification started with the application of methods from universal algebra and equational logic to the specification of abstract data types, later the algebraic nature was found more in the powerful constructs that are used to build larger specifications from smaller ones in a modular way. one such construct is the restriction to so-called initial and free models, a quite central but complex notion in the area of algebraic specification. while teaching this notion, i developed the idea to use propositional logic (instead of equational or first-order logic) to illustrate constructs for structuring specification. the advantage is that the logic is so simple that one can really concentrate on the structuring. moreover, it is possible to display individual models: they are just rows in a truth table. using this approach, the following subsections explain logical consequence, conservative extensions, and initial/free specifications. the development will be a bit more technical than above, and also will rely on mathematical notation. however, it will be intensively illustrated with results from hets. 1we have not published this axiomatisation, since it would enable students to cheat when solving the exercises in the book. however, the axiomatisation can be mailed to instructors on request. festschrift h.-j. kreowski 6 / 19 eceasst 2.1 logical consequence logical consequence is the central notion of logic (and is also important for algebraic specification): what follows from what? as indicated above, logical consequence is a notion that is difficult to grasp for many students. hence, with hets, we provide an easy truth table approach for illustrating this notion. definition 1 (signature) a propositional signature σ is a set (of propositional symbols, or variables). definition 2 (sentence) given a propositional signature σ, a propositional sentence over σ is one produced by the following grammar φ ::= p |⊥ |> |¬φ | φ ∧φ | φ ∨φ | φ → φ | φ ↔ φ with p ∈ σ. sen(σ) is the set of all σ-sentences definition 3 (model) given a propositional signature σ, a σ-model (or σ-valuation) is a function in σ →{t, f}. mod(σ) is the set of all σ-models. a σ-model m can be extended to m# : sen(σ) →{t, f} using truth tables. definition 4 φ holds in a σ-model m (or m satisfies φ ), written m |=σ φ iff m#(φ ) = t definition 5 (logical consequence) given γ ⊆ sen(σ) and φ ∈ sen(σ), φ is a logical consequence of γ (written as γ |= φ ), if for all m ∈ mod(σ) m |= γ implies m |= φ . example 1 an argument in natural language is tested for validity by translating it into propositional logic. john plays tennis, if it’s a sunny weekend day. if john plays tennis, then mary goes shopping. it is saturday. it is sunny. mary goes shopping sunny ∧ weekend → tennis tennis → shopping saturday sunny saturday → weekend shopping the set of premises has the sentence shopping as a logical consequence note that the formalisation contains an axiom saturday → weekend not present in the informal version. this axiom represents implicit background knowledge. the hets input syntax for this example is shown in listing 1. note that logical implication → is input as =>, conjunction ∧ as /\ etc. moreover, each formula is preceded by a dot, and formulas can be labelled with 7 / 19 volume 26 (2010) on teaching logic and algebraic specification %(label)%. the notation %implied marks a formula to be a theorem (that has to be proved to follow from the axioms); all other formulas are axioms.  logic propositional   spec weekend =  props tennis, shop, sunny, sat, we  . sunny /\ we => tennis %(swt)%  . tennis => shop %(tsh)%  . sat %(sat)%  . sat => we %(satw)%  . sunny %(sun)%  . shop %(shop)% %implied  end � listing 1: a simple logical consequence with hets, we can now construct the following truth table as shown in listing 2. the truth table is divided into three parts, using ||. the first part consists of the signature: all propositional letters are listed. below the signature, you find all possible models, one per row. the second part consists of the theory (the axioms, also playing the role of premises of the argument): for each axiom, its truth value is listed. only rows containing t for every axiom are models of the theory (indicated by an m). finally, the third part contains the proof goal, or conclusion of the argument. the conclusion needs to be true for each row that is a model. a simple non-example of a logical consequence (actually, we omitted the fact that saturday is a weekend day) is shown in listing 3. 2.2 conservative extensions a theory is satisfiable if it has a model.1 satisfiability of theories is quite important for an axiomatic or loose approach to specification: it is easy to introduce unintentional inconsistencies, and an inconsistent (unsatisfiable) specification cannot be realised, hence it does not successfully model an aspect of reality.2 satisfiability of large theories is hard to show. actually, there are large first-order theories like the sumo ontology for which satisfiability is an open question — indeed there is a prize set up for proving consistency of sumo [psst08]. a modular way to satisfiability is opened up by conservative extensions: in a sense, these transport satisfiability. to illustrate the concept, consider the specification in listing 6. indeed, to formally underpin this, we introduce some notions that will be central for structured specification: definition 6 given two signatures σ1, σ2 a signature morphism is a function σ : σ1 → σ2 (note that signatures here are sets). sentences can be translated along signature morphisms: 1in some logics like equational logic, each theory is trivially satisfiable. in these cases, satisfiability should be replaced with satisfiability by a non-trivial model, where the latter is a model that falsifies at least one sentence. 2this is different for paraconsistent logics, which however will not be considered here. festschrift h.-j. kreowski 8 / 19 eceasst  legend:  m = model of the premises  + = ok, model fulfils conclusion  = not ok, counterexample for logical consequence  o = ok, premises are not fulfilled, hence conclusion is irrelevant   -----------signature -------------------premises --------conclusion  || sat | shop | sunny | tennis | we || swt | tsh | sat | satw | sun || shop  ===++=====+======+=======+========+====++=====+=====+=====+======+=====++=====  o || f | f | f | f | f || t | t | f | t | f || f  o || f | f | f | f | t || t | t | f | t | f || f  o || f | f | f | t | f || t | f | f | t | f || f  o || f | f | f | t | t || t | f | f | t | f || f  o || f | f | t | f | f || t | t | f | t | t || f  o || f | f | t | f | t || f | t | f | t | t || f  o || f | f | t | t | f || t | f | f | t | t || f  o || f | f | t | t | t || t | f | f | t | t || f  o || f | t | f | f | f || t | t | f | t | f || t  o || f | t | f | f | t || t | t | f | t | f || t  o || f | t | f | t | f || t | t | f | t | f || t  o || f | t | f | t | t || t | t | f | t | f || t  o || f | t | t | f | f || t | t | f | t | t || t  o || f | t | t | f | t || f | t | f | t | t || t  o || f | t | t | t | f || t | t | f | t | t || t  o || f | t | t | t | t || t | t | f | t | t || t  o || t | f | f | f | f || t | t | t | f | f || f  o || t | f | f | f | t || t | t | t | t | f || f  o || t | f | f | t | f || t | f | t | f | f || f  o || t | f | f | t | t || t | f | t | t | f || f  o || t | f | t | f | f || t | t | t | f | t || f  o || t | f | t | f | t || f | t | t | t | t || f  o || t | f | t | t | f || t | f | t | f | t || f  o || t | f | t | t | t || t | f | t | t | t || f  o || t | t | f | f | f || t | t | t | f | f || t  o || t | t | f | f | t || t | t | t | t | f || t  o || t | t | f | t | f || t | t | t | f | f || t  o || t | t | f | t | t || t | t | t | t | f || t  o || t | t | t | f | f || t | t | t | f | t || t  o || t | t | t | f | t || f | t | t | t | t || t  o || t | t | t | t | f || t | t | t | f | t || t  m+ || t | t | t | t | t || t | t | t | t | t || t � listing 2: truth table for the logical consequence from listing 1  spec weekend2 =  props tennis, shop, sunny, sat, we  . sunny /\ we => tennis %(swt)%  . tennis => shop %(tsh)%  . sat %(sat)%  . sunny %(sun)%  . shop %(shop)% %implied  end � listing 3: example of a non-consequence 9 / 19 volume 26 (2010) on teaching logic and algebraic specification  legend:  m = model of the premises  + = ok, model fulfils conclusion  = not ok, counterexample for logical consequence  o = ok, premises are not fulfilled, hence conclusion is irrelevant   -----------signature ---------------premises -----conclusion  || sat | shop | sunny | tennis | we || swt | tsh | sat | sun || shop  ===++=====+======+=======+========+====++=====+=====+=====+=====++=====  o || f | f | f | f | f || t | t | f | f || f  o || f | f | f | f | t || t | t | f | f || f  o || f | f | f | t | f || t | f | f | f || f  o || f | f | f | t | t || t | f | f | f || f  o || f | f | t | f | f || t | t | f | t || f  o || f | f | t | f | t || f | t | f | t || f  o || f | f | t | t | f || t | f | f | t || f  o || f | f | t | t | t || t | f | f | t || f  o || f | t | f | f | f || t | t | f | f || t  o || f | t | f | f | t || t | t | f | f || t  o || f | t | f | t | f || t | t | f | f || t  o || f | t | f | t | t || t | t | f | f || t  o || f | t | t | f | f || t | t | f | t || t  o || f | t | t | f | t || f | t | f | t || t  o || f | t | t | t | f || t | t | f | t || t  o || f | t | t | t | t || t | t | f | t || t  o || t | f | f | f | f || t | t | t | f || f  o || t | f | f | f | t || t | t | t | f || f  o || t | f | f | t | f || t | f | t | f || f  o || t | f | f | t | t || t | f | t | f || f  m|| t | f | t | f | f || t | t | t | t || f  o || t | f | t | f | t || f | t | t | t || f  o || t | f | t | t | f || t | f | t | t || f  o || t | f | t | t | t || t | f | t | t || f  o || t | t | f | f | f || t | t | t | f || t  o || t | t | f | f | t || t | t | t | f || t  o || t | t | f | t | f || t | t | t | f || t  o || t | t | f | t | t || t | t | t | f || t  m+ || t | t | t | f | f || t | t | t | t || t  o || t | t | t | f | t || f | t | t | t || t  m+ || t | t | t | t | f || t | t | t | t || t  m+ || t | t | t | t | t || t | t | t | t || t � listing 4: truth table for the non-consequence from listing 3  spec sp =  σ1  γ1  then  σ∆  γ∆  end �  spec animals =  props bird, penguin  . penguin => bird  then  prop can_fly  . penguin => not can_fly  end � listing 5: theory extensions in casl. festschrift h.-j. kreowski 10 / 19 eceasst  logic propositional   spec animal =  props bird, penguin, living  . penguin => bird %(pb)%  . bird => living %(bl)%  then %cons  prop animal  . bird => animal %(ba)%  . animal => living %(al)%  end �   spec penguin =  props bird, penguin  . penguin => bird %(pb)%  then  prop can_fly  . bird => can_fly %(bc)%  . penguin => not can_fly %(pnc)%  end � listing 6: example of a conservative and a non-conservative extension in casl definition 7 a signature morphism σ : σ1 → σ2 induces a sentence translation σ : sen(σ1) → sen(σ2), defined inductively by • σ (⊥) = ⊥ • σ (>) = > • σ (φ1 ∧φ2) = σ (φ1)∧σ (φ2) • etc. models are translated against signature morphisms. the intuition is that the translated model m|σ works as follows: interpret a symbol by first translating it along the signature morphism σ and then look up the interpretation in the original model m. definition 8 a signature morphism σ : σ1 → σ2 induces a model reduction |σ : mod(σ2) → mod(σ1). given m ∈mod(σ2) i.e. m : σ→{t, f}, then m|σ∈mod(σ1) is defined as m|σ (φ ) := m(σ (φ )) i.e. m|σ = m◦σ . dually, m is called a σ -expansion of m|σ . sentence and model translation interact well with each other: theorem 1 (satisfaction condition) given a signature morphism σ : σ1 → σ2, m2 ∈ mod(σ2) and φ1 ∈ sen(σ1), then: m2 |=σ2 σ (φ1) iff m2|σ|=σ1 φ1 (“truth is invariant under change of notation.“) 11 / 19 volume 26 (2010) on teaching logic and algebraic specification this condition is the central ingredient of the notion of institution [gb92]. in a special course, i first introduce several examples of the satisfaction condition in order to motivate this abstract notion. definition 9 a theory morphism (σ1, γ1)→(σ2, γ2) is a signature morphism σ : σ1 → σ2 such that for m2 ∈ mod(σ2, γ2) we have m2|σ∈ mod(σ1, γ1) extensions (written in casl with the keyword then; cf. listing 5) always lead to a theory morphism (by definition). the semantics of the casl specification is the theory morphism σ : (σ1, γ1) → (σ2, γ2), where σ2 = σ1 ∪σ∆ and γ2 = γ1 ∪γ∆, such that σ : σ1 → σ2 is the inclusion. we are now ready to define conservative extensions: definition 10 a theory morphism σ : t1 → t2 is model-theoretically-conservative, if any m1 ∈ mod(t1) has a σ -expansion to a t2-model. we can now evaluate which of the extensions shown in listing 6 are conservative. actually, the first extension is conservative. the truth table output by hets is shown in listing 7. on the left hand side (columns bird, living and penguin), we see valuations of the smaller signature, and the corresponding evaluations of the axioms pb and bl. models of the smaller theory are marked with an m in the leftmost column. on the right hand side in column animal, possible expansions to the larger signature are listed, together with the evaluation of the axioms ba and al. models of the larger theory are marked with an m in the column right to the middle. altogether, we can see that each model of the smaller theory has at least one expansion to the larger theory. by contrast, the second extension is not conservative: the last model fails to have an expansion, see listing 8. the central theorem that allows us to transport satisfiability is the following: theorem 2 if t1 σ1−→ t2 σ2−→ . . . σn−1−−→ tn are model-theoretically conservative, and t1 is satisfiable, then tn is satisfiable. 2.3 initial and free specifications freeness and cofreeness constraints are a powerful mechanism at the level of structured specifications. they work for any logic. propositional logic is a good starting point for learning about freeness and cofreeness, since things are much less complicated here when compared with other logics. consider the following two somewhat circular statements: harry: john tells the truth. john: if mary is right, then harry does not tell the truth. let us formalise these statements and look at the logical consequences. we introduce three propositions telling us whether harry, john, resp. mary tell the truth. festschrift h.-j. kreowski 12 / 19 eceasst  legend:  m = model of the axioms  + = ok, has expansion  = not ok, has no expansion, hence conservativity fails  o = ok, not a model of the axioms, hence no expansion needed   ---small signature ---axioms --large ---axioms --- signature  || bird | living | penguin || pb | bl || || animal || ba | al  ===++======+========+=========++======+======++===++========++========+=======  m+ || f | f | f || t | t || m || f || t | t  || | | || | || || t || t | f  ---++------+--------+---------++------+------++---++--------++--------+------ o || f | f | t || f | t || || || |  ---++------+--------+---------++------+------++---++--------++--------+------ m+ || f | t | f || t | t || m || f || t | t  || | | || | || m || t || t | t  ---++------+--------+---------++------+------++---++--------++--------+------ o || f | t | t || f | t || || || |  ---++------+--------+---------++------+------++---++--------++--------+------ o || t | f | f || t | f || || || |  ---++------+--------+---------++------+------++---++--------++--------+------ o || t | f | t || t | f || || || |  ---++------+--------+---------++------+------++---++--------++--------+------ m+ || t | t | f || t | t || || f || f | t  || | | || | || m || t || t | t  ---++------+--------+---------++------+------++---++--------++--------+------ m+ || t | t | t || t | t || || f || f | t  || | | || | || m || t || t | t � listing 7: truth table for a conservative extension from listing 6  legend:  m = model of the axioms  + = ok, has expansion  = not ok, has no expansion, hence conservativity fails  o = ok, not a model of the axioms, hence no expansion needed   small signature axioms large --axioms -- signature  || bird | penguin || pb || || can_fly || bc | pnc  ===++======+=========++======++===++=========++========+=====  m+ || f | f || t || m || f || t | t  || | || || m || t || t | t  ---++------+---------++------++---++---------++--------+---- o || f | t || f || || || |  ---++------+---------++------++---++---------++--------+---- m+ || t | f || t || || f || f | t  || | || || m || t || t | t  ---++------+---------++------++---++---------++--------+---- m|| t | t || t || || f || f | t  || | || || || t || t | f � listing 8: truth table for a non-conservative extension from listing 6 13 / 19 volume 26 (2010) on teaching logic and algebraic specification  spec liar0 =  prop mary  props harry, john  . harry => john %(whenjohn)%  . john => (mary => not harry) %(whenharry)%  then %implies  . harry %(harry)%  . john %(john)%  . mary %(mary)%  . not harry %(notharry)%  . not john %(notjohn)%  . not mary %(notmary)%  end � listing 9: a circular set of statements actually, when calling hets with the truth table prover, the first goal cannot be proved, see listing 10.  legend:  m = model of the premises  + = ok, model fulfils conclusion  = not ok, counterexample for logical consequence  o = ok, premises are not fulfilled, hence conclusion is irrelevant   ----signature --------premises -----conclusion  || harry | john | mary || whenjohn | whenharry || harry  ===++=======+======+======++==========+===========++======  m|| f | f | f || t | t || f  m|| f | f | t || t | t || f  m|| f | t | f || t | t || f  m|| f | t | t || t | t || f  o || t | f | f || f | t || t  o || t | f | t || f | t || t  m+ || t | t | f || t | t || t  o || t | t | t || t | f || t � listing 10: truth table for the circular statements from listing 9 the other goals cannot be proved either. so this theory cannot decide the truth of the propositional letters, and it leaves open whether harry, john or mary tell the truth or lie, and indeed, we have five possible cases (indicated by the five models, i.e. those rows marked with m in listing 10). a semantics that admits many possible interpretations and only constrains them by logical formulas is called open world semantics. by contrast, a closed world semantics assumes some default, e.g. any propositional letter whose truth value cannot be determined is assumed to be false. indeed, free or initial semantics imposes this kind of constraints. as a prerequisite, we need to define a partial order on propositional models: definition 11 given a propositional signature σ and two σ-models m1 and m2, then m1 ≤ m2 if m1(p) = t implies m2(p) = t for all p ∈ σ. festschrift h.-j. kreowski 14 / 19 eceasst then, a free (or initial) specification, written free{sp}, selects the least model of a specification: mod(free{sp}) = {m ∈ mod(sp)|m least model in mod(sp)} note that a least model need not exist; in this case, the model class of free{sp} is empty, hence the free specification inconsistent. coming back to our example, have a look at listing 11. with the hets truth table prover, we now get the truth table in listing 12. that is, harry, john and mary all are lying! actually, we are not forced by the specification to think that they tell the truth, so by minimality of the initial model, the propositional letters are all assigned false.  spec liar1 =  free {  prop mary  props harry, john  . harry => john %(whenjohn)%  . john => (mary => not harry) %(whenharry)%  }  then %implies  . not harry %(notharry)%  . not john %(notjohn)%  . not mary %(notmary)%  end � listing 11: closed world assumption, specified as a free extension  ----signature -----------premises -------conclusion  || harry | john | mary || notharry | notjohn | free || notmary  ===++=======+======+======++==========+=========+======++========  m+ || f | f | f || t | t | t || t  o || f | f | t || t | t | f || f  o || f | t | f || t | f | f || t  o || f | t | t || t | f | f || f  o || t | f | f || f | t | f || t  o || t | f | t || f | t | f || f  o || t | t | f || f | f | f || t  o || t | t | t || f | f | f || f � listing 12: truth table for the specification of listing 11 of course, the assumption that propositional letters are false by default is somewhat arbitrary. we could have taken the opposite assumption. indeed, this exactly is what final (or cofree) specifications do, see listing 13. however, no greatest model exists in this case, hence the cofree specification is inconsistent, as shown in listing 14. mod(cofree{sp}) = {m ∈ mod(sp)|m greatest model in mod(sp)} we can also mix the open and closed world assumptions. assume that we want to be unspecific about mary, but use closed world assumption for harry and john, see listing 15. the semantics is as follows: 15 / 19 volume 26 (2010) on teaching logic and algebraic specification  spec liar2 =  cofree {  prop mary  props harry, john  . harry => john %(whenjohn)%  . john => (mary => not harry) %(whenharry)%  }  then %implies  . false %(false)%  end � listing 13: closed world assumption, specified as a cofree extension  ----signature -------------premises --------conclusion  || harry | john | mary || whenjohn | whenharry | cofree || false  ===++=======+======+======++==========+===========+========++======  o || f | f | f || t | t | f || f  o || f | f | t || t | t | f || f  o || f | t | f || t | t | f || f  o || f | t | t || t | t | f || f  o || t | f | f || f | t | f || f  o || t | f | t || f | t | f || f  o || t | t | f || t | t | f || f  o || t | t | t || t | f | f || f � listing 14: truth table for the specification of listing 13  spec liar3 =  prop mary  then  free {  props harry, john  . harry => john %(whenjohn)%  . john => (mary => not harry) %(whenharry)%  }  then %implies  . not harry %(notharry)%  . not john %(notjohn)%  end � listing 15: mixed open world and closed world semantics using free festschrift h.-j. kreowski 16 / 19 eceasst mod(sp1 then free{sp2}) = {m ∈ mod(sp1 then sp2) | m is the least model in {m′ ∈ mod(sp1 then sp2) | m|σ = m′|σ}} and as a result, we obtain that both harry and john lie (independently of what marry does!), see listing 16.  ----signature -------------premises -------conclusion  || harry | john | mary || whenjohn | whenharry | free || notharry  ===++=======+======+======++==========+===========+======++=========  m+ || f | f | f || t | t | t || t  m+ || f | f | t || t | t | t || t  o || f | t | f || t | t | f || t  o || f | t | t || t | t | f || t  o || t | f | f || f | t | f || f  o || t | f | t || f | t | f || f  o || t | t | f || t | t | f || f  o || t | t | t || t | f | f || f � listing 16: truth table for the specification of listing 15  spec liar4 =  prop mary  then  cofree {  props harry, john  . harry => john %(whenjohn)%  . john => (mary => not harry) %(whenharry)%  }  then %implies  . harry \/ mary %(harrymary)%  . john %(john)%  end � listing 17: mixed open world and closed world semantics using cofree the dual concept is cofreeness with mixed open and closed world semantics, see listing 17. also the semantics is obtained by dualising: mod(sp1 then cofree{sp2}) = {m ∈ mod(sp1 then sp2) | m is the greatest model in {m′ ∈ mod(sp1 then sp2) | m|σ = m′|σ}} the result in the example is that john tells the truth, and at least either of harry and mary as well, see listing 18. 3 conclusion the overall picture is as follows: typically, i start with a course on first-order logic as described in section 1, followed by a more special course on structuring and institutions, following section 2. 17 / 19 volume 26 (2010) on teaching logic and algebraic specification  ----signature ------------premises ----------conclusion  || harry | john | mary || whenjohn | whenharry | cofree || harrymary  ===++=======+======+======++==========+===========+========++==========  o || f | f | f || t | t | f || f  o || f | f | t || t | t | f || t  o || f | t | f || t | t | f || f  m+ || f | t | t || t | t | t || t  o || t | f | f || f | t | f || t  o || t | f | t || f | t | f || t  m+ || t | t | f || t | t | t || t  o || t | t | t || t | f | f || t � listing 18: truth table for the specification of listing 17 the second course starts with propositional logic, which keeps the examples simple, and then proceeds to description logics (used for ontologies and semantic web) and finally again to firstorder logic. teaching algebraic specification and logic can really be fun, and there is much room for developing better ideas and tools supporting this. feedback and improvements are welcome! acknowledgments this work has been supported by the german federal ministry of education and research (project 01 iw 07002 formalsafe). bibliography [akk99] e. astesiano, h.-j. kreowski, b. krieg-brückner. algebraic foundations of systems specification. springer, 1999. [be02] j. barwise, j. etchemendy. language, proof and logic. csli publications, 2002. [bm04] m. bidoit, p. d. mosses. casl user manual. lecture notes in computer science (ifip series) 2900. springer, 2004. with chapters by t. mossakowski, d. sannella, and a. tarlecki. http://www.cofi.info/index.php/casl user manual [cof04] cofi (the common framework initiative). casl reference manual. lecture notes in computer science (ifip series) 2960. springer, 2004. http://www.cofi.info/index.php/casl reference manual [gb92] j. goguen, r. burstall. institutions: abstract model theory for specification and programming. journal of the acm 39(1):95–146, 1992. [mei00] a. meier. system description: tramp: transformation of machine-found proofs into nd-proofs at the assertion level. in mcallester (ed.), automated deduction cade-17, 17th international conference on automated deduction, pittsburgh, pa, usa, june 17-20, 2000, proceedings. lecture notes in computer science 1831, pp. 460–464. springer, 2000. festschrift h.-j. kreowski 18 / 19 http://www.cofi.info/index.php/casl_user_manual http://www.cofi.info/index.php/casl_reference_manual eceasst [mml07] t. mossakowski, c. maeder, k. lüttich. the heterogeneous tool set. in grumberg and huth (eds.), tacas 2007. lecture notes in computer science 4424, pp. 519– 522. springer, 2007. [mos05] t. mossakowski. heterogeneous specification and the heterogeneous tool set. 2005. habilitation thesis, university of bremen. [mqp06] j. meng, c. quigley, l. c. paulson. automation for interactive proof: first prototype. information and computation 204(10):1575–1596, 2006. http://www.sciencedirect.com/science/article/b6wgk-4k9c6j3-1/2/ e4e5661335eef1bb58ed32a67a7f2427 [psst08] a. pease, g. sutcliffe, n. siegel, s. trac. the annual sumo reasoning prizes at casc. in konev et al. (eds.), proceedings of the first international workshop on practical aspects of automated reasoning, sydney, australia, august 10-11, 2008. ceur workshop proceedings 373. ceur-ws.org, 2008. http://ceur-ws.org/vol-373/paper-05.pdf [wbh+02] c. weidenbach, u. brahm, t. hillenbrand, e. keen, c. theobalt, d. topic. spass version 2.0. in voronkov (ed.), automated deduction – cade-18. lecture notes in computer science 2392, pp. 275–279. springer, 2002. 19 / 19 volume 26 (2010) http://www.sciencedirect.com/science/article/b6wgk-4k9c6j3-1/2/e4e5661335eef1bb58ed32a67a7f2427 http://www.sciencedirect.com/science/article/b6wgk-4k9c6j3-1/2/e4e5661335eef1bb58ed32a67a7f2427 http://ceur-ws.org/vol-373/paper-05.pdf first-order logic language, proof and logic hets and state-of-the-art provers structured specification logical consequence conservative extensions initial and free specifications conclusion electronic communications of the easst volume 43 (2011) proceedings of the 4th international discotec workshop on context-aware adaption mechanisms for pervasive and ubiquitous services (campus 2011) context awareness: challenges and opportunities in modern smartphone use nearchos paspallis, gabriel panis 6 pages guest editors: gabriel hermosillo, russell nzekwa, michael wagner managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 eceasst context awareness: challenges and opportunities in modern smartphone use nearchos paspallis1, gabriel panis2 department of computer science, university of cyprus1 cyta, nicosia, cyprus2 abstract: commonly, improvement to smart-phone technology focuses at advancing the connectivity of human users. this results to better and richer information access but, undeniably, it also increases the accessibility of the users themselves, something that could arguably have negative side-effects. this position paper discusses the potential of context awareness in modern smart-phones by presenting the challenges and opportunities in modern smartphone use. in particular, we examine the implications of the advanced network capabilities-and accompanying servicesof modern smart-phones and list what we argue to be their main drawbacks. we then present our position which summarizes what we expect the role of contextawareness to be in modern smart-phone applications. keywords: context, context-awareness, challenges, opportunities, smartphones 1 introduction in recent years, we have experienced the rapid growth and evolution of the mobile phone market. with more than 4.1 billion subscribers-and with the global population penetration exceeding 61%-as of 2008, mobile phones have been named the most prolific technology ever [rub08]. meanwhile, an increasing fraction of the mobile phones are branded as smart-phones, vaguely meaning that they feature sophisticated (third-party) applications. evidently, the industry took note of the trend and they have introduced a number of highly capable platforms, most notably the iphone, blackberry and android-while the competition is only getting more intense with alliances such as the one by nokia and microsoft which was recently announced [but11] [wan10]. packing the functionality of devices such as the personal computer, personal digital assistant, digital camera, music player, navigation system, and-of course-the mobile phone, it is no wonder that smart-phones are considered one of the top technologies of the decade [rom11]. especially since the formation and development of application ecosystems [ms04], smart-phones have endeavoured at becoming an indispensable part of our everyday lives, both in terms of lifestyle and utility. however, it can be argued that while the smart-phone has tremendously increased the potential of its users for communication and interaction, it has also introduced some-arguably negative-side-effects. in this position paper we argue that context aware applications can be the key to overcoming them. the rest of this paper is organized as follows: section 2 discusses the evolution of context awareness as well as the capability of modern smart phones for context aware behaviour. section 3 discusses a few critical challenges for the future of mobile phone use and argues how these open up opportunities for developing novel context aware applications. the paper closes with conclusions in section 4. 1 / 6 volume 43 (2011) context awareness: challenges and opportunities 2 context awareness and smart-phones context-aware computing has been actively studied since at least mid-nineties [saw94], shortly after weiser introduced the concept of ubiquitous computing [wei91]. initially, research was concentrated on stand-alone context-aware applications, mainly location-aware ones (e.g. tour guides and active badges [lkaa96, pas97]). however, as the interest for context awareness picked up, the research naturally shifted towards building frameworks providing support for general context-awareness, such as the context toolkit, carisma and music [das01, cem03, prb+08]. however, only recently have powerful smart-phones been introduced, featuring many sensors and capabilities, paving the way for sophisticated context-aware applications. although context awareness has been studied for nearly two decades now, no widespread adoption of context-aware applications can be claimed yet. while a few commercial applications feature context-aware behaviour already, these are primarily limited to location awareness, and their context aware behaviour is often a (not critical) subset of the application logic. it can be argued that the killer-app of context-awareness has not been invented yet. 2.1 sensing context sensors are common in most modern smart phones now. these include both hardware-based and software-based sensors. the most typical hardware sensors include: gps sensor (used for follow-me applications, positioning, navigation, etc); wifi/gsm sensor (signal strength and base station id-can be used to infer location); accelerometer sensor (used to infer user status-walking, running, driving, etc); orientation sensor (ui modality-adjusting the way the ui is presented to the user); compass sensor (direction-allowing for sophisticated navigation applications); light sensor (ambient lighting conditions-e.g. in tunnel while driving); camera (tags-e.g., infer location with qr codes, or bridging the physical and the virtual worlds, a major application of ubiquitous computing); nfc (also used to bridge the physical with the virtual worlds). one level above the hardware sensors we find software apis that expose context-related information or functionality that can be exploited by mobile applications. the context information is usually derived from the underlying hardware sensors. for example google latitude and facebook check-in offer apis to access information related to the current location of the user and people in their social network, the location history, places and things of interest and user status. the calendar is another purely software based source of context. specifically, an application may derive from a user’s calendar information regarding the user’s availability and the type of engagement (work or private). 2.2 context aware applications research-oriented context-aware applications appeared as early as in mid nineties. the cyberguide [lkaa96] and the stick-e framework [pas97], for instance, were intelligent tour guides using location to automate their operation. another common showcase of context awareness was with follow-me apps, such as the intercom project [kon+00]. one of the most elaborate applications of the time was the conference assistant, which realized a scenario with an automated service meant to support attendees at an academic conference [das01]. proc. campus 2011 2 / 6 eceasst a more recent application from parc-the founders of ubiquitous computing-is the magitti application. the authors of [ba08] argue that applications will be increasingly intent-aware, anticipating the users’ intentions. therefore, they argue that ”the system will be aware of four levels of system awareness: basic context awareness, behavior awareness, activity awareness, and intend awareness”. this is also supported by wright, who argues that applications like the magitti will become more common [wri09]. finally, an extensive demo was organized by the music consortium to illustrate the viability of context aware applications, particularly as assistants to passengers and personnel of the paris metro (an extensive coverage was also documented by euronews1). this demo included specialized applications such as metro navigators and assistants for persons with motor disabilities, as well as social applications such as instantsocial which facilitates rapid interaction with nearby passengers [fhs08]. commercial applications that are currently exploiting context information fall almost entirely under the location based services category. it is becoming increasingly evident that a user’s location and location history is considered a great commercial asset that can be exploited in a number of ways. hence there is a growing interest from both application developers and network providers to build into their applications the acquisition and exploitation of that information. these applications exploit the location information to enhance the social networking experience and/or improve the relevance of information provided to the user. among the most popular applications exploiting location information are the google latitude, facebook check-in, twitter, foursquare and gowalla which provide features such as tracking the location of the user and their friends, posting and searching for user experiences at specific businesses, receiving location targeted promotional offers and geo-searching for specific businesses/points of interests in an area. 3 challenges and opportunities in modern smart phone use while many research and commercial applications have been developed featuring context aware behaviour, it can be argued that the killer app of context awareness has not been invented yet. by definition, a killer app is one that is so successful that it paves the way for a new family of applications (in our case, context-aware applications). naturally, it is not only hard to produce such applications, but it is also hard to make a prediction of. we argue that while most context aware applications aim at utilizing the additional information for providing more and richer information to the users, context could also be used for exactly the opposite goal: trimming unnecessary-or lower priority-information. this is further analyzed in the following two subsections. 3.1 challenges in modern smart phone use undeniably, the smart phone has changed the way hundreds of millions of people live and organize their lives by. while the smart-phone revolution has tremendously increased the possibility for communication and interaction, it has also contributed to two negative side-effects: information overload: as people are constantly moving towards a faster and more hectic lifestyle, they are continuously asked to deal with an increasing amount of information. this information includes voice calls, text messages, email, as well as other data generated by browsing web1 http://www.euronews.net/2010/06/16/music-to-you-mobile-s-ears 3 / 6 volume 43 (2011) context awareness: challenges and opportunities sites (such as news, sports and social network updates). at the same time, while mobile phones have increased the possibilities for communication, they have also inadvertently limited people’s privacy and isolation. the physical boundaries of distance and inaccessibility have mostly disappeared, exposing us to increased and often undesired (or untimely) communication. frequent interruptions: modern office and home lifestyle experience has shown that people tend to interact with a large number of information sources, often after they are asynchronously interrupted (such as by phone calls, text messages, twits, facebook status updates, etc). while it has long been understood that you are less productive when you are constantly switching your attention, scholars have found something even stronger: pioneering researchers from the stanford’s communication between humans and interactive media (chime) lab have found that the impact of electronic multitasking goes beyond the momentary sense of distraction, as it can also create permanent changes to the way the brain functions [onw09]. these observations are not new. as early as almost a decade ago, sousa et al argued that ”the most precious resource in a computer system is no longer its processor, memory, etc, but rather a resource that is not subject to moore’s law: user attention” [sg02]. while this still holds true, only now is smart phone becoming so powerful and central to our life that we can actually respond to it. our position is that the challenges imposed by the use of smart phones in modern life are so important that they actually provide a significant opportunity for novel context aware solutions. naturally, information overload-especially when involving asynchronous communication such as email, text messages and phone calls-cannot be filtered manually by users. rather, it is expected that smart phones-and their software-will be able to make such filtering for the users themselves. furthermore, frequent interruptions of the users could easily distract them and lower their productivity. today, the smart phone is often the main gateway of information for many people. this makes it the ideal platform for deploying software that manages communications, filtering them by priority, and perhaps grouping them in meaningful batches which are delegated to the users only periodically, allowing them sufficient distraction-free intervals. 3.2 opportunities for context awareness in smartphones based on the previous observations, we attempt to define the killer app of context awareness. the key to this application is the use of contextual information to intelligently manage the communications of the user. it aims at enhancing the communication experience of the user through the exploitation of sensed context information, while preventing the user from becoming overloaded. the behaviour of the application is controlled by a number of user-defined rules that are applied using the information collected at real time by sensors such as the gps receiver, calendar, facebook status etc. from a functional perspective, the main opportunities that arise from the exploitation of context information in managing the users’ communications are: minimize the amount of information communicated to the user: this extends the filtering concept that is commonly found in email applications to other forms of communications such as text messaging, chatting and voice communication. for instance, applications can be configured so that e-banking sms messages are filtered in order to ignore informational messages (e.g., daily updates on your account balance), while allowing alert messages (e.g., about suspicious credit card activity). this is enabled by using context data such as calendar status (free, in a meeting, out of office) to activate the filtering of incoming communication. proc. campus 2011 4 / 6 eceasst defer communication: for example, many smartphone users are tempted to casually read their work email even after normal business hours, resulting to them not being able to relax and rest. on the other hand, a busy professional does not want to be distracted during work hours by noncritical personal communication. context aware apps can allow for clever filtering of the user’s communication using such context information such as location, time-of-day, holiday schedule, etc. for instance, email and sms messages arriving after business hours from co-workers are hidden until the next business day, or until the user’s location changes back to work (i.e., meaning that the user is back to work and ready to resume office work). this can also be applied to voice calls being directed to a voicemail server. in this way, a virtual, protective boundary is formed between the users’ personal and professional lives. smart scheduling: one of the most important opportunities is the ability of smartphones to schedule the users’ daily activities in a way that minimizes the number of interruptions during the day and makes the information available to the user at the right time. for instance, instead of notifying the user of new status updates (e.g., from facebook) as they happen, those are either cumulatively reported at the end of the day, or they are deferred until an actual communication occurs. for example, when joe smith calls, his latest facebook status can also be shown on the smart-phone display, thus allowing the user to be intelligently updated of any useful information concerning joe, while also minimizing the need (or urge) to periodically check friends’ status. we believe that these novel features are so important that they will trigger a new family of context-aware apps, aiming at addressing the users’ need for more intelligent communication. 4 conclusions this paper presents our position which can be summarized in two points: first, current smart phones are powerful enough and feature sufficient sensing capacity which makes them the ideal platform for deploying context aware applications. second, while most mobile phone applications aim at increasing the amount of information accessible by-and inevitable flowing towardsthe user, we argue that there is a great opportunity for applications that aim at controlling this flow by intelligently filtering and scheduling the information delivered to the users. while it is practically impossible to predict which will be the killer app of context awareness, we foresee this as the opportunity of context awareness becoming mainstream. bibliography [ba08] v. bellotti, et al. activity-based serendipitous recommendations with the magitti mobile leisure guide. 26th annual sigchi conference on human factors in computing systems, pp. 1157–1166, 2008. [but11] m. butler. android: changing the mobile landscape. ieee pervasive computing 10:4–7, 2011. [cem03] l. capra, w. emmerich, c. mascolo. carisma: context-aware reflective middleware system for mobile applications. ieee transactions on software engineering 29:929–945, 2003. 5 / 6 volume 43 (2011) context awareness: challenges and opportunities [das01] a. k. dey, g. d. abowd, d. salber. a conceptual framework and a toolkit for supporting the rapid prototyping of context-aware applications. human-computer interaction 16(2):97–166, 2001. [fhs08] l. fragas, s. hallsteinsen, u. sholtz. ’instantsocial’ implementing a distributed mobile multi-user application with adaptation middleware. 1st international discotec workshop on context-aware adaptation mechanisms for pervasive and ubiquitous services, 2008. [kon+00] c. d. kidd, t. o’connell, k. nagel, s. patil, g. d. abowd. building a better intercom: context-mediated communication within the home. 2000. [lkaa96] s. long, r. kooper, g. d. abowd, c. g. atkeson. rapid prototyping of mobile context-aware applications: the cyberguide case study. 2nd annual international conference on mobile computing and networking, pp. 97–107, 1996. [ms04] d. g. messerschmitt, c. szyperski. marketplace issues in software planning and design. ieee software, pp. 62–70, 2004. [onw09] e. ophir, c. nass, a. d. wagner. cognitive control in media multitaskers. proceedings of the national academy of sciences (pnas) 106(37):15583–15587, 2009. [pas97] j. pascoe. the stick-e note architecture: extending the interface beyond the user. 2nd international conference on intelligent user interfaces, pp. 261–264, 1997. [prb+08] n. paspallis, r. rouvoy, p. barone, g. a. papadopoulos, f. eliassen, a. mamelli. a pluggable and reconfigurable architecture for a context-aware enabling middleware system. 5331:553–570, 2008. [rom11] j. j. romero. smartphones: the pocketable pc. ieee spectrum 9, 2011. [rub08] a. rubin. the future of mobile. sept. 2008. http://googleblog.blogspot.com/2008/09/future-of-mobile.html [saw94] b. n. schilit, n. i. adams, r. want. context-aware computing applications. pp. 85–90, 1994. [sg02] j. sousa, d. garlan. aura: an architectural framework for user mobility in ubiquitous computing environments. 3rd ieee/ifip conference on software architecture: system design, development and maintenance, pp. 29–43, 2002. [wan10] r. want. iphone: smarter than the average phone. ieee pervasive computing 9:6– 9, 2010. [wei91] m. weiser. the computer for the 21st century. scientific american, 1991. [wri09] a. wright. get smart. communications of the acm 52(1):15–16, 2009. proc. campus 2011 6 / 6 design pattern modeling with constraint relaxation electronic communications of the easst volume 25 (2010) proceedings of the workshop visual formalisms for patterns at vl/hcc 2009 design pattern modeling with constraint relaxation tamás vajk, tamás mészáros and tihamér levendovszky 12 pages guest editors: paolo bottoni, esther guerra, juan de lara managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst design pattern modeling with constraint relaxation tamás vajk, tamás mészáros and tihamér levendovszky [tamas.vajk, mesztam, tihamer]@aut.bme.hu department of automation and applied informatics budapest university of technology and economics, budapest, hungary abstract: metamodeling is a widely applied technique in the field of graphical language engineering. environments supporting metamodeling aid rapid and flexible domain-specific modeling language (dsml) definition and utilization. in software engineering, design patterns are efficient solutions for recurring problems. with the proliferation of dsmls, there is a need for domain-specific design patterns to offer solutions to problems recurring in different domains. the aim of this paper is to illustrate a concept that integrates modeling patterns into a metamodeling environment. the introduced approach utilizes the modeling functionalities of the environment; a visual design pattern metamodel, a system architectural metamodel extended with textual constraints are introduced. furthermore, design patterns are validated against relaxed constraints defined in the metamodel to only allow the creation of patterns that can be extended to valid instance models. keywords: design pattern, dsml, vmts, ocl constraint, relaxation 1 introduction design patterns in software engineering describe a problem that recurs, and then describe the core of the solution to that problem, in a way that the solution can be used many times, without ever doing it the same way twice [ghjv94]. in general, patterns have four essential elements: a name for identification, a problem description, the solution and the consequences, meaning the achieved results and trade-offs. as an example, a pattern ensuring that a class only has one instance with a global point of access is named singleton pattern. the solution (in c++) is to create a protected constructor, a private member variable that stores the globally unique instance and a static query method that instantiates the instance if it has not been already done, and returns it. and finally, as an example benefit of the use of this pattern is that it can have strict control over how and when clients access the sole instance. together this four elements define a design pattern. graphical modeling languages have been applied in software engineering since the beginning of the field. one of the most successful techniques to define the rules of graphical modeling languages is metamodeling. domain-specific modeling [kt08] can be aided by design pattern [ghjv94] utilization. domain-specific design patterns are design patterns inserted into domainspecific instance models. in dsmls, not only design patterns can be developed, but model patterns for many other purposes as well. design patterns can be considered uml-like best practice structural patterns, while model patterns are general purpose submodels that can be reused several times. in this sense, design patterns are specialized model patterns. 1 / 12 volume 25 (2010) mailto:[tamas.vajk, mesztam, tihamer]@aut.bme.hu design pattern modeling with constraint relaxation design patterns aid rapid development only if the tool support is flexibly solved. defining and reusing patterns should be seamless, otherwise users would remodel the pattern instead. also, design-time validation should be available to support validated pattern development and insertion. a pattern is only valid, if it can be extended to an instance of the metamodel, this instance should satisfy all the hierarchical restrictions defined by the metamodel and none of the textual constraints should fail on it. we have developed tool support for domain-specific model patterns for our metamodeling and model transformation environment called visual modeling and transformation system (vmts). in our solution, the four essential elements of design patterns are integrated as follows: a name should be given for identification purposes, a pattern model is created as a solution and finally, problem statement and consequences can be explained in description fields. visual modeling and transformation system [vmt09] is a general purpose metamodeling environment supporting n-level metamodeling. n-level means in this context that the instance models can be used as metamodels: they can be used to define model hierarchies such as metaclass diagram class diagram object diagram. the maximum depth of these hierarchies is not limited; we can construct an n-level modeling chain. vmts uses a proprietary modeling space. models in vmts are represented as directed, attributed graphs. in our approach, edges are attributed as well. the structure of this paper is as follows. section 2 provides a brief overview of available modeling tools. section 3 describes the design pattern development process in vmts. afterwards section 4 details the hierarchical constraint relaxation in section 4.1 and the general ocl constraint handling in section 4.2. finally, we draw the conclusions and describe future research options in section 5. 2 related work there are several modeling and metamodeling frameworks that support domain-specific modeling. the generic modeling environment (gme) [lbm+01] is a highly configurable metamodeling tool supporting two layers: a metamodel, and a modeling layer. diagram editor generator (diagen) [min02] provides an efficient solution to create visual editors for dsls. diagen is not based on metamodeling techniques, it uses its own specification language for defining the structure of diagrams. eclipse [bbm03] is probably the most popular, highly extensible, open source modeling platform that supports metamodeling. to the best of our knowledge, besides vmts, only gme provides tool support for domainspecific design patterns to certain extent. however, there are several implementations and industrial applications that utilize patterns in uml environments. commercial applications, such as rational software architect [ibm09], have the functionality to define and apply patterns in a productive environment, but these tools only support uml as modeling language, thus domain-specific patterns and models cannot be created. the standardization of design patterns in uml diagrams is handled in [dyz07], where detailed formalism and implementation details have been given. the main idea of the paper is that it is not enough to utilize design patterns, but information should be stored on how they have been applied. in this way, refactoring and the comprehension of the developed system can be simpliproc. vffp 2009 2 / 12 eceasst fied. in the given solution, an uml profile has been provided to brand diagrams with stereotype information. based on the attached information, the applied design patterns and the role of each element played in the pattern can be retrived from the system. the authors implemented a system, named visdp, in which the augmented information is not only stored but visualized in a legible way. the complexity of the resulting diagrams are kept to a minimum based on several aspects. the given solution could be integrated into vmts to aid domain-specific design pattern creation, however, our approach now deals with more fundamental problems, such as how to integrate design patterns into a dsl environment, and how to force valid pattern definition. thus, the uml related design pattern achievments given in [dyz07] can be considered a future work for our domain-specific pattern solution. the design pattern modeling language (dpml) [mhg02] is a high level language which is proposed to describe uml design patterns. with dpml one can model the static structure of a pattern, however, the approach also provides a solution to identify the usage of a pattern in the host model later as well. during the instantiation process, an instance model is created, that maps the elements of the pattern to the elements of the host model. compared to dpml, our solution is not limited to uml, and we use the target domain and the concrete syntax to define patterns. although, we do not create a reference between the pattern elements and the concrete instances of them. furthermore, the focus of our research is to verify at least partially the constraints of the metamodel on the patterns, which issue is not handled by dpml. the work presented in [zkdz07] provides solutions for two different problems: (i) it verifies whether a design observes the structural integrity of the pattern using spatial graph grammars. (ii) furthermore, it offers graph transformation to evolve models by preserving the properties of the patterns: an individual graph transformation is suggested for each characteristic operations related to a design pattern. although [zkdz07] is limited to uml class diagrams, the approach could be generalized to arbitrary modeling languages as well. 3 design pattern modeling support in vmts as we are embedding design pattern support into a metamodeling environment, it is straightforward to use the modeling environment and its data repository to create and store patterns as well. the simplest solution is to define patterns as general models, thus, we have a complete solution to store default model element properties and layout information together with the patterns as well. in addition to defining design patterns, there is a natural need to organize them into categories, and attach meta information to them. for this purpose, we have created a simple language that can model the hierarchy of pattern categories, and the position of design patterns in this hierarchy. 3.1 defining design patterns in vmts recall that design patterns can be created as any other models, however, the modeling environment can be less restrictive when performing editing operations compared to traditional modeling. a criterion that does not have to be verified for design patterns is the existence of dangling edges. obviously, a model with a dangling edge cannot be valid, however, a design pattern may 3 / 12 volume 25 (2010) design pattern modeling with constraint relaxation (a) transitive closure (b) registering design pattern figure 1: design pattern definition in vmts contain edges with only one endpoint set, as the another endpoint can be set in the target model the design pattern is inserted into. another criterion that can be checked less restrictively is the correspondence of the containment hierarchy to the one defined in the metamodel: when building a model, the container node of an element has to be exactly of the type that was defined in the metamodel. however, when a design pattern is built, each element can also be placed directly onto the diagram, and we have to check at insert time, whether the target container is correct or not. figure 1 illustrates a general transitive closure pattern for graph rewriting rules, and the interface to register a pattern in the central repository. when registering a design pattern, one can select among existing pattern categories for the container of the new element (or create a new category in the tree), and provide a name and description for the pattern. 3.2 organization of design patterns design patterns can be organized into categories. these categories correspond to the elements of a unique model, its metamodel is depicted in figure 2 (a). on the diagram, the repository element corresponds to the categories. repositories can be embedded into each other, and they can contain patterns. each pattern contains a description attribute, and a re f erence attribute pointing to a model that contains a design pattern. 3.3 inserting patterns design pattern instances can be inserted into any target model, however, verifications have to be performed whether the pattern can be inserted into the selected context or not. the most important constraint is that the design pattern must have the same metamodel as the target model. figure 2 (b) depicts the window used to insert patterns into the target model. design patterns with non matching metamodels are not even provided for insertion. another important criterion is that the root elements of the pattern (the elements that are placed directly onto the diagram of the pattern model) should be able to be contained by the target element in the target model according to the metamodel. during the insertion, one can also customize the properties of the inserted elements. in addition to providing a new name for each element, the attributes that are not specified in the pattern model can also be set. proc. vffp 2009 4 / 12 eceasst (a) (b) figure 2: (a) pattern repository metamodel (b) pattern insertion window when a design pattern is being inserted, it is common that several elements of the pattern are already defined by the target model. these elements are the connection points between the pattern and the target model. therefore, vmts also provides the possibility to select a matching target model element for pattern elements. pattern elements with matching target model elements are not inserted again, but the remaining parts are glued to the existing ones. 4 constraint relaxation restrictions applied to models can be divided into two categories: (i) general restrictions that the modeling environment forces onto the models and (ii) domain-specific constraints defined in the metamodels. the former ones can be considered domain independent constraints that are given by the tool-set of the environment. generally, these are structural constraints, such as the disallowance of dangling edges. the latter ones are developed by the metamodel creator, these constraints are restrictions that cannot be defined visually by the metamodel. a platformindependent, standardized language for this purpose is the object constraint language (ocl) [wk03]. during the pattern creation, constraint validation should be performed to filter invalid patterns. a pattern can be considered invalid, if there is no possible augmentation to create a valid instance model from it. the two types of constraint require different constraint relaxation approaches, which are introduced in the following sections. 4.1 structural constraint relaxation in vmts, metamodels can be extended with object constraint language restrictions that are checked on the instance models during their design [vml08]. these domain-specific textual constraints that cannot be expressed with graphical notations give a fine control over our models. as mentioned before, to extend the modeling environment, it is a straightforward approach to 5 / 12 volume 25 (2010) design pattern modeling with constraint relaxation utilize previously implemented functionalities. 4.1.1 interface hierarchy of vmts models to utilize ocl constraints for validating general structural properties, such as cardinality, edge multiplicity or whether a model contains dangling edges or not, a technique is needed to define general constraints that do not correspond to a specific domain. extending ocl with non-domain specific features would require changing the language definition, thus, this is not considered a viable solution. as illustrated in [aala09], vmts translates metamodels into c# class libraries that are instantiated when instance models are created. naturally, the generated classes implement a predefined interface hierarchy, called vmts domain interface (vdi). to support domain independent constraints, this vdi has been modeled in vmts as a standard domain-specific model, which is depicted in figure 3. the illustrated model gives the possibility to express constraints that apply to all the domains, which implement the vdi. the modeled vdi hierarchy strictly follows the one used in the actual vdi implementation. thus, for further reference see [aala09]. figure 3: modeled vmts domain interface (vdi) general model constraints that can be expressed with standard ocl are integrated into vmts. for example, during modeling, dangling edges should not be allowed, thus a constraint illustrated in figure 4 is defined to enforce valid edges. 4.1.2 constraint relaxation in pattern definition during pattern definition, general ocl constraints should be relaxed, as the defined constraints need to be valid on models and not on patterns. however, patterns that cannot be augmented to a valid model should be filtered. in most of the practical cases, partial instantiation means relaxing proc. vffp 2009 6 / 12 eceasst context iedgebase inv danglingedge: not self.left.oclisundefined() and not self.right.oclisundefined() figure 4: dangling edge invariant the multiplicities on the edges, the cardinalities of the nodes in the metamodel and allowing empty attributes [llm]. in practice, this means that some of the general constraints should be changed, such as the multiplicity checking; some should be omitted, such as the dangling edge validation; and some may be left unchanged, such as enforcing model item naming conventions. figure 5 illustrates the constraint that validates edge multiplicities in design patterns. note that the minimum multiplicity verification is omitted. in line 3, the code iterates through all the nodes in the model. line 4 selects an edge from the leftedges navigation. in line 5, the metaedge of the selected edge is stored in a local variable (let expression). in line 6, edges of the metaedge-type are counted from the leftedges. finally, the previously computed value is compared to the upper value of the right multiplicity. the code fragment only checks the leftedges navigation on the node, similarly the rightedges navigation should be validated as well. 1 context imodelbase 2 inv relaxededgemultiplicity: 3 self.nodes->forall(node | 4 node.leftedges->forall(edge | 5 let medge: iedgebase := edge.metaitem.oclastype(’iedgebase’) in 6 node.leftedges->select(e | e.metaitem = medge)->size() <= 7 medge.rightmultiplicity.maxint) 8 and ...) figure 5: relaxed edge multiplicity checking similarly, figure 6 depicts the relaxed cardinality validation constraint. the code fragment developed collects all the metamodel elements used in the current model into a set, and then the number of the instances are compared to the maximum value of the cardinality. 1 context imodelbase 2 inv relaxedcardinality: 3 self.items->collect(element | 4 element.metaitem.oclastype(’imodelelement’))->asset()-> 5 forall( meta | 6 self.items->select(i | i.metaitem = meta)->size() <= 7 meta.cardinality.maxint) figure 6: relaxed cardinality multiplicity checking 7 / 12 volume 25 (2010) design pattern modeling with constraint relaxation 4.2 constraint relaxation the structural constraint relaxation introduced above works only because the hierarchical relaxation rules in patterns do not change based on the actual domain, but only on general restrictions, such as the allowance of dangling edges. however, metamodels are augmented with domainspecific constraints that should be enforced on the instance models. thus, a mechanism is needed to handle ocl constraint relaxation as well. if a comprehensive method is given for ocl relaxation, the development tool can force restrictions on the developed pattern to ensure that patterns that cannot be augmented to a conforming model cannot be created at all. figure 7 illustrates the general overview of the constraint relaxation. mm illustrates the metamodel, m the instance model, pm is the pattern model. pm ′ marks a modified pattern on which the relaxed c ′ constraints should be checked. pm ′ is an extended version of pm, in which each dangling edge is augmented with the appropriate end node. this is by no mean a restriction, as all the edges are typed, the types of the end nodes are well-known. thus adding an element to the end does not cause any ambiguities. however, the constraint evaluation can be facilitated by providing the evaluator as much information as possible. figure 7 depicts the schematic overview of the constraint relaxation. mm c de f ines oo �� equals �� pm con f orms oo // pm ′ c ′ validates oo m augments oocon f orms gg c validates oo ww figure 7: general constraint relaxation overview 4.2.1 relationship between ocl and relaxation to handle ocl relaxation comprehensively, the relationship between ocl constraints and design patterns should be examined. figure 8 depicts the basic structure of the ocl expression metalanguage. studying the figure reveals that the only point where an ocl code fragment interacts with the underlying model is the callexp, more precisely, the featurecallexp non-terminal of the language. a featurecallexp can express attribute calls, navigations and method calls on model items. 4.2.2 relaxation a simple ocl constraint relaxation can be provided as follows: (i) if there is at least one featurecallexp in the currently checked constraint, the constraint is omitted, and it is reported to the user that it cannot be validated. (ii) if there is no featurecallexp, the constraint is validated on the design pattern. this is a simple and bullet-proof constraint relaxation algorithm that can proc. vffp 2009 8 / 12 eceasst figure 8: ocl language overview be further refined if the constraint is separated into several independent parts, and only those subexpressions are omitted that contain featurecallexps. the separation can be implemented alongside boolean operations, such as and or or, and possibly, lazy evaluation may not require the evaluation of undecidable expressions. however simple this method is, it is not useful in practice, as ocl constraints rarely omit model element retrieval, since the main aim of the constraint is to restrict the models somehow. handling the model element access is a complex task, as different programming constructs react differently to a subpart that cannot be evaluated. for instance, in an if expression, if the condition is undecidable, the true and false branches should not be evaluated at all, and all the expressions that rely on this if have undecidable value. unless, of course, the true and false branches contain the same evaluatable expressions. on the other hand there are cases, when there is no need to evaluate an expression on a pattern, for instance, consider the following expression: element.navigation → includes(ex pression). if navigation is a navigation with 0..∗ multiplicity, the ex pression does not need to be evaluated as the pattern is always amendable with a new item connected to element that satisfies the ex pression. thus in this case, we can see that includes should always return true on a pattern. in general, expressions that contain a body part can hardly be evaluated without all the information. thus iterate and the iterators that needs complex program comprehension to analyze them in an off-line way can be considered undecidable. however, methods on collection types, such as size(), includes(), count(), etc., can be handled. naturally, these differ from collection type to collection type. in the following, a simple set is examined, more precisely a navigation, whose multiplicity is 0..∗, thus returns a set of elements. table 1 summarizes the methods avail9 / 12 volume 25 (2010) design pattern modeling with constraint relaxation able on ocl sets, their meanings and how they should be handled during constraint relaxation. method name meaning handling size() : int the size of the set gives a lower bound includes(t 1) : bool whether the element is in the set omit excludes(t 1) : bool opposite of includes enforce count(t 1) : int the number of occurrences of the argument gives a lower bound includesall(set(t 1)) : bool whether all the elements of the argument is in the set omit excludesall(set(t 1)) : bool opposite of includesall enforce isempty() : bool whether the set is empty enforce notempty() : bool whether the set is not empty omit sum() : t 1 the sum of the elements if + exists on t 1 no information product(coll(t 2)) : t 3 the cross product of the two sets gives a partial result union(set(t 1)) : set(t 1) the union of the two sets gives a partial result intersect(set(t 1)) : set(t 1) the intersection of the two sets gives an augmented result minus(set(t 1)) : set(t 1) the elements of the set that are not in the argument gives a partial result symmetricdi f f erence( set(t 1)) : set(t 1) the elements of the set that are in one of the sets no information including(t 1) : set(t 1) the set with the argument union added to it gives a partial result excluding(t 1) : set(t 1) the set with the argument union subtracted from it gives a partial result table 1: ocl set methods and relaxation in the third column of table 1, the following options are presented: gives a lower bound a number is returned and the evaluated constraint would give a smaller number than it would return on the instance model. omit the constraint validation can be omitted on the design pattern as the instance can always be augmented to return true. enforce the constraint validation should be enforced on the design pattern, if it returns f alse, the evaluation on the instance would return f alse as well. no information nothing can be stated about the result of the method. proc. vffp 2009 10 / 12 eceasst gives a partial result the method executed on the pattern returns a subset of the real result. gives an augmented result the method executed on the pattern returns a superset of the real result. the last two can be considered undecidable as well, because in general we cannot state anything based on approximate results. omit and enforce are straightforward. and the first option that states it gives a lower bound should be examined further. in this case, if we still consider that the set is a result of a navigation, the multiplicity of the navigation gives another restriction on the model. thus the combination of the two multiplicity constraints should be utilized. multiplicity relaxation states that n1..n2 multiplicity should be changed to 0..n2, where n2 can be infinity. the lower bound restriction (c1) coming from the constraint modifies it to c1..n2. note that if c1 > n2, there cannot be any instance model that satisfies all the restrictions thus the pattern is not valid. 5 conclusions and future work this paper has presented an approach to treat domain-specific design patterns in metamodeling environments. the visual modeling and transformation system has been utilized as the implementation framework. we have shown a way how a modeling environment can facilitate the design pattern definition, categorization and utilization. also, structural constraints defined in the metamodels have to be partly checked in design patterns to allow only valid pattern definition. thus, relaxed versions of general constraints are given in the modeling environment. also, ocl constraints added to the metamodels should be considered during pattern validation, however, comprehensive handling requires complex program analysis. the given solution for supporting domain-specific design patterns reutilizes the modeling functionalities of the environment, thus, it requires only few modifications in the system, and integrates well into the environment. pattern integration in vmts could be further improved by providing automatic gluing of patterns to the already existing model elements in the instance models. this requires common subgraph matching, as the most appropriate gluing options should be returned to the user. also with drag and drop capabilities, this automatic gluing could be improved to aid pattern gluing to a specific subpart of the model. constraint relaxation requires further examination. it would be highly useful to support the relaxation of iterator and iterate expressions. however, these programming constructs require a high level of program comprehension that has not been yet studied. acknowledgment this paper was supported by the jános bolyai research scholarship of the hungarian academy of sciences. 11 / 12 volume 25 (2010) design pattern modeling with constraint relaxation bibliography [aala09] l. angyal, m. asztalos, l. lengyel, et al. towards a fast, efficient and customizable domain-specific modeling framework. in proceedings of the iasted international conference. volume 31, pp. 11–16. innsbruck, austria, february 2009. [bbm03] f. budinsky, s. a. brodsky, e. merks. eclipse modeling framework. pearson education, 2003. [dyz07] j. dong, s. yang, k. zhang. visualizing design patterns in their applications and compositions. ieee trans. softw. eng. 33(7):433–453, 2007. [ghjv94] e. gamma, r. helm, r. johnson, j. m. vlissides. design patterns: elements of reusable object-oriented software (addison-wesley professional computing series). addison-wesley professional, illustrated edition edition, november 1994. [ibm09] ibm. rational software architect website. 2009. http://www-01.ibm.com/software/awdtools/architect/swarchitect/ [kt08] s. kelly, j.-p. tolvanen. domain-specific modeling: enabling full code generation. john wiley & sons, march 2008. [lbm+01] kos ldeczi, rpd bakay, m. marti, p. vlgyesi, g. nordstrom, j. sprinkle, g. karsai. composing domain-specific design environments. computer 34(11):44–51, 2001. [llm] t. levendovszky, l. lengyel, t. mészáros. supporting domain-specific model patterns with metamodeling. software and systems modeling. accepted. [mhg02] d. mapelsden, j. hosking, j. grundy. design pattern modelling and instantiation using dpml. in noble and potter (eds.), fortieth international conference on technology of object-oriented languages and systems (tools pacific 2002). crpit 10, pp. 3–11. acs, sydney, australia, 2002. [min02] m. minas. specifying graph-like diagrams with diagen. in science of computer programming. p. 2002. 2002. [vml08] t. vajk, g. mezei, t. levendovszky. ocl compiler support for modeling environments with incremental compilation. buletinul stiintific al universitatii ”politehnica” din timisoara 53(1):19–24, 2008. [vmt09] vmts team. visual modeling and transformation system website. 2009. http://vmts.aut.bme.hu [wk03] j. warmer, a. kleppe. object constraint language, the: getting your models ready for mda, second edition. addison wesley, 2003. [zkdz07] c. zhao, j. kong, j. dong, k. zhang. pattern-based design evolution using graph transformation. journal of visual languages & computing 18(4):378–398, 2007. visual interactions in software artifacts. proc. vffp 2009 12 / 12 http://www-01.ibm.com/software/awdtools/architect/swarchitect/ http://vmts.aut.bme.hu introduction related work design pattern modeling support in vmts defining design patterns in vmts organization of design patterns inserting patterns constraint relaxation structural constraint relaxation interface hierarchy of vmts models constraint relaxation in pattern definition constraint relaxation relationship between ocl and relaxation relaxation conclusions and future work recognizable graph languages for checking invariants electronic communications of the easst volume 29 (2010) proceedings of the ninth international workshop on graph transformation and visual modeling techniques (gt-vmt 2010) recognizable graph languages for checking invariants christoph blume, h.j. sander bruggink and barbara könig 13 pages guest editors: jochen küster, emilio tuosto managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst recognizable graph languages for checking invariants christoph blume, h.j. sander bruggink and barbara könig abteilung für informatik und angewandte kognitionswissenschaft, universität duisburg-essen, germany christoph.blume@uni-due.de, sander.bruggink@uni-due.de, barbara koenig@uni-due.de abstract: we generalize the order-theoretic variant of the myhill-nerode theorem to graph languages, and characterize the recognizable graph languages as the class of languages for which the myhill-nerode quasi order is a well quasi order. in the second part of the paper we restrict our attention to graphs of bounded interface size, and use myhill-nerode quasi orders to verify that, for such bounded graphs, a recognizable graph property is an invariant of a graph transformation system. a recognizable graph property is a recognizable graph language, given as an automaton functor. finally, we present an algorithm to approximate the myhill-nerode ordering. keywords: graph transformation, recognizable graph languages, myhill-nerode theorem, invariants 1 introduction regular languages and well quasi orders have proven to be useful analysis techniques in the field of string rewrite systems. in particular, the myhill-nerode well quasi order of a regular language l, which is strongly related to the well-known myhill-nerode equivalence, has nice properties [ehr83, lv94]: the left and right concatenation are monotone w.r.t. the order and the regular language l used to define it is upward-closed with respect to it. let a string rewrite system s be given. from the first property it follows that if r is greater (with respect to the order) than ` for every rewrite rule ` → r of s , then it holds that v is greater than w for each word v reachable from w. the second property means, that for each word v that is greater than w, it holds that v ∈ l if w ∈ l. together, these two properties ensure that it is decidable whether a property, described as a regular language containing exactly the words satisfying the property, is an invariant of a string rewrite system. since the late 1980s several notions of regular graph languages – in this context called recognizable graph languages – have been introduced [bc87, cou90, bk06, bk08b], which all turned out to be equivalent. recognizable graph languages have found many applications, especially in the field of complexity theory. in the light of the above observations it is natural to ask how results from regular languages, such as myhill-nerode equivalences, can be transferred and used for recognizable graph languages. while myhill-nerode equivalences are typically used to show that a language is not regular, we use them in a different way and study myhill-nerode quasi orders in order to verify that a specified property is an invariant of a graph transformation system. the definition of recognizable graph language we use in this paper is based on the notion of automaton functor introduced in [bk08b], a category-based generalization of finite (word) 1 / 13 volume 29 (2010) mailto:christoph.blume@uni-due.de, sander.bruggink@uni-due.de, barbara_koenig@uni-due.de recognizable graph languages for checking invariants automata. like finite automata in the word case, automaton functors provide an operational view on recognizable graph languages, which allows one to define a “myhill-nerode”-order on automaton states rather than on graphs directly. this is convenient, because states typically represent an infinite class of graphs. still, automaton functors are in general infinite structures, due to the unboundedness of graph interfaces. in section 2 we briefly define recognizable graph languages, automaton functors, and the category-theoretic notions at the heart thereof. in section 3 we generalize the order-theoretic variant of the myhill-nerode theorem to (recognizable) graph languages; that is, we define the myhill-nerode quasi order on graph languages and characterize recognizable graph languages as the class of languages for which this order is a well quasi order. in the second part of the paper we focus on the application of the myhill-nerode quasi order in practice. first, in section 4 we show that we need only define the automaton functor for a restricted set of so-called atomic cospans, so that we do not need consider all cospans when calculating the order. as indicated above, the quasi order typically cannot be represented in a finite way, due to the unboundedness of graph interfaces. in section 5 therefore, we restrict our attention to graphs which can be constructed with atomic cospans of bounded interface sizes, and we present an algorithm which approximates (and in the case of deterministic automaton functors even computes) the myhill-nerode quasi order of an automaton functor. finally, we illustrate the work with a short example in section 6. the full version with proofs can be found at [bbk10]. 2 preliminaries in this section we briefly recall some concepts of category theory and recognizable graph languages. we presuppose a basic knowledge of category theory and order theory. 2.1 category theory and recognizable graph languages first we review and fix some notations. the category which has sets as objects, relations as arrows and relation composition as composition operator is denoted by rel . the subcategory which has total functions as arrows instead of relations is denoted by set . the composition of two arrows f and g will be denoted by ; where f ; g = g◦ f indicates the arrow which is obtained by first applying the arrow f and then the arrow g. let c be a category with pushouts. a cospan c : j −cl� c �cr− k is a pair of c -arrows with the same codomain. here, j and k are the domain (or inner interface) and codomain (or outer interface) of the cospan c, respectively. the identity cospan for an object e is the cospan consisting of twice the identity arrow of e. let c : j −cl�c �cr−k and d : k −dl� d �dr−m be cospans (where the codomain of c equals the domain of d). the composition of c and d is obtained by taking the pushout of cr and dl. a semi-abstract cospan is an equivalence class of cospans, where we take the middle object of the cospan up to isomorphism. now, the cospan category cospan(c ) is defined as the category which has the objects of c as objects, and semi-abstract cospans as arrows. if the middle object is not important, a cospan c : j →c ← k (an arrow in the cospan category from j to k) will be denoted as c : j # k. proc. gt-vmt 2010 2 / 13 eceasst let a set σ of labels be given. a hypergraph g, later also simply called graph, is a four-tuple 〈vg, eg, attg, labg〉, where vg is a finite set of vertices (or nodes) of g, eg is a finite set of edges of g, attg : eg →v∗g is the attachment function and labg : eg → σ is the labeling function. here, v∗g denotes the set of finite sequences of elements of vg. a hypergraph morphism f is a structure-preserving map between two hypergraphs. a discrete graph is a graph which does not contain any edges. the discrete graph with n nodes is denoted by dn. the empty graph is denoted by /0 instead of d0. the category of graphs and graph morphisms is denoted by hgraph . a cospan of graphs (an arrow in the category cospan(hgraph )) can be seen as a graph with an inner (left) and an outer (right) interface. intuitively, the interfaces designate the parts of the graph which can be “touched” from the outside. with [g] : /0 → g ← /0 we denote the cospan consisting of a graph g with empty inner and outer interfaces. cospans of graphs are closely related to graph transformation systems, in particular to the double-pushout (dpo) approach to graph rewriting [ss05]. a dpo rewrite rule ρ : l�ρl−i −ρr� r can be considered as a pair of cospans ` : /0 → l �ρl−i and r : /0 → r �ρr−i, which will in the following be called leftand right-hand side, respectively. then it holds that g ⇒ρ h if and only if [g] = ` ; c and [h] = r ; c, for some cospan c. we define recognizable graph languages by using automaton functors on the category of cospans of graphs, as in [bk08b]. definition 1 (automaton functor, recognizability) let a category c with initial object /0 be given. an automaton functor is a functor a : c → rel , which maps every object x of c to a finite set a (x ) of states of x and every arrow f : x →y to a relation a ( f ) ⊆ a (x )×a (y ), together with two distinguished sets ia ⊆ a ( /0) and fa ⊆ a ( /0) of initial and final states, respectively. an automaton functor is deterministic if every relation a ( f ) is a function and every ia contains exactly one element. an arrow f : /0 → /0 is accepted by an automaton functor a , if 〈s,t〉∈ a ( f ), for some s ∈ ia and t ∈ fa . the language l(a ) of an automaton functor contains exactly those arrows which are accepted by it. a language l of arrows from /0 to /0 is a recognizable language if l = l(a ), for some automaton functor a . the intuition behind the definition is to have a mapping into a (locally) finite domain. the functor property guarantees that decomposing an object in different ways does not affect acceptance in any way. this is different from word languages, where there is essentially one way to decompose an object into subobjects. familiar constructions on finite automata, such as the determinization construction, can be easily generalized to automaton functors. also, it was shown in [bk08b], that restricting to discrete interfaces does not affect the expressiveness of the formalism. due to the latter result, we shall restrict to discrete interfaces in the rest of this paper. the above definition can easily be generalized to accept languages between arbitrary objects. however, in our setting we require only languages from the initial object to the initial object. a characterization of recognizable graph languages can be obtained in terms of recognizable languages in cospan(hgraph ): definition 2 (recognizable graph language) a set l of graphs is a recognizable graph language, 3 / 13 volume 29 (2010) recognizable graph languages for checking invariants if [l] = {[g] : /0 → g ← /0 | g ∈ l} is a recognizable language in cospan(hgraph ). in the following we will not distinguish between l, a language of graphs, and [l], a language of (cospans of) graphs with empty interfaces. 2.2 orders on categories one of the basic concepts in checking invariants of regular languages is the notion of (well) quasi orders. first, we review the definition of (well) quasi orders on arbitrary sets (see also [lv94]). a quasi order (qo) is a binary relation vm on a set m if vm is reflexive and transitive. a quasi order vm on m is called well-quasi order (wqo) whenever if m1, m2, . . . is an infinite sequence of elements of m, then there exist integers i, j such that 0 < i < j and mi v m j. in the following we will write v instead of vm if m is clear from the context. next, we consider a semigroup (m,∗) and a quasi order v on m. we say that v is left-monotone (resp. right-monotone) if for all m1, m2, m ∈ m the following condition is satisfied: m1 v m2 =⇒ m∗m1 v m∗m2 (resp. m1 v m2 =⇒ m1 ∗m v m2 ∗m). in the following we will define orders on the homsets of a category. more specifically, two arrows f , g can only be related by a quasi order v if they have the same source and target objects. alternatively we could consider v as a family of quasi orders, one for each homset. the notion of order in categories is also present in enriched categories [gmm94, kel82]. note however that unlike in enriched categories we do not necessarily require that the order is always preserved by composition ( f v f ′ and g v g′ implies f ; g v f ′ ; g′), since we will usually only require right-monotonicity as defined above. 3 a generalization of the myhill-nerode theorem in this section we generalize the theorem of myhill-nerode to graph languages. this theorem says that a language is regular if and only if it is the union of equivalence classes of a monotone (or right-monotone) congruence on words of finite index. there is an order-theoretic variant of this theorem given in [ehr83, lv94] saying that a language is regular if and only if it is upward-closed with respect to a monotone well quasi order. in order to state this theorem in our framework we first need the notion of myhill-nerode quasi order. note that while the word or string variant of this theorem uses orders that are both left-monotone and right-monotone, here we work only with right-monotone orders. intuitively this is sufficient since we start with the empty interface and attaching any cospan on the left can always be simulated by attaching an appropriate cospan on the right. definition 3 (myhill-nerode quasi order) let l be a graph language over cospan(hgraph ). a quasi order ≤l on cospan(hgraph ) is called myhill-nerode quasi order (relative to l), if for arbitrary cospans a, b : /0 # dn the following condition is satisfied: a ≤l b iff ∀(c : dn # /0) : ((a ; c) ∈ l =⇒ (b ; c) ∈ l) . proc. gt-vmt 2010 4 / 13 eceasst based on ≤l we can define the myhill-nerode equivalence ≡l on cospans a, b : /0 # dn as follows: a ≡l b iff a ≤l b and a ≥l b the myhill-nerode equivalence is called locally finite, if for every cospans a : /0 # dn the equivalence class of a is a finite set. one can prove that the myhill-nerode quasi order is in fact a quasi order on cospan(hgraph ). it also possesses two other properties which will be important in the following. (note that all proofs can be found in the appendix.) proposition 1 let l be a graph language over cospan(hgraph ). the myhill-nerode quasi order (relative to l) is right-monotone and the language l is upward-closed with respect to ≤l. this proposition is the key to invariant checking. we say that a graph language l is an invariant for a rule ρ if g ∈ l and g ⇒ρ h always implies h ∈ l. imagine a rule ρ is given by a pair of cospans `, r : /0 # i and it holds that ` ≤l r. if g is rewritten to h via ρ we have that [g] = `; c and [h] = r; c for some cospan c : i # /0. now ` ≤l r implies [g] ≤l [h] (right-monotonicity) and if g is contained in l, then h is contained in l as well (upward-closure). hence l is an invariant w.r.t. ρ . furthermore if ` 6≤l r, there is a cospan c violating the condition of definition 3 and l is no invariant w.r.t. ρ . hence we have that l is an invariant for ρ if and only if ` ≤l r. similar to the case of word languages we can characterize the recognizable graph languages in terms of congruence classes as shown in [bk08b]. furthermore ehrenfeucht et al. [ehr83] give a generalization of the theorem of myhill-nerode by characterizing regular languages in terms of well quasi orders instead of equivalence classes of finite index. as an important result we can lift this theorem to the case of recognizable graph languages. theorem 1 (generalized myhill-nerode theorem) let a graph language l over cospan(hgraph ) be given. the following statements are equivalent: (i) l is a recognizable graph language, (ii) ≡l is locally finite and l is the union of (finitely many) equivalence classes of ≡l. (iii) l is upward closed with respect to some right-monotone well quasi order vl. (iv) the myhill-nerode quasi order ≤l is a well quasi order. 4 atomic cospans in this section we introduce atomic graph operations which play the role of letters in the case of words. these atomic graph operations are based on the algebra of graphs originally described by courcelle [bc87]. each atomic graph operation is given by an atomic cospan, so that applying the graph operation to a cospan (a graph with interfaces) amounts to composing the cospan with 5 / 13 volume 29 (2010) recognizable graph languages for checking invariants the atomic cospan of the operation. in the following, we will not distinguish between graph operations and atomic cospans used to define them. we assume that the set of nodes of each discrete graph dn is vdn = {v0, . . . vn−1}. we set nn = {0, . . . , n−1} and we denote the disjoint union of two graphs g1 and g2 by g1 ⊕g2. we assume that g1 and g2 are disjoint. furthermore we define the disjoint union f ⊕g : g1 ⊕g2 → h1 ⊕h2 of two graph morphisms f : g1 → h1 and g : g2 → h2 where h1 and h2 are disjoint as follows: ( f ⊕g)(v) = { f (v), if v ∈vg1 g(v), if v ∈vg2 and ( f ⊕g)(e) = { f (e), if e ∈ eg1 g(e), if e ∈ eg2 . definition 4 (atomic graph operations) restriction of the outer interface: let ρ : dn−1 → dn with ρ(vi) = vi be an arrow between two discrete graphs. we define the cospan resn as follows: resn : dn −iddn� dn �ρ−dn−1. permutation of the outer interface: let a permutation π : nn → nn with π(i) = i + 1 for 0 ≤ i < n−1 and π(n−1) = 0 and an arrow σ : dn → dn with vi 7→ vπ(i) between two discrete graphs be given. we define the cospan permn as follows: permn : dn −iddn� dn �σ−dn. transposition of the outer interface: let a transposition τ : nn → nn with τ(0) = 1, τ(1) = 0 and τ(i) = i for 2 ≤ i ≤ n−1 and an arrow σ : vn →vn with vi 7→ vτ(i) between two discrete graphs be given. we define the cospan transn as follows: transn : dn −iddn� dn �σ−dn. fusion of two nodes of the outer interface: let n > 1 and an equivalence relation θ = idvn ∪ {(v0, v1), (v1, v0)}, an arrow θmap which maps every node of dn to its θ -equivalence class, and an arrow ϕ : dn−1 → d with vi 7→ jvi+1kθ , where d is the discrete graph with node set {jvkθ | v ∈vn}, be given. we define the cospan fusen as follows: fusen : dn −θmap� d �ϕ− dn−1. connection of a single hyperedge: let an edge label a ∈ σ, m ∈ n with 0 ≤ m ≤ n and a hypergraph h which consists of a single hyperedge h with arity m and labeled with a be given. we define the cospan connecta,mn as follows: connect a,m n : dn −e�h ⊕dn−m �e−dn with e(vi) = atti(h) for 0 ≤ i < m and e(vi) = vi−m otherwise. disjoint union with a single node: we define the cospan vertexn as follows: vertexn : dn −dl� dn+1 �iddn+1−dn+1 with dl = iddn ⊕i and i : /0 → d1. the intuitions behind these atomic graph operations are as follows (see figure 1): with the cospan resn we can hide the last node of the outer interface of a precomposed cospan. the cospan fusen glues the first two nodes of the outer interface of a precomposed cospan and afterward restricts the second node of this outer interface. the cospans transn and permn permute the outer interface of a precomposed cospan. the former maps the nodes of the outer interface in such a way that only the first two nodes are transposed. the latter permutes the nodes of the outer interface such that every node is mapped to its successor node. in order to be able to construct new graphs the cospans vertexn and connect a,m n can be used to generate new nodes and edges. by composing vertexn with an arbitrary cospan c : /0 → g ← dn proc. gt-vmt 2010 6 / 13 eceasst resn = dn dn dn−1 ... ... ... ρ permn = dn dn dn ... ... ... σ transn = dn dn dn ... ... ... σ fusen = dn d dn−1 ... ... ... θmap ϕ connect a,m n = dn h ⊕dn−m dn ... ... ... ... a ... ... e vertexn = dn dn+1 dn+1 ... ... ... dl figure 1: graph operations we add a single, isolated node to g and extend the outer interface of c to dn+1, such that the last node of the extended outer interface is mapped to the new node. the cospan connecta,mn adds an a-labeled hyperedge with arity m in such a way to g that the first m nodes of the outer interface are mapped to the m nodes of the hyperedge h. we can restrict our attention to these atomic graph operations, because any graph g (seen as a cospan of the form /0 → g ← /0) can be constructed by composing a finite number of them as shown by the next proposition. proposition 2 every cospan of the form c : dm −ϕ l� g �ϕ r− dn where the right leg ϕ r is injective can be constructed by a sequence op1, . . . , opk of atomic graph operations, i.e. c can be obtained as the composition c = op1 ; . . . ; opk. 5 a decidable variant in this section we develop an algorithm – based on the myhill-nerode quasi order – for checking invariants for recognizable graph languages. the algorithm takes as input an automaton functor which accepts the given graph language. in general this automaton functor has infinitely many states, since for every interface dn (n ∈ n) there exists a set of states. but for practical purposes we need an automaton functor which is finite, i.e. has only a finite number of states. in order to get automaton functors with a finite number of state sets, we only take cospans with a bounded interface size into account. definition 5 (bounded cospan) a cospan c : s # t is called bounded (by k), if there exist graph operations op1, . . . , op j such that c = op1 ; . . . ; op j and for every graph operation opi : dni # dmi for 1 ≤ i ≤ j it holds that ni, mi ≤ k. definition 6 (bounded myhill-nerode quasi order) let a natural number k ∈ n and a graph language l over cospan(hgraph ) be given. the quasi order ≤kl on cospan(hgraph ) is called bounded myhill-nerode quasi order (relative to l), if for arbitrary k-bounded cospans a, b : /0 # dn 7 / 13 volume 29 (2010) recognizable graph languages for checking invariants the following condition is satisfied: a ≤kl b iff ∀(c : dn # /0, c k-bounded) : ((a ; c) ∈ l =⇒ (b ; c) ∈ l) . the bounded myhill-nerode quasi order defined above gives us an over-approximation of ≤l, i.e., two cospans with a ≤l b are for sure related by the relation ≤kl, but not necessarily vice versa. note that graphs with edges of arity more than k can not be constructed by cospans that are bounded by k. also for edges with smaller arity it is not guaranteed that they are constructible. for example a k-grid consisting of binary edges needs interfaces of size at least k. since all automaton functors which accept only cospans of bounded interface size have a finite representation, we are able to consider an algorithm which computes the myhill-nerode quasi order relative to a given deterministic automaton functor similar to the algorithm for computing the myhill-nerode equivalence by pairwise comparing two states with their successor states. but for practical purposes the algorithm is not useful due to the fact, that in general the deterministic automaton functor can be exponentially larger than the equivalent non-deterministic automaton functor. therefore we also allow non-deterministic automaton functors as input for the algorithm. however this leads to some additional changes. since the automaton functor is non-deterministic, for a given state there exists a set of successor states instead of a unique successor state and we cannot pairwise compare two states with their (unique) successor states. in order to circumvent this difficulty, we allow an “one-sided error” by taking a stronger relation than the myhill-nerode quasi order. roughly, we are under-approximating language inclusion via some form of simulation. a relation r on the states of an automaton functor a is a simulation, if the following condition is satisfied: s1 r s2 =⇒ ( s1 ∈ fa ⇒ s2 ∈ fa ) ∧∀op : ∀s′1 ∈ a (op)(s1) : ∃s ′ 2 ∈ a (op)(s2) : (s ′ 1 r s ′ 2). a state t2 simulates a state t1, denoted by t1 � t2, if t1 r t2 holds for some simulation r. definition 7 (bounded simulation) let l be a graph language over cospan(hgraph ) and a an automaton functor, which accepts the language l. the quasi order ≤ka is called bounded simulation (relative to l), if for arbitrary, k-bounded cospans a, b : /0 # dm the following condition is satisfied: a ≤ka b iff ∀s1 ∈ a (a)(i a ) : ∃s2 ∈ a (b)(ia ) : s1 � s2. replacing the (bounded) myhill-nerode quasi order by the (bounded) simulation relation results in fact in an one-sided error, as the next proposition shows: proposition 3 let n, k ∈ n with n ≤ k, a, b : /0 # dn be cospans and a be the automaton functor which accepts the language l. if a ≤ka b holds, then a ≤ k l b holds. the inverse direction holds if a is deterministic. algorithm 1 on page 9 computes ≤ka as defined above. note that this is a fixed-point algorithm computing the greatest fixed-point. the relations �i (one for each interface size) first contain all possible pairs of states and are suitably refined in each step. first, we delete all pairs, where the first state is final and the second is not. then, for all pairs still in the relation we check whether proc. gt-vmt 2010 8 / 13 eceasst each transition from the first state can be mimicked by the second such that the resulting states are in the relation. if no more pairs can be deleted we have reached a fixed-point and terminate. then it is left to check whether the two cospans under consideration are related. algorithm 1 checksimrelated(a, b, k, a ) input: bounded cospans a, b : /0 # dn with n ≤ k, an automaton functor a output: true, if a ≤ka b and false, if a 6≤ k a b set �i= a (di)×a (di) for all 0 ≤ i ≤ k for all s0 ∈ fa , s1 ∈ a ( /0)\fa do delete (s0, s1) ∈�0 repeat for all (s0, s1) ∈�i with 0 ≤ i ≤ k do for all op ∈{connecta,mi , fusei, permiresi, transi, vertexi} do for all s′0 ∈ a (op)(s0) do if there exists no s′1 ∈ a ′(op)(s1), such that (s′0, s ′ 1) ∈� i then delete (s0, s1) from �i until no deletion has been performed in the last iteration for all i ∈ ia do for all s0 ∈ a (a)(i) do if there exists no state s1 ∈ a (b)(i), such that (s0, s1) ∈�n then return false return true theorem 2 let an automaton functor a and two bounded cospans a, b : /0 # dn with n ≤ k be given. then a ≤ka b holds, if and only if checksimrelated(a, b, k, a ) returns true. we implemented the algorithm in a naive way: our implementation explicitly stores the relations �i in tables and iterates until no further changes occur. more details about the run-time and memory requirement of the naive implementation are given in the next section; some ideas for significant improvement are presented as future work in the conclusion. 6 short example in this section we consider a multi-user file system where the access to the system is controlled by several rules in order to guarantee some consistency properties. the case study was inspired by [kmp02]. as in most cases, the violation of these consistency properties can be modeled by the occurrence of one or more forbidden graphs. therefore, we first introduce a k-bounded automaton functor a , i.e. an automaton functor processing only k-bounded graphs, which accepts every graph [g] which contains a specified subgraph u . the idea behind this automaton functor is as follows: the automaton functor used in this example contains a state set a (di) for every discrete interface di, 0 ≤ i ≤ k. every state in each state set stores two kinds of information: on the one hand the subgraph u′ of u which has already been read and on the other hand a partial function f from vdi to vu′ describing which vertices of u′ are contained in the interface di. by proposition 2, we can restrict the automaton functor to 9 / 13 volume 29 (2010) recognizable graph languages for checking invariants accept only atomic graph operations (see section 4), since every cospan [h] can be decomposed to a sequence of atomic graph operations op1, . . . , op` such that [h] = op1 ; . . . ; op`. for every atomic graph operation op j : dm # dn with 1 ≤ j ≤ `, m, n ∈{0, . . . , k} containing a subgraph u′′ of u and a state (u′, f ) ∈ a (dm) the successor state (u′∪u′′, f ′) ∈ a (dn) is computed by adding the new subgraph u′′ to the subgraph u′ and updating the partial function f according to op j resulting in the partial function f ′ (see image below). note that op j might contain various subgraphs u′′ and hence the automaton is heavily non-deterministic. more details concerning the construction of this automaton functor can be found in [blu08]. we can show that we obtain a functor which guarantees that the decomposition of the cospan [h] does not affect the acceptance behavior of the automaton functor. the set of start states ia contains only the state ( /0, /0) consisting of the empty graph and the empty partial function. the set of acceptance states fa contains only the state (u, /0) consisting of the wanted subgraph and the empty partial function. now we want to use this automaton functor f ′(dn) u u′∪u′′ dndm op j u′′ for the verification of the multi-user file system. we consider two properties which describe when the consistency of the multi-user file system is violated. the system is in a consistent state as long as these properties are not satisfied. the first property is the double write access of a user to a file (double access), i.e. a user has two times a write access to the same file at the same time. the second property is the write access of two different users to the same file at the same time (two users). these two properties can be modeled by the following two graphs, where nodes labeled with u (resp. f ) denote users (resp. files) and edges from a user-node to a file-node labeled with w (resp. r) denote a write (resp. a read) access of that user to that file: note that it is not forbidden that a user has more than one read access to u f w w u f u w w a file at the same time and that two or more users can have read access to the same file at the same time even if one user has write access to that file. since recognizable languages are closed under boolean operations and with the considerations above we can now construct an automaton functor that recognizes all graphs violating one of the two properties, i.e., all graphs that contain either of the two subgraphs. furthermore, the multi-user file system offers the usual operations such as adding and removing users, creating, deleting and requesting files as well as switching, dispossessing and transferring access rights. in the following, we will show with the rules “user creates new file” and “user requests file” how these file system operations can be modeled as dpo rewrite rules. the rule “user creates new file” applied for some user u creates a new file f and gives the user a write access to this file. it can be modeled by the following span: u 0 ←− u 0 −→ u 0 f w proc. gt-vmt 2010 10 / 13 eceasst the rule “user requests file” applied for some user u sets the write access of this user from the current file to some other existing file. the following span models this rule: u 0 f 1 f 2 ←− u 0 f 1 f 2 −→ u 0 f 1 f 2 w w since every rewrite rule can be considered as two cospans ` and r (see subsection 2.1) which are the left and right hand side of the corresponding rewrite rule, we can verify the consistency of this multi-user file system by checking, if the language of all graphs containing none of the forbidden subgraphs is an invariant for each rule. since the automaton functor accepts the complement of this language, i.e., all graphs that do contain one of the forbidden subgraphs, we perform a backwards analysis on each rewrite rule and check whether r ≤ka `. if r is related to `, then the original rewrite rule does not violate the consistency of the multi-user file system. after the application of the rule the consistency of the system is violated only if it was already violated before the rule application, hence the language is verified to be an invariant. we now use the algorithm described in the previous section to check the rewrite rules mentioned above. for all interface sizes that we checked the result of the algorithm is that the language is an invariant w.r.t. the first rule, but not w.r.t. the second rule. this is clear, since a user can request write access to a file, to which another user has already write access. note also that, due to the under-approximation by simulations, there are actually rules which are correct, but are not recognized as such by the algorithm. although the example is rather small, the computed simulation relation becomes very large quickly. table 1 presents the size of the simulation relation (according to the number of pairs contained in the relation) and the run-time of the implementation of algorithm 1 for some interface sizes. the tests were performed on a linux machine with a xeon dualcore 5150 processor and 2 gb of available main memory. maximum interface size 0 1 2 3 4 size (in pairs) 400 3.425 31.314 323.995 ≈3, 7·106 run-time (in seconds) <1s <1s <1s 2s 26s table 1: size of the simulation relation and run-time of the algorithm note that for interfaces with a size more than 4 the size of the simulation relation exceeds the amount of main memory. nevertheless it is possible to verify all rewrite rules which have a interface size up to 4. 7 conclusions the notion of recognizable graph language used in this paper has been introduced in [bk08b] and is strongly related to [cou90, gri03, bk06]. especially the notion of recognizability considered 11 / 13 volume 29 (2010) recognizable graph languages for checking invariants here is equivalent to courcelle’s notion. for a detailed comparison see [bk08b]. in [bk08a] a weaker notion of graph automata is introduced. invariant checking for graph transformation rules has already been considered in several papers: in [fl97, bpr03] shape types and shapes are introduced in order to describe graph languages. both papers propose algorithms that analyze each rule and check whether (and how) it may change the shape of a graph. in order to describe shapes the former uses context-free grammars whereas the latter uses more expressive graph reduction systems, that are able to express properties such as balancedness of trees. in [hpr06] a method for computing weakest preconditions of application conditions, which are equivalent to first-order graph logic, is presented. this method can also be used for invariant checking, by showing that for every rule the weakest precondition of the invariant is implied by the invariant. note that, in general, recognizable graph languages are more expressive than first-order logic since every monadic second-order graph logic formula is known to specify a recognizable graph language [cou90]. another related work [bbg+06] considers graph patterns consisting of negative and positive components and shows that they are invariants via an exhaustive search. interestingly, this method made efficient by a symbolic algorithm based on binary decision diagrams, an idea that we are trying to reuse in a somewhat different setting (see remarks below). we have not yet compared the effectiveness of our approach to these other approaches in detail, but our method is different from all the others in that it is based on the myhill-nerode quasi order. our approach suffers from the restriction that we have to work with k-bounded cospans. especially we first over-approximate the relation ≤l by ≤kl (by introducing k-boundedness), which is subsequently under-approximated by ≤ka (by using simulation instead of language inclusion). while it is difficult to imagine how to avoid the restriction to interfaces up to size k, the determinization of the automaton functor a , which would avoid the under-approximation, should be achievable if we use a more succinct representation of automaton functors. we are currently experimenting with the representation of automaton functors (which are basically very large relations) with binary decision diagrams (bdds), which are well-suited for the compact representation of large (but finite) relations. our experiments have so far been very promising. with bdds we can handle much larger interfaces and we expect to obtain less memory usage and better run-times. finally, decomposing a graph into atomic cospans is basically equivalent to the path decomposition of a graph and checking whether a graph is contained in the language is hence linear-time for graphs of bounded pathwidth. for efficiency reasons it would be more suitable to consider generalizations of tree automata that can handle tree decompositions of graphs, as it is similarly done in the work by courcelle. hence we are currently investigating tree automata and their generalization to graphs. bibliography [bbg+06] b. becker, d. beyer, h. giese, f. klein, d. schilling. symbolic invariant verification for systems with dynamic structural adaptation. in proc. of icse ’06 (international conference on software engineering). pp. 72–81. acm, 2006. [bbk10] c. blume, h. s. bruggink, b. könig. recognizable graph languages for checking proc. gt-vmt 2010 12 / 13 eceasst invariants. 2010. http://www.ti.inf.uni-due.de/publications/blume/invcheck.pdf [bc87] m. bauderon, b. courcelle. graph expressions and graph rewritings. mathematical systems theory 20(2-3):83–127, 1987. [bk06] s. bozapalidis, a. kalampakas. recognizability of graph and pattern languages. acta informatica 42(8/9):553–581, 2006. [bk08a] s. bozapalidis, a. kalampakas. graph automata. theoretical computer science 393:147–165, 2008. [bk08b] h. j. s. bruggink, b. könig. on the recognizability of arrow and graph languages. in proc. of icgt ’08. springer, 2008. lncs 5214. [blu08] c. blume. graphsprachen für die spezifikation von invarianten bei verteilten und dynamischen systemen. master’s thesis, universität duisburg-essen, november 2008. (in german). [bpr03] a. bakewell, d. plump, c. runciman. checking the shape safety of pointer manipulations. in proc. of relmics ’03. pp. 48–61. 2003. [cou90] b. courcelle. the monadic second-order logic of graphs. i. recognizable sets of finite graphs. inf. comput. 85(1):12–75, 1990. [ehr83] a. ehrenfeucht, d. haussler, g. rozenberg. on regularity of context-free languages. theor. comput. sci. 27:311–332, 1983. [fl97] p. fradet, d. le métayer. shape types. in proc. of popl ’97. pp. 27–39. acm, 1997. [gmm94] p. h. b. gardiner, c. e. martin, o. de moor. an algebraic construction of predicate transformers. sci. comput. program. 22(1-2):21–44, 1994. [gri03] g. griffing. composition-representative subsets. theory and applications of categories 11(19):420–437, 2003. [hpr06] a. habel, k.-h. pennemann, a. rensink. weakest preconditions for high-level programs. in proc. of icgt ’06. springer, 2006. lncs 4178. [kel82] g. m. kelly. basic concepts of enriched category theory. cambridge university press, 1982. [kmp02] m. koch, l. v. mancini, f. parisi-presicce. decidability of safety in graph-based models for access control. in proceedings of the 7th european symposium on research in computer security. pp. 229–243. springer, 2002. lncs 2502. [lv94] a. de luca, s. varricchio. well quasi-orders and regular languages. acta inf. 31(6):539–557, 1994. [ss05] v. sassone, p. sobociński. reactive systems over cospans. in lics. pp. 311–320. 2005. 13 / 13 volume 29 (2010) http://www.ti.inf.uni-due.de/publications/blume/invcheck.pdf introduction preliminaries category theory and recognizable graph languages orders on categories a generalization of the myhill-nerode theorem atomic cospans a decidable variant short example conclusions electronic communications of the easst volume 27 (2010) guest editors: klaus david, michael zapf managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 workshop über selbstorganisierende, adaptive, kontextsensitive verteilte systeme (saks 2010) assessment – ein ansatz zur evaluierung selbstorganisierender systeme jens tiemann, mikhail smirnov und tanja zseby 11 pages eceasst 2 / 11 volume 27 (2010) assessment – ein ansatz zur evaluierung selbstorganisierender systeme jens tiemann, mikhail smirnov und tanja zseby fraunhofer institut für offene kommunikationssystems (fokus), berlin abstract: selbstorganisierende systeme werden in der kommunikationstechnik als möglichkeit gesehen, die dienstqualität zu verbessern und gleichzeitig den administrationsaufwand zu senken. die eingesetzten selbstanpassenden algorithmen führen zu völlig neuen systemeigenschaften, die beim testen und der evaluation der leistungsfähigkeit dieser systeme berücksichtigt werden müssen. ausgehend von definitionen zu kontextsensitiven systemen und überlegungen zu schnittstellen zwischen der testumgebung und dem zu testenden system wird das neuartige, als assessment bezeichnete evaluationsverfahren vorgestellt. abschließend werden probleme bei der generierung von testfällen diskutiert und dabei neue, anstehende forschungsaufgaben skizziert. der ansatz soll zur diskussion einer systemtheorie dieser neuartigen systeme beitragen und ganz praktisch das vertrauen in die arbeit derartiger, hochgradig flexibler systeme stärken sowie deren zukünftigen einsatz fördern. keywords: selbstorganisation, selbstmanagement, selbstkonfiguration, selbstoptimierung, future internet, kommunikationssysteme, testen, evaluation 1 einleitung konzepte der selbstorganisation und des selbstmanagement werden für die anwendung in computersystemen und zur steuerung von kommunikations-infrastrukturen seit jahren erforscht. ihr einsatz wird in den nächsten jahren erwartet. wesentliche gründe für den einsatz dieser konzepte ist die hohe komplexität zur kontrolle dieser technischen systeme. auch besteht die erwartung, insgesamt den administrativen aufwand zu reduzieren (und damit die kosten zu senken), trotz des weiterhin starken leistungszuwachses von computerund kommunikationssystemen. es entstehen aber auch neuartige, komplexe anwendungen, z.b. im bereich opportunistic radio, die ohne den einsatz derartiger mechanismen nicht realisiert werden können. im bereich der kommunikationstechnik sind seit langem adaptive algorithmen bekannt, die allerdings vorprogrammiert jeweils nur in wenigen freiheitsgraden operieren. das autonome netzwerkmanagement verlangt jedoch die einbeziehung einer vielzahl von informationen – von der übertragungsqualität über die verfügbarkeit von ressourcen bis hin zu den anforderungen von nutzern – sowie eine möglichst umfangreiche konfiguration der netzkomponenten. die aufgaben des selbstmanagement in netzen lassen sich anhand des fcapsmodells (fault, configuration, accounting, performance, security) beschreiben, das sich mit den bekannten self-chop-prinzipien (configuration, healing, optimization, protection) des autonomic computing vergleichen lässt. in diesem beitrag wird ein ansatz zur evaluierung selbstorganisierender, selbstanpassender kommunikationssysteme (z.b. mobiltelefone, basisstationen, router) vorgestellt. damit assessment saks 2010 3 / 11 verbundene schwierigkeiten und lösungsansätze werden diskutiert – aufgrund von systemeigenschaften stellt schon die kopplung von zu testendem system und test-system sowie die initialisierung von tests eine schwierigkeit dar. die vorgeschlagene evaluierung soll dabei auf bisherigen tests aufbauen und neue systemeigenschaften adressieren. die als assessment bezeichnete methode wird kurz in einer darstellung des verfahrens skizziert, ein beispiel soll die methode illustrieren. der beitrag schließt mit einem vorschlag, wie die implementierung von einfachen beispielsystemen forciert werden kann. dabei entsteht eine umgebung, die eine reihe von realistischen situationen und aufgaben zur selbstorganisation für netzkomponenten präsentiert. 2 selbstorganisierende, kontextsensitive kommunikationssysteme obwohl noch viele fragen zur konkreten realisierung selbstorganisierender systeme offen sind, zeichnen sich doch gemeinsamkeiten beim systementwurf ab [mmj09][zkh08]: die systeme basieren • auf einem kognitiven zyklus (vergleichbar mit dem sense-think-act cycle als ansatz der klassischen künstlichen intelligenz), • auf der verarbeitung einer vielzahl von umgebungsinformationen oder kontext, • auf intern gesammeltem oder vorhandenem wissen sowie • auf der kooperation zwischen systemen. ein früher einsatz der prinzipien selbstorganisation und selbstmanagement wird im bereich des netzmanagements für den mobilfunk erwartet [soc][e3]. gründe hierfür sind die komplexität der management-aufgaben sowie die möglichkeit, selbstorganisation in verschiedenen gebieten und unter verschiedenen einsatzbedingungen einzuführen. optimierungsaufgaben können zunächst offline auf vorhandenen daten des konventionellen netzmanagements durchgeführt werden und erlauben danach (bei positiven erfahrungen mit den algorithmen) automatische verfahren, die auch in echtzeit laufen können. 2.1. verwendete definitionen zu systemen und testverfahren aufgrund des ziels dieser arbeit, selbstorganisierende systeme zu evaluieren, werden diese systeme anhand ihres umgangs mit kontext definiert [stc09]. selbstanpassende systeme (self-adaptive systems) erkennen für den betrieb notwendigen kontext und dessen relevante veränderungen rechtzeitig und passen ihr verhalten innerhalb einer begrenzten zeitspanne an. hierunter fallen auch systeme, die einen sehr großen satz von festen regeln enthalten. kognitive systeme (cognitive systems) sind selbstanpassende systeme, die zusätzlich in der lage sind, neuen relevanten kontext zu entdecken und neue verhaltensweisen zu entwickeln, z.b. durch lernen. darauf aufbauend sind ich-bewusste systeme (self-aware systems) definiert, die sowohl die relevanz von kontext, seine zeitige verarbeitung als auch die daraus abgeleiteten verhaltensweisen evaluieren können. derartige systeme spielen für diese arbeit zur evaluation noch keine rolle. kommunikationssysteme durchlaufen verschiedene tests, wie z.b. konformitätsund leistungsmessungen, die natürlich auch für selbstorganisierende systeme relevant sind. dabei ist das ergebnis eines konformitätstests abhängig von der spezifikation und der implementierung, während eine leistungsmessung zusätzlich von den aktuellen betriebsbedingungen abhängt, im folgenden auch situation genannt. beispielsweise kann der eceasst 4 / 11 volume 27 (2010) durchsatz eines kommunikationssystems von den auftretenden paketlängen abhängen. als erweiterung ist damit das ergebnis des assessments sowohl von spezifikation, implementierung und der situation abhängig, zusätzlich aber auch vom komplexen, internen zustand des zu testenden systems, z.b. dem erlernten wissen. 2.2. bestehende ansätze zum testen selbstorganisierender systeme erste ansätze zur evaluation stammen aus dem bereich autonomic computing. verglichen mit den tests im bereich autonomic communication ergeben sich gemeinsamkeiten beim ziel, die leistung von systemen zu bestimmen. es existieren einige ansätze zur beurteilung von autonomen systemen, die sich nur auf eine auswertung von leistungsmessungen beschränken. im besten fall werden diese metriken gruppiert, trotzdem ist meist nicht klar, ob die vorgestellten metriken vollständig und systematisch erhoben sind. auch werden interne und externe metriken sowie metriken verschiedener abstraktionsniveaus vermischt, was zu problemen bei der evaluation von realen systemen führen wird (z.b. fehlender zugriff auf interne ressourcen). brown et al. [bhh04] beschreiben einen ersten ansatz für den einsatz von benchmarkverfahren bei autonomen eigenschaften. das ziel ist die erstellung einer benchmark-suite für die self-chop-eigenschaften, um sowohl die einführung derartiger systeme zu fördern als auch den vergleich zwischen systemen zu ermöglichen. die vorgeschlagene methode basiert auf einer test-umgebung zur generierung von synthetischer last und auf dem einbringen von zusätzlichen änderungen (z.b. störungen oder änderungen an ressourcen). das ergebnis dieser evaluierung besteht aus der messung von systemantworten (z.b. reaktionszeit, qualität, kosten) und wird in einem kennzahlensystem präsentiert. als herausforderungen wird das einfügen der änderungen identifiziert, z.b. deren wiederholbarkeit oder ihre repräsentativität. das forschungsprojekt socrates entwickelte metriken, die zur beurteilung selbstorganisierender mobilfunk-netze geeignet sind [als08]: leistungsaspekte, abdeckung, kapazität, betriebswirtschaftliche aspekte wie investitionsaufwand (capex) und betriebsaufwand (opex), sowie zusätzliche, von den algorithmen abhängige metriken wie konvergenzzeit oder robustheit. ziel ist die bewertung des zugewinns durch die nutzung von neuen, selbstanpassenden algorithmen. die metriken werden anhand der systemaspekte gruppiert und im sinne einer leistung des systems mithilfe von benchmarks ermittelt. das gesamtergebnis wird aus einzelnen gruppen der erwähnten metriken und deren gewichtung ermittelt. die gewichtung kann dabei von dem geschäftsmodell beim einsatz der systeme abhängen, z.b. ob eher der preis oder die qualität von diensten im vordergrund steht. 3 assessment mit dem hier vorgestellten ansatz möchten wir auch die adaptierung zwischen tester und zu testendem system für kommunikationssysteme behandeln und die frage der wiederholbarkeit von tests adressieren. dabei soll es nicht um die messung einzelner oder gruppen von leistungsindikatoren gehen. vielmehr werden wir aus einer externen sichtweise ein „level of autonomicity“ [lsk06] ermitteln, aufgrund dessen die autonomie des systems und damit die möglichkeiten und grenzen des selbstmanagements von kommunikationssystemen vor deren einsatz abgeschätzt werden kann. dabei wird zu jeder zeit berücksichtigt, dass das system korrekt angepasst ist (process correctness [ddf06]), d.h. jeder anpassungsschritt muss die assessment saks 2010 5 / 11 korrekte funktion des systems erlauben. von vielen, kommerziell eingesetzten systemen und algorithmen liegt die innere struktur nicht offen, deshalb wird der ansatz des black-boxtestens gewählt. ein weiterer vorteil unseres testansatzes ist auch, dass die art des algorithmus keine rolle spielt und selbstorganisierende systeme mit konventionellen systemen auch auf dieser funktionsebene miteinander verglichen werden können. es wird nicht die lernfähigkeit evaluiert, sondern ausschließlich die fähigkeit, anwendungsbezogene probleme zu lösen. der vergleich mit der methode assessment center bei der auswahl von bewerbern bietet sich an: als möglicher teil dieser methode werden z.b. einem kandidaten verschiedene, zu lösende aufgaben präsentiert, und es kann sowohl sein vorgehen als auch das ergebnis bewertet werden. in dieser art von planspielen lassen sich mit vergleichsweise wenigen parametern bereits komplexe und repräsentative situationen erzeugen – insbesondere bei den kandidaten wird eine realistische problemlösungs-situation erzeugt. für die praktische evaluation von selbstanpassenden systemen, dem assessment-prozess, werden methoden aus der softwaretechnik und methoden zum testen von kommunikationssystemen kombiniert. wie im software-entwurf wird von anwendungsfällen (uc use cases) ausgegangen, aus denen testfälle (tc test cases) abgeleitet werden. diese testfälle bilden ein benchmark-verfahren, wie man sie ebenfalls aus der softwaretechnik kennt. vom testen von kommunikationsystemen übernehmen wir die methoden der generierung von testdatenverkehr und die beobachtung des systemverhaltens. 3.1. assessment-schnittstellen eines der hauptprobleme ist die vielzahl an informationen, die den entscheidungsprozess eines selbstorganisierenden, kontextsensitiven systems beeinflussen. die systemantwort eines lernenden systems ist nicht mehr in jedem fall einfach vorherzusagen und hängt auch von internen algorithmen und bereits gesammelten informationen ab. hilfreich ist hier auch für das testen und die evaluierung der einsatz eines systems zum kontextmanagement (context management system), über dessen schnittstellen die testumgebung und das zu testende system (sut – system under test) miteinander verbunden werden können. sut ft ftbt policies context management know-how ap ak ac speicher sut ftft ftftbtbt policiespolicies context management know-how ap ak ac speicher abbildung 1: schnittstellen für das assessment dabei kann das sut für einen einzelnen algorithmus, für ein teilsystem oder ein komplettes gerät stehen. in einem einfachen modell wird das system durch policies gesteuert eceasst 6 / 11 volume 27 (2010) (beispielsweise werden definierte frequenzbereiche zur nutzung freigegeben) und der einfluss auf das system kann über die schnittstelle ap kontrolliert werden. das system reagiert auf umgebungsbedingungen und nutzungsanforderungen in form von kontext, hier dargestellt durch die schnittstelle ac, und baut dabei intern einen komplexen systemzustand auf (beispielsweise das wissen, das ein lernender algorithmus ansammelt). da algorithmen und andere systeminterna unbekannt sein können, geht das assessment von dem black-boxtestansatz aus. das systemverhalten ist hochgradig von diesem internen systemzustand abhängig, daher ist eine schnittstelle nötig, mit der das zu testende system in definierte zustände gebracht werden kann (ak). hierüber kann das system initialisiert werden, und es wird überhaupt erst möglich, einen test effizient zu wiederholen. im fall von kontextsensitiven systemen muss die situation oder die umgebungsinformation nicht direkt an den sensoren erzeugt werden, sondern es können über das kontextmanagement auch künstliche kontextquellen als testgeneratoren eingebunden werden. hier wird, wie beim testen von kommunikationssystemen, zwischen vordergrundtestern (ft) und hintergrundtestern (bt) unterschieden. das zu testende system interagiert mit den komplexeren vordergrundtestern, d.h. es beeinflusst durch seine reaktion wiederum den tester, während die einfacher aufgebauten hintergrundtester sich hiervon nicht beeinflussen lassen und eingesetzt werden, um eine grundlast zu erzeugen. bei kontextsensitiven systemen kann auf die tatsächliche generierung von datenströmen verzichtet werden, wenn sich mittels des kontextmanagements die zu untersuchenden algorithmen eines systems von sensoren und anderen kontextquellen isolieren lassen. auf diese weise lassen sich wesentlich einfacher sehr komplexe situationen generieren, da man mittels des kontextmanagements quasi interne schnittstellen eines systems zum testen nutzen kann. beispielweise könnte ein interner monitor zur analyse des datenverkehrs durch einen test-generator ersetzt werden, der (test-)verkehrsströme als schon ausgewertete information anbietet. da auch die generierung von testdatenströmen auf dieser abstrakten beschreibung von verkehrsströmen basiert, lässt sich eine aufwändige erzeugung von tatsächlichem datenverkehr vermeiden. 3.2. assessment-prozess beim assessment-prozess [e3d23] wird von den anwendungsfällen (uc) ausgegangen, die auch der implementierung des zu testenden systems zugrunde liegen. uc tc leistungsmonitor situationsgenerator sut zustandsspeicher (implementierung) ergebnis = σ abbildung 2: assessment-prozess assessment saks 2010 7 / 11 zur erstellung der testfälle (tc) werden den anwendungsfällen angaben zum kontext und dem erwarteten systemverhalten entnommen. im idealfall sind diese direkt verknüpft mit einer metrik und grenzwerten zur erwarteten leistungsfähigkeit des systems. die testfälle stellen situationen oder zu lösende probleme dar. über die schnittstelle ak wird das system für die jeweiligen tests aus einem externen speicher für systemzustände vor einem neuen testfall ggf. initialisiert. die testfälle selber werden von kontextoder situationsgeneratoren erzeugt und mehrfach durchlaufen, da sich ein selbstorganisierendes system mithilfe eines selbstanpassenden algorithmus im laufe des betrieb verändern kann, d.h. es wird die anpassung des sut an eine situation ermöglicht. das verhalten des systems wird über normale messungen der leistungsfähigkeit aufgenommen (z.b. der durchsatz für einen bestimmten dienst in einer definierten qualität). die leistung des systems kann dabei über einfache metriken bestimmt werden oder aus schon vorverarbeiteten werten bestehen, wie sie key performance indicator (kpi) bieten. die ergebnisse für einen testfall werden gesammelt, und eine aufgabe gilt als gelöst, wenn mindestens 50% der läufe erfolgreich waren. ein solcher testfall kann auch als benchmark gesehen werden, der eine aufgabe einer definierten schwierigkeit enthält. das system wird abschließend mit dem höchsten schwierigkeitsgrad einer reihe von benchmarks bewertet, die das system lösen konnte. 3.3. assessment-beispiel mit diesem beispiel soll der assessment-prozess illustriert werden. dabei kommen sowohl demo-algorithmen als auch demo-testfälle zum einsatz, deren konstruktion den assessment-vorgang deutlich sichtbar macht. eine implementierung des assessmentverfahrens für reale systeme befindet sich in der entwicklung. in diesem beispiel soll ein teilsystem untersucht und evaluiert werden, das die selbständige kanal-zuweisung für eine basisstation oder einen wlan-zugangspunkt ermöglicht. dabei kommt es darauf an, dass der gleiche kanal nicht zweimal in benachbarten zellen des typischen „7-zellen“-musters genutzt wird. in diesem stark vereinfachten beispiel wird also eine umgebung oder situation erzeugt, in der 6 zellen jeweils einen kanal nutzen. das zu testende system soll nun mit seinem implementierten algorithmus einen weiteren kanal im zentrum auswählen. in diesem beispiel werden drei demo-fälle mit steigender schwierigkeit verwendet: • „umfangreiche ressourcen“ – es sind 50 kanäle verfügbar, damit wird auch eine zufällige auswahl eines kanals durch die sut in vielen fällen erfolgreich sein. • „knappe ressourcen“ – es sind genau 7 kanäle verfügbar, der nicht belegte kanal muss also von dem sut per messung bestimmt und ausgewählt werden. • „störer“ – es sind 9 kanäle verfügbar, allerdings springt eine zelle bei der kanalnutzung zwischen kanal 6, 7 und 8. damit muss das verhalten des störers in der nachbarschaft von dem sut „gelernt“ werden, um erfolgreich einen kanal zu wählen. die drei verwendeten demo-implementierungen des algorithmus zur kanalauswahl sind damit: • „random“ – zufällige auswahl eines kanals; • „sense“ – die kanalnutzung in der umgebung wird einmal zu beginn gemessen und ein ungenutzter kanal wird ausgewählt; eceasst 8 / 11 volume 27 (2010) • „learn“ – die wahrscheinlichkeit der kanalnutzung der nachbarn wird durch fortlaufende messungen bestimmt, der kanal mit der geringsten nutzungswahrscheinlichkeit wird ausgewählt. nun werden die drei algorithmen den drei demo-situationen ausgesetzt. bei jeweils mehreren läufen wird eine deutliche differenzierung in bezug auf die problemlösefähigkeit der algorithmen erwartet. der algorithmus „random“ kann nur als funktionstest gesehen werden, bei umfangreich verfügbaren ressourcen genügt er allerdings einfachen ansprüchen. wird tatsächlich durch das sut die kanalauswahl in der nachbarschaft gemessen, so ermöglicht der algorithmus „sense“ eine kanalauswahl in einer statischen umgebung. erst der algorithmus „learn“ erlaubt auch eine anpassung an dynamische und damit komplexere umgebungen und situationen. sut “rand” interner zustand von sut “learn” p(ch_used) interferenz: �� fail übersicht zum ablauf der evaluation ergebnis des assessment � vergleich bezeichner für sut sut “sense” sut “learn” sut “rand” interner zustand von sut “learn” p(ch_used) interferenz: �� fail übersicht zum ablauf der evaluation ergebnis des assessment � vergleich bezeichner für sut sut “sense” sut “learn” abbildung 3: assessment-beispiel die abbildung zeigt die durchführung und das ergebnis des assessments für die drei demoimplementierungen unter einsatz der drei demo-testfälle. auf der linken seite werden die umgebungen der sut dargestellt, die jeweils die kanalauswahl in der mitte des zellenmusters vornehmen müssen. wählt der algorithmus einen schon vorhandenen kanal aus (interferenz), so gilt dieser test-lauf als nicht bestanden. im fall des „lernenden“ algorithmus‘ wird auch der interne zustand des sut dargestellt. im abgebildeten beispiel wurden jeweils 100 läufe pro testfall durchgeführt, bei mehr als 50 erfolgreichen läufen gilt ein einzelner testfall als bestanden und der nächste, schwierigere wird ausgeführt. das ergebnis ist hier eine vergleichende darstellung der evaluierten algorithmen (oben rechts im bild). assessment saks 2010 9 / 11 4 generierung komplexer situationen ein wesentlicher bestandteil des assessment-verfahrens ist die erstellung von testfällen oder benchmarks, die verschiedene und definierte schwierigkeitsgrade bei der problemlösung abdecken müssen. neben der problembeschreibung spielt auch die erwartete leistung des systems eine rolle: von dem besseren system wird schneller eine lösung des problems angeboten. im einfachsten fall stellen experten diese benchmarks zusammen und orientieren sich dabei an bisherigen, konventionellen einsatzgebieten und der leistungsfähigkeit verfügbarer systeme. allerdings kann die ordnung von aufgaben im bereich mittlerer schwierigkeiten probleme bereiten. bei diesen benchmarks könnte die schwierigkeit auf andere größen zurückgeführt werden, wie z.b. die komplexität (einer aufgabe oder situation). sehr schwierige benchmarks lassen sich an theoretischen maximalwerten orientieren (z.b. die maximal mögliche auslastung von ressourcen), während sehr leichte benchmarks eher die rolle von funktionstests übernehmen (im sinne der process correctness). eine andere möglichkeit zur ordnung von benchmarks ist eine reihe von implementierungen, die über die ausführung verschiedener benchmarks miteinander verglichen werden können. ähnlich dem intelligenztest für menschen kann bei hinreichend vielen verfügbaren und vergleichbaren implementierungen (eingeschränkt auf einen speziellen anwendungsbereich) eine statistische aussage zu einzelnen aspekten der fähigkeiten eines systems gemacht werden, basierend auf latenten, nicht direkt messbaren variablen. hierbei ergibt sich eine relative aussage zur schwierigkeit von benchmarks und den fähigkeiten von algorithmen und systemen. dies ist für einen vergleich von systemen im sinne der erwarteten leistungsfähigkeit ausreichend. um sowohl implementierte systeme zur verfügung zu haben als auch realistische, komplexe situationen analysieren zu können, eignet sich auch ein wettbewerb ähnlich dem robocup (turnier für roboter-fußball). dabei wird davon ausgegangen, dass schon eine geringe anzahl von regeln, umgebungsvariablen und implementierter funktionalität ausreicht, um komplexe situationen zu erzeugen, insbesondere in der interaktion verschiedener systeme untereinander und mit ihrer umgebung. im bereich der kommunikationstechnik bieten sich dabei aufgaben an, bei denen qualitativ hochwertige kommunikationsdienste auf einem netz mit beschränkten ressourcen angeboten werden: dabei müssen die verschiedenen systeme um die gleichen ressourcen konkurrieren und damit auch interagieren. verschiedene schwierigkeitsgrade lassen sich über die netztopologie (z.b. anordnung und mobilität von netzknoten, heterogene verbindungen) und den dienste-mix erreichen. ein solcher wettbewerb kann als simulation oder mit vereinfachten realen systemen durchgeführt werden. ein schlüssel ist hier wieder die verwendung eines gemeinsamen systems zum kontextmanagement. trotz der vereinfachten bedingungen wird erwartet, dass das assessment-verfahren auf diese weise überprüft und verfeinert werden kann. auch trägt ein solcher wettbewerb insgesamt zum besseren verständnis von selbstorganisierenden kommunikationssystemen bei. eceasst 10 / 11 volume 27 (2010) 5 zusammenfassung und ausblick zum vollständigen verständnis von komplexen systemen und deren entwurf gehören das testen und die bestimmung der leistungsfähigkeit. selbstorganisierende, selbstanpassende systeme erfordern allerdings eine zusätzliche evaluation im zusammenhang mit ihrer anpassungsfähigkeit: inwieweit ist ein system in der lage, spezifische probleme innerhalb seines einsatzgebietes zu lösen? da der betrieb dieser systeme auf einer vielzahl von informationen (kontext) und dem angesammelten, internen wissen beruht, sind zum testen und zur evaluierung besondere mechanismen nötig. die vollständige evaluation eines selbstorganisierenden kommunikationssystems muss über bisher verwendete ansätze, wie das testen der konformität oder die messung der leistungsfähigkeit, hinausgehen. insbesondere muss es eine neue systemeigenschaft erfassen – die anpassung an die betriebsumgebung und -bedingungen. diese verborgene eigenschaft kann nicht direkt gemessen werden, sondern wird aus leistungsmessungen abgeleitet. die vorgestellte methode des assessments geht dabei von einer eindeutigen, externen sichtweise auf das zu testende system aus. die vorgeschlagene evaluationsmethode, das assessment, beruht auf der durchführung einer reihe von benchmark-tests, die nach der schwierigkeit des zu lösenden problems sortiert sind. durch diese methode wird die bestimmung der anpassungsfähigkeit auf die fähigkeit zur problemlösung in verschieden komplexen situationen abgebildet. die komplexität einer aufgabe zu bestimmen ist allerdings nicht einfach – sie kann zunächst durch experten eingeschätzt werden und sich auch an theoretischen grenzen orientieren. besser wäre eine automatische ableitung der benchmarks, z.b. indem beobachtet wird, wie selbstorganisierende systeme mit anderen systemen und einer mehr oder weniger komplexen einsatzumgebung interagieren. das ziel der arbeiten ist die entwicklung von beispielhaften, anerkannten testsuiten zum vergleich der leistungsfähigkeit selbstorganisierender systeme, die dann eine zertifizierung dieser neuen systemeigenschaften ermöglicht. danksagung diese arbeiten wurden teilweise im 7. eu-forschungsrahmenprogramm innerhalb des projekts e3 (end-to-end efficiency) durchgeführt. dieser beitrag stellt nur die sichtweise der autoren dar, die gemeinschaft kann für jegliche verwendung der hierin enthaltenen informationen nicht haftbar gemacht werden. die autoren danken für den kollegialen austausch innerhalb des e3-konsortiums. assessment saks 2010 11 / 11 literatur [als08] m. amirijoo, r. litjens, k. spaey, m. döttling, t. jansen, n. scully and u. türke: "use cases, requirements and assessment criteria for future selforganising radio access networks", iwsos 2008, vienna, austria, december 10-12, 2008 [bhh04] a. b. brown, j. hellerstein, m. hogstrom, t. lau, s. lightstone, p. shum and m. peterson yost, "benchmarking autonomic capabilities: promises and pitfalls", first international conference on autonomic computing (icac'04), pp. 266-267, 2004 [ddf06] s. dobson, s. denazis, a. fernández, d. gaïti, e. gelenbe, f. massacci, p. nixon, f. saffre, n. schmidt and f. zambonelli, "a survey of autonomic communications," acm trans. auton. adapt. syst. 1, 2 (dec. 2006), pp. 223259 [e3] projektseite “e3 – end-to-end efficiency”, https://ict-e3.eu/ [e3d23] project e3 deliverable d2.3, “architecture, information model and reference points, assessment framework, platform independent programmable interfaces”, september 2009 [lsk06] d. lewis, d. o'sullivan and j. keeney, "towards the knowledge-driven benchmarking of autonomic communications," in proceedings of the 2006 international symposium on on world of wireless, mobile and multimedia networks (june 26 29, 2006). international workshop on wireless mobile multimedia. ieee computer society, washington, dc, usa [mmj09] a. marikar, j. mödecker, k. jonas, “selbstverwaltung im future internet”, electronic communications of the easst, volume 17: kommunikation in verteilten systemen 2009 [tt09] s. taranu and j. tiemann, "general method for testing context aware applications," in proceedings of the 6th international workshop on managing ubiquitous communications and services (barcelona, spain, june 15 2009). mucs '09. acm, new york, ny, usa [soc] projektseite “socrates self-optimisation & self-configuration in wireless networks”, http://www.fp7-socrates.org/ [stc09] m. smirnov, j. tiemann, r. chaparadza, y. rebahi, et al.: "demystifying selfawareness of autonomic systems", ict-mobilesummit 2009. conference proceedings, 10-12 june 2009, santander, spain, iimc, dublin, ireland, isbn: 978-1-905824-12-0 9 [zkh08] t. zseby, m. kleis, t. hirsch, „the internet of the future: challenges, approaches and obstacles“, telekommunikation aktuell, vol.62 (2008), no. 5-6, pp. 1-19, erlangen, germany towards a conceptual framework supporting model compilability electronic communications of the easst volume 36 (2010) proceedings of the workshop on ocl and textual modelling (ocl 2010) towards a conceptual framework supporting model compilability dan chiorean, vladiela petraşcu 14 pages guest editors: jordi cabot, tony clark, manuel clavel, martin gogolla managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst towards a conceptual framework supporting model compilability dan chiorean1, vladiela petraşcu2 1chiorean@cs.ubbcluj.ro 2vladi@cs.ubbcluj.ro faculty of mathematics and computer science, computer science department babeş-bolyai university, cluj-napoca, romania abstract: the ever-growing use of modeling languages today is largely due to a maturation of model-based development technologies. however, there is enough room for improving language specifications and consequently, the efficiency of their usage. the state of facts in specifying well formedness rules is among the most important issues calling for improvements. despite the fact that various papers have approached it, the topic is still open. to solve it, there is the need of a rigorous conceptual framework supporting the specification of modeling languages’ static semantics. this would stand as a basis for ensuring model compilability, a mandatory requirement in a model-driven context. through this paper, we aim at providing core ideas that would contribute to the creation of such a framework. our approach is testing-oriented and promotes the use of ocl specification patterns. keywords: model compilability, metamodel, wfrs, static semantics, mof, uml 1 introduction the value of both correctness and completeness in a language specification is widely acknowledged. a poor language definition negatively impacts every model employing the language in question. the emergence of the model-driven paradigm1 is grounded on significant changes in the model usage requirements, triggering counterparts in the area of modeling languages and technologies. these concern an increased rigor of language definitions, accompanied by an alignment of technologies to the specifics of the model-driven development process. the automation goals envisioned by the aforementioned paradigm call for appropriate tools. in a model-driven context, models are equally used as inputs and outputs of such tools. this places two critical requirements on them: (1) being defined in rigorous languages supporting their efficient manipulation, and (2) being fully compliant to (correct with respect to) those languages. well formedess rules (wfrs) play a key role in ensuring the completeness and rigor of a language definition and stand as a basis for assessing the correctness of models with respect to it. researches in the field have revealed that modeling and programming languages share more commonalities than differences [csw08]. the differences are mainly related to a higher abstraction level employed by modeling languages, as well as to the common use of graphical 1 this paradigm comes in various flavors, such as mda (model driven architecture), mde (model driven engineering), mdd (model driven development) or ldd (language driven development). 1 / 14 volume 36 (2010) mailto:chiorean@cs.ubbcluj.ro mailto:vladi@cs.ubbcluj.ro towards a conceptual framework supporting model compilability formalisms for representing their concrete syntax. the graphical formalism though is exclusively meant to support understandability, as all model processing tasks (serialization included) employ a textual syntax representation. moreover, nowadays there are experts promoting the use of a textual concrete syntax even for model specification2 [ss08], [fk]. acknowledging the truth that the graphical and textual concrete syntaxes are equivalent, that modeling and programming languages are closely similar, assists in accepting the fact that, similar to program compilability, full compliance of a model with its modeling language is a must. models that conform to their modeling language’s wfrs are generally referred to as well formed models in the literature. however, we propose using the phrase compilable models instead of well formed models. the arguments are twofold. on the one side, aparts from wfrs, there may be other kinds of rules that a model has to comply with, such as methodological rules, metric rules, or business rules. a well formed model should designate a model complying with any of these rules, which is a generic requirement compared to mere compilability. on the other side, the newly proposed phrase stresses on the similarity among modeling and programming languages, hence on the imperative nature of the compilability requirement. therefore, regardless of their size, models’ compilability is a must if we want them manipulated by tools. while in case of small (didactical) ones, checks may even be manually performed, in case of medium-sized to large models the existence of appropriate verification instruments becomes a mandatory requirement. the fact that models, at their turn, will generally be complemented by assertions denoting different kinds of business rules is just another argument for requiring enforcement of model compilability. an uncompilable model may trigger failures in the compilation of its own assertions 3. despite all these arguments, current practice shows that model compilability is more a goal than a reality. this state of facts has both human and technological roots. on the one side, there is the unfortunate assumption that seems to be still governing the developers’ community (worse, even the researchers’ one), according to which models are primarily meant to facilitate problem understanding and assist the client-developer communication, a rigorous model verification not being therefore an imperative. on the other, there are the shortcomings concerning the formalisms and tools involved in compilability assessments. the current paper aims at identifying the reasons underneath this state of facts, with the intention of proposing solutions meant to improve it. the rest of the paper is organized as follows. section 2 diagnoses the state of facts in the field of model compilability, and summarizes our contribution as compared to related approaches. the principles that we propose at the basis of a conceptual framework meant to support an accurate specification of modeling languages’ static semantics (a prerequisite in enforcing model compilability) are explained in section 3. a proof of concepts is provided in section 4, by means of two relevant examples of uml wfrs. the paper ends with conclusions and hints on future work in section 5. 2 however, even in this case, the language used for model representation is complemented by a second language, targeted at model navigation and specification of constraints. 3 as an example, the existence of several equally named properties in a class will make an ocl expression referring to any of these properties uncompilable. proc. ocl 2010 2 / 14 eceasst 2 model compilability reality and goals 2.1 diagnosing the state of facts as previously pointed out, there is a strong technological factor involved in what causes the current state of facts in the field of model compilability. as a proof, we cite two recent references arguing the behavior of a few uml2 tools and of argouml when required to perform model validation. in a posting entitled “poor validation of uml models in eclipse uml2 tools” [por], the author analyzes the failure reasons of an xmi transformation service, concluding that the failure has been caused by the use of an eclipse uml2 not well-formed model. in [bf09], the authors report on identifying “counter examples” of uml models (models breaking well-formedness rules) that were not catched by the argouml tool. the former reference highlights the fact that the eclipse uml2 tools under study enable the creation of uncompilable uml2 models, while the latter raises a warning with respect to the proper translation of wfrs into java. in addition, [por] reveals the fact that the tools under study fail to implement the entire set of wfrs. however, the problems with the aforementioned uml tools are only the visible tip of the iceberg. in fact, these problems are rooted in the absence of a general consensus within the modeling community with respect to the necessity and means of using constraints. consequently, the real, “hidden” issues are related to the inadequate specification, deficient validation, and poor understanding of constraints and their usage. this statement is motivated by a detailed analysis concerning the specification and use of constraints within uml and some of the best known meta-metamodels (mof [omg06], ecore [sbpm08], and xcore [csw08]). unfortunately, a number of specification errors reported for the uml 1.x wfrs ([rg00], [ccbc04]) have not been fixed yet, being further inherited by the mof 2.0 and uml 2.x documents. these problems have significantly affected the possibility of checking models’ compilability, and have even compromised the concept of model compilability itself. 2.2 related work through the last decade, a significant number of papers focusing on the specification and usage of wfrs have been written. we claim that [rg00], [fql+03] and [ccbc04] are the closest to the approach presented in this paper. thus, we briefly summarize their contents in the following. in [rg00], the authors have given a first quasi-exhaustive analysis of the wfrs specified in uml 1.3. the work has focused on the foundation::core package (31 classes and 27 associations) that has been specified in use, in order to check the corresponding 43 wfrs. also, 28 additional operations were tested. errors have been found in 39 out of 71 tested expressions. four categories of errors have been identified: syntax errors, minor inconsistencies, type checking errors, and general problems. the paper was the first to draw an alarm with respect to the quality of the uml wfrs specifications. the following statement worth mentioned: “for future work we plan to extend the analysis to the complete uml metamodel including all of its wellformedness rules and making it available in use. this might not only be usefull for improving the state of the standard but also implies another very nice application: in principle, any uml model can be checked for conformance to the uml standard. ” 3 / 14 volume 36 (2010) towards a conceptual framework supporting model compilability in [fql+03], the second published paper on this topic, the authors claim having tested the entire set of wfrs specified in the context of the uml 1.3 metamodel. they report 450 errors of three kinds: non-accessible elements, empty names, and miscellanea. the proposed solutions for fixing the reported problems seem a bit bizarre. namely, they suggest to “take the empty names into account in every rule of the metamodel (296 errors). consider access and contents as two different concepts (138 errors). avoid two opposite association ends with the same name (18 errors)”. in [ccbc04], the authors analyze different kinds of errors and propose new specifications to fix the identified bugs. as the title suggests, the focus is on proposing “good practices” meant to support “a correct, clear and efficient specification”. the consistency among the formal and informal specifications, the clearness of ocl expressions, the fact that evaluating ocl specifications instead of only compiling them is imperative, are among the proposed and exemplified practices. 2.3 setting the goals as shown in the previous subsection, there are various papers signaling the inadequacy of uml wfrs specifications. however, most of the reported work has focused on the uncompilability of wfrs with respect to ocl. still, a closer look at the standard specifications (both wfrs and additional operations (aos)) reveals that, apart from compilability issues, the specifications in question enclose logical errors, as well as drawbacks caused by their superficial testing4. in this context, the current paper aims at contributing to the set up of a framework supporting an accurate definition of the static semantics of modeling languages and enabling efficient model compilability checks. the topics addressed outrun those concerning the mere compilability of ocl wfrs, being closer to the conceptual issues involved in specifying a static semantics. namely, we focus on the difference between wfrs and “classical invariants” and the importance of choosing an appropriate specification context, test-driven specifications, testing-oriented specifications and the use of ocl specification patterns. the experience aquired while working at and with the uml 1.5 wfrs in ocle [lci] has allowed us to conclude that the task of creating an efficient ocl specification for the static semantics of an uml metamodel is not an easy one, even for specialists. this may explain the previously reported state of facts in the field. therefore, explaining the basics of the specification approach that we promote and arguing it by means of selective examples, is believed to provide greater benefits than merely depicting the complete, final set of wfrs. moreover, the chosen examples (one related to the semantics of composition, and the other to the name uniqueness constraint within namespaces) have not been randomly picked; they are both well known, core metamodeling issues. the fact that even their corresponding specifications are bogus is a strong argument towards the adoption of a rigorous wfrs specification framework, as promoted by this paper. 4 the information outputed in case of an invariant violation is insufficient for error diagnosis. proc. ocl 2010 4 / 14 eceasst 3 requirements of a static semantics specification compilability of a model is checked against its metamodel and associated wfrs; the metamodel defines the abstract syntax of the modeling language, while the wfrs enclose its static semantics. in order to fully serve its intended purpose of supporting efficient model compilability checks, there are a number of requirements that any set of wfrs should comply with. the first one is completeness; the wfrs should entirely cover the static semantics rules of the language. this entails an intimate understanding of all metamodel-level concepts and how they may be suitably related. furthermore, each wfr specification should fulfill some quality criteria. the following three are among the most important, the first two being also among the least addressed in the literature. 1. detailed, test-driven informal specification. preceding the formal wfr expression with a detailed and rigorous informal equivalent is the basic requirement for ensuring correct understandability of the rule. at its turn, the informal specification should be based on meaningful test snapshots needed for its validation (both positive and negative). by analogy to the programming approach known as test-driven development, this test-driven specification approach provides for a deeper reasoning with respect to the rules, with a positive effect on the correctness/comprehensiveness of their final statements. in fact, all good programming habits remain valid in the design of sizable ocl specifications. 2. testing-oriented formal specification. the ocl wfrs should be stated so as to facilitate efficient error diagnosis in case of assertion failure. in this respect, [cpo10] argues on the use of several testing-oriented ocl specification patterns. this quality requirement comes from acknowledging the ultimate purpose of models and assertions within a model-driven development process. 3. correct and efficient formal specification. the correctness of an ocl wfr encompasses two different aspects: correctness with respect to its informal equivalent, as well as correctness with respect to the language specification. the former asks for a full conformance between the ocl specifications and their natural language counterparts; the latter enforces compilability, therefore conformance to the ocl standard. another aspect to consider when specifying wfrs refers to choosing the most appropriate context and shape for each. this involves understanding the differences between a wfr and a “classical invariant”, as introduced by object oriented programming (oop) techniques. specifically, in oop, the semantics of invariants states that the invariant of a class should refer exclusively to relationships between the values of its attributes [mey97],[mo94]. in case the type of the attribute is a reference or a collection of references, the invariant is only allowed to constrain their existence and cardinality, being denied any access to the state of the objects attached to the references. this comes from the fact that objects should be autonomous and have exclusive control over their state. when specifying wfrs however, this rule is seldom obeyed. generally, the invariant corresponding to a wfr refers to the state of the objects that are accessible by navigation starting from the contextual instance self. this semantic difference among wfrs and the “classical” oop invariants influences the choice of their specification context, their complexity and evaluation. 5 / 14 volume 36 (2010) towards a conceptual framework supporting model compilability 4 proof of concepts this section is aimed at offering a proof of concepts by means of two case studies centered around two relevant constraints for uml: one related to composition, and the other to name clashes within namespaces. the first case study reveals the incompleteness of the wfrs set enclosing the semantics of composition in both uml 1.x and 2.x, and emphasizes some inconsistencies among the informal statements and the ocl wfrs related to composition in uml 2.x. the proposed solutions stem from an analysis supported by the use of the test-driven specification principle. the possibility of expressing the same informal constraint in different contexts and under different shapes, as well as the criteria involved in choosing the right ones are also discussed and exemplified here. the second case study uncovers three types of errors within the wfr and aos prohibiting name clashes within namespaces: syntactic errors, logical ones, as well as faults coming from failure to provide the information required for error diagnosis in case the assertion gets violated. the solution proposed for the latter case involves the use of an appropriate ocl specification pattern. to sum up, the considered case studies cover all aspects discussed in the previous section. moreover, apart from proving our point, the solutions offered contribute to improving the static semantics of the uml 1.x and 2.x metamodels. 4.1 on the uml composition relationship let us consider the uml composition relationship. as inferable from the omg documents ([omg05], [omg10]) and papers such as [bhb+01], composition is a stronger form of association, whose semantics may be captured by the following constraints: [c1]. only binary associations can be compositions. [c2]. at most one end of an association may specify composition (a container cannot be itself contained by a part). [c3]. an association end specifying composition must have an upper multiplicity bound less or equal to one (a part is included in at most one composite at a time). [c4]. since the composite has sole responsibility for the disposition of its parts, the parts should be accessible starting from the container (navigation from container to parts should be enforced). the above mentioned rules are equally important in defining the semantics of composition and should be all formalized at the metamodel level by means of appropriate wfrs. in accordance with the test-driven specification principle, let us consider the example models from figure 1. the first (from top to bottom) is correct with respect to the semantics of compostion, as expressed by constraints [c1] to [c4]. the last two are both wrong; the second breaks the [c3] constraint (having an upper bound of 2 on the composition end), while the third violates the navigability constraint [c4] (allowing exclusively a part-to-container navigability). proc. ocl 2010 6 / 14 eceasst figure 1: sample models involving composition as shown in figure 2, in uml 1.x, an association is defined by its two associationends. composition can be specified by setting the aggregation enumeration attribute of associationend to #composite5. figure 2: uml 1.4 metamodel excerpt illustrating associations with respect to enforcing the composition semantic rules [c1] to [c4], the specification only covers the first three of them. the ocl wfrs for [c1] and [c2] are stated in the context of association, while the one for [c3] is written in the context of associationend, as follows: self.aggregation = #composite implies self.multiplicity.max = 1 listing 1: the uml 1.4 wfr for c3 the navigability constraint [c4] is missing from the uml 1.x specification, therefore the third sample model of figure 1, although incorrect, would be reported as compilable. there are at least three different ways of writing this missing wfr in ocl, as shown below. favoring one over another is a decision that depends on both language semantics and available tool facilities. context associationend inv validcompositionnavigability1: self.aggregation = #composite implies self.association.connection->any(ae | ae <> self).isnavigable context associationend inv validcompositionnavigability2: 5 for denoting enumeration type values, we kept the notation used in the uml 1.4 specification (#enumerationliteral), instead of classifier::enumerationliteral, as used in uml 2.x. 7 / 14 volume 36 (2010) towards a conceptual framework supporting model compilability self.association.connection->exists(ae | ae <> self and ae.aggregation = #composite) implies self.isnavigable context association inv validcompositionnavigability3: self.connection->exists(ae | ae.aggregation = #composite) implies self.connection->any(ae | ae.aggregation <> #composite).isnavigable listing 2: proposed wfr expressions for c4 in mof and uml 1.x the first two invariants from listing 2 are both written in the context of associationend. if we were to judge from a classic invariants perspective, the second is better, since, in case of assertion failure, the objects which own the slot whose value has caused the failure (isnavigable) would be the ones reported as guilty. the first wfr reports the opposite ends. nevertheless, with the aid of an ocl-supporting tool that allows the evaluation of subexpressions (such as [lci]), the other ends can be easily accessed. the third invariant is written in the context of the association metaclass. this specification is the only one fully complying with the uml 1.x composition semantics, stating that the ends of a composition association are both created and destroyed simultaneously with their owning association. according to this, the wfr in listing 1 can be itself rephrased in the association context as follows. context association inv validcompositionupperbound: self.connection->exists(ae | ae.aggregation = #composite) implies self.connection->any(ae | ae.aggregation = #composite).multiplicity.max = 1 listing 3: proposed wfr for c3 in mof and uml 1.x the wfr from listing 3 and the last wfr from listing 2 may also be combined within a single ocl expression, as shown below. however, this has the disadvantage of requiring partial evaluation in case of assertion failure, so as to identify precisely which expression in the conjunction has caused the failure. context association inv validcompositionupperandnavigability: self.connection->exists(ae | ae.aggregation = #composite) implies ( self.connection->any(ae | ae.aggregation = #composite).multiplicity.max = 1 and self.connection->any(ae | ae.aggregation <> #composite).isnavigable ) listing 4: proposed wfr covering both c3 and c4 in mof and uml 1.x as illustrated by figure 3, the uml 2.x infrastructure brings some changes in the definition of associations, changes that are also reflected in the mof 2.0 specification. at the core of these changes stands the removal of the associationend metaclass, and its replacement with propety, “... associated with an association via memberend attribute” [omg06] (pp. 66). regarding navigability, [omg10] (pp. 112) states that: “an end property of an association that is owned by an end class or that is a navigable owned end of the association indicates that the association is navigable from the opposite ends, otherwise the association is not navigable from the opposite ends.” unfortunately, concerning the semantics of composition, things seem to have worsened compared to the 1.x specifications. from those four constraints expressing the semantics of composition stated at the beginning of this section, only [c1] has a correct ocl equivalent within proc. ocl 2010 8 / 14 eceasst figure 3: mof 2.0 and uml 2.3 metamodel excerpt the specification documents. as for the others, [c4] seems to be missing, [c3] has a drawback that we will detail in the following, and [c2] appears in the mof 2.0 specification rather as an informal precondition of the create operation from the reflection::factory package. regarding composition, [omg10] (pp. 113) states that “composition is represented by the iscomposite attribute on the part end of the association being set to true”. given the fact that the word composite has a similar meaning to container, the previous statement is totally counter-intuitive. it basically reads as a part in a composition is a composite/container. in this respect, the omg specifications should adopt a solution inspired by the emf ecore implementation, which has introduced the attributes container and containment with their natural interpretation. overpassing the language ambiguity problem, the ocl wfr corresponding to constraint [c3] found in [omg10] (pp.125) in the context of property iscomposite implies (upperbound()->isempty() or upperbound() <= 1) contradicts the above cited specification statement. if iscomposite is true, then (in accordance with the above) the property plays the role of a part in a composition. thus, this ocl expression constrains the upper bound of the part, instead of constraining the upper bound of its container. given the conflicting situation, we assume the textual statement at pp. 113 of [omg10], although counter-intuitive, as being the intended one. in tis context, in the following we propose 9 / 14 volume 36 (2010) towards a conceptual framework supporting model compilability appropriate ocl wfrs for each of the constraints [c2] to [c4]. the natural context for [c2] is represented by the association metaclass. its corresponding ocl invariant is given below. context association inv atmostonecompositeend: self.memberend->select(p | p.iscomposite)->size() <= 1 listing 5: proposed wfr for c2 in mof and uml 2.x the rules [c3] and [c4] can be stated both in context of association and property, as shown in listing 6 and listing 7. context association inv validcompositionmultiplicity1: self.memberend->exists(p | p.iscomposite) implies self.memberend->any(p | not p.iscomposite).upper = 1 context property inv validcompositionmultiplicity2: self.iscomposite and self.association->notempty() implies self.association->any(p | p <> self).upper = 1 listing 6: proposed wfrs for c3 in mof and uml 2.x context association inv validcompositionnavigability1: self.memberend->exists(p | p.iscomposite) implies self.memberend->any(p | p.iscomposite).isnavigable() context property def: isnavigable() : boolean = (self.class->notempty()) xor (self.owningassociation->notempty() and self.owningassociation.navigableownedend->includes(self)) context property inv validcompositionnavigability2: self.iscomposite and self.owningassociation->notempty() implies self.owningassociation.navigableownedend->includes(self) listing 7: proposed wfrs for c4 in mof and uml 2.x 4.2 on forbiding name clashes within namespaces the rule prohibiting name conflicts within namespaces is among the most important wfrs, therefore, in the following we will argue on its specification. in [omg10], a namespace is defined as follows: “a namespace is an element in a model that contains a set of named elements that can be identified by name.” it logically follows that the coexistence under the same namespace of at least two elements having identical names should be forbidden. the type of the elements is irrelevant. in fact, this is the only constraint specified in the namespace context of core::abstractions (see [omg10], pp. 73). its corresponding informal specification states that: “all the members of a namespace are distinguishable within it.” below is the corresponding formal specification. proc. ocl 2010 10 / 14 eceasst context namespace inv distinguishablename: membersaredistinguishable() the membersaredistinguishable() operation is formaly defined as: context namespace def: membersaredistinguishable():boolean = self.member->forall( memb | self.member->excluding(memb) ->forall(other | memb.isdistinguishablefrom(other, self))) figure 4: the elements defined in the namespace package let us assume that the namespace contains a large number of elements. if this additional operation evaluates to false, it is important to discover the identity of those elements producing the failure. with this aim, we propose instead the specification below, which is an instantiation of the forall reject ocl specification pattern proposed in [cpo10]. context namespace def: membersaredistinguishable():boolean = self.member->reject(memb | self.member->excluding(memb)-> reject(other | memb.isdistinguishablefrom(other, self))->isempty())->isempty() both the standard specification and the proposal above employ the ao isdistinguishablefrom(p1,p2). this operation is firstly defined within the namedelement context, being redefined in the behavioralfeature context. as stated in the [omg10] (pp. 72), the query “... determines whether two namedelements may logically co-exist within a namespace. by default, two named elements are distinguishable if (a) they have unrelated types or (b) they have related types but different names.” context namedelement::isdistinguishablefrom(n:namedelement,ns: namespace):boolean def: isdistinguishablefrom(n:namedelement,ns:namespace):boolean = if self.ocliskindof(n.ocltype) or n.ocliskindof(self.ocltype) then ns.getnamesofmember(self)->intersection(ns.getnamesofmember(n))->isempty() else true endif 11 / 14 volume 36 (2010) towards a conceptual framework supporting model compilability a simple analysis of this last additional operation specification suggests that this query is wrong. in both emof and cmof, class and enumeration are unrelated types. let colour be the name of two instances, one of the class metaclass (self), and the other of the enumeration metaclass (n). in this case, the if condition evaluates to false, and the entire if statement to true. this evaluation result, allowing the two instances to co-exist in the same namespace, is obviously a wrong one. as concerning the query getnamesofmember(m:namedelement), [omg10] states that “the query getnamesofmember() gives a set of all of the names that a member would have in a namespace. in general, a member can have multiple names in a namespace if it is imported more than once with different aliases. those semantics are specified by overriding the getnamesofmember operation. the specification here simply returns a set containing a single name, or the empty set if no name.” context namespace def: getnamesofmember(element:namedelement): set(string)= if member->includes(element) then set{}->including(element.name) else set{} endif the above specification is not compilable, because the type of set{} is set(oclundefined) and not set(string). in order to fix the bug, set{} must be replaced with oclempty(set(string)). behavioral features are namespaces. in this case, the coexistence relationship requests that each two behavioralfeatures have different signatures. therefore, the query isdistinguishablefrom() from specified in the namedelement context must be overriden. in [omg10], the corresponding formal specification is: context behavioralfeature def: isdistinguishablefrom(n:namedelement,ns: namespace):boolean = if n.ocliskindof(behavioralfeature) then if ns.getnamesofmember(self)->intersection(ns.getnamesofmember(n)) ->notempty() then set{}->include(self)->include(n)->isunique(bf | bf.ownedparameter->collect(type)) else true endif else true endif this specification is not compilable because the type of set{}->include(self)->include(n) is set(namedelement), thus bf.ownedparameter cannot be computed since bf is a namedelement. following, is the correct specification. context behavioralfeature def: isdistinguishablefrom(n:behavioralfeature,ns:namespace):boolean = if ns.getnamesofmember(self)->intersection(ns.getnamesofmember(n))->notempty() then oclempty(set(behavioralfeature))->including(self)->including(n) ->isunique(bf | bf.ownedparameter->collect(type)) else true endif proc. ocl 2010 12 / 14 eceasst 5 conclusions and future work switching the developers way of thinking with respect to the role of models in software development from supporting communication and problem understanding to supporting code generation and system testing is a key aspect in ensuring the success of model-driven methodologies. in this respect, we have proposed thinking about model compilability by similarity to program compilability. in this context, the completeness and correctness of wfrs specifications represents a mandatory requirement. unfortunately, the state of facts is far from expectations. there are no mof or uml 2.x editors supporting model compilation. in order to surpass this situation, the first priority is fixing the bugs in the existing specifications, followed by the addition of new aos and constraints, so as to complete the specification of the static semantics. the approach proposed in this paper highlights the importance of a detailed analysis, reflected in both informal and formal specifications. the use of the test-driven specification principle (describing test models prior to writing the formal specification itself) has proven to be a useful technique. choosing the right context for each wfr is another key issue. this is due to the fact that, as opposed to “classical” invariants, the wfrs may refer to the state of those objects connected to the current object through links. another core issue concerns the specification style. we have proposed a specification style supporting model testing, by providing the information needed for error diagnosis in case of assertion failure. this testing-oriented specification style relies on the use of appropriate ocl specification patterns [cpo10]. in future, we intend to extend our work to encompass the whole mof 2.0 and uml 2.3 specifications, as well as to identify and test new specification patterns. acknowledgements: this work was supported by cncsis-uefiscsu, project number pniiidei 2049/2008. our kind thanks go to the anonymous reviewers who’s comments helped us in restructuring the paper. bibliography [bf09] p. bunyakiati, a. finkelstein. the compliance testing of software tools with respect to the uml standards specification the argouml case study. in proceedings of the fourth international workshop on automation of software test (ast’09). pp. 138–143. ieee cs press, 2009. [bhb+01] j.-m. bruel, b. henderson-sellers, f. barbier, a. le parc, r. france. improving the uml metamodel to rigorously specify aggregation and composition. 2001. technical report. [ccbc04] d. chiorean, d. corutiu, m. bortes, i. chiorean. good practices for creating correct, clear and efficient ocl specifications. in koskimies et al. (eds.), proceedings of the 2nd nordic workshop on the unified modeling language (nwuml2004). tucs general publications 35, pp. 127–142. turku center for computer science (tucs), finland, 2004. 13 / 14 volume 36 (2010) towards a conceptual framework supporting model compilability [cpo10] d. chiorean, v. petraşcu, i. ober. testing-oriented improvements of ocl specification patterns. in proceedings of the 2010 ieee international conference on automation, quality and testing, robotics aqtr. volume ii, pp. 143–148. ieee computer society, 2010. [csw08] t. clark, p. sammut, j. willans. applied metamodeling: a foundation for language driven development. ceteva, second edition, 2008. http://itcentre.tvu.ac.uk/∼clark/ docs/applied%20metamodelling%20%28second%20edition%29.pdf. [fk] p. friese, b. kolb. validating ecore models using oaw workflow and ocl. in eclipse summit europe 2007. http://www.eclipsecon.org/summiteurope2007/ presentations/ese2007 model-friese-oawandocl.pdf. [fql+03] j. m. fuentes, v. quintana, j. llorens, g. génova, r. prieto-dı́az. errors in the uml metamodel? acm sigsoft software engineering notes 28(6):3–3, 2003. [lci] lci (laboratorul de cercetare ı̂n informatică). object constraint language environment (ocle). http://lci.cs.ubbcluj.ro/ocle/. [mey97] b. meyer. object-oriented software construction. prentice hall, second edition, 1997. [mo94] j. martin, j. odell. object-oriented methods: a foundation. prentice-hall, 1994. [omg05] omg (object management group). unified modeling language (uml) specification, version 1.4.2. 2005. http://www.omg.org/spec/uml/iso/19501/pdf/. [omg06] omg (object management group). meta object facility (mof) core specification, version 2.0. 2006. http://www.omg.org/spec/mof/2.0/pdf. [omg10] omg (object management group). unified modeling language (uml), infrastructure, version 2.3. 2010. http://www.omg.org/spec/uml/2.3/infrastructure/pdf/. [por] modeling languages portal. http://modeling-languages.com/blog/content/ poor-validation-uml-models-eclipse-uml2-tools. [rg00] m. richters, m. gogolla. validating uml models and ocl constraints. in evans et al. (eds.), uml 2000 the unified modeling language. advancing the standard: third international conference proceedings. lecture notes in computer science 1939, pp. 265–277. springer, 2000. [sbpm08] d. steinberg, f. budinsky, m. paternostro, e. merks. emf: eclipse modeling framework. addison-wesley professional, second edition, 2008. [ss08] m. seifert, r. samlaus. static source code analysis using ocl. in cabot et al. (eds.), proceedings of the 8th international workshop on ocl concepts and tools (ocl 2008) at models 2008. electronic communications of the easst 15, p. 15 pages. european association of software science and technology (easst), 2008. http: //journal.ub.tu-berlin.de/index.php/eceasst/article/view/174/171. proc. ocl 2010 14 / 14 http://itcentre.tvu.ac.uk/~clark/docs/applied%20metamodelling%20%28second%20edition%29.pdf http://itcentre.tvu.ac.uk/~clark/docs/applied%20metamodelling%20%28second%20edition%29.pdf http://www.eclipsecon.org/summiteurope2007/presentations/ese2007_model-friese-oawandocl.pdf http://www.eclipsecon.org/summiteurope2007/presentations/ese2007_model-friese-oawandocl.pdf http://lci.cs.ubbcluj.ro/ocle/ http://www.omg.org/spec/uml/iso/19501/pdf/ http://www.omg.org/spec/mof/2.0/pdf http://www.omg.org/spec/uml/2.3/infrastructure/pdf/ http://modeling-languages.com/blog/content/poor-validation-uml-models-eclipse-uml2-tools http://modeling-languages.com/blog/content/poor-validation-uml-models-eclipse-uml2-tools http://journal.ub.tu-berlin.de/index.php/eceasst/article/view/174/171 http://journal.ub.tu-berlin.de/index.php/eceasst/article/view/174/171 introduction model compilability reality and goals diagnosing the state of facts related work setting the goals requirements of a static semantics specification proof of concepts on the uml composition relationship on forbiding name clashes within namespaces conclusions and future work automatic proving of fuzzy formulae with fuzzy logic programming and smt electronic communications of the easst volume 64 (2013) proceedings of the xiii spanish conference on programming and computer languages (prole 2013) automatic proving of fuzzy formulae with fuzzy logic programming and smt miquel bofill, ginés moreno, carlos vázquez and mateu villaret 19 pages guest editors: clara benac earle, laura castro, lars-〉akefredlund managingeditors : tizianamargaria,juliapadberg,gabrieletaentzer eceasst homepage : htt p : //www.easst.org/eceasst/ issn1863−2122 http://www.easst.org/eceasst/ eceasst automatic proving of fuzzy formulae with fuzzy logic programming and smt miquel bofill1, ginés moreno2, carlos vázquez2 and mateu villaret1 1 miquel.bofill@udg.edu, mateu.villaret@udg.edu department of computer science, applied mathematics and statistics university of girona 17071 girona (spain) 2 gines.moreno@uclm.es, carlos.vazquez@uclm.es department of computing systems university of castilla-la mancha 02071 albacete (spain) abstract: in this paper we deal with propositional fuzzy formulae containing several propositional symbols linked with connectives defined in a lattice of truth degrees more complex than bool. we firstly recall an smt (satisfiability modulo theories) based method for automatically proving theorems in relevant infinitelyvalued (including łukasiewicz and gödel) logics. next, instead of focusing on satisfiability (i.e., proving the existence of at least one model) or unsatisfiability, our interest moves to the problem of finding the whole set of models (with a finite domain) for a given fuzzy formula. we propose an alternative method based on fuzzy logic programming where the formula is conceived as a goal whose derivation tree contains on its leaves all the models of the original formula, by exhaustively interpreting each propositional symbol in all the possible forms according the whole set of values collected on the underlying lattice of truth-degrees. keywords: fuzzy logic programming; automatic theorem proving; smt 1 introduction research on sat (boolean satisfiability) and smt (satisfiability modulo theories) [bsst09] represents a successful and large tradition in the development of highly efficient automatic theorem solvers for classic logic. more recently there also exist attempts for covering fuzzy logics, as occurs with the approaches presented in [abmv12, vbg12]. moreover, if automatic theorem solving supposes too an starting point for the foundations of logic programming as well as one of its important application fields [llo87, sti88, fit96, apt90, bra00], in this work we will show some preliminary guidelines about how fuzzy logic programming can face the automatic proving of fuzzy theorems. let us start our discussion with an easy motivating example. assume that we have a very simple digital chip with just a single input port and just one output port, such that it reverts on out the signal received from in. the behaviour of such chip can be represented by the following propositional formula f : (in′∧out)∨(in∧out′). depending on how we interpret 1 / 19 volume 64 (2013) mailto:miquel.bofill@udg.edu, mateu.villaret@udg.edu mailto:gines.moreno@uclm.es, carlos.vazquez@uclm.es automatic proving of fuzzy formulae with fuzzy logic programming and smt figure 1: interpreting a formula with two values for signals/propositions in and out. each propositional symbol, we obtain the following final set of interpretations for the whole formula: i1 : {in = 0,out = 0} ⇒ f = 0 i2 : {in = 0,out = 1} ⇒ f = 1 i3 : {in = 1,out = 0} ⇒ f = 1 i4 : {in = 1,out = 1} ⇒ f = 0 a sat solver easily proves that f is satisfiable since, in fact, it has two models (i.e., interpretations of the propositional variables in and out that assign 1 to the whole formula) represented by i2 and i3. an alternative way for explicitly obtaining such interpretations consists of using the fuzzy logic environment floper developed in our research group [mmpv10, mmpv11, mmpv12, jmm+13] (http://dectau.uclm.es/floper/). as we will explain in the rest of the paper, when floper executes the following goal (representing formula f ) “(@not(i(in)) & i(out)) | (i(in) & @not(i(out)))” with respect to a fuzzy logic program comproc. prole 2013 2 / 19 http://dectau.uclm.es/floper/ eceasst figure 2: interpreting a formula with three values for signals/propositions in and out. posed by just two rules: “i(1) with 1” and “i(0) with 0”, it draws the tree shown in figure 1, where models i2 and i3 appear in the two central leaves of the tree inside a blue box. each branch in the tree starts by interpreting variables in and out and continues with the evaluation of operators appearing in f . note that whereas formula f describes the behaviour of our chip in an “implicit way”, the whole set of models i2 and i3 “explicitly” describes how the chip successfully works (any other interpretation not being a model, represents an abnormal behaviour of the chip), hence the importance of finding the whole set of models for a given formula. assume now that we plan to model an “analogic” version of the chip, where both the input and output signals might vary in an infinite range of values between 0 and 1, such that out will simply represent the “complement” of in. the new behaviour of the chip can be expressed again by the same previous formula, but taking into account now that connectives involved in f could be defined in a fuzzy way as follows (see also figure 3 afterwards): x′ = 1−x product logic’s negation x∧y = min(x,y) gödel logic’s conjunction x∨y = min(x + y,1) łukasiewicz logic’s disjunction here we could use an smt solver to prove that f is satisfiable. following the approach of the work in [abmv12], it can be easily checked that f is satisfiable1 with the following smt-lib script, encoding the previous connectives into sat modulo linear real arithmetic: 1 the formula has infinite models of the form {in = x,out = y} such that x + y = 1. 3 / 19 volume 64 (2013) automatic proving of fuzzy formulae with fuzzy logic programming and smt ; set logic: quantifier free linear real arithmetic (set-logic qf_lra) ; min(x,y) (define-fun min ((x real) (y real)) real (ite (> x y) y x)) ; x’ = 1 x (define-fun agr_not ((x real)) real (1 x)) ; &g(x,y) = min{x,y} (define-fun and_godel ((x real) (y real)) real (min x y)) ; |l(x,y) = min{x+y,1} (define-fun or_luka ((x real) (y real)) real (min (+ x y) 1)) ; declaration of variables (declare-fun x () real) (declare-fun y () real) ; ordering relation (assert (>= x 0)) (assert (<= x 1)) (assert (>= y 0)) (assert (<= y 1)) ; formula to check (assert (= (or_luka (and_godel (agr_not x) y) (and_godel x (agr_not y))) 1)) ; check for satisfiability (check-sat) it is easy to understand the smt-lib syntax of the previous code. just in case, we recall that the ite expression corresponds to the if-then-else construct. note that all necessary connectives are easily encoded as is done in [abmv12]. it is worth noting that, apart from proving satisfiability of a formula, smt solvers can be used to prove that a formula is a theorem, by checking unsatisfiability of its negation. on the other hand, figure 2 shows too three models in the tree depicted by floper when considering only three kinds of values (that is, 0, 0.5 and 1) for interpreting in and out. such models include, apart of i2 and i3 seen before, the interpretation {in = 0.5,out = 0.5} since, as proc. prole 2013 4 / 19 eceasst we can see in the detailed computations performed along the middle branch of the tree, we have: (0.5′∧0.5)∨(0.5∧0.5′) = ((1−0.5)∧0.5)∨(0.5∧0.5′) = (0.5∧0.5)∨(0.5∧0.5′) = min(0.5,0.5)∨(0.5∧0.5′) = 0.5∨(0.5∧0.5′) = 0.5∨(0.5∧(1−0.5)) = 0.5∨(0.5∧0.5) = 0.5∨min(0.5,0.5) = 0.5∨0.5 = min(0.5 + 0.5,1) = min(1,1) = 1 similarly, we can check for instance in the second branch of the tree that {in = 1,out = 0.5} is not a model (in fact, our chip can not return a signal of value 0.5 when its input is 1) since: (1′∧0.5)∨(1∧0.5′) = ((1−1)∧0.5)∨(1∧0.5′) = (0∧0.5)∨(1∧0.5′) = min(0,0.5)∨(1∧0.5′) = 0∨(1∧0.5′) = 0∨(1∧(1−0.5)) = 0∨(1∧0.5) = 0∨min(1,0.5) = 0∨0.5 = min(0 + 0.5,1) = min(0.5,1) = 0.5 to finish this section, let us comment some connections between the two main topics of this work, i.e. fuzzy logic programming and fuzzy smt, with answer set programming (asp), a well-known declarative programming paradigm oriented towards combinatorial search problems which has been recently combined with fuzzy logic [vdv07]. in asp, answer sets are models computed according to the stable model semantics of logic programming. this introduces nonmonotonic reasoning into logic programming, and gives raise to a paradigm that is different from the proof-derivation approach of prolog. in [mo09], it is presented an asp semantics for a kind of fuzzy logic programs very close to malp, based on the idea of finding models that we also use in this paper when analyzing fuzzy logic formulae with our floper tool. on the other hand, constraint satisfaction problems (csps) are mathematical problems defined as a set of objects whose state must satisfy a number of constraints or limitations and hence, smt and asp can be roughly thought of as certain forms of csps. the translation of answer-set programs into smt has been considered in [nie08, jns09, njn13]. also, asp has been recently combined with smt in [wz11]. although its nonmonotonic form of reasoning is out of the scope of this paper, we are interested in coping with this topic in future extensions of our proposal. the structure of this paper is as follows. section 2 constitutes the core of our paper and it is divided in three blocks. in sub-section 2.1 we present the main features of our fuzzy logic programming environment floper, which are used in sub-section 2.2 for analyzing several fuzzy formulae, whereas in sub-section 2.3 we provide some interesting hints on cost measures associated to our method. finally, we conclude in section 3 by also describing a few number of challenging lines for future research. 2 malp, floper and automatic theorem proving in what follows we describe a very simple subset of the malp2 language (see [mov04, jmp09] for a complete formulation of this framework), which in essence consists of a first-order language, l , containing variables, constants, function symbols, predicate symbols, and several 2 multi-adjoint logic programming. 5 / 19 volume 64 (2013) automatic proving of fuzzy formulae with fuzzy logic programming and smt &p(x,y) , x∗y |p(x,y) , x + y−x∗y ←p (x,y) , min(1,x/y) &g(x,y) , min(x,y) |g(x,y) , max{x,y} ←g (x,y) , { 1 if y ≤ x x otherwise &l(x,y) , max(0,x + y−1) |l(x,y) , min{x + y,1} ←l (x,y) , min{x−y + 1,1} figure 3: conjunctors, disjunctors and implications from product, gödel and łukasiewicz logics. (arbitrary) connectives to increase language expressiveness: implication connectives (denoted by ←1,←2,...); conjunctive connectives (∧1,∧2,...), disjunctive connectives (∨1,∨2,...), and hybrid operators (usually denoted by @1,@2,...), all of them are grouped under the name of “aggregators”. although these connectives are binary operators, we usually generalize them as functions with an arbitrary number of arguments. so, we often write @(x1,...,xn) instead of @(x1,...,@(xn−1,xn)). by definition, the truth function for an n-ary aggregation operator [[@]] : ln → l is required to be monotonous. additionally, our language l contains the values of a lattice (l,≤) and a set of connectives interpreted over such lattice. in general, l may be the carrier of any complete bounded lattice where a l-expression is a well-formed expression composed by values of l, as well as variable symbols, connectives and primitive operators (i.e., arithmetic symbols such as ∗,+,min, etc.). in what follows, we assume that the truth function of any connective @ in l is given by its corresponding connective definition, that is, an equation of the form @(x1,...,xn) , e, where e is a l-expression not containing variable symbols apart from x1,...,xn. for instance, some fuzzy connective definitions in the lattice ([0,1],≤) are presented in figure 3 (from now on, this lattice will be called v along this paper), where labels l, g and p mean respectively łukasiewicz logic, gödel logic and product logic (with different capabilities for modeling pessimistic, optimistic and realistic scenarios, respectively). this subset of malp is intended to cope with fuzzy propositional formulae like p∧q → p∨q, where propositions p and q are interpreted as values of the lattice. to this end, a program is defined as a set of rules (also called “facts”) of the form “h with v”, where h is an atomic formula or atom (usually called head), and v is its associated truth degree (i.e., a value of l). more precisely, in our application, heads have always the form “i(v)” and each program rule looks like “i(v) with v”. it is noteworthy to point out that even when we use the same names for constants (building data terms) and truth degrees, the herbrand universe of each program and the carrier set of its associated lattice should never be confused, since they are in fact disjoint sets. a goal is a formula built from atomic formulas b1,...,bn (n ≥ 0 ), truth values of l, conjunctions, disjunctions and aggregations, submitted as a query to the system. in this subset of malp, the atomic formulas of a goal have always the form “i(p)”, being p a variable symbol. in this way, when running a simple goal like “i(p)” (as done in figure 4), we could obtain several answers meaning something like “when p = v, then the resulting truth degree is v”, representing all possible interpretations in l for proposition p in the original formula. the procedural semantics of this subset of the malp language consists of an operational phase (based on admissible steps that exploits the atoms in the goal), followed by an interpretive phase (that performs arithmetic operations to interpret the resulting formula on the lattice). in proc. prole 2013 6 / 19 eceasst the following, c [a] denotes a formula where a is a sub-expression which occurs in the –possibly empty– context c []. moreover, c [a/a′] means the replacement of a by a′ in context c []. definition 1 (admissible step) let q be a goal and let σ be a substitution. the pair 〈q; σ〉 is a state. given a program p, an admissible computation is formalized as a state transition system, whose transition relation →as is defined as the least one satisfying: 〈q[a]; σ〉 →as 〈(q[a/v])θ ; σ θ〉 where a is the selected atom in q, θ = mgu({h = a})3 and “h with v” in p. an admissible derivation is a sequence 〈q; id〉→as ···→as〈q′; θ〉. if we exploit all atoms of a given goal, by applying admissible steps as much as needed during the operational phase, then it becomes a formula with no atoms (a l-expression) which can be then interpreted w.r.t. lattice l as follows. definition 2 (interpretive step and fuzzy computed answer) let p be a program, q a goal and σ a substitution. assume that [[@]] is the truth function of connective @ in the lattice (l,≤) associated to p, such that, for values r1,...,rn,rn+1 ∈ l, we have that [[@]](r1,...,rn) = rn+1. then, we formalize the notion of interpretive computation as a state transition system, whose transition relation →is is defined as the least one satisfying: 〈q[@(r1,...,rn)]; σ〉 →is 〈q[@(r1,...,rn)/rn+1];σ〉 an interpretive derivation is a sequence 〈q; σ〉→is ···→is〈q′; σ〉. when q′ = r ∈ l, the state 〈r; σ〉 is called a fuzzy computed answer (f.c.a.) for that derivation. 2.1 the fuzzy logic programming environment floper the parser of our floper tool [mmpv10, mmpv11] has been implemented by using the prolog language. once the application is loaded inside a prolog interpreter, it shows a menu which includes options for loading/compiling, parsing, listing and saving malp programs, as well as for executing/debugging fuzzy goals. moreover, in [mmpv10] we explain that floper has been recently equipped with new options, called “lat” and “show”, for allowing the possibility of respectively changing and displaying the lattice associated to a given program. a very easy way to model truth-degree lattices for being included into the floper tool is also described in [mmpv10], according the following guidelines. all relevant components of each lattice are encapsulated inside a prolog file which must necessarily contain the definitions of a minimal set of predicates defining the set of valid elements (member/1 predicate), the top and bottom elements (top/1 and bot/1 predicates), the full or partial ordering established among them (leq/2 predicate), as well as the repertoire of fuzzy connectives which can be used for their subsequent manipulation. if we have, for instance, some fuzzy connectives of the form &label1 (conjunction), |label2 (disjunction) or @label3 (aggregation) with arities n1, n2 and n3 respectively, we must provide clauses defining the connective predicates “and label1/(n1+1)”, 3 here mgu(e) denotes the most general unifier of an equation set e [lmm88]. 7 / 19 volume 64 (2013) automatic proving of fuzzy formulae with fuzzy logic programming and smt figure 4: a work-session with floper solving goal i(p). “or label2/(n2+1)” and “agr label3/(n3+1)”, where the extra argument of each predicate is intended to contain the result achieved after the evaluation of the proper connective. finally, for the purposes of the current work, we also require for each lattice a prolog fact of the form members(l) being the l a list containing the set of truth degrees belonging to the modeled lattice (or at least a representative subset of them when working with infinite lattices) for being used when interpreting propositional variables of fuzzy formulae. for instance, a lattice defining the simplest notion of binary lattice should implement predicate member/1 with facts member(0) and member(1) (including also members([0,1])) and the boolean conjunction could be defined by the pair of facts and bool(0, ,0) and and bool(1,x,x). following the prolog style regulated by the previous guidelines, in figure 5, we show the set of clauses modeling the more flexible lattice v , which enables the possibility of working with truth degrees in the infinite space of the real numbers between 0 and 1, offering too a wide range of conjunction and disjunction operators recasted from the three typical fuzzy logics described before (i.e., the łukasiewicz, gödel and product logics), as well as a useful description for the hybrid aggregator average and the negation connective. note that we have included the fact “members([0,0.5,1]).” which implies that in our application, propositional variables involved in fuzzy formulae to be proved, only three values (i.e., real numbers 0, 0.5 and 1, collected from the infinite unit interval) should be considered for interpreting such formulas, as proc. prole 2013 8 / 19 eceasst member(x) :number(x),0=y,z=y). pri_sub(x,y,z) :z is x-y. pri_max(x,y,z) :(x=y,z=x). pri_prod(x,y,z) :z is x * y. pri_div(x,y,z) :z is x/y. figure 5: prolog code for representing lattice v , which models truth degrees in the real interval [0,1] with standard fuzzy connectives. shown in figure 2. note also that we have included definitions for auxiliary predicates, whose names always begin with the prefix “pri ”. all of them are intended to describe primitive/arithmetic operators (in our case +, −, ∗, /, min and max) in a prolog style, for being appropriately called from the bodies of clauses defining predicates with higher levels of expressivity (this is the case for instance, of the three kinds of fuzzy connectives we are considering: conjunctions, disjunctions and aggregations). since till now we have considered two classical, fully ordered lattices (with a finite and infinite number of elements, respectively), we wish now to introduce a different case coping with a very simple lattice where not always any pair of truth degrees are comparable. so, consider the following partially ordered lattice f in the diagram of figure 6, which is equipped with conjunction, disjunction and implication connectives based on the gödel logic described in figure 3, but with the particularity that now, in the general case, the gödel’s conjunction must be expressed as &g(x,y) , in f (x,y), where it is important to note that we must replace the use of “min” by “inf ” in the connective definition (and similarly for the disjunction connective, where “max” must be substituted by “sup”). to this end, observe in the prolog code accompanying the graphic in figure 6 that we have introduced clauses defining the primitive operators “pri inf/3” and “pri sup/3” which are intended to return the infimum and supremum of two elements. related with this fact, we must point out the following aspects: • note that since truth degrees α and β are incomparable, then any call to goals of the form “?leq(alpha,beta).” or “?leq(beta,alpha).” will always fail. 9 / 19 volume 64 (2013) automatic proving of fuzzy formulae with fuzzy logic programming and smt > | γ / \ α β \ / ⊥ member(bottom). member(alpha). member(beta). member(gamma). member(top). members([bottom,alpha,beta,gamma,top]). leq(bottom,x). leq(x,x). leq(alpha,gamma). leq(beta,gamma). leq(x,top). l(x,x) :!. l(x,y):-leq(x,y),!. l(x,y):-leq(x,z),l(z,y). and godel(x,y,z) :pri inf(x,y,z). or godel(x,y,z) :pri sup(x,y,z). agr impl(x,y,z) :(l(y,x),!,z=top ; z=x). pri inf(x,y,x):l(x,y), !. pri inf(x,y,y):l(y,x), !. pri inf( , ,bottom). pri sup(x,y,x):l(y,x), !. pri sup(x,y,y):l(x,y), !. pri sup( , ,gamma). figure 6: the finite, partially ordered lattice f modeled in prolog. • a goal of the form “?pri inf(alpha,beta,x).”, instead of failing, successfully produces the desired result “x=bottom”. • note anyway that the implementation of the “pri inf/3” predicate is mandatory for coding the general definition of “and godel/3” (a similar reasoning follows for “pri sup/3” and “or godel/3” ). 2.2 some examples this subset of the malp language suffices for developing a simple fuzzy theorem prover, where it is important to remark that our tool can cope with different lattices (not only the real interval [0,1]) containing a finite number of elements -marked in “members”maintaining full or partial ordering among them. hence, we can use floper for enumerating the whole set of interpretations and models of fuzzy formulae. to this end, only a concrete lattice l is required in order to automatically build a program composed by a set of facts of the form “i(α) with α ”, for each α ∈ l. for instance, the malp program associated to lattice f in figure 6 looks like: i(top) with top. i(gamma) with gamma. i(alpha) with alpha. i(beta) with beta. i(bottom) with bottom. once the lattice and the residual program have been loaded into floper, the formula to be evaluated is introduced as a goal to the system following some conventions: proc. prole 2013 10 / 19 eceasst figure 7: a work-session with floper solving formula p∨q (25 interpretations, 9 models). • if p is a propositional variable in the original formula, then it is denoted as “i(p)” in the goal f . • if & is a conjunction of a certain logic “label” in the original formula, then it is denoted as “&label” in goal f . • for disjunctions, negations and implications, use respectively “|label”, “@no label” and “@im label” in f . • for other aggregators use “@label” in f . in what follows we discuss some examples related with the lattice shown in figure 6 and its residual malp program just seen before. firstly, if we execute goal “i(p)” into floper, we obtain the five interpretations for p shown in figure 4. on the other hand, consider now the 11 / 19 volume 64 (2013) automatic proving of fuzzy formulae with fuzzy logic programming and smt figure 8: full proof tree for formula p∧(p∨p) with 1 model among 5 interpretations. propositional formula p∨q, which is translated into the malp goal “(i(p) | i(q))” and after being executed with floper, the tool returns a tree4 whose 25 leaves represent the whole set of interpretations (9 of them -inside blue cloudsare models) as seen in figure 7. see also figure 8 associated to formula p∧(p∨p). consider now the more involved formula p∧q → p∨q which becomes into the malp goal “(i(p) & i(q)) @impl (i(p) | i(q))”. when interpreted by floper, the system returns the list of answers displayed in figure 9, having all them the maximum truth degree “top”, which proves that this formula is a tautology, as wanted. 2.3 some hints on cost measures we wish to finish this section by providing some comments about cost measures and efficiency. so, given a lattice l, a formula f and its associated proof tree t , we define the following values: • v is the number of distinct variables in f . • v′ is the number of occurrences (including repetitions) of variables in f . • c is the number of connectives in f . • r is the number of (marked) elements in lattice l given by predicate “members”. and now we have that: • the width of the tree t , or total number of interpretations of f , is rv. 4 each state contains its corresponding goal and substitution components and they are drawn inside yellow circles. admissible steps, colored in blue, are labeled with the program rule they exploit. finally, those blue circles annotated with word “is”, correspond to interpretive steps. sometimes we include blue circles labeled with “result” which represents a chained sequence of interpretive steps. proc. prole 2013 12 / 19 eceasst figure 9: full proof tree for tautology p∧q → p∨q (25 models). • the number of admissible steps performed on a single branch of t is v′. • the number of interpretive steps performed on a single branch of t is c. • the depth of t , or number of computational (admissible/interpretive) steps for each possible interpretation of f is v′+ c. • an upper bound for the total number of admissible steps in t is |as|≤ (v′−v)rv + v ∑ i=1 ri. • an upper bound for the total number of interpretive steps in t is |is|≤ crv. • an finally, an upper bound for the total number of computational (admissible and interpretive) steps is |t|≤ (c + v′−v)rv + v ∑ i=1 ri. let us come back again to tautology p∧q → p∨q for which floper displays the whole set of models seen in figure 9, and assume now a more general version with the following shape p1 ∧...∧pn → p1 ∨...∨pn for which we have studied its behaviour in the table of figure 10. in the horizontal axis we represent the number n of different propositional variables appearing in the formula, whereas the vertical axis refers to the number of seconds5 needed to obtain the whole set of interpretations (all them are models in this case) for the formula. both the red and blue lines refers to the method just commented along this paper, but whereas the red line indicates that 5 the benchmarks have been performed using a computer with processor intel core duo, with 2 gb ram and windows vista. 13 / 19 volume 64 (2013) automatic proving of fuzzy formulae with fuzzy logic programming and smt figure 10: behaviour of the method. the derivation tree has been produced by performing admissible and interpretive steps according definitions 1 and 2, respectively, the blue line refers to the execution of the prolog code obtained after compiling with floper the malp program and goal associated to our intended formula. the results achieved in the figure show that our method has a nice behaviour in both cases, even for formulae with a big number of propositional variables. of course, the method does not try to compete with sat techniques (which are always faster and can deal with more complex formulae containing many more propositional variables), but it is important to remark again that in our case, we face the problem of finding the whole set of models for a given formula, instead of only focusing on satisfiability. 3 conclusions and future work in this paper we have focused on two different, but related problems regarding the automatic proving of propositional fuzzy formulae. in particular, whereas an smt solver has been used for checking satisfiability, an alternative technique based on fuzzy logic programming has been introduced for finding the whole set of interpretations which are models for a given formula. in the future we plan to introduce improvements on both methods, regarding the set of truth degrees collected in the lattice used for interpreting a given formula. in the case of smt, we plan to investigate how to cope with lattices equipped with partial ordering among their elements, whereas for the method based on fuzzy logic programming, it is important to design a much more flexible technique for dealing with infinite lattices than the one we have used in this paper proc. prole 2013 14 / 19 eceasst r0 or_godel(i(p),i(q)) {} r1 or_godel(bottom,i(q)) {p/bottom} r1 or_godel(bottom,bottom) {q/bottom,p/bottom} result bottom {q/bottom,p/bottom} ... figure 11: part of the xml file representing the execution tree shown in figure 7. (based on “pointing out” just a few number of truth degrees in the infinite space). in this last sense, some halting rules and branch cuts should be needed (maybe through alfa cuts) or even it could be interesting to study how to obtain all models of a formula by a constraint (as x+y = 1 for the example given in the introduction about the analogical chip) or a set of constraints. moreover, we are also interested in reinforcing our techniques by making use of recent advances produced in the field of (fuzzy variants of) asp. anyway, we are nowadays planning to make use of the standard “xml path language” xpath [bbc+07] in order to automate the process of directly extracting the set of models contained on proof trees once they have been exported by floper in xml format. in what follows, we simply draft some key-point ideas which can be very useful when dealing with complex formulae beyond the simpler examples seen along this paper since, as formally stated in sub-section 2.3, the number of interpretations grows exponentially w.r.t. the set of propositions and connectives included on fuzzy formulae to be tested. moreover, in the near future, the method will be reinforced by means of the “fuzzy xpath” tool developed too with floper as described in [alm11, alm12, almv13] and which is freely available from http://dectau.uclm.es/fuzzyxpath. so, let us recall that xpath was designed as a query language for xml text in which the path of the underlying tree of any xml document is used to describe the query (subsequent nodes on xpath expressions are separated by a simple slash ‘/’ or a double slash ‘//’, being this last case useful for overriding several nodes). moreover, xpath expressions can be adorned with boolean 15 / 19 volume 64 (2013) http://dectau.uclm.es/fuzzyxpath automatic proving of fuzzy formulae with fuzzy logic programming and smt {q/top,p/bottom} {q/top,p/alpha} {q/top,p/beta} {q/top,p/gamma} {q/bottom,p/top} {q/alpha,p/top} {q/beta,p/top} {q/gamma,p/top} {q/top,p/top} figure 12: xml file obtained after evaluating an xpath query. conditions (between square brackets ‘[]’) on nodes and leaves to restrict the number of answers of the query. for instance, we have used the xpath online tool http://www.xpathtester.com/test for executing the query “//node[goal=’top’]/substitution” against the xml file shown in figure 11, which was generated by floper when producing the proof tree drawn in figure 7, thus returning as output the new xml document listed in figure 12. as illustrated in figure 11, note that the xml files representing proof trees exported by floper, are always rooted with the node label, whose children are based on four finds of ‘tags’ (this structure is nested as much as needed): • rule, which indicates the program rule evaluated to reach the current node (the virtual rule r0 is pointed out only in the initial node), • goal, which contains the malp expression under evaluation, that is, the formula that the system is trying to prove on its current initial/intermediate/final step. note that, when in our example such value is top, then we have found a model, where the values assigned to the propositional symbols of the formula are collected in the following tag... • substitution, which accumulates the variable bindings performed along a fuzzy logic derivation (i.e., chain of computational steps along a branch of the execution tree) and whose meaning in our target setting, reveals the way of interpreting the propositions contained on a formula for obtaining its models (see figure 12, where the nine solutions labeled with this tag and reported in the output xml document, indicate each one the truth values for the propositional variables that satisfy the formula with the maximum truth degree), and finally • children, which contains the set of underlying nodes of the tree in a nested way. as we have just revealed, the combined use of fuzzy logic programming together with the standard xpath language for xml data retrieval, admits a challenging feedback applicable to the automatic search of models of fuzzy formulae for which we plan to introduce extra capabilities by using the flexible resources of our “fuzzy xpath” system developed with floper. proc. prole 2013 16 / 19 http://www.xpathtester.com/test eceasst acknowledgements: this work has been partially supported by the eu (feder), and the spanish mineco ministry (ministerio de economı́a y competitividad) under grants tin201233042 and tin2013-45732-c4-2-p. moreover, carlos vázquez and ginés moreno received grants for international mobility from the university of castilla-la mancha (cytema project and vicerrectorado de profesorado). bibliography [abmv12] c. ansótegui, m. bofill, f. manyà, m. villaret. building automated theorem provers for infinitely-valued logics with satisfiability modulo theory solvers. in proceedings of the 42nd ieee international symposium on multiple-valued logic, ismvl 2012. pp. 25–30. 2012. [alm11] j. almendros-jiménez, a. luna, g. moreno. a flexible xpath-based query language implemented with fuzzy logic programming. in bassiliades et al. (eds.), proceedings of 5th international symposium on rules: research based, industry focused, ruleml’11. barcelona, spain, july 19–21. pp. 186–193. springer verlag, lncs 6826, 2011. [alm12] j. almendros-jiménez, a. luna, g. moreno. fuzzy logic programming for implementing a flexible xpath-based query language. electronic notes in theoretical computer science 282:3–18, 2012. [almv13] j. almendros-jiménez, a. luna, g. moreno, c. vázquez. analyzing fuzzy logic computations with fuzzy xpath. in fredlund and castro (eds.), actas de las xiii jornadas sobre programación y lenguajes, prole’13, jornadas sistedes, madrid, spain, september 18-20. pp. 136–150 (“work in progress” track, extended version submitted to eceasst). universidad complutense de madrid (isbn: 97884-695-8331-9), 2013. [apt90] k. r. apt. logic programming. in leewen (ed.), handbook of theoretical computer science. volume b: formal models and semantics, chapter 10, pp. 493–574. mit press, massachusetts institute of technology, usa, 1990. [bbc+07] a. berglund, s. boag, d. chamberlin, m. fernandez, m. kay, j. robie, j. siméon. xml path language (xpath) 2.0. w3c, 2007. [bra00] i. bratko. prolog programming for artificial intelligence. addison wesley, september 2000. [bsst09] c. w. barrett, r. sebastiani, s. a. seshia, c. tinelli. satisfiability modulo theories. in handbook of satisfiability. frontiers in artificial intelligence and applications 185, pp. 825–885. ios press, 2009. [fit96] m. fitting. first-order logic and automated theorem proving. springer verlag, 1996. 17 / 19 volume 64 (2013) automatic proving of fuzzy formulae with fuzzy logic programming and smt [jmm+13] p. julián, j. medina, p. morcillo, g. moreno, m. ojeda-aciego. an unfoldingbased preprocess for reinforcing thresholds in fuzzy tabulation. in advances in computational intelligence proc of the 12th international work-conference on artificial neural networks, iwann 2013. tenerife, spain, june 12-14. pp. 647– 655. springer verlag, lncs 7902, part i, 2013. [jmp09] p. julián, g. moreno, j. penabad. on the declarative semantics of multi-adjoint logic programs. in proceedings of the 10th international work-conference on artificial neural networks, iwann’09. salamanca, spain, june 10-12. pp. 253–260. springe verlag, lncs 5517, 2009. [jns09] t. janhunen, i. niemelä, m. sevalnev. computing stable models via reductions to difference logic. in erdem et al. (eds.), proc. of the 10th international conference on logic programming and nonmonotonic reasoning, lpnmr 2009, potsdam, germany, september 14-18. pp. 142–154. springer verlag, lncs 5753, 2009. [llo87] j. lloyd. foundations of logic programming. springer-verlag, berlin, 1987. second edition. [lmm88] j. l. lassez, m. j. maher, k. marriott. unification revisited. in minker (ed.), foundations of deductive databases and logic programming. pp. 587–625. morgan kaufmann, los altos, california, 1988. [mmpv10] p. morcillo, g. moreno, j. penabad, c. vázquez. a practical management of fuzzy truth degrees using floper. in al. (ed.), proceedings of 4th intl symposium on rule interchange and applications, ruleml’10. washington, usa, october 21–23. pp. 119–126. springer verlag, lncs 6403, 2010. [mmpv11] p. morcillo, g. moreno, j. penabad, c. vázquez. fuzzy computed answers collecting proof information. in al. (ed.), advances in computational intelligence. proceedings of the 11th international work-conference on artificial neural networks, iwann 2011. torremolinos, spain, june 8-10. pp. 445–452. springer verlag, lncs 6692, 2011. [mmpv12] p. j. morcillo, g. moreno, j. penabad, c. vázquez. dedekind-macneille completion and cartesian product of multi-adjoint lattices. int. j. comput. math. 89(1314):1742–1752, 2012. [mo09] n. madrid, m. ojeda-aciego. on coherence and consistence in fuzzy answer set semantics for residuated logic programs. in gesù et al. (eds.), proc. of the 8th international workshop on fuzzy logic and applications, wilf 2009. palermo, italy, june 9-12. pp. 60–67. springer verlag, lncs 5571, 2009. [mov04] j. medina, m. ojeda-aciego, p. vojtáš. similarity-based unification: a multiadjoint approach. fuzzy sets and systems 146:43–62, 2004. [nie08] i. niemelä. stable models and difference logic. annals of mathematics and artificial intelligence 53(1-4):313–329, 2008. proc. prole 2013 18 / 19 eceasst [njn13] m. nguyen, t. janhunen, i. niemelä. translating answer-set programs into bitvector logic. in tompits et al. (eds.), proc. of the 19th international conference on applications of declarative programming and knowledge management, inap 2011. vienna, austria, september 28-30. pp. 95–113. springer verlag, lncs 7773, 2013. [sti88] m. e. stickel. a prolog technology theorem prover: implementation by an extended prolog compiler. journal of automated reasoning 4(4):353–380, 1988. [vbg12] a. vidal, f. bou, l. godo. an smt-based solver for continuous t-norm based logics. in proceedings of the 6th international conference on scalable uncertainty management, sum 2012. marburg, germany, september 17-19. pp. 633– 640. springer verlag, lncs 7520, 2012. [vdv07] d. van nieuwenborgh, m. de cock, d. vermeir. an introduction to fuzzy answer set programming. annals of mathematics and artificial intelligence 50(3-4):363– 388, 2007. [wz11] y. wang, m. zhang. answer set programming modulo theories. in zhang (ed.), applied informatics and communication. communications in computer and information science 228, pp. 655–661. springer berlin heidelberg, 2011. 19 / 19 volume 64 (2013) introduction malp, floper and automatic theorem proving the fuzzy logic programming environment floper some examples some hints on cost measures conclusions and future work position paper: m2n—a tool for translating models to natural language descriptions electronic communications of the easst volume 34 (2010) proceedings of the 6th educators’ symposium: software modeling in education at models 2010 (edusymp 2010) position paper: m2n—a tool for translating models to natural language descriptions petra brosch and andrea randak 8 pages guest editors: peter j. clarke, martina seidl managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst position paper: m2n—a tool for translating models to natural language descriptions petra brosch∗ and andrea randak lastname@big.tuwien.ac.at, http://www.big.tuwien.ac.at business informatics group vienna university of technology, austria abstract: to describe the structure of a system, the uml class diagram yields the means-of-choice. therefor, the class diagram provides concepts like class, attribute, operation, association, generalization, aggregation, enumeration, etc. when students are introduced to this diagram, they often have to solve exercises where texts in natural language are given and they have to model the described systems. when analyzing such exercises, it becomes evident that certain kinds of phrases describing a particular concept appear again and again contextualized to the described domain. in this paper, we present an approach which allows the automatic generation of textual specifications from a given class diagram based on standard phrases in natural language. besides supporting teachers in preparing exercises, such an approach is also valuable for various e-learning scenarios. keywords: modeling exercises, natural language description 1 introduction when teaching modeling, one of the most repetitive and time consuming tasks is the development of exercises and the corresponding solutions. a typical exercise consists of a given textual description of an arbitrary domain (e.g., university systems, enterprises, airports) which students have to model for example with a uml class diagram. in order to obtain an adequate exercise, it does not suffice to prepare the textual specification only, but also the sample solution has to be modeled for checking if all taught concepts are covered and if the difficulty level and size are reasonable. hence, the teacher has to describe the same content twice: once as textual specification in natural language and once as a model. as there should be a one-to-one correspondence between text and model, the question at hand is if it is possible to automatically derive one artifact from the other. already in the early 1980s attempts of automated translation of textual descriptions into program code were conducted. r.j. abbott [abb83] discusses a method for deriving programming concepts like data types and references by analyzing informal english descriptions. an important remark of abbott’s work relates to the automation level of such a method. he points out that such a transformation is far away from being fully automated. user interaction is still needed ∗ funding for this research was provided by the fforte wit women in technology program of the vienna university of technology, and the austrian federal ministry of science and research. 1 / 8 volume 34 (2010) mailto:lastname@big.tuwien.ac.at http://www.big.tuwien.ac.at position paper: m2n—a tool for translating models to natural language descriptions to make the outcome perfect. after all natural language is imprecise and therefore leaves room for interpretation. only if the text obeys a certain structure and the sentences are expressed in a precise, unambiguous way, the models can be automatically derived as it is for example done in the field of requirements engineering (cf. [fkm05, wkh08]). in contrast to models of real-world software engineering projects, the models of the exercises have not to express customers’ and users’ expectations, but they have to fulfill certain didactical expectations and usually show fictive, simplified scenarios only. therefore, the construction is different: when a teacher prepares an exercise, (s)he usually does not write the text and model the sample solution afterwards, but starts with modeling the sample solution. having the sample solution at hand, a formal specification of the scenario is available. in this paper, we propose to use the sample solution for generating the natural language textual description of the exercise. 2 background with five years experience in teaching the course object-oriented modeling at the vienna university of technology [bsw+08], it becomes evident that specific modeling concepts are expressed by recurring phrases, solely contextualized to the described domain. phrases like “part of” for expressing composite aggregations or “is a” for generalizations are used repeatedly, irrespective of describing houses, persons, or elements of any other domain. fig. 1 shows a typical toy example of our modeling course, covering the basic concepts of class diagrams. one possible textual description is as follows. persons have a name. guides and visitors are persons. a guide leads multiple guided tours. each guided tour has exactly one guide. each visitor may attend multiple guided tours, guided tours are attended by one to 20 visitors. for each guided tour the id and the duration are known. a guided tour covers exactly one sight, but each sight is covered by multiple guided tours. a sight has a name and an address. a sight is located in one city. a city may have multiple sights. for each city name and size are known. although this textual description sounds natural, it follows an algorithmic pattern. in a first step, the most important class of the model is identified as a starting point for the description and input for the algorithm. this class is described by its name and its attributes. then, inheritance relations and associations follow. in the order of exploring related classes, the procedure recurs. figure 1: class diagram example proc. edusymp 2010 2 / 8 eceasst traversal strategyecore mm sentences natural 2 language description m2n figure 2: m2n architecture 3 realization the m2n tool (short for model to natural language description) yields a framework for translating models of arbitrary metamodels to natural language descriptions as depicted in fig. 2. the implementation is based on the eclipse modeling framework1, hence any ecore based metamodel may be integrated. three artifacts are necessary to define a translation specification for a modeling language: a metamodel, a model traversal strategy, and a set of sentence templates for describing specific concepts. in the following, these artifacts are examined in detail for a simplified class diagram. metamodel. the class diagram metamodel used in our first prototype comprises a restricted set of the uml class diagram concepts. at the moment, we support the concepts of class, attribute, generalization (single inheritance), and association (binary). sentence templates. standard phrases in the form of sentence templates have to be provided for each concept of the metamodel. if there are more than one sentence for a concept, one is randomly selected, which makes the generated text more natural. these sentences contain wildcards, which are replaced by concrete model values. traversal strategy. each metamodel needs a dedicated traversal strategy to explore the model. a traversal strategy should implement a dedicated interface to allow reliable integration into the m2n framework by the dynamic class loading mechanism of java. the traversal strategy for the class diagram implements a special kind of a breadth first search as shown in listing 1. the most important model element is identified by a heuristic and acts as a starting point for the algorithm. currently, subclass relations and associations are counted. generalizations are higher ranked than associations. in the example of fig. 1, the class person is selected as most important element, because of its two subclasses. for the actual text generation, the root class is first introduced in the generated text by a sentence describing its name and attributes. second, all direct subclasses are named and put to a queue holding the succeeding model elements to describe, if they are not printed so far. third, associations are specified. currently, the reading direction is not explicitly available in the class diagram metamodel. to construct a sentence, the direction is derived from source and target 1 http://www.eclipse.org/modeling/emf/ 3 / 8 volume 34 (2010) position paper: m2n—a tool for translating models to natural language descriptions roles of the association. referenced classes are then put into the queue. as long as the queue is not empty, the algorithm prints the details for the next node. if the model is split into parts, then a new root node has to be found. the algorithm terminates, when all model elements are printed. 1 /∗ v a r i a b l e d e c l a r a t i o n s ∗/ 2 queue n o d e q u e u e ; /∗ t e m p o r a r y b u f f e r f o r a l l d i s t i n c t v i s i t e d e l e m e n t s ∗/ 3 s e t p r i n t e d m e ; /∗ h o l d s a l r e a d y p r i n t e d m o d e l e l e m e n t s ∗/ 4 s e t a l l m e ; /∗ h o l d s a l l m o d e l e l e m e n t s ∗/ 5 6 /∗ f u n c t i o n d e c l a r a t i o n s ∗/ 7 v o i d g e t t e x t ( ) { /∗ i m p l e m e n t e d m e t h o d o f i n t e r f a c e ; c a l l e d b y m2n ∗/ 8 w h i l e ( p r i n t e d m e ! = a l l m e ) { /∗ a l l m o d e l e l e m e n t s p r i n t e d ? ∗/ 9 n o d e = l o c a l i z e r o o t c l a s s ( ) ; /∗ s e a r c h f o r m o s t i m p o r t a n t m o d e l e l e m e n t ∗/ 10 n o d e q u e u e . a d d ( n o d e ) ; /∗ add n o d e a s s t a r t i n g c l a s s t o n o d e q u e u e ∗/ 11 p r i n t m o d e l ( ) ; /∗ p r i n t m o d e l d e t a i l s ∗/ 12 } 13 } 14 15 v o i d p r i n t m o d e l ( ) { 16 n o d e = n o d e q u e u e . p o l l ( ) ; /∗ g e t n o d e t o d e s c r i b e ∗/ 17 p r i n t a t t r i b u t e s ( n o d e ) ; /∗ p r i n t s e n t e n c e f o r a t t r i b u t e s ∗/ 18 p r i n t i n h e r i t a n c e ( n o d e ) ; /∗ p r i n t s e n t e n c e f o r i n h e r i t a n c e ; 19 add e a c h new s u b c l a s s t o n o d e q u e u e ∗/ 20 p r i n t a s s o c i a t i o n ( n o d e ) ; /∗ p r i n t s e n t e n c e f o r a s s o c i a t i o n ; 21 add e a c h new a s s o c i a t e d c l a s s t o n o d e q u e u e ∗/ 22 p r i n t e d m e . a d d ( n o d e ) ; /∗ p r i n t i n g o f n o d e c o m p l e t e d ∗/ 23 i f ( ! n o d e q u e u e . i s e m p t y ( ) ) /∗ i f a n y n o d e s l e f t , r e p e a t ; ∗/ 24 p r i n t m o d e l ( ) ; 25 } listing 1: model to natural language description generation 4 the long-term vision the presented m2n-tool supports on the one hand teachers in keeping exercises consistent with the sample solutions, i.e., it facilitates the management of teaching artifacts. on the other hand, if provided to the students, they can generate natural text out of the given diagram, providing them some explanation of the diagram. but these are only side-effects; we developed our tool with a very different intention in mind. m2n is intended to be used within a major e-learning project aiming at the development of an interactive e-learning system for class diagrams. in the following, we motivate why we need such an e-learning system, then we shortly describe the basic architecture, and finally we explain the important role m2n plays in these considerations. 4.1 motivation one of the basic challenges in teaching modeling is the practical part of the course. unlike in programming where the programs of the students are relatively easily testable by checking whether they show the expected behavior or not, the situation in modeling is different. especially proc. edusymp 2010 4 / 8 eceasst when models are used for describing, analyzing, or designing systems, and when the models are not executable or transferable to a formal specification like code, automatic testing is hardly possible. a serious correction and grading is only possible by human teachers, often requiring considerable intellectual effort to follow the students’ approach, because students often have a different viewpoint on a matter, which is still correct. it is also possible, that the specification is interpretable in different ways. especially in teaching modeling, learning by doing is extremely important, so such practical exercises in which the students have to derive a model from a textual specification. even if the students use modeling tools instead of drawing the models by hand, automatic correction is hardly possible, and if it is possible then the specification has to be formulated very narrow, teaching the students to recognize patterns only instead of allowing them to be creative. due to this reasons it is extremely difficult, to build e-learning environments which allow the students to train on their own and to get valuable feedback from the system, especially when no teacher is at hand. naturally, the exercises may be formulated in a very static manner in terms of multiple choice questions, where the students have to decide if a statement about a given model is true or false. another approach is to give the students textual specifications and a sample solution, which they can compare to their own result. although such approaches are certainly helpful, they do not allow to train creativity, which is certainly an important skill in practical modeling. in the following, we propose an approach which allows a more flexible way to practice the modeling of class diagrams. 4.2 the basic architecture the ideal case for teaching modeling is that the students have to realize a software engineering project where they have to create the models as primary design and documentation artifacts. since in many courses it is not possible to combine teaching modeling with realizing a practical project (or if the assumption is that it is preferable to learn the necessary concepts first before putting them into practice), typical modeling exercises consist of small textual specifications as they may be created with m2n. the students are asked to model the given text as precisely as possible. a good approach is as follows: 1. identify classes, 2. decorate classes with attributes and operations, 3. include inheritance relationships, 4. introduce the associations between classes. one of the major problems hampering the automatic correction is the naming of the modeling elements. model elements are usually identified by their names and often there is a huge choice of freedom on how to name an element. to circumvent this problem we propose the following approach. the specification is internally annotated with the information which words describe model elements. considering our example from above, the annotated specification contains information 5 / 8 volume 34 (2010) position paper: m2n—a tool for translating models to natural language descriptions that a guide is a class, that person is a class and that name is an attribute of person. naturally, the annotations are not visible to the students, as they contain the solutions. additionally, the relationships between the model elements are known. in the proposed tool, the student only sees the given textual specification. first, (s)he is allowed to select those terms of the text which (s)he thinks represents classes. having identified the classes, attributes and operations are added similarly. when the student selects a term in the text, a corresponding model element is created in a graphical editor. when the student is done with the identification of model elements, (s)he adds the relationships between the model elements. the system monitors the student’s behavior and is able to give immediate feedback. similar approaches have been presented in [apl08, bm06, sm04], but our approach is novel in the way how the specifications are created. 4.3 the role of m2n whenever a new exercise is created, the specification has to be prepared accordingly in order to be suitable for being used as input for the e-learning tool. without automatic support, the creation of the specification with the required information is cumbersome and time-consuming. furthermore, it has to be done extremely carefully because otherwise the exercise in the e-learning system is buggy and the students either get confused or they even learn wrong things. for supporting the teachers in easily creating new exercises, we propose an extension of m2n which is able to create such an annotated specification automatically which may serve as input for the e-learning tool. as we have already seen, the teacher provides the sample solution model and m2n creates the textual version. furthermore, the extension of m2n also creates an annotated version of the specification which may be directly imported from the e-learning tool. naturally, the sample solution model provides all information necessary and the required annotation is straightforward in the case that the text is used as provided by our tool. if manual postprocessing is desired, then the danger is that the model and specification are not synchronized anymore. it may be possible that certain features are not derived as expected and then manual intervention is necessary. for this problem, we intend to develop a sophisticated update mechanism allowing to propagate modifications not only from the model to the specification but also vice versa, i.e., from the specification to the model. having this extension at hand, we expect to offer an e-learning tool for class diagrams which allows an easy creation of exercises with minimizing the problem of inconsistencies between specification and model. 5 conclusion in this paper, we presented a tool for transforming a given class diagram to a textual specification in natural language. with such a tool teachers can automatically create the textual specification from the sample solution of an exercise which may serve as a basis for the description of the students’ homework or for examination questions. we realized a first prototype implementation as eclipse plugin. although the text generated in first experiments yield a good basis for describing a given model, the implementation leaves proc. edusymp 2010 6 / 8 eceasst much room for interesting extensions and fine-tuning. for example, currently the plural of a noun is obtained by appending an “s” at the end of the word—irregular forms are neglected. furthermore, we will extend the collection of sentences and elaborate on a more sophisticated assembly algorithm of the text in order to obtain a more natural specification. also we consider a subset of the class diagram’s elements only at the moment—e.g., we are not able to express association classes or n-ary associations which may be treated as any other model element. furthermore, better synchronization support between text and model will be an issue, because if the text has been edited manually and the model is modified, then the manual changes of the text should not get lost. our tool may also be used by the students for practicing. students get a textual description of their model and by experimenting they obtain an explanation of the modifications’ impact. for the realization of this use case, it will be necessary to build a dedicated user interface which is able to highlight the modifications. the long-term goal is building an e-learning framework for learning uml diagrams. given a textual specification, the students shall identify model elements like classes, associations, aggregations etc. which have to be arranged as described in the specification. the result of the students’ effort is compared to a sample solution and differences (i.e., the mistakes) are reported. similar approaches are presented in [apl08, bm06, sm04]. in order to obtain the link between textual specification and sample solution, the text has to be annotated, which is done by hand so far. with the approach presented in this paper it will be possible to annotate the textual specification automatically, facilitating the creation of new exercises. bibliography [abb83] r. j. abbott. program design by informal english descriptions. communications of the acm 26(11):882–894, 1983. [apl08] l. auxepaules, d. py, t. lemeunier. a diagnosis method that matches class diagrams in a learning environment for object-oriented modeling. in icalt ’08: proc. of the 2008 eighth ieee international conference on advanced learning technologies. pp. 26–30. ieee computer society, 2008. [bm06] n. baghaei, a. mitrovic. a constraint-based collaborative environment for learning uml class diagrams. in proc. intelligent tutoring systems. lncs 4053, pp. 176–186. springer, 2006. [bsw+08] m. brandsteidl, m. seidl, m. wimmer, c. huemer, g. kappel. teaching models @ big how to give 1000 students an understanding of the uml. in promoting software modeling through active education, educators symposium models’08. pp. 64–68. warsaw university of technology, 2008. [fkm05] g. fliedl, c. kop, h. c. mayr. from textual scenarios to a conceptual schema. data & knowledge engineering 55(1):20–37, 2005. 7 / 8 volume 34 (2010) position paper: m2n—a tool for translating models to natural language descriptions [sm04] p. suraweera, a. mitrovic. an intelligent tutoring system for entity relationship modelling. international journal of artificial intelligence in education (ijaied) 14(3-4):375–417, 2004. [wkh08] k. wolter, t. krebs, l. hotz. a combined similarity measure for determining similarity of model-based and descriptive requirements. in artificial intelligence techniques in software engineering (ecai 2008 workshop). pp. 11–15. 2008. proc. edusymp 2010 8 / 8 introduction background realization the long-term vision motivation the basic architecture the role of m2n conclusion electronic communications of the easst volume 24 (2009) proceedings of the workshop the pragmatics of ocl and other textual specification languages at models 2009 preface 2 pages guest editors: j. cabot, j. chimiak-opoka, f. jouault, m. gogolla, a. knapp managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst preface jordi cabot, joanna chimiak–opoka, martin gogolla, frédéric jouault, alexander knapp in recent years, model-driven methodologies, approaches and languages (like qvt) emphasized the role that ocl has to play in all kinds of model-based software development. now, ocl is being used for quite different purposes (e.g., model verification and validation, code generation, test–driven development, transformations) and application domains (domain–specific languages, web semantics). successfully adapting ocl to all these different scenarios requires strong research on alternative notations/representations for ocl that simplify its application, improvements and clarifications on its semantics, modular language extensions, new evaluation techniques, mappings from ocl to other languages and formalisms and of course, the tools that will make all of this possible among many other relevant aspects. the papers presented in the workshop covered many of these interesting topics. all submitted papers were reviewed by three industrial or academic members from the program committee: • thomas baar, tech@spree, germany • achim brucker, sap, germany • manuel clavel, imdea software institute, spain • dan chiorean, university of cluj, romania • tony clark, thames valley university, uk • birgit demuth, technical university of dresden, germany • remco dijkman, eindhoven university of technology, the netherlands • robert france, university of fort collins, usa • heinrich hußmann, university of munich, germany • tihamer levendovszky, vanderbilt university, usa • richard mitchell, inferdata, uk • richard paige, university of york, uk • mark richters, astrium space transportation, germany • shane sendall, ibm, switzerland • pieter van gorp, university of eindhoven, the netherlands 1 / 2 volume 24 (2009) preface • burkhart wolff, lri, university paris–sud, france • steffen zschaler, lancaster university, uk during the workshop a broad spectrum of topics was discussed: syntax, semantics and pragmatics of the language, using formal or lightweight approaches, discussing core ocl aspects or its application in different domains and presented by a mixture of academic and industrial participants. several papers pointed out semantic inconsistencies with the current standard specification of the language and presented concrete solutions to those problems. this triggered a very interesting discussion on the ocl standardization process and on how the ocl workshop community could have a more tight cooperation with the standardization committee to increase the desired community–driven character of the ocl language and thus improve quality of the ocl specification by opening a communication channel to easily report on the issues and improvements discussed during the workshop. a second set of papers showed once again the broad application scenarios of ocl (this was also observed in other workshops and the main conference). papers in the workshop presented the use of ocl as constraint or query language and at the user model or metamodel levels (either in the context of mof, or as part of domain specific languages) and its usefulness as part of testing activities, model transformations and business process modelling. this lead to a long discussion regarding tool support for ocl, a key aspect in all application scenarios. in this context, an initiative for a community–driven specification and development of a new user–friendly ocl tool was presented. as part of discussion, attendees were asked to fill in questionnaires regarding the most important features a user–friendly ocl tool should have. everybody agreed on the importance of such initiative and was eager to propose new features for the tool to-do list (or better said wish list). architectural aspects and possible strategies for a collaborative-building effort of such a tool were also discussed. jordi cabot, joanna chimiak–opoka, martin gogolla, frédéric jouault, alexander knapp december 2009 proc. ocl 2009 2 / 2 checking unsatisfiability for ocl constraints electronic communications of the easst volume 24 (2009) proceedings of the workshop the pragmatics of ocl and other textual specification languages at models 2009 checking unsatisfiability for ocl constraints manuel clavel, marina egea and miguel a. garcı́a de dios 13 pages guest editors: j. cabot, j. chimiak-opoka, f. jouault, m. gogolla, a. knapp managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst checking unsatisfiability for ocl constraints manuel clavel1, marina egea2 and miguel a. garcı́a de dios3∗ 1 manuel.clavel@imdea.org 3 miguelangel.garcia@imdea.org imdea software institute, madrid, spain departamento de sistemas informáticos y computación universidad complutense de madrid, spain 2 marinae@inf.ethz.ch information security / zisc eth zürich, switzerland abstract: in this paper we propose a mapping from a subset of ocl into firstorder logic (fol) and use this mapping for checking the unsatisfiability of sets of ocl constraints. although still preliminary work, we argue in this paper that our mapping is both simple, since the resulting fol sentences closely mirror the original ocl constraints, and practical, since we can use automated reasoning tools, such as automated theorem provers and smt solvers to automatically check the unsatisfiability of non-trivial sets of ocl constraints. keywords: ocl, unsatisfiability, automated deduction, smt solvers 1 motivation the lack of tool support for ocl was pointed out in [cbc05] as a main cause for the limited adoption of the language in industry. since then, many initiatives have been brought to fruition and their outcomes are available to designers (see [dem05]). among the tool categories that have received significant attention are: • parsers: to check the syntactical well-formedness of an expression: e.g., the dresden ocl 2.0 parser [kon05, sof07]. • evaluators: to obtain the value of an expression within a contextual model: e.g., use [dat06], mdt ocl [hus08], and eos [ced08, dce08]. • translators: to map (for different purposes) an expression into a (logically equivalent) expression in other languages and/or formalisms: e.g., – ocl2sql [hei06, sof07] maps ocl constraints into sql queries; ∗ research partially supported by spanish mec projects tin2006-15660-c02-01 and by comunidad de madrid program s-0505/tic/0407. 1 / 13 volume 24 (2009) mailto:manuel.clavel@imdea.org mailto:miguelangel.garcia@imdea.org mailto:marinae@inf.ethz.ch checking unsatisfiability for ocl constraints – umltocsp [ccr07b, ccr07a] maps ocl constraints into constraint programming expressions to support automated bounded verification of uml class diagrams annotated with ocl constraints; – moment [crbg08] and itp-ocl [ce08] map ocl into equational logic (although using different approaches) to support automated evaluation of ocl expressions using term-rewriting. – key [bs07] includes a mapping of ocl into first-order logic to allow interactive reasoning about uml diagrams with ocl constraints. – hol-ocl [bru07, bw07] maps ocl into higher-order logic also to allow interactive reasoning about uml diagrams with ocl constraints. the work presented here belongs to the third category: it proposes a mapping from ocl to first-order logic, which is defined with the purpose of supporting (unbounded) unsatisfiability checks for ocl expressions using automated reasoning tools. in our view, being able to check the unsatisfiability of (sets of) ocl expressions is a powerful tool, since it will allow modelers to (among other tasks): • verify class invariants, by checking that they logically imply the expected constraints/properties; • verify method preconditions, by checking that the class invariants do not logically imply their negations; and • verify method postconditions, by checking that they do not logically imply the negation of (any of) the class invariants. however, also in our view, what will make an unsatisfiability checker not only powerful, but also practical, is being automated. given the undecidable nature of the full ocl language, one can only expect to have an automated unsatisfiability checker for a large class of ocl expressions. in this paper we do not attempt to define how large and/or interesting is the class of unsatisfiable ocl expressions that we are able to check automatically. nevertheless, we will argue that our mapping is both simple, since the resulting fol sentences closely mirror the original ocl constraints, and practical, since we can use existing automated theorem provers (e.g., prover9 [mcc06]) and/or smt solvers (e.g., yices [dm08]) to automatically check the unsatisfiability of non-trivial sets of ocl constraints. organization in section 2 we define our notion of unsatisfiability for ocl constraints. then, in section 3 we define our mapping from ocl to fol. next, in section 4 we report on our experience using two different automated reasoning tools for checking the unsatisfiability of (sets of) ocl constraints: namely, prover9 [mcc06] (an automated theorem prover) and yices [dm08] (an smt solver). we conclude with a discussion on related and future work. proc. ocl 2009 2 / 13 eceasst ! ! figure 1: a simple library-model. 2 unsatisfiability of ocl constraints in this section we introduce our notion of unsatisfiability for ocl constraints, as well as the examples that we will use in the following sections. the notion of unsatisfiability that we propose emphasizes the logical meaning of ocl constraints; in fact, it basically translates to ocl the standard notion of unsatisfiability for logic formulas. there are other notions of satisfiability/unsatisfiability for ocl constraints in the literature, which we will briefly discuss at the end of this section. in what follows, we denote by ocl constraint any ocl expression of type boolean. we do not assume that instances of models always have a finite a number of elements. definition 1 given a model (class diagram) m , and a set of ocl constraints φ, we say that φ is m -unsatisfiable if and only if there does not exist an m -instance (object diagram) o on which every constraint in φ evaluates to true. to illustrate this notion, we introduce the following example. table 1 shows a list of ocl constraints: they all refer to the simple class diagram library shown in figure 1. in this model, libraries contains books and books have authors, pages, and an isbn code. according to definition 1, the following subsets (among others) of the constraints shown in table 1 are library-unsatisfiable: {1,2}, {1,8}, {1,10}, {2,3}, {2,4}, {2,5}, {2,6}, {7,8}, {11, 13}, {12}, {14}, and {15}. notice that the subset {9,10,11} is not library-unsatisfiable: a library with just one book will satisfy these constraints. on the other hand, the subset {9,10,11,16} is indeed libraryunsatisfiable. notice also that the subset {17} is not library-unsatisfiable: a library with an infinite number of books will satisfy this constraint. on the other hand, the subset {17, 18} is indeed libraryunsatisfiable. as mentioned before, other notions of satisfiability/unsatisfiability of uml models with ocl constraints can be found in the literature. in particular, the notions used in [ccr07b, ct07] are those of weak and strong satisfiability (and related notions are also introduced in [bw07]). weak satisfiability means that there exists a finite instance of the model in which at least one class is populated with at least one element. strong satisfiability means that there exists a finite instance of the model in which all its classes are populated with at least one element. notice that, if a set of constraints is unsatisfiable (in our sense), then it can not be weak nor strong satisfiable. on the other hand, if a set of constraints is not weak nor strong satisfiable, it does not imply that is unsatisfiable (in our sense). 3 / 13 volume 24 (2009) checking unsatisfiability for ocl constraints 1. book.allinstances()−>isempty(). 2. book.allinstances()−>exists(x|x.pages > 300). 3. book.allinstances()−>forall(x|x.pages < 300). 4. book.allinstances()−>select(x|x.pages > 300)−>isempty(). 5. book.allinstances()−>reject(x|x.pages <= 300)−>isempty(). 6. book.allinstances()−>collect(x|x.pages)−>asset()−>forall(i|i < 300). 7. book.allinstances()−>forall(x|x.author−>isempty()). 8. author.allinstances()−>exists(a|a.books−>notempty()). 9. book.allinstances()−>forall(x,y|x<>y implies x.isbn<>y.isbn)). 10. book.allinstances()−>exists(x|book.allinstances()−>excluding(x) −>forall(y|y.isbn=x.isbn)). 11. book.allinstances()−>notempty(). 12. book.allinstances()−>exists(x|book.allinstances()−>excludes(x)). 13. book.allinstances()−>forall(x|book.allinstances()−>excluding(x)−>includes(x)). 14. book.allinstances()−>exists(x|book.allinstances()−>excluding(x)−>includes(x)). 15. book.allinstances()−>collect(x|x.author)−>asset()−>exists(y|y.books −>isempty())). 16. book.allinstances()−>size() > 1. 17. book.allinstances()−>forall(b|book.allinstances()−>exists(x|x.pages > b.pages)). 18. book.allinstances()−>size() = 2. table 1: list of constraints 3 a mapping from ocl to fol in this section we define a mapping from a subset of ocl into first-order logic (fol). given a set of ocl constraints, our mapping generates a set of fol formulas such that, if the resulting set is unsatisfiable, then the original set is also unsatisfiable. we will argue in section 4 that our mapping is both simple and practical. at this preliminary stage, we are not ready, however, to provide a formal proof of the correctness of this mapping (with respect to a well-defined formal semantics for ocl). proc. ocl 2009 4 / 13 eceasst ocl constraints specify properties that must be satisfied by a model. in order to do so in a concise way, ocl provides different constructors to refer to specific collections of elements. in a nutshell, our mapping is defined recursively over the structure of ocl expressions: • boolean-expressions are translated to formulas, which essentially mirror their logical structure; integer-expressions are basically copied; at this point, we do not consider stringexpressions. • collection-expressions are translated to predicates, whose meaning is defined by additional formulas generated by the mapping; at this point, we only consider set-expressions. • association-ends are translated by predicates, which are also defined by formulas generated by the mapping; at this point, we do not consider qualified associations. • attributes are translated by functions, which are left undefined by the mapping. the function map() below defines our mapping from ocl to fol. we do not attempt to cover here the full ocl language, but only a subset that is significantly enough so as to show the potential of our proposal. in what follows, given an iterator variable x, the expression x[ denotes a fresh new logical variable. similarly, given boolean-expressions boolexpr, object expressions objexpr, and setexpressions setexpr and setexpr′, the expressions [collect, setexpr, setexpr’][, [select, setexpr, boolexpr][, [reject, setexpr, boolexpr][, [including, setexpr, objexpr][, and [excluding, setexpr, objexpr][ denote fresh new predicate names. the auxiliary function name(), used in the definition of map(), is the one in charge of providing unique names for the fol predicates that translate the different ocl collection-expressions; it also translates ocl literal values by the corresponding fol terms. definition 2 the auxiliary function name() is defined by the following clauses: name(integer) = integer. name(−integer) = −integer. name(integer[+ | ∗]integer′) = integer[+ |×]integer′. name(var) = var. name(classid) = classid. name(objexpr.attr) = attr(name(objexpr)). name(objexpr.assocend) = assocend(name(objexpr)). name(classexpr.allinstances()) = name(classexpr). name(setexpr−>collect(x|setexpr′)) = [collect, setexpr, setexpr′][. name(setexpr−>select(x|boolexpr)) = [select, setexpr, boolexpr][. name(setexpr−>reject(x|boolexpr)) = [reject, setexpr, boolexpr][. name(setexpr−>excluding(x|objexpr)) = [excluding, setexpr, objexpr][. name(setexpr−>including(x|objexpr)) = [including, setexpr, objexpr][. the auxiliary function in coll(), also used in the definition of map(), basically returns the atomic formula that represents the application of a given predicate to a given number of arguments. 5 / 13 volume 24 (2009) checking unsatisfiability for ocl constraints definition 3 the auxiliary function in coll() is defined by the following clause: in coll(name, x) = name(x). finally, the auxiliary function make conj returns the conjunction of a given set of formulas. definition 4 the auxiliary function make conj() is defined by the following clauses: make conj( /0) = >. make conj({φ}) = φ . make conj({φ1, . . . , φn+1}) = φ1 ∧···∧φn+1. we are now ready to define our mapping from ocl to fol. first, the function map() generates, by default, the sentences defining the predicates that represent, in our mapping, the association-ends specified in the given model. definition 5 given an association between two classes class1 and class2, with associationends assocendclass1 and assocendclass2 , the function map() generates, by default, the following sentences: ∀(x, y)(assocendclass1 (x, y) ⇒ class1(y)). ∀(x, y)(assocendclass2 (x, y) ⇒ class2(y)). ∀(x, y)(assocendclass1 (x, y) ⇔ assocendclass2 (y, x)). next, we define the mapping from ocl boolean-expressions to fol formulas: essentially, we mirror the logical structure of the ocl expressions in the resulting fol formulas. in particular, we map iterator variables into logical variables, which are existentially or universally quantified depending on the iterator used. definition 6 the function map() on boolean-expressions is defined by clauses shown in figure 2. finally, we define the mapping from ocl collection-expressions to fol formulas. recall that collections are represented in our mapping by predicates. the function map() defines these predicates by generating the appropriate fol formulas. recall also that the only collectionexpressions currently covered by our mapping are the set-expressions. definition 7 the function map() on collection-expressions is defined by clauses shown in figure 3. 4 examples in this section, we argue, using a set of examples, that our mapping is both simple and practical. proc. ocl 2009 6 / 13 eceasst map(true) = {>}. map(false) = {⊥}. map(intexpr[> | < | >= | <= | = | <>]intexpr′) = {name(intexpr)[>|>|>=|<=|=|<>]name(intexpr′)}. map(not boolexpr) = {¬(make conj(map(boolexpr)))}. map(boolexpr and boolexpr′) = {make conj(map(boolexpr))∧make conj(map(boolexpr′))}. map(boolexpr or boolexpr′) = {make conj(map(boolexpr))∨make conj(map(boolexpr′))}. map(boolexpr implies boolexpr′) = {make conj(map(boolexpr)) ⇒ make conj(map(boolexpr′))}. map(setexpr−>isempty()) = {∀(x[)(¬(in coll(name(setexpr), x[)))} ∪ map(setexpr). map(setexpr−>notempty()) = {∃(x[)(in coll(name(setexpr), x[))} ∪ map(setexpr). map(setexpr−>excludes(objexpr)) = {¬(in coll(name(setexpr), name(objexpr)))} ∪ map(setexpr). map(setexpr−>includes(objexpr)) = {in coll(name(setexpr), name(objexpr))} ∪ map(setexpr). map(setexpr−>exists(x|boolexpr)) = {∃(x[)(in coll(name(setexpr), x[) ∧ make conj(map(boolexpr[x 7→ x[])))} ∪ map(setexpr). map(setexpr−>forall(x|boolexpr)) = {∀(x[)(in coll(name(setexpr), x[) ⇒ make conj(map(boolexpr[x 7→ x[])))} ∪ map(setexpr). figure 2: definition: map() on boolean-expressions. 7 / 13 volume 24 (2009) checking unsatisfiability for ocl constraints map(classid.allinstances()) = /0. map(setexpr−>collect(x|setexpr′)−>asset()) = {∀(y[)(in coll(name(setexpr−>collect(x|setexpr′), y[) ⇔∃(w[)(in coll(name(setexpr), w[)∧ in coll(name(setexpr′[x 7→ w[]), y[))))}. map(setexpr−>collect(x|objexpr)−>asset()) = {∀(y[)(in coll(name(setexpr−>collect(x|objexpr)), y[) ⇔∃(w[)(in coll(name(setexpr), w[)∧ y[ = name(objexpr[x 7→ w[])))}. map(setexpr−>select(x|boolexpr)) = {∀(y[)(in coll(name(setexpr−>select(x|boolexpr[x 7→ y[])), y[) ⇔ (in coll(name(setexpr), y[)∧ make conj(map(boolexpr[x 7→ y[]))))}. map(setexpr−>reject(x|boolexpr)) = {∀(y[)(in coll(name(setexpr−>reject(x|boolexpr[x 7→ y[])), y[) ⇔ (in coll(name(setexpr), y[)∧ ¬(make conj(map(boolexpr[x 7→ y[])))))}. map(setexpr−>excluding(objexpr)) = {∀(y[)(in coll(name(setexpr−>excluding(objexpr)), y[) ⇔ (in coll(name(setexpr), y[)∧y[ 6= name(objexpr)))}. map(setexpr−>including(objexpr)) = {∀(y[)(in coll(name(setexpr−>including(objexpr)), y[) ⇔ (in coll(name(setexpr), y[)∨y[ = name(objexpr)))}. figure 3: definition: map() on collection-expressions. . proc. ocl 2009 8 / 13 eceasst 4.1 mapping constraints with respect to other mappings previously proposed, one advantage of our mapping is that, in addition to be mechanizable, the resulting formulas are similar to the original ocl constraints, both in their size and in their logical structure. in this sense, we claim that our mapping is simple. to illustrate this claim, we show in figure 4 the fol formulas that the function map() generates to define the predicates that represent, in our mapping, the two association-ends in the librarymodel. more interestingly, we show in figure 5 the fol formulas resulting from applying the function map() to a representative subset of the constraints listed in table 1. ∀(x, y)(books(x, y) ⇒ book(y)) ∀(x, y)(author(x, y) ⇒ author(y)) ∀(x, y)(books(x, y) ⇔ author(y, x)) figure 4: example: mapping association-ends. 4.2 checking unsatisfiability another crucial advantage of our mapping is that the resulting formulas can be checked for unsatisfiability using automated reasoning tools. to illustrate our point, we have tried to automatically prove the unsatisfiability of different subsets of the constraints shown in table 1 using prover9 [mcc06] (an automated theorem prover) and yices [dm08] (an smt solver). the results are shown in table 2. both tools finished their tasks in less than a second, running on a standard laptop computer. in our experiments, we used both tools with their default (command) options. prover9 [mcc06] is a resolution/paramodulation automated theorem prover for first-order and equational logic. it uses two default limits which, although good in practice, can prevent proofs from being found. not surprisingly (since it does not support integer arithmetic), prover9 could not automatically prove the unsatisfiability of some of the subsets of constraints in our experiment. yices [dm08] is a high-performance smt solver that decides the satisfiability of propositional formulas that mix uninterpreted function symbols and equality with interpreted symbols from various theories, in particular for linear real and integer arithmetic, but also for recursive datatypes, tuples, records, lambda expressions and quantifiers among others. although yices is not complete when quantifiers are used, it was able to automatically prove the unsatisfiability of all the subsets of constraints in our experiment. this result is certainly encouraging for our purposes; moreover, we expect to take advantage of its decision procedures for recursive datatypes, tuples, and records, in order to prove the unsatisfiability of more complex subsets of ocl constraints. 9 / 13 volume 24 (2009) checking unsatisfiability for ocl constraints (1) map(book.allinstances()−>isempty()) = {∀(x)(¬book(x))}. (2) map(book.allinstances()−>exists(x|x.pages > 300)) = {∃(x)(book(x)∧(pages(x) > 300))}. (3) map(book.allinstances()−>forall(x | x.pages < 300)) = {∀(x)(book(x) ⇒ (pages(x) < 300))}. (4) map(book.allinstances()−>select(x|x.pages > 300)−>isempty()) = {∀(x)¬(select1(x)), ∀(x)(select1(x) ⇔ (book(x)∧(pages(x) > 300)))}. (7) map(book.allinstances()−>forall(x|x.author−>isempty())) = {∀(x)(book(x) ⇒∀(y)(¬(author(x, y)}. (8) map(author.allinstances()−>exists(a|a.books−>notempty())) = {∃(a)(author(a)∧∃(x)(books(a, x)))}. (9) map(book.allinstances()−>forall(x,y|x<>y implies x.isbn<>y.isbn)) = {∀(x)(book(x) ⇒∀(y)(book(y) ⇒ (x 6= y ⇒ isbn(x) 6= isbn(y))))}. (10) map(book.allinstances()−>exists(x|book.allinstances()−>excluding(x) −>forall(y|y.isbn=x.isbn))) = {∃(x)(book(x)∧[∀(y)(excluding1(y) ⇒ (isbn(x) = isbn(y))) ∧∀(z)(excluding1(z) ⇔ (book(z)∧z 6= x))])}. (11) map(book.allinstances()−>notempty()) = {∃(x)(book(x))}. (12) map(book.allinstances()−>exists(x|book.allinstances()−>excludes(x))) = {∃(x)(book(x)∧¬(book(x)))}. (13) map(book.allinstances()−>forall(x|book.allinstances()−>excluding(x) −>includes(x))) = {∀(x)((book(x) ⇒ excluding1(x)) ∧∀(y)((book(y)∧y 6= x) ⇔ excluding1(y)))}. (14) map(book.allinstances()−>exists(x|book.allinstances()−>excluding(x) −>includes(x))) = {∃(x)(book(x)∧excluding1(x) ∧(∀(y)((book(y)∧y 6= x) ⇔ excluding1(y))))}. (15) map(book.allinstances()−>collect(x|x.author)−>asset() −>exists(y|y.books−>isempty())) = {∃(y)(collect1(y)∧∀(x)(¬(books(y, x))), ∀(z)(collect1(z) ⇔∃(w)(book(w)∧author(w, z))))}. figure 5: example: mapping constraints. 5 related work as already mentioned, there are other mappings from ocl into different languages and/or formalisms, each one with its own purposes and target reasoning tool, which makes difficult to do a general comparison. we discuss here only those proposals that support (in one way or another) our same objectives, namely, checking unsatisfiability for ocl constraints. in a nutshell, none of these mappings supports both unbounded and automated unsatisfiability checks for ocl constraints, as our mapping does, for a significantly subset of the language. proc. ocl 2009 10 / 13 eceasst {1,2} {1,8} {1,10} {2,3} {2,4} {2,5} {2,6} {7,8} {11,13} {12} {14} {15} prover9 √ √ √ • √ • • √ √ √ √ √ yices √ √ √ √ √ √ √ √ √ √ √ √ table 2: case study: checking unsatisfiability the key tool [bs07] is able to generate proof obligations from checking different properties of uml models with ocl constraints (e.g., invariant preservation), using a translation of ocl into first order predicate logic. to the best of our knowledge, the key tool translates ocl collection expressions into first order terms, introducing additional axioms in order to constrain the interpretation of the new function symbols which represent the ocl collections [bks02].1 users can then interact with the key theorem prover to logically reason about their uml models. a limited amount of automated reasoning is provided, which is far from what is currently offered by modern smt solvers. hol-ocl [bw07] is an interactive proof environment for ocl. it is implemented as a shallow embedding of ocl into higher-order logic (hol) within the theorem prover isabelle. the resulting translations may be hard to understand by standard software engineers. also, since the amount of automated reasoning which is supported by hol-ocl is limited, software engineers may find hard to use this tool when reasoning about their uml models. umltocsp [ccr07b] provides bounded automatic verification of uml models annotated with ocl constraints. the users must limit the search space by explicitly indicating the number of objects in each class, the number of links of each association and the possible values of each attribute. when the tool can not find a satisfying instance within the specified search space, this does not means that the property does not hold: it can still hold for values outside the search space (and the user may try to verify the property with wider intervals). uml2alloy [ana, abgr07] is a front-end that transforms uml diagrams annotated with ocl constraints into the alloy notation. it translates the model into a boolean expression, which is then analysed by the sat solvers implemented within alloy. as in the case of umltocsp, the domain must be bounded by the user before analysing the model. 6 conclusions and future work in this paper we have proposed a mapping from a significant subset of ocl into first-order logic (fol). although this is still preliminary work, we have argued that our mapping is both simple, since the resulting fol sentences closely mirror the original ocl constraints, and practical, since we can use automated theorem provers (e.g., prover9) and/or smt solvers (e.g., yices) to automatically check the unsatisfiability of non-trivial sets of ocl constraints. in the near future, we plan to extend our mapping to deal with larger subsets of ocl. since this is preliminary work, the list of currently missing features is certainly large: we discuss here 1 since the result is often lengthy and hard to read, it was suggested (via some examples) in [bks02] to use, as an alternative, a predicative translation to first order formulas. again, to the best of our knowledge, this line of research has not been followed up within the key community. also the examples shown in [bks02] do not provide enough information so as to understand how this predicative translation will deal with other cases, like collect-expressions, and including|excluding-expressions, or with nested-iterator expressions. 11 / 13 volume 24 (2009) checking unsatisfiability for ocl constraints only the most important ones. first, we should be able to deal with bags. our idea here is to translate bag-expressions using predicates, as we do for set-expressions, but with an additional argument indicating the number of occurrences of a given element in the bag. of course, the proposed mapping for the different collect-operations will have to be modified accordingly. second, we should be able to deal with generalizations. the idea here is to add, by default, the expected sentences formalizing that every element in the subclass-collection also belongs to the super-class collection. third, we should be able to deal with size-expressions. here, we do not have yet a general solution: dealing with constraints like (16) and (18) in table 1 and, in general, with constraints that simply restrict the multiplicity of collections, is rather simple; defining a mapping for arbitrary size-expressions appearing anywhere inside constraints requires further investigation. finally, it would be interesting to define a mapping for general collection-expressions and for tuple-expressions, and to explore the capabilities of smt solvers to automatically check the unsatisfiability of the resulting formulas. in the long term, we should prove, of course, the correctness of our mapping with respect to a formal semantics of the ocl language. bibliography [abgr07] k. anastasakis, b. bordbar, g. georg, i. ray. uml2alloy: a challenging model transformation. in acm/ieee 10th international conference on model driven engineering languages and systems (models 2007). lncs 4735. 2007. [ana] k. anastasakis. uml2alloy. http://www.cs.bham.ac.uk/∼bxb/uml2alloy. [bks02] b. beckert, u. keller, p. h. schmitt. translating the object constraint language into first-order predicate logic. in proceedings, verify, workshop at federated logic conferences (floc), copenhagen, denmark. 2002. [bru07] a. d. brucker. an interactive proof environment for object oriented specifications. phd thesis, eth zurich, 2007. [bw07] a. d. brucker, b. wolff. the hol-ocl tool. http://www.brucker.ch/, 2007. eth zurich. [bs07] b. beckert, r. hähnle, p. h. schmitt (eds.). verification of object-oriented software: the key approach. lncs 4334. springer-verlag, 2007. [cbc05] d. chiorean, m. bortes, d. corutiu. proposals for a widespread use of ocl. in tool support for ocl and related formalisms needs and trends– models’05 conference workshop. pp. 68–82. 2005. [ccr07a] j. cabot, r. clarisó, d. riera. a tool for the formal verification of uml/ocl models using constraint programming. 2007. http://gres.uoc.edu/umltocsp/. [ccr07b] j. cabot, r. clarisó, d. riera. umltocsp: a tool for the formal verification of uml/ocl models using constraint programming. in ase ’07: proceedings of the twenty-second ieee/acm international conference on automated software engineering. acm, new york, ny, usa, 2007. proc. ocl 2009 12 / 13 http://www.cs.bham.ac.uk/~bxb/uml2alloy http://www.brucker.ch/ http://gres.uoc.edu/umltocsp/ eceasst [ce08] m. clavel, m. egea. the itp/ocl tool. http://maude.sip.ucm.es/itp/ocl/, 2008. [ced08] m. clavel, m. egea, m. a. g. de dios. building an efficient component for ocl evaluation. eceasst 15, 2008. [crbg08] j. carsı́, i. ramos, a. boronat, a. gómez. the moment: model management framework project. http://moment.dsic.upv.es, 2008. [ct07] j. cabot, e. teniente. transformation techniques for ocl constraints. science computer programming 68(3):152–168, 2007. [dat06] database systems group. the uml specification environment (use) tool. 2006. http://www.db.informatik.uni-bremen.de/projects/use/. [dce08] m. a. g. de dios, m. clavel, m. egea. the eye ocl software (eos). 2008. http: //maude.sip.ucm.es/eos. [dem05] b. demuth. the ocl portal. http://www-st.inf.tu-dresden.de/ocl/, 2005. [dm08] b. dutertre, l. moura. yices: an smt solver. http://yices.csl.sri.com/, 2008. [hei06] f. heidenreich. ocl-codegenerierung für deklarative sprachen. master’s thesis, university of dresden, march 2006. http://dresden-ocl.sourceforge.net. [hus08] k. hussey. mdt-ocl. http://www.eclipse.org, 2008. [kon05] a. konermann. the parser subsystem of the dresden ocl 2.0 toolkit design and implementation. http://dresden-ocl.sourceforge.net/publications.html, 2005. [mcc06] w. mccune. prover9. http://www.cs.unm.edu/∼mccune/prover9/manual/ june-2006c/, 2006. [sof07] software technology group. the ocl 2.0 dresden toolkit. http://sourceforge.net, 2007. 13 / 13 volume 24 (2009) http://maude.sip.ucm.es/itp/ocl/ http://moment.dsic.upv.es http://www.db.informatik.uni-bremen.de/projects/use/ http://maude.sip.ucm.es/eos http://maude.sip.ucm.es/eos http://www-st.inf.tu-dresden.de/ocl/ http://yices.csl.sri.com/ http://dresden-ocl.sourceforge.net http://www.eclipse.org http://dresden-ocl.sourceforge.net/publications.html http://www.cs.unm.edu/~mccune/prover9/manual/june-2006c/ http://www.cs.unm.edu/~mccune/prover9/manual/june-2006c/ http://sourceforge.net motivation unsatisfiability of ocl constraints a mapping from ocl to fol examples mapping constraints checking unsatisfiability related work conclusions and future work safe integration of annotated components in open source projectsthis work was supported by project cross, funded by fct (ptdc/eia-cco/108995/2008) electronic communications of the easst volume 33 (2010) proceedings of the fourth international workshop on foundations and techniques for open source software certification (opencert 2010) safe integration of annotated components in open source projects sérgio areias, daniela da cruz, pedro rangel henriques, jorge sousa pinto 17 pages guest editors: luis s. barbosa, antonio cerone, siraj a. shaikh managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst safe integration of annotated components in open source projects∗ sérgio areias1, daniela da cruz1, pedro rangel henriques1, jorge sousa pinto1 departamento de informática, universidade do minho, braga, portugal1 abstract: the decision of using existing software components versus building from scratch custom software is one of the most complex and important choices of the entire development/integration process. however, the reuse of software components raises a spectrum of issues, from requirements negotiation to product selection and integration. the correct tradeoff is reached after having analyzed advantages and issues correlated to the reuse. despite the reuse failures in real cases, many efforts have been made to make this idea successful. in this context of software reuse in open source projects, we address the problem of reusing annotated components proposing a rigorous approach to assure the quality of the application under construction. we introduce the concept of caller-based slicing as a way of certifying that the integration of a component annotated with a contract into a system will preserve the correct behavior of the former, avoiding malfunctioning after integration. to complement the efforts done and the benefits of slicing techniques, there is also a need to find an efficient way to visualize the main program with the annotated components and the slices. to take full profit of visualization, it is crucial to combine the visualization of the control/data flow with the textual representation of source code. to attain this objective, we extend the notions of system dependence graph and slicing criterion to cope with annotations. keywords: caller-based slicing, annotated system dependency graph 1 introduction reuse is a very simple an natural concept, however in practice is not so easy. according to the literature, selection of reusable components has proven to be a difficult task [ms93]. sometimes this is due to the lack of maturity on supporting tools that should easily find a component on a repository or library [sv03]. also, non experienced developers tend to reveal difficulties when describing the desired component in technical terms. most of the times, this happens because they are not sure of what they want to find [sv03, ss07]. another barrier is concerned with reasoning about component similarities in order to select the one that best fits in the problem solution; usually this is an hard mental process [ms93]. integration of reusable components has also proven to be a difficult task, since the process of understanding and adapting components is hard, even for experienced developers [ms93]. ∗ this work was supported by project cross, funded by fct (ptdc/eia-cco/108995/2008) 1 / 17 volume 33 (2010) safe integration of annotated components in open source projects1 another challenge to component reuse is to certify that the integration of such component in a open-source software system (oss) keeps it correct. this is, to verify that the way the component is invoked will not lead to an incorrect behavior. a strong demand for formal methods that help programmers to develop correct programs has been present in software engineering for some time now. the design by contract (dbc) approach to software development [mey92] facilitates modular verification and certified code reuse. the contract for a software component (a sub-program, or commonly, a procedure) can be regarded as a form of enriched software documentation composed of annotations (pre-conditions, post-conditions and invariants) that fully specifies the behavior of that component. so, a welldefined annotation can give us most of the information needed to integrate a reusable component in a oss, as it contains crucial information about some constraints to obtain the correct behavior from the component. in this context, we say that the annotations (the pre-, post-conditions and invariants that form the contract) can be used to verify that each component invocation is valid (preserves the contract); in that way, we can guarantee that a correct system will still be correct after the integration of that component. this is the motivation for our research: to find a way to help on the safety reuse of components. this article introduces the concept of caller-based slicing, an algorithm that takes into account the calls to an annotated component in order to certify that it is being correctly used. to support the idea, we also introduce gamapolarslicer, a tool that implements such algorithm: to identify when an invocation is violating the component annotation; and to display a diagnostic or guidelines to correct it. the remainder of paper is composed of 8 sections. section 2 is devoted to basic concepts crucial to the understanding of the rest of the paper: the notions of slicing and system dependency graph are introduced. section 3 formalizes the definition of caller-based slicing that supports our approach to safety reused of annotated components. section 4 defines the concept of annotated system dependency graph (sdga), used for the visual analysis of the slices and pre-conditions preservation. section 5 illustrates the main idea through a concrete example. section 6 gives a general overview of gamapolarslicer, introducing its architecture, functionalities and implementation details. section 7 discusses related work on slicing programs with annotated components as it is the main idea behind our proposal. section 8 discusses related work on visualization of (sliced) programs, because we strongly believe that good visual tool is crucial for software analysis. then the paper is closed in section 9. 2 basic concepts in this section we introduce both the original concepts of slicing and system dependency graph. 2.1 slicing since weiser first proposed the notion of slicing in 1979 in his phd thesis [wei79], hundreds of papers have been proposed in this area. tens of variants have been studied, as well was algorithms to compute them. different notions of slicing have different properties and different proc. opencert 2010 2 / 17 eceasst applications. these notions vary from weiser’s syntax-preserving static slicing to amorphous slicing which is not syntax-preserving; algorithms can be based on dataflow equations, information flow relations or dependence graphs. slicing was first developed to facilitate program debugging [m.93, ads93, wl86], but it is then found helpful in many aspects of the software development life cycle, including software testing [bin98, hd95], software metrics [ot93, lak93], software maintenance [clm96, gl91], program comprehension [lfm96, hhf+01], component re-use [be93, clm95], program integration [bhr95, hpr89] and so on. program slicing, in its original version, is a decomposition technique that extracts from a program the statements relevant to a particular computation. a program slice consists of the parts of a program that potentially affect the values computed at some point of interest referred to as a slicing criterion. definition 1 (slicing criterion) a static slicing criterion of a program p consists of a pair c = (p,vs), where p is a statement in p and vs is a subset of the variables in p. a slicing criterion c = (p,vs) determines a projection function which selects from any state trajectory only the ordered pairs starting with p and restricts the variable-to-value mapping function σ to only the variables in vs. definition 2 (state trajectory) let c = (p,vs) be a static slicing criterion of a program p and t =< (p1,σ1), (p2,σ2), ...,(pk,σk) > a state trajectory of p on input i. ∀i,1 ≤ i ≤ k: pro j′c(pi,σi) = { λ i f pi 6= p < (pi,σi|vs) > i f pi = p where σi|vs is σi restricted to the domain vs, and λ is the empty string. the extension of pro j′ to the entire trajectory is defined as the concatenation of the result of the application of the function to the single pairs of the trajectory: pro jc(t ) = pro j ′ c(p1,σ1)...pro j ′ c(pk,σk) a program slice is therefore defined behaviorally as any subset of a program which preserves a specified projections in its behavior. definition 3 (static slicing) a static slice of a program p on a static slicing criterion c = (p,vs) is any syntactically correct and executable program p′ that is obtained from p by deleting zero or more statements, and whenever p halts, on input i, with state trajectory t , then p′ also halts, with the same input i, with the trajectory t ′, and pro jc(t ) = pro jc(t ′). related work of slicing programs taking into account the annotations of a program will be referred in section 7. 3 / 17 volume 33 (2010) safe integration of annotated components in open source projects2 2.2 system dependency graph the use of dependency graphs to visualize the data and control flow of a program has been widely accepted in the last years (section 8). before exploring the use dependency graphs for visualization and comprehension, we present below the definitions of procedure dependency graph and system dependency graph. definition 4 (procedure dependence graph) given a procedure p, a procedure dependence graph, pdg, is a graph whose vertices are the individual statements and predicates (used in the control statements) that constitute the body of p, and the edges represent control and data dependencies among the vertices. in the construction of the pdg, a special node, considered as a predicate, is added to the vertex set: it is called the entry node and is decorated with the procedure name. a control dependence edge goes from a predicate node to a statement node if that predicate condition the execution of the statement. a data dependence edge goes from an assignment statement node to another node if the variable assigned at the source node is used (is referred to) in the target node. additionally to the natural vertices defined above, some extra assignment nodes are included in the pdg linked by control edges to the entry node: we include an assignment node for each formal input parameter, another one for each formal output parameter, and another one for each returned value — these nodes are connect to all the other by data edges as stated above. moreover, we proceed in a similar way for each call node; in that case we add assignment nodes, linked by control edges to the call node, for each actual input/output parameter (representing the value passing process associated with a procedure call) and also a node to receiving the returned values. definition 5 (system dependence graph) a system dependence graph, sdg, is a collection of procedure dependence graphs, pdgs, (one for the main program, and one for each component procedure) connected together by two kind of edges: control-flow edges that represent the dependence between the caller and the callee (an edge goes from the call statement into the entry node of the called procedure); and data-flow edges that represent parameter passing and return values, connecting actualin,out parameter assignment nodes with formalin,out parameter assignment nodes. 3 caller-based slicing in this section, we introduce our slicing algorithm. we start by extending the notion of static slicing and slicing criterion to cope with the contract of a program. definition 6 (annotated slicing criterion) an annotated slicing criterion of a program p consists of a triple ca = (a,si,vs), where a is an annotation of pa (the annotated callee), si correspond to the statement of p calling pa and vs is a subset of the variables in p (the caller), that are the actual parameters used in the call and constrained by α or δ . proc. opencert 2010 4 / 17 eceasst definition 7 (caller-based slicing) a caller-based slice of a program p on an annotated slicing criterion ca = (α,call f ,vs) is any subprogram p′ that is obtained from p by deleting zero or more statements in a two-pass algorithm: 1. a first step to execute a backward slicing with the traditional slicing criterion c = (call f ,vs) retrieved from ca — call f corresponds to the call statement under consideration, and vs corresponds to the set of variables present in the invocation call f and intervening in the precondition formula (α ) of f 2. a second step to check if the statements preceding the call f statement will lead to the satisfaction of the callee precondition. for the second step in the two-pass algorithm, in order to check which statements are respecting or violating the precondition we are using abstract interpretation, in particular symbolic execution. according to the original idea of james king in [kin76], symbolic execution can be described as “instead of supplying the normal inputs to a program (e.g. numbers) one supplies symbols representing arbitrary values. the execution proceeds as in a normal execution except that values may he symbolic formulas over the input symbols.” using symbolic execution we will be able to propagate the precondition of the function being called through the statements preceding the call statement. in particular, to integrate symbolic execution with our system, we are thinking to use javapathfinder [apv07]. javapathfinder is a tool than can perform program execution with symbolic values. moreover, javapathfinder can mix concrete and symbolic execution, or switch between them. javapathfinder has been used for finding counterexamples to safety properties and for test input generation. to sum up, the main goal of our caller-based slicing algorithm is to facilitate the use of annotated components by discovering statements that are critical for the satisfaction of the precondition, i.e., that do not verify the precondition or whose statements values can lead to its non-satisfaction (a kind of tracing call analysis of annotated procedures). 4 annotated system dependency graph (sdga) in this section we present the definition of annotated system dependency graph, sdga for short, that is the internal representation that supports our slicing-based code analysis approach. definition 8 (annotated system dependence graph) an annotated system dependency graph, sdga, is a sdg in which some nodes of its constituent pdgs are annotated nodes. definition 9 (annotated node) given a pdg for an annotated procedure pa, an annotated node is a pair < si,a > where si is a statement or predicate (control statement or entry node) in pa, and a is its annotation: a pre-condition α , a post-condition ω , or an invariant δ . the differences between a traditional sdg and an sdga are: • each procedure dependency graph (pdg) is decorated with a precondition as well as with a postcondition in the entry node; 5 / 17 volume 33 (2010) safe integration of annotated components in open source projects3 • the while nodes are also decorated with the loop invariant (or true, in case of invariant absence); • the call nodes include the preand postcondition of the procedure to be called (or true, in case of absence); these annotations are retrieved from the respective pdg and instantiated as explained below. we can take advantage from the call linkage dictionary present in the sdga (inherited from the underlying sdg) to associate the variables used in the calling statement (the actual parameters) with the formal parameters involved in the annotations. given a program and an annotated slicing criterion, we identify the node of the respective sdga that corresponds to the criterion (yellow node in figure 1). after building the respective caller-based slice, the critic statements will be highlighted in the graph, making easier to identify the statements violating the precondition (red nodes in figure 1). 5 an illustrative example to illustrate the previous definitions and our proposal, consider the program listed below (example 1) that computes the maximum difference among student ages in a class. example 1 diffage p u b l i c i n t d i f f a g e ( ) { i n t min = s y s t e m . i n t 3 2 . maxvalue , max = s y s t e m . i n t 3 2 . minvalue , d i f f ; s y s t e m . o u t . p r i n t ( ” number o f e l e m e n t s : ” ) ; i n t num = s y s t e m . i n . r e a d ( ) ; i n t [ ] a = new i n t [ num ] ; f o r ( i n t i = 0 ; i y)? \result == x : \result == y @∗/ 1: public int min(int x, int y) { 2: int res; 3: res = x−y; 4: return ((res > 0)? y : x); 5: } example 3 max /∗@ requires x ≥ 0 && y ≥ 0 @ ensures (x > y)? \result == y : \result == x @∗/ 1: public int max(int x, int y) { 2: int res; 3: res = x−y; 4: return ((res > 0)? x : y); 5: } example 4 backward slice for a[i] i n t [ ] a = new i n t [ num ] ; f o r ( i n t i = 0 ; i 3.3.co;2-0 http://dx.doi.org/http://dx.doi.org/10.1002/(sici)1096-908x(199605)8:3<145::aid-smr127>3.3.co;2-0 http://dx.doi.org/http://doi.acm.org/10.1145/372202.372784 citeseer.ist.psu.edu/gallagher91using.html safe integration of annotated components in open source projects12 [go97] k. gallagher, l. o’brien. reducing visualization complexity using decomposition slices. in proc. software visualisation work. pp. 113–118. department of computer science, flinders university, adelaide, australia, 11–12 dezembro 1997. [hd95] m. harman, s. danicic. using program slicing to simplify testing. software testing, verification & reliability 5(3):143–162, 1995. citeseer.ist.psu.edu/100763.html [hhf+01] m. harman, r. hierons, c. fox, s. danicic, j. howroyd. pre/post conditioned slicing. icsm 00:138, 2001. doi:http://doi.ieeecomputersociety.org/10.1109/icsm.2001.972724 [hpr89] s. horwitz, j. prins, t. reps. integrating noninterfering versions of programs. acm trans. program. lang. syst. 11(3):345–387, 1989. doi:http://doi.acm.org/10.1145/65979.65980 [kin76] j. c. king. symbolic execution and program testing. commun. acm 19(7):385–394, 1976. doi:http://doi.acm.org/10.1145/360248.360252 [kri04] j. krinke. visualization of program dependence and slices. in icsm ’04: proceedings of the 20th ieee international conference on software maintenance. pp. 168– 177. ieee computer society, washington, dc, usa, 2004. [lak93] a. lakhotia. rule-based approach to computing module cohesion. in icse ’93: proceedings of the 15th international conference on software engineering. pp. 35–44. ieee computer society press, los alamitos, ca, usa, 1993. [lc04] g. t. leavens, y. cheon. design by contract with jml. 2004. [lfm96] a. d. lucia, a. r. fasolino, m. munro. understanding function behaviors through program slicing. in proceedings of the 4th workshop on program comprehension. pp. 9–18. 1996. citeseer.ist.psu.edu/delucia96understanding.html [m.93] k. m. interprocedural dynamic slicing with applications to debugging and testing. phd thesis, linkoping university, sweden, 1993. [mey92] b. meyer. applying ”design by contract”. computer 25(10):40–51, 1992. doi:http://dx.doi.org/10.1109/2.161279 [ms93] n. a. m. maiden, a. g. sutcliffe. people-oriented software reuse: the very thought. in advances in software reuse second international workshop on software reusability. pp. 176–185. ieee computer society press, 1993. [ot93] l. ottenstein, j. thuss. slice based metrics for estimating cohesion. 1993. citeseer.ist.psu.edu/ott93slice.html proc. opencert 2010 16 / 17 citeseer.ist.psu.edu/100763.html http://dx.doi.org/http://doi.ieeecomputersociety.org/10.1109/icsm.2001.972724 http://dx.doi.org/http://doi.acm.org/10.1145/65979.65980 http://dx.doi.org/http://doi.acm.org/10.1145/360248.360252 citeseer.ist.psu.edu/delucia96understanding.html http://dx.doi.org/http://dx.doi.org/10.1109/2.161279 citeseer.ist.psu.edu/ott93slice.html eceasst [san95] g. sander. graph layout through the vcg tool. in gd ’94: proceedings of the dimacs international workshop on graph drawing. pp. 194–205. springer-verlag, london, uk, 1995. [ss07] s. g. shiva, l. a. shala. software reuse: research and practice. in itng. pp. 603– 609. ieee computer society, 2007. http://dblp.uni-trier.de/db/conf/itng/itng2007.html#shivas07 [sv03] k. sherif, a. vinze. barriers to adoption of software reuse a qualitative study. inf. manage. 41(2):159–175, 2003. doi:http://dx.doi.org/10.1016/s0378-7206(03)00045-4 [wei79] m. d. weiser. program slices: formal, psychological, and practical investigations of an automatic program abstraction method. phd thesis, ann arbor, mi, usa, 1979. [wl86] m. weiser, j. lyle. experiments on slicing-based debugging aids. in papers presented at the first workshop on empirical studies of programmers on empirical studies of programmers. pp. 187–197. ablex publishing corp., norwood, nj, usa, 1986. 17 / 17 volume 33 (2010) http://dblp.uni-trier.de/db/conf/itng/itng2007.html#shivas07 http://dx.doi.org/http://dx.doi.org/10.1016/s0378-7206(03)00045-4 introduction basic concepts slicing system dependency graph caller-based slicing annotated system dependency graph (sdga) an illustrative example gamapolarslicer architecture implementation related work — slicing related work — visualization of (sliced) programs conclusion efficient implementation of automaton functors for the verification of graph transformation systems electronic communications of the easst volume 38 (2010) proceedings of the fifth international conference on graph transformation doctoral symposium (icgt-ds 2010) efficient implementation of automaton functors for the verification of graph transformation systems christoph blume 15 pages guest editor: andrea corradini managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst efficient implementation of automaton functors for the verification of graph transformation systems christoph blume∗ abteilung für informatik und angewandte kognitionswissenschaft, universität duisburg-essen, germany christoph.blume@uni-due.de abstract: in this paper we show new applications for recognizable graph languages to invariant checking. furthermore we present details about techniques we used for an implementation of a tool suite for (finite) automaton functors which generalize finite automata to the setting of recognizable (graph) languages. in order to develop an efficient implementation we take advantage of binary decision diagrams (bdds). keywords: graph transformation, recognizable graph languages, invariants, implementation of automaton functors, binary decision diagrams 1 introduction the theory of regular languages is the basis of a number of analysis techniques, such as regular model checking [6], termination analysis [14] and reachability analysis [13]. the notion of regularity has been straightforwardly generalized to regular graph languages – which are also called recognizable graph languages – in different ways [2, 10, 7, 8], but all leading to the same notion of recognizability. very roughly, one can say that a property (or language) of graphs is recognizable whenever it can be derived inductively via an arbitrary decomposition of the graph. in addition the size of the information “transported” over an interface in the decomposition must be bounded by a function which is dependent only on the size of the interface. alternatively recognizability can be defined via a family of myhill-nerode style congruences of finite index, i.e., congruences with finitely many equivalence classes. in this paper, we use the notion of recognizability by bruggink and könig [8] which is based on a categorical definition of recognizability in terms of so-called automaton functors, which are a generalization of non-deterministic finite automata. an advantage of this automaton-oriented notion of recognizability is that many familiar constructions on finite automata, such as the determinization, minimization as well as closure properties under boolean operations, can be straightforwardly generalized to automaton functors. the paper is structured as follows: in section 2 we briefly define recognizable graph languages, automaton functors, and the category-theoretic notions at the heart thereof. in section 3 we show some new examples of our invariant checking technique developed in [4]. in section 4 we present our implementation techniques we have used for starting to develop an automaton functor tool suite. in section 5 we give a conclusion and point out new links for further research topics. ∗ research partially supported by the dfg project garev. 1 / 15 volume 38 (2010) mailto:christoph.blume@uni-due.de efficient implementation of automaton functors for the verification of gtss 2 preliminaries in this section we briefly recall some concepts of category theory and recognizable graph languages. we presuppose a basic knowledge of category theory and order theory. 2.1 category theory and recognizable graph languages the category which has sets as objects and relations as arrows is denoted by rel. the subcategory which has total functions as arrows is denoted by set. the composition of two composable arrows f and g is denoted by f ; g = g◦ f . let c be a category with pushouts. a cospan c : j −cl�c �cr−k is a pair of c-arrows with the same codomain. here, j and k are the domain (or inner interface) and codomain (or outer interface) of the cospan c, respectively. the identity cospan for an object e is the cospan consisting of twice the identity arrow of e. let c : j −cl�c �cr−k and d : k −dl� d �dr−m be cospans (where the codomain of c equals the domain of d). the composition of c and d is obtained by taking the pushout of cr and dl. a semi-abstract cospan is an equivalence class of cospans, where we take the middle object of the cospan up to isomorphism. now, the cospan category cospan(c) is defined as the category which has the objects of c as objects, and semi-abstract cospans as arrows. let a set σ of labels be given. a hypergraph g, later also simply called graph, is a four-tuple 〈vg,eg,attg,labg〉, where vg is a finite set of vertices (or nodes) of g, eg is a finite set of edges of g, attg : eg →v∗g is the attachment function and labg : eg → σ is the labeling function. here, v∗g denotes the set of finite sequences of elements of vg. a hypergraph morphism f is a structure-preserving map between two hypergraphs. a discrete graph is a graph which does not contain any edges. the discrete graph with n nodes is denoted by dn. the empty graph is denoted by /0 instead of d0. the category of graphs and graph morphisms is denoted by hgraph. a cospan of graphs (an arrow in the category cospan(hgraph)) can be seen as a graph with an inner (left) and an outer (right) interface. intuitively, the interfaces designate the parts of the graph which can be “touched” from the outside. with [g]: /0 → g ← /0 we denote the cospan consisting of a graph g with empty inner and outer interfaces. cospans of graphs are closely related to graph transformation systems, in particular to the double-pushout (dpo) approach to graph rewriting [19]. a dpo rewrite rule ρ : l �ρl−i −ρr� r can be considered as a pair of cospans `: /0 → l �ρl−i and r : /0 → r �ρr−i, which will in the following be called leftand right-hand side, respectively. then it holds that g ⇒ρ h if and only if [g] = `; c and [h] = r ; c, for some cospan c. we define recognizable graph languages by using automaton functors on the category of cospans of graphs, as in [8]. definition 1 (automaton functor, recognizability) let a category c with initial object /0 be given. an automaton functor is a functor a : c → rel, which maps every object x of c to a finite set a (x) of states of x and every arrow f : x →y to a relation a ( f )⊆ a (x)×a (y ), together with two distinguished sets ia ⊆ a (/0) and fa ⊆ a (/0) of initial and final states, respectively. an automaton functor is deterministic if every relation a ( f ) is a function and every ia contains exactly one element. proc. doctoral symposium icgt 2010 2 / 15 eceasst an arrow f : /0 → /0 is accepted by an automaton functor a , if 〈s,t〉∈ a ( f ), for some s ∈ ia and t ∈ fa . the language l(a ) of an automaton functor contains exactly those arrows which are accepted by it. a language l of arrows from /0 to /0 is a recognizable language if l = l(a ), for some automaton functor a . the intuition behind the definition is to have a mapping into a (locally) finite domain. the functor property guarantees that decomposing an object in different ways does not affect acceptance in any way. this is different from word languages, where there is essentially one way to decompose an object into subobjects. familiar constructions on finite automata, such as the determinization construction, can be easily generalized to automaton functors. also, it was shown in [8], that restricting to discrete interfaces does not affect the expressiveness of the formalism. due to the latter result, we shall restrict to discrete interfaces in the rest of this paper. the above definition can easily be generalized to accept languages between arbitrary objects. however, in our setting we require only languages from the initial object to the initial object. a characterization of recognizable graph languages can be obtained in terms of recognizable languages in cospan(hgraph): definition 2 (recognizable graph language) a set l of graphs is a recognizable graph language, if [l] ={[g]: /0 → g ← /0 | g ∈ l} is a recognizable language in cospan(hgraph). in the following we do not distinguish between l, a language of graphs, and [l], a language of (cospans of) graphs with empty interfaces. 2.2 atomic cospans we assume that the set of nodes of each discrete graph dn is vdn = {v0,...vn−1}. we set nn = {0,...,n−1} and we denote the disjoint union of two graphs g1 and g2 by g1 ⊕g2. we assume that g1 and g2 are disjoint. furthermore we define the disjoint union f ⊕g : g1 ⊕g2 → h1 ⊕h2 of two graph morphisms f : g1 → h1 and g : g2 → h2 where h1 and h2 are disjoint as follows: ( f ⊕g)(v) = { f (v), if v ∈vg1 g(v), if v ∈vg2 and ( f ⊕g)(e) = { f (e), if e ∈ eg1 g(e), if e ∈ eg2 . definition 3 (atomic graph operations) restriction of the outer interface: let ρ : dn−1 → dn with ρ(vi) = vi be an arrow between two discrete graphs. we define the cospan resn as follows: resn : dn −iddn� dn �ρ−dn−1. permutation of the outer interface: let a permutation π : nn → nn with π(i) = i + 1 for 0 ≤ i < n−1 and π(n−1) = 0 and an arrow σ : dn → dn with vi 7→ vπ(i) between two discrete graphs be given. we define the cospan permn as follows: permn : dn −iddn� dn �σ−dn. transposition of the outer interface: let a transposition τ : nn → nn with τ(0) = 1, τ(1) = 0 and τ(i) = i for 2 ≤ i ≤ n−1 and an arrow σ : vn →vn with vi 7→ vτ(i) between two discrete graphs be given. we define the cospan transn as follows: transn : dn −iddn� dn �σ−dn. 3 / 15 volume 38 (2010) efficient implementation of automaton functors for the verification of gtss resn = dn dn dn−1 ... ... ... ρ permn = dn dn dn ... ... ... σ transn = dn dn dn ... ... ... σ fusen = dn d dn−1 ... ... ... θmap ϕ connect a,m n = dn h ⊕dn−m dn ... ... ... ... a ... ... e vertexn = dn dn+1 dn+1 ... ... ... dl figure 1: graph operations fusion of two nodes of the outer interface: let n > 1 and an equivalence relation θ = idvn ∪ {(v0,v1),(v1,v0)}, an arrow θmap which maps every node of dn to its θ -equivalence class, and an arrow ϕ : dn−1 → d with vi 7→ jvi+1kθ , where d is the discrete graph with node set {jvkθ | v ∈vn}, be given. we define the cospan fusen as follows: fusen : dn −θmap� d �ϕ− dn−1. connection of a single hyperedge: let an edge label a ∈ σ, m ∈ n with 0 ≤ m ≤ n and a hypergraph h which consists of a single hyperedge h with arity m and labeled with a be given. we define the cospan connecta,mn as follows: connect a,m n : dn −e�h ⊕dn−m �e−dn with e(vi) = atti(h) for 0 ≤ i < m and e(vi) = vi−m otherwise. disjoint union with a single node: we define the cospan vertexn as follows: vertexn : dn −dl� dn+1 �iddn+1−dn+1 with dl = iddn ⊕i and i : /0 → d1. the following proposition, which is proven in [4], shows that every graph (viewed as cospan with empty inner and outer interface) can be decomposed in a sequence of atomic cospans: proposition 1 every cospan of the form c : dm −ϕ l� g �ϕ r− dn where the right leg ϕ r is injective can be constructed by a sequence op1,...,opk of atomic graph operations, i.e. c can be obtained as the composition c = op1 ;...; opk. due to this result, we can restrict our attention to atomic cospans instead of considering arbitrary cospans in the following sections. 3 recognizability and invariant checking in this section we give a short introduction to a straightforward approach to verification which is based on recognizable graph languages. the main idea is to provide an invariant and to check that it is preserved by all transformation rules. this technique was first presented in [3, 4]. in this section we want to present new examples how to use technique for verification. an implementation which provides an invariant check among other things will be discussed in section 4. proc. doctoral symposium icgt 2010 4 / 15 eceasst a b b figure 2: subgraph t 0 1 a =⇒ 0 1 a figure 3: transformation rule σa in the case of words, a language is an invariant for a rule `→ r if it holds for all words u and v that u`v ∈ l implies urv ∈ l. if we consider regular word languages the rule ` → r preserves the language l if and only if ` and r are ordered with respect to a monotone well-quasi-order such that l is upward-closed w.r.t this well-quasi-order [12, 18]. the coarsest such order is the myhill-nerode quasi-order of a language l which relates arbitrary words v and w if and only if it holds for all words u and x that uvx ∈ l implies uwx ∈ l. this is the coarsest monotone quasi-order such that l is upward-closed with respect to this quasi-order and it can be computed by a fixed-point iteration similar to the computation of the minimal finite automaton [3]. the notion of the myhill-nerode quasi-order and the result that a rule ` → r preserves a languages if and only if ` and r are ordered with respect to the myhill-nerode quasi-order can be lifted to recognizable graph languages (based on cospan(graph)) [4]. the algorithm for computing the myhill-nerode quasi-order can also be adapted to the more general setting and there exists a prototype implementation to check whether the language of all graphs containing a given subgraph is an invariant according to a given graph transformation rule [3]. in the following we present some instances for recognizable graph languages which are invariants for different transformation rules. first we consider the language lu of all graphs which contain a fixed subgraph u . the automaton functor a accepting this language works as follows: for every discrete graph di, i ∈ n, the automaton functors contains a state set au (di). every state in each of the state sets has to hold two informations. the first information represents which parts of the subgraph have already been recognized. the second information is a function which maps every node of the interface di to a node which has already been recognized or to some “bottom element” to indicate that the interface node is not mapped to a node of the wanted subgraph. for every cospan c : dm −cl� g �cr−dn two states (u′, f ′)∈ au (dm) and (u′∪u′′, f ′′)∈ au (dn) are related by au (c) if and only if u′′ is a graph containing those nodes and edges of u which lie in the graph g and by “updating” the function f ′ to a function f ′′ according to c. since the graph g might contain several graphs u′′ as subgraph, the automaton functor is highly non-deterministic. more details about the construction of this automaton functor can be found in [3]. example 1 as an example we want to take the graph t (see figure 2) as the wanted subgraph. it can be shown that the language lt of all graphs containing t as a subgraph is an invariant for the rule σa (see figure 3). the general idea is now to perform the following three steps. the first step is to compute the automaton functor at for lt . the next step is to compute the myhill-nerode quasi-order for lt using the automaton functor at and the algorithm presented in 5 / 15 volume 38 (2010) efficient implementation of automaton functors for the verification of gtss 0 1 =⇒ 0 1 figure 4: transformation rule αn 0 1 (a) left-hand side 0 1 (b) right-hand side figure 5: colorings for the rule αn [3]. the last step is to check whether the left-hand side of σa (viewed as a cospan) is related to the right-hand side of σa (viewed as a cospan) according to the myhill-nerode quasi-order. note that in practice we use a slightly different algorithm which computes the simulation relation instead of the myhill-nerode quasi-order due to the fact that the automaton functor is non-deterministic and the algorithm computing the myhill-nerode quasi-order is only applicable to deterministic automaton functors. another recognizable graph language we want to consider is the language l(k) of all k-colorable graphs (for some k ∈ n). a k-coloring of a graph g is a function f : vg → nk such that for all edges e ∈ eg and for all nodes v1,v2 ∈ attg(e) it holds that f (v1) 6= f (v2) if v1 6= v2. the question whether a graph is k-colorable is essential in many applications, for example in scheduling theory to find a solution for allocations of limited (hardware) resources or for assignments of limited bandwidth in networks. the idea of the automaton functor a(k) : cospan(hgraph) → rel accepting all k-colorable graphs (as defined in [8]) is as follows: every discrete graph di, i ∈n, is mapped to the state set a(k)(di) containing all valid k-colorings of di, i.e. a(k)(di) ={ f : vdi → nk | f is a valid k-coloring of di}. for every cospan c : dm −cl� g �cr−dn two states fm ∈ a(k)(dm) and fn ∈ a(k)(dn) are related by a(k)(c) if and only if f (c l(v)) = fm(v) for every node v ∈vdm and f (c r(v)) = fn(v) for every node v ∈vdn . example 2 now we want to consider two examples. the first example is the transformation rule αn (see figure 4) for which the language l(2) is an invariant. the rule αn simply adds two new nodes to an existing path. the second example is the transformation rule αr (see figure 6) for which the language language l(3) is an invariant. the second rule replaces the middle node of a rectangular graph by a new rectangle. since the path of the left-hand side is 2-colorable (see figure 5) and since the two nodes in the image of the interface do not need to be re-colored, it is obvious that the language l(2) is an invariant for the rule αn. due to the fact that the outer rectangle of the lhs of αr is a (closed) path it is also 2-colorable (see figure 7) and since the inner node of the left-hand side of αr in each case forms a triangle with two of the outer rectangle nodes and every triangle is 3-colorable it is clear, that the left-hand side is 3-colorable. the 3-colorability of the right-hand side of the rule αr can be obtained in a similar way, therefore l(3) is an invariant for the rule αn. please note that, although it is guaranteed that the colorability for a graph is preserved by the applied transformation rule, it might be necessary to “re-color” the graph during the processing proc. doctoral symposium icgt 2010 6 / 15 eceasst 0 1 2 3 =⇒ 0 1 2 3 figure 6: transformation rule αr 0 1 2 3 (a) left-hand side 0 1 2 3 (b) right-hand side figure 7: colorings for the rule αr of (the decomposition of) the graph to obtain a valid k-coloring of the graph. the information about possible “re-colorings” are automatically hold by the automaton functor a(k) due to its construction. 4 efficient implementations of automaton functors in this section we present our (prototype) java-implementation of a tool suite for computing and manipulating automaton functors. in order to implement such a tool suite we have to restrict ourselves to automaton functors of finite size, i.e. the considered automaton functors must not consist of infinitely many finite state sets. but in general an automaton functor is not finite, since graphs with an arbitrary pathwidth have to be considered. but if only recognizable graph languages of bounded pathwidth are allowed, it is possible to use automaton functors of bounded size, since the size of the interface of every graph is bounded. in the following we only take cospans into account which have a bounded interface size. definition 4 (bounded cospan) a cospan c : s−cl� g �cr−t is called bounded (by k), if there exist atomic graph operations op1,...,op j such that c = op1 ;...; op j and for every graph operation opi : dni −op l i � gi �opri −dmi for 1 ≤ i ≤ j it holds that ni,mi ≤ k. however, the automaton functors might still be very large. therefore it is not suitable to represent the automaton functors explicitly. to achieve a compact representation of the automaton functor we use binary decision diagrams (bdds) [1] to encode the transition relation of the automaton functor. the basic idea is to encode each state of the automaton functor as a bit string of length t. the transition relation can then be seen as set t of bit strings of length 2t where a bit string b1 ...b2t is contained in t if and only if b1 ...bt is the encoding of a state q, bt+1 ...b2t is the encoding of a state q′ and q is related to q′ by the transition relation. the set t can be characterized by a boolean function f with 2n atomic propositions and this formula f can be represented by a bdd. as an example we want to consider the following set of 4-bit vectors: {0000,0011,1100,1111}. we assume that the bits of the bit vectors are numbered from b0 to b3 with the least significant bit left. then the set can be characterized by the formula (b0 ↔ b1)∧(b2 ↔ b3). the bdd which encodes this formula can be seen in figure 8. besides the compact representation of sets and relations bdds provide some other useful 7 / 15 volume 38 (2010) efficient implementation of automaton functors for the verification of gtss features. one of these features is that bdds are unique (up to isomorphism) if the ordering of the atomic propositions of the represented boolean function is fixed and if the bdd is reduced. we use this property of bdds to efficiently check the equivalence of boolean functions. another feature of bdds is the possibility to directly compute boolean operations or both existential and universal quantifications on bdds instead of performing these operations on the represented boolean functions. in our implementation we use the javabdd1-package which is based on the buddy2-bdd-package written in c as implementation of bdds. in the following we present the state encoding and the b0 b1 b1 b2 b3 b3 1 0 figure 8: bdd for the formula (b0 ↔ b1)∧(b2 ↔ b3) propositional formulas we used for the implementation of the automaton functor accepting all graphs containing a specific subgraph (see section 3). the state encoding has to take care of the following informations: • the interface size (of the outer interface of the cospan seen so far) • the parts of the subgraph which have been recognized so far • the overlap of the parts (of the subgraph) with the current interface since a good ordering of the bits holding these informations is essential to construct bdds which are very compact, we have done some experiments to find the best possible ordering. the resulting encoding of a state is as follows if we assume that the maximum interface size is k, ` =dlog2(k + 1)e and that the wanted subgraph has m edges and n nodes: b1 ...b`e0 ...em−1(v0 f0,0 ... f0,k−1)...(vn−1 fn−1,0 ... f0,k−1). the bits b1 ...b` encode the current interface size as a binary number, the bit ei (for 0 ≤ i ≤ m−1) and the bit v j (for 0 ≤ j ≤ n−1) respectively represent the (non-)existence of the i-th edge and j-th node respectively, and the bit fi, j (for 0 ≤ i ≤ n−1, 0 ≤ j ≤ k−1) encode that the j-th interface node is (not) mapped to the i-th node of the wanted subgraph. to distinguish between the bits encoding the current state and the bits encoding the successor state we indicate the successor state encoding by b′1 ...b ′ `e ′ 0 ...e ′ m−1(v ′ 0 f ′ 0,0 ... f ′ 0,k−1)...(v ′ n−1 f ′ n−1,0 ... f ′ n−1,k−1). in the following we do not distinguish between the nodes and edges of the wanted subgraphs and the bits encoding the (non-)existence of these nodes and edges in states encoded by the several bit strings. for each of the atomic graph operations (connecta,p, fuse, perm, res, trans, vertex) we define a separate propositional formula describing all transitions – for all permitted interfaces – of the automaton functor (for the particular atomic graph operation). these formulas can then be easily transformed in bdds which describe the transition functions for the different atomic graph operations. in the following we present the formula fconnecta,p for the connect a,p-operation as an example. in order to define the formula we use six auxiliary formulas 1 javabdd project homepage: http://javabdd.sourceforge.net 2 buddy manual: http://buddy.sourceforge.net/manual/main.html proc. doctoral symposium icgt 2010 8 / 15 http://javabdd.sourceforge.net http://buddy.sourceforge.net/manual/main.html eceasst • to describe that none of the edges from ei to e j have been changed: edgesunchanged(i, j) ⇐⇒ j∧ t=i (et ↔ e′t) • to describe that the a-labeled edge ei of arity s has been added and all other edges have not been changed: edgeadded(i,a,s) ⇐⇒ edgesunchanged(0,i−1)∧(lab(ei) = a ∧|att(ei)| = s∧¬ei ∧e′i)∧edgesunchanged(i + 1,m−1) • to describe that none of the nodes from vi to v j have been changed: nodesunchanged(i, j) ⇐⇒ j∧ t=i (vt ↔ v′t) • to describe that the node vi must have been recognized and be present in the interface if it is adjacent to the edge e j and must not be changed otherwise: adjacentnodeexisting(i, j) ⇐⇒ (vi ∈ att(e j)→ (vi ∧v′i ∧ k−1∨ t=0 fi,t)) ∧(vi /∈ att(e j) → (vi ↔ v′i)) • to describe that the interface from j to k for the node vi has not been changed: interfaceunchanged(i, j,k) ⇐⇒ k∧ t= j ( fi,t ↔ f ′i,t) • to describe that the interface from j to k for the node vi is undefined: interfaceundefined(i, j,k) ⇐⇒ k∧ t= j (¬ fi,t ∧¬ f ′i,t). now we can define the formula f connect a,p i . a transition q−connecta,pi � q′ is allowed if and only if both states q and q′ belong to the same state set a (di) (i.e. both states have the same interface size) and if either the currently added edge does not belong to the wanted subgraph (i.e. the parts of the subgraph already recognized does not change) or the currently added edge is exactly one of the edges which belong to the wanted subgraph (i.e. this edge will be added to the parts of the 9 / 15 volume 38 (2010) efficient implementation of automaton functors for the verification of gtss subgraph already recognized): f connect a,s i = ∧̀ j=1 ( (bin j (i)↔ b j)∧(b j ↔ b′j) ) ∧ (1) ( edgesunchanged(0,m−1)∨ (2) m−1∨ j=0 ( edgeadded( j,a,s)→ n−1∧ t=0 adjacentnodeexisting(t, j) )) ∧ (3) n−1∧ j=0 ( interfaceunchanged( j,0,i)∧interfaceundefined( j,i + 1,k−1) ) (4) the function bini (x) used in the formula above returns the i-th bit of the binary encoding of a natural number x. in line 1 it is required that the interface size of the current state is i and that the successor state has also the interface size i. in line 2 the case is described that the currently added edge does not belong to subgraph. whereas in line 3 it is described that in the case that the added edge belongs to the subgraph it has to be checked that the label and the arity of the new edge matches to an edge of the subgraph, that exactly one edge which has not be recognized before has been added and that all nodes which are adjacent to the new edge has been recognized before and are still present in the interface. in line 4 it is required that the interface nodes which represent the current interface, i.e. the first i interface bits, have not been changed and the other interface bits, i.e. the bits from i + 1 to k−1 have not been set. note that in the case that the wanted subgraph does not contain an edge with the specified label and the specified arity it can only occur that no edge of the subgraph has been changed. example 3 we consider that the graph s (see figure 9) is the subgraph we are looking for and that the maximum interface of the corresponding automaton functor is 3. the length of the state encoding then is 16, since we need two bits for the interface size, two bits for the edges, three bits for the nodes and nine bits for the interface function. the encoding of the state q (see figure 10) of this automaton functor in which the nodes v0 and v1 have already been recognized, the node v2 as well as both edges e0 and e1 are still missing and the second interface node is mapped to v1 and the third is mapped to v0 would be: b1 b2 e0 e1 v0 f0,0 f0,1 f0,2 v1 f1,0 f1,1 f1,2 v2 f2,0 f2,1 f2,2 1 1 0 0 1 0 0 1 1 0 1 0 0 0 0 0 if we assume that the automaton functor is in state q and the next atomic graph operation it processes is the connecta,23 -operation, two transitions are possible. by the first transition the automaton functor decides non-deterministically that the new binary a-labeled edge is none of the edges belonging to s and therefore the automaton functors remains in state q. by the second possible transition the automaton functor decides that the new edge is one of the edges of s and moves to the state q′ (see figure 10) in which the newly added edge has been recognized. since all adjacent nodes must have been recognized before an edge can be added, there is only the possibility to add the edge e0 in this situation. the encoding of the state q′ is as follows: proc. doctoral symposium icgt 2010 10 / 15 eceasst v0 2 v1 1 a a =⇒ connect a,2 3 v0 2 v1 1 a e0 a figure 10: transition from state q to state q′ b1 b2 e0 e1 v0 f0,0 f0,1 f0,2 v1 f1,0 f1,1 f1,2 v2 f2,0 f2,1 f2,2 1 1 1 0 1 0 0 1 1 0 1 0 0 0 0 0 the encoding of relations is usually done in an “interleaving fashion”, more precisely the bits encoding the first element of the pair are alternated with the bits encoding the second element. the great advantage of this interleaving encoding is that the bdd representing the relation gets rather small, since the bits encoding the same piece of information are near each other. for example the following bit vector encodes the pair (q,q′) for the connecta,23 -operation: b1 b2 e0 e1 v0 f0,0 f0,1 f0,2 v1 f1,0 f1,1 f1,2 v2 f2,0 f2,1 f2,2 b′1 b ′ 2 e ′ 0 e ′ 1 v ′ 0 f ′ 0,0 f ′ 0,1 f ′ 0,2 v ′ 1 f ′ 1,0 f ′ 1,1 f ′ 1,2 v ′ 2 f ′ 2,0 f ′ 2,1 f ′ 2,2 1 1 1 1 0 1 0 0 1 1 0 0 0 0 1 1 1 1 0 0 1 1 0 0 0 0 0 0 0 0 0 0 in order to optimize the computation and size of the bdds needed to v0 v1 v2 a e0 a e1 figure 9: subgraph s represent the transition relations for the different atomic graph operations, we permitted all bit vectors which encode an interface which has a size less than or equal to the maximum interface size of the automaton functor. the idea behind this is that the bdds spend much information to the check whether a state (bit vector) is valid, i.e. it has to check four consistency conditions: • the parts of the subgraph already recognized do not contain dangling edges (for example if e0 is set also v0 and v1 have to be set), • interface nodes are only mapped to subgraph nodes which have already been recognized (for example if one of f0,i, 0 ≤ i ≤ 2, is set also v0 has to be set), • an interface node is only mapped to exactly one subgraph node (for example if f1,1 is set, then f0,1 and f2,1 must not be set), • the bits of interface nodes which do not belong to the current interface must not be set (for example if the current interface size is 1, then fi,1 and fi,2, 0 ≤ i ≤ 2, must not be set). 11 / 15 volume 38 (2010) efficient implementation of automaton functors for the verification of gtss pathnumber of number of time for bdd time for explicit width valid states bdd nodes construction computation3 5 7475 2049 0.37 sec 17 sec 10 6041421 7782 0.42 sec −4 20 5.9·1012 30044 0.67 sec −4 50 6.8·1030 183038 7.85 sec −4 100 8.6·1060 726156 1 min 10 sec −4 200 1.4 ·10121 2892392 60 min 44 sec −4 table 1: performance statistics for the automaton functor as since the formulas for the several transitions guarantee that these consistency conditions are fulfilled by the transitions, it is not possible to reach an “invalid” state by starting in a “valid” state. in table 1 we present some results for the automaton functor from example 3 for different interface sizes. the first column indicates the maximum interface size, the second column shows the number of states – without “invalid” bit vectors – of the automaton functor recognizing the subgraph s. in the third column the number of bdd nodes is given which are needed to represent the bdds for all atomic graph operations. the last two columns show the time for constructing the automaton functor recognizing the subgraph s by computing the bdd-based representation and by computing an explicit-state representation3. the table shows that it is not efficiently possible to represent the automaton functor in an explicit way. due to the fact that the number of states grows exponential the explicit representation leads to an exhaustive consumption of resources. therefore it is only possible to compute the automaton functor (accepting all graphs containing s as subgraph) for a maximum interface size of 7 on a machine with 2 gb main memory. despite of that we have successfully tested the implicit bdd-based representation for maximum interface sizes of 1000 and more. in table 2 the results for another automaton functor recognizing the figure 11: subgraph r subgraph r which can be seen in figure 11 are shown. it turns out that the computation of automaton functors also scales for subgraphs with higher number of nodes and edges. however, the computation of the simulation relation (which is needed to perform the invariant check) does not benefit from the usage of bdds in the same dimension as the automaton functor computation. in table 3 we present the time needed for the bdd-based computation of the simulation relation. currently we were able to compute the simulation relation up to a maximum interface size of 7. for comparison, if we use an explicit representation of the simulation relation we were only able to compute the relation up to a maximum interface size of 4 [3]. the problem of the computation is that the “intermediate relations” which occur during the fixed-point computation are not efficiently representable by a bdd, i.e. with a small number of bdd nodes. 3 further informations about the explicit-state implementation can be found in [3]. 4 computation impossible due to exhaustive resource consumption. proc. doctoral symposium icgt 2010 12 / 15 eceasst pathnumber of number of time for bdd width valid states bdd nodes construction 5 32748051 7521 0.47 sec 10 7.7 ·1011 28014 0.77 sec 20 6.5 ·1020 106646 3.37 sec 50 8.4 ·1047 643550 1 min 7 sec 100 1.2 ·1093 2542518 23 min 18 sec table 2: performance statistics for the automaton functor ar pathwidth time 1 0.49 sec 2 0.53 sec 3 0.83 sec 4 2.51 sec 5 19.32 sec 6 4 min 17 sec 7 53 min 12 sec table 3: performance statistics for the simulation relation 5 conclusions and future work we have presented techniques for an efficient implementation of a tool suite for computing and manipulating (bounded) automaton functors. apart from the invariant check which we have shown in this paper we have already implemented methods for computing the union and the intersection of automaton functors. in addition we are working on both a universality and a language inclusion check for recognizable graph languages which are both based on an antichain construction introduced by henzinger et. al. [20]. since our invariant check suffers from an under-approximation – due to the non-determinism of the automaton functor – we suffer from a one-sided error. this lack could be eliminated if we were able to solve the language inclusion problem on non-deterministic automaton functors (efficiently). furthermore we are tackling another problem: now we have to construct our automaton functors very directly, but this is hard because of the functor property which has to be enforced. in [9] a category-based logic (called a logic on subobjects) which has the same expressive power as monadic second-order logic is presented that can be employed for all kinds of (graph-like) structures. this logic can be used for generating automaton functors from formulas due to a result by courcelle [10, 11] which states that every monadic second-order definable language is recognizable. currently, we are working on a project to implement this formula-based generation. finally, we are studying another approach to the verification of distributed and infinite-state systems: regular model checking [6]. the main idea is to describe (possibly infinite) sets of states as regular languages and transitions of the system as regular relations represented by finite-state transducers transforming a regular language into another regular language. for this purpose we are developing the notion of so-called transduction functors, i.e. the counterpart of finite-state transducers in the case of word languages. since this approach has been extended to the setting of regular tree languages and tree transducers [5] it is a logical step to generalize regular model checking to graph transformation systems where recognizable graph languages play the role of regular languages and transduction functor play the role of finite-state transducers. there already exists the notion of mso-definable transductions invented by courcelle [11], but this notion does not seem to be that useful, since these transductions are very complex and do not guarantee to transform a recognizable graph language into another recognizable graph language in general which is required for a forward analysis. it has to be investigated how the notion of 13 / 15 volume 38 (2010) efficient implementation of automaton functors for the verification of gtss finite-state transducer can be generalized to transduction functors similar to the generalization of finite-state automata to automaton functors. the goal is to have a notion of transduction functor which is equivalent to finite-state transducers when restricted to word languages. in addition to our application, bdds have also been used in other automaton-oriented tools such as mona [16, 15]. in contrast to our approach in which we represent sets and relations on states implicitly by bdds, in mona bdds are used in a different way, since in mona the input labels of the automaton are encoded as bit vectors. the idea is that the root node and the leaf nodes of the bdds indicate states of the automaton which are represented explicitly. starting in the root node and following some path in the bdd to a leaf node one reaches the successor state according to the input letter encoded by the chosen path. this idea is quite different to our approach since we use a different bdd for each input letter, i.e. for each atomic cospan, to represent the whole transition relation induced by this input letter. another related work by kneis and langer [17] is based on dynamic programming on tree decompositions to check whether a given graph has some property. for their approach kneis and langer take advantage of game-theoretic formalisms to check after each step of the processing of the tree decomposition whether the property still holds. we have not yet compared our results with this approach in detail and it has also to be investigated further, whether this technique could be applied to our setting. acknowledgements: the author would like to thank barbara könig, sander bruggink and mathias hülsbusch for their suggestions and their valuable discussions on this research topic. bibliography [1] andersen, h.r.: an introduction to binary decision diagrams. course notes (1997), http: //www.configit.com/fileadmin/configit/documents/bdd-eap.pdf [2] bauderon, m., courcelle, b.: graph expressions and graph rewritings. mathematical systems theory 20(2-3), 83–127 (1987) [3] blume, c.: graphsprachen für die spezifikation von invarianten bei verteilten und dynamischen systemen. master’s thesis, universität duisburg-essen (2008) [4] blume, c., bruggink, s., könig, b.: recognizable graph languages for checking invariants. in: proceedings of gt-vmt ’10. electronic communications of the easst, vol. 29 (2010) [5] bouajjani, a., habermehl, p., rogalewicz, a., vojnar, t.: abstract regular tree model checking of complex dynamic data structures. in: proceedings of sas ’06. pp. 52–70. springer (2006) [6] bouajjani, a., jonsson, b., nilsson, m., touili, t.: regular model checking. in: proceedings of cav ’00: proceedings of the 12th international conference on computer aided verification. pp. 403–418. springer (2000), lncs 1855 proc. doctoral symposium icgt 2010 14 / 15 http://www.configit.com/fileadmin/configit/documents/bdd-eap.pdf http://www.configit.com/fileadmin/configit/documents/bdd-eap.pdf eceasst [7] bozapalidis, s., kalampakas, a.: graph automata. theoretical computer science 393, 147–165 (2008) [8] bruggink, h.j.s., könig, b.: on the recognizability of arrow and graph languages. in: proceedings of icgt ’08. pp. 336–350. springer (2008), lncs 5214 [9] bruggink, h.s., könig, b.: a logic on subobjects and recognizability. in: calude, c., sassone, v. (eds.) theoretical computer science. ifip advances in information and communication technology, vol. 323, pp. 197–212. springer boston (2010) [10] courcelle, b.: the monadic second-order logic of graphs i. recognizable sets of finite graphs. inf. comput. 85(1), 12–75 (1990) [11] courcelle, b.: the expression of graph properties and graph transformations in monadic second-order logic. in: rozenberg, g. (ed.) handbook of graph grammars and computing by graph transformation, vol.1: foundations, chap. 5. world scientific (1997) [12] ehrenfeucht, a., haussler, d., rozenberg, g.: on regularity of context-free languages. theoretical computer science 27, 311–332 (1983) [13] fribourg, l., olsén, h.: reachability sets of parameterized rings as regular languages. in: proceedings of infinity ’97. electronic notes in theoretical computer science, vol. 9. elsevier (1997) [14] geser, a., hofbauer, d., waldmann, j.: match-bounded string rewriting systems. applicable algebra in engineering, communication and computing 15(3–4), 149–171 (2004) [15] gottlob, g., pichler, r., wei, f.: bounded treewidth as a key to tractability of knowledge representation and reasoning. artif. intell. 174(1), 105–132 (2010) [16] klarlund, n., møller, a.: mona version 1.4 user manual. brics, department of computer science, aarhus university (january 2001) [17] kneis, j., langer, a.: a practical approach to courcelle’s theorem. in: proceedings of the international doctoral workshop on memics ’08. electronic notes in theoretical computer science, vol. 251, pp. 65–81. elsevier (2009) [18] de luca, a., varricchio, s.: well quasi-orders and regular languages. acta inf. 31(6), 539–557 (1994) [19] sassone, v., sobociński, p.: reactive systems over cospans. in: proceedings of lics ’05. pp. 311–320. ieee computer society (2005) [20] wulf, m.d., doyen, l., henzinger, t.a., raskin, j.f.: antichains: a new algorithm for checking universality of finite automata. in: proceedings of cav ’06. pp. 17–30 (2006) 15 / 15 volume 38 (2010) introduction preliminaries category theory and recognizable graph languages atomic cospans recognizability and invariant checking efficient implementations of automaton functors conclusions and future work automatically generating csp models for communicating haskell processes electronic communications of the easst volume 23 (2009) proceedings of the ninth international workshop on automated verification of critical systems (avocs 2009) automatically generating csp models for communicating haskell processes neil c. c. brown 12 pages guest editor: markus roggenbach managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst automatically generating csp models for communicating haskell processes neil c. c. brown1 1 neil@twistedsquare.com, http://www.cs.kent.ac.uk/∼nccb2/ computing laboratory, university of kent, uk abstract: tools such as fdr can check whether a csp model of an implementation is a refinement of a given csp specification. we present a technique for generating such csp models of haskell implementations that use the communicating haskell processes library. our technique avoids the need for a detailed semantics of the haskell language, and requires only minimal program annotation. the generated cspm model can be checked for deadlock or refinements by fdr, allowing easy use of formal methods without the need to maintain a model of the program implementation alongside the program itself. keywords: csp, automatic model generation, haskell 1 introduction programs designed using formal methods such as communicating sequential processes (csp) [hoa85, ros97] typically have a specification and a more complicated implementation. a tool such as fdr [for97] can be used to check that the implementation is a refinement of the specification. however, determining the csp model of an implementation – written in an executable programming language using a csp-based library – can be difficult due to problems with unclear semantics, or translation errors. generating a model from the program should thus be done automatically. generating a formal model of an existing program typically requires complete access to the program’s source code (including libraries) and a detailed semantics of the programming language. both requirements can be problematic: libraries may be closed source, and the programming language may lack a detailed semantics, especially a platform independent semantics that includes the semantics of the threading system and memory model. communicating haskell processes (chp) [bro08] is a library for the functional programming language haskell with a strong correspondence to csp. chp allows for execution of csp-like programs, combining the concurrency concepts of csp with the expressive power of haskell. in this paper we describe a technique for generating formal models of chp programs without the need for source code analysis. we take advantage of haskell’s purity and thus do not require a semantics of the haskell language. we describe the class of programs that can be modelled, along with several examples. our technique can be used to generate models to check for refinement of specifications, or for generating models of rapidly prototyped programs (for example, using agile development methods). 1 / 12 volume 23 (2009) mailto:neil@twistedsquare.com http://www.cs.kent.ac.uk/~nccb2/ automatically generating csp models for communicating haskell processes 2 chp although haskell is a functional programming language, it has support for imperative programming through the concept of monads: a monad captures a common pattern that can be used for imperative programming. thus, a chp program can be conceptually separated into the pure functional computations, and the imperative communication aspects. for example, this is a map process in chp that transforms items as they pass through: map :: (a -> b) -> chanin a -> chanout b -> chp () map f input output = do x chp () blackhole input = do readchannel input blackhole input this can also be written using the common haskell function forever that infinitely repeats in sequence a monadic action: blackhole’ :: chanin a -> chp () blackhole’ input = forever (readchannel input ) infinite behaviour cannot be detected with our substituted monad; there is no way to determine after one million consecutive inputs whether the next statement will definitely be a input. we must require the programmer to add an annotation to aid in spotting recursion. the process annotation is placed as follows: blackhole :: chanin a -> chp () blackhole = process "blackhole" inner where inner input = do readchannel input blackhole input the process annotation uses haskell’s type-classes to take as its second argument a process with n arguments, and return a process that takes the same n arguments. the behaviour of the process wrapper function is to record the arguments to the process ready for future equality checking. when blackhole is first called with a channel c, the process annotation stores a pair of the process name and a list containing all the arguments (in this case, just c) as the key in an associative map with a placeholder for the value. when the process then recurses, the process name and list of arguments (which is again, the singleton list with c) is looked up in the map. a value is found, which causes the execution of the process to return the placeholder. thus only one execution of the process is examined, and the recursive call is skipped. proc. avocs 2009 4 / 12 eceasst the analysis of the blackhole process is then complete, and the placeholder is substituted for a definition of the process’s behaviour. this relies on the user-provided guarantee that all parameters that affect a process’s behaviour are included in the argument list; a process may not use any other free names. as well as the process annotation, we supply a replacement for the haskell library function forever , named foreverp that has identical semantics, but correctly deals with the repeating behaviour in our mirror implementation. these annotations can be used with the normal library (process becomes benign, foreverp is simply defined as forever ) without effect, but then they take on significance in the mirror implementation. 5 io actions an interaction with the program’s external environment is an action in the io monad in haskell. this can include (but is not limited to) interactions with files, sockets and graphical user interfaces. results of these interactions cannot be predicted and are non-deterministic. our generated model accounts for this by modelling the interactions as events selected by the environment. the complication is modelling the value returned by operations such as reading from a file. with source code analysis it would be possible to analyse how the result affects the program’s subsequent behaviour. however, with our approach, the program’s behaviour can only be determined by testing it with each possible value. for values with small finite domains, such as booleans, or enumerated types, this is easily achieveable. for values such as 32-bit integers, it becomes infeasible, and for values with infinite domains such as strings, it is impossible. our analysis of a program is therefore accurate and feasible if the io actions return values with small finite domains, or if the values are discarded. this is often the case for io actions: for example, printing to the screen, waiting for a specified amount of time or writing to a file all return values of the unit type, which has a domain size of one (which also means the value is not usually inspected). we can extend our approach to cover some other cases where the value is used and the domain is large; the problem of determining a program’s behaviour for a range of inputs without source code analysis is identical to the problem of program testing. several developments have been made in this field in haskell. claessen and hughes’ quickcheck generated random values of a given type and tested that specified properties held on the output [ch00]. this was made more systematic in runciman et al.’s smallcheck, which generated all values up to a given depth [rnl08]. the depth of a list would be its length, whereas the depth of an integer would be its absolute value. the clever extension, lazy smallcheck, took advantage of haskell’s laziness to specialise on demand, allowing more efficient exploration of the state space. we use the lazy smallcheck library to explore a program’s behaviour given the result of an io action. crucially, lazy smallcheck will efficiently detect if the value is not used to affect the program’s behaviour, as the first value it will try will be ⊥. if the program does not raise an error with this value, it must not have evaluated it, and thus it cannot have altered its behaviour based on the value. we use lazy smallcheck with an arbitrary maximum depth. if the deepest value is not reached in the lazy search, we can deduce that we have covered all possible behaviours of the program. 5 / 12 volume 23 (2009) automatically generating csp models for communicating haskell processes if this is not the case, the model generated is only an approximation of the program’s behaviour, and much of the advantages of the formal method are lost. this is a necessary restriction of our approach and one that we expose to the user. we deal with values returned from reading channels in the same manner as the result of io actions. 6 examples we provide two examples of our system: the first is a small example demonstrating refinement checking, the second is a larger example demonstrating deadlock freedom. 6.1 copy buffer a simple example of a refinement check, taken from the fdr manual [for97], is that of a copying process, specified as follows: copy = left?x → right!x → copy the example implementation given in the manual, in csp, is: send = left?x → mid!x → ack → send rec = mid?x → right!x → ack → rec system = (send || {x} rec) \ x where x = {mid, ack} we can create the analogue of this implementation in chp as follows: system :: forall a. typeable a => chanin a -> chanout a -> chp () system input output = do c enroll d (\d1 -> send input ( writer c) d0 <||> rec output ( reader c) d1)) return () where send :: chanin a -> chanout a -> enrolledbarrier -> chp () send = process "send" (\input mid ack -> do x chanin a -> enrolledbarrier -> chp () rec = process "rec" (\output mid ack -> do x x is the identity function). the enroll function takes as its arguments a barrier, and a function that itself takes an enrolled barrier and yields a chp process. this higher-order process style is used to scope enrolling on and resigning from the barrier. this program can be executed normally with the chp monad as part of a larger system, or used with our new mirror library to generate a model, which results in the following: channel ack channel in channel mid channel out main_0= (((send_1) [|{| ack , mid |}|] (rec_2))) rec_2= (mid?x_2 -> out!x_2 -> ack -> rec_2) send_1= (in?x_1 -> mid!x_1 -> ack -> send_1) main = main_0 it can be seen that, a few spurious brackets and appended unique identifiers aside, this is the same as the csp we began with – except for the hiding. we can now prove this is a refinement of the original specification by adding the following lines to the fdr script: copy = in?x -> out!x -> copy assert copy [fd= (main\{mid,ack}) assert copy [t= (main\{mid,ack}) these refinements check successfully. we were able to take a specification, implement a chp equivalent (in this case we had some csp for the implementation, but this was not necessary), and make a successful refinement check against the original specification. the main manual step required was that we hid the mid and ack events. we could attempt to infer when to hide events (a difficult option), or we could add an operator in the code to hide events. for example, we could modify a line of our system process to be: enroll d (\d0 -> enroll d (\d1 -> send input ( writer c) d0 <||> rec output ( reader c) d1 <\\> [c, d ])) 6.2 dining philosophers as an example of generating a csp model from a chp program and checking for deadlock, we use the dining philosophers problem. the code for the deadlocking dining philosophers, that can be executed normally, or used to produce traces [bs08], is as follows: fork :: enrolledbarrier -> enrolledbarrier -> chp () fork = process "fork" (\left right -> foreverp (( do syncbarrier left syncbarrier left ) <-> (do syncbarrier right syncbarrier right ))) 7 / 12 volume 23 (2009) automatically generating csp models for communicating haskell processes philosopher :: enrolledbarrier -> enrolledbarrier -> chp () philosopher = process "philosopher" (\left right -> foreverp ( do randomdelay syncbarrier left <||> syncbarrier right randomdelay syncbarrier left <||> syncbarrier right )) where randomdelay :: chp () randomdelay = liftchp $ ( liftio $ getstdrandom (randomr (500000, 1000000))) >>= waitfor college :: int -> chp () college = process "college" (\nphil -> withbarrierpairlistwithstem nphil "fork_left_phil" (\forkleftchans -> withbarrierpairlistwithstem nphil "fork_right_phil" (\forkrightchans -> runparallel ( [ fork ( fst (forkrightchans !! n )) ( fst ( forkleftchans !! (( n + 1) ‘mod‘ nphil ))) | n <[0.. nphil 1]] ++ [ philosopher (snd ( forkleftchans !! n )) (snd (forkrightchans !! n )) | n <[0.. nphil 1]])))) the process annotations on the fork and philosopher are not strictly necessary (the use of foreverp catches the infinite behaviour) but help to label the processes in the generated model. the <-> operator is external choice, while <||> is parallel composition (and runparallel is a list version). this real running code can then be changed to use the chp-model library by changing a single import statement (omitted for brevity). the generated model for three philosophers is shown in figure 1. if we append the line assert main :[ deadlock free ] to that script, fdr produces a trace of one of the deadlocks in the system: begin trace example=0 process=0 fork_right_phil2 fork_right_phil1 fork_right_phil0 end trace example=0 process=0 7 post-processing after the model for a program has been determined, it is a relatively simple matter to print it out in the machine-readable cspm form that the fdr model checker expects. the only current drawback is that each different combination of arguments to an annotated process will correspond to a different process in the generated output. returning to our example of the input consuming process, the system with blackhole c <||>blackhole d generates: channel c channel d blackhole_1= (c?x_1 -> blackhole_1) proc. avocs 2009 8 / 12 eceasst blackhole_2= (d?x_2 -> blackhole_2) main_0= (((blackhole_1) ||| (blackhole_2))) main = main_0 even though the behaviour of the two black hole processes is identical except for the channel involved, we currently generate two instantiations of the process rather than one parameterised process. in future we would like to maintain the correctness of the specification, but also reduce its verbosity by merging such processes together. 7.1 alphabets in chp, the synchronisation rules are as follows. a channel requires exactly two processes to synchronise on it. a barrier has an enrollment count, and a number of processes equal to that count must synchronise on the barrier for it to complete. in roscoe’s csp [ros97], an event can have any number of parties, from one upwards. which processes must synchronise with each other on an event is determined by the shared alphabet when the two processes are composed in parallel. given this csp: p = a → b → c → skip q = b → skip r = c → skip all = p || {b} q || {c} r the event a will involve just p, whereas b will involve p and q, and c will involve p and r. should the event a have been included in the alphabet of either parallel composition, p would cause deadlock as the other process in the composition would not be offering the event a. in translating chp programs into csp models, we must infer the alphabets for parallel compositions. since all of our events have unique identifiers we are able to follow a simple rule: the events in the alphabet of parallel composition are the intersection of the sets of events engaged in by the two processes being composed. this rule works correctly for most programs (including the dining philosophers example). however, consider the following program: p = do a enroll a (\a1 -> enroll b (\b0 -> enroll b (\b1 -> runparallel [do syncbarrier a0 syncbarrier b0 , syncbarrier a1 ])))) this program will deadlock when run, as only one process (of two enrolled) will synchronise on the barrier b. if the specification is generated with our original simple rule, we get this specification: p = (a -> b -> skip) [|{| a |}|] (a -> skip) 9 / 12 volume 23 (2009) automatically generating csp models for communicating haskell processes this specification will not deadlock, as the event b is not in the shared alphabet with any other process. more generally, if less processes are using a barrier than are enrolled, or if only one process is using a particular channel, the model generated with our simple alphabet rule will be incorrect. the simplest solution to this is as follows. we augment our framework to track how many processes should be using a particular event (two for channels, the enrollment count for barriers). if the actual number of processes turns out to be lower than this, we compose the relevant processes in parallel with a dummy process (skip) with the events shared, for example: p = ((a -> b -> skip) [|{| a |}|] (a -> skip)) [|{| b |}|] skip this new model will reveal the deadlock in the original program. 8 summary our approach is able to generate models for the following features of chp programs: • sequential and parallel composition, • external choice, • barrier creation and synchronisations (but not a proper semantics of dynamic enrollment and resignation), • channel outputs, • channel inputs and lifted io actions (where the result either has a small finite domain, or is not used to make a choice about the program’s behaviour), and • terminating pure computations. the main area not supported is where the domain of channel-reads and io-actions is large and the result is used to influence decisions about the program’s flow. we also do not support programs with pure computations that do not terminate – such non-termination would also be problematic in the real running version of chp. 9 conclusions we have demonstrated a technique for generating csp models of haskell programs that use the chp library. it does not require complete access to the source code, and requires minimal program annotation. the technique can be used to generate models for prototype programs (or programs developed with an agile methodology) or to generate models for programs and perform a refinement check against a specification. the cspm that is generated by our approach can be passed directly to tools such as fdr in order to prove properties such as freedom from deadlock or perform refinement checks. it can proc. avocs 2009 10 / 12 eceasst also be used with other model-checkers (such as prob [lf08]) or tools (such as fdr explorer [fw09]) on the specification. alternatively, a tool such as probe [ros97] could be used to explore the possible traces of a program by deciding which of all the available events should happen next. 9.1 availability the chp library is already available for general use – more details can be found at http://www. cs.kent.ac.uk/projects/ofa/chp/. we hope to soon release the mirror implementation described in this paper that generates csp models. bibliography [bro08] n. c. c. brown. communicating haskell processes: composable explicit concurrency using monads. in communicating process architectures 2008. pp. 67–84. sept. 2008. [bs08] n. c. c. brown, m. l. smith. representation and implementation of csp and vcr traces. in communicating process architectures 2008. pp. 329–345. sept. 2008. [ch00] k. claessen, j. hughes. quickcheck: a lightweight tool for random testing of haskell programs. in proc. of international conference on functional programming (icfp). acm sigplan, 2000. [for97] formal systems (europe) ltd. failures-divergence refinement: fdr2 manual. 1997. [fw09] l. freitas, j. woodcock. fdr explorer. formal aspects of computing 21:133–154, 2009. [hoa85] c. a. r. hoare. communicating sequential processes. prentice-hall, 1985. http://www.usingcsp.com/ [lf08] m. leuschel, m. fontaine. probing the depths of csp-m: a new fdr-compliant validation tool. icfem 2008, 2008. [rnl08] c. runciman, m. naylor, f. lindblad. smallcheck and lazy smallcheck: automatic exhaustive testing for small values. in haskell ’08: proceedings of the first acm sigplan symposium on haskell. pp. 37–48. acm, 2008. [ros97] a. w. roscoe. the theory and practice of concurrency. prentice-hall, 1997. http://www.comlab.ox.ac.uk/people/bill.roscoe/publications/68b.pdf 11 / 12 volume 23 (2009) http://www.cs.kent.ac.uk/projects/ofa/chp/ http://www.cs.kent.ac.uk/projects/ofa/chp/ http://www.usingcsp.com/ http://www.comlab.ox.ac.uk/people/bill.roscoe/publications/68b.pdf automatically generating csp models for communicating haskell processes channel fork_left_phil0 channel fork_left_phil1 channel fork_left_phil2 channel fork_right_phil0 channel fork_right_phil1 channel fork_right_phil2 college_1= (((fork_2) [|{| fork_left_phil1 , fork_right_phil0 |}|] ((fork_3) [|{| fork_left_phil2 , fork_right_phil1 |}|] ((fork_4) [|{| fork_left_phil0 , fork_right_phil2 |}|] ((philosopher_5) ||| ((philosopher_6) ||| (philosopher_7))))))) fork_2= (repeated_8) fork_3= (repeated_9) fork_4= (repeated_10) main_0= (college_1) philosopher_5= (repeated_11) philosopher_6= (repeated_12) philosopher_7= (repeated_13) repeated_8= (((fork_right_phil0 -> fork_right_phil0 -> skip) [] (fork_left_phil1 -> fork_left_phil1 -> skip)) ; repeated_8) repeated_9= (((fork_right_phil1 -> fork_right_phil1 -> skip) [] (fork_left_phil2 -> fork_left_phil2 -> skip)) ; repeated_9) repeated_10= (((fork_right_phil2 -> fork_right_phil2 -> skip) [] (fork_left_phil0 -> fork_left_phil0 -> skip)) ; repeated_10) repeated_11= (((fork_left_phil0 -> skip) ||| (fork_right_phil0 -> skip)) ; ((fork_left_phil0 -> skip) ||| (fork_right_phil0 -> skip)) ; repeated_11) repeated_12= (((fork_left_phil1 -> skip) ||| (fork_right_phil1 -> skip)) ; ((fork_left_phil1 -> skip) ||| (fork_right_phil1 -> skip)) ; repeated_12) repeated_13= (((fork_left_phil2 -> skip) ||| (fork_right_phil2 -> skip)) ; ((fork_left_phil2 -> skip) ||| (fork_right_phil2 -> skip)) ; repeated_13) main = main_0 figure 1: the generated model for the deadlocking version of the dining philosophers with three philosophers. proc. avocs 2009 12 / 12 introduction chp approach reading from channels value sources recursion and looping io actions examples copy buffer dining philosophers post-processing alphabets summary conclusions availability paper.dvi electronic communications of the easst volume 2 (2006) proceedings of the workshop on petri nets and graph transformation (pngt 2006) algebraic high-level nets as weak adhesive hlr categories ulrike prange 13 pages guest editors: paolo baldan, hartmut ehrig, julia padberg, grzegorz rozenberg managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 eceasst algebraic high-level nets as weak adhesive hlr categories ulrike prange department of software engineering and theoretical computer science technical university of berlin, germany uprange@cs.tu-berlin.de abstract: adhesive high-level replacement (hlr) systems have been recently introduced as a new categorical framework for double pushout transformations. algebraic high-level nets combine algebraic specifications with petri nets to allow the modelling of data, data flow and data changes within the net. in this paper, we show that algebraic high-level schemas and nets fit well into the context of weak adhesive hlr categories. this allows us to apply the developed theory also to algebraic high-level net transformations. keywords: algebraic high-level nets, adhesive hlr categories 1 introduction adhesive high-level replacement (hlr) systems have been recently introduced as a new categorical framework for graph transformation in the double pushout approach [ehpp06, eept06]. they combine the well-known framework of hlr systems with the framework of adhesive categories introduced by lack and sobociński [ls05]. the main concept behind adhesive categories are the so-called van kampen squares, which ensure that pushouts along monomorphisms are stable under pullbacks and, vice versa, that pullbacks are stable under combined pushouts and pullbacks. in the case of adhesive hlr categories the class of all monomorphisms is replaced by a subclass m of monomorphisms closed under composition and decomposition. algebraic high-level (ahl) nets combine algebraic specifications with petri nets [per95] to allow the modelling of data, data flow and data changes within the net. in general, an ahl net denotes a net based on a specification sp in combination with an sp-algebra a, in contrast a net without a specific algebra is called a schema. while many types of graphs and graph-like structures are adhesive hlr categories, the categories of elementary nets, place/transition nets as well as ahl schemas with fixed specification only satisfy a weaker version of adhesive hlr categories [ep06] called weak adhesive hlr categories. the reason is that the category ptnets of place/transition nets has general pullbacks, but pullbacks in general cannot be constructed componentwise in sets. however, pullbacks along monomorphisms in ptnets can be constructed componentwise in sets. this is the key idea to weaken the concept of adhesive hlr categories using weak vk squares. in this case, van kampen squares ensure the corresponding properties only under stricter requirements on the morphisms. nevertheless, the framework of weak adhesive hlr categories is still sufficient to show under some additional assumptions (which are necessary also in the non-weak case) as 1 / 13 volume 2 (2006) algebraic high-level nets as weak adhesive hlr categories main results the local church-rosser theorem, the parallelism theorem, the concurrency theorem, the embedding and extension theorem and the local confluence theorem, also called critical pair lemma. thus, underlying an adhesive hlr systems we consider either a weak or a non-weak adhesive hlr category. since this concept of adhesive hlr systems includes all kinds of graphs mentioned above, and also elementary nets, place/transition nets and ahl schemas with fixed specification, adhesive hlr systems can be seen as a suitable unifying framework for graph and petri net transformations. the question arises, if and how different types of ahl schemas and nets, where we do not fix the algebra or the specification, fit into the framework of adhesive hlr systems. in case of ahl nets with fixed specification sp, this category of ahl nets can be shown to be a weak adhesive hlr category, if the underlying category of algebras algs(sp), together with a suitable morphism class m , is a weak adhesive hlr category. generalized ahl schemas, where the specification may change, can be shown to be a weak adhesive hlr category using an isomorphic comma category construction. in case both specification and algebra may change, the corresponding category of generalized ahl nets is a weak adhesive hlr category, if the category of all algebras can be shown to be a weak adhesive hlr category. these three results are the main new contributions of this paper. this paper is organized as follows: in section 2, we introduce weak adhesive hlr categories and systems and review in section 3, that different kinds of petri nets are weak adhesive hlr categories. in section 4, ahl schemas and nets are described and shown to be weak adhesive hlr categories. in section 5, we present generalized ahl schemas and nets and prove the properties of a weak adhesive hlr category. at last, in section 6 we give a conclusion and identify future work. 2 review of weak adhesive hlr categories and systems the intuitive idea of (weak) adhesive hlr categories are categories with suitable pushouts and pullbacks which are compatible with each other. more precisely the definition is based on socalled van kampen squares. the idea of a van kampen (vk) square is that of a pushout which is stable under pullbacks, and vice versa that pullbacks are stable under combined pushouts and pullbacks. definition 1 a pushout (1) is a van kampen square, if for any commutative cube (2) with (1) in the bottom and the back faces being pullbacks holds: the top face is a pushout if and only if the front faces are pullbacks. a′ b′ a b c′ d′ c d (2) m′ a f ′ g′ b m f n′ c d n g a b c d (1) m f n g since not even in the category sets of sets and functions each pushout is a van kampen square, proc. pngt 2006 2 / 13 eceasst for (weak) adhesive hlr categories only those vk squares of definition 1 are considered where m is a monomorphism. the main difference between (weak) adhesive hlr categories as described in [ehpp06, eept06] and adhesive categories introduced in [ls05] is that a distinguished class m of monomorphisms is considered instead of all monomorphisms, so that only pushouts along m morphisms have to be vk squares. in the weak case, only special cubes are considered for the vk square property. definition 2 a category c with a morphism class m is a (weak) adhesive hlr category, if 1. m is a class of monomorphisms closed under isomorphisms, composition ( f : a → b ∈ m , g : b →c ∈ m ⇒ g◦ f ∈ m ) and decomposition (g◦ f ∈ m , g ∈ m ⇒ f ∈ m ), 2. c has pushouts and pullbacks along m -morphisms and m -morphisms are closed under pushouts and pullbacks, 3. pushouts in c along m -morphisms are (weak) vk squares. for a weak vk square, the vk square property holds for all commutative cubes with m ∈ m and ( f ∈ m or b, c, d ∈ m ) (see definition 1). the categories sets of sets and functions, graphs of graphs and graph morphisms and graphstg of typed graphs and typed graph morphisms are adhesive hlr categories for the class m of all monomorphisms. moreover, an important example is the category (agraphsatg, m ) of typed attributed graphs with a type graph at g and the class m of all injective morphisms with isomorphisms on the data part. the categories elemnets of elementary nets and ptnets of place/transition nets with the class m of all corresponding monomorphisms fail to be adhesive hlr categories, but they are weak adhesive hlr categories (see section 3). both adhesive and weak adhesive hlr categories are closed under product, slice, coslice, functor and comma category constructions. that means we can construct new (weak) adhesive hlr categories from given ones. theorem 1 if (c, m1) and (d, m2) are (weak) adhesive hlr categories, then the following categories are also (weak) adhesive hlr categories: 1. the product category (c×d, m1×m2), 2. the slice category (c\x , m1 ∩c\x ) and the coslice category (x\c, m1 ∩x\c) for any object x in c, 3. for every category x the functor category ([x, c], m1-functor transformations), where an m1-functor transformation is a natural transformation t : f → g where all morphisms tx : f(x ) → g(x ) are in m1, 4. the comma category (comcat(f, g; i ), m ) with m = (m1 ×m2)∩morcomcat(f,g;i ) and functors f : c → x, g : d → x, where f preserves pushouts along m1-morphisms and g preserves pullbacks (along m2-morphisms). 3 / 13 volume 2 (2006) algebraic high-level nets as weak adhesive hlr categories now we are able to generalize graph transformation systems, grammars and languages in the sense of [ehr79, eept06]. in general, an adhesive hlr system is based on productions, also called rules, that describe in an abstract way how objects in this system can be transformed. an application of a production is called a direct transformation and describes how an object is actually changed by the production. a sequence of these applications yields a transformation. definition 3 given a (weak) adhesive hlr category (c, m ), a production p = (l l ← k r → r) (also called rule) consists of three objects l, k and r called left hand side, gluing object and right hand side respectively, and morphisms l : k → l, r : k → r with l, r ∈ m . given a production p = (l l ← k r → r) and an object g with a morphism m : l → g, called match, a direct transformation g p,m =⇒h from g to an object h is given by the following diagram, where (1) and (2) are pushouts. a sequence g0 ⇒ g1 ⇒ ... ⇒ gn of direct transformations is called a transformation and is denoted as g0 ∗ ⇒ gn. l k r g d h (1) (2) l r m k n f g an adhesive hlr system ah s = (c, m , p) consists of a (weak) adhesive hlr category (c, m ) and a set of productions p. 3 petri nets as weak adhesive hlr categories petri net transformation systems have been first introduced in [ehkp91] for the case of low-level nets and in [per95] for high-level nets using the algebraic presentation of petri nets as monoids introduced in [mm90]. the main idea of petri net transformation systems is to extend the wellknown theory of petri nets based on the token game by general techniques which allow to change also the structure of the nets. in [pad96], a systematic study of petri net transformation systems has been presented in the categorical framework of abstract petri nets, which can be instantiated to different kinds of low-level and high-level petri nets. in this section we introduce our notion of elementary nets and place/transition nets and recapitulate that the respective categories (elemnets, m ) and (ptnets, m ) are weak adhesive hlr categories (see [ep06]). the corresponding instantiations of adhesive hlr systems lead to different kinds of petri net transformation systems. definition 4 an elementary net is given by n = (p, t, pre, post) with a set p of places, t of transitions, and preand post-domain functions pre, post : t → p(p), where p is the power set functor. an elementary net morphism f : n → n′ is given by f = ( fp : p →p ′, ft : t → t ′) compatible with the preand post-domain functions, i.e. pre′◦ ft = p( fp)◦ pre and post ′◦ ft = p( fp)◦ post. elementary nets and elementary net morphisms form the category elemnets. proc. pngt 2006 4 / 13 eceasst corollary 1 the category (elemnets, m ) is a weak adhesive hlr category, where m is the class of all injective morphisms. proof idea. the category elemnets is isomorphic to the comma category comcat(idsets, p; i ), where p : sets → sets is the power set functor and i = {1, 2}. according to theorem 1.4 it suffices to note that (sets, m ) is a weak adhesive hlr category and that p : sets → sets preserves pullbacks along injective morphisms. note, that (elemnets, m ) is not an adhesive hlr category as stated in [eept06], since p only preserves pullbacks along injective morphisms, but not over general ones. definition 5 a place/transition net n = (p, t, pre, post) is given by a set p of places, a set t of transitions, as well as preand post-domain functions pre, post : t → p⊕, where p⊕ is the free commutative monoid over p. a place/transition net morphism f : n → n′ is given by f = ( fp : p→ p ′, ft : t →t ′) compatible with the preand post-domain functions, i.e. pre′◦ ft = f ⊕ p ◦ pre and post ′◦ ft = f ⊕ p ◦ post. place/transition nets and place/transition net morphisms form the category ptnets. corollary 2 the category (ptnets, m ) is a weak adhesive hlr category, if m is the class of all injective morphisms. proof idea. the category ptnets is isomorphic to the comma category comcat(idsets, � ⊕; i ) with i = {1, 2}, where �⊕ : sets → sets is the free commutative monoid functor. according to theorem 1.4 it suffices to note that (sets, m ) is a weak adhesive hlr category and that �⊕ : sets → sets preserves pullbacks along injective morphisms. the following example shows that (ptnets, m ) is not an adhesive hlr category. this is due to the fact, that �⊕ : sets → sets does not preserve general pullbacks. this would imply that pullbacks in ptnets are constructed componentwise for places and transitions. example 1 in figure 1, the square (1) with non-injective morphisms g1, g2, p1, p2 is a pullback in the category ptnets, where the transition component is not a pullback in sets. in the cube, the bottom face is a pushout in ptnets along an injective morphism m ∈ m , all front and back faces are pullbacks, but the top face is no pushout. hence, this cube violates the vk property. 4 ahl schemas and nets as weak adhesive hlr categories in this section, we combine algebraic specifications with petri nets leading to ahl schemas and nets (see [per95]). intuitively, an ahl net is a petri net, where ordinary, uniform tokens are replaced by data elements from the given algebra. firing a transition t means to remove some data elements from the input places and add some data elements, computed by term evaluation, to the output places of t. there could be also some firing conditions to restrict the firing behaviour of a transition. in addition, a typing of the places restricts the data elements which could be put on each place to that of a certain type. 5 / 13 volume 2 (2006) algebraic high-level nets as weak adhesive hlr categories t0 t′0 1,1′ 1,2′ 2,2′ 2,1′ t1 1 2 t2 1′ 2′ t3 p 2 (1) a b c d p1 p2 g2 g1 t0 t′0 1,1′ 1,2′ 2,2′ 2,1′ t1 1 2 t2 1′ 2′ t3 p 2 1,1′ 1,2′ 2,2′ 2,1′ 1 2 1′ 2′ 1m p1 p2 g2 g1 figure 1: the pullback (1) in ptnets and the cube violating the vk property definition 6 an ahl schema over an algebraic specification sp, where sp = (sig, e, x ) has additional variables x and sig = (s, op), is given by as = (p, t, pre, post, cond,type) with sets p and t of places and transitions, pre, post : t → (tsig(x )⊗p) ⊕ as preand post-domain functions, cond : t → p f in(e qns(sig, x )) assigning to each t ∈ t a finite set cond(t) of equations over sig and x , and type : p → s a type function. note that tsig(x ) is the sig-term algebra with variables x and (tsig(x )⊗p) = {(term, p) | term ∈ tsig(x )type(p), p ∈ p}. an ahl schema morphism f : as → as′ is given by a pair of functions f = ( fp : p → p ′, ft : t → t ′) which are compatible with pre, post, cond and type as shown below. p f in(e qns(sig, x )) t (tsig(x )⊗p) ⊕ t ′ (tsig(x )⊗p ′)⊕ p p′ s pre post pre′ post′ cond cond′ ft (id⊗ fp) ⊕ ty pe ty pe′ fp== = given an algebraic specification sp, ahl schemas over sp and ahl schema morphisms form the category ahlschemas(sp). as shown in [eept06], ahl schemas over a fixed algebraic specification sp are a weak adhesive hlr category. corollary 3 the category (ahlschemas(sp), m ) is a weak adhesive hlr category. m is the class of all injective morphisms f , i.e. fp and ft are injective. proof idea. since sp is fixed, the construction of pushouts and pullbacks in ahlschemas(sp) is essentially the same as in ptnets, which is already a weak adhesive hlr category. we can apply the idea of comma categories comcat(f, g; i ), where in our case the source functor of the operations pre, post, cond,type is always the identity idsets, and the target functors are (tsig(x )⊗ ) ⊕ : sets → sets and two constant functors. in fact, (tsig(x )⊗ ) : sets → sets, the constant functors and �⊕ : sets → sets preserve pullbacks along injective functions. hence also (tsig(x )⊗ ) ⊕ : sets → sets preserves pullbacks along injective functions. proc. pngt 2006 6 / 13 eceasst to represent the actual data space, we combine ahl schemas and algebras to ahl nets. definition 7 an ahl net an = (s, a) is given by an ahl schema s over sp and an sp-algebra a. an ahl net morphism f : an → an′ is given by a pair f = ( fs : s → s ′, fa : a → a ′), where fs is an ahl schema morphism and fa an sp-homomorphism. given an algebraic specification sp, ahl nets over sp and ahl net morphisms form the category ahlnets(sp). corollary 4 if (algs(sp), m ) is a weak adhesive hlr category then the category (ahlnets(sp), m ′) is a weak adhesive hlr category. m ′ is the class of all morphisms f = ( fs, fa), where fs is injective and fa ∈ m . proof idea. the category ahlnets(sp) is isomorphic to the product category ahlschemas(sp) × algs(sp). according to theorem 1.1 this implies that (ahlnets(sp), m ′) is a weak adhesive hlr category. up to now, it is not clear whether the category algs(sp) of algebras over an arbitrary specification sp with the class m of injective morphisms is a weak adhesive hlr category. this has been shown in [eept06] only for so-called graph structure algebras, where only unary operations are allowed. for an arbitrary specification, we can use the class m of isomorphisms to obtain a weak adhesive hlr category. 5 generalized ahl schemas and nets as weak adhesive hlr categories we get a more powerful variant of ahl schemas, called generalized ahl schemas, if we do not fix the specification. this is especially useful for net transformations, where we can define rules based on a (small) specification sp, which represents the necessary data, that can be applied to nets over a (larger) specification sp′. in this section, we define generalized ahl schemas and nets, and show that they form weak adhesive hlr categories under certain conditions on the data part. definition 8 a generalized ahl schema gs = (sp, as) is given by an algebraic specification sp and an ahl schema as over sp. a generalized ahl schema morphism f : gs → gs′ is a tuple f = ( fsp : sp → sp ′, fp : p → p′, ft : t → t ′), where fsp is a specification morphism and fp, ft are compatible with pre, post, cond and type. f #sp is the extension of fsp to terms and equations. p f in(e qns(sig, x )) p f in(e qns(sig ′, x )) t (tsig(x )⊗p) ⊕ t ′ (tsig′(x )⊗p ′)⊕ p p′ s s′ p f in ( f # sp) fsp,s pre post pre′ post′ cond cond′ ft ( f #sp⊗ fp) ⊕ ty pe ty pe′ fp== = generalized ahl schemas and generalized ahl schema morphisms form the category ahlschemas. 7 / 13 volume 2 (2006) algebraic high-level nets as weak adhesive hlr categories to show that generalized ahl schemas form a weak adhesive hlr category, we need an extension of comma categories, where we loosen the restrictions on the domain of the functors. definition 9 given index sets i and j , categories c j for j ∈ j and xi for i ∈ i , and for each i ∈ i two functors fi : cki → xi, gi : c`i → xi with ki, `i ∈ j , then the general comma category gcomcat((c j) j∈j , (fi, gi)i∈i ; i , j ) is defined by • objects ((a j ∈ c j) j∈j , (opi)i∈i ), where opi : fi(aki ) → gi(a`i ) is a morphism in xi, • morphisms h : ((a j), (opi)) → ((a ′ j), (op ′ i)) as tuples h = ((h j : a j → a ′ j) j∈j ) such that for all i ∈ i op′i ◦fi(hki ) = gi(h`i )◦opi. we can extend the result from theorem 1.4 to general comma categories, such that the general comma category is a weak adhesive hlr category under certain conditions. theorem 2 a general comma category gc = (gcomcat((c j) j∈j , (fi, gi)i∈i ; i , j ), m ) with m = (× j∈j m j)∩morgc is a weak adhesive hlr category, if (c j, m j) are weak adhesive hlr categories for j ∈ j , and for all i ∈ i fi preserves pushouts along mki -morphisms and gi preserves pullbacks along m`i -morphisms. proof idea. it is easy to show that m is a class of monomorphisms closed under isomorphisms, composition and decomposition since this holds for all components m j. as in normal comma categories, pushouts along m -morphisms are constructed componentwise in the underlying categories. the pushout object is the componentwise pushout object, where the operations are uniquely defined using the property that fi preserves pushouts along mki -morphisms. analogously, pullbacks along m -morphisms are constructed componentwise, where the operations of the pullback object are uniquely defined using the property that gi preserves pullbacks along m`i -morphisms. the weak vk square property follows, since in a proper cube, all pushouts and pullbacks can be decomposed leading to proper cubes in the underlying categories, where the weak vk property holds. the subsequent recomposition yields the weak vk property for the general comma category. also the restriction of a weak adhesive hlr category to a full subcategory yields a weak adhesive hlr category, if the pushouts and pullbacks over m -morphisms are preserved. corollary 5 given a weak adhesive hlr category (c, m ), a full subcategory (c′, m ′) of c with m ′ = m |c′ is a weak adhesive hlr category, if c ′ has pushouts and pullbacks along m ′-morphisms which are preserved by the inclusion functor. proof idea. by precondition, pushouts and pullbacks along m ′-morphisms in c′ exist. obviously, m ′ is a class of monomorphisms with the required properties. since we only restrict the objects and morphisms, the weak vk square property is inherited from c. with these results, we are now able to show that the category of generalized ahl schemas is a weak adhesive hlr category. proc. pngt 2006 8 / 13 eceasst theorem 3 the category (ahlschemas, m ) is a weak adhesive hlr category. m is the class of all morphisms f = ( fsp, fp, ft ), where fsp is a strict injective specification morphism and fp, ft are injective. proof. the category ahlschemas is isomorphic to a suitable full subcategory of the general comma category gc = gcomcat(c1, c2, (fi, gi)i∈i ; i , j ) with • i = {pre, post, cond,type}, j = {1, 2}, • c1 = specs×sets, c2 = sets, xi = sets for all i ∈ i , • fi : c2 → xi for i ∈{pre, post, cond}, ftype : c1 → xtype, gi : c1 → xi for all i ∈ i , where the functors are defined by • fi = idsets, gi(sp, p) = (tsig(x )×p) ⊕, gi( fsp, fp) = ( f # sp × fp) ⊕ for i ∈{pre, post}, • fcond = idsets, gcond (sp, p) = p f in(e qns(sig, x )), gcond ( fsp, fp) = p f in( f # sp), • ftype(sp, p) = p, ftype( fsp, fp) = fp, gtype(sp, p) = s, gtype( fsp, fp) = fsp,s. since (specs, m1) with the class m1 of strict injective morphisms and (sets, m2) with the class m2 of injective morphisms are weak adhesive hlr categories, theorem 1.1 implies that also (specs×sets, m1 ×m2) is a weak adhesive hlr category. the functors fi preserve pushouts along mki -morphisms, which is obvious for fpre, fpost , fcond and shown in corollary 6 for ftype, and the functors gi preserve pullbacks along m`i -morphisms as shown in corollary 7, corollary 8 and corollary 9, therefore we can apply theorem 2 such that gc is a weak adhesive hlr category. now we restrict the objects ((sp, p), t, pre, post, cond,type) in gc to those, where (1) pre(t), post(t) ∈ (tsig(x )⊗p) ⊕ for all t ∈ t. the full subcategory induced by these objects is isomorphic to ahlschemas. since the condition (1) is preserved by pushout and pullback constructions in gc, it follows that for morphisms f , g ∈ ahlschemas with the same (co)domain, the pushout (pullback) over f , g in gc is also the pushout (pullback) in ahlschemas. with corollary 5 we conclude that (ahlschemas, m ) is a weak adhesive hlr category. corollary 6 the functor h : specs×sets → sets : (sp, m) 7→ m, ( fsp, fm ) 7→ fm preserves pushouts (along m1 ×m2-morphisms). proof. in a product category, a square is a pushout if and only if the componentwise squares are pushouts in the underlying categories. thus, if (1) is a pushout in specs×sets also (2) is a pushout in sets, which means that h preserves pushouts. (sp0, m0) (sp1, m1) (sp2, m2) (sp3, m3) (1) ( fsp, fm ) (gsp,gm ) (g ′ sp,g ′ m ) ( f ′sp, f ′ m ) m0 m1 m2 m3 (2) fm gm g′m f ′m 9 / 13 volume 2 (2006) algebraic high-level nets as weak adhesive hlr categories corollary 7 the functor h : specs×sets → sets : (sp, m) 7→ s, ( fsp, fm ) 7→ fsp,s preserves pullbacks (along m1 ×m2-morphisms). proof. in a product category, a square is a pullback if and only if the componentwise squares are pullbacks in the underlying categories. thus, if (3) is a pullback in specs×sets also (4) is a pullback in specs. in specs, pullbacks are constructed componentwise on the signature part (with some special treatment of the equations). thus, also (5) is a pullback in sets, which means that h preserves pullbacks. (sp0, m0) (sp1, m1) (sp2, m2) (sp3, m3) (3) ( fsp, fm ) (gsp,gm ) (g ′ sp,g ′ m ) ( f ′sp, f ′ m ) sp0 sp1 sp2 sp3 (4) fsp gsp g′sp f ′sp s0 s1 s2 s3 (5) fsp,s gsp,s g′sp,s f ′sp,s tsig0 (x0) tsig1 (x1) tsig2 (x2) tsig3 (x3) (6) f #sp g#sp g ′# sp f ′#sp corollary 8 the functor h : specs×sets → sets : (sp, m) 7→ (tsig(x )×m)⊕, ( fsp, fm ) 7→ ( f #sp × fm) ⊕ preserves pullbacks along m1 ×m2-morphisms. proof. the product functor × preserves general pullbacks and, as shown in [eept06], the functor �⊕ preserves pullbacks along injective morphisms. thus, it lasts to show that t : specs → sets : sp 7→ tsig(x ), where we forget the type information of the terms, preserves pullbacks. in specs, the pullback (4) is constructed componentwise on the sorts, operations and variables, which means that s0 = {(s1, s2) | g ′ sp,s(s1) = f ′ sp,s(s2)}, op0 = {(op1, op2) : (s 1 1, s 1 2)...(s n 1, s n 2) → (s1, s2) | g ′ sp,op(op1 : s 1 1...s n 1 → s1) = f ′ sp,op(op2 : s 1 2...s n 2 → s2)} and x0 = {(x1, x2) | g ′ sp,x (x1) = f ′sp,x (x2)}. therefore, the terms in tsig0 (x0) are defined by tsig0,s(x0) = x0,s ∪{(c1, c2) | (c1, c2) :→ s ∈ op0}∪{(op1, op2)(t1, ..,tn) | (op1, op2) : s1...sn → s ∈ op0,ti ∈ tsig0,si (x0)}. we have to show that tsig0 (x0) is isomorphic to the pullback object p over f ′# sp and g ′# sp with p = {(t1,t2) | g ′# sp(t1) = f ′# sp(t2)}. since p is a pullback, with f ′# sp ◦ g # sp = g ′# sp ◦ f # sp we get an induced morphism i : tsig0 (x0) → p with i(t) = ( f # sp(t), g # sp(t)), which means that i is inductively defined by i(c1, c2) = (c1, c2) for constants, i(x1, x2) = (x1, x2) for variables and i((op1, op2)(t1, ...,tn)) = (op1(i(t1)1, ..., i(tn)1), op2(i(t1)2, ..., i(tn)2)) for complex terms. f ′sp, g ′ sp are specification morphisms and f ′# sp, g ′# sp are inductively defined on terms. this means, for a pair (t1,t2) ∈ p, the terms t1 and t2 have to have the same structure. define j : p → tsig0 (x0) inductively by j(c1, c2) = (c1, c2) for constants, j(x1, x2) = (x1, x2) for variables and j(op1(t 1 1 , ...,t n 1 ), op2(t 1 2 , ...,t n 2 )) = (op1, op2)( j(t 1 1 ,t 1 2 ), ..., j(t n 1 ,t n 2 )) for complex terms. by induction, it can be shown that i◦ j = idp and j◦i = idtsig0 (x0) . this means that i and j are isomorphisms and (6) is a pullback in sets. corollary 9 the functor h : specs×sets→sets : (sp, m) 7→p f in(e qns(sig, x )), ( fsp, fm) 7→ p f in( f # sp) preserves pullbacks along m1 ×m2-morphisms. proof. in [eept06], it is shown that p preserves pullbacks along injective morphisms. analogously, this can be shown for p f in, since if we start the construction for finite sets, this property is preserved. thus, it lasts to show that e qns preserves pullbacks, which can be proven similar to the proof for sets of terms in corollary 8 above. proc. pngt 2006 10 / 13 eceasst x l(x)⊕r(x) xx x l(x)⊕r(x) think:phil eat:phil table: f orkput take sorts : phil, f ork opns : p1, ..., pn :→ phil f1, ..., fn :→ f ork l, r : phil → f ork eqns : l(pi) = fi ∀i = 1, ..., n r(pi) = fi+1 ∀i = 1, ..., n−1 r(pn) = f1 figure 2: the ahl net for n dining philosophers as previously, we combine generalized ahl schemas and algebras to generalized ahl nets. definition 10 a generalized ahl net gn = (gs, a) is given by a generalized ahl schema gn over the algebraic specification sp and an sp-algebra a. a generalized ahl net morphism f : gn → gn′ is a tuple f = ( fgs : gs → gs ′, fa : a → vfsp (a ′)), where fgs is a generalized ahl schema morphism and fa an algebra homomorphism. vfsp : algs(sp ′) → algs(sp) is the forgetful functor induced by fsp. generalized ahl nets and generalized ahl net morphisms form the category ahlnets. corollary 10 if the category (algs, m1) of all algebras and generalized homomorphisms is a weak adhesive hlr category, then also the category (ahlnets, m ) is a weak adhesive hlr category. m is the class of all injective ahl net morphisms f with fa ∈ m1. proof idea. the category ahlnets is isomorphic to the full subcategory (ahlschemas×algs)|ob′, where ob ′ = {((sp, p, t, pre, post, cond,type), a) | a ∈ algs(sp)}. in this subcategory, the pushout and pullback objects over m -morphisms are the same as in ahlschemas×algs. according to theorem 1.1 and corollary 5 this implies that (ahlnets, m ) is a weak adhesive hlr category. up to now we do not know whether the category (algs, m1) with the class m1 of injective morphisms is a weak adhesive hlr category. but if we restrict m1 to isomorphisms, (algs, m1) is a weak adhesive hlr category and m1 is already a useful class for rules in net transformation systems. in many cases, one does not want to change the specification and algebra within the rule (where m1-morphisms are necessary). but for the match, general morphisms are allowed, thus we can apply such a rule to nets over different specifications and with different algebras. another possibility is to restrict the algebra part to quotient term algebras leading to the category algs|qta with objects (sp, tsp) and morphisms f = ( fsp, ft ) : (sp, tsp) → (sp ′, tsp′) with fsp : sp → sp′ and ft : tsp → vfsp (tsp′) uniquely determined. algs|qta is isomorphic to the category of specifications and thus, together with strict injective morphisms, a weak adhesive hlr category. in the following, we present an example based on the well-known dining philosophers problem (see [bee01]), where the behaviour of the philosophers is modeled by a net, while the philosophers themselves are modeled within the data structure. example 2 for n philosophers, the ahl net with its specification is given in figure 2. for the 11 / 13 volume 2 (2006) algebraic high-level nets as weak adhesive hlr categories x xf av(x) f av(x)x xthink:phil think:phil think:phil read:phil lib:book get returnsorts: phil sorts: phil sorts: phil,book opns: f av:phil→book l k r l r x x f av(x)f av(x) x x x l(x)⊕r(x) xx x l(x)⊕r(x) read:phil lib:book think:phil eat:phil table: f orkput take return get sorts : phil, f ork, book opns : p1, ..., pn :→ phil f1, ..., fn :→ f ork l, r : phil → f ork f av : phil → book eqns : l(pi) = fi ∀i = 1, ..., n r(pi) = fi+1 ∀i = 1, ..., n−1 r(pn) = f1 figure 3: the production and the result of the direct transformation data part, we use the quotient term algebra. each philosopher pi has a left fork fi and a right fork fi+1, except pn with the right fork f1, and needs these two forks to eat. in the ahl net, this condition is assured by the preand post-domain functions. in the top of figure 3 an examplary production is shown, where we extend the possible behaviour of the philosophers. we introduce a library, where a philosopher pi may go to and get his favourite book f av(pi) to read. due to our developed theory, this very simple rule can be applied to all kinds of nets, independent from the number of philosophers. in the bottom, the application of this rule to the ahl net in figure 2 is shown, where the library has been introduced. note that also the specification has changed, since the new sort book and the operation f av have been added. now a thinking philosophers may go to the library by firing the new transition get. 6 conclusion and future work in this paper we have shown that all kinds of algebraic high-level schemas and nets are weak adhesive hlr categories. this means, that we can apply the theory for graph transformations developed in [eept06] also to different kinds of net transformations based on ahl schemas and nets. at the moment, the available data structure underlying the ahl nets is restricted to a few, but still interesting cases. more work is needed in the area of algebras, where the categories algs(sp) of algebras over a certain specification sp and algs of generalized algebras and homomorphisms should be verified to be weak adhesive hlr categories, likely under some restrictions on the specification or m -morphisms. the category algs is equivalent to a grothendieck category (see [tbg91]) indexed over the category specs. grothendieck categories have general pushouts and pullbacks, if so have the underlying categories, but they have not been shown to be proc. pngt 2006 12 / 13 eceasst weak adhesive hlr categories. a step towards this has been made in [eop06], where also some restrictions to the morphism class m are discussed which could lead to a suitable weak adhesive hlr category. bibliography [bee01] r. bardohl, c. ermel, h. ehrig. generic description of syntax, behavior and animation of visual models. technical report 19, tu berlin, 2001. [eept06] h. ehrig, k. ehrig, u. prange, g. taentzer. fundamentals of algebraic graph transformation. eatcs monographs. springer, 2006. [ehkp91] h. ehrig, a. habel, h. kreowski, f. parisi-presicce. parallelism and concurrency in high-level replacement systems. mathematical structures in computer science 1(3):361–404, 1991. [ehpp06] h. ehrig, a. habel, j. padberg, u. prange. adhesive high-level replacement systems: a new categorical framework for graph transformation. fundamenta informaticae 74(1):1–29, 2006. [ehr79] h. ehrig. introduction to the algebraic theory of graph grammars (a survey). in claus et al. (eds.), graph grammars and their application to computer science and biology. lncs 73, pp. 1–69. springer, 1979. [eop06] h. ehrig, f. orejas, u. prange. categorical foundations of distributed graph transformation. in corradini et al. (eds.), graph transformations. proceedings of icgt 2006. lncs 4178, pp. 215–229. springer, 2006. [ep06] h. ehrig, u. prange. weak adhesive high-level replacement categories and systems: a unifying framework for graph and petri net transformations. in futatsugi et al. (eds.), algebra, meaning and computation. essays dedicated to j.a. goguen. lncs 4060, pp. 235–251. springer, 2006. [ls05] s. lack, p. sobociński. adhesive and quasiadhesive categories. theoretical informatics and applications 39(3):511–546, 2005. [mm90] j. meseguer, u. montanari. petri nets are monoids. information and computation 88(2):105–155, 1990. [pad96] j. padberg. abstract petri nets: a uniform approach and rule-based refinement. phd thesis, tu berlin, 1996. [per95] j. padberg, h. ehrig, l. ribeiro. algebraic high-level net transformation systems. mathematical structures in computer science 5(2):217–256, 1995. [tbg91] a. tarlecki, r. burstall, j. goguen. some fundamental algebraic tools for the semantics of computation: part 3: indexed categories. theoretical computer science 91(2):239–264, 1991. 13 / 13 volume 2 (2006) preface electronic communications of the easst volume 34 (2010) proceedings of the 6th educators’ symposium: software modeling in education at models 2010 (edusymp 2010) preface martina seidl, peter j. clarke 3 pages guest editors: peter j. clarke, martina seidl managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst preface martina seidl1∗, peter j. clarke2 1business informatics group, vienna university of technology, austria, institute for formal models and verification, jku linz, austria martina.seidl@jku.at 2 school of computing and information sciences, florida int. university, usa clarkep@cis.fiu.edu abstract: collocated with the acm/ieee international conference on modeldriven engineering languages and systems (models), the educators’ symposium (edusymp) focuses on the huge topic of software modeling education ranging from experience reports and case studies to novel pedagogical approaches. in the following, we shortly report on the 6th edusymp held in october 2010 in oslo. keywords: modeling education, pedagogy for modeling 1 background over the last years, the technologies necessary to develop according to the model-driven engineering paradigm have made a huge step forward from mere academic research prototypes to mature production ready tools. these model-based technologies support handling the ever increasing complexity of modern software systems by raising the abstraction level. for their practical applications, developers are required which have been trained on working based on this higher level of abstraction. consequently, an adoption of the curricula of computer science is necessary to prepare future developers for the model-driven engineering technologies and to provide them with the skills necessary for their successful application. however, although model-driven engineering is already used in industry, it is still a young and emerging research discipline where it is not clear which technologies are just short-lived trends and which approaches have a long-lasting impact. the challenge here for educators is to find a compromise between well-established basic principles and the novel state-of-the-art technologies. to provide a forum to the educators and trainers from both academia and industry to exchange experiences and to discuss current trends and novel directions to follow in software modeling education the educators’ symposium (edusymp) has been established as a fixpoint at the models conference. in the remainder of this paper, we summarize the educators’ symposium 2010. 2 résumé on educators’ symposium 2010 despite the early hour, the edusymp started with a well attended keynote with the title “formality in education – bitter medicine or bitter administration?’ held by thomas kühne. in this ∗ this work has been partly funded by the austrian federal ministry of transport, innovation, and technology and the austrian research promotion agency under grant fit-it-819584. 1 / 3 volume 34 (2010) preface keynote, dos and don’ts were demonstrated to gain/to lose the students’ attention and to make them understand the teaching material. after the keynote, oral paper presentations where given. the papers are included in this volume. one third of the symposium was dedicated to discussions and a panel on the important topic of tooling in modeling education. in the forefront of the symposium, an online survey1 has been conducted to gain an impression about the current situation concerning modeling tools in education. within this context, the following questions have been discussed: • the field of software modeling continues to change rapidly. at what point in the continuum of change shall we start to teach modeling? • do students consider models to aid in software development or are they viewed as pretty pictures only? • can the benefits of modeling be realized without having proper tool support? • are tools imposing an extra inhibition/threshold in teaching modeling? • is it necessary for modeling tools to conform to standards or is it more important that they provide simplified concepts tailored for didactical purposes? • is it positive/negative when students are forced to use a specific tool implementation from a specific vendor? do we teach them knowledge with an expiration date? the generals consensus was that in software modeling education, teaching theory only is not enough, but hands-on experience of the students is indispensable. on the one hand, students are more motivated if they get some tools to play with, on the other hand, they only understand the taught concepts if they have the possibility to practically apply them. in the context of modeldriven engineering, they have to be shown that the creation of models (which seems to be an overhead only at the first look), overcomes traditional software engineering approaches within many aspects. as the courses on modeling cover a wide spectrum reaching from basic modeling courses over traditional software engineering courses to model-driven engineering courses, the requirements posed on modeling tools vary for the specific aims. in contrast to previous years, where there was a huge demand for more stable tools, in this year the participants expressed their satisfaction with regards to stability and documentation of the modeling tools. usability and user-friendliness still poses a major burden to the students. overall, this year’s symposium was very well attended (between 20 and 50 participants have been participating over the day) which clearly indicates that software modeling education is an important issue within the modeling research community. we hope that the discussions initiated at the symposium will result in interesting novel ideas on the realization on software modeling education and that the next edition of the symposium will continue increasing the awareness on the importance of high quality education. 1 a summary of the results is available at http://edusymp.big.tuwien.ac.at/slides/survey.pdf. proc. edusymp 2010 2 / 3 eceasst 3 acknowledgments the papers presented at edusymp and included in this volume have passed through a rigorous review process. at this place we would like to express our gratitude to the reviewers who supported the edusymp with excellent reviews. the list of the international program committee is shown below: • jordi cabot, école des mines de nantes, france • fábio costa, universidade federal de goiás, brazil • gregor engels, university of paderborn, germany • robert france, colorado state university, usa • martin gogolla, university of bremen, germany • jeff gray, university of alabama, usa • øystein haugen, sintef, norway • gerti kappel, vienna university of technology, austria • ludwik kuźniarz, blekinge institute of technology, sweden • timothy lethbridge, university of ottawa, canada • werner retschitzegger, johannes kepler university linz, austria • jean-paul rigault, university of nice, france • patricia roberts, university of westminster, uk • michal smialek, warsaw university of technology, poland • dániel varró, budapest university of technology and economics, hungary 3 / 3 volume 34 (2010) background résumé on educators' symposium 2010 acknowledgments stepping from graph transformation units to model transformation units electronic communications of the easst volume 30 (2010) international colloquium on graph and model transformation on the occasion of the 65th birthday of hartmut ehrig (gramot 2010) stepping from graph transformation units to model transformation units hans-jörg kreowski, sabine kuske, caroline von totth 24 pages guest editors: claudia ermel, hartmut ehrig, fernando orejas, gabriele taentzer managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst stepping from graph transformation units to model transformation units hans-jörg kreowski1, sabine kuske2, caroline von totth3∗ 1 kreo@informatik.uni-bremen.de 2 kuske@informatik.uni-bremen.de 3 caro@informatik.uni-bremen.de department of computer science university of bremen, germany abstract: graph transformation units are rule-based entities that allow to transform source graphs into target graphs via sets of graph transformation rules according to a control condition. the graphs and rules are taken from an underlying graph transformation approach. graph transformation units specify model transformations whenever the transformed graphs represent models. this paper is based on the observation that in general models are not always suitably represented as single graphs, but they may be specified as the composition of a variety of different formal structures such as sets, tuples, graphs, etc., which should be transformed by compositions of different types of rules and operations instead of single graph transformation rules. consequently, in this paper, graph transformation units are generalized to model transformation units that allow to transform such kind of composed models in a rule-based and controlled way. moreover, two compositions of model transformation units are presented. keywords: graph transformation, model transformation, transformation units, model transformation units 1 introduction computers are devices that can be used to solve all kinds of data-processing problems – at least in principle. the problems to be solved come from economy, production, administration, science, education, entertainment, and many other areas. there is quite a gap between the problems as one has to face them in reality and the solutions one has to provide so that they run on a computer. therefore, computerization is concerned with bridging this gap by transforming a problem into a solution. many efforts in computer science contribute to this need for transformation. first of all, compilers are devices that transform programs in a high-level language into programs in a low-level language where the latter are nearer and more adapted to the computer than the former. the possibility and success of compilers have fed the dream of transforming descriptions of data-processing problems automatically or at least systematically into solutions that are given by ∗ the authors would like to acknowledge that their research is partially supported by the collaborative research centre 637 (autonomous cooperating logistic processes – a paradigm shift and its limitations) funded by the german research foundation (dfg). 1 / 24 volume 30 (2010) mailto:kreo@informatik.uni-bremen.de mailto:kuske@informatik.uni-bremen.de mailto:caro@informatik.uni-bremen.de stepping from graph transformation units to model transformation units smoothly running programs. in recent years, the term model transformation has become popular for this idea. in this paper, graph transformation units are generalized to model transformation units as rulebased devices for modeling model transformations in a compositional framework. our approach has three sources of inspiration: 1. following the ideas of model-driven architecture (mda; cf., e.g., [fra03]), the aim of model transformation is to transform platform-independent models (pims), which allow to describe problems adequately, into platform-specific models (psms), which run properly and smoothly on a computer. as a typical description of the pims one may use uml diagrams, while psms are often just programs in some common higher-level language like java or c++. a significant model transformation language within the framework of mda is the qvt standard of the omg [omg08]. 2. one encounters quite an amazing number of model transformations in theoretical computer science – in formal language theory as well as in automata theory in particular. these areas provide a wealth of transformations between various types of grammars and automata like, for example, the transformation of nondeterministic finite automata into deterministic ones, or of pushdown automata into context-free grammars (or the other way round), or of arbitrary chomsky grammars into the pentonen normal form (to give a less known example). 3. graph transformation units (cf., e.g., [kks97, kk99, kkr08]) are rule-based devices to model binary relations between initial and terminal graphs. if the initial graphs are interpreted as input models and the terminal graphs as output models, then such a unit embodies a model transformation. the transformation of uml sequence diagrams into uml collaboration diagrams in [chk04] and the transformation of well-structured flow diagrams into while-programs in [khk06] are examples of this kind. this observation supports the idea to use graph transformation units as building blocks for the modeling of model transformations. while the models in the mda context are often diagrammatic or textual, the examples of theoretical computer science show that models may also be tuples with components being sets of something. accordingly, graphs as well as tuples, sequences, and sets of models are introduced as models in section 3, while section 2 provides the necessary mathematical preliminaries. the basic steps of model transformation are defined in section 4 by actions that are applied componentwise to tuples of models and consist of rules in case of graph components and of data type operations in all other cases. based on models and actions, the notion of a model transformation unit is introduced in section 5, providing the descriptions of input, working and output models, a set of actions, and a control condition to regulate the use of actions. the semantics of such a unit is a transformation of input models into output models. in section 6, the sequential and parallel compositions of model transformation units are studied. in this way, complex model transformations can be built up from simple ones in a modular way. while we discuss related work in section 7, the paper ends with some concluding remarks. as a running example, the transformation of right-linear grammars into finite state automata is developed in several stages. proc. gramot 2010 2 / 24 eceasst 2 preliminaries in this section, we recall the notion of a graph rule base providing a class of graphs, a class of rules and a rule application operator. in the following sections graphs are used as basic visual models and rules are used for their elementary transformations. besides graphs, we use identifiers, truth values, and non-negative integers as smallest atomic models. moreover, cartesian products, free monoids, and powersets are recalled because these constructions will be used to build up composite models in the next section. 2.1 graph rule bases a graph rule base b = (g ,r,=⇒) consists of a class of graphs g , a class of rules r, and a rule application operator =⇒ with =⇒ r ⊆ g × g for every r ∈ r. the rule application operator is used in infix notation, i.e, (g,h) ∈ =⇒ r is denoted by g =⇒ r h . subsections 2.2 through 2.4 present examples for the components of rule bases which are used throughout this paper. 2.2 graph classes there are many different kinds of graph classes, two of which are explored here further: the class of directed edge-labeled graphs and the class of finite state graphs, the latter being a subclass of the former. directed edge-labeled graphs. the class of directed, edge-labeled graphs with individual, possibly multiple edges is defined as follows. let σ be a set of labels. a graph over σ is a system g = (v,e,s,t,l) where v is a set of nodes, e is a set of edges, s,t : e → v are mappings assigning a source s(e) and a target t(e) to every edge in e , and l : e → σ is a mapping assigning a label to every edge in e . an edge e with s(e) = t(e) is also called a loop. for a node v ∈ v the number of edges which have v as source is denoted by outdegree(v) and the number of edges that point to v is the indegree of v. an edge e with label x is called an x-pointer if indegree(s(e)) = 0 and outdegree(s(e)) = 1. the components v , e , s, t, and l of g are also denoted by vg, eg, sg, tg, and lg, respectively. the set of all graphs over σ is denoted by gς. for graphs g,h ∈ gς, a graph morphism g : g → h is a pair of mappings gv : vg → vh and ge : eg → eh that are structure-preserving, i.e., gv (sg(e)) = sh(ge (e)), gv (tg(e)) = th(ge (e)), and lh(ge (e)) = lg(e) for all e ∈ eg. if the mappings gv and ge are inclusions, then g is called a subgraph of h, denoted by g ⊆ h. for a graph morphism g : g → h , the image of g in h is called a match of g in h , i.e., the match of g with respect to the morphism g is the subgraph g(g) ⊆ h . finite state graphs. two particular subclasses of gς are the classes of finite state graphs and finite state graphs with word transitions respectively. more concretely, let i be some input alphabet such that i∗ ⊎ {start,final} ⊆ σ 1. then the graph in figure 1 represents a finite state graph with word transitions over i = {a,b,c}, where the edges labeled with w ∈ i∗ represent transitions, 1 given sets x and y,x ⊎y denotes the disjoint union of x and y. 3 / 24 volume 30 (2010) stepping from graph transformation units to model transformation units start finala ccc a bb ccc figure 1: a finite state graph with word transitions start final a b b c c c c c c a figure 2: a finite state graph and the sources and targets of the transitions represent states. the start state is indicated with a start-pointer and every final state with a final-pointer. states are depicted as unfilled circles whereas all other nodes are shown as small filled circles. figure 2 shows a finite state graph where each transition is labeled with a symbol from i. 2.3 rules to be able to transform graphs, rules are applied to the graphs yielding graphs again. one rule class that can be used to transform graphs in gς is defined as follows. a rule r = (l ⊇ k ⊆ r) consists of three graphs l,k,r ∈ gς such that k is a subgraph of l and r. the components l, k, and r of r are called left-hand side, gluing graph, and right-hand side, respectively. a rule may be depicted as l → r if k is clear from the context (the numbered nodes form the common gluing graph). an example of a rule is given in figure 3. the left-hand side of this rule consists of two nodes refine : 1 2 xyu 1 2 x yu −→ x,y∈i u∈i∗ figure 3: the graph transformation rule refine proc. gramot 2010 4 / 24 eceasst 1 and 2 and an edge from node 1 to node 2 that is labeled with a word xyu from some alphabet i∗ where x and y are symbols of i. the gluing graph consists of the two nodes 1 and 2; the right-hand side is obtained from the gluing graph by inserting a new node v and two new edges e1 and e2 where e1 points from node 1 to v and is labeled with x, and e2 points from v to node 2 and is labeled with yu. 2.4 rule application the application of a graph transformation rule to a graph g consists of replacing a match of the left-hand side in g by the right-hand side in such a way that the match of the gluing graph is kept. hence, the application of r = (l ⊇ k ⊆ r) to a graph g = (v,e,s,t,l) consists of the following three steps. 1. a match g(l) of l in g is chosen. 2. now the nodes of gv (vl −vk) are removed, and the edges of ge (el − ek) as well as the edges incident to removed nodes are removed yielding the intermediate graph z ⊆ g. 3. afterwards the right-hand side r is added to z by gluing z with r in g(k) yielding the graph h = z ⊎(r − k) with vh = vz ⊎(vr −vk) and eh = ez ⊎(er − ek). the edges of z keep their labels, sources, and targets so that z ⊆ h. the edges of r keep their labels; they also keep their sources and targets provided that those belong to vr −vk. otherwise, sh(e) = g(sr(e)) for e ∈ er − ek with sr(e) ∈ vk, and th(e) = g(tr(e)) for e ∈ er − ek with tr(e) ∈ vk. the application of a rule r to a graph g is denoted by g =⇒ r h , where h is the graph resulting from the application of r to g. a rule application is called a direct derivation. if the rule refine in figure 3 is applied to a finite state graph, it splits a word transition labeled with a word w of length at least two into two consecutive transitions, the first of which takes the first symbol of w, while the second one gets labeled with the remainder of w. in particular, if refine is applied as long as possible to the finite state graph in figure 1, one gets the finite state graph in figure 2. 2.5 further basic types in addition to graph rule bases, we assume a set of identifiers id, the set of truth values bool = {true,false}, and the set of non-negative numbers n. all these sets are equipped with the usual predicates and operations, i.e. the arithmetic operations like +,−,·,≤,=, etc. for n, the boolean operations like ∧,∨,¬,→, etc. for bool, and the equality predicate = for id. all involved sets may be subject to the following three constructions that yield sets again: 1. the cartesian product x1 ×···× xk for sets x1,...,xk,k ∈ n; 2. the free monoid x ∗ for a set x ; 3. the powerset set(x) for a set x that contains all subsets of x . 5 / 24 volume 30 (2010) stepping from graph transformation units to model transformation units furthermore we assume that the usual operations of these data types are available, like the projections in the case of the product, concatenation and other string-processing operations in the case of x ∗ and the usual operations and predicates on sets like ∪,∩,∈,⊆, etc. 3 models and model types many models used in computer science are of a graphical, diagrammatic, and visual nature, and they can be represented as graphs in an adequate way in most cases. moreover, further types of elementary models such as numbers, truth values, or identifiers may be useful in addition to graphs. and models may not occur only as singular items, but also as tuples or as some other collections of models like sequences and sets. to cover this, we define models and their types in a recursive way. definition 1 (models and their types) models together with their types are recursively defined as follows: 1. let y be a class of graphs g , id, bool, or n. then each y ∈ y is a model of type y . 2. if mi is a model of type ti for i = 1,...,k for some k ∈ n, then the k-tuple (m1,...,mk) is a model of type t1 ×···× tk. 3. if mi is a model of type t for i = 1,...,k for some k ∈ n, then the sequence m1 ··· mk is a model of type t ∗. 4. if m is a set of models of type t , then m is a model of type set(t ). note that in this way every model gets a type which is a set of models, but can serve as a name on the syntactic level as well. to stress the semantic level we may write m(t ) for t . point 1 makes sure that all graphs and – in this way – all diagrams with graph representations are models. besides graphs, truth values, numbers and identifiers become available as elementary models. point 2 allows one to consider a k−tuple of models as a model and makes k models simultaneously available in this way. point 3 and point 4 also make many models of the same type available at the same time. while point 3 provides them as a sequence, point 4 collects them as a set. the types of models as introduced above may be considered as free because they are based on the free constructions product, free monoid, and power set. but in many cases, it may not be reasonable to transform all models of a free type without any further restriction. for example, a chomsky grammar g = (n,t,p,s) is not just a quadruple of type set(id)× set(id)× set(id∗ × id∗)×id, but n, t and p should be finite, n and t should be disjoint, s should be a nonterminal, and a pair (u,v) ∈ p should consist of two strings of terminals and nonterminals rather than of arbitrary identifiers. to make such restrictions possible, we introduce constrained types. proc. gramot 2010 6 / 24 eceasst definition 2 (constrained model types) let t be a model type. 1. then x (t ) is a class of constraints if each x ∈ x (t ) specifies a set of models of type t , i.e. sem(x) ⊆ m(t ). 2. for x ∈ x (t ), 〈t with x〉 is called a constrained model type. the models of this type are the models of sem(x), denoted by m(〈t with x〉). the definition is used in a recursive way considering the free model types and the constrained model types both as model types. consequently, one can build types of the form 〈〈t with x〉 with y〉 with iterated constraints. 3.1 examples for constraints 1. for the model type g , constraints x with sem(x) ⊆ g are called graph class expressions in the framework of graph transformation units and are extensively used there to specify initial and terminal graphs. examples of graph class expressions are the following. (a) single graphs z ∈ g with sem(z) = {z} are useful as start graphs of graph grammars. (b) for g = gς with σ ⊆ id, a subset x ⊆ σ describes sem(x) = gx and may serve as terminal labels. (c) for g = gς and x ⊆ σ, the expression pointers(x) specifies all graphs in gς in which all edges labeled with some x ∈ x are pointers (cf. subsection 2.2). (d) for g = gς and x ⊆ σ, the expression one(x) specifies all graphs g in which for each x ∈ x there occurs exactly one x-labeled edge, i.e., |{e ∈ eg | lg(e) = x}| = 1 for each x ∈ x . 2. logical formulas are further typical examples for constraints. they may involve model variables and the usual predicates and operations of the basic and free types: (a) boolean operations in case of bool like ¬,∧,∨,→; (b) arithmetic operations and predicates on n like +, ·, mod, =, ≤; (c) string operations and predicates on x ∗ for some set x , like concatenation, transposition, equality; (d) set operations and predicates like ∪, ∩, ⊎, =, ⊆, ∈. consider, for example, a model (x,y,x,y,m,n,u,v,g,h) of type id × id × set(id) × set(id) × n × n × id∗ × id∗ × gς × gς. then one may add the following constraints: x = y, x ∈ x , y ∈ y , x ∩y = /0, m ≤ n, length(u) ≥ n, uv 6= vu, u = vtranspos(v), g ⊆ h , g ∈ gx , where length measures the length of a word u and returns an integer, and transpos reverses the sequence of symbols in a word. clearly, all the constraints may be combined by boolean operations. 7 / 24 volume 30 (2010) stepping from graph transformation units to model transformation units 3. another frequently used constraint for graphs and sets is the requirement of finiteness indicated by the constant model class expression finiteness. instead of 〈gς with finiteness〉 we may write fin(gς), and finset(id) instead of 〈set(id) with finiteness〉. 3.2 examples for constrained model types 1. finite state automata with word transitions can be defined as a constrained model type, i.e. a finite state automaton fsa = (i,g) is a pair of type 〈set(id) × gς with (∆ ⊆ σ) ∧ (g ∈ (∆ ∩ pointers({start,final})∩ one({start})))〉 where ∆ = i∗ ⊎{start,final}. the constraint means that every state graph g is labelled over i∗ ⊎{start,final}, finaland start-edges are pointers, and there is exactly one start-pointer. in the following, the constrained model type of finite state automata with word transitions is denoted by fsa∗. the type of finite state automata the transitions of which are labelled only with single symbols from i, can be defined as the finite state automata in fsa∗, but where in the constraint i∗ is replaced by i, i.e., ∆ = i ⊎ {start,final}. the type of all finite state automata with single-symbol transitions is denoted by fsa. 2. chomsky grammars can be introduced in the framework above as models nearly in the same way as they are defined in the literature. a chomsky grammar g = (n,t,p,s) is a quadruple of type set(id)× set(id)× set(id∗ × id∗)× id with finite n, t and p, n ∩ t = /0, s ∈ n, and (u,v) ∈ p implies u,v ∈ (n ∪ t )∗ and u /∈ t ∗. g is right-linear if, in addition, (u,v) ∈ p implies u ∈ n and v ∈ (t +n)∪{ε} where ε denotes the empty string. more formally, the constraint of an arbitrary chomsky grammar is with n,t,p ∈ finset(id) ∧n ∩ t = /0∧ s ∈ n ∧((u,v) ∈ p → (u,v ∈ (n ∪ t )∗ ∧ u 6∈ t ∗)). and in case of right-linear grammars one must add ((u,v) ∈ p → (u ∈ n ∧ v ∈ t +n ∪{ε})). the type of right-linear grammars will be denoted by rlg. for explicit use below we mention here also the type rlg × gς which will be used for transforming right-linear grammars into finite state automata. 4 actions and model transformation processes in this section, the dynamic part of model transformations is introduced. the basic notion is that of an action that describes an elementary step of model transformations. then the iteration of such steps provides more complex transformations. it is worth noting that in this paper we do not explicitly consider infinite model transformations because the purpose of model transformation units is to convert input models into output models in finitely many steps. infinite processes are considered in [hkk09]. each model m can be identified with the 1-tuple (m) so that one may consider tuples of models only without loss of generality. given such a tuple (m1,...,mk), an action is also a k-tuple a = (a1,...,ak) of component operations where, for i = 1,...,k, ai specifies how mi is processed by the action. if mi is a graph, then ai is a rule to be applied to mi. if mi is an identifier or truth value, then ai may replace it by another identifier or the negated truth value respectively. if mi proc. gramot 2010 8 / 24 eceasst is a number, string or set, then ai may operate on it yielding a modified number, string or set respectively. moreover, we employ the void action ai = − meaning that mi remains unchanged. if the component actions are performed, then a new tuple (m′1,...,m ′ k ) of models is obtained. this is made precise in the following definition. definition 3 (actions) let t1 ×···× tk be a model type. 1. then an action a = (a1,...,ak) is a k-tuple such that one of the following holds for i = 1,...,k: (a) ai = −, (b) ai ∈ r provided that ti ⊆ g , (c) ai = rename provided that ti ⊆ id where rename is some mapping on ti, (d) ai is a term of operations with a distinguished variable of type n and which evaluates to n provided that ti = n. (e) the same as (d) replacing n by bool, t ∗ and set(t ) for some type t , (f) recursively, ai is an action provided that ti is a product type with more than one component. 2. let m = (m1,...,mk) ∈ m(t1 × ··· × tk). then the action (a1,...,ak) may be performed on m yielding m′ = (m′1,...,m ′ k ) ∈ m(t1 ×···× tk) denoted by m =⇒ a m′ if the following holds for i = 1,...,k: (a) m′i = mi if ai = −; (b) mi =⇒ ai m′i if ai ∈ r; (c) m′i = ai(mi) if ai = rename or ai is a term as described in 1.(d) or (e). (d) mi =⇒ ai m′i if ai is an action. 3. let a be a set of actions. then a model transformation process is a sequence of performed actions m = m0 =⇒ a1 m1 =⇒ a2 ···=⇒ an mn = m ′ with the action sequence a1 ··· an ∈ a ∗. such a process may be denoted by m n =⇒ a m′ or m ∗ =⇒ a m′ if the omitted details do not matter. the set of model transformation processes over a is denoted by mtp(a). 4.1 examples for actions let (n,t,p,s,g) be an arbitrary model of type rlg ×gς as defined in point 2 of subsection 3.2. 1. an action that removes a nonterminal symbol x from the first component of the rightlinear grammar (n,t,p,s) and then inserts a state labeled with x in the graph component can be defined as (remove(x),−,−,−,node(x)), where remove(x) removes x from n (if x ∈ n) and node(x) is the graph transformation rule depicted in figure 4. if n does not contain x the action cannot be executed. 9 / 24 volume 30 (2010) stepping from graph transformation units to model transformation units node(x): /0 x −→ figure 4: graph transformation rule node(x) edge(x,u,y ): 1 2 x y 1 2 x y u −→ figure 5: graph transformation rule edge(x,u,y ) 2. an action that removes a rule with a non-empty right-hand side from the right-linear grammar while inserting a corresponding transition in the graph that contains a state for every nonterminal of the rule can be defined as (−,−,remove((x,uy )),−,edge(x,u,y )); the graph transformation rule edge(x,u,y ) is given in figure 5. model transformation processes are nondeterministic in three respects. first, the rule applications in graph model components are nondeterministic as some rules may be applicable at several matches. second, although the operations of the basic types are functional, the evaluations of the action terms of these types may not lead to unique values as the terms can contain free variables with a variety of instantiations. third, there may be a choice of many actions that can process a current model, and the only regulating requirement for actions is that of sequential composition, which is that one action is executed after the other. sometimes such nondeterminism is desired, convenient, or unavoidable. but in other cases one would like to avoid nondeterminism, or cut it down at least. this can be achieved by choosing rules and actions in such a way that only one or a few of them can be applied and performed. but the rules and actions may become quite complicated. another possibility is extra regulation which can be provided by control conditions. definition 4 (control conditions) let a be a set of actions. then c is a class of control conditions if sem(c) ⊆ mtp(a) for every c ∈ c . 4.2 examples for control conditions in the area of graph transformation, control conditions are frequently expressions over rules. many of these kinds of control conditions can be generalized by replacing rules with actions. 1. a typical kind of control conditions are regular expressions over a. each regular expression r specifies a regular language l(r). a model transformation process m ∗ =⇒ a m′ belongs to sem(r) if and only if its action sequence belongs to l(r). in the following, the operators concatenation, union, and kleene star on languages will be denoted on the level of regular expressions as a semicolon, a vertical bar and a star, respectively. 2. another kind of control condition is a priority given by a partial reflexive and transitive relation ≤ on a where a ≥ a′, but a′ 6≥ a means that a has higher priority than a′. a proc. gramot 2010 10 / 24 eceasst model transformation process belongs to sem(≤) if and only if each performed action mi−1 =⇒ ai mi has highest priority meaning that there is no mi−1 =⇒ a m with a ≥ ai but ai 6≥ a. 3. for any action a, the control condition a! requires to apply a as long as possible. hence, m ∗ =⇒ a m′ is in sem(a!) if the application sequence is in {a}∗ and there is no m′′ such that m′ =⇒ a m′′. (due to the fact that model transformation processes are finite, this means that sem(a!) = /0 if a can be applied infinitely often to any model m.) this condition can be combined with regular expressions in a straightforward way. for example, the expression a1!; a2! requires to apply first a1 as long as possible and then a2 as long as possible. 5 model transformation units the previous sections provide all the ingredients that are needed to introduce model transformation units as devices to specify model transformations. such a unit consists of the type of models to be transformed, of the actions to be performed, and of the control condition that regulates the transformation process. moreover, the types of input and output models are specified, including their relation to the type of working models. the reasons to separate input, output and working models is that input and output may have different types and that it may be convenient to use further component models for intermediate processing. in other words, an input model m of type 〈i1 ×···× ik with x〉 (i.e. a model of type i1 ×···× ik that satisfies the constraint x) is first of all extended to a working model m of type t1 ×···× tl by taking the components of m as components of m according to a mapping initial. this mapping yields for each component of m the positions in m (i.e. the numbers out of 1,...,l) where the component should be used. clearly, each position in m may be associated in this way with with at most one component of the input type. the components of the working model not covered by initial are initialized by the initial models of the respective component types. initial models are chosen in some appropriate way, like 0 for tj = n, etc. then m is transformed into m ′ by performing the given actions such that the control condition is satisfied. afterwards an output model m′ of type 〈o1 × ··· × on with y〉 is constructed according to a mapping terminal. this mapping selects for every position in m′ (i.e. for every number out of 1,...,n) a component of m′. moreover, it must be assured that the obtained model m′ satisfies the constraint y. definition 5 (model transformation unit) 1. a model transformation unit is a system mtu = (itd,otd,wt,a,c) where − wt is a product type t1 ×···× tl called working type, − itd is the input type declaration which consists of the constrained product type 〈i1 × ··· × ik with x〉 and a mapping initial : [k] → set[l] such that initial(i)∩ initial( j) = /0 for i 6= j and ii = tj for i = 1,...,k and j ∈ initial(i), − otd is the output type declaration which consists of a constrained product type 〈o1 ×···×on with y〉 and an injective mapping terminal : [n] → [l] with oi = tterminal(i) for i = 1,...,n, 11 / 24 volume 30 (2010) stepping from graph transformation units to model transformation units − a is the set of actions with respect to the working type and − c is the control condition. the type i = 〈i1 ×···× ik with x〉 is called input type of mtu and the mapping initial initialization. the type o = 〈o1 ×···× on with y〉 is called output type of mtu and the mapping terminal terminalization. 2. the model transformation modeled by the model transformation unit mtu is a mapping sem(mtu): m(〈i1 ×··· × ik with x〉) → set(m(〈o1 ×··· × on with y〉)) which is defined by m′ = (m′1,...,m ′ n) ∈ sem(mtu)(m1,...,mk) for every m = (m1,...,mk) ∈ m(〈i1 ×···× ik with x〉) if and only if the following holds: there are working models m = (m1,...,ml), m ′ = (m′1,...,m ′ l ) ∈ m(t1 × ··· × tl) such that (a) m j = { mi for i = 1,...,k and j ∈ initial(i) init(tj) for j 6∈ initial([k]) = ⋃ i∈[k] initial(i) , (b) m ∗ =⇒ a m′ ∈ sem(c), (c) m′i = m ′ j for i = 1,...,n and terminal(i) = j, (d) m′ ∈ sem(y). the initial model init(tj) in (a) may be chosen in some appropriate way, like 0 for tj = n, the empty string ε for tj = t ∗, the empty set /0 for tj = set(t ) or false for tj = bool. in examples, initial will be represented in the form i 7→ j1,..., jp if initial(i) = { j1,..., jp} and terminal in the form i 7→ j for terminal(i) = j. remark given a model transformation unit mtu with input type i = 〈i1 ×··· × ik with x〉 and output type o = 〈o1 ×···× on with y〉, mtu can be graphically represented by mtu i o emphasizing that mtu specifies a transformation of input models into output models. 5.1 examples for model transformation units a model transformation unit that transforms right-linear chomsky grammars into finite state automata is given in figure 6. the components of this model transformation unit rlg2fsa∗ are the following: proc. gramot 2010 12 / 24 eceasst rlg2fsa∗ input: rlg & 1 7→ 1,2 7→ 2,3 7→ 3,4 7→ 4 add: 5 : gς & init(5) = /0 for σ = (n ∪ t ) ∗ ⊎{start,final} actions: a1 = (remove(x),−,−,−,node(x)) for x ∈ n a2 = (−,−,remove((x,ε)),−,final(x)) for x ∈ n a3 = (−,−,remove((x,uy )),−,edge(x,uy )) for x,y ∈ n,u ∈ t + a4 = (−,−,−,−,start(s)) a5 = (−,−,−,−,remove loop(x)) for x ∈ n cond: a1!; a2!; a3!; a4; a5! output: fsa∗ & 1 7→ 2,2 7→ 5 figure 6: the model transformation unit rlg2fsa∗ transforms right-linear chomsky grammars (rlg) into finite state automata with word transitions (fsa∗) − a model of the working type is a quintuple where the first four components of the working type correspond to the four types of a right-linear grammar; the last component is equal to gς and serves to build up the finite state graph. it is initialized with the empty graph /0. the alphabet σ must equal (n ∪ t )∗ ⊎{start,final} where n are the nonterminal symbols and t the terminal symbols of the input grammar, and start and final will serve to label the start and final states of the finite state graph respectively. − the input type declaration is composed of the constrained model type for right-linear grammars and the initialization initial : [4] → set([5]) with initial(i) = {i} for i = 1,...,4. this means that the four components of the input type are the first four components of the working type. hence, the four components of every input model are used as the first four components in the model the model transformation unit starts working with. − the output type declaration consists of the constrained model type fsa∗ and the terminalization terminal with terminal(1) = 2 and terminal(2) = 5. hence, every output model of the unit is the pair consisting of the second and the last component of the model the unit ends working with, provided that the type of this pair equals fsa∗. − the set of actions of rlg2fsa∗ consists of five kinds of actions, each of which contains among other operations one of the graph transformation rules depicted in figures 4, 5 and 7. 1. the first action a1 = (remove(x),−,−,−,node(x)) serves to generate a state in the graph for each nonterminal of the input grammar. more concretely, every application of this action generates a state with name x while removing the nonterminal x from the set of nonterminals. 2. the second action a2 = (−,−,remove((x,ε)),−,final(x)) inserts final pointers at all final states of the graph, while removing the corresponding rules from the grammar. 13 / 24 volume 30 (2010) stepping from graph transformation units to model transformation units start(s): s s start −→ final(x): x x final −→ remove − loop(x): x −→ figure 7: graph transformation rules for the actions of model transformation unit rlg2fsa∗ 3. the third action a3 = (−,−,remove((x,uy )),−,edge(x,u,y )) serves to generate transitions from those rules of the grammar that have a nonterminal in their righthand side. every application of a3 removes such a rule from the rule set in the third component at the same time that a corresponding transition in the graph is generated. 4. action a4 = (−,−,−,, start(s)) inserts the start pointer at the state s if s is the start symbol of the grammar. 5. finally, the last action a5 = (−,−,−,−,remove loop(x)) for x ∈ n serves to remove all state names in order to obtain a finite state graph. − the control condition a1!; a2!; a3!; a4; a5! requires that at first all states be generated. this is achieved by applying a1 as long as possible. the application of a2 as long as possible inserts for every rule with the empty word as right-hand side a final-pointer while removing this rule. then a3 requires to insert a transition for every remaining rule. then the start state is inserted by a4 and afterwards all state names are removed by applying a5 as long as possible. fsa∗2fsa input: fsa∗ & 1 7→ 1,2 7→ 2 actions: a = (−,refine) cond: a! output: fsa & 1 7→ 2,2 7→ 2 figure 8: the model transformation unit fsa∗2fsa transforms finite state automata with word transitions (fsa∗) into finite state automata (fsa) if the input model of rlg2fsa∗ is the right-linear grammar ({s,a},{a,b,c},p,s) with p = {(s,asa),(s,aa),(s,bbs),(a,ccca),(a,ε)}, the output model is ({a,b,c},g) where g is the finite state graph with word transitions in figure 1. proc. gramot 2010 14 / 24 eceasst finite state graphs with word transitions can be transformed into finite state graphs with symbol transitions by the model transformation unit fsa∗2fsa given in figure 8. the input type declaration consists of the constrained model type fsa∗ of finite state automata with word transitions and the initialization initial that maps the two components of every input model to the first two components of the working type. the working type of the unit is equal to set(id)× gς; the output type declaration consists of the model type fsa for finite state automata and the terminalization terminal, which is the identity in this case. the only action a applies the rule refine of figure 3 to the graph component of the current model, while the control condition requires to apply the action a as long as possible. if the input model of fsa∗2fsa is equal to the state automaton ({a,b,c},g) where g is the finite state graph of figure 1, the output is equal to ({a,b,c},g′) where g′ is the finite state graph in figure 2. 6 sequential and parallel composition model transformation units can be used as building blocks for more complex model transformation constructions obtained by sequential and parallel composition. this leads to the notion of model transformation expressions on the syntactic level. semantically, the sequential composition of model transformations is just the usual one of relations. and the parallel composition uses the fact that all models are considered as tuples of some product types so that the product of such types yields again models of some product type. definition 6 (compositional expressions) 1. the set cx of compositional expressions is defined recursively: (a) model transformation units are in cx , (b) cx1,...,cxk ∈ cx implies cx1;... ; cxk ∈ cx (sequential composition), (c) cx1,...,cxk ∈ cx implies cx1 ‖ ... ‖ cxk ∈ cx (parallel composition). 2. the semantic relation of a compositional expression cx ∈ cx is defined according to its syntactic structure: (a) if cx = mtu for some model transformation unit, then sem(cx) = sem(mtu). (b) if cx1;... ; cxk for some model transformation units cxi with i = 1,...,k , then sem(cx1; ... ; cxk) = sem(cx1)◦... ◦ sem(cxk)where sem(cxi)◦ sem(cxi+1)(m) = ⋃ m′∈sem(cxi) sem(cxi+1)(m ′) for each i ∈ {1,...,k − 1} and each m in the domain of sem(cxi). (c) (m′1,...,m ′ k ) ∈ sem(cx1 ‖ ... ‖ cxk)(m1,...,mk) if and only if m ′ i ∈ sem(cxi)(mi) for i = 1,...,k. 15 / 24 volume 30 (2010) stepping from graph transformation units to model transformation units 6.1 examples the sequential composition rlg2fsa∗; fsa∗2fsa of the model transformation units in section 5 transforms right-linear grammars into finite state automata so that the language generated by the input grammar is recognized by the automaton. the formal language theory offers many examples of sequential compositions of model transformations like the transformation of right-linear grammars into finite state automata followed by their transformation into deterministic automata followed by the transformation of the latter into minimal automata. a typical example of a parallel composition is given by the acception processes of two finite state automata that run simultaneously. if they try to accept the same input strings, this parallel composition simulates the product automaton that accepts the intersection of the two accepted regular languages. to make the definition of compositional expressions more transparent, one may assign an input type and an output type to each compositional expression. then the relational semantics of an expression turns out to be a relation between input and output types. definition 7 (input and output types) the input type in and the output type out of a compositional expression cx ∈ cx is recursively defined. 1. if cx = mtu for some model transformation unit with input type i and output type o, then in(mtu) = i, out(mtu) = o, 2. if cx = cx1;... ; cxk for some model transformation units cxi with i = 1,...,k, then in(cx1;... ; cxk) = in(cx1) and out(cx1;... ; cxk) = out(cxk), 3. if cx = cx1 ‖ ... ‖ cxk for some model transformation units cxi with i = 1,...,k, then in(cx1 ‖ ... ‖ cxk) = in(cx1) ‖ ... ‖ in(cxk) and out(cx1 ‖ ... ‖ cxk) = out(cx1) ‖ ... ‖ out(cxk), where the parallel composition of model types is defined as follows (a) (t ‖ t ′) = (t × t ′) provided that t and t ′ are free, (b) t ‖ (〈t ′ with x′〉) = 〈(t ‖ t ′) with x′〉 provided that t is free, (c) (〈t with x〉) ‖ t ′ = 〈(t ‖ t ′) with x〉 provided that t ′ is free, and (d) (〈t with x〉) ‖ (〈t ′ with x′〉) = 〈t ‖ t ′ with x ∧ x′〉, due to these definitions, it is easy to see that compositional expressions describe transformations from input models to output models. observation sem(cx)(m) ∈ set(m(out(cx))) for all m ∈ m(in(cx)). the compositions can be quite intuitively depicted: proc. gramot 2010 16 / 24 eceasst tr1 i1 o1 tr2 i2 o2 tr1; tr2 i1 ‖ i2 tr1 i1 tr2 i2 o1 o2 o1 ‖ o2 tr1 ‖ tr2 the sequential and parallel compositions on the level of model transformation expressions have the disadvantage that their results cannot be subject to further constraints. this is particularly problematic with respect to the parallel composition because the composed units run in parallel, but without any interaction. this is quite all right provided that the components are meant to run independently of each other. but in many cases of parallel composition one intends that the components exchange information or process some data simultaneously. such interrelations and interactions could be achieved by adding further constraints and control conditions. this requires either to extend the notion of constraints and control conditions to the level of model transformation expressions or to flatten such expressions into model transformation units. the latter is done in the following. 6.2 sequential composition let mtui = (itdi,otdi,wt i,ai,ci) for i = 1,2 be two model transformation units with input types ii = 〈ii,1 × ··· × ii,ki with xi〉 and output types oi = 〈oi,1 × ··· × oi,ni with yi〉. by definition of the semantics of the sequential composition mtu1; mtu2, the following holds: m ′′ = (m′′1,...,m ′′ n2 ) ∈ sem(mtu1; mtu2)(m) for m = (m1,...,mk1) ∈ m(i1) if and only if there is an m′ with m′ ∈ sem(mtu1)(m) and m ′′ ∈ sem(mtu2)(m ′). this means in particular that m′ ∈ m(o1)∩m(i2) and therefore n1 = k2. to avoid too much technical trouble, we assume in addition that wt = wt 1 = o1 × ···× on1 = i1 × ··· × ik2 = wt 2. then the sequential composition of mtu1 and mtu2 can be simulated by the model transformation unit mtu(mtu1; mtu2) = (itd1,otd2,wt,a1 ∪ a2,c(c1,c2,y1,x2,a1,a2)) where the control condition is chosen in such a way that a model transformation process m ∗ =⇒ a1∪a2 m′′ is accepted if and only if it decomposes into m ∗ =⇒ a1 m′ ∗ =⇒ a2 m′′ with the following properties: 17 / 24 volume 30 (2010) stepping from graph transformation units to model transformation units 1. m ∗ =⇒ a1 m′ is accepted by c1, 2. m′ ∈ sem(y1)∩ sem(x2), 3. m′ ∗ =⇒ a2 m′′ is accepted by c2. such a control condition may have the form of a transition system: s0 s1 s2 s3 a∗1,c1 −,y1 ∧ x1 a ∗ 2,c2 requiring that at the beginning the actions of a1 are iterated regarding c1, that the result must obey y1 and x2 and that finally actions of a2 are iterated regarding c2. it is not difficult to show that the following correctness result holds. observation sem(mtu1; mtu2) = sem(mtu(mtu1; mtu2)). 6.3 parallel composition let mtui = (itdi,otdi,wt i,ai,ci) for i = 1,2 be two model transformation units each with input type ii = 〈ii,1 ×···× ii,ki with xi〉 and initialization initiali : [ki] −→ set[li] as well as output type oi = 〈oi,1 ×···× oi,ni with yi〉 and terminalization terminal : [ni] −→ [li]. then the parallel composition of mtu1 and mtu2 can be simulated by the model transformation unit mtu(mtu1 ‖ mtu2) = (itd,otd,wt 1 × wt 2,a,c) where − itd consists of the input type i1 ‖ i2 and the initialization initiali : [k1 + k2] −→ set[l1 + l2] with initial(i) = initial1(i) for i ∈ [k1] and initial(i) = l1 + initial2(i − k1) for i = k1 + 1,...,k1 + k2, − otd consists of the output type o1 ‖ o2 and the terminalization terminal : [n1 + n2] −→ [l1 + l2] with terminal(i) = terminal1(i) for i ∈ [n1] and terminal(i) = l1 + terminal2(i− n1) for i = n1 + 1,...,n1 + n2, − a = a1 ′ × a2 ′ with a1 ′ = a1 ∪{−} l1 and a2 ′ = a2 ∪{−} l2 , and − the control condition c is chosen in such a way that a model transformation process (m1,m2) ∗ =⇒ a (m1 ′,m2 ′) is accepted if and only if it decomposes into m1 ∗ =⇒ a1 ′ m1 ′ and m2 ∗ =⇒ a2 ′ m2 ′ so that the former is accepted by c1 and the latter by c2 after removal of the void steps given by the performance of the void actions (−,...,−). proc. gramot 2010 18 / 24 eceasst the construction relies on the cartesian product of types and actions. because the working type components 1 to l2 become the components l1 + 1 to l1 + l2, the initialization and terminalization must be adapted accordingly. the actions of mtu1 and mtu2 are extended by the void action (−,...,−) with l1 and l2 components respectively. this is necessary because the actions of mtu1 and mtu2 may run in parallel, but the model transformation processes are of different lengths in general so that they cannot run fully simultaneously. it is again not difficult to show the following correctness result. observation sem(mtu1 ‖ mtu2) = sem(mtu(mtu1 ‖ mtu2)). 7 related work in this section we briefly describe a selection of related work concerning model transformation. since there exists quite an amount of publications we restrict ourselves to papers that are concerned with model transformations in the context of graph transformation. moreover, we also mention some work that is concerned with the composition of model transformation definitions. model transformations based on graph transformation. one approach to define model transformations is by triple grammars [sch94, ks06, sk08]. each rule of a triple grammar can be easily transformed into a forward rule, a source rule, and a backward rule. the source rules are used to generate source models that – represented as graph triples – have the form (s, /0, /0) where s represents the source model. the forward rules are used to produce target models from source models. these target models – represented as graph triples – have the form (s,c,t ) where t is the target model. the backward rules are used to transform a target model (/0, /0,t ) to a source model (s,c,t ). in [eee+07], it is shown that any source consistent model transformation based on triple grammars is backward information preserving. this means that the target model (generated by the forward rules of the grammar) can be transformed into the source model via the backward rules of the grammar. roughly spoken, a model transformation mt is source consistent if there is a transformation that generates the source model from (/0, /0, /0) and that completely determines the matches in the source model of the forward rules applied in mt. in [ee08], models are graphs equipped with a semantics given as a set of simulation rules, and a model transformation is composed of generating first an integrated model by graph transformation rules and restricting it then to the target model. it is shown under which conditions semantical correctness and completeness of model transformations are achieved. in [küs06], an approach to model transformation is presented that uses transformation units based on typed attributed graph transformation. it provides criteria for syntactic correctness as well as for termination and confluence. examples of model transformation tools based on graph transformation are viatra2 [vb07], great [bnvbk06] and atom3 [dlva04]. viatra2 integrates graph transformation and abstract state machines. basically, model transformation steps are captured by graph transformation rules whereas abstract state machines control the order of rule application. great mainly consists of a pattern specification language, a transformation rule language and a control flow language. the graph transformation rules of great include for example input and output in19 / 24 volume 30 (2010) stepping from graph transformation units to model transformation units terfaces where the former can receive graph objects from previous rules and the latter can send graph objects to another rule. atom3 focuses on modeling complex systems composed of various formalisms and allows to transform them into a single common formalism based on graph transformation. in [dlt04], atom3 is combined with agg for validation purposes. in general, the mentioned publications on model transformation with graph transformation are very close to our approach – they are however restricted to transform mainly graphs, not tuples of graphs, sets or sequences as proposed in this paper. composition of model transformations. in the literature one can find two main types of composition techniques for model transformation definitions: external and internal composition. the first one chains model transformations sequentially whereas the second composes the rules of a set of model transformation definitions into one transformation definition. in this sense the compositions presented in subsections 6.2 and 6.3 can be considered as internal compositions. in [wag08], the composition of model transformation definitions via superimposition is described, which is a feature of the atlas transformation language [jk05]. superimposition of modules is an internal composition technique where models can be superimposed on top of each other yielding a module that contains the union of all transformation rules. in [ycwd09], the authors consider composition of model transformation definitions that transform high-level models into low-level models by defining a correspondence model that specifies the relations between the high-level meta models. the low-level correspondence model is automatically generated so that the low-level models can be composed homogeneously. in this way, new concerns can be added to existing model transformation definitions. in [cm08], two approaches for reusing model transformation definitions are proposed. the first one is called factorization and it allows to extract common parts of model transformation definitions obtaining in this way a base transformation definition which can be reused. the second concerns composition of transformation definitions which have compatible source metamodels but different target metamodels. metamodels are related via small new metamodels and the transformations are integrated via an integration transformation definition that locates and connects the join points (without knowing the rules but some kind of trace information) by using so-called refinement rules. one approach towards composition of model transformations based on graph transformation is studied in [bhe09] where models are typed graphs that are mapped to semantic domains. the authors define spatial compositionality of semantic mappings which roughly spoken means that the semantics of a model is equal to the semantics that is obtained by embedding the semantics of a piece of the model into some context. it is assumed that the semantic mappings are graph transformation systems with a functional behavior and it is shown under which conditions they behave compositionally. in [kks07], a first approach towards structured model transformation is proposed that allows package import, package merge and generalization according to a standardized packaging concept of the uml. in particular, the authors extend triple graph grammars by the mentioned concepts. 8 conclusion in this paper, we have introduced the notion of model transformation units as a generalization of graph transformation units. models are tuples of graphs and other data structures like strings, proc. gramot 2010 20 / 24 eceasst sets, numbers, etc. models of this kind cover graphical models like uml diagrams as well as set-theoretic models like grammars and automata. they are transformed componentwise by rule applications in the cases of graphs and by applications of data type operations in the other cases. besides a set of such actions, a model transformation unit provides descriptions of input, output, and working models as well as a control condition to regulate the use of actions. semantically, a transformation of input models into output models is specified. moreover, we have studied sequential and parallel compositions of model transformation units as means to build up complex transformations from simple ones. although the considerations in this paper seem to be promising, more work is needed to underpin the significance of this novel approach, including the following points. 1. as pointed out in section 4, the introduced kind of model transformation is nondeterministic. therefore, sufficient conditions are often of interest that guarantee termination, completeness and functionality where the first property means that there is no infinite run, the second one requires at least one output for each input, and the latter one requires at most one output for each input. 2. concerning our running example, it is known from the literature that a right-linear grammar generates the same language as is recognized by the finite state automaton resulting from the transformation. one intention of our approach is to support such correctness proofs. therefore, notions of correctness and an appropriate proof theory must be studied in the future. 3. an interesting question in this respect is whether and how these correctness notions are compatible with the sequential and parallel compositions so that the correctness of the components yields the correctness of the composed model transformation. 4. further explicit and detailed examples are needed to illustrate all introduced concepts more convincingly, in particular examples for parallel and sequential composition with interaction between components. acknowledgments we are grateful to the unknown referees for various helpful comments. the first author wants to thank hartmut ehrig for the long lasting cooperation and friendship. hans-jörg (being a math student at the time) met hartmut in 1970 when a very close relationship started. hartmut supervised hans-jörg’s diploma thesis in 1974 and his phd thesis in 1978. moreover, he guided hans-jörg to habilitation in 1981. hartmut introduced hans-jörg to category theory. they both learned automata theory together. hartmut convinced hans-jörg of the significance of graph transformation. they both together got involved in algebraic specification. although this happened in the 1970s, it sticks: elements of all four areas can be found in the present paper. hans-jörg happily acknowledges that he is one of hartmut’s grateful students. bibliography [bhe09] dénes bisztray, reiko heckel, and hartmut ehrig. compositionality of model transformations. electr. notes theor. comput. sci., 236:5–19, 2009. 21 / 24 volume 30 (2010) stepping from graph transformation units to model transformation units [bnvbk06] daniel balasubramanian, anantha narayanan, christopher p. van buskirk, and gabor karsai. the graph rewriting and transformation language: great. eceasst, 1, 2006. [chk04] björn cordes, karsten hölscher, and hans-jörg kreowski. uml interaction diagrams: correct translation of sequence diagrams into collaboration diagrams. in john l. pfaltz, manfred nagl, and boris böhlen, editors, applications of graph transformations with industrial relevance (agtive 2003), volume 3062 of lecture notes in computer science, pages 275–291, 2004. [cm08] jesús sánchez cuadrado and jesús garcı́a molina. approaches for model transformation reuse: factorization and composition. in vallecillo et al. [vgp08], pages 168–182. [dlt04] juan de lara and gabriele taentzer. automated model transformation and its validation using atom3 and agg. in alan f. blackwell, kim marriott, and atsushi shimojima, editors, diagrammatic representation and inference, volume 2980 of lecture notes in computer science, pages 182–198. springer, 2004. [dlva04] juan de lara, hans vangheluwe, and manuel alfonseca. meta-modelling and graph grammars for multi-paradigm modelling in atom3. software and system modeling, 3(3):194–209, 2004. [ee08] hartmut ehrig and claudia ermel. semantical correctness and completeness of model transformations using graph and rule transformation. in ehrig et al. [ehrt08], pages 194–210. [eee+07] hartmut ehrig, karsten ehrig, claudia ermel, frank hermann, and gabriele taentzer. information preserving bidirectional model transformations. in matthew b. dwyer and antónia lopes, editors, fase, volume 4422 of lecture notes in computer science, pages 72–86. springer, 2007. [ehrt08] hartmut ehrig, reiko heckel, grzegorz rozenberg, and gabriele taentzer, editors. graph transformations, 4th international conference, icgt 2008, leicester, united kingdom, september 7-13, 2008. proceedings, volume 5214 of lecture notes in computer science. springer, 2008. [fra03] david s. frankel. model driven architecture. applying mda to enterprise computing. wiley, indianapolis, indiana, 2003. [hkk09] karsten hölscher, hans-jörg kreowski, and sabine kuske. autonomous units to model interacting sequential and parallel processes. fundamenta informaticae, 92(3):233–257, 2009. [jk05] frédéric jouault and ivan kurtev. transforming models with atl. in jean-michel bruel, editor, satellite events at the models 2005 conference, volume 3844 of lecture notes in computer science, pages 128–138. springer, 2005. proc. gramot 2010 22 / 24 eceasst [khk06] hans-jörg kreowski, karsten hölscher, and peter knirsch. semantics of visual models in a rule-based setting. in r. heckel, editor, proceedings of the school of segravis research training network on foundations of visual modelling techniques (fovmt 2004), volume 148 of electronic notes in theoretical computer science, pages 75– 88. elsevier science, 2006. [kk99] hans-jörg kreowski and sabine kuske. graph transformation units with interleaving semantics. formal aspects of computing, 11(6):690–723, 1999. [kkr08] hans-jörg kreowski, sabine kuske, and grzegorz rozenberg. graph transformation units – an overview. in p. degano, r. de nicola, and j. meseguer, editors, concurrency, graphs and models, volume 5065 of lecture notes in computer science, pages 57–75. springer, 2008. [kks97] hans-jörg kreowski, sabine kuske, and andy schürr. nested graph transformation units. international journal on software engineering and knowledge engineering, 7(4):479–502, 1997. [kks07] felix klar, alexander königs, and andy schürr. model transformation in the large. in ivica crnkovic and antonia bertolino, editors, esec/sigsoft fse, pages 285– 294. acm, 2007. [ks06] alexander königs and andy schürr. tool integration with triple graph grammars a survey. electr. notes theor. comput. sci., 148(1):113–150, 2006. [küs06] jochen malte küster. definition and validation of model transformations. software and system modeling, 5(3):233–259, 2006. [omg08] omg. meta object facility (mof) 2.0 query/view/transformation (qvt). http://www.omg.org/spec/qvt/, 2008. [sch94] andy schürr. specification of graph translators with triple graph grammars. in ernst w. mayr, gunther schmidt, and gottfried tinhofer, editors, graph-theoretic concepts in computer science, volume 903 of lecture notes in computer science, pages 151–163. springer, 1994. [sk08] andy schürr and felix klar. 15 years of triple graph grammars. in ehrig et al. [ehrt08], pages 411–425. [vb07] dániel varró and andrás balogh. the model transformation language of the viatra2 framework. science of computer programming, 68(3):187–207, 2007. [vgp08] antonio vallecillo, jeff gray, and alfonso pierantonio, editors. theory and practice of model transformations, first international conference, icmt 2008, zürich, switzerland, july 1-2, 2008, proceedings, volume 5063 of lecture notes in computer science. springer, 2008. [wag08] dennis wagelaar. composition techniques for rule-based model transformation languages. in vallecillo et al. [vgp08], pages 152–167. 23 / 24 volume 30 (2010) stepping from graph transformation units to model transformation units [ycwd09] andrés yie, rubby casallas, dennis wagelaar, and dirk deridder. an approach for evolving transformation chains. in andy schürr and bran selic, editors, models, volume 5795 of lecture notes in computer science, pages 551–555. springer, 2009. proc. gramot 2010 24 / 24 introduction preliminaries graph rule bases graph classes rules rule application further basic types models and model types examples for constraints examples for constrained model types actions and model transformation processes examples for actions examples for control conditions model transformation units examples for model transformation units sequential and parallel composition examples sequential composition parallel composition related work conclusion static analysis of information release in interactive programs electronic communications of the easst volume 35 (2010) proceedings of the 10th international workshop on automated verification of critical systems (avocs 2010) static analysis of information release in interactive programs adedayo o. adetoye and nikolaos papanikolaou 15 pages guest editors: jens bendisposto, michael leuschel, markus roggenbach managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst static analysis of information release in interactive programs adedayo o. adetoye and nikolaos papanikolaou international digital laboratory, wmg, university of warwick, uk abstract: in this paper we present a model for analysing information release (or leakage) in programs written in a simple imperative language. we present the semantics of the language, an attacker model, and the notion of an information release policy. our key contribution is the static analysis technique to compute information release of programs and to verify it against a policy. we demonstrate our approach by analysing information released to an attacker by faulty password checking programs; our example is inspired by a known flaw in versions of openssh distributed with various unix, linux, and openbsd operating systems. keywords: secure information release, static analysis, program verification. 1 introduction it is often inevitable, during the course of program execution, for sensitive information to be leaked to the environment; in the presence of an attacker, such leakage — henceforth information release — can be catastrophic, or at the very least damaging, to the parties with whom the data is concerned. ensuring that information release is minimal is a critical requirement in a variety of applications; this is true, for instance, with authentication, encryption and statistical analysis software. general purpose applications infected by malicious code, or malware, may seek to release much more information than expected by the user; this is also the case with trojan horses (think of a tax-return calculator that releases private financial information to an unauthorised observer). what the user generally expects in these applications is that the amount of information release does not exceed what is absolutely necessary for normal operation. therefore it is highly necessary to have means of controlling the information released by a program, while taking into account its purpose and functionality, namely, how it transforms its inputs to publicly observable output. the problem we are then concerned with is how to check whether the program does not release more than is specified. in other words, we seek a way of checking that a given program conforms to an information release policy. in this paper we present static analysis techniques to measure the information released by a program, both qualitatively and quantitatively (using information theory), and develop a policy model whereby users’ information release requirements may be specified. the intention is that, by comparing the information actually released by the program with a specification of its expected information release, as stated in a policy, we can judge whether the program has secure information flow and reject insecure implementations. we demonstrate our approach by investigating attacks on password-checking programs, where timing delays can give clues to potential attackers about the validity of user log-in names and passwords. the examples are inspired by password checking programs used in different versions of openssh on various unix, linux, and openbsd operating system. 1 / 15 volume 35 (2010) static analysis of information release in interactive programs contributions. in this paper we present a general static analysis technique, parametrised by attacker models, for the verification of secure information flow in interactive programs. this includes a concrete static analysis technique for while programs under a “standard attacker” model, which can observe program outputs as prescribed by the standard operational semantics. our analysis is both flow-sensitive and termination-sensitive, accounting for sequencing of programs as well as correctly dealing with information release in the face of program divergence. we present a qualitative policy framework, whereby users may enforce secure information release requirements on programs. we also demonstrate how the qualitative policies can be described quantitatively, with examples. we show a limitation of the quantitative technique. the overall architecture and framework is described in section 2, while the static analysis of information release for arbitrary while programs is presented in section 3. information release policies are described in section 4. we illustrate our analysis and enforcement technique by considering examples which exploit design, implementation and configuration flaws in password authentication programs in section 5. the examples are motivated by flaws in version of the openssh authentication module. section 6 shows how the qualitative per-based policies of section 4 may also be expressed quantitatively using information theory. section 7 concludes and looks at areas of future work. related work. this paper describes a technique for the analysis of secure information release in computer programs, which is an established field [10]. this paper extends our earlier work [2], on the lattice-based formulation of secure information flow under various attacker models, with a concrete static analysis methodology. we are evaluating ways of efficiently implementing the proposed technique, which may benefit from minimal model generation results of [3]. in [1] a theorem-proving approach is presented that deals with noninterference properties of programs. the implementation for real languages is still further away, but we envisage applying the technique in the context of low-level code such as assembly or virtual machine languages [8, 14, 4]. 2 analysis and enforcement framework our approach forms the basis of a framework for analysing the security of programs. in particular, we envisage the technique of static analysis described in this paper as being implemented in a software tool, possibly a kernel module for various operating systems, which computes the information release of programs during installation or prior to that in a proof-carrying code setting [9]. a user would supply (or be supplied with, by a trusted source) an information release policy to this tool, and if a program fails to satisfy the requirement of the policy, its execution would be prevented and the user warned. we have so far developed the theory of information release for programs expressed in a simple, but typical, imperative language. the static analysis rules described in this paper could be adapted to different languages and generalised to account for different types of attacker. as part of a long-term research programme, we will be targeting the analysis of low-level code for system software and applications running on mobile devices. the analysis technique we are proposing would be used in a system architecture comprising: a set of users , programs assumed to be potentially hostile (until verified otherwise), an execution proc. avocs 2010 2 / 15 eceasst environment, a set of information release policies, a static analyser. users are assumed to have legitimate uses for the programs in the system. the environment in which programs are executed is assumed to include attackers, potentially waiting locally or on other networks for the program to disclose confidential or sensitive information to them. that is, we consider the malicious code scenario, where the program may contain spyware or design or implementation flaws that can be used to reveal sensitive data that are ordinarily accessible only to the user and the programs. information release policies may be published by authors of programs; additionally, users can define their own information release policies for programs they use, in order to specify their expectations of information release. most importantly, users control the application of the static analysis tool to programs they execute in order to check that their policies are satisfied. on one hand, if a program fails the analysis, this is an indication that it may contain exploitable flaws. on the other hand, programs that pass verification are provably secure against the attacker model used in the verification. 3 static analysis in this section we present a static analysis of information flow in while programs. 3.1 syntax and semantics of the while language. in this section we present the core imperative language, while, which has loops and input-output interactions. its syntax (figure 1) and the operational semantics (figure 2) are largely familiar. c ∶∶= skip ∣ z ∶= e ∣readz ∣writee ∣ c; c ∣if(b)thencelsec ∣while(b)doc figure 1: the while language in the language, expressions are either boolean-valued (with values taken from b ≜ {tt,ff}), or integer-valued (taken from z). program states, σ, are maps from variables to values. the evaluation of the expression e at the state σ ∈ σ is summarised as σ (e). expression evaluations are performed atomically and have no side-effect on state. a program action, ranged over by a, can either be an internal action τ , which is not observable ordinarily; or it can be an input action through the read command; or it can be an output action via the write command, where the expression value can be observed. secret program inputs are treated as parameters. the operational semantics is specified through transition relations between expression configurations (⟨e,σ ⟩ τð→ ⟨σ (e),σ ⟩) and command configurations (⟨c,σ ⟩ að→ ⟨c′,σ ′⟩). a special terminal command configuration, ⟨⋅,σ ⟩, indicates termination in the state σ . the set of all command configurations, including the terminal command configuration is denoted by s. we adopt the relational semantics definition of [6], where program semantics is modelled as a relation j⋅o ⊂ σ∞ × σ∞ over the extended state space σ∞ = σ ∪{∞}, which is obtained by adding a special “looping state” ∞ to σ. thus, for any program c, σ jco σ ′ holds if there exists a terminating state σ ′ ∈ σ of c when it is executed at the initial state of σ ∈ σ; otherwise σ jco ∞ asserts the divergence of c under σ . additionally, no program can exit the “looping state”, so that 3 / 15 volume 35 (2010) static analysis of information release in interactive programs ∞jco∞ always holds. furthermore, we assume that ⟨c,∞⟩ τð→ ⟨c,∞⟩. the angelic relational semantics j⋅o ↓ restricts the domain and range of j⋅o to σ. the operators ; and ∪, when used with relations, are respectively the standard relational composition and union operators. ⟨skip,σ ⟩ τð→ ⟨⋅,σ ⟩ ⟨z ∶= e,σ ⟩ τð→ ⟨⋅,σ [z ↦ σ (e)]⟩ ⟨read z,σ ⟩ in(n) ð→ ⟨⋅,σ [z ↦ n]⟩ ⟨write e,σ ⟩ out(σ (e)) ð→ ⟨⋅,σ ⟩ ⟨c1,σ ⟩ að→ ⟨⋅,σ ′⟩ ⟨c1; c2,σ ⟩ að→ ⟨c2,σ ′⟩ ⟨c1,σ ⟩ að→ ⟨c′1,σ ′⟩ ⟨c1; c2,σ ⟩ að→ ⟨c′1; c2,σ ′⟩ ⟨b,σ ⟩ τð→ ⟨tt,σ ⟩ ⟨c1,σ ⟩ að→ ⟨c′1,σ ′⟩ ⟨if(b)thenc1 elsec2,σ ⟩ að→ ⟨c′1,σ ′⟩ ⟨b,σ ⟩ τð→ ⟨ff,σ ⟩ ⟨c2,σ ⟩ að→ ⟨c′2,σ ′⟩ ⟨if(b)thenc1 elsec2,σ ⟩ að→ ⟨c′2,σ ′⟩ ⟨b,σ ⟩ τð→ ⟨ff,σ ⟩ ⟨while(b)doc,σ ⟩ τð→ ⟨⋅,σ ⟩ ⟨b,σ ⟩ τð→ ⟨tt,σ ⟩ ⟨c,σ ⟩ að→ ⟨c′,σ ′⟩ ⟨while(b)doc,σ ⟩ að→ ⟨c′;while(b)doc,σ ′⟩ figure 2: operational semantics of while preliminaries. partial equivalence relations (pers) have been used to model information [7, 11]. a per over a set ω is a symmetric and transitive binary relation. if, in addition, the per is reflexive over ω, then it is an equivalence relation over that set. for any given set ω, we denote the set of all pers over ω to be per(ω). let r ∈ per(ω) be a per, the domain of definition of r is given by dom(r) ≜ {ω ∈ ω ∣ ω r ω}, and for any ω ∈ dom(r), the equivalence class of ω is given by [ω]r ≜ {ω′ ∈ ω ∣ ω r ω′}. we denote by [ω]r ≜ {[ω]r ∣ ω ∈ dom(r)} the set of all equivalence classes of r. a per over ω models information by its ability to distinguish, or not, the elements of the set ω [12]. two elements of ω are said to be indistinguishable (lack of knowledge) by a per if they are related by that per, otherwise the per distinguishes (has knowledge about) them. let r,r′ ∈ per(ω) be pers, r′ is said to be more informative than r, written r ⊑ r′, iff for every ω,ω′ ∈ ω, ω r′ ω′ ô⇒ ω r ω′. the intuition behind r ⊑ r′ is that if r′ cannot distinguish a pair, neither can r; and thus by the contrapositive, r′ distinguishes more than r, making r′ more informative. in order to combine the information in two pers r and r′, we define the lattice join operation ⊔ over pers, such that for all ω,ω′ ∈ ω,ω (r⊔r) ω′ iff ω r ω′ and ω r′ ω′. it is clear that r ⊑ r′ ⇐⇒ r⊔r′ = r′. the extension of ⊔ to sets is defined in the usual way, such that for any r⊆ per(ω), ω ⊔rω′ iff ∀r ∈r, ω r ω′. for any set ω, per(ω) is a complete lattice. we also note the general property that the union r∪r′ of disjoint pers is also a per. we define the identity (id) and the all (all) equivalence relations over ω such that for all ω,ω′ ∈ ω, ω all ω′ holds; and ω id ω′ holds iff ω = ω′. for any while expression e of type t, where ⟦t⟧ is the set of all t-values, and φ ∈ per(⟦t⟧), define e ∶ φ ∈ per(σ) to be the per over program states defined such that ∀σ,σ ′ ∈ σ,σ e ∶ φ σ ′ iff σ (e) φ σ ′(e). let rng(r) be the range of the relation r, we define the operator ●, which composes a relation and a per, and is defined proc. avocs 2010 4 / 15 eceasst for any per r over σ such that ∀σ,σ ′ ∈ σ,σ jco ● r σ ′ iff ∃σ1,σ2 ∈ rng(jco↓) s.t. σ jco σ1 ∧ σ ′ jco σ2 ∧σ1 r σ2 ∨(σ jco ∞∧σ ′ jco ∞). since c is deterministic, and hence jco is a function, the relation jco● r is a per, and it mirrors in the domain of jco, the partitioning of the range of jco by r. additionally, jco● r partitions initial states of c that lead to divergence from those under which c terminates. the map µ ∶p(ω) → [0,1] is a probability measure over ω if µ(ω) = 1, and for any disjoint x,y ⊆ ω, µ(x ∪y ) = µ(x)+ µ(y ). for singleton events {ω} ⊆ ω, we write µ(ω) instead of µ({ω}). given the probability measure µ over the space ω, the entropy of the space due to µ is given by h(µ) = −∑ω∈ω µ(ω)log2(µ(ω)). 3.2 attacker models the information gained by an attacker through a program is determined by what the attacker can observe during the program’s execution. we refer to what the attacker can see about a program’s execution as the attacker’s observational power. therefore, the analysis of secure information release is carried out relative to a specific attacker, modelled by the attacker’s observational power. we formalise the attacker’s observational power as a rewrite of the labels of the standard transition system of the program to an induced transition system. this allows us to parametrise the static analysis with the specific attacker models, against which the analysis is secure. let t = ⟨s,ð→,a⟩ be the labelled transition system of a program in the concrete semantics, then the observational power of an attacker a over this program induces another transition system ta = ⟨s,ð→a,aa⟩, where aa is the set of actions that can be observed by a, and ð→a⊆s×aa ×s is the transition relation as seen by a. typically, ð→a is defined as rewrite rules over ð→. as usual, a∗a is the kleene closure of aa, and we abbreviate by αð→a, the sequence of transitions a1ð→a a2ð→a ... in ta, where α = a1,a2,... ∈a∗a. we consider a standard attacker as, which is able to observe the output values of write statements. this attacker cannot ordinarily observe input actions or the values read during input, which allows us to model input actions (such as read from files), which are not visible to the attacker. however, what the attacker knows about inputs is modelled directly in our information flow definition (r ⇒ r′, introduced in section 4). this is reasonable, since the attacker’s prior knowledge is external to the program semantics, and is only a parameter to our analysis of information flow. thus, ð→as rewrites all labels of the transition relation ð→ of the standard operational semantics to τ , except for output labels out(v), which are left unchanged. 3.3 information release typing rules we now present the concrete static analysis of while programs with respect to an attacker model a. firstly, we define an equivalence relation ≡ac over states, which models the information released to the attacker a by observing the execution of c as follows: ∀σ,σ ′ ∈ σ, σ ≡ac σ ′ iff ∀α,α′ ∈a∗a ∃⟨⋅,σ1⟩ ∈s∧⟨c,σ ⟩ αð→a ⟨⋅,σ1⟩ ⇐⇒ ∃⟨⋅,σ2⟩ ∈s∧⟨c,σ ′⟩ αð→a ⟨⋅,σ2⟩ & ∃⟨c′,σ1⟩ ∈s∧⟨c,σ ⟩ α ′ ð→a ⟨c′,σ1⟩ ⇐⇒ ∃⟨c′′,σ2⟩ ∈s∧⟨c,σ ′⟩ α ′ ð→a ⟨c′′,σ2⟩ (1) it is clear that ≡ac relates any pair of states that lead to executions of c, which are observa5 / 15 volume 35 (2010) static analysis of information release in interactive programs tionally equivalent as far as the attacker a can tell, and it captures semantically, the information that a can gain about the initial states of c. the definition of ≡ac is termination-sensitive, distinguishing between terminating and non-terminating executions of c. it is easy to see that ≡ac is an equivalence relation over states. our static analysis is defined as a type system, parametrised by an attacker model. the typing derivation for a program c, under the attacker model a, captures how a’s knowledge changes due to information released by c and is written in the form γa ⊢ c ∶ (rx ,r) ⇒ (ry ,r′). the typing environment γa makes explicit the fact that the analysis is with respect to the attacker model a. the per r stands for our assumption about a’s initial knowledge and the per r′ is the information released to the attacker, which includes the attacker’s initial knowledge (that is, r ⊑ r′). we use rx and ry to model how c transforms program states, linking the analysis of information flow to the program semantics. we assume rx ⊆ σ∞ × σ∞ is a function, which maps an initial set of states of interest to the set of states prior to the execution of c. then, ry ⊆ σ∞ × σ∞ is also a function, which maps the initial set of states to the states after the execution of c, and is simply obtained by the composition ry = rx ;jco. formally, the type judgement γa ⊢ c ∶ (rx ,r) ⇒ (ry ,r′) is valid if ry = rx ;jco and ∀σ,σ ′ ∈ σ, σ r′ σ ′ ô⇒ σ r σ ′ ∧(∃σ1,σ2 ∈ rng(rx ) ∶ σ rx σ1 ∧σ ′ rx σ2 ô⇒ σ1 ≡ac σ2). (2) the judgement γa ⊢ c ∶ (rx ,r) ⇒ (ry ,r′) characterises the information released by c to the attacker a, which refines a’s knowledge over the initial set of states in dom(rx ). for full program analysis, we will typically take rx to be the identity relation over σ. thus, under the assumption of initial information r that the attacker a might have, a can gain at most the information r′ by observing the execution of c which can be computed as r′ = (rx● ≡ac )⊔ r. this semantic definition of information flow ties together the standard program semantics, the attacker’s observational power, and the information release. note that the clause σ r′ σ ′ ô⇒ σ r σ ′ in (2) ensures that the attacker’s knowledge is monotonically increasing. we present the analysis rules for the standard attacker model as in figure 3. the rules also apply to other attacker models, such as at (introduced in section 5), which are simple rewrites of the transition relation under as. since the attacker model is clear, we shall simply write the typing judgement γas ⊢ c ∶ (rx ,r) ⇒ (ry ,r′) as c ∶ (rx ,r) ⇒ (ry ,r′), and ≡asc as ≡c. the analysis rules for skip, assignment and read statements do not change the attacker’s knowledge, and hence do not ordinarily release information because the attacker model cannot directly learn anything about the inputs by observing their execution. the rule for write statement shows that the attacker gains information about the expression e, by partitioning the input space so that all states in each class evaluates e to an identical value. the composition rule, [comp], shows how to compose the analysis of sequential statements. the rule [sub] says that we can safely weaken our assumptions about attacker’s prior knowledge and strengthen the result of the analysis of the attacker’s final knowledge. the rule for if statement combines the information released by the execution of the conditional statement with the attacker’s prior knowledge. finally, the while rule, computes a fixed point of the information released by unrolling the while statement to an equivalent one-step execution, and applying the rule until a fixed point is reached. since the analysis rules are to be applied in a concrete static analysis tool, we assume that the set of states σ considered is finite, so that there exists a unique n for the least fixed point. a more general definition, of the while fixed point, which copes with a countably infinite set of proc. avocs 2010 6 / 15 eceasst skip ∶ (rx ,r) ⇒ (rx ,r) z ∶= e ∶ (rx ,r) ⇒ (rx ;jz ∶= eo,r) readx ∶ (rx ,r) ⇒ (rx ;jreadxo,r) writee ∶ (rx ,r) ⇒ (rx ,r⊔(rx ●e ∶ id)) [comp] c1 ∶ (rx ,r) ⇒ (ry ,r′) c2 ∶ (ry ,r′) ⇒ (rz,r′′) c1; c2 ∶ (rx ,r) ⇒ (rz,r′′) ry = rx ;jc1o rz = ry ;jc2o [sub] c ∶ (rx ,r1) ⇒ (ry ,r2) r0 ⊑ r1 r2 ⊑ r3 c ∶ (rx ,r0) ⇒ (ry ,r3) ry = rx ;jco c = if(b)thenc1 elsec2 if(b)thenc1 elsec2 ∶ (rx ,r) ⇒ (ry ,r⊔(rx ● ≡c)) ry = rx ;jco if(b)thencelseskip ∶ (rxi,ri) ⇒ (r′xi,ri+1) rxi+1 = rxi ∪r ′ xi r′xn ≜ {(σ,∞),(σ1,σ2)∣(σ,σ ′) ∈ rxn,σ ′(b) = tt∨σ ′ = ∞,(σ1,σ2) ∈ rxn,σ2(b) = ff} σ r′nσ ′ ⇐⇒ (∃σ1,σ2 ∈ rng(kr′xn p↓)∧σ r ′ xn σ1 ∧σ ′ r′xn σ2)∨(σ r ′ xn ∞∧σ ′ r′xn ∞) while(b)doc ∶ (rx0,r0) ⇒ (r′xn,rn ⊔r ′ n) rxn = rxn+1 rn = rn+1 figure 3: information release typing rules states would be (⋃i∈n rxi,⊔i∈n ri). at the fixed point, the while statement diverges at states that evaluate the guard b to tt, hence those states are replaced by the “looping state” ∞, which cannot cause further information flow in subsequent statements. furthermore, r′n partitions the initial states between those that lead to divergence of the while and those that do not. theorem 1 (correctness) for any program p, and attacker as’s initial knowledge r. let rx ⊆ σ∞ × σ∞ be a strict total function over the finite extended state space σ∞ of p and let σ ∣rx ∣σ ′ ⇐⇒ σ,σ ′ ∈ {σ1 ∈ dom(rx ) ∣∃σ2 ∈ rng(jrx o↓)∧σ1 rx σ2}. then the type derivation γas ⊢ p ∶ (rx ,r) ⇒ (r′x ,r ′) has the following properties 1. r′x = rx ;jpo, 2. (rx● ≡asp )⊔r ⊑ ∣rx ∣⊔r ′. theorem 1 establishes the correctness of the analysis by expressing a safety property of the analysis. in particular, if we choose rx to be the identity relation over the state space of p, then we can see that the result of the analysis of information release r′, under any assumption of the attacker’s prior knowledge is always at least as great as the combination of the attacker’s prior knowledge and the actual information (rx● ≡asp ) =≡ as p released by the program p. that is, ≡asp ⊔r ⊑ r ′. 7 / 15 volume 35 (2010) static analysis of information release in interactive programs 4 information flow policies our objective is to ensure that a program that requires (legitimate) access to confidential data does not release more information than is intended. we now present a semantic definition of information flow policies, which characterises our intentional information release requirements. generically, we view information release policies such that, given a lattice of information, the policy sets upper bounds on the information transferred through a program to an observer. our information release policies fall under the what dimension of information declassification, which considers what information is released by a system. other dimensions of declassification include the who, when, and where dimensions [12]. after information release, the final knowledge of the observer is dependent on the observer’s initial knowledge. in this paper, we consider the case where the observer’s final knowledge is simply computed by taking the lattice join of the initial knowledge and the information release. schematically, if ki ∈i is the initial knowledge of the observer, and r ∈i is the intended information release, both taken from some underlying lattice of information i, then, in this scheme, the final knowledge k f of the observer is computed simply as k f = ki ⊔ r. more generally though, we consider a class of information release policies, _, which are maps from some initial knowledge of the observer to a final one. since information release causes knowledge to increase, the only requirement in this more general case is that the final knowledge is at least as much as the initial one before receiving additional information. we define such a class of policies below. because the secrets to be protected are stored in program states during computation, in this paper, our information lattice is defined as partial equivalence relation over states. definition 1 (enforcement of per-based information release policies) let σ be the set of program states and let i ≜ per(σ) be the set of all partial equivalence relations over σ such that r,r′ ∈ i. an information release policy, r _ r′, is a transformer over the lattice i such that r ⊑ r′. a program p is said to satisfy the policy r _ r′ (under the attacker model a) if the typing judgement γa ⊢ p ∶ (id,r) ⇒ (ry ,r′′) holds, and we have that r′′ ⊑ r′. the information release policy r _ r′ allows the observer to gain at most the information r′ if the observer has a prior information ra such that r ⊑ ra ⊑ r′. intuitively, the requirement r ⊑ r′ means that information release policies can only increase the observer’s knowledge; although, it may dissalow information gain in case of the noninterference [5] policy: r _ r. as an example, a policy that releases at most the parity of the secret contained in variable x may be defined as: all _ parx, where parx is the equivalence relation defined such that ∀σ,σ ′ ∈ σ,σ parx σ ′ ⇐⇒ σ (x) = σ ′(x) mod 2. this says that if the observer has no prior information (i.e. cannot distinguish any pair of states since σ all σ ′ holds for all states), then the observer is allowed to be able to distinguish at most the parity of x after the release. the second part of definition 1 shows how to enforce the information release policy r _ r′. we start by the verification, through static analysis, of the program to determine the level of information that it might release to the observer. the verification is based on the assumption r, of the attacker’s initial knowledge. the program is deemed secure if the analysis result r′′, which represents the information that the program might release is below r′ (the upper bound on proc. avocs 2010 8 / 15 eceasst information flow allowed by the policy). because we specified id in γa ⊢ p ∶ (id,r) ⇒ (ry ,r′′), the analysis is carried out over the total state space of p. because of the ordering property pers, which means that r1 ⊑ r2 ô⇒ dom(r2) ⊆ dom(r1), we need not use the identity relation id over σ, rather, we can restrict this to the identity relation over the actual space of inputs to p; or, in the case that dom(r) is smaller than that input space, over dom(r). this results in some analysis efficiencies. 5 example: password timing attacks in this section we consider two password-checking programs, expressed in the while language. this example is motivated by potential timing attacks that may be mounted against versions of the openssh with pam (pluggable authentication module) support distributed with various linux operating systems. in summary, depending on the behaviour (timing delay) of the authentication module on invalid username-password combinations, the attacker may be able to infer further information on whether a user exists or not, in addition to whether the supplied password matches the valid user’s password or not. note that the timing delays are usually added to failed authentication steps to reduce the effectiveness of dictionary attacks, however, wronglyimplemented, can be exploited as we demonstrate in the following analyses. the standard observational model as cannot observe time delays in program execution. hence, for the examples below, we shall introduce an attacker model, at , which can observe the passage of time, or, more precisely, can model various delays during program execution by counting the number of primitive commands executed. it can also observe read prompts, when the program accepts either the username or password. the attacker model at extends the standard observational capability of as by introducing a capability to count the number of primitive commands executed. the transition relation ð→at as seen by the attacker at is defined, for any of the small-step command-configuration transition in ð→as , as ⟨c,σ ⟩ að→as ⟨c′,σ ′⟩ ⟨c,σ ⟩ ⟨a,t+1⟩ ð→ at ⟨c′,σ ′⟩ [t] ⟨c,σ ⟩ að→as ⟨⋅,σ ′⟩ ⟨c,σ ⟩ ⟨a,t+1⟩ ð→ at ⟨⋅,σ ′⟩ [t] ⟨readx,σ ⟩ að→as ⟨⋅,σ ′⟩ ⟨readx,σ ⟩ ⟨in,t+1⟩ ð→ at ⟨⋅,σ ′⟩ [t] (3) thus, if the program makes a small step transition in the standard semantics at the “time” t, the attacker observes the increment of counter t by 1, in addition to the action a performed in the standard semantics. this capability constitutes the basis of the timing attacks demonstrated below. in a password authentication program we have to release the information that a user with the correct password is valid (the case when authentication succeeds) and that a valid user with the wrong password as well as invalid users regardless of the password are invalid (the case when authentication fails). what we do not want to do is to further distinguish the cases between a valid user with wrong password and a non-existent user. the intended information release policy can be formalised as follows. let u be the set of all possible users, regardless of whether they exist or not on the target system, and let u ⊆u be the valid ones, that exist on the target system. for each valid user u ∈ u , let pu be the user’s password. similarly, let p be the set of all possible passwords, of which a 9 / 15 volume 35 (2010) static analysis of information release in interactive programs subset of it is the set of legitimate users’ passwords. the set of valid users, with valid passwords is thus v = {(u, pu) ∣ u ∈ u, pu ∈p}. hence, we can define our username-password state space to be σ =u×p, and the equivalence relation which models precisely the information we intend to release is rv where ∀(u, p),(u′, p′) ∈ σ,(u, p)rv (u′, p′) ⇐⇒ (u, p),(u′, p′) ∈v ∨(u, p),(u′, p′) ∈ σ/v . this equivalence relation only distinguishes legitimate users with correct passwords from the rest of the world, and no more. hence, our intended information release policy would be all _ rv, which allows the observer, which has no prior information, to gain the information rv (as required by a genuine authentication system). now consider the program on the left-hand-side of figure 4. this program accepts both the username and password at the beginning, and then outputs the value 1 on a successful authorisation, or: • either produces a time delay1 of na units and outputs the value 2 to indicate an unsuccessful attempt (the case of an invalid password), • or produces a time delay of nb units and outputs the value 2 to indicate an unsuccessful attempt (the case of an invalid username). clearly the values of na and nb are significant: if na=nb then an attacker observing time delays will not be able to distinguish whether a delay has been caused by an incorrect username or an incorrect password. if the attacker only observes program output he or she will not be able to distinguish these cases, since both write out the same “error message” value of 2. our static analysis, under the attacker model at , is able to distinguish between the case when na=nb, and the case when na≠nb. let the program be pa, which sets na=nb. then applying the analysis rule to pa, under the attacker model at , gives γat ⊢ pa ∶ (id,all) ⇒ (ry ,rv) on the one hand2. on the other hand, now consider another implementation pb where na≠nb. we obtain the type analysis γat ⊢ pb ∶ (id,all)⇒(ry ,r′v), where ∀(u, p),(u′, p′) ∈ σ,(u, p)r′v (u′, p′) ⇐⇒ (u, p),(u′, p′) ∈ v,(u, p),(u′, p′) ∈ v ′,(u, p),(u′, p′) ∈ σ/(v ∪v ′), and where v ′ = (u ×p)/v is the set of valid users with invalid passwords. clearly, since r′v /⊑ rv,(in fact, rv ⊏ r′v), pb does not satisfy our information release policy, and should therefore be rejected. generally, the evaluation of expressions is not observable, and therefore the evaluation of the member and valid expressions conditions is not visible to the attacker in these examples. the password checking program on the right hand side of figure 4 is differently structured to that of the left, in that it first accepts only the username at the start and directly checks whether it is valid or not, producing a delay nb in the latter case before reporting a failure. however, the fact that the user is prompted to enter the password in the case that the username exists, and is not in the case that the user does not exist already reveals information on the existence or not of the specified user, even without further interaction. the static analysis of this program pc is γat ⊢ pc ∶ (id,all)⇒(ry ,r′v), where ∀(u, p),(u′, p′) ∈ σ,(u, p) r′v (u′, p′) ⇐⇒ (u, p),(u′, p′) ∈ v,(u, p),(u′, p′) ∈ v ′,(u, p),(u′, p′) ∈ σ/(v ∪v ′). this is exactly the same information released by the program pb where the fact that na differs from nb helps the attacker to distinguish the 1 the delay n function may be implemented in the while language by looping over a skip statement n times, which can be differentiated by the attacker model at for different values of n. 2 the relation ry maps all initial states to a final state that contains the supplied username and password values. proc. avocs 2010 10 / 15 eceasst read user; read pw; if (member(user,u)) then if (valid(user,pw)) then write 1 else delay na write 2 else delay nb write 2 read user; if (member(user,u)) then read pw; if (valid(user,pw)) then write 1 else delay na write 2 else delay nb write 2 figure 4: password-checking programs (version 1 on the left, and version 2 on the right). case between non-existent user and a valid user with invalid password. however, in the case of pc, the same information is released regardless of the equality or not of na and nb. the lesson learned from these analyses is that even non-malicious program can contain subtle bugs or design flaws which violate information security policies and must therefore be checked against such unintended information leakage. however, our approach is perfect for the malicious code scenario, where apart from the possibility of unintentional information leakage, malicious information release can be detected through static verification of programs. in the case of the program on the left hand side of figure 4, the implementation is correct, but the configuration (i.e. how the values of na and nb are set relative to each other) can expose the timing flaw, which our analysis detects. however, in the case of the right hand side program, it is an implementation or design flaw to check the existence of the user before proceeding to prompt for a password. 6 quantifying the information release the analysis presented in this paper shows that deterministic programs may be viewed as agents that release information by partitioning their input domains. policies are then controls, which specify to what extent a program is allowed to partition this domain. when the analysis is furnished with a probability measure, which represents the attacker’s uncertainty over the input space, our qualitative per-based policy specification actually dictates the maximum quantitative information, in an information-theoretic [13] sense, that the program in question is allowed to release. because of the determinism, any sort of probability distribution observed in the output behaviour of the program is induced by the probability distribution of the input space, and hence any reduction in the uncertainty of the attacker over the entropy of the input space obtained by observing program execution is, in fact, as a result of the refinement of the partitioning of the input space caused by the program. hence, when we specify the policy r _ r′, where r ⊑ r′ are equivalence relations, we are effectively also specifying an upper bound on the quantitative information that we allow to be released. specifically, given a probability distribution µ over the input space σ, the equivalence relation r over σ describes what the attacker is assumed to 11 / 15 volume 35 (2010) static analysis of information release in interactive programs know before the execution of the program, and the qualitative information r can be quantified as h(µ∣r) (see definition 2), which measures the entropy of the input space under the distribution µ , subject to the partitioning of the input space by r. similarly, under the policy r _ r′, where we allow the attacker to refine its knowledge about the input space from r up to a maximum of r′, the policy effectively specifies the minimum entropy h(µ∣r′) over the input space that the attacker is allowed to reach. thus, under any given probability distribution of the input space, the policy r _ r′ specifies an upper bound on the quantitative information that we allow to be released: this is a maximum allowable reduction in entropy h(µ∣r _ r′) given below. definition 2 (quantifying information release) let µ be a probability measure over the set σ and let r,r′ ∈ per(σ) be equivalence relations over σ such that r ⊑ r′. define the entropy of the space σ, under µ , subject to the partitioning of r as h(µ∣r) =h(µ)− ∑ x∈[σ]r µ(x)log2(µ(x)). define the entropy reduction over the space σ under r _ r′ as h(µ∣r _ r′) =h(µ∣r)−h(µ∣r′). the definition of h(µ∣r) takes away from the entropy of µ , the entropy of the space of the equivalence classes of r. since σ is assumed finite, recall that by the finite additivity property of µ , we may compute µ(x), for any equivalence class x ∈ [σ]r of r, as µ(x) = ∑σ∈x µ(σ ). now, the definition h(µ∣r _ r′) of quantitative information release is reasonable. for example, the policy all _ id, which on the one hand allows the attacker to gain all information about the input space quantitatively removes all the uncertainty of the attacker, because for any initial uncertainty as modelled by the measure µ over the input space h(µ∣all _ id) =h(µ). on the other hand, the non-interference [5] policy, all _ all, which prevents the attacker from refining its knowledge through information release has the property that h(µ∣all _ all) = 0. for the password authentication example of section 5, the desired quantitative information release under the assumption of the attacker’s initial probability distribution µ is h(µ∣all _ rv). like under the qualitative per-based policy, the programs pb and pc do not satisfy the quantitative information release requirement either under any assumption of µ . this is be because rv ⊏ r′v and rv ⊏ r′′v and we can easily show that for any µ , and pers ra and rb, ra ⊑ rb ô⇒ h(µ∣rb) ≤ h(µ∣r). however, because the reverse implication does not necessarily hold, this can lead to a false sense of security. in particular, because the entropy measure only uses the probability distributions, and not the space itself, the values may not reflect which element has become more likely as a result of information release. this is clear because, for example, permutation of probability measures over the space will leave the entropy measure unaffected. to have more control over about what elements of the input space information is released, we advocate using qualitative policies, rather than only quantitative ones. let us illustrate this with a final example. now consider the following four programs, which processes the input parameter h ∈ {0,1,2,3}, which is a secret: • p1 ≜ writeh−h proc. avocs 2010 12 / 15 eceasst • p2 ≜ writeh mod 2 • p3 ≜ if(h ≤ 1)thenwrite1elsewrite2 • p4 ≜ writeh. let us model the state space of these programs by h = {0,1,2,3}, where n ∈ h models the state where the value of variable h is n. our analysis shows the following results: γas ⊢ p1 ∶ (id,all) ⇒ (ry ,all), γas ⊢ p2 ∶ (id,all) ⇒ (ry ,κ), γas ⊢ p3 ∶ (id,all) ⇒ (ry ,κ′), γas ⊢ p4 ∶ (id,all) ⇒ (ry ,id), as depicted in figure 5, where ry maps all states to the input value of h. the equivalence relations are defined as follows: ∀h,h′ ∈ h, h κ h′ iff h = h′ mod 2, h κ′ h′ iff h,h′ ∈ {0,1} or h,h′ ∈ {2,3}. the arrows in figure 5 describe how the respective programs transform the partition of their domains. for example, the arrow labelled p4 shows that given the initial knowledge represented by all, the attacker’s final knowledge is modelled by id. by following the arrows labelled p2 and p3, we obtain the transformation of the attackers knowledge from all via κ to id, which can be obtained by running the composed program p2; p3. not all possible arrows are shown. now suppose that we wish to release, at most, the parity of the secret h. the desired qualitative policy would be all _ κ , which releases the parity of h. clearly p1 and p2 satisfy this policy, but p3 and p4 do not because κ′ /⊑ κ and id /⊑ κ . now, let us take a uniform probability measure µ over h, such that ∀h ∈ h, µ(h) = 14 . the desired quantitative information release is h(µ∣all _ κ) = 1: which allows 1-bit information over the space h to be released, since we are effectively halving the uncertainty over the whole space, which is 2 bits. so, quantitatively, we have for p1 and p2, the information release h(µ∣all _ all) = 0 and h(µ∣all _ κ) = 1, which satisfies our requirement as usual. however, for p3, we have also that h(µ∣all _ κ′) = 1, which satisfies our quantitative release requirement, but releases information other than the parity of h. this is a class of the probability permutation problem, where elements with the same probabilities in different equivalence classes are swapped between the equivalence classes of the per. this leads to a different per but leaves the entropy measure intact. 7 conclusions and future work in this paper we have presented a general static analysis technique for the verification of information release by programs written in a simple imperative language. the analysis technique is defined parametric to an attackers’ observational power. by using various observational powers, we can move the analysis from the standard semantics to other non-standard semantics, allowing us to model aspects of the system that may be implicit in the design, or that are specific to certain implementation environments, for example, multi-user environments where a program may be interacted with locally or across a network with different behaviours. to illustrate the use of various attacker’s observational power model, we presented an attacker which can count instruction execution, allowing this attacker to mount a “timing” attack on the system. we have demonstrated the value of such an attacker model through the analysis of password checking programs, which are inspired by the corresponding code in the openssh with pam implementation found in various unix systems, including versions of openbsd, and linux. 13 / 15 volume 35 (2010) static analysis of information release in interactive programs p1 all p2 κ p3 κ ′ p4 p3 p2 id 0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3 figure 5: how programs transform partitions of secret domain h = {0,1,2,3}. the work presented here forms the basis of a wider programme to analyse information release of operating system-level programs and code for mobile devices. building on the ideas presented here, we expect to be able to implement static code checking against information release policies: the first step will be to incorporate the rules for static analysis into a type checker for while-like programs. extensions of the language will be considered, including constructs for procedure invocation, object-oriented programming, and other features. if the verification of programs against information release policies is to be done at operating system level (with the type checker implemented as a kernel module, for example), then the analysis of binary executables may be necessary, since the original source code may not be to hand. in this case, the static analysis needs to be adapted for low-level language constructs. for mobile devices it may be sufficient to apply the analysis to the instruction set of a virtual machine such as the jvm or the dalvik executable format of the android platform, and this is a direction for further investigation. we find the approach of [4] very interesting. there is significant interest in the android platform for mobile devices, and there is an opportunity to study information release in this setting. finally, in this paper we have considered specific attacker models (as and at ) we hope to be able to perform the analysis for attackers with different observational capabilities. while for the password-checking problem it seems our model is sufficient, there are other possibilities to consider, and we hope to do so in the light of further examples and case studies. bibliography [1] ádám darvas, reiner hähnle, and dave sands. a theorem proving approach to analysis of secure information flow. in dieter hutter and markus ullmann, editors, proc. 2nd international conference on security in pervasive computing, volume 3450 of lncs, pages 193–209. springer-verlag, 2005. [2] a. o. adetoye and atta badii. a policy model for secure information flow. in pierpaolo proc. avocs 2010 14 / 15 eceasst degano and luca viganò, editors, arspa-wits, volume 5511 of lecture notes in computer science, pages 1–17. springer, 2009. [3] a. bouajjani, jean-claude fernandez, and nicholas halbwachs. minimal model generation. in edmund m. clarke and robert p. kurshan, editors, proceedings of computer-aided verification (cav ’90), volume 531 of lncs, pages 197–203, berlin, germany, june 1991. springer. [4] avik chaudhuri. language-based security on android. in plas ’09: proceedings of the acm sigplan fourth workshop on programming languages and analysis for security, pages 1–7, new york, ny, usa, 2009. acm. [5] j. a. goguen and j. meseguer. security policies and security models. in proceedings of the ieee symposium on research in security and privacy, pages 11–20, oakland, ca, april 1982. ieee computer society press. [6] r. joshi and k. r. m. leino. a semantic approach to secure information flow. science of computer programming, 37(1-3):113–138, 2000. [7] j. landauer and t. redmond. a lattice of information. in proceedings of the computer security foundations workshop vi (csfw ’93), pages 65–70, washington brussels tokyo, june 1993. ieee. [8] greg morrisett, karl crary, neal glew, dan grossman, richard samuels, frederick smith, david walker, stephanie weirich, and steve zdancewic. talx86: a realistic typed assembly language. in in second workshop on compiler support for system software, pages 25–35, 1999. [9] g. c. necula. proof-carrying code. in proceedings of the 24th acm sigplan-sigact symposium on principles of programming langauges (popl ’97), pages 106–119, paris, january 1997. [10] a. sabelfeld and a. c. myers. language-based information-flow security. ieee journal on selected areas in communications, 21(1):5–19, january 2003. [11] a. sabelfeld and d. sands. a per model of secure information flow in sequential programs. higher-order and symbolic computation, 14(1):59–91, march 2001. [12] a. sabelfeld and d. sands. declassification: dimensions and principles. journal of computer security, 2007. [13] c. e. shannon. a mathematical theory of communication. the bell system technical journal, 27(3):379–423, 1948. [14] dachuan yu and nayeem islam. a typed assembly language for confidentiality. in peter sestoft, editor, esop, volume 3924 of lecture notes in computer science, pages 162–179. springer, 2006. 15 / 15 volume 35 (2010) introduction analysis and enforcement framework static analysis syntax and semantics of the while language. attacker models information release typing rules information flow policies example: password timing attacks quantifying the information release conclusions and future work a middleware for self-organising distributed ambient assisted living applications electronic communications of the easst volume 27 (2010) workshop über selbstorganisierende, adaptive, kontextsensitive verteilte systeme (saks 2010) a middleware for self-organising distributed ambient assisted living applications jan schaefer 12 pages guest editors: klaus david, michael zapf managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst a middleware for self-organising distributed ambient assisted living applications jan schaefer distributed systems lab hochschule rheinmain, university of applied sciences kurt-schumacher-ring 18, d-65197 wiesbaden, germany jan.schaefer@hs-rm.de, http://wwwvs.cs.hs-rm.de abstract: this paper presents a middleware approach for self-organising distributed applications in the area of ambient assisted living (aal) as part of a home service platform. the middleware uses real time data processing techniques to identify complex events based on sensor input and service logs. this low-level and high-level information represents the platform’s context model, which forms the basis for self-organisation properties: controllers use context information to manage running services while adhering to strategies defined by users or inferred by the system itself. keywords: self-organisation adaptation context-awareness middleware aal 1 motivation flexible applications that are able to adapt their behaviour to an always changing environment at runtime are becoming more and more important. this need for runtime flexibility is caused predominantly by an increasing mobility of the devices executing applications (e.g. mobile devices) and growing user interest in applications that suit themselves to the current context (e.g. the user’s location). here, self-organising applications can increase the usability and the user experience and enable new application features and capabilities. contrary to static applications whose structure, features and behaviour are defined prior to execution, adaptive applications can react to external stimuli to support new or alternating capabilities without the need to restart the system. in addition, automated application adaptation reduces the need for manual intervention, which increases the manageability of adaptive systems profoundly. especially in environments with a constantly changing number of interacting distributed software components running on devices using and providing services, a formalised adaptation process and an accompanying adaptation middleware can increase the benefit and overall stability of the system. questions such as “what functionality can the system provide right now using the currently available components?” or “which additional components must i add to enable feature x?” cannot be answered easily at the moment. one field of research that heavily benefits from context-aware adaptive applications are service platforms for ambient assisted living (aal) environments. in recent years, several service platforms have been developed with different focuses. however, distributed computing and, especially, self-organisation properties such as self-management and structural adaptation have 1 / 12 volume 27 (2010) mailto:jan.schaefer@hs-rm.de a middleware for self-organising distributed aal applications not been focused so far. generally, it is either assumed that a technician installs and manages each component and the system as a whole, whenever the user likes to change something, or the platform consists of a fixed set of components provided by a single vendor (or a group of vendors) and cannot easily be changed. but being able to gradually build and extend their platform without being bound to a certain vendor and continuing services availability as resource availability fluctuates are major acceptance factors for users of such platforms, and as such these problems have to be addressed accordingly, if a service platform wants to succeed. instead of integrating the computation required for the decision to adapt into each application running on the platform, this computation has to be provided by the platform itself, more specifically its middleware. apart from the already discussed manageability and platform stability aspects, platform-provided adaptation also enables new types of applications: applications (and user interfaces) that react to the current position of a mobile device and/or user, or applications that react to even more complex information that is made available by the platform (e.g. the detection of emergency situations derived from fused sensor data). to be able to adapt to changes quickly, the service platform must enable applications to react automatically with minimal delay. as applications have to adapt to a changing execution environment (e.g. triggered by a change in location or resource availability), the service platform itself must incorporate self-management methods. however, user surveys have shown that they still want to be able to intervene and control the system themselves whenever they like. in the face of these challenges, this paper proposes a middleware for self-managing adaptive distributed applications, whose application area will be aal living environments. section 2 shortly introduces the ongoing research related to ambient assisted living. section 3 analyses related aal projects and feasible approaches for aspects of aal systems subsequently. the proposed service platform architecture is presented in section in section 4. although research and development for the architecture are still in an early phase, section 5 presents the results of preliminary work of the distributed systems lab. section 6 completes the paper with an outlook on the next steps. 2 ambient assisted living the emerging demographic change towards an ageing population has begun to introduce drastic changes in the european society. therefore, solutions have to be developed to motivate and assist older people to stay active for longer in the labour market, to prevent social isolation and to help people stay independent for as long as possible. information and communication technologies (ict) are designated to play a major role in helping to achieve these goals. it can help elderly individuals to improve their quality of life, stay healthier, live independently for longer, and counteract reduced capabilities which are more prevalent with age. ict can enable them to remain active at work, in their community and at home. however, the problems cannot be solved by means of ict alone. thus, interdisciplinary work is required to identify the actual problems and to develop and evaluate solutions together with the involved parties. it is important to note that ict technologies are supposed to work in the background, as many users simply will not be able to deal with the attached technical complexity. this is a major factor to ensure the acceptance of developed solutions. the research field dealing with the above presented problems saks 2010 2 / 12 eceasst is called ambient assisted living1 (aal). the european ambient assisted living innovation alliance called aaliance, which is funded within the specific programme cooperation and the research theme ict of the 7th european framework programme, focuses on aal solutions based on advanced ict technologies for the areas of ageing at work, at home and in the society. in 2009, aaliance released an ambient assisted living roadmap [bcow09], which presents a detailed overview into the prospected future of aal topics, concepts and technologies until the year 2025. of special importance for the work presented in this paper, this roadmap contains the aal systems composition reference architecture shown in figure 1, which details the common requirements for aal systems. �� !� �� "�� # $�� $�� $�� figure 1: aaliance systems composition reference architecture [bcow09] the reference architecture describes a three-layer networking approach to enable communication and connectivity between devices and services. it defines an aal system consisting of seven component types: • pan devices represent sensors and actuators that are either in-body, on-body or wearable and collect raw data. some devices are powerful enough to process the collected data locally and aggregate collected data. depending on its type, a device may be able to give basic feedback to the user in case of emergencies or failure (e.g. if the sensor cannot contact the application hosting device). • the pan interface provides communication and data exchange facilities between pan devices and one or more application hosting devices supporting dynamic configurations, which requires standardised discovery and communication protocols. security and data safety are equally important as health care data may be transmitted between nodes. if devices are battery powered, they should give a timely warning before they run out of power. • lan devices represent rather stationary devices, although they may be moved between rooms, quarters or public spaces. they also may be able to process data locally or collect data from multiple sensors. like pan devices, lan devices should give user feedback, if they cannot contact the application hosting device. 1 http://www.aal-europe.eu 3 / 12 volume 27 (2010) http://www.aal-europe.eu a middleware for self-organising distributed aal applications • the lan interface is similar to the pan interface, although energy consumption respectively power loss usually is a lesser issue for devices connected to power outlets. • an application hosting device (ahd) represents the central component of an aal system communicating with pan and lan devices to collect sensor data and control other devices. it relays the sensor data to relevant services and processes their reaction. in addition, it stores data gathered from devices for processing and reasoning and provides a user interface for information and interaction of system users. • the wan interface provides access to external (internet) services for the ahd. it does not matter, whether this connection is established via (a)dsl, cable, mobile or (public) wireless networks. in public networks, encryption is especially important to protect private information. • wan services are external services that are integrated into the aal system remotely. they may, for example, provide teleconferencing or health monitoring services. 3 related work home service platforms have not only been objects of research in the wake of increasing aal activities. for many years vendors have tried to develop hardware, software and services for home automation purposes that achieve broad acceptance in the consumer market (often called smart home). several german and european projects targeting selected aspects described in section 1 are presented subsequently. funded by the german federal ministry of economics and technology (bmwi), the sercho2 (service centric home) project was one of the first aal system projects focusing on the development of a platform, models and tools for service development in the area of health care and home automation. as a result, a proprietary closed platform was developed, which assumes a completely outfitted apartment and is not planned for incremental growth. the music3 (self-adapting applications for mobile users in ubiquitous computing environments) project is funded as part of the 6th european framework programme and primarily targets developers of modular, context-aware and adaptive mobile applications based on osgi. for these, the project provides methods and tools that support the development of mobile applications. this approach is based on a model defining the applications adaptation behaviour, from which source code is generated. the music middleware is released as open source software. the methodology developed by the music project is highly relevant for this paper, although its focus lies on mobility rather than aal. also funded as part of the 6th european framework programme is the soprano4 project that aims to develop an affordable osgi-based service platform, which promises ease of use for the elderly and support for social interactions and external health monitoring. the project plans to release its source code as open source software under the name openaal5. 2 http://www.sercho.de 3 http://www.ist-music.eu 4 http://www.soprano-ip.org 5 http://www.openaal.org saks 2010 4 / 12 http://www.sercho.de http://www.ist-music.eu http://www.soprano-ip.org http://www.openaal.org eceasst the german subproject osami-d6 of the european itea 2 (information technology for european advancement) project osami aims to develop an osgi-based service platform for it and health care called osami commons that uses the devices profile for web services (dpws) for sensor integration. the german research institute offis, which is the primary developer of the service platform, is also pushing standardisation of interoperable aal components within the german aal research community. although several aal and smart home projects featuring service platforms have been developed in recent years or are still under development, they do not focus on principles of selforganisation and coordinated distributed computing – especially self-management, adaptation and context-awareness. for example, [gpz04] proposes an infrastructure for context-aware applications, which relies on a static application structure. the music project features several of the self-organising properties desirable for aal systems, although it does not specifically target aal environments. in addition to music, openaal or osami commons might prove to be suitable building blocks for the implementation of the approach described in this paper, once the latter two become publicly available, as interoperability will likely become a major factor for acceptance and success of aal service platforms. 4 service platform architecture the main goal of the service platform architecture presented in this paper is to enable development, deployment and execution of self-organising services in living environments consisting of distributed computing resources, which are connected by wired or wireless networks. the system features a constantly updating information model, which is based on system (e.g. logs) and environment (e.g. sensors) data gathered at runtime. the model relies on formal, ontology-based descriptions [hwdc09] of users, devices, services and their relationships. although the system has to cope with potentially high dynamics caused by tens or hundreds of interacting nodes ranging from small sensors to pc-like workstations that can connect to or disconnect at any time, the service platform has to maintain a stable execution environment for executed services. 4.1 system level to be able to connect suitable communication partners with each other automatically (e.g. cameras producing video and tvs consuming video), this approach relies on formal descriptions of capabilities and dependencies in the form of ontologies provided by each device and service. ideally, this description is aligned with the platform’s core ontologies, which defines the basic terminology and relationships of relevant entities. the supplied descriptions are merged with the core ontologies and stored in an ontology repository, which can be queried by services. once a device has connected to the platform or a service has been deployed and provided its description, the platform stores the relevant mediation information in the repository and uses it to find appropriate communication partners henceforward. in addition, if a service specifies quality of service (qos) requirements for potential partners, the platform also regards their performance guarantees and history, before coupling service consumer and provider. 6 http://www.osami-commons.org 5 / 12 volume 27 (2010) http://www.osami-commons.org a middleware for self-organising distributed aal applications figure 2 illustrates the elements of the service platform. basically, the service platform runs arbitrary services while processing events according to the preferences of its user – the person or persons currently staying in the living quarter, in which the system is deployed. the activities can consist of automatic services, which manage available devices like lights, shutters or heating based on the users’ preferences, and of services interacting with users like a medicine reminder or teleconferencing application. each activity and each service can introduce new capabilities to the platform (described by ontologies), which can be shared between activities and services. �� figure 2: system level overview depending on their computing capabilities, devices (e.g. hardware sensors) are integrated into the system using either osgi [osg09] standardised by the osgi alliance (including osgi remote services for discovery and remote service access) and the less resource-demanding data distribution service (dds) [obj07] by the object management group. both middleware technologies are used to integrate devices into the platform to set the foundation for the core platform, which provides basic facilities required by services: • a service registry, which relies on semantic descriptions and performance data for its mediation • access to the ontology repository, which allows services to query the context model • security features (e.g. user authentication and code signing) to ensure data safety and platform integrity • performance instrumentation capabilities to enable reporting and claiming runtime performance characteristics although the platform employs several self-organisation properties (which are described in the subsequent section 4.2), it also contains a subsystem for manual administration and management, which allows defining user preferences and analysing, tracing and overriding decisions the system reached autonomically. the management subsystem also supports enabling performance instrumentation for selected services to gain a deeper insight of currently active services. the saks 2010 6 / 12 eceasst subsystem can be accessed locally by the system’s users or remotely by, for example, authorised service partners. in addition, it is able to list the ontologies stored in the ontology repository and to display the context model, so that administrators and tech-savvy users can analyse the current state and capabilities of the system. this knowledge is vital for adding new devices and services to extend the system’s functionality. 4.2 service level the self-organisation properties of the service platform heavily depend on its service layer, as this layer contains the data processing and control subsystems. because of its importance, the service layer is illustrated in further detail in figure 3 (cf. services in figure 2). �� figure 3: service level overview the data processing subsystem is responsible for collecting and processing events gathered from other services at runtime (e.g. instrumentation logs and sensor data). it consists of three components: the event collector, the context model and the mining framework. the first merely collects, sorts and categorises the gathered information and, thus, is not considered here any further. the platform supports data processing modules to derive complex, higher level context information from low-level events (e.g. to detect emergency or failure situations). to achieve this, different approaches for data analysis are integrated into the service platform: in addition to existing complex event processing [lf98] (cep) engines like esper [esp09, hit10], custom data stream mining (dsm) [gzk05] and knowledge reasoning approaches are used to process incoming information. to integrate the different analysis approaches, the event processing subsystem features a mining framework, into which additional processing modules can be plugged. the raw logging and event data and the processed complex, higher level information are provided to services as an ontology-based context model, which is partitioned into different layers of ontologies depending on the quality of the information: raw output from integrated small hardware sensors supplies the lowest layer of what is also referred to as the context pyramid information model. the second to lowest layer already requires processing of some sort (e.g. 7 / 12 volume 27 (2010) a middleware for self-organising distributed aal applications statistical calculations); information on higher layers may require elaborate processing (e.g. multiple sensor data fusion). but, hardware sensors do not necessarily deliver low-level information only. specialised appliances might provide already processed information to a higher layer of the context model (e.g. an optical tracker consisting of several cameras may deliver coordinates of a user’s location instead of a mere collection of single tracks). the higher in the pyramid an information element is placed (the more abstract it is), the less likely it can be associated directly to a specific service or hardware sensor output. services can subscribe to the elements of any layer in the context pyramid and are notified in case of changes caused by events. the more complex information contained in the context pyramid is primarily accessed by the control subsystem, which features a portal and controllers. the portal provides strategies, which can consist of global goals affecting all devices connected to the platform (e.g. “minimise energy consumption”), and local goals only affecting a subset of devices at a time (e.g. “always illuminate the room user x is in”). further details on the control subsystem and its capabilities are presented in section 4.4. a controller bundles services and devices with common functionality trying to meet strategy’s requirements. for example, a strategy may concern a light source controller able to control all light sources in a room. for this controller, the current locations of persons in the room are important as well as their individual illumination preferences. 4.3 horizontal and vertical integration the complexity of controlling the service platform and securing data integrity is increased by the services’ and devices’ distribution throughout the users’ living environment and beyond. thus, not every subsystem and its services has to be replicated to every device. rather, depending on the computing power of a device, services can be executed either locally on devices, or devices can consume necessary services remotely from peers. especially event processing, being computing-intensive, is provided by powerful devices, and the resulting context information is merely replicated horizontally to other nodes, which subscribed to the information, using dds. an aal system consists of devices with highly heterogeneous features, especially regarding computing power, power consumption and network connectivity. thus, not all devices can be integrated into the service platform in the same way, and not all devices will be connected to the internet directly. using both osgi and dds allows supporting a much broader range of devices, their deployment and vertical integration into the system. adoption of osgi and related technologies like universal plug and play (upnp) or devices profile for web services (dpws) by technology vendors in smart homes has increased significantly, so that more and more devices can be integrated as osgi services easily. in addition, dds is used to enable communication between small sensors (or even sensor networks) and high-level services and devices. the details of the dds subsystem are not in the focus of this paper and, therefore, not presented further. 4.4 self-organisation aspects whenever a service connects to the platform for the first time, it provides an ontology describing its capabilities and public interfaces offered to other services. if the new service enables new platform capabilities in combination with existing services and devices, the new functionality is saks 2010 8 / 12 eceasst enabled subsequently, which may require reconfiguration of existing services. new services also must provide management interfaces, which can be used by controllers to set up and manage the service at runtime, thus forming a control loop. for validation purposes, sensor feedback allows controllers to evaluate the effectiveness of their decisions. with regard to osgi, the application adaptation is not merely limited to service starts and stops. services might even be moved between containers (structural adaptation), in case of hardware or power failure, or if osgi bundles have to relocate to a mobile (e.g. before a user leaves the living quarter). especially mobile usage of services provides a wide range of adaptation scenarios, as the actions a user wants to take with his mobile can greatly differ between being at home and abroad. the portal provides strategies representing user preferences (“user x likes a room temperature of 22◦c”) or resulting from machine learning approaches used on runtime data. the latter, however, is not within the focus of this work). this setup can lead to conflicts of interest (e.g. between a user’s will and system stability), which have to be resolved automatically (e.g. through strategy prioritisation). the main purpose of strategies is, however, to define a set of policies for controllers, which enforce the instructions concerning their area of influence (e.g. rules or parameters). for this, controllers do not have to be connected to the portal permanently. if they do not receive strategy or policy updates, they continue their current course of operation. similar to the portal, controllers also have to deal with conflicting strategies, which have to be resolved (e.g. if users with contradicting preferences are in the same room). controllers are also responsible for monitoring changes in the systems structure (i.e., service or device availability), which may affect it or its controlled services. in case a relevant change occurs, it has to trigger the affected services’ adaptation (e.g. by activation or deactivation of interfaces). in addition to strategies, the portal may set application modes (e.g. emergency, night, party, absence), which trigger an adaptation in active services and influence how controllers and services react to sensorial input, if services know these modes and have the ability to adapt their behaviour (i.e., react differently for each mode). for example, the event “a window has been opened.” does usually not pose a problem generally. if, however, the current application mode was set to "absence" (i.e., no one is supposed to be home), this event could be an indication for an intrusion attempt. if a service does not know an announced application mode, it simply ignores the switch command. 5 preliminary work the development of the ambient assisted living service platform is still in an early phase, but fundamental work on several aspects has already begun. the results from the work presented subsequently are used in the development of the aal system. 5.1 data processing this section presents three master thesises and a diploma thesis, which were completed in the distributed systems lab. 9 / 12 volume 27 (2010) a middleware for self-organising distributed aal applications [mar09] changes application modes (cf.4.4) based on changing context information. using a finite state machine, applications can adapt their behaviour to context changes by switching rule sets. in addition, the adaptation is influenced by the new and previous application modes. this work is based on music. [ign09, mol09, gro09] developed three it management approaches using data stream mining based on uml models, owl ontologies and a bayesian network respectively. the first approach uses object constraint language (ocl) to annotate uml models with performance constraints. using the previously developed constraint monitor [tssk09], application logs are processed and workflows reconstructed. if a workflow violates its constraints, an appropriate notification is generated. the second approach is based on owl ontologies in combination with swrl rules. here, facts are extracted from application logs and update the knowledge base. the last approach uses log data to parametrise a bayesian network. afterwards, the network analyses log data to detect imminent failures. 5.2 osgi management being able to manage (e.g. monitor, analyse and configure) an application at runtime greatly eases the development process, especially when dealing with a potentially high number of distributed interacting nodes. thus, two student projects established a basis for generic, applicationindependent management and performance instrumentation of osgi-based applications. the developed prototypical management solution enables remote access to an osgi platform and all deployed osgi bundles using java management extensions (jmx). to achieve this, all jmx-enabled bundles register themselves with a local jmx agent, which can be accessed remotely using an jmx connector. this solution is used to dynamically alter the configuration (e.g. attributes) of jmx-instrumented bundles. the developed prototypical instrumentation solution relies on aspect-oriented programming (aop) to weave instrumentation code into osgi bundles. the instrumentation, which adds logging, call counter and execution time measurement capabilities, contains switches to enable or disable parts of the instrumentation dynamically at runtime using the management solution presented in the previous paragraph. 5.3 aal system demonstration environment osgi integrations for several home appliances have been developed in the distributed systems lab at hochschule rheinmain, so that they can be used to test, develop and demonstrate selected details of the distributed aal service platform. the integrated devices include: • ip power outlets, which can be switched and queried • a wireless camera, which can be rotated and delivers video, audio and pictures • wired door opening sensors, which can be queried for their status so far, the ip power outlets are mostly used to control light sources, which typically only require the on/off-states. the device services can be accessed via web service interfaces. in saks 2010 10 / 12 eceasst addition, mobile clients for google android and windows mobile have been developed, which offer graphical user interfaces for device interaction. 5.4 study of acceptance of mobile devices by the young elderly in a joint study between the distributed systems lab and the social welfare department at rheinmain university, two workshops with two groups of men and women between the age 50 and 65 – the so-called young elderly – were held in may and june 2009. during each workshop, requirements, interests and fears of the participants were collected and discussed. this input was used to develop a small prototypical application based on the integrated appliances presented in section 5.3, which were presented to the participants during another workshop in october 2009. the demonstration featured a complex activity, in which the system is configured to monitor all door opening sensors. whenever one of the sensors is activated (a door is opened), the camera turns to the respective door, takes a picture and sends it to a selected mobile. this demonstration was well-received by all workshop participants. the summarising report for this study is pending. 6 next steps and open issues this paper presents a middleware approach for self-organising distributed applications in the area of ambient assisted living. as presented in section 5, the current work focuses on enabling features such as data processing for the construction of the layered context model. the next step will concentrate on context subscription and evaluation by services and further self-organising properties such as approaches for the structural adaptation of distributed osgi applications. with regard to the implementation, the evaluation of existing service platforms will continue focusing on candidates supporting the integration of the approach presented here. this paper has not discussed how new devices or services are integrated into the aal system, nor how the describing ontologies are defined as these topics have not been within the focus of this paper. development and initial deployment of an aal system with its devices and services present a problem by itself, which will be addressed at a later stage. the creation of communication groups (e.g. between controllers and services) is another topic not covered in this paper. tightly related to this area of research are feasible approaches for resolving conflicts between strategies and controllers, which have yet to be dealt with. bibliography [bcow09] g. van den broek, f. cavallo, l. odetti, c. wehrmann (eds.). aaliance ambient assisted living roadmap. vdi/vde-it aaliance office, berlin, germany, september 2009. http://www.aaliance.eu/public/documents/aaliance-roadmap/ [esp09] espertech inc. esper an event stream processing and event correlation engine (version 3.3.0). december 2009. http://esper.codehaus.org 11 / 12 volume 27 (2010) http://www.aaliance.eu/public/documents/aaliance-roadmap/ http://esper.codehaus.org a middleware for self-organising distributed aal applications [gpz04] t. gu, h. k. pung, d. q. zhang. toward an osgi-based infrastructure for contextaware applications. ieee pervasive computing 3(4):66–74, october 2004. http://dx.doi.org/10.1109/mprv.2004.19 [gro09] p. großmann. klassifizierung von laufzeit-zuständen kritischer anwendungen mit hilfe von bayes-netzen [german]. master’s thesis, rheinmain university of applied sciences, november 2009. [gzk05] m. m. gaber, a. zaslavsky, s. krishnaswamy. mining data streams: a review. sigmod rec. 34(2):18–26, june 2005. http://dx.doi.org/10.1145/1083784.1083789 [hit10] j. hitchings. flexible log monitoring with scribe, esper, and nagios. january 2010. http://eng.kaching.com/2010/01/flexible-log-monitoring-with-scribe.html [hwdc09] m. hadzic, p. wongthongtham, t. dillon, e. chang. introduction to ontology. studies in computational intelligence 219, pp. 37–60. 2009. http://dx.doi.org/10.1007/978-3-642-01904-3_3 [ign09] a. ignat. ein data-stream-mining-ansatz zum proaktiven management von kritischen it-anwendungen [german]. master’s thesis, rheinmain university of applied sciences, november 2009. [lf98] d. c. luckham, b. frasca. complex event processing in distributed systems. technical report, 1998. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.56.876 [mar09] b. a. marinescu. eine architektur für kontextsensitive und adaptive verteilte anwendungen in aal-umgebungen [german]. master’s thesis, rheinmain university of applied sciences, october 2009. [mol09] g. moldovan. proaktives management einer kritischen it-anwendung unter nutzung von semantic web-ansätzen [german]. master’s thesis, rheinmain university of applied sciences, november 2009. [obj07] object management group. data distribution service for real-time systems (version 1.2). january 2007. http://www.omg.org/technology/documents/formal/data_distribution.htm [osg09] osgi alliance. osgi service platform release 4 (version 4.2) core specification. may 2009. http://www.osgi.org/download/release4v42 [tssk09] a. textor, m. schmid, j. schaefer, r. kroeger. soa monitoring based on a formal workflow model with constraints. in proceedings of the quasoss’09 workshop co-located with the esec-fse’09 conference. pp. 47–53. acm, amsterdam, the netherlands, august 2009. saks 2010 12 / 12 http://dx.doi.org/10.1109/mprv.2004.19 http://dx.doi.org/10.1145/1083784.1083789 http://eng.kaching.com/2010/01/flexible-log-monitoring-with-scribe.html http://dx.doi.org/10.1007/978-3-642-01904-3_3 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.56.876 http://www.omg.org/technology/documents/formal/data_distribution.htm http://www.osgi.org/download/release4v42 motivation ambient assisted living related work service platform architecture system level service level horizontal and vertical integration self-organisation aspects preliminary work data processing osgi management aal system demonstration environment study of acceptance of mobile devices by the young elderly next steps and open issues faster fdr counterexample generation using sat-solving electronic communications of the easst volume 23 (2009) proceedings of the ninth international workshop on automated verification of critical systems (avocs 2009) faster fdr counterexample generation using sat-solving h. palikareva, j. ouaknine and a. w. roscoe 15 pages guest editor: markus roggenbach managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst faster fdr counterexample generation using sat-solving h. palikareva, j. ouaknine and a. w. roscoe oxford university computing laboratory, oxford, uk abstract: with the flourishing development of efficient sat-solvers, bounded model checking (bmc) has proven to be an extremely powerful symbolic model checking technique. in this paper, we address the problem of applying bmc to concurrent systems involving the interaction of multiple processes running in parallel. we adapt the bmc framework to the context of csp and fdr yielding bounded refinement checking. refinement checking reduces to checking for reverse containment of possible behaviours. therefore, we exploit the sat-solver to decide bounded language inclusion as opposed to bounded reachability of error states, as in most existing model checkers. we focus on the csp traces model which is sufficient for verifying safety properties. we present a boolean encoding of csp processes resting on fdr’s hybrid two-level approach for calculating the operational semantics using supercombinators. we describe our bounded refinement-checking algorithm which is based on watchdog transformations and incremental sat-solving. we have implemented a tool, symfdr, written in c++ which uses fdr as a shared library for manipulating csp processes and the state-of-the-art sat-solver minisat. experiments indicate that in some cases, especially for complex combinatorial problems, symfdr significantly outperforms fdr. keywords: csp, fdr, concurrency, process algebra, bounded model checking, sat-solving, safety properties 1 introduction model checking techniques can be partitioned into those which are symbolic, based on abstract representation of sets of states, and those which are based on explicit examination of individual states. the former generally represent sets of states as formulae in boolean logic and use techniques such as sat-solving and bdd manipulation to decide checks. the latter can be enhanced by techniques such as hierarchical state-space compression and partial-order methods. the main obstacle when applying these approaches in practice is the state-space explosion problem by which the number of states in a system grows exponentially with the number of parallel components and also the number and bit sizes of data values. fdr [ros94, g+05] is a long-established tool for the refinement checking of csp [hoa85, ros98]. when deciding whether a proposed implementation process impl refines a normalised specification process spec, fdr follows algorithms exploring the cartesian product of the state spaces of spec and impl in a way comparable to conventional model checking. therefore, until now, fdr has followed the explicit model checking approach. there has been, however, some work on the symbolic model checking of csp [py96, slds08]. 1 / 15 volume 23 (2009) faster fdr counterexample generation using sat-solving this paper reports our attempts to integrate sat-based bounded model checking [bccz99] into fdr. we show how the same internal structures used in fdr’s two-level representation of state spaces can be translated readily into boolean logic. within the scope of this paper, we only consider the translation of trace refinement to sat checking. the result is a prototype tool symfdr which, when combined with state-of-the-art satsolvers such as minisat [es03a, eb05], sometimes outperforms fdr by a significant margin when finding counterexamples. we compare the performance of symfdr with the performance of fdr, fdr used in a non-standard way, pat [sld08] and, in some cases, nusmv [ccg+02], alloy analyzer [jac06] and straight sat encodings of the problems under consideration. the remainder of the paper is organised as follows. in section 2, we set out the necessary background on csp and fdr’s two-level strategy for performing refinement checks. we briefly describe the ideas underlying bmc. in section 3, we show how to adapt the watchdog approach [rgm+03] to bmc, while in section 4, we summarise the methods we use to translate fdr’s supercombinator representation of a state machine into input for a sat-solver. section 5 gives details of how symfdr is built on top of this, and section 6 offers experimental comparisons. 2 preliminaries 2.1 csp and fdr in this section, we assume that the reader is familiar with csp and we therefore give only a brief overview of csp and fdr. the interested reader is referred to [ros98]. furthermore, we restrict our focus exclusively to the traces model, intentionally omitting information about other more expressive models of csp. 2.1.1 csp syntax in this section, we recall the core syntax of csp. let σ be a finite alphabet of (visible) events with τ, x 6∈ σ. the internal action τ occurs silently and is invisible outside a process. x denotes a successful termination of a process. in what follows, we assume that a ∈ σ, a ⊆ σ and b ⊆ σ x = σ∪{x}. r ⊆ σ×σ denotes a renaming relation on σ. definition 1 a csp process is defined recursively via the following grammar: p := st op | skip | div | x : a → p(x) | p1�p2 | p1 up2 | p1|| b p2 | p1; p2 | p\a | pjrk | µ p•f(p) cspm converts core csp into an ascii form and adds several further operators and an extensive functional language. symfdr supports the full cspm syntax, except that it cannot at present handle scripts using the function chase. 2.1.2 denotational semantics csp supports a hierarchy of several denotational semantic models. each of them describes a process in terms of the observable behaviours it can exhibit. all denotational models are proc. avocs 2009 2 / 15 eceasst compositional in the sense that the denotational value of each process can be computed in terms of the denotational values of its subcomponents. in the traces model, a process p is identified with the set of its finite traces, denoted by traces(p). intuitively, a trace of a process is a sequence of visible actions that the process can perform. the set of traces of a process is non-empty and prefix-closed. there are two different approaches for obtaining the set traces(p) — either by constructing it inductively from the traces of its subcomponents, or by extracting it from the operational semantics. refer to [ros98] for the rules underlying the first approach. since denotational values of processes are rather complex and often infinite, fdr calculates the behaviours of a process from its standard operational representation which is justified by semantic models being congruent to it. the congruence theorems are presented and proven in [ros98]. 2.1.3 operational semantics the operational semantics models csp processes as labelled transition systems (lts’s), with nodes denoting processes and labels denoting visible or τ actions. since the lts representation is not unique, in terms of the operational semantics, two processes are considered equivalent if they are strongly bisimilar [ros98]. the operational semantics is calculated by repeatedly applying a set of inference rules, called firing rules. firing rules provide recipes for constructing an lts out of a csp description of a process. the recipes define how processes can evolve by calculating the initial actions available at each node and the possible results after performing each action. the reader is referred to [ros98] for more information. extracting behaviours from operational semantics. we now present how behaviours, in our case – traces, can be retrieved from the operational semantics of a process. formally, a labelled transition system is a quadruple m = 〈s, s0, l, t〉, where s is a finite set of states, s0 ∈ s is the initial state, l is a finite set of labels, t ⊆ s×l×s is the transition relation. for convenience, we write s l→ s′ instead of (s, l, s′) ∈ t . furthermore, we write s l→ if there exists s′ ∈ s, such that s l→ s′. for s ∈ s and l ∈ l, we define post(s, l) = {s′ ∈ s|s l→ s′} — the set of direct l-successors of s. m is then is deterministic if, for any s ∈ s and l ∈ l, |post(s, l)|≤ 1. an execution of m is a finite or an infinite alternating sequence of states and events π = s0l1s1l2 . . . lnsn . . . such that s0 is the initial state and for all i, si li+1→ si+1. let p be a finite-state process and osp = 〈sp, sp0 , l p = στ,x, t p〉 be the lts underlying the operational semantics of p. we denote by αp the set of all visible events that p can perform, i.e. αp = σx. we write σ∗x to denote the set of finite words over σ which might end with x, and similarly, (στ )∗x. for p, q ∈ sp, we use the following notation: • initials(p) = {l ∈ σx|p l→}, i.e. initials(p) is the set of visible events that can be communicated from the state p. • for t = 〈xi|0 ≤ i < n〉 ∈ (στ )∗x, we write p t7−→ q if there exists a sequence of states p0, p1, . . . , pn, such that p0 = p, pn = q and pk xk→ pk+1 for k ∈{0, . . . , n−1}. • for t ∈ σ∗x, we write p t=⇒ q if there exists t′ ∈ (στ )∗x, such that p t ′ 7−→ q and t = t′ � σx, i.e. t is t′ with all the τ ’s removed. then, we define traces(p) = {t ∈ σ∗x|∃q ∈ sp.sp0 t =⇒ q}. 3 / 15 volume 23 (2009) faster fdr counterexample generation using sat-solving the two-level approach. in fact, fdr exploits a hybrid high-/lowlevel approach for calculating the operational semantics of a process [ros08]. generally, the low level comprises all true recursions, the high level – processes composed by parallel composition, hiding and renaming, although the dividing line is a bit more complex. for each process compiled on the low level, an explicit lts is produced, following the firing rules. compiling on the high-level is called supercompiling. it is based on calculating a set of rules for turning a combination of lts’s into a single lts, without explicitly constructing it. for most practical examples, the result of supercompilation is a high-level structure. the high-level structure consists of two parts. the first one is a process tree with leaves – low-level compiled lts’s, and internal nodes – csp operators such as hiding, renaming or parallel composition. each node, even if internal, represents a process and is interpreted as an lts with its behaviours deducible from the behaviours of its children on-the-fly. the second part of the high-level structure is a set of rules mapping actions of a number of leaf processes to an event-outcome of the composite root process [ros98]. those rules are called supercombinators. in what follows, we use the notions of supercombinators and rules interchangeably. within a supercombinator, each process can participate with a visible event, a silent action τ , or not be involved at all. the supercompiler generates the following types of rules [ros98, rrs+01]: • a rule for a leaf willing to perform a τ which promotes a τ action of the root process • rules using visible actions note that the visible actions that the leaf processes perform need not be the same if hiding or renaming is involved in the combination being modelled. for example, if p = a → p and q = b → q, then if p performs a and q performs b, p || {a} qja/bk can perform a, where qja/bk is the process q with the event b being renamed to a. hence, (a, b, a) is a valid rule for the root process p || {a} qja/bk with leaves p and q: the first two elements of the rule triple represent the actions of p and q, respectively, the last element provides the event-outcome of p || {a} qja/bk . in fdr, at every particular step the leaf processes can be either switched on or switched off. processes are switched on if they are currently under a csp operator that makes their actions immediately relevant for the action of the overall system. processes are switched off if they are under a csp operator that does not need their actions to deduce the resulting action of the system. for instance, in p1|||p2, both p1 and p2 are switched on. in p1; p2, p2 is switched off until p1 performs x. in a→(p1|||p2), both p1 and p2 are initially switched off until a is communicated. we refer to the different configurations of switched on and switched off leaf processes as formats. in the worst case, there could be exponentially many different formats, but in practice this is rarely the case. in fdr, the set of supercombinators is partitioned with respect to the existing formats. hence, supercombinators can be viewed as dynamic or static, depending on whether they switch the system to another format after being triggered or not. a state of the root high-level process, also called a configuration, is a tuple of the current states of its leaf processes. when running the root process, fdr computes its initial actions by checking which supercombinators are enabled from the current configuration and the current format of the root. a supercombinator might be disabled if not all leaf processes are able to communicate the event they are responsible for within the supercombinator. hence, the operational semantics proc. avocs 2009 4 / 15 eceasst ��?>=<89:;s0 τ ~~}} }} }} }} } τ aa aa aa aa a ?>=<89:;s1 a -?>=<89:;s2 (a) lt sp ��?>=<89:;s0 b jj (b) lt sq || �� !! bb bb bb bb b p ja/bk �� q (c) the root process r figure 1: example os of the root can be considered an implicit lts, whose transitions can be switched on and off. the states are represented by a pair of a configuration and a format of the root. transitions are modelled by supercombinators. we formalise these notions when describing our boolean encoding of csp processes. in this section, we illustrate the two-level approach with a small example. example 1 let us consider the process r = p || {a} qja/bk, where p = a → p u st op and q = b → q. the process tree of r is presented on figure 2(c). the explicit lts machines underlying the semantics of the leaves p and q are depicted on figure 2(a) and figure 2(b), respectively. the root process r contains a single format with two rules — one rule stating that if p performs τ then the entire system performs τ and another rule stating that if p performs a and q performs b, r can perform a. 2.1.4 refinement checking given two csp processes spec and impl, the refinement check spec v impl reduces to checking for reverse containment of possible behaviours. for the traces model, spec vt impl iff traces(impl) ⊆ traces(spec). we briefly outline how fdr carries out the refinement check. let osspec = 〈ss, ss0, l s, t s〉 and osimpl = 〈si, si0, l i, t i〉 be the labelled transition systems representing the operational semantics of spec and impl, respectively. as a preprocessing step, fdr normalises osspec, so that osspec reaches a unique state after any trace. the normalisation procedure requires as a precondition that osspec be explicated and therefore s pec sequentialised. essentially, the normalisation procedure transforms osspec into the unique equivalent τ -free deterministic lts with the fewest possible states (bisimulation-reduced). after normalising osspec, fdr traverses the cartesian product of osspec and osimpl in a breadth-first manner, checking for compatibility of mutually-reachable states. for the traces model, a pair of states (ss, si) is compatible, if initials(si) ⊆ initials(ss). 2.2 bounded model checking sat-based bounded model checking [bccz99] is a symbolic model checking technique considered complementary to bdd-based model checking [bcm+92, mcm93]. bounded model checking focuses on searching for counterexamples of bounded length only. 5 / 15 volume 23 (2009) faster fdr counterexample generation using sat-solving the underlying idea is to fix a bound k and to unwind the model for k steps, thus considering behaviours and counterexamples of length at most k. in practice, bmc is conducted iteratively by progressively increasing k until either a counterexample is detected or k reaches a precomputed threshold called completeness threshold [ckos05], which indicates that the model satisfies the specification. it is important to note that without knowing the completeness threshold, the bmc procedure is incomplete. hence, bmc is mostly suitable for detecting bugs, not for verification (proving absence of bugs). sat-based bmc [bccz99] reduces the model checking problem to a propositional satisfiability problem. the idea is to construct a boolean formula which is satisfiable if and only if there is a counterexample of length k. this formula is fed into a sat-solver which decides the model checking problem in question and produces a counterexample, if any. due to the dfs-nature of the sat decision procedure, this technique allows for a fast detection of counterexamples. 3 performing bounded trace refinement in this section, we present our iterative bounded refinement checking algorithm. our approach for establishing trace refinement is based on watchdog transformations [rgm+03]. our objective is the following. we are given two csp processes spec and impl and an integer k. we aim at checking whether spec vkt impl, i.e., whether all executions of the implementation of length at most k agree with the specification. 3.1 preprocessing phase using fdr our implementation is intended as an alternative back-end for fdr, orthogonal to the standard explicit method of performing trace refinement. currently, we use a shared library version of fdr for manipulating csp processes and we mimic fdr up to the point of the final state-space exploration phase. therefore, symfdr reuses fdr’s compiler and supercompiler and the data structures underlying the operational semantics. at present, we use fdr to supercompile and normalise spec and to retrieve ltsspec representing the operational semantics of spec. we assume that the implementation impl comprises the interaction of c sequential processes p1, . . . , pc running in parallel, possibly using hiding and renaming. we write impl = p1||p2 . . .||pc to denote a high-level process impl with leaf processes p1, . . . , pc. we use fdr to supercompile impl and to retrieve both the set of supercombinators and the set {ltspi|i ∈{1, . . . , c}}. 3.2 watchdog refinement checking algorithm in a nutshell, the main steps of our algorithm are the following: 1. we transform spec into a process watchdog which allows the behaviours of both spec and impl. the transformation adds a special state sink to ltsspec and forces all erroneous traces (traces that do not conform with spec) to be directed to sink. 2. we construct a process refinement = watchdog || αimpl∪αspec impl = watchdog || αimpl∪αspec (p1||p2 . . .||pc) proc. avocs 2009 6 / 15 eceasst 3. we check whether watchdog can reach its sink state within k steps of the execution of refinement. the watchdog process. the transformation we apply on spec is performed at the level of ltsspec. we add a state sink and make ltsspec total with respect to the alphabet αspec ∪αimpl. the resulting process watchdog operationally passes through sink whenever executing a trace that is not allowed by spec. we allow an execution of watchdog to contain any number of τ ’s after visiting sink in order to be able to increase the bmc bound by more than 1 at each step. the refinement process. the process refinement = watchdog || αimpl∪αspec (p1||p2 . . .||pc) can be used as an indicator whether impl can behave in a way incompatible with spec. watchdog becomes just one of the sequential leaf processes of refinement. it is evident then that: 1. spec vt impl ⇐⇒ watchdog never reaches its sink state in any execution of refinement 2. all executions of refinement forcing watchdog to pass through its sink state constitute valid counterexamples of the assertion spec vt impl 4 boolean encoding of csp processes in this section we present our encoding of csp processes into boolean formulae. first, we demonstrate how to encode sequential or explicated processes, corresponding to leaf processes in the operational representation. then, we show how to glue together sequential processes with supercombinators to obtain an encoding of a high-level process. in what follows, we call a high-level process a concurrent system. for the boolean encoding we use the following notation. dxe(vars) denotes the boolean encoding of x with respect to the vector(s) of boolean variables vars. 4.1 encoding a sequential process let p be a finite-state process with alphabet of events σ. let osp = 〈s, s0, l = στ,x, t〉 be the lts representing the operational semantics of p. encoding the set of states. the basic idea is to enumerate the states in binary and represent them as boolean functions. each state s ∈ s is identified by a bit vector b = (b1, . . . , bn) of size n = dlog2 |s|e using an injective encoding encs : s →{0, 1} n . we introduce an ordered vector of n distinct boolean variables x = (x1, ..., xn). each variable xi uniquely identifies its corresponding bit bi and, for each s ∈ s, dse(x)|x=b = 1 iff encs(s) = b. we define die(x) = ds0e(x). encoding the set of labels. using the same technique, we introduce an ordered vector y = (y1, ..., ym) of m = dlog2 |l|e distinct boolean variables for encoding the set of labels l = σ τ,x. encoding the transition relation. in order to represent the transition relation t , we introduce a copy x′ = (x′1, . . . , x ′ n) of x = (x1, . . . , xn). x serves for representing the source states of transitions, x′ – for representing the destination states. then, for t = (ssrc, l, sdest ) ∈ t , dte(x, y, x′) = dssrce(x)∧dle(y)∧dsdeste(x′). for any s ∈ s, we write dse(x′) to denote dse(x)[x′ ← x], i.e. we represent s with respect to the variables x and then substitute the variables x with x′. the encoding of the entire transition relation is the following: dte(x, y, x′) = ∨ t∈tdte(x, y, x′). 7 / 15 volume 23 (2009) faster fdr counterexample generation using sat-solving encoding executions. we can now represent a sequential process p implicitly by the pair of functions 〈dt pe(x, y, x′),dipe(x)〉. for a given integer k, we define paths(p, k) to be the set of all executions s0l1s1l2 . . . lksk of osp of length k. if flattened to traces, paths(p, k) might contain traces of p of size less than k if τ ’s are present in the executions. in order to represent paths(p, k) symbolically, we introduce (k + 1) vectors of n boolean variables x0, x1 . . . xk and k vectors of m boolean variables y1, y2 . . . yk. the vectors x0, x1, . . . , xk represent the states s0, s1, . . . , sk, respectively. likewise, the vectors y1, y2, . . . , yk represent the labels of the corresponding transitions. then dpaths(p, k)e(x0, x1 . . . xk, y1, y2 . . . yk) = dipe(x0)∧ ∧k−1 i=0 dt pe(xi, yi+1, xi+1). 4.2 encoding a concurrent system since a high-level root process can be modelled as an lts, we now show how to encode a concurrent system similarly to a low-level sequential process. a concurrent system is a set of processes running in parallel possibly using renaming and hiding. we denote by sys(c) the interaction of c sequential processes p1, ..., pc communicating over sets of events σ1, ...., σc, respectively. let σ = ∪ci=1σi, m = dlog2 |σ τ,x|e. encoding the sequential processes. for i ∈{1, ..., c}, let opi = 〈si, si0, l i = στ,xi , t i〉 be the lts representing the operational semantics of pi. since σi ⊆ σ, we actually consider li = στ,x. for each process pi, let ni = dlog2 |s i|e. in order to represent si and the transition relation t i, we introduce two copies of ni boolean variables xi = (xi1, ..., x i ni ) and x i′ = (xi ′ 1 , ..., x i′ ni ). the construction of dt ie(xi, yi, xi′) and diie(xi) follows the ideas from section 4.1. as illustrated in section 4.1, for each process pi we introduce a vector of m boolean variables yi = (yi1, ..., y i m) for encoding the set l i = στ,x symbolically. thus, each process has its own set of variables for representing the alphabet στ,x. we introduce an additional vector of boolean variables y = (y1, ..., ym) for encoding the resulting action of the entire system. encoding states (configurations) of the overall system. recall that a concurrent system consists of multiple sequential processes running in parallel. a state of the entire system, also called a configuration, is identified by the current states of its sequential components. formally, the set of states of the system is a c-ary relation s ⊆ s1 × ...×sc, the initial state being s0 = (s10, ..., s c 0). therefore, s can be represented symbolically using the boolean variables from x1, ..., xc. if s = (s1, ..., sc) ∈ s, then dse(x1, ..., xc) = ∧c i=1(dsie(xi)). for clarity, we denote the set of states of the overall system by configurations. supercombinators and formats. as we mentioned in section 2.1.3, supercombinators are rules for combining together actions of the individual sequential processes into event-outcomes of the overall system [ros98]. within a supercombinator, each process can participate with a visible event, a silent action τ , or not be involved at all. we denote the non-involvement with the symbol ε . for any alphabet σ, we let σε = σ∪{ε}. in addition, the set of supercombinators is partitioned into existing formats, i.e., different configurations of switched on and switched off processes among p1, . . . , pc. we denote by sc the set of supercombinators and by formats the set of formats of the concurrent system. formally, the set of supercombinators can be represented as a (c + 3)-ary relation sc ⊆ formats×στ,x,ε1 ×...×σ τ,x,ε c ×στ,x×formats, or more generally sc ⊆ formats×(στ,x,ε )c × σ τ,x×formats. ( fsrc, a1, ..., ac, a, fdest )∈ sc iff from a certain configuration and a certain format proc. avocs 2009 8 / 15 eceasst fsrc of the overall system, p1 performs a1, ..., pc performs ac and the overall system performs a switching to a format fdest . the operational semantics of the concurrent system can be considered an implicit lts, whose transitions can be switched on and off: • set of states – formats×configurations • set of labels – sc • transition relation – t ⊆ (formats×configurations)×sc×(formats×configurations). if the system is in a given configuration and in a given format, the individual processes transition relations determine if the labels are switched on or off. formally, ( fi, (s1i , . . . , s c i )) ( fi,a1,...,ac,a, f j )→ ( f j, (s1j , . . . , s c j)) iff ( fi, a1, . . . , ac, a, f j) ∈ sc∧∀ck=1((ak 6= ε ⇒ (s k i , ak, s k j) ∈ t k)∧(ak == ε ⇒ ski = s k j)). encoding supercombinators. for a given supercombinator sc = ( fsrc, a1, ..., ac, a, fdest )∈ sc, let passive(sc) = {i ∈{1,··· , c}|ai = ε , i.e. pi is not involved in sc}. let u = (u1, ..., uc) be a vector of (supercombinator-independent) boolean variables. we denote: lit(ui) = { ui if pi is not involved ¬ui if pi performs a visible event or a τ note that a process might be switched on in a format and still be passive in a certain supercombinator in this format. hence, we cannot use the format to conclude which processes are passive in a supercombinator. let f and f ′ be two vectors of dlog2|formats|e variables for encoding the source and destination format of a rule. let sc = ( fsrc, a1, ..., ac, a, fdest ) ∈ sc. then, dsce(y1, ..., yc, y, u, f , f ′) =∧ i /∈passive(sc)(daie(yi)∧¬ui) ∧ ∧ i∈passive(sc) ui ∧dae(y)∧d fsrce( f )∧d fdeste( f ′). hence, in an encoding of a supercombinator, we indicate a passive process pi just by affirming a single boolean variable ui. we call ui a trigger. for non-passive processes, we also encode the event that the process performs. the encoding of all supercombinators in all formats now becomes the following: dsce(y1, ..., yc, y, u, f , f ′) = ∨ sc∈scdsce(y1, ..., yc, y, u, f , f ′). encoding a transition of the concurrent system. let for i ∈{1,··· , c}, ψi(xi, xi ′ , yi, ui) := if ui then (xi = xi ′) else dt ie(xi, yi, xi′), where xi = xi′ is the short for ∧ni j=1(x i j ⇔ x i′ j ). the intuition behind a ψi is that, if pi does not participate in a transition of the entire system, i.e. pi is not involved in a supercombinator, pi remains in the same state within its own labelled transition system opi. otherwise, pi progresses with respect to its transition relation t i. expressed as a boolean formula, ψi ≡ (ui ∧(xi = xi ′))∨(¬ui ∧dt ie(xi, yi, xi ′)). we define a predicate t sys(c) which is true exactly for the transitions of the overall system: dt sys(c)e(x1,··· , xc, x1′,··· , xc′, y1,··· , yc, y, u, f , f ′) = = ∧c i=1 ψi(xi, xi ′ , yi, ui)∧dsce(y1,··· , yc, y, u, f , f ′) encoding fixed length executions of the concurrent system. within the bmc framework, let k be the maximal bound for the length of the counterexamples we are looking for. then: 9 / 15 volume 23 (2009) faster fdr counterexample generation using sat-solving dpaths(sys(c), k)e( // variables for p1 x10, . . . , x 1 k , y 1 1, . . . , y 1 k , u 1 1, . . . , u 1 k // variables for p2 x20, . . . , x 2 k , y 2 1, . . . , y 2 k , u 2 1, . . . , u 2 k . . . . . . // variables for pc xc0, . . . , x c k, y c 1, . . . , y c k, u c 1, . . . , u c k // variables for the traces of the system y1, . . . , yk, // variables for the formats in the rules f0, . . . , fk) = // processes start from their initial states and the initial format is format[0]∧c j=1di je(x j 0) ∧di fe( f0) ∧ // supercombinators as transitions at each of the k steps∧k i=1dsce(y1i , . . . , y c i , yi, u 1 i , . . . , u c i , fi−1, fi) ∧ // the idea of the ψ formulas – either transitions or wait, depending on supercombinators∧ j=1,...,c i=1,...,k ((u ji ∧(x j i−1 = x j i ))∨(¬u j i ∧dt je(x ji−1, y j i , x j i ))) = disys(c)e(x10, . . . , x c 0, f0)∧∧k i=1dt sys(c)e(x1i−1, . . . , x c i−1, x 1 i , . . . , x c i , y 1 i , . . . , y c i , yi, u 1 i , . . . , u c i , fi−1, fi) 5 implementation details in the original version of bmc, the system is unwound step by step until the bound k is reached. despite the recent advances in sat-solvers’ learning capabilities and incremental sat-solving, we have observed that the bottleneck of the bounded refinement procedure is the sat-solver. therefore, we allow unfolding a configurable number i of steps of the process refinement before running the sat-solver. the sat-solver is then used to check if refinement can pass through the sink state in any of its last i unwindings. if yes, we have found a counterexample, otherwise we continue iterating until reaching the configured bound k. we refer to the value of i as satfrequency. we believe that this multi-step approach works well because the sat-solver typically finds it much easier to find a satisfying assignment, if there is any, than to prove unsatisfiability, given cnf formulas with comparable size and structure. we transform the boolean formulae into equisatisfiable formulas in cnf using the tseitin encoding [bkww08]. for brevity, we skip details about how we exploit the incremental satinterface. currently, symfdr supports minisat (version 2.0), picosat and zchaff. for our test cases, we have found minisat to be most efficient and all quoted results use minisat. for our larger test cases, we also observed that minisat finds a counterexample faster if we configure it to keep a smaller number of learned clauses and to restart more frequently. we also implemented adding unit learned clauses explicitly, as suggested in [es03a]. using positive polarity in decision heuristics also produced much better results. the current implementation of symfdr supports refinement checking systems with a single format only. however, we do not anticipate any problems generalising the problem to a multiformat setting. moreover, most practical cases are also single-format. in addition to the standard refinement check, symfdr also supports the ”zig-zag” temporal induction algorithm [es03b], which makes bmc complete. however, due to concurrency, the proc. avocs 2009 10 / 15 eceasst recurrence diameter is too big. some other approaches that did not scale well include exploiting unary rather than binary encoding, restricting the decision variables to the input ones [sht00], incorporating picosat’s restarting scheme and phase saving strategy [bie08] in minisat, etc. 6 experimental results in this section, we investigate the performance of symfdr on a small number of case studies. we compare it to the performance of fdr, fdr used in a non-standard way, pat [sld08], and, in some cases, direct sat encodings, nusmv [ccg+02] and alloy analyzer [jac06]. all sat-based experiments use minisat although symfdr and the direct sat encoder build upon minisat version 2.0, while alloy and nusmv exploit the earlier version 1.14. all tests were performed on a 2.6 ghz pc with 2 mb ram running linux, except the test marked with a ∗, which was performed on a 4-mb-ram pc running linux, and the tests with pat, which were performed on a 1.67 ghz pc with 2 mb ram running windows. the results are summarised in table 1, table 2 and table 3. the last column titled ] lists the length of counterexamples. fdr-div. the main search strategy for fdr is bfs [ros94] because this has the combined advantages of always finding a shortest counterexample and of enabling implementations that work comparatively well on virtual memory. however, the strategy for discovering divergences is based on dfs. in test cases where it is likely that there are a good number of counterexamples, but that all of them occur comparatively deep in the bfs, there is good reason to use a bounded dfs (bdfs) algorithm to search for them, so that only error states reachable in less than some fixed number n of steps are reached. bdfs will quickly get to the depth where counterexamples are expected without needing to enumerate all of the levels where they are not. provided that the counterexamples have something like a uniform distribution through the order in which the dfs discovers them, we can expect one to be found after searching through approximately s/(c + 1) states, where s is the total number of states and c is the number of counterexamples. fdr does not implement such a strategy directly. it was, however, observed a number of years ago by roscoe and james heather that it is possible to use a trick that achieves the same effect using the present version of the tool. that is, arrange (perhaps using a watchdog) a system p′ that performs only up to n events of the target implementation process p and then performs an infinite number of some indicator event when a trace specification is breached. provided p is itself divergence-free, we then have that p′\σ can diverge precisely when p violates the specification. fdr searches for this divergence by dfs. this approach is particularly well suited to csp codings of puzzles, since it is frequently known ab initio how long a counterexample will be, and the usual csp coding uses the repeatable event done to indicate that the puzzle has been solved. the columns labelled fdr-div in table 1 and table 2 report on the result of using this technique. in several ways this method is more similar to approach of pat and symfdr than the usual fdr approach. as is apparent from the experiments, there seems to be a large element of luck in how fast this approach is, possibly based on how close the path followed by the dfs is to a counterexample. pat. pat [sld08] is a model checker of a version of csp enhanced with shared variables. despite the bmc attempt [slds08], pat is at present a fully explicit checker. in addition to ltl model checking, pat supports csp refinement checking which it performs in a way similar 11 / 15 volume 23 (2009) faster fdr counterexample generation using sat-solving to fdr although using dfs (instead of bfs), normalisation of the specification on-the-fly and partial-order reductions. in the test cases quoted here, the specification is given as a reachability property on the values of the shared variables. the reachability algorithm is based on dfs and state hashing is applied for compact state-space representation. nusmv. nusmv [ccg+02] is a symbolic model checker verifying smv against ctl properties using bdds. the bmc framework of nusmv, which we refer to as nusmv-bmc, uses specifications written in ltl. alloy analyzer. alloy analyzer [jac06] is a fully-automatic tool for finding models of software systems designed in the lightweight alloy modelling language. alloy analyzer could be considered a bmc checker due to its searching for a model only up to a certain scope and generating the model, if existing, using sat-solving techniques. direct sat encodings. we believe that experimenting with direct sat encodings of problems will offer guidance for optimising the translation of csp to logic. for example, the chess knight test case suggests that a shorter chain of inference for high-level actions might be beneficial. test cases. first, we consider the peg solitaire puzzle [ros98], performing experiments on a chain of soluble boards with increasing level of difficulty. in the initial configuration, the board has all slots but one occupied by pegs. the only allowed move in the game is a peg hopping over another peg and landing on an empty slot. the hopped over peg is then removed from the board. the objective of the game is ending up with a board with a single peg positioned on the slot which had been initially empty. the length of any solution of the puzzle is equal exactly to the number n of pegs on the initial board — a hop event for (n−1) pegs followed by an event done signifying a valid solution of the puzzle. the results are summarised in table 1. the experiments indicate that for n ≥ 26 symfdr clearly outperforms fdr. in cases where a counterexample does not exist, fdr’s bfs strategy outperforms the dfs-based tools pat and symfdr. our second test case is the chess knight tour. a knight is placed at position (1, 1) on an empty chess board of size n ×n. the objective is covering all squares of the board by visiting each square exactly once. similarly to peg solitaire, a solution is generated as a counterexample to a specification asserting that the event done is never communicated. the length of a possible solution is n2 + 1. the results are presented in table 2. for n = 5, fdr generates a counterexample faster, but for n = 6 already, symfdr found a solution in approximately 13 minutes, while fdr crashed after an hour and a half of state-space exploration. the third test case — the classical puzzle of towers of hanoi, aims primarily at comparing symfdr with other sat-based bounded checkers such as nusmv and alloy analyzer. the results are summarised in table 3. nusmv-bmc and symfdr seem to be competitive, both outperforming alloy analyzer. however, all non-sat tools — fdr, pat and nusmv — are clearly orders of magnitudes more efficient than the sat-based ones. we can conclude that symfdr is likely to outperform fdr in large combinatorial problems for which a solution exists, the length of the longest solution is relatively short (growing at most polynomially) and is predictable in advance. in those cases, we can fix the sat-frequency close to a sizeable divisor of this length and thus spare large sat overhead. the search space of those problems can be characterised as very wide (with respect to bfs), but relatively shallow — with counterexamples with length up to approximately 50–60. we suspect that problems with multiple solutions also induce good sat performance. the experiments with the towers of hanoi suggest that sat-solving techniques offer advantages up to a certain threshold and weaken afterwards. proc. avocs 2009 12 / 15 eceasst table 1: performance comparison – peg solitaire (] = n) n fdr time (sec.) sat ] ] states fdr fdr pat symfdr symfdr freq. checked -div sat total 20 41 703 0 0 6.14 6.92 10.23 10 20 10.82 14.06 20 23 411 976 5 0 2.16 11.21 16.72 12 23 6.62 12.33 23 26 4 048 216 72 0 7.23 27.73 35.16 13 26 15.39 24.66 26 29 28 249 254 581 1 89.93 54.29 65.39 15 29 39.33 49.61 29 32 > 139 000 000 > 11 700 5 8.91 175.05 189.20 16 32 187 000 000∗ 2 640∗ 172.56 186.61 32 35 — — 1 485 399 529.88 548.80 18 35 291.59 309.94 35 38 — — 43 1773.19 1 047.01 1 071.59 19 38 41 — — 4 198.77 1 584.62 1 617.09 41 41 table 2: performance comparison – chess knight tour (] = n2 + 1) n fdr time (sec.) sat ] ] states fdr fdr pat direct symfdr symfdr freq. checked -div sat sat total 5 508 451 3 0.147 0.28 8.5 6.26 8.81 13 26 13.47 16.46 26 6 > 120 000 000 > 4 800 18 9.75 125.3 777.41 785.67 19 37 7 — — — 6.41 1 138 30 515.6 30 544.5 50 50 7 conclusions and future work in this paper we have demonstrated the feasibility of integrating a bounded refinement checker in fdr, and more specifically, exchanging the expensive explicit state-space traversal phase in fdr by a sat check in symfdr. on some test cases, such as complex combinatorial problems, symfdr’s performance is very encouraging, coping with problems that are beyond fdr’s capabilities. in general, though, fdr usually outperforms symfdr, particularly when a counterexample does not exist. we plan to further investigate and try to gain insight about the classes of problems that are tackled more successfully within the bmc framework. we envision several directions for future work. we plan to extend the bmc framework in symfdr to make it applicable to the stable failures and failures-divergences models as well. this will involve extending the encoding of csp processes with information about maximal refusals and divergences. 13 / 15 volume 23 (2009) faster fdr counterexample generation using sat-solving table 3: performance comparison – hanoi towers (] = 2n ) n time (sec.) sat ] fdr pat nusmv symfdr alloy nusmv-bmc freq. 5 0.198 0.64 0.43 4.92 11.53 2.157 16 32 6 0.202 2.89 0.66 27.26 327.37 34.910 32 64 7 0.164 5.01 0.171 182.68 21 537.27 1 864.75 64 128 8 0.182 27.76 0.292 3 114.05 — 2 218.23 128 256 we intend to implement mcmillan’s algorithm combining sat and interpolation techniques to yield complete unbounded refinement checking [mcm03]. this method has proven to be more efficient for positive bmc instances (instances with no counterexamples) than other sat approaches. the completeness threshold in this case is the reverse depth of the state-space which is smaller than its recurrence diameter, as is the case with temporal induction [es03b]. moreover, experimental results have shown that, in practice, the algorithm often converges substantially faster, for bounds considerably smaller than the reverse depth. in addition, the interpolation algorithm allows jumping multiple time frames at once and hence allows tuning the sat-frequency. the bmc framework presented in this paper will be the foundation to build upon. other avenues for further enhancing fdr’s performance include partial-order reductions [pel98] and cegar [coyc03, cco+05]. acknowledgements: we are grateful to d. kroening and j. worrell for their comments and p. armstrong for his help with fdr. the analysis using dfs refinement through divergence checking was inspired by a correspondence several years ago between a. w. roscoe and j. heather. the work presented in this paper is supported by grants from epsrc and us onr. bibliography [bccz99] a. biere, a. cimatti, e. m. clarke, y. zhu. symbolic model checking without bdds. in tacas ’99: proceedings of the 5th international conference on tools and algorithms for construction and analysis of systems. pp. 193–207. springer-verlag, london, uk, 1999. [bcm+92] j. r. burch, e. m. clarke, k. l. mcmillan, d. l. dill, l. j. hwang. symbolic model checking: 1020 states and beyond. inf. comput. 98(2):142–170, 1992. [bie08] a. biere. picosat essentials. jsat 4(2-4):75–97, 2008. [bkww08] a. biere, d. kroening, g. weissenbacher, c. wintersteiger. digitaltechnik. springer, 2008. [ccg+02] a. cimatti, e. clarke, e. giunchiglia, f. giunchiglia, m. pistore, m. roveri, r. sebastiani, a. tacchella. nusmv version 2: an opensource tool for symbolic model checking. in proc. international conference on computer-aided verification (cav 2002). lncs 2404. springer, copenhagen, denmark, july 2002. [cco+05] s. chaki, e. m. clarke, j. ouaknine, n. sharygina, n. sinha. concurrent software verification with states, events, and deadlocks. formal aspects of computing 17(4), 2005. proc. avocs 2009 14 / 15 eceasst [ckos05] e. clarke, d. kroening, j. ouaknine, o. strichman. computational challenges in bounded model checking. software tools for technology transfer (sttt) 7(2):174–183, april 2005. [coyc03] s. chaki, j. ouaknine, k. yorav, e. m. clarke. automated compositional abstraction refinement for concurrent c programs: a two-level approach. in proc. softmc 03. 2003. [eb05] n. een, a. biere. effective preprocessing in sat through variable and clause elimination. in in proc. sat05, volume 3569 of lncs. pp. 61–75. springer, 2005. [es03a] n. een, n. sorensson. an extensible sat-solver. in sat. 2003. [es03b] n. een, n. sorensson. temporal induction by incremental sat-solving. in proceedings of first international workshop on bounded model checking. entcs 4. 2003. [g+05] m. goldsmith et al. failures-divergence refinement. fdr2 user manual. formal systems (europe) ltd., june 2005. doi:http://www.fsel.com/documentation/fdr2/fdr2manual.pdf [hoa85] c. a. r. hoare. communicating sequential processes. communications of the acm 21:666–677, 1985. [jac06] d. jackson. software abstractions: logic, language, and analysis. the mit press, 2006. [mcm93] k. l. mcmillan. symbolic model checking: an approach to the state explosion problem. phd thesis, cmu, 1993. [mcm03] k. l. mcmillan. interpolation and sat-based model checking. in cav. pp. 1–13. 2003. [pel98] d. peled. ten years of partial order reduction. in cav ’98: proc. 10th international conference on computer aided verification. pp. 17–28. springer-verlag, london, uk, 1998. [py96] a. parashkevov, j. yantchev. arc a tool for efficient refinement and equivalence checking for csp. in ieee 2nd international conference on algorithm and architectures for parallel processing. 1996. [rgm+03] a. w. roscoe, m. goldsmith, n. moffat, t. whitworth, i. zakiuddin. watchdog transformations for property-oriented model checking. in proceedings of fme 2003. 2003. http://web.comlab.ox.ac.uk/oucl/work/bill.roscoe/publications/91.pdf [ros94] a. w. roscoe. model-checking csp. chapter 21. prentice-hall, 1994. http://web.comlab.ox.ac.uk/oucl/work/bill.roscoe/publications/50.ps [ros98] a. w. roscoe. the theory and practice of concurrency. prentice hall, 1998. http://web.comlab.ox.ac.uk/oucl/work/bill.roscoe/publications/68b.pdf [ros08] a. w. roscoe. lecture notes for the course advanced concurrency tools. oxford university computing laboratory 2008. [rrs+01] a. w. roscoe, p. ryan, s. schneider, m. goldsmith, g. lowe. the modelling and analysis of security protocols. addison-wesley, 2001. [sht00] o. shtrichman. tuning sat checkers for bounded model checking. in cav ’00: proceedings of the 12th international conference on computer aided verification. pp. 480–494. springer-verlag, london, uk, 2000. [sld08] j. sun, y. liu, j. s. dong. model checking csp revisited: introducing a process analysis toolkit. in isola. pp. 307–322. 2008. [slds08] j. sun, y. liu, j. s. dong, j. sun. bounded model checking of compositional processes. in proceedings of the second ieee international symposium on theoretical aspects of software engineering. pp. 23–30. ieee, 2008. 15 / 15 volume 23 (2009) http://dx.doi.org/http://www.fsel.com/documentation/fdr2/fdr2manual.pdf http://web.comlab.ox.ac.uk/oucl/work/bill.roscoe/publications/91.pdf http://web.comlab.ox.ac.uk/oucl/work/bill.roscoe/publications/50.ps http://web.comlab.ox.ac.uk/oucl/work/bill.roscoe/publications/68b.pdf introduction preliminaries csp and fdr csp syntax denotational semantics operational semantics refinement checking bounded model checking performing bounded trace refinement preprocessing phase using fdr watchdog refinement checking algorithm boolean encoding of csp processes encoding a sequential process encoding a concurrent system implementation details experimental results conclusions and future work towards transformation rule composition electronic communications of the easst volume 42 (2011) proceedings of the 4th international workshop on multi-paradigm modeling (mpm 2010) towards transformation rule composition mark asztalos, eugene syriani, manuel wimmer and marouane kessentini 13 pages guest editors: vasco amaral, hans vangheluwe, cécile hardebolle, lazlo lengyel managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst towards transformation rule composition mark asztalos1, eugene syriani2, manuel wimmer3 and marouane kessentini4 1 budapest university of technology and economics, budapest 1111, hungary asztalos@aut.bme.hu 2 mcgill university, montréal, québec, canada h3a 2a7 esyria@cs.mcgill.ca 3 vienna university of technology, 1040 wien, austria wimmer@big.tuwien.ac.at 4 diro, université de montréal, montréal, québec, canada h3t 1j4 kessentm@iro.umontreal.ca abstract: many model transformation problems require different intermediate transformation steps. for example, platform-specific models (psm) are often generated from platform-independent models (pim) by chains of model transformations. this requires the presence of several intermediate meta-models between those of the pim and the psm. thus, most of the effort is needed to define a transformation mechanism for each intermediate step. the solution proposed in this paper is to investigate whether it is possible to generate a single transformation from a chain of transformations, solely involving the initial pim and final psm meta-models. the presented work focuses on the composition of transformations at the rule level. we apply the automatic procedure for composing rules in the context of the evolution of the enterprise java beans (ejb) language, transforming uml models into ejb 2.0 models and then to ejb 3.0 models. keywords: rule composition, transformation chain, transitive transformation 1 introduction nowadays, software platforms evolve very rapidly. this is also true for modelling languages, which have to reflect the evolution of the underlying platforms. the evolution of a modelling language requires one to adapt its meta-model as well as any model transformation involving it. the task of adapting the transformations to the new version of the language can be very tedious and error prone, especially when this is done manually. let us take the example scenario of generating platform-specific models (psms) from platform-independent models (pims). due to the continuous evolution of the platform, while several versions of the platform-specific metamodel have to be employed, transformations between these meta-model versions are necessary for migrating the psms at version n to psms at version n + 1. these transformations can be also reused within a model transformation chain for transforming a pim over several intermediate meta-models into a psm for the latest platform version. over time, such transformation chains naturally become larger and larger, which has a negative impact on maintainability and execution performance. 1 / 13 volume 42 (2011) mailto:asztalos@aut.bme.hu mailto:esyria@cs.mcgill.ca mailto:wimmer@big.tuwien.ac.at mailto:kessentm@iro.umontreal.ca transformation rule composition the goal of this paper is to reduce the manual effort of shortening transformation chains by eliminating intermediate transformation steps. the presented work proposes to compose a chain of transformations into one transformation that does not involve any intermediary meta-model. in particular, this is done by computing the transitive transformation of two given transformations. in section 2, we first define the composition of transformations in general. section 3 reduces the problem to the composition of rules by (1) elaborating on the criteria for composing graph transformation rules and (2) presenting an automatic procedure to compose such rules into one. in section 4, we illustrate this approach in the context of the evolution of the enterprise java beans (ejb) language, transforming uml models into ejb 2.0 models and then to ejb 3.0 models. section 5 is dedicated to the related work and we conclude in section 6. 2 transformation composition in this section, we define a composition operator to precisely specify the meaning of a transformation composition. this operation is applied in the context of a chain of model transformations as defined below. definition 1 (transformation chain). let tn = 〈t1,t2,...,tn〉n∈n be an ordered sequence of transformations where each ti defines a mapping from a meta-model mi to a different metamodel mi+1. we denote such a transformation chain as m1 t1→m2 t2→m3 t3→ ... tn→mn+1. note that we enforce that all the meta-models involved in the chain tn be different from one another, i.e., each transformation must be exogenous [mv06]. using the previous notation, we call mi the domain of ti and mi+1 its co-domain. the transformation is applied on a model mi conforming to its meta-model mi and results in a new model mi+1 = ti(mi) conforming to its meta-model mi+1. note that transformations, transformation rules, as well as the preand post-condition patterns of the rules are also considered as models conforming to their respective meta-models [kms+10]. the presented approach assumes that each transformation in the chain is specified using algebraic graph transformation rules. the models involved are represented as graph objects in the category of typed attributed graphs as defined in [eept06]. in the remainder of the paper, a model m and its element graph g will be used interchangeably. the typed attributed graph g consists of a set of nodes v (g) and edges e(g), where each node conforms to a specific node type in a type graph (representing m, the meta-model of m) and can hold attribute values. we however require that graph edges be partitioned in two sets e(g) = em(g)∪λ(g), distinguishing trace edges λ(g) from the edges em(g) conforming to those defined in the type graph. a trace edge represents a traceability link connecting any two nodes regardless of their type. while a transformation is applied, traceability links are created such that any newly created element must have at least a traceability link1. definition 2 (transformation composition). let t1 and t2 be two consecutive transformations in a transformation chain such that m1 t1→ m2 t2→ m3. we denote t ′ = t2 •t1 the composed 1 traceability links can be created implicitly such as in [jk06]. otherwise, their creation must be explicitly specified in the rules. proc. mpm 2010 2 / 13 eceasst transformation of t1 with t2, following the composition operator • which satisfies the sequence, elimination, and transitivity criteria as defined below. we describe the application criteria of the composition operator given an arbitrary input model m1 for t1, m2 = t1(m1), and m3 = t2(m2), where m1,m2, and m3 conform to m1,m2, and m3 respectively. we denote m′ = t2 •t1(m1) be the resulting model after the composition. in the case where traceability links are created explicitly in the rules, m̂ represents the graph model isomorphic to m without any trace edge. sequence there shall exist three injective graph morphisms (seqi)i=(1,2,3) that must be defined as: seq1 : m1 → m′, seq2 : m̂3 −m̂2 −m̂1 → m′, and seq3 : m̂′ → m3. seq1 ensures that the input model is preserved. seq2 ensures that all the elements from m3 produced by t2 are present in m′. seq3 ensures that m′ contains no other elements than those found in m3. elimination there should not be any morphism elem : m2 −m̂1 → m′. that is, m′ shall not contain any occurrence of an element from m2. moreover, no traceability links involving elements from m2 shall be present. transitivity we denote by λi j a traceability link (trace edge) between an element from mi and an element from m j. the following predicate must hold: ∃λ12 ∈ λ(m3)∧∃λ23 ∈ λ(m3)⇒ ∃λ13 ∈ λ(m′). this ensures the transitive closure of traceability links, i.e., for any instance element of m2 in m3, if it is connected through trace edges to both an instance element of m1 and an instance element of m3, then m′ must have a trace edge between the latter two instance elements. the sequence criterion ensures soundness and completeness of the composition operator. the elimination criterion ensures that the resulting transformation is independent from any intermediate meta-model. finally, the transitivity criterion ensures that traceability links correctly map the source and target model elements of the composed transformation t ′. the following generalizes the transformation composition definition to an arbitrary number of transformations. definition 3 (transformation chain composition). given the chain tn = 〈t1,t2,...,tn〉n∈n, the composed transformation of tn is a transformation t ′ = tn •(tn−1 •...(t3 •(t2 •t1))...). this can be written in short t ′ = tn •tn−1 • ...•t3 •t2 •t1. 3 rule composition the task of composing two arbitrary transformations is a very complex problem. that is because the choice of which rule from one transformation to compose with a rule from the other transformation often depends on the domain of application. for the scope of this paper, we concentrate on applying the composition operation on two graph transformation rules. in this section, we provide a procedure for composing two individual rules into a single one such that the sequence, elimination, and transitivity criteria are satisfied. 3 / 13 volume 42 (2011) transformation rule composition 3.1 criteria for rule composability in the following, we assume that rewriting rules or productions are defined as presented in [eept06]. this means that a rule p = (l ← k → r) consists of three objects in the category of typed attributed graphs: the left hand side (l), the interface k, and the right hand side (r) objects respectively. in this paper, we assume that each transformation transforms an instance of one metamodel into an instance of another, therefore, the objects l, k, and r may contain elements from both the source and the target metamodel of the current transformation. to apply the composition operator on two individual rules, we assume that each of the transformations involved consists of a single rule for sake of completeness: t1 ={r1} and t2 ={r2}. the procedure assumes that the rules r1 and r2 are monotonically increasing, i.e., they can only create new elements and/or modify attribute values. moreover, all traceability links created during the application of t1 and t2 shall be preserved. the output of the composition procedure is a new transformation t3 = t2 •t1 = {r2}•{r1} = {r3} consisting of a single rule. the following proposition specifies the necessary condition for the composition procedure to satisfy definition 2. proposition 1 (composability condition). two rules r1 = l1 ←k1 →r1 and r2 = l2 ←k2 →r2 satisfy the composability condition if there exists a partial morphism n : l2 → r1 such that: • the domain of n is a subgraph of l2, which consists of all the elements that is from m2, • the co-domain of n is a subgraph of r1 consisting of elements only from m2, • the mapping from the domain to the co-domain of n is a total injective morphism. the formal definition of the traditional composition of two sequential rewriting rules is described in [eept06], this composition is called the e-concurrent production. the definition states that given two rules p1 and p2, then they can be composed into a new rule p = (l,k,r). informally, the p is composed along a new graph object e, which is produced by jointly surjective morphisms from r1—the right-hand side (rhs) of p1—and l2—the left-hand side (lhs) of p2. the application of the new rule is equal with the sequential application of the two original rules. however, there are often more than one possible compositions of the rules, because of the non-determinism of the matches. to satisfy the elimination and transitivity criteria of definition 2, the sub-procedure in algorithm 1 is required: algorithm 1 eliminate(m) 1: for all λ12,λ23 ∈ λ(m) do 2: if trg(λ12) = src(λ23) then 3: create λ13 such that src(λ13) = src(λ12) and trg(λ13) = trg(λ23) 4: λ(m)← λ(m)∪{λ13}−{λ12,λ23} 5: v (m)←v (m)−{trg(λ12)} 6: end if 7: end for 8: for all λ12 ∈ λ(m) do 9: λ(m)← λ(m)−{λ12} 10: v (m)←v (m)−{trg(λ12)} 11: end for proc. mpm 2010 4 / 13 eceasst given a model m, the elimination procedure performs two runs over the trace edges in m. in the first run (lines 1 to 7), it first looks for a trace edge λ12 linking an element conforming to m1, say e1, to an element conforming to m2, say e2 and another trace edge λ23 linking e2 to an element conforming to m3, say e3. it then creates the transitive trace edge λ13, removes the two other traceability edges as well as e2. in the second run, the elimination procedure looks for all remaining trace links involving m1 and m2 elements and removes them from m. note that there cannot be any trace edge in the form λ23 remaining after the first run, since any element from m2 must be linked to an element from m1 by construction. therefore after the elimination procedure terminates, the only remaining trace edges in m link elements from m1 to elements from m3. 3.2 composition procedure let r1 = l1 ← k1 → r1 and r2 = l2 ← k2 → r2 be two rules that satisfy the composability condition of proposition 1. we want to produce the composite rule r3 such that {r3}={r2}•{r1} as defined in section 2. algorithm 2 compose(r1,r2) 1: compute the e-based composition (l3,k3,r3) of r1 and r2 such that e = r1 2: k3 ← r1 3: l3 ← eliminate(l1) 4: r ← φ 5: r′2 ← r2 extended with r2 as a nac, if not present 6: repeat 7: r3 ← apply r′2 exhaustively on e 8: eliminate(r3) 9: r ← r∪{(l3,k3,r3)} 10: until all application sequences of r′2 have been exhausted on e 11: return r algorithm 2 produces the set of all possible compositions of r1 and r2. r2 is extended with a negative application condition (nac) corresponding to its rhs. this ensures that r2 is only applied once on every match found in e. it is worth noting that there can be different r3’s even if r′2 is applied exhaustively on e, if the order of application affects the result. before analyzing the algorithm, we demonstrate its operation on the composition of two simple rules r1 and r2 presented in figure 1. let r′2 be rule r2 extended by the nac which consists of the rhs of r2. by algorithm 2, the e graph is rhs of r1. if we modify r1 by applying r′2 once on its rhs, we get rule r. however, we apply r ′ 2 exhaustively, therefore, rhs of r is modified again, which results in rule r′. note that there are no other possible matches, because of the nac in r′2. the next step is the application of the elimination algorithm, which performs the transitive closure on the trace edges. rhs of r′ is eliminated, which results in rule r′′. the lemmas below validate the composition procedure. lemma 1 ensures that the procedure will output all possible composed rules r3 and lemma 2 ensures its correctness. lemma 1. if r1 and r2 satisfy the composability condition, then compose(r1,r2) outputs all compositions of r1 and r2 such that the exhaustive application of compose(r1,r2) is equivalent to the composition of r1 and r2 using the composition operator of definition 2. 5 / 13 volume 42 (2011) transformation rule composition b1:t2 … a1:t1 a1:t1 t … b:t2 b:t2 c:t3tr1 r2 b2:t2 b1:t2 ’ c:t3t ’’ c:t3b1:t2 c:t3t … a1:t1 a1:t1 b2:t2 tr’ c:t3t … a1:t1 a1:t1 tr’’ c:t3 … a1:t1 a1:t1 b2:t2 tr b2:t2 c:t3t c:t3b2:t2 figure 1: example for rule composition. proof. assume that there is a possible e-based composition r = l ← k → r such that the egraph e 6= r1. this implies that ∃e ∈ e : e /∈ r1 where e can be any type of element in the graph. e is produced by jointly surjective morphisms from r1 and l2; thus e ∈ l2. moreover, e is an element conforming to m2 as it is the domain of r2. however e /∈ r1, which implies that e ∈ l, according to the definition of the e-concurrent production. but l cannot contain elements from m2 because if it did, the input model would contain elements conforming to m2, which is a contradiction. lemma 2. the result of the composition procedure {r3}={r2}•{r1} satisfies definition 2. proof. assume that a model m1 is processed by the transformations t1 and t2 through a possible traditional e-based composition r′3 of the rules r1 and r2. let r3 be a rule computed by applying the elimination procedure on the lhs, rhs, and interface graph of r′3. let t3 = {r3}, m2 = t1(m1), m3 = t2(m2), and m′ = t3(m1). we shall now prove that t3 satisfies the sequence, elimination, and transitivity criteria. • sequence criterion: ∃seq1 : m1 → m′, because l3 = k3 and hence the input model m1 is not modified. ∃seq2 : m̂3−m̂2−m̂1 → m′ as no elements from r′3 have been deleted during the elimination that was performed to produce r3. moreover, ∃seq3 : m̂′ → m3 since r3 contains elements conforming to m3 because of the exhaustive application of r′2. • elimination criterion: m′ does not contain any element from m2 since applying the elimination procedure on r′3 ensures that all elements from the intermediate meta-model are removed from it. • the transitivity criterion is also satisfied because the elimination procedure generates all the traceability links required by the condition. when nacs come into play in r1 or r2, we distinguish the following case: • if there is a nac in r1 and it corresponds to r1, then we extend each composite rule r3 with a nac corresponding to r3. • if there is a nac in r2 and it corresponds to r2, then it is taken into account when applying r2 to e. • any other nac is not considered in the presented procedure. proc. mpm 2010 6 / 13 eceasst 4 application we now apply the composition approach presented in section 3 in the following scenario. a company has developed a transformation t1 for transforming uml class diagrams to enterprise java beans (ejb) 2.0. however, after some time, the company decided to use ejb 3.0 due to several simplifications of the new version of the standard. thus, they developed a transformation t2 for migrating existing ejb 2.0 models to ejb 3.0 models. however, to support the generation of new ejb 3.0 models from uml class diagrams, they would have to implement a dedicated transformation t3, if applying the transformation chain 〈t1,t2〉 is undesired. reasons for this may be related to performance issues for ensuring rapid generation of ejb 3.0 models. also, direct traceability between uml models and ejb 3.0 models is desired since ejb 2.0 instances would become obsolete. 4.1 involved artefacts ejb 3 t d luml metamodel ejb 3 metamodel t3 ? ejb 2 metamodel figure 2: meta-models of the case study. a simplified version of the meta-models and transformation rules for this scenario are illustrated in figures 2 and 3 respectively. t1 transforms packages into ejbarchives and classes into either sessionbeans or entitybeans, depending on the ispersistent attribute, as well as into interfaces. furthermore for each bean, an entry in the deploymentdescriptor has to be generated. the deploymentdescriptor concept is no longer used in ejb 3.0, because no additional xml configuration files for beans are required. instead, a light-weight approach for configuring beans directly in the java code through annotations 7 / 13 volume 42 (2011) transformation rule composition is supported by ejb 3.0. note that given the semantics of this migration, all rules of the transformations are applied exhaustively. the transformations t1 and t2 have been implemented in atl [jk06] and subsequently transformed into graph transformation rules based on emf tiger 2 [bet08]. to adhere to the behaviour of atl, the resulting graph transformation rules have the following properties which also comply to the criteria for rule composition: • matchable elements: atl is designed as a model-to-model transformation language meaning that the target model is completely rebuilt from the source model. thus, the only elements that can be matched by a rule are elements of the source model and elements of the target model already created by previous rule applications. the latter are only accessible via trace edges. • creation and deletion of elements: in atl the source model is considered as read-only, thus elements of this model may not be altered. furthermore, elements of the target model are created by executing the transformation, but once created, they can no longer be deleted by the transformation. • trace model: for each rule execution, a trace element is generated linking all matched source elements to all generated target elements. other transformation rules can build on this trace information, e.g., for adding links to already created target elements. • unique matching: each transformation rule can only match once for a given set of elements. thus, to ensure this behaviour in the graph transformation rules, each rule comprises a nac corresponding to the rhs of the rule3. 4.2 composing the transformations we now apply the composition procedure to our example by composing the rules of t1 with those of t2. since the composition procedure is applied on individual rules, we have implemented a program in java that first detects which combinations of rules from t1 can be composed with rules from t2, based on proposition 1. the iteration over the rules of t2 follows the order shown in the upper left of figure 3. however, this may lead to several possible valid combinations of rules. the user then selects the most appropriate combination according to his knowledge of uml class diagrams and ejb. then, the composition procedure is applied on these two rules. the result, i.e., the transformation t3, is shown at the bottom of figure 3. composing t2 : r1. t2 : r1 is composable with t1 : r1, t1 : r2, and with t1 : r3 according to the composability condition. however, due to the fact that t1 : r2 and t1 : r3 both contain a subgraph of the lhs of t2 : r1 in both their lhs and rhs, t1 : r1 seems to be more appropriate for composition. the reason is that t1 : r1 actually generates the input elements for t2 : r1 in contrast to the other two rules which only check for the existence of these elements. the composite rule t3 : r1 is constructed by composing t1 : r1 and t2 : r1 as follows. the lhs of t3 : r1 remains the same as the one for t1 : r1. then to create the rhs of t3 : r1, the composition procedure connects an ejbarchive3 element to the package element of t1 : 2 other graph transformation frameworks explicitly representing transformations as models are applicable as well. 3 please note that due to space limitations, the nacs are not shown in figure 3. proc. mpm 2010 8 / 13 eceasst r1 via a trace edge. then the elimination procedure removes both the ejbarchive2 and t1 uml 2 ejb2 t2 ejb2 2 ejb3t1: uml 2 ejb2 t2: ejb2 2 ejb3 b2:ejbarchive2 a1:package 1 p k tr1 … c1:ejbarchive2 c1:ejbarchive2 d2:ejbarchive3tr1a1:package… a1:package tr1 r1 b3:deploydescp y d2:ejbarchive3 d2:ejbarchive3t b2:ejbarchive2 d2:ejbarchive3 d2:ejbarchive3t b2:ejbarchive2 b2:ejbarchive2 t c1:ejbarchive2tb2:ejbarchive2 b3:deploydesc c1:ejbarchive2 d6:entitybean r2a1:package b3:deploydesc t … c1:ejbarchive2 name = c4.namer2 b7:entityentry t r2 c4:entitybean t 1 p k b3:deploydesc b7:entityentryr2 c4:entitybean y d7:interface a1:package… c4:entitybean name = c4.name a4:class b5:entitybeant name = a4.name d2:ejbarchive3 d2 ejbarchi e3ta4:class b6 i t f d2:ejbarchive3 d2:ejbarchive3t ispersistent = true b6:interface d6 s i b t name = a4.name c1:ejbarchive2 c1:ejbarchive2 d6:sessionbean c1:ejbarchive2 name = c3.name r3b2:ejbarchive2 t … c3:sessionbean r3 b2:ejbarchive2 t c3:sessionbean c3:sessionbean d7:interface t a1:package b3:deploydesc t c5:sessionentry name = c3.namet a1:package b7 s i e t t c5:sessionentry c5:sessionentry d8:statelessisstateful = false b3:deploydesc b7:sessionentry i s f l f l r3 c5:sessionentry d8:statelessisstateful = false a1:package b3:deploydesc isstateful = false … r3 a1:package b5 s i b … d2:ejbarchive3 d2:ejbarchive3t a4:class b5:sessionbeant t a4:class name = a4.name d6:sessionbean t i p i t t f l a4:class b6:interface c1:ejbarchive2 c1:ejbarchive2 d6:sessionbean 3ispersistent = false name = a4 name b6:interface … name = c3.namer4name = a4.name c3:sessionbean c3:sessionbean d7:interface r4 c3:sessionbean c3:sessionbean d7:interface name = c3 name t c5:sessionentry name = c3.name c5:sessionentry d8:statefulisstateful = true t3: uml 2 ejb3t3: uml 2 ejb3 1 p k d2 ejba hi 31 p k tr1 a1:package… d2:ejbarchive3a1:package tr1 d2:ejbarchive3 d2:ejbarchive3t 1 p kt a1:packaget a1:package d6:entitybeanr2 g a4:class name = a4.name d6:entitybean… t r2 a4:class a4:class name a4.namet i p i t t t a4:class d7:interface ispersistent = true name = a4.name d2:ejbarchive3 d2:ejbarchive3t a1:package d8:statelesst a1:packaget a1:package d6:sessionbean…r3 a1:package name = a4 name d6:sessionbeanr3 a4:class name = a4.namet a4:class d7:interface ispersistent = false name = a4.namename a4.name figure 3: transformations of the case study. deploydesc elements from the result. finally a trace edge connecting the package element to the ejbarchive3 is created. t3 : r1 also comprises a nac corresponding to its rhs since t1 : r1 did have a nac corresponding to its own rhs. for computing this nac, we are currently not using a composition procedure. instead we just copy the elements of the rhs into the nac to ensure the aforementioned unique rule matching. composing t2 : r2. t2 : r2 is only composable with t1 : r2 as it is the only rule of t1 that has a rhs matchable by the lhs of t2 : r2. the two rules are thus composed in the same way as described in the previous case. in addition, we now have to compose not only the graph patterns but also the attribute value computations. for example, consider the assignment name = c4.name in element d6:entitybean of the rhs of t2 : r2. it cannot be copied as is 9 / 13 volume 42 (2011) transformation rule composition since the assignment refers to an element of the ejb 2.0 meta-model. in this example, we only have simple value assignments without using more complex functions. for setting the attribute values in the composed transformation rule, we have to find out for each attribute value assignment in t2, how the value is actually computed in t1. in our example, we can easily find out that the name attribute of the element c4 in t2 : r2 is actually calculated by using the name attribute value of the element a4. thus, only this assignment has to be used in the composed transformation rule. finally, the elimination procedure applied on the lhs of t3 : r2 not only deletes the deploydesc element from the rhs of t3 : r2 (as in the previous case), but also from the lhs of t3 : r2. composing t2 : r3. t2 : r3 is only composable with t1 : r3. in this case, in addition to composing the nodes and edges of the pattern, we also consider the attribute value condition isstateful = false of the lhs of t2 : r3. however, the rest of the composition is analogous to the previous case. composing t2 : r4. t2 : r4 is not composable with any rule of t1. 4.3 implementation the presented composition procedure allows to compose t1 and t2 nearly automatically. the transformation t3 can be entirely produced with the help of some heuristics to further filter out meaningful composition possibilities (e.g., reasoning about if a rule generates the elements or uses them only as context, as discussed in the first composition). furthermore, some specific extensions such as attribute value assignments as well as constraints are necessary in the future to allow for a higher automation degree. we have implemented the composition procedure on top of emf tiger. the user chooses two transformations to compose. if they are composable, the procedure outputs the composite rule. in the case where there are more than one possibility, the user can interactively select the most appropriate composition. the implementation relies on a higher-order transformation implemented in java. the first step is the generation of templates out of the lhs of the rules from t2. these templates are then matched against the rhs of the rules from t1. this match model is the basis for further composition computations. in a second step, the rules of t1 are rewritten according to the presented composition procedure. in addition, we have implemented the mentioned heuristic for filtering the composition possibilities and support simple attribute value assignments. after the composition computation has finished, the resulting transformation is serialized as t3 expressed again as an emf tiger transformation. 5 related work in this section, we outline how others have investigated in transformation composition: in graph transformation theory, in model-driven engineering, and more widely for model management in the field of data engineering. proc. mpm 2010 10 / 13 eceasst 5.1 composition of algebraic graph transformations as mentioned in section 3.2, a formal definition for the composition of two graph transformation rules was already proposed in [eept06], by creating the so-called e-concurrent rule. however, the authors do not explicitly precise how this rule is constructed. in the current paper, we propose a systematic algorithm to (1) detect if two rules are composable and (2) explicitly give the steps on how to construct the e-concurrent rule. also, the scope of the definitions and algorithms of this paper are directly applicable in model-driven frameworks. 5.2 composition of model transformations in the latest years, the sequential composition of model transformations has been an active research field. several approaches for modelling transformation chains [old05, vbh+06, fabj09, rrl+09] have been proposed. most of them are based on uml activity diagrams which orchestrate several transformations to achieve a larger goal. however, none of these approaches tries to compute new transformations out of existing transformations as done in this paper. in [pgpb08], the authors present an approach for composing rules within one transformation: the so called internal composition. for example, considering a transformation from uml class diagrams to java, two rules can be composed when they both transform uml classes to java classes with different mapping details. in [wag08], wagelaar presents sophisticated internal composition techniques for atl and qvt [obj08] in order to improve the design of model transformations. since these approaches focus on internal composition only, they do not discuss the computation of the transitive transformation from two given transformations. in [bhe09], the compositionality of model transformations is addressed. by compositionality the authors do not mean sequential composition as meant in this paper, but they are interested in the spatial composition when mapping a model to its semantic domain. compositionality is guaranteed by a transformation t if the execution of t produces a set of semantic expressions (instances of the semantic domain) such that their composition represents the semantics of the whole model. in summary, to our best knowledge no comparable approach to ours exists in the field of model-driven engineering for composing two transformations into the transitive transformation. 5.3 composition in model management in the area of data engineering, model management [bm07] has gained much interest during the last decade. model management stands for the idea of dealing with evolution in data engineering by using models (i.e., schemas and mappings between them) and operators for producing new models out of existing ones. they define schema operators, such as diff and merge, as well as mapping operators, such as inverse and compose. the goal of the compose operator is similar to our model transformation composition approach. however, its realization is quite different (cf. [bgmn08] and [yp05]). first, in data engineering, only relational and hierarchical schemas are considered in contrast to object-oriented meta-models, which are the basis for the composition approach of this paper. second, in data engineering, pre-defined relational operators (e.g., project, select, and join) are used for describing mappings between schemas. in contrast, our approach is built on graph transformations, which is a significantly different paradigm for describing mappings between object-oriented meta-models. 11 / 13 volume 42 (2011) transformation rule composition 6 conclusion in this paper, we provide a mechanism for composing individual rules from a transformation chain. this composition allows for the creation of a new transformation involving only the initial and target meta-models. although some assumptions must be made on the syntax of rules, the composition procedure is general enough in the sense that it is independent from the input model. the presented approach is based on the syntactic composition of the rules. extending the procedure to the transformation level requires to take into account the semantics of the chain of transformations. the main benefits of our approach are: (1) it is possible to reduce the complexity of transformation chains by eliminating unnecessary transformation steps, (2) if there is traceability from m1 to m2 and from m2 to m3, we are able to provide traceability from m1 to m3, and (3) our approach seems to be perfectly suited in metamodel evolution scenarios where the target metamodel evolves. if there is already an instance migration transformation from the initial target metamodel version to the new target metamodel version, this migration transformation may be composed with the transformation between the source and the initial target metamodel in order to ensure transformation co-evolution. as this is a first attempt on composing chains of transformations, a number of open issues still remain. in the presented example, we have only considered the core part of atl which is comparable to the core of other model-to-model transformation approaches, such as qvtrelations [obj08]. in particular, we did not focus on transformations requiring an explicit rule scheduler (e.g., with a control flow). also, several other features of atl should be supported, such as ocl queries and called rules (rules that are not automatically executed by the transformation engine but that have to be explicitly invoked in the transformation). furthermore, our example only considers simple attribute value assignments in the rules. however, before considering more complex attribute manipulations in the composition, one should first think of how to map them to graph transformations in order to provide a theoretical basis for extending the composition procedure. moreover, dealing with arbitrary ocl expressions when composing transformations is challenging and should certainly form a composition topic on its own. finally, we have to provide tool support for transforming the composed transformations, expressed as graph transformations, back to atl transformations. in this context, we have intend to migrate our current prototype to a bi-directional model transformation formalism. acknowledgements we would like to thank all the participants of the 2010 computer-aided multi-paradigm modelling workshop (campam) for their useful feedback. bibliography [bet08] e. biermann, c. ermel, g. taentzer. precise semantics of emf model transformations by graph transformation. in international conference on model driven engineering languages and systems. lncs 5301, pp. 53–67. springer, 2008. proc. mpm 2010 12 / 13 eceasst [bgmn08] p. a. bernstein, t. j. green, s. melnik, a. nash. implementing mapping composition. vldb j. 17(2):333–353, 2008. [bhe09] d. bisztray, r. heckel, h. ehrig. compositionality of model transformations. electronic notes in theoretical computer science 236:5–19, 2009. [bm07] p. a. bernstein, s. melnik. model management 2.0: manipulating richer mappings. in international conference on management of data. pp. 1–12. acm, 2007. [eept06] h. ehrig, k. ehrig, u. prange, g. taentzer. fundamentals of algebraic graph transformation. eatcs. springer-verlag, 2006. [fabj09] m. d. d. fabro, p. albert, j. bézivin, f. jouault. achieving rule interoperability using chains of model transformations. in international conference on theory and practice of model transformations. lncs 5563, pp. 249–259. springer, 2009. [jk06] f. jouault, i. kurtev. transforming models with atl. in model transformation in practice workshop. lncs 3844, pp. 128–138. springer, 2006. [kms+10] t. kühne, g. mezei, e. syriani, h. vangheluwe, m. wimmer. explicit transformation modeling. in models 2009 workshops. lncs 6002, pp. 240–255. springer, 2010. [mv06] t. mens, p. van gorp. a taxonomy of model transformation. in gramot’05. entcs 152, pp. 125–142. tallinn (estonia), march 2006. [obj08] object management group. meta object facility 2.0 query/view/transformation specification. april 2008. [old05] j. oldevik. transformation composition modelling framework. in international conference on distributed applications and interoperable systems. lncs 3543, pp. 108–114. springer, 2005. [pgpb08] c. pons, r. giandini, g. perez, g. baum. an algebraic approach for composing model transformations in qvt. in international workshop on software language engineering. 2008. [rrl+09] j. e. rivera, d. ruiz-gonzalez, f. lopez-romero, j. bautista, a. vallecillo. orchestrating atl model transformations. in mtatl workshop. pp. 34–46. 2009. [vbh+06] b. vanhooff, s. v. baelen, a. hovsepyan, w. joosen, y. berbers. towards a transformation chain modeling language. in international workshop on embedded computer systems. lncs 4017, pp. 39–48. springer, 2006. [wag08] d. wagelaar. composition techniques for rule-based model transformation languages. in international conference on theory and practice of model transformations. lncs 5063, pp. 152–167. springer, 2008. [yp05] c. yu, l. popa. semantic adaptation of schema mappings when schemas evolve. in int. conference on very large data bases. pp. 1006–1017. acm, 2005. 13 / 13 volume 42 (2011) introduction transformation composition rule composition criteria for rule composability composition procedure application involved artefacts composing the transformations implementation related work composition of algebraic graph transformations composition of model transformations composition in model management conclusion preface electronic communications of the easst volume 12 (2008) formal modeling of adaptive and mobile processes preface kathrin hoffmann, julia padberg 1 pages guest editors: julia padberg, kathrin hoffmann managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst preface kathrin hoffmann1, julia padberg2 1institute for software technology and theoretical computer science technical university berlin, germany 2university of applied sciences, hamburg, germany combining diverse topics as adaptive and mobile processes with formal modeling leads to an interesting collection of contributions. here we find a mixture of agent-based, transformationbased and petri-net-based approaches that share the distinction of dynamic behavior of the system and its change due to mobility and/or adaption. since mobility and adaptivity both induce strong challenges for dynamic systems, they both need new concepts for the formal modeling. in contribution by michael köhler-bußmeier object nets are uses to model mobile systems. object nets are petri nets which have petri nets as tokens – an approach known as the netswithin-nets paradigm. the same paradigm is employed for the results concerning the layered architecture for modeling workflows in mobile ad-hoc networks (manets) using algebraic higher order nets by padberg, biermann and hoffmann. in contrast hoffmann, ehrig and padberg demonstrate the advantages of reconfigurable systems in manets and present the main results for this approach. bottoni, de rosa and mecella also deal with the process management in manets. as the modifications occur dynamically, they propose the use of a rule-based formalism, expressed in terms of multi-set rewriting. an agent-based approach can be fount in the paper by pfalzgraf and soboll, where the focus is on the construction of a transformation system for multiagent systems based on categorical notions. the contribution by beierle and kernisberner concerns the modeling of an agent’s beliefs and their dynamic changes using inductive reasoning techniques for the agent’s knowledge base. 1 / 1 volume 12 (2008) electronic communications of the easst volume 25 (2010) proceedings of the workshop visual formalisms for patterns at vl/hcc 2009 preface paolo bottoni, esther guerra and juan de lara 2 pages guest editors: paolo bottoni, esther guerra, juan de lara managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 eceasst preface this proceedings contains selected and extended papers presented at vffp’09, the first international workshop on visual formalisms for patterns. the workshop was held as a satellite event of the 2009 ieee symposium on visual languages and human-centric computing, vl/hcc 2009. the workshop brought together researchers interested in the definition, usage and analysis of patterns through visual formalisms, which couple the simplicity of traditional methods for pattern expression with solid foundations for pattern-based activities. patterns are used in different disciplines as a way to record expert knowledge for problem solving in specific areas. in software engineering, they are increasingly used for the definition of software applications and frameworks, as well as in model-driven engineering, to indicate parts of required architectures, drive code refactorings, or build model-to-model transformations. their systematic use promotes quality, standardization, reusability and maintainability of software artefacts. the full realisation of their power is however hindered by the lack of a standard formalization of the notion of pattern. presentations of patterns are typically given through natural language to explain their motivation, context and consequences; programming code to show usages of the pattern; and diagrams to communicate their structure and behaviour. several researchers have indicated the limitations of the current semi-formal devices for pattern definition – generally based on domain modelling languages, such as uml for design patterns, or coloured petri nets for workflow – and research is active to propose rigorous formalisms, methodologies and languages for pattern definition in specific domains, as well as to propose general models of patterns. the availability of formalisms will make common practices involving patterns, such as pattern discovery, pattern enforcement, pattern-based refactoring, etc., simpler and amenable to automation, and open new perspectives for pattern composition and analysis of pattern consequences. this workshop was conceived as a forum to communicate, discuss and advance in these directions. the vffp’09 technical programme included the keynote presentation “pinning down patterns” by prof. john hosking, director of the centre for software innovation of the university of auckland (new zealand). the workshop technical contributions were carefully reviewed by three referees, and the program committee selected 6 long and 3 short papers. the workshop was organized in in three technical sessions (“pattern definition and formalization”, “patterns in process and test engineering” and “patterns and visualization”) and finished with a discussion panel on the benefits, limits and uses of pattern formalization. for these final proceedings, the papers were extended and revised according to the feedback obtained in the workshop, an additional round of revisions was organized and a total of 8 papers were finally accepted. we would like to thank the members of the program committee and the secondary reviewers for their excellent work, they are listed below. we would also like to thank the organizing committee of vl/hcc’09 for their constant support, and to all workshop participants, which helped to make the first edition of vffp a success!. february 2010. paolo bottoni, esther guerra, juan de lara. pc chairs of vffp’09. 1 / 2 volume 25 (2010) preface of vffp’09 program committee • jing dong, university of texas, dallas. • amnon h. eden, university of essex. • gregor engels, university of paderborn. • reiko heckel, university of leicester. • john hosking, university of auckland. • dae-kyoo kim, oakland university. • soon-kyeong kim, university of queensland. • susana montero, universidad carlos iii de madrid. • francesco parisi presicce, university of rome, “sapienza”. • claudia pons, university of la plata. • nick russell, technical university of eindhoven. • michael stal, siemens ag. • david stotts, university of north carolina. • gerson sunyé, université de nantes. • toufik taibi, university of western ontario. • kang zhang, university of texas, dallas. • albert zundorf, university of kassel . external reviewers nina aschenbrenner, christian gerth, jun kong, christian soltenborn, yajing zhao. proc. vffp 2009 2 / 2 integrating ocl and model transformations in fujaba electronic communications of the easst volume 5 (2006) proceedings of the sixth ocl workshop ocl for (meta-)models in multiple application domains (oclapps 2006) integrating ocl and model transformations in fujaba mirko stölzel, steffen zschaler and leif geiger 16 pages guest editors: dan chiorean, birgit demuth, martin gogolla, jos warmer managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst integrating ocl and model transformations in fujaba mirko stölzel1, steffen zschaler2 and leif geiger3 1 s2729561@inf.tu-dresden.de, http://st.inf.tu-dresden.de/ department of computer science dresden university of technology, germany 2 steffen.zschaler@inf.tu-dresden.de, http://st.inf.tu-dresden.de/ department of computer science dresden university of technology, germany 3 leif.geiger@uni-kassel.de, http://www.se.eecs.uni-kassel.de/se/ universität kassel, wilhelmshöher allee 73, 34121 kassel abstract: this paper discusses the integration of the dresden ocl toolkit into the fujaba tool suite. the integration not only adds ocl support for class diagrams but also makes ocl usable in fujaba’s model transformations. this makes fujaba’s model transformations more powerful, completely platform independent and easier to read for developers who are already familiar with ocl. by using the code generator of the dresden toolkit, we are able to generate executable java code from fujaba’s model transformations including the ocl constraints. keywords: object constraint language, fujaba, dresden ocl toolkit, model transformation, story diagrams 1 introduction the fujaba tool suite [zün99] is a case tool which supports model driven development (mdd) [kwb03]. within mdd model transformations play an important role. fujaba offers special interaction diagrams to specify model transformations. within these diagrams most of the transformations are specified graphically. nevertheless, some expressions have to be specified textually, like complicated constraints, return values, etc. since fujaba generates java source code from model transformations, these textual statements have been specified using java expression. currently, no syntax-checking is done for these expressions, so an erroneous expression results in a compile error after code generation. newer work adds c++ code generation to fujaba. note, that if a developer wants to use c++ code generation, the constraints have to be written in c++ syntax. so, it would be helpful to have a platform-independent constraint language, which makes syntax checking possible within fujaba’s model transformations, and adds code completion and code generation for the different target languages fujaba offers. this paper suggest to use the object constraint language (ocl) [obj03a] for this task. to this end, we have integrated the dresden ocl toolkit [ocl99] into the fujaba tool suite. this allows us to use ocl as the constraint language for fujaba’s model transformations. 1 / 16 volume 5 (2006) mailto:s2729561@inf.tu-dresden.de http://st.inf.tu-dresden.de/ mailto:steffen.zschaler@inf.tu-dresden.de http://st.inf.tu-dresden.de/ mailto:leif.geiger@uni-kassel.de http://www.se.eecs.uni-kassel.de/se/ this paper is structured as follows: section 2 briefly describes how model transformations are specified using fujaba, section 3 describes the integration of ocl into fujaba’s model transformations, section 4 describes the implementation of the dresden ocl toolkit integration into fujaba4eclipse, section 5 discusses code generation. in section 6, related work is presented and section 7 concludes. 2 story diagrams – a short overview the fujaba tool suite [zün99] uses unified modelling language (uml) [obj03b] class diagrams to model the structure of an application. in [stö05] we have integrated the dresden ocl toolkit [ocl99] for use in fujaba’s class diagrams. for behaviour specification, model transformations are specified by using graph transformations within fujaba. this is done by modelling specialized uml interaction diagrams for the method bodies—so-called story diagrams [fnt98, zün01b]. from such diagrams fujaba can then generate executable java source code. figure 1 shows such a story diagram. it is an activity diagram into which graph transformation rule have been embedded. the activity diagram models the control flow. the graph transformations within the activities model the behaviour. the first activity of figure 1 shows such a graph transformation. here, starting from the object this, which is the object the method nameexists() is called on, a child is searched via the children association. this child’s name attribute should equal the passed name parameter. if such a child is found, it is stored in a local variable called child. figure 1: story diagram afterwards, the activity is left. if the graph transformation was applied, it is left via the success transition. so the method returns true. otherwise, the failure transition is taken, proc. oclapps 2006 2 / 16 eceasst thus false is returned. note, that in fujaba’s story diagrams, there are several places, where java source code can be used. for example, the return value for a stop activity can be any java expression. this code is directly copied into the source code during code generation. 3 integrating ocl into story diagrams this section discusses the integration of ocl into fujaba’s story diagrams. first, we give a short overview of the places where ocl can be used in story diagrams. then some special characteristics of fujaba’s story diagrams, which must be considered to use ocl in story diagrams, are presented. finally a possible solution which considers these special characteristics will be shown. 3.1 where to integrate in this section, we will present a short overview of all possibilities to use ocl in fujaba’s story diagrams. on the left side of the figures 2–6 one can see some examples with the original notation of fujaba while on the right the same example is illustrated using ocl: attribute expressions can be used to assign new attribute values to an attribute of an object and to define some additional attribute conditions which must be fulfilled by an object. in the example of figure 2 the value of the name attribute of the this-object is assigned to the name attribute of the child-object by calling the getname() method of the thisobject. on the right side of figure 2 one can see that the name attribute of the this-object can be directly referenced using ocl. figure 2: attribute assertion and attribute constraints collaboration statements are used to execute methods, to define new variables or to assign new values to variables. these operations can be combined using the sequential, ifor while composition. in the following example (figure 3) a collaboration statement is used to define the variable count of type integer. the sizeofchildren() method has been automatically generated by fujaba for the to-n association children. it returns the number of person instances which are assigned to the this-object as a child. using ocl, one can reference the children association directly and can call the size() method of ocl-set to get the number of children of the this-object. 3 / 16 volume 5 (2006) figure 3: collaboration statements additional constraints are boolean constraints which can be assigned to a story pattern so that the story pattern is applicable if the constraint evaluates to true. in the example of figure 4 the additional constraint defines that the this-object must have exactly five children. figure 4: additional constraints boolean transition guards can be used to realize a ifor while-composition in the activity diagram part of the story diagrams. in the following example the variable found will be set to true if the child-object was successfully bound in the previous story pattern. as one can see on the right side of this example the oclisundefined() method can be used to formulate the boolean condition with ocl. figure 5: boolean if-condition proc. oclapps 2006 4 / 16 eceasst method return value the last possible use of ocl in fujaba’s story diagrams is represented in figure 6. at every stop activity, the operation’s return value can be defined using a constraint. figure 6: stop activity 3.2 resolving scoping to integrate ocl in fujaba’s story diagrams we use the ocl parser of the dresden ocl toolkit. it checks the syntax and the consistency of an ocl constraints in the context of the containing story diagram. to perform a consistency check the parser of the dresden ocl toolkit tries to find all variables which are referenced within an ocl constraint in its story diagram. to do so, the parser has to know which variables and objects are defined in the corresponding story diagram. this information is contained in the so-called context of an ocl constraint. when generating the context of ocl constraints in fujaba’s story diagrams we have to consider some special characteristics of story diagrams: • in each story diagram the this-object and the method parameters are predefined bound objects. those can always be referenced in ocl constraints. • a story diagram in general contains many execution paths. every path visits different story activities and so different variables and objects can be bound. it can, for example, occur that one variable is not initialized on one special path leading to a story activity and initialized on another one. for this reason, only these variables and objects can be used in an ocl constraint of a story activity which are defined on every path leading to that story activity. • an object of a story diagram is initialized with a valid value if the corresponding story pattern is applicable. so the objects of a story pattern can only be referenced by the ocl constraints of the next story activity if the activities are connected by a success or eachtime transition. an eachtime transition is used in combination with a so called foreach activity. this special activity basically represents repeated matching. it is not left after the first object was found, but the specified transformations are executed for every valid object allocation. in the example of figure 1 we could have used a foreach activity to count all children where the name attribute equals the passed name parameter. in the following we present an algorithm which considers these characteristics and can be used to generate the context of an ocl constraint in a story diagram. to obtain this context, an environment is assigned to every element in the story diagram, beginning with the start activity. 5 / 16 volume 5 (2006) an environment encapsulates a set of name–type bindings representing the variables accessible under this environment. when a name lookup occurs, the environment first checks whether it contains a corresponding binding itself. if this is not the case, the environment can delegate the lookup to its parent environments (other environments linked to it via a parent association). if all parent environments agree on the result of the lookup, this will be returned. if they do not agree, the lookup fails. as we will see, parent–child relations can, thus, be used to represent the control flow in a story diagram. note that story diagrams allow the deletion of objects from the object graph. therefore, after deletion of an object its name will be no longer bound. to represent this, environments distinguish different types of bindings; one of them is used to mark deleted objects. in order to clarify the context generation algorithm an example story diagram is represented in figure 7. there one can see that first an initial environment e1 is assigned to the start activity of the story diagram and that the this-object and the method parameter var1 are added to this environment. in the next step, the outgoing transition of the start activity is traversed and the first activity is visited. in addition, the environment e2 is assigned to the activity as input environment. since the variables this and var1 of the environment e1 can also be used within the first activity, the parent–child relationship between e1 and e2 is created. in the first activity the variable var2 is created and it is added to the outgoing environment e3 of the activity. figure 7: generation of the ocl-context proc. oclapps 2006 6 / 16 eceasst in the next step the two outgoing transitions of the second activity are traversed and the environments e4 and e5 are assigned to the corresponding story activities. it must be considered, that on the path following the failure transition the story pattern of the second activity was not applicable. consequently, we cannot assume that the objects of the second activity were successfully bound. therefore these objects cannot be used in following ocl constraints. that’s the reason why the parent–child relationship is made between the environment e4 and the environment e2 and not to the environment e3. similarly, the variable var2 could successfully be bound when taking the success transition and can be used in following ocl constraints. so the parent–child relationship between the environment e3 and e5 is created. in the next steps the environment e6 and e7 are created, which contain the visible variables, and the outgoing transitions are traversed. as result the environment e8 is assigned to the next story activity and the parent–child relations between the environment e8 and the environments e6 and e7 are created. at this point the second problem mentioned above must be considered. since the variable var4 is defined only on the left path, the environment e8 does not contain this variable. the same problem applies to the variable var2. because of the failure transition this variable can be used only in the right path and thus the variable var2 is also not a part of the environment e8. the last step of the generation process is to generate the environments e9 and e10 which is assigned to the stop activity of the story diagram. 4 fujaba and the dresden ocl toolkit this section discusses the implementation of the ocl integration into fujabas story diagrams within the scope of fujaba4eclipse [zün01a] and the dresden ocl toolkit. the section starts with a short discussion of the context declaration to be used for the ocl constraints defined in fujaba’s story diagrams. every ocl constraint must be preceded by a context declaration that defines the context in which the constraint is to be evaluated. next, we discuss the integration interface of the dresden ocl toolkit. this interface has already been used in [stö05] to allow the specification of ocl constraints in fujaba’s class diagrams. finally, we present our ocl editor for eclipse. this allows creating and editing ocl constraints for a given story diagram—and actually for any model edited in an eclipse-based application. the ocl parser of the dresden ocl toolkit is used to check syntax and consistency of the ocl constraints. 4.1 ocl constraint context declaration the parser of the dresden ocl toolkit needs for a consistency check the context declaration of the ocl constraints. that’s the reason why the context of the ocl constraints in fujaba’s story diagrams has to be specified. as already mentioned in section 3 an environment containing all visible variables is assigned to each story diagram element. thus, the environment of a story diagram element represents the context of an ocl constraint defined for this element. in order to illustrate the context declaration of ocl constraints in story diagrams two exam7 / 16 volume 5 (2006) ples are shown below. in the first example one can see an ocl constraint which can be used for general constraints of a story activity, an attribute condition or for a transition guard. this constraint is defined in the context of the cond() method of the class environment and the evaluation results in true if the ocl constraint is fulfilled. in the second example one can see an ocl constraint which can be used to specify an attribute assertion, a collaboration statement or to define the result clause of a method. the difference between these two examples is the result type of the cond() method which is equivalent to the type of the asserted value. environment::cond():boolean post:result = (child.oclisundefined()) environment::cond():string post:result = (this.name) figure 8: examples 4.2 integration interface of the dresden ocl toolkit the dresden ocl toolkit was developed by the department of computer science of the technical university dresden. it can be used to check syntax and consistency of ocl constraints against a uml model and to generate the corresponding java code. the required model information are managed in an metadata repository (mdr) [mat03] and can be accessed using so called java metadata interfaces (jmi) [inc06]. when integrating the dresden ocl toolkit in a case-tool the problem occurs that the model information required for the consistency check are not part of the toolkit repository, but can be found in the repository of the case-tool. thus, the main goal of the integration interface was to find a way to allow the parser of the dresden ocl toolkit the direct access to the case-tool repository. we have presented an integration concept in [stö05]. the main idea is to create representative elements in the toolkit repository which know their corresponding model elements in the case-tool repository. these representatives serve as proxies into the case-tool repository. duplicating the case-tool repository is not required, all model information can remain in the case-tool repository. the most important part of the integration interface is the class modelfacade. an instance of this class is assigned to a uml model in the toolkit repository and manages the relationships between the representative elements and the corresponding elements in the case-tool repository. thus, this instance can be used to determine the actual attributes of a representative element related to the model element in the case-tool repository. in order to allow using the integration interface not only for one case-tool but for any case-tools the class modelfacade is defined as an abstract class and has to be implemented case-tool specific. in order to illustrate the use of the integration interface the consistency check process for the right hand side of figure 2 is shown below. there one can see the executed steps to find the this object referenced in the ocl constraint of figure 2. proc. oclapps 2006 8 / 16 eceasst 7 figure 9: integration interface of the dresden ocl toolkit to find referenced model elements, the parser of the dresden ocl toolkit uses method findclassifier() of the toppackage representative model element which is the entry point to an uml model in the toolkit repository. inside the findclassifier() method the getownedelements() method of the jmi interface namespace is called to determine all model elements in the name space of the toppackage element. in order to use the fujaba specific implementation of the class modelfacade the method getownedelements() was implemented in a custom way. thus, the instance of the class fujabafacade assigned to the uml model in the toolkit repository is determined and its getownedelements() method is called. inside this method the getrefobject() method is used to find out the corresponding element of the representative element the getownedelement() method was called for. this way, all model elements defined in the name space of the corresponding element can be determined and the getelement() method is called for each of these elements as a parameter. as result of this method a new representative element is created, or the still existing one is returned. since the class environment is not part of the fujaba uml model the representative element for the environment is not in the set of the determined elements. thus, getelement() is invoked additionally with the environment instance referenced by the fujabafacade. finally all found representative elements including the environment element are returned as the result of the getownedelements() method. after this step the parser of the dresden ocl toolkit can use the representative element of the environment to search for the this variable. for this the getfeatures() method of the jmi interface classifier is called and 9 / 16 volume 5 (2006) the same procedure is started again. in the last step the getname() method of the found element representing the this variable is used to check whether the name attribute exists. the integration as presented has been implemented for class and story diagrams. thus, input, consistency and syntax checking of ocl constraints in story diagram are possible, as it is possible for fujabas class diagrams. we use the algorithm described in section 3.2 to generate the context of ocl constraints in a story diagram which is used by the fujaba specific implementation of the modelfacade. thus, the parser of the dresden ocl toolkit is able to check whether referenced variables within an ocl constraint are defined in the corresponding story diagram. 4.3 ocl editor of the dresden ocl toolkit in order to use the dresden ocl toolkit within fujaba4eclipse to check syntax and consistency of ocl constraints it had to be implemented as a eclipse plugin. on basis of this plugin an ocl editor plugin was developed and the integration of the dresden ocl toolkit for fujabas class diagrams has already been accomplished in [stö05] using the dresden ocl toolkit integration interface. presently, we extended the ocl editor plugin to integrate the dresden ocl toolkit also for fujaba’s story diagrams. the ocl editor plugin allows other eclipse plugins to create and edit ocl constraints, and check syntax and consistency of these constraints against a given model. to do this, the ocl editor provides an extension point consisting of the abstract class iocleditorextension which is shown in figure 10. figure 10: extension point iocleditorextension proc. oclapps 2006 10 / 16 eceasst in figure 10 one can see that the class iocleditorextension contains a method named setselection() which is called by the ocl editor if the selection of the eclipse ide changed. this method is used to check whether the actual selection is a model element of an eclipse plugin implementing the ocl editor extension point. inside the setselection() method the isvalidselection() method is called which should return a value unequal null if the selection is a model element of the plugin. the ocl editor can search for all implementations of its extension point being responsible for the actual selection. thus, all existing ocl constraints can be displayed, edited, deleted or new ocl constraints can be created. in order to realize this some other methods of the class iocleditorextension have to be implemented: • the method isenabled() is called by the ocl editor to check whether ocl constraints can be defined for the selected model element. • after the method isenabled() returns true the method getconstraints() is used to get all existing constraints for the selected model element. to display these constraints in the ocl editor area the getconstrainttext() is called. • the method createpartcontrol() is called to create the graphical user interface which is used to create and edit ocl constraints • after an ocl constraint was edited the getparseconfiguration() method is used to determine the modelfacade instance, the toppackage element and the textual ocl constraint which are encapsulated by an instance of the class parseconfiguration. the modelfacade instance and the toppackage element are used by the ocl editor to check consistency and syntax of the textual constraint. • if the syntax and the consistency check for an ocl constraints was successful the methods createoclconstraint() or editoclconstraint() are used to create a new model element or edit the existing model element representing an ocl constraint on case-tool side. • the method deleteoclconstraint() is called to delete an existing ocl model element. finally, a screen shot of the ocl editor plugin can be seen in figure 11. in the left lower part of this figure you can see the ocl-editor for eclipse which allows you to create and edit ocl constraints for a given story diagram. additionally, you can use the ocl parser of the dresden ocl toolkit to check syntax and consistency of the ocl constraints against the story diagram. in the example shown in figure 11 one can see, that an error message is shown in the problems view of eclipse, since the variable var4 is not defined on the left path of the example story diagram. 5 generating code as already mentioned, fujaba generates executable java code from class diagrams and model transformations. the code that would be generated for the left hand side of figure 4 is shown 11 / 16 volume 5 (2006) figure 11: ocl editor eclipse plugin below. 01 // bind child: person 02 iterator iter = this.iteratorofchildren (); 03 while ( !(fujaba__success) && iter.hasnext () ) 04 { 05 try 06 { 07 child = (person) iter.next (); 08 // check isomorphic binding 09 javasdm.ensure ( !(this.equals (child)) ); 10 // constraint proc. oclapps 2006 12 / 16 eceasst 11 javasdm.ensure ( child.sizeofchildren() == 5 ); 12 fujaba__success = true; 13 } 14 catch ( javasdmexception e ) {} 15 } to search through all children of the this object, a iterator is created in line 02. the while loop from line 04 to line 15 is repeated till one child has been found, that matches all conditions (fujaba success == true) or till no more child exists in the list. in this loop, in line 07 the current child object is fetched from the list. since the this object, and the child object are both of class person, it is possible to make a person its own child. fujaba’s semantics forbids such matches (unless explicitly allowed in the story diagram), so this is checked in line 09. note, that fujaba provides the library method javasdm.ensure(boolean) which simply does nothing, when passed true and throws a javasdmexception otherwise. so, if this equals child, this would end the checks for the current object and continue with the next one. otherwise the additional constraint is checked in line 11. note, that the text from the constraint is directly copied into the code surrounded by another javasdm.ensure. if this test is also passed, fujaba success is set to true, to indicate that a valid child has been found. the loop is terminated in that case. if the additional constraint is now specified in ocl, as done in the right hand side of figure 4, the code generation has to be adapted. we have integrated the code generation of the dresden ocl toolkit into fujaba4eclipse. the modified code generation leaves most of the code above untouched, but changes the check of the condition in line 11. the source code below shows the code which is now generated. 01 //bind child: person 02 iterator iter = this.iteratorofchildren (); 03 while ( !(fujaba__success) && iter.hasnext () ) 04 { 05 try 06 { 07 child = (person) iter.next (); 08 // check isomorphic binding 09 javasdm.ensure ( !(this.equals (child)) ); 10 //*******************constraint**************** 11 oclany self = 12 (oclany) ocl.getoclrepresentationfor(this); 13 oclboolean constraintvalid= 14 self.getfeatureascollection("children"). 15 size().isequalto( new oclinteger(5) ); 16 javasdm.ensure ( constraintvalid.istrue() ); 17 //*******************constraint**************** 18 fujaba__success = true; 19 } 13 / 16 volume 5 (2006) 20 catch ( javasdmexception e ) {} 21 } within the dresden ocl toolkit the ocl standard library is implemented by some java classes, which are used by the java code, created by the java code generator of the dresden ocl toolkit, to evaluate an ocl constraint. to evaluate the ocl constraint of the right hand side of figure 4 an instance of the class oclany is created as one can see in line 11 of the code example shown above. this instance is used in line 13 to get an instance of the class oclcollection which represents the children association end of the this-object. afterwards the number of the elements in this collection is determined using the size() method of the oclcollection instance. this results in an instance of the class oclinteger of which the isequalto() method is used to evaluate whether the number of collection elements equals 5. as the result of the isequalto() method call an instance of the class oclboolean is created of which the istrue() method returns the result of the comparison. so the result of this method can be used as input of the javasdm.ensure() method call as one can see in line 15. 6 related work many case tools offer ocl support for class diagrams. for example, the dresden ocl toolkit has been integrated with together and argouml. but those tools have no support for model transformation and no integration of ocl in other diagrams. the emft project [the06] supports ocl for constraints and queries. one can use ocl for constraints on the static model and for specification of querying behavior. this way e.g. derived attributes can be modeled. so emft uses ocl for some very basic behavior specification. but it has no support for model transformations. the qvt standard [obj06] by the omg has some similar ideas. qvt defines a model transformation language which uses ocl. qvt extends the ocl with imperative expressions to make it more powerful. in this imperativeocl things like attribute assignments, link creation etc. can now be expressed. in our approach this imperative part is modeled using story diagrams. currently, complete tool support for qvt is still missing. 7 conclusions the fujaba tool suite is a case-tool which supports the most important diagrams of the unified modelling language with code generation for java. to also specify the behaviour of a system modelled with fujaba one can use so-called story diagrams. as described in section 2 story diagrams combine uml activity diagrams and collaboration diagrams for the specification of methods. within story diagrams some expressions, like additional constraints, return values, etc are specified textually using java expressions. these expressions are inserted identically in the code generated by fujaba. if a developer wants to use another programming language than java every constraint within the story diagrams have to be changed separately. so it is useful to specify the additional constraints using the object constraint language. proc. oclapps 2006 14 / 16 eceasst therefore, we discussed the possibilities to use ocl in fujaba’s story diagrams in section 3 and described some special characteristics which must be considered to generate the context of ocl contraints within story diagrams. after that we explained an algorithm to generate the ocl context considering the special characteristics. on basis of the context generation algorithm the integration of the dresden ocl toolkit into fujaba4eclipse using the dresden ocl toolkit integration interface is described in section 4. additional in section 5 we described the code generation for fujaba’s story diagrams and discussed how the generated code of a story diagram could look like using ocl. as already mentioned in section 4, we use the dresden ocl toolkit to integrate ocl in fujaba’s story diagrams. this enables using ocl in various places in fujaba’s story diagrams, while maintaining the ability to generate code. development of a prototype implementation of the concepts discussed in this paper was completed in [stö06]. finally, the implemented integration has been modularly constructed from eclipse plugins. therefore, integration with other eclipse-based case tools should be very straight forward. bibliography [fnt98] t. fischer, j. niere, l. torunski. konzeption und realisierung einer integrierten entwicklungsumgebung für uml, java und story-driven modeling. diplomarbeit, university of paderborn, 1998. [inc06] s. m. inc. java metadata interface. nov. 2006. http://java.sun.com/products/jmi/. http://java.sun.com/products/jmi/ [kwb03] a. kleppe, j. warmer, w. bast. mda explained: the model-driven architecture– practice and promise. addison-wesley, 2003. [mat03] m. matula. netbeans metadata repository. mar. 2003. http://mdr.netbeans.org/mdrwhitepaper.pdf. http://mdr.netbeans.org/mdr-whitepaper.pdf [obj03a] object management group. uml 2.0 ocl specification. omg document ptc/200310-14, oct. 2003. [obj03b] object management group. uml resource page. 2003. http://www.omg.org/uml/ [obj06] object management group. mof qvt final adopted specification. 2006. http://www.omg.org/docs/ptc/05-11-01.pdf [ocl99] ocl toolkit team. dresden ocl toolkit homepage. 1999. http://dresden-ocl.sourceforge.net/ [stö05] m. stölzel. ocl für fujaba. großer beleg, technische universität dresden, 2005. in german. 15 / 16 volume 5 (2006) http://java.sun.com/products/jmi/ http://mdr.netbeans.org/mdr-whitepaper.pdf http://www.omg.org/uml/ http://www.omg.org/docs/ptc/05-11-01.pdf http://dresden-ocl.sourceforge.net/ [stö06] m. stölzel. verwendung der ocl zur formulierung von bedingungen in storydiagrammen. diplomarbeit, technische universität dresden, 2006. in german. [the06] the eclipse foundation. emft eclipse modeling framework technologies. 2006. http://www.eclipse.org/emft/projects/ocl/ [zün99] a. zündorf. the fujaba toolsuite. 1999. http://www.fujaba.de/ [zün01a] a. zündorf. fujaba for eclipse. 2001. http://wwwcs.uni-paderbord.de/cs/fujaba/projects/eclipse/ [zün01b] a. zündorf. rigorous object oriented software development, habilitation thesis. university of paderborn, 2001. proc. oclapps 2006 16 / 16 http://www.eclipse.org/emft/projects/ocl/ http://www.fujaba.de/ http://wwwcs.uni-paderbord.de/cs/fujaba/projects/eclipse/ introduction story diagrams -a short overview integrating ocl into story diagrams where to integrate resolving scoping fujaba and the dresden ocl toolkit ocl constraint context declaration integration interface of the dresden ocl toolkit ocl editor of the dresden ocl toolkit generating code related work conclusions towards the tree automata workbench marbles electronic communications of the easst volume 26 (2010) manipulation of graphs, algebras and pictures essays dedicated to hans-jörg kreowski on the occasion of his 60th birthday towards the tree automata workbench marbles frank drewes 16 pages guest editors: frank drewes, annegret habel, berthold hoffmann, detlef plump managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst towards the tree automata workbench marbles∗ frank drewes institutionen för datavetenskap umeå universitet, s-901 87 umeå (sverige) drewes@cs.umu.se abstract: the conceptual ideas that are intended to become the basis for the tree automata workbench marbles1 are sketched. the goal is to design and implement an extensible system that facilitates experiments with virtually any kind of algorithm on tree automata. moreover, the system will be released with a library and an application programmer’s interface to make it accessible to anyone who wants to apply tree automata algorithms in research and development. keywords: tree automaton; tree automata workbench; marbles 1 introduction already in the 1960s, researchers realized that large parts of the theory of finite automata can be generalized by replacing strings with trees, retaining most of the positive algorithmic results and closure properties. this observation gave rise to a flourishing theory, including a large number of techniques and algorithms for the analysis, modification, and synthesis of various kinds of tree recognizers, tree grammars, and tree transducers [gs84, np92, gs97, fv98, cdg+07]. throughout the rest of this paper, all devices that fall into one of these categories will be called tree automata. nowadays, probably more theoretical research than ever before is done in this area, a fact that is explained by a constantly growing number of applications in fields such as verification and model checking [gk00, ajmd02, löd02, fgv04], natural language processing [kg05, gkm08], xml processing [sch07], code selection in compilers [fsw94, bor04], and generation of graphs and pictures [eng94, dre06]. the system treebag2 uses tree generators to generate sets of objects over arbitrary domains. the central data type of treebag is the ranked and ordered tree, with nodes labelled by symbols taken from a ranked alphabet σ. in other words, every symbol f ∈ σ comes with a rank k ≥ 0, such that a node labelled with f is required to have exactly k children (which are totally ordered). this means that a tree in the sense of treebag is a term, i.e., a well-formed expression composed of abstract (i.e., “meaningless”) operation symbols, each having a specified rank that determines the number of subexpressions. treebag deals with two types of tree automata on such trees, namely tree grammars and tree transducers. a tree grammar is a device that generates trees out of itself, whereas a tree transducer transforms input trees into output trees. a tree generator is a tree grammar composed with a (possibly empty) sequence of tree transducers. ∗ dedicated to hans-jörg kreowski on the occasion of this 60th birthday. 1 tree automata workbench = taw = a large marble, a game of marbles (oxford new amer. dict.). 2 tree-based generator 1 / 16 volume 26 (2010) mailto:drewes@cs.umu.se towards the tree automata workbench marbles3 in the well-known way, trees of the type described above can be assigned a semantics by choosing a domain a and associating an operation on a (of the appropriate arity) with each symbol in the ranked alphabet σ. in other words, a σ-algebra is specified that maps every tree to an element of a. together, a tree generator and an algebra constitute a tree-based generator whose generated language is a subset of a: tree-based generator tree generator interpretationgenerated trees semantic domain a treebag makes it possible to assemble tree-based generators interactively. this makes treebag very flexible, because arbitrary combinations of tree grammars, tree transducers, and algebras can be used. however, in another respect, treebag is quite restricted. all that can be done when a tree-based generator has been assembled is to execute it. in contrast, the usefulness of tree automata in most application areas does not primarily lie in the fact that they can be executed. their real advantage is that they are simple enough to be effectively analyzed and manipulated. for instance, in a model checking application, tree automata may be generated that model safety and liveness properties of a protocol to be verified. analyzing these automata then corresponds to checking correctness criteria. a tool that is supposed to be useful in such situations must make it possible to assemble not only tree automata but also algorithms on tree automata. this means that tree automata are mainly perceived as objects to be analyzed and manipulated, rather than as executable algorithms. marbles is intended to become such a tool. its major purpose is to provide researchers with a software environment and infrastructure that enables them to create, use, and experiment with algorithms on tree automata. in addition to treebag, there are several other systems that implement certain types of tree automata or algorithms on them. autowrite (http://dept-info.labri.fr/∼idurand/autowrite) is a system that allows the user to check properties of term rewrite systems by means of tree automata constructions. in particular, it allows to load, save, and combine bottom-up tree recognizers. using the graphical user interface, one can build and manipulate bottom-up tree recognizers related to the term rewrite systems whose properties one wants to check. forest fire (http://www.loekcleophas.com) is a toolkit focusing on recognition, pattern matching, and parsing algorithms in connection with regular tree languages. the system has been developed on the basis of detailed taxonomies, with the major purpose of gaining a deeper conceptual understanding of how the ideas and techniques used in various tree automata constructions are related to each other. mona (http://www.brics.dk/mona) is a tool for checking the validity of formulas in the weak second-order theory of one successor (ws1s) or of two successors (ws2s). for deciding ws2s, the decision procedures convert a given formula into a so-called guided tree automaton, a variant of a bottom-up tree recognizer, and analyze this automaton. tiburon (http://www.isi.edu/licensed-sw/tiburon) is a command-line based package of algorithms on weighted regular tree grammars, context-free string grammars, and tree transducers, including various analyzers, modifiers, and synthesizers. tiburon has mainly been developed for applications in natural language processing, but can be used for other purposes as well. festschrift h.-j. kreowski 2 / 16 http://dept-info.labri.fr/~idurand/autowrite http://www.loekcleophas.com http://www.brics.dk/mona http://www.isi.edu/licensed-sw/tiburon eceasst timbuk (http://www.irisa.fr/lande/genet/timbuk) is a toolkit for reachability proofs in term rewrite systems, among other techniques by manipulating nondeterministic bottom-up tree recognizers. it is intended to be used for the verification of programs and cryptographic protocols. the proposed system marbles differs from each of these systems in several respects. most notably, the systems above have all been developed with a particular application or problem area in mind. the one that is probably closest to marbles is tiburon. the devices and algorithms implemented in tiburon are typical even for marbles, and it is conceivable that tiburon could, in principle, be extended to include most of the intended functionality of marbles. however, its design was not guided by marbles’ emphasis on a general concept that is reflected in both the graphical user interface and the application programmers interface and that allows the system to be adapted and extended by researchers with different needs. this distinguishes marbles from the other systems. the intention behind it is to support tree automata research in general, by providing researchers with a suitable platform and infrastructure for their own extensions. of course, the list of systems above could be extended by mentioning various implementations of general term rewrite systems, (functional) programming languages based on term rewriting, theorem provers, and systems for executable algebraic specifications, because most of them include tree automata as special cases (at least in the unweighted case). however, the point is that such systems and languages are too general to provide support for the kind of problems marbles is supposed to address. this article is a revised version of [dre09b]. its remainder is structured as follows. the next section presents some aspects of treebag that have, in one way or the other, inspired the intended characteristics of marbles. in section 3, some of the different types of trees, tree automata, and tree automata algorithms that should, in principle, be covered by marbles, are discussed. section 4 presents initial ideas regarding some of the concepts needed for making this possible. finally, section 5 concludes the paper. 2 treebag let us now have a slightly closer look at the concepts and design principles of treebag. the following description is intentionally kept at a rather abstract level. concrete classes of, e.g., tree grammars and algebras in treebag are sometimes mentioned as examples, mainly for readers who happen to be familiar with tree automata theory. readers who want to inform themselves in more detail should consult the treebag user manual (see http://www.cs.umu.se/∼drewes/treebag) or [dre06] for the theory behind. the work on treebag was started during the second half of the 1990s, when the author was a member of hans-jörg kreowski’s research group at the university of bremen. around this time, context-free graph and collage grammars were two of the major research topics of the group; see, e.g., [hkv91, hkl93, hkt93, dhkt95, dk96, dhk97, dk99]. their generative power can be characterized by combinations of a certain type of tree grammar (namely the regular tree grammar) with suitable algebras in the style of mezei and wright [mw67], i.e., the grammars can be viewed as tree-based generators. for graphs, this has been made explicit by engelfriet in [eng94], and for collages by the author in [dre96, dre00]. see also [dekk03], where this characterization was used to establish certain decidability results for collage languages. in [eng80], 3 / 16 volume 26 (2010) http://www.irisa.fr/lande/genet/timbuk http://www.cs.umu.se/~drewes/treebag towards the tree automata workbench marbles4 engelfriet discusses symbolic computation by tree transductions, which is essentially the same idea, applied to transformation rather than generation: a tree transduction, together with algebras interpreting the input and output trees, is considered as a symbolic algorithm that performs a computation on abstract trees rather than on the concrete objects of the two domains in question. although the results mentioned above use only regular tree grammars, it should be obvious that one may in fact combine arbitrary kinds of tree generators with any sort of algebra, yielding a large number of different grammatical formalisms with comparatively little effort. being a rather straightforward implementation of this idea (in java), treebag allows its user to assemble tree-based generators of various kinds. there are four major abstract classes, namely tree grammars, tree transducers, algebras, and displays. the first three represent the corresponding formal concepts, whereas displays show the results of the generating process. concrete subclasses of the four abstract classes implement particular types of tree grammars, tree transducers, algebras, and displays. for example, the classes generators.et0ltreegrammar and generators.mttransducer implement et0l tree grammars and macro tree transducers, resp. (see [eng80, cf82, ev85, fv98] for the latter.) the user can define specific instances (usually in ordinary ascii text files) of such concrete classes and use them in assembling treebased generators. such instances are called components in the following. figure 1 shows a typical situation when working with treebag. window 1 is the main window of the system, the so-called worksheet. when the user loads a component, it is represented on the worksheet as a blob. these blobs represent the nodes of a directed acyclic graph whose edges determine the data flow between components. the data-flow edges are interactively established by the user, subject to a few rather obvious rules: the output of a tree grammar or tree transducer can become the input of any number of tree transducers and algebras, and the output of an algebra can become the input any number of displays. the configuration in figure 1 consists of a regular tree grammar, a free term algebra with a corresponding tree display, a top-down tree transducer, and two copies of a collage algebra, each with its corresponding collage display. with each display component, a window is associated, namely the windows numbered 3–5. these windows show the tree generated by the regular tree grammar, its interpretation by the collage grammar, and the interpretation of the transformed tree by (another instance of) the same collage algebra. an additional window (numbered 2 in the figure) contains buttons that provide access to the user commands of the regular tree grammar. double clicks on the other components on the worksheet would open similar sections in this window, each one being populated by the individual commands understood by the respective component. let us now discuss two aspects of the design of treebag which are expected to have some influence on marbles. in fact, these two aspects are quite closely related and can be seen as the two sides of the same coin. from the point of view of the user, the way in which components can be interconnected depends only on their types, i.e., whether they are tree grammars, tree transducers, algebras or displays. in other words, if the user wants to connect a tree grammar and a tree transducer, this can be done regardless of whether the tree grammar at hand is a regular tree grammar, et0l tree grammar, context-free tree grammar or whatever type of tree grammar might at some point in time be implemented in treebag. of course, users must interconnect the “right” components to achieve the desired effect. every concrete component class provides the user with a set of commands that can be used to interact with components of this class (recall figure 1, where festschrift h.-j. kreowski 4 / 16 eceasst figure 1: a typical configuration of treebag window 2 contains buttons for the commands provided by the implementation of regular tree grammars). while the commands would be different for, e.g., et0l tree grammars, this has no influence on the way in which regular tree grammars or et0l tree grammars can be connected to other components. the person who implements new classes of tree grammars, tree transducers, algebras or displays will find out that the properties mentioned in the previous paragraph simply reflect properties of the implementation. the core of treebag does not make any distinction between, e.g., different classes of tree grammars. in fact, consider the file defining the regular tree grammar used in figure 1: generators.regulartreegrammar("example grammar"): ( { s, a }, { f:2, g:1, a:0 }, { s -> f[s,s], s -> g[a], a -> f[a,a], a -> a }, s ) 5 / 16 volume 26 (2010) towards the tree automata workbench marbles5 when the user instructs treebag to load this component, treebag parses only the first line, to discover that the user wishes to load an instance of generators.regulartreegrammar. the rest of the file uses a syntax which is specific to the implementation of this class and therefore unknown to (the core of) treebag. to handle this, treebag dynamically tries to load the class generators.regulartreegrammar and, upon success, creates an (uninitialized) object of this class. now, it lets this object, which is required to contain a method called parse, initialize itself by parsing the remainder of the file. each of the four abstract component types of treebag requires its concrete subclasses to implement such a parsing method. to handle component-specific user commands, each concrete subclass provides two further methods. the first returns, at any point in time, the list of user commands available at that moment (which means that the list of commands may change), while the second executes a given command. this structure makes it possible to extend treebag by new classes of tree grammars, tree transducers, algebras, and displays in an easy way, without having to change existing parts of the system. one only has to implement it as a subclass of the appropriate abstract component class and place it in the appropriate directory. immediately afterwards (provided that everything has been done correctly), it is possible to load instances of this class onto the worksheet, interconnect them with other components, and work with them. it may be interesting to note that the implementations of some of the classes currently available in treebag make use of decomposition results from the literature. for example, a so-called branching synchronization tree grammar of nesting depth n can be decomposed into a regular tree grammar and a sequence of n top-down tree transducers (see [de04]). during the parsing step, the implementation of this class in treebag performs this decomposition and writes the n+1 components onto the hard disk (in the syntax required by the respective classes). afterwards, it uses treebag’s loading mechanism to load them as internal variables hidden from the user (i.e., so that they do not appear on the worksheet). every user command is basically forwarded to these internal components, and whichever output tree they produce is returned. in this way, the implementation of the class becomes considerably easier and less error prone than a direct one. 3 trees, tree automata, and tree automata algorithms as mentioned in the introduction, the major intended purpose of marbles is to make it possible to apply and experiment with algorithms on tree automata. the aim is to design marbles in such a way that it accommodates virtually all kinds of tree automata algorithms. while this does not mean that all such algorithms should readily be implemented in the system, the design of marbles should enable researchers (and application programmers) interested in a particular type of algorithm on tree automata to make the necessary extensions. as in the case of treebag, this should be possible without changes to existing parts. however, compared to treebag, the design challenge is considerably bigger for marbles, because its intended coverage is much wider. it seems to be reasonable to distinguish between (at least) three central categories of objects: trees, tree automata, and tree automata algorithms. each of them may, in principle, have any number of subcategories one may wish to implement in marbles. in the following, some of the possible subcategories of each will be discussed to illustrate this point. festschrift h.-j. kreowski 6 / 16 eceasst 3.1 trees in the traditional setting (and in treebag), tree automata work on trees over ranked alphabets, as explained above. this is appropriate, because trees are supposed to be evaluated by algebras by associating with every symbol of rank k a k-ary function on some domain. however, tree automata on unranked trees have received a lot of attention during recent years. in this setting, symbols are unranked, and the number of children of a node does not depend on its label. it turns out that this variant is well suited for applications in connection with xml, because xml documents can appropriately be viewed as unranked trees. (for example, a node corresponding to a list structure in html may have any number of children of type list item.) thus, an xml document type corresponds to a tree language of unranked trees, and a tree transducer on unranked trees corresponds to a transformation between xml document types. while the two types of trees mentioned are the only ones that play a major role in contemporary research on tree automata, this situation may change in the future. thus, marbles should allow programmers to implement other classes of trees than just these. 3.2 tree automata tree automata can be classified according to various criteria. an important observation is that the resulting classifications are, to a rather large extent, orthogonal. perhaps the most obvious classification is the one that gave rise to the structure of treebag, namely the distinction between tree grammars, tree recognizers (which are not directly available in treebag), and tree transducers. from an abstract point of view, a tree grammar is a formal device that generates output trees without requiring input. as usual, the tree recognizer is the dual concept. it takes a tree as input and computes an output value, usually in the range {0, 1}, indicating whether the tree is accepted or not. finally, a tree transducer is a formal device transforming input trees into output trees. the second classification distinguishes between tree automata according to the type of trees they act upon, i.e., tree automata on ranked or unranked trees. each of the types of tree automata in the first classification can be ranked or unranked. in this sense, these two classifications are orthogonal. in fact, one may even wish to consider tree transducers that turn unranked trees into ranked ones, or vice versa. finally, one may consider weighted tree automata [fv09], which deal with tree series instead of tree languages. a tree series is a mapping ψ : tς → s, where tς denotes the set of all trees over a given alphabet, and s is a semiring. in other words, weighted tree automata generalize the traditional case, which is obtained by choosing the boolean semiring. even this third classification is orthogonal to the two previous ones, provided that the used definition of tree automata is general enough to include the weighted case. it is interesting to note that, from an abstract point of view as well as from the point of view of system design, weighted tree recognizers are very similar to algebras. both take a tree as input and compute a value in some other domain. in fact, this observation yields one of the possible ways to define the semantics of weighted tree automata. the initial algebra semantics of a weighted tree automaton a over a semiring s associates a σ-algebra a with a [fv09, pp. 322–323]. the domain of a is sk, where k is the number of states of a. the evaluation of 7 / 16 volume 26 (2010) towards the tree automata workbench marbles6 a tree with respect to a yields the tuple of weights carried by the states at the root node of the tree. 3.3 algorithms on tree automata many useful algorithms on tree automata have been described in the literature. for classification purposes, it is useful to distinguish between analyzers, synthesizers, and decomposition algorithms. an analyzer for tree automata takes a tree automaton as input and analyses it with respect to certain properties. well-known examples are algorithms that decide whether the language represented by a tree recognizer or tree grammar is empty or whether it is finite (cf., e.g., [de98]). a synthesizer is an algorithm that takes zero or more tree automata (and maybe some additional data) as input and yields a tree automaton as output. there are various important types of synthesizers: • a generator is an algorithm that outputs tree automata without requiring other tree automata as input. a prominent example is given by grammatical inference algorithms for tree automata. these are algorithms whose purpose it is to “learn” tree languages. for this, the algorithm is provided with some source of information regarding the tree language (or tree series) to be learned, such as positive and negative examples. the algorithm is then expected to construct a tree automaton representing the tree language in question. see, e.g., the references in [dre09a] for a variety of approaches. conceptually, a tree automaton a may be considered as a generator that outputs the constant value a. • conversion algorithms take a tree automaton as input and yield another tree automaton as output, usually with the same semantics as the input automaton. well-known examples are conversions between regular tree grammars and finite-state tree recognizers and algorithms that minimize tree automata, make them deterministic, remove useless states or nonterminals, etc (see, e.g., [cdg+07]). there are also conversion algorithms that do not retain the semantics of the tree automaton they are applied to. for example, a macro tree transducer mtt may be turned into a finite-state tree recognizer that accepts the pre-image of the tree transformation computed by mtt. a conversion algorithm that inverts suitable types of top-down tree transducers would be another example. • composition algorithms turn n tree automata (n > 1) into one. a wealth of such algorithms can be found in the literature. one type of example is, of course, given by composition in the strict sense. for instance, certain types of tree transductions are known to be closed under composition. another example is the main result of [de04], which provides an algorithm for converting a regular tree grammar g and n top-down tree transducers td1, . . . , tdn into a branching synchronization tree grammar generating the image of l(g) under tdn ◦···◦ td1. composition algorithms in a more general sense may not perform mathematical composition, but combine tree automata in a different way. for example, two finite-state tree recognizers can be turned into one that recognizes the intersection of the tree languages recognized by the two individual automata. festschrift h.-j. kreowski 8 / 16 eceasst finally, decomposition algorithms are the conceptual inverse of composition algorithms, turning one tree automaton into several others. for example, for {x, y} = {top-down, bottom-up}, every x tree transducer may be decomposed into two y tree transducers [eng75]. a similar example is given by the result that every deterministic total macro tree transducer may be decomposed into a top-down tree transducer followed by a yield mapping [ev85]. of course, algorithms on tree automata may additionally be classified by the types of tree automata they work on, similarly to the way in which tree automata can be classified. 4 a proposed attribute type system for marbles as mentioned earlier, the goal behind the development of marbles is that it should allow its user to assemble configurations of tree automata algorithms in a similar way as treebag allows its user to assemble various sorts of tree-based generators. in particular, there should be a way to load components representing (tree automata and) tree automata algorithms, establish a dataflow relation between them, and execute them. however, while treebag comes with a fixed set of component types, something like this is neither possible nor desirable for marbles. in contrast, users should be given the possibility to define and implement their own classes of tree automata algorithms and experiment with them. the following two fictitious scenarios try to illustrate this.7 scenario 1: test environment for minimization algorithms. doctoral student x works in a research group using bottom-up tree recognizers for model checking purposes. a typical example is the verification of a process communication protocol p by generating a tree recognizer ap that models the system behavior p causes, and then analyzing ap to establish p’s correctness. the problem is that ap tends to be unnecessarily huge, so that its analysis takes too much time. unfortunately, ap is also nondeterministic, which means that it cannot efficiently be minimized. therefore, in her thesis, x proposes and studies a number of efficient heuristics for reducing nondeterministic tree recognizers a in size (called minimization, for simplicity). the general technique used is to compute a suitable equivalence ≡ on the state set of a, such that the quotient automaton a/≡ accepts the same language as a. the various heuristics studied differ only in the concrete definition (and computation) of ≡. besides studying the minimization algorithms theoretically to establish their correctness and worst case complexity, x wants to study empirically how they behave on real examples arising in the model checking context, in terms of size reduction and efficiency. however, x does not have the time to implement a test environment for her algorithms from scratch, in addition to her theoretical studies. therefore, she decides to use marbles. first, she notices that there is a type of tree automata algorithm called generator, a special type of synthesizer. she defines and implements a simple generator which lets the user choose the name of a protocol (from a fixed set of possible choices) and possibly some other parameters. 7 while being fictitious, the scenarios have a real background, as they are inspired by [kaa08] and ongoing work in our own group, resp. 9 / 16 volume 26 (2010) towards the tree automata workbench marbles9 the generator will then output nondeterministic bottom-up tree recognizers of increasing size, whenever the user presses a certain button. next, x discovers that there are so-called converters, and decides to implement a new type of converter as an abstract class. a concrete implementation is obtained by providing a method that, for a given bottom-up tree recognizer a, computes an equivalence relation ≡ on the states. the converter will then return a/≡. fortunately, x finds out that someone else has already implemented two useful auxiliary components. one of them is a wrapper for arbitrary converters that simply executes them, but also reports how much time the execution takes. the other one takes bottom-up tree recognizers as input and saves some statistics about them to a file, such as the number of states and transitions. now, x has everything needed to make the desired tests. all she has to do is to implement the different algorithms yielding the equivalence relations ≡, load and interconnect the required components, and execute them. scenario 2: simulation of minimal adequate teachers using corpora. the research group in which researcher y is working has previously studied grammatical inference algorithms that, within angluin’s learning model of a minimal adequate teacher (mat), construct a bottom-up tree recognizer for a recognizable tree languages l. now, they want to find out whether such an algorithm can be used to learn the syntax of natural languages reasonably well, where the necessary data is taken from a corpus.8 the major obstacle is the mat, an oracle capable of answering two types of queries, namely membership queries (is the tree t in l?) and equivalence queries (does the bottom-up tree recognizer a satisfy l(a) = l? if not, return a counterexample.) clearly, a mat is not available in the situation sketched above. the research question is whether it can (imperfectly) be simulated on the basis of a corpus, so that the inference algorithm as a whole runs with reasonable efficiency and yields acceptable results. y decides to try out some approaches and to use marbles for that purpose. thus, she defines two new types of algorithms, namely mats and learners. a learner is a generator that must be connected to a mat to create a tree automaton. during the first phase, she only wants to test different realizations of the mat, to see whether the results are promising enough to continue. therefore, she implements a single learner (e.g., any of those in [dre09a]). in contrast, a variety of different mats are implemented, using different approaches for answering membership and equivalence queries based on a corpus. to find out how good the various approaches are, y implements a component that has access to a sufficiently large sample of positive and negative examples. it takes a tree recognizer as input, runs it on the samples, and returns statistics regarding its sensitivity and specifitivity. in a second phase of her research work, y even wants to study other variants of the learner, which can be done in the same setting by replacing one learner with another. in scenarios such as those above, the researcher who wants to use marbles must implement certain extensions, new types of tree automata and algorithms that become components of marbles. the central idea behind marbles is that the developer can easily tell the system 8 a corpus is a manually analyzed and annotated database of sentences in a natural language. festschrift h.-j. kreowski 10 / 16 eceasst how the implemented extensions can be used and, in particular, how the new components can be combined with others. thus, there must be a possibility to describe the types of components in an easy and flexible way. rather than defining a strict typing system, the goal is to enable developers to communicate the major properties of new components to both marbles and its users. thus, one needs a way to name the basic data types and relate them with each other. the solution proposed here is an extensible hierarchy of attributes. to see where the hierarchy comes in, consider the case of binary ordered trees. the property of being binary should be expressed by an appropriate attribute, for example, by giving the attribute uniformrank the value binary. however, since binary trees are essentially a special case of ranked trees, one may wish to reserve this attribute for ranked trees, which means that one should be allowed to specify uniformrank only under the premise that the tree is ranked, which may be indicated by the attribute ranked having the value true. independently of whether or not the tree is ranked, it may be ordered or not. the latter could be expressed by assigning the attribute ordered the value true or false. however, both ranked and ordered make sense only for trees. thus, their premise could be that the attribute class associated with the data structure in question has the value tree. this attribute may be an “outermost” one, meaning that it does not have a premise and can, thus, be the root of the hierarchical structure. in summary, binary ordered trees could be designated a tree of attribute assignments of the form tree class[trueranked[binaryuniformrank], trueordered], designating a basic type in marbles. the following definition formalizes this notion. definition 1 (attribute trees and basic types) 1. let attr be a finite set of attributes a, each having a finite set v (a) = {v1, . . . , vn} of possible values. for v ∈ v (a), let va denote the assignment of v to a. the set of all such assignments is denoted ass(attr). 2. for all a∈attr, assume that an attribute assignment prem(a)∈ass(attr)∪{⊥}, called the premise of a, is specified. the set of all attribute trees is defined inductively, as follows. (a) every va ∈ ass(attr) is an attribute tree with root attribute a. (b) for all attribute trees t1, . . . ,tn whose root attributes are pairwise distinct and have the same premise va, va[t1, . . . ,tn] is an attribute tree with root attribute a. 3. an attribute tree whose root attribute has the premise ⊥ is a basic type. the set of basic types is denoted by basic. it should be noted that attribute trees (and, thus, basic types) are loose specifications in the sense that they do not generally refer to a specific data type. the rationale behind this is that it should be possible to specify only those attributes that are of interest in a given situation. for example, consider a class of algorithms working on, e.g., tree grammars. if it is essential that the trees generated by these tree grammars are binary ordered trees, then the basic type discussed above may be appropriate. however, if the algorithms work on any type of ranked trees, ordered or not, then the more general basic type treeclass[trueranked] is more appropriate. 11 / 16 volume 26 (2010) towards the tree automata workbench marbles10 note that no specific semantics or implementation is associated with the attributes. it should, however, be possible to do this in marbles by, e.g., associating an attribute with formal semantic requirements, or with an abstract class in the implementation. how this can be done in the most appropriate way is an interesting topic for future work. a similar remark applies to the types at the higher levels discussed next. the next definition concerns automaton types. it takes a very general approach, where an automaton is a device that turns a finite number of input values of specified basic types and into a finite number of output values, also of specified basic types. definition 2 (automaton type) an automaton type is a pair (in, out) with in ∈ basick and out ∈ basic l for some k, l ≥ 0. such a type will normally be written as in → out. the set of all automaton types is denoted by aut . as an example, a tree grammar of the most general form could be described as being an automaton of type () → (treeclass). in other words, it takes no input and yields any type of tree as output. note that such an automaton type does not say much about how the actual implementation of an automaton behaves, which kinds of operations it provides, and so on. for example, reasonable types of tree grammars are always nondeterministic. implementations should therefore provide a means to enumerate the generated trees or nondeterministically generate one. automaton types may specify such details if necessary, but they need not. in the most specific case, an automaton type may be associated with a particular class in the implementation. the level of detail used may vary depending on the situation. slightly more specific than the type () → (treeclass) would be the type of tree grammars generating ranked trees, namely () → (treeclass〈trueranked〉). for weighted tree automata over a semifield that work on ranked trees, the type (treeclass〈trueranked〉) → (semiringclass〈hasinversesprop〉) could be an appropriate description, and for tree transducers on unranked trees one could use (treeclass〈falseranked〉) → (treeclass〈falseranked〉). though uncommon in the literature, one may also wish to consider, e.g., tree transducers that take two trees as input and produce one output tree, the corresponding type being (treeclass, treeclass) → (treeclass). note that the concept is very general. for example, an algebra can be seen as an automaton of type (treeclass〈trueranked〉) → (anyclass), if anyclass is assumed to be the most general basic type, standing for arbitrary data. also weighted tree automata over multioperator monoids [kui00] have this type. clearly, the concept covers even devices that do not work on trees at all. thus, in principle, marbles may even be extended to automata on other structures, such as graphs. finally, the next definition makes it possible to specify types of algorithms on tree automata. definition 3 (algorithm type) the set alg of algorithm types is inductively defined to be the smallest set containing all triples (in, use, out) such that, for some k, l, m ≥ 0, in ∈ aut k, out ∈ aut m, and use ∈ algl . such a triple is denoted by in use−→ out. the intuitive interpretation of in use−→ out is that of an algorithm which turns inputs according to in into outputs according to out, thereby possibly making use of other algorithms given by use. a typical example is the mat learner in scenario 2, which could be of the type () mat−−→ (ta), where ta is the automaton type treeclass〈trueranked〉→ boolclass. festschrift h.-j. kreowski 12 / 16 eceasst as mentioned earlier, one of the ideas behind marbles is that its gui, similar to the one of treebag, should allow the user to assemble configurations of tree automata in order to experiment with them. the basic (and still somewhat tentative) plan is that every implementation of a class of tree automata or tree automata algorithms comes with a specified type according to the definitions above. when the user loads an instance of such a component, this information is used in order to determine which connections between these components are possible. the idea is that an algorithm of the type in definition 3 will, from the point of view of the user, have k + l + m slots representing the inputs, the used algorithms, and the outputs. for instance, if a component has an output slot s of type treeclass〈trueranked〉→ boolclass (a recognizer for ranked trees) and another one has an input slot s′ of type treeclass → boolclass (a recognizer for any sort of trees), then the data flow can be directed from s to s′. 5 concluding remarks in this paper, ideas and plans regarding a successor of the system treebag have been presented. while this work is still in a very preliminary phase, the overall goal is clear. marbles should make it possible to experiment with configurations of tree automata algorithms in a similar way as treebag makes it possible to experiment with tree-based generators. moreover, marbles should be extensible by researchers who are not directly involved in the development of the system itself, but want to use it for their own purposes. for this, concepts such as those presented in section 4 seem to be a necessity, because the gui must be able to handle extensions without explicitly being adapted. an aspect that has not been discussed in the present paper, but which is a necessity as well, is to provide programmers with a well-documented library and a clearly structured application programmer’s interface (api). without this, it would be too difficult, error prone, and time consuming for other researchers to make their own extensions. in fact, it should also be possible to make use of the api without adopting the rest of marbles, and especially its gui. this would give programmers the possibility to apply tree automata algorithms in their own applications. another aspect that has not yet been decided upon is whether and to what extent marbles shall be compatible and able to interoperate with other systems dealing with tree automata, such as those mentioned in section 1. acknowledgements: i thank the anonymous referees for their unusually thorough reading of the manuscript, resulting in many appreciated comments, suggestions, and corrections. most of all, however, i want to thank you, hans-jörg, for your support during all those years, for teaching me so much about our profession, and for being a good example in all respects. i wish you many more years of continued scientific productivity to come, and want to conclude this paper by paraphrasing the final sentence you once formulated in our survey paper [dk99]: whichever serious goals one aims at in the investigation of theoretical formalisms, they can also be great fun! 13 / 16 volume 26 (2010) towards the tree automata workbench marbles11 bibliography [ajmd02] p. a. abdulla, b. jonsson, p. mahata, j. d’orso. regular tree model checking. in brinksma and larsen (eds.), proc. 14th intl. conf. on computer aided verification (cav’02). lecture notes in computer science 2404, pp. 555–568. 2002. [bor04] b. borchardt. code selection by tree series transducers. in domaratzki et al. (eds.), proc. 9th intl. conf. on implementation and application of automata (ciaa 2004). lecture notes in computer science 3317, pp. 57–67. springer, 2004. [cdg+07] h. comon, m. dauchet, r. gilleron, f. jacquemard, c. löding, d. lugiez, s. tison, m. tommasi. tree automata techniques and applications. internet publication available at http://tata.gforge.inria.fr, 2007. release october 2007. [cf82] b. courcelle, p. franchi-zannettacci. attribute grammars and recursive program schemes i, ii. theoretical computer science 17:163–191, 235–257, 1982. [de98] f. drewes, j. engelfriet. decidability of the finiteness of ranges of tree transductions. information and computation 145:1–50, 1998. [de04] f. drewes, j. engelfriet. branching synchronization grammars with nested tables. journal of computer and system sciences 68:611–656, 2004. [dekk03] f. drewes, s. ewert, r. klempien-hinrichs, h.-j. kreowski. computing raster images from grid picture grammars. journal of automata, languages and combinatorics 8:499–519, 2003. [dhk97] f. drewes, a. habel, h.-j. kreowski. hyperedge replacement graph grammars. in rozenberg (ed.), handbook of graph grammars and computing by graph transformation. vol. 1: foundations. chapter 2, pp. 95–162. world scientific, singapore, 1997. [dhkt95] f. drewes, a. habel, h.-j. kreowski, s. taubenberger. generating self-affine fractals by collage grammars. theoretical computer science 145:159–187, 1995. [dk96] f. drewes, h.-j. kreowski. (un-)decidability of geometric properties of pictures generated by collage grammars. fundamenta informaticae 25:295–325, 1996. [dk99] f. drewes, h.-j. kreowski. picture generation by collage grammars. in ehrig et al. (eds.), handbook of graph grammars and computing by graph transformation, vol. 2: applications, languages, and tools. chapter 11, pp. 397–457. world scientific, singapore, 1999. [dre96] f. drewes. language theoretic and algorithmic properties of d-dimensional collages and patterns in a grid. journal of computer and system sciences 53:33–60, 1996. [dre00] f. drewes. tree-based picture generation. theoretical computer science 246:1–51, 2000. festschrift h.-j. kreowski 14 / 16 http://tata.gforge.inria.fr eceasst [dre06] f. drewes. grammatical picture generation – a tree-based approach. texts in theoretical computer science. an eatcs series. springer, 2006. [dre09a] f. drewes. mat learners for recognizable tree languages and tree series. acta cybernetica 19:249–274, 2009. [dre09b] f. drewes. towards the tree automata workbench marbles. in drewes et al. (eds.), manipulation of graphs, algebras and pictures. essays dedicated to hansjörg kreowski on the occasion of his 60th birthday. pp. 83–98. 2009. [eng75] j. engelfriet. bottom-up and top-down tree transformations – a comparison. mathematical systems theory 9:198–231, 1975. [eng80] j. engelfriet. some open questions and recent results on tree transducers and tree languages. in book (ed.), formal language theory: perspectives and open problems. pp. 241–286. academic press, new york, 1980. [eng94] j. engelfriet. graph grammars and tree transducers. in tison (ed.), proceedings of the caap 94. lecture notes in computer science 787, pp. 15–37. springer, 1994. [ev85] j. engelfriet, h. vogler. macro tree transducers. journal of computer and system sciences 31:71–146, 1985. [fgv04] g. feuillade, t. genet, v. viet triem tong. reachability analysis over term rewriting systems. journal of automated reasoning 33:341–383, 2004. [fsw94] c. ferdinand, h. seidl, r. wilhelm. tree automata for code selection. acta informatica 31(8):741–760, 1994. [fv98] z. fülöp, h. vogler. syntax-directed semantics: formal models based on tree transducers. springer, 1998. [fv09] z. fülöp, h. vogler. weighted tree automata and tree transducers. in kuich et al. (eds.), handbook of weighted automata. chapter 9, pp. 313–403. springer, 2009. [gk00] t. genet, f. klay. rewriting for cryptographic protocol verification. in mcallester (ed.), proc. 17th international conference on automated deduction (cade’00). lecture notes in computer science 1831, pp. 271–290. 2000. [gkm08] j. graehl, k. knight, j. may. training tree transducers. computational linguistics 34(3):391–427, 2008. [gs84] f. gécseg, m. steinby. tree automata. akadémiai kiadó, budapest, 1984. [gs97] f. gécseg, m. steinby. tree languages. in rozenberg and salomaa (eds.), handbook of formal languages. vol. 3: beyond words. chapter 1, pp. 1–68. springer, 1997. [hkl93] a. habel, h.-j. kreowski, c. lautemann. a comparison of compatible, finite, and inductive graph properties. theoretical computer science 110:145–168, 1993. 15 / 16 volume 26 (2010) towards the tree automata workbench marbles12 [hkt93] a. habel, h.-j. kreowski, s. taubenberger. collages and patterns generated by hyperedge replacement. languages of design 1:125–145, 1993. [hkv91] a. habel, h.-j. kreowski, w. vogler. decidable boundedness problems for sets of graphs generated by hyperedge-replacement. theoretical computer science 89:33–62, 1991. [kaa08] l. kaati. reduction techniques for finite (tree) automata. doctoral dissertation, uppsala university, sweden, 2008. [kg05] k. knight, j. graehl. an overview of probabilistic tree transducers for natural language processing. in gelbukh (ed.), proc. 6th intl. conf. on computational linguistics and intelligent text processing (cicling 2005). lecture notes in computer science 3406, pp. 1–24. springer, 2005. [kui00] w. kuich. linear systems of equations and automata on distributive multioperator monoids. in dorninger et al. (eds.), proc. 58th workshop on general algebra (1999). contributions to general algebra 12, pp. 247–256. johannes heyn, klagenfurt, 2000. [löd02] c. löding. model-checking infinite systems generated by ground tree rewriting. in nielsen and engberg (eds.), proc. 5th intl. conf. on foundations of software science and computation structures (fossacs’02). lecture notes in computer science 2303, pp. 280–294. 2002. [mw67] j. mezei, j. b. wright. algebraic automata and context-free sets. information and control 11:3–29, 1967. [np92] m. nivat, a. podelski (eds.). tree automata and languages. elsevier, amsterdam, 1992. [sch07] t. schwentick. automata for xml a survey. journal of computer and system sciences 73(3):289–315, 2007. festschrift h.-j. kreowski 16 / 16 introduction treebag trees, tree automata, and tree automata algorithms trees tree automata algorithms on tree automata a proposed attribute type system for marbles concluding remarks evaluation of the technology agnostic service creation approach electronic communications of the easst volume 27 (2010) workshop über selbstorganisierende, adaptive, kontextsensitive verteilte systeme (saks 2010) evaluation of the technology agnostic service creation approach sian lun lau, niklas klein, andreas pirali, olaf droegehorn and klaus david 12 pages guest editors: klaus david, michael zapf managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst evaluation of the technology agnostic service creation approach sian lun lau, niklas klein, andreas pirali, olaf droegehorn and klaus david comtec@uni-kassel.de, http://www.comtec.eecs.uni-kassel.de/ chair for communication technology (comtec), university of kassel, kassel abstract: the current computing and communication services provide convenience and functionality. the creation of these services is however not an easy task. service development is still mainly technical oriented, where service creation tools are meant for serving and assisting the professional developers. in other words, service creation is not seen as a task for end-users. in our research, we wish to enable service creation for the end-users. this is achieved by introducing the technology agnostic approach into the process. in this paper, we present the conceptual architecture as the proposed solution. prototype tools were designed and implemented as proof of concept. an evaluation event was held to obtain user feedback on the approach and the prototype tools. this paper presents and discusses the outcome of the evaluation. keywords: service creation, technology agnostic, semantic service description, end-users 1 introduction services in the computing and communication technologies play an important role in our daily lives. the services simplify tasks and automate routines, so that we can enjoy the convenience brought. currently, most services are created by professional developers, who have the necessary technical knowledge. this is due to the fact that service creation is a resource demanding and complex process. different factors contribute to this, such as the heterogeneity of devices, availability of software platforms on different devices and communication interoperability. for a person who does not posses the necessary technical know-how, for instance an end-user, it can be rather difficult to create services he needs. in today’s service creation cycle, an end-user is only seen as a service consumer. he should only use the services that are provided to him. if the end-user needs new services, he is not able to create them by himself unless he acquires the needed service creation skills, such as programming. in our research, we have the vision to enable service creation for everyone. our objective is to remove the technical barriers that might have hindered non-technical users from taking part in the service creation process. the users are the one who know their needs best. users can make own decisions in creating, obtaining and using their desired services, when the appropriate service creation tools are available. at the same time, the developers can concentrate more on functionality development. based on the above vision we have proposed the technology agnostic service creation (tasc) architecture [lkp+08]. based on the architecture prototype tools were implemented as 1 / 12 volume 27 (2010) mailto:comtec@uni-kassel.de http://www.comtec.eecs.uni-kassel.de/ evaluation of the technology agnostic service creation approach proof of concept. an evaluation was carried out to investigate how the approach can be applied in the designated environment. we wish to obtain feedback that can help to improve the approach and to allow real usage of the tasc approach. this paper gives a brief overview of the tasc approach, and presents a report on the evaluation of our concepts. the structure of the paper is as follows: section 2 presents a brief summary of related work in the area of service creation. section 3 gives an overview on the tasc approach. the evaluation methodology is elaborated in section 4, and is followed by the evaluation results, feedback and suggestions summary. section 7 will conclude the paper. 2 state of the art when it comes to service creation, most people will naturally categorize the tasks of service creation as the developers’ responsibilities. this includes using programming and development tools (such as compilers, interpreters and ides) to create services with a certain programming language. in order to simplify and to open up service creation tasks to potential users other than professional developers, different technologies and approaches have been introduced. the idea of reusable software component modules [szy97] [ws01] can potentially be a good idea to reduce technical complexity of the service creation process. the created modules can be packaged to be applied in a designated service creation tools. one popular approach is the graphical development tool. these tools translate graphical diagrams into programming languages. for instance, the development tool fujaba [fuj] can generate java source code from the produced system design that consists of unified modelling language (uml) class diagrams and uml behaviour diagrams. such approaches simplify the development process, and are able to visually represent the service logic and workflow. but they are still considerably technically demanding. the uml classes and behaviour representations are direct representations of source code level information. these tools are actually enhanced development tools for developers. they enable developers to design services in modelling languages. this can help them to refine the designed service. they are not intended to enable service creation for end-users. in the field of end-user programming, there are also efforts in providing end-users the means to create services without in-depth knowledge of a specific programming language. tools such as the agentsheet [rep93], icap [sd03] and topiary [lhl04] provide developers the possibility to create applications without code writing. these tools focus on simulation and prototypes for the designated environment, hence do not provide the solution in areas like service deployment, life cycle management and semantic service description. however, the graphical interface approach used is in line with our idea. with the emergence of web services and service oriented architecture, there are also other service creation examples. reusable service components can be created as open and standardized elements. with protocols such as soap and uddi, one can search, locate and use desired components in a given environment. several works have been carried out to investigate how easy service creation and composition can be enabled. among them are jopera [pha06] and pilote [as01]. most of them provide the possibilities to model the workflow and process using bpel visually and allow execution via an underlying bpel engine. these approaches demonstrated how one can use visual tools to compose services with available web services in a given saks 2010 2 / 12 eceasst environment. but users are still required to know and to understand the web services and their features directly. the above approaches focus on visual bpel workflow representation. users are not aided directly in expressing their service needs and desire semantically. they will still need a sufficient amount of technical know-how in order to perform service creation tasks. since the start of web 2.0 services, the concept of mash-ups was introduced. the idea is to aggregate and delegate data from different web services to create new services. in the meantime, there are mash-up web editors that assist the mash-ups creation process, such as yahoo! pipes 1. these tools enable the creation of web-data processing and presentation applications. from our observation, the mash-up concepts are comparatively limited because they are more towards content aggregation and manipulation. there is also no semantic-based approach to locate and to use potential web 2.0 services. the investigation of the various approaches above shows that the direction of technology agnostic approach has its potential in bringing service creation to common users. the migration from manual coding to visually aided composition indicates simplification without sacrificing functionality. however, most of the approaches are still technically demanding and are complex for people who have no programming knowledge. there are also no solutions where users can freely express their service needs without directly understanding the provided components or building blocks. 3 technology agnostic service creation (tasc) approach from our observation, the main obstacles in enabling service creation for the end-users are the complexity and technical issues. without sufficient know-how, they are not able to create services that can be used to answer to their daily needs. the tasc approach provide service creation tools that enable the end-users to create services using non-technical expressions. if the supporting service creation platform is capable of processing these expressions, it can trigger and execute the needed functionality. in this section, we presents a brief overview of the tasc approach. details of this approach can be found in [lkp+08]. in the tasc approach, services are defined as a composition of service building blocks (sbb). the concept of sbb is similar to the concept of enablers, specified by the open mobile alliance (oma) [all]. each sbb provides a specific function. therefore, if we can provide a possibility for an end-user to compose a desired service by putting the needed sbb together in a non-technical way, this will be the answer to the question above. contrary to today’s service creation approaches, the professional developers are responsible for the sbb development. the end-users are responsible to create services according to their own needs. we use a simple scenario to explain our concept. an end-user wants to publish his location on the micro-blogging site twitter2. if he is at home, the service should post “at home”. if he reaches his office, the service will update his twitter page with “at work”. the challenge is: how can the end-user create a service that performs the above tasks, without any programming knowledge or the need to acquire technical know-how? we assume that the end-users can express their service needs in a non-technical way. they 1 http://pipes.yahoo.com/pipes/, last visited on 10th january 2010 2 http://www.twitter.com/, last visited on 10th january 2010 3 / 12 volume 27 (2010) evaluation of the technology agnostic service creation approach figure 1: the visualization of a service using sbbs can use terms and logical relationships to describe the nature of the desired services. hence the visual service editor (vse) was developed as a prototype tool that simplifies this process. end-users can use the graphical blocks and expressions to “draw-a-service” (fig. 1). most of the time, we foresee the expressions can be described using the “if...else...” relationship. therefore we chose ruleml [rul] as the representation language for the “drawn” services. as illustrated in the fig. 1, the desired service mentioned in the scenario above can be created using 4 sbbs. two different sbb categories were defined in our approach. firstly, we have the state sbbs, which are used as context providers. secondly, we have the action sbbs, which triggers a desired action. the state sbbs provide information updates that are used as conditions to trigger action sbbs. in our scenario the location sbb is an example of state sbb, whereas the twitter sbb is an action sbb. besides the vse, we have also proposed another tool that aims to simplify the development of sbbs for a given service execution environment (see). we observed that for different sees there are usually specific requirements and development routines to follow. these processes are usually recurring, and can be automated or assisted. the prototype plug-in we have developed is targeted on our see the wireless-internet platform (wi-p) [wdd04]. by using the plugin, wi-p specific interfaces are created automatically upon creation of a new sbb development project. tasks such as packaging, deployment and service description generation are also assisted with wizards and menus. the purpose of this tool is to reduce the workload of developers in creating sbbs for a given see. in this way they can focus on the sbb functionality development and let the plug-in to handle the recurring processes. one can even reuse the created codes to develop sbbs for multiple sees, when corresponding plug-ins are available. the plug-in for professional developers is found on layer 1. the realisation of the tasc depends on the semantic sbb discovery and description layer (layer 2). this layer is responsible in translating and linking the technology agnostic expressions to the designated sbbs. the use of a semantic sbb description enables the functionality to be described in a meaningful high-level sense. the semantic sbb discovery searches for the bestmatched sbbs so that the see can execute them at runtime. currently we use only simple keywords and domain terms to describe sbbs. in the see we use the business rule evaluator (bre) component to search and trigger sbbs. it uses a rule engine to evaluate the produced service in ruleml. the component first locates the corresponding state sbbs to gather necessary information for the rule evaluation. the outcome saks 2010 4 / 12 eceasst of the rule evaluation is used to trigger the designated action sbbs. as an example from the scenario, the bre queries a sbb that provides location information. if the location sbb returns “home”, the bre will then request the twitter sbb to post the message “at home”. 4 evaluation event there were altogether 25 participants in the evaluation event. the event was divided into three parts. the participants are from diversified backgrounds. there are some developers among them. they provide evaluation from a developer’s point of view for potential end-users. we also had some participants from the business sector. they are part of our targeted audience they can be potentially the user group who wishes to create services for their needs without the requirement of technical know-how. in the first part of the event, participants were presented with the core concepts of the service creation approaches, such as an introduction to the tasc approach, semantic service description and discovery. the goal was to allow the participants to obtain the necessary background knowledge. the prototype service creation tools were introduced next. the tools were placed at different stations, and the participants were invited to test them in three groups. moderators were assigned to ensure that the participants understood the functions and features of the tools, and to guide them in using these tools. the participants were encouraged to ask questions in order to provide them better understanding on the realisation of the tasc approach. we selected some scenarios and the participants were requested to realise these scenarios using the prototype tools. for example, they were expected to create a sbb using the ide plugin that performs a twitter update. with the created sbb, the participants then used the vse to compose a service that sends a message via the twitter sbb upon location change. when service composition was completed, the participants tested the deployment process to see whether the service was working as expected. the last part of the event was the evaluation. instead of using the conventional questionnaire approach, meta-planning [wil80] was used to provide a more intuitive and efficient evaluation. before the event intended evaluation areas were first identified and selected. the evaluation questions were then generated in forms of charts and boxes. the participants answered them on flip charts, where answers were given in forms of voting, drawings or writings. facilitators led and guided this process. this approach allows us to have discussions during the answering session. this enabled a two-way communication to sum up the evaluation opinions and critics. the evaluation ended with the summary and discussion of the evaluation results. the interaction helped not only us to understand the comments and feedback from the participants, but also clarified some uncertainties concerning our approaches. besides that, the participants also discussed and presented some suggestions for the next steps and further potential research focuses. these evaluation results will be presented in the coming sections. 5 evaluation questions and results this section will present the evaluation results. each subsection consists of a question put forward to the participants and a summary of the respective answers and feedback. the first two 5 / 12 volume 27 (2010) evaluation of the technology agnostic service creation approach questions focused on the prototype tools, while the rest of the questions intended to investigate the general ideas of the service creation approach. the questions were presented in chart or table form, where participants can freely provide their answers accordingly. in the following sub-sections the questions and answers will be elaborated. the colours of the provided feedback indicate answers from the three different groups of participants. 5.1 q1: how do you rate the usability of the visual service editor? the participants were expected to write their answers in the given table. the usability evaluation was divided in four categories: strength, weaknesses, opportunities and threats. as seen in figure 2: evaluation results on the vse usability fig. 2, there was mixed feedback concerning the usability of the vse. some agreed that such a graphical tool can provide simple rule composition and hide the complexity. the abilities to deploy, test and debug composed services were also noted as strength. this was observed from the rule-based service execution and triggering, since composed services can be tested immediately. the participants also mentioned about opportunities in sbbs development, where third party development and new service developers can be encouraged and increased through the proposed approaches. the usability evaluation revealed some potential issues. the graphical approach currently has a lack of syntax and consistency check for sbbs. this was seen as a crucial issue if the amount and complexity of sbbs increase. at the same time, several possible threats were also highlighted by the participants. among them were potential security threats, drawing complexity and loose coupling between sbbs and the drawn services. 5.2 q2: what percentage of workload do you expect to save through the usage of the plug-in? as presented in fig. 3, the participants were requested to mark on the given chart to indicate the amount of workload saving estimation. the maximum savings were indicated at around 7080%. a group did indicate that the user interface and plug-in concept each saves up to 30-35%. saks 2010 6 / 12 eceasst figure 3: evaluation results on the workload savings another group gave a variable from 10-80%. because they foresee that the saving percentage will increase as more sbbs are developed. generally the plug-in approach was well received. this showed that the participants welcome the idea of resource saving tools that can simplify and accelerate the development process. 5.3 q3: accessing the “rule-idea” figure 4: evaluation results on the viability of the “draw-a-service” concept figure 5: evaluation result on the acceptance of the rule approach there were two parts in this question. the first part was to evaluate the viability of the ’drawa-service’ concept (fig. 4). most participants rated the concept as strong to very strong. it was seen as a useful approach especially for non-technical people. the comment on keeping rules simple was also valuable, since it revealed the usability issue in the concept. the participants did presume that the current idea might not work as expected, when rules become more complex. this gave us an important pointer to be looked at in the future. the second part asked for the opinion on whether the ’rule representation’ approach is inline with the participants’ idea of processing software creation tasks (fig. 5). we received a rather mixed result. two groups showed acceptance of the rule representation approach, since they could foresee how the approach would fit into their service creation tasks. a remark was made, stating that the approach requires rethinking by service developers. a group gave a neutral feedback (group blue). this was due to the fact where the group saw the approach as hard to debug. this point was similar to the “weaknesses” part in q1 (fig. 2). 7 / 12 volume 27 (2010) evaluation of the technology agnostic service creation approach 5.4 q4: how do you assess the general definition of service in the tasc approach? figure 6: evaluation result on the proposed general definition of service the definition of service in our approach brought also some mixed feedback. the strength of the idea was the clear definition of sbbs and their relationships to services. the participants saw the benefits of reusability and flexibility for services. with the approach, the service creation tasks can be provided to wider audience and will stimulate the service creation cycle. on the other hand, some saw weaknesses in limited ability in reusing composed services. they proposed services to be re-used in a simpler representation. at the same time some also commented that more sbbs are needed in helping the success of the approach. the lack of consistency check for operators in defined service could also be a possible threat to the idea. 5.5 q5: which are the most rivalling ideas with regard to the tasc? table 1: evaluation result on the rivalling ideas general approaches projects products (academic + market) mda mams yahoo! pipes spice google mashup opuce sms loms the summarized result was as illustrated in table 1. model-driven architecture (mda) [gro] was mentioned as a rivalling idea. however, mda is a formalisation of a technical development process. it is not intended for end-users and they will not be able to understand the complexity of the different modelling layers in mda. mda can generate code out of graphical models but it is not intended to run this code without further looking in the code. saks 2010 8 / 12 eceasst at the second column, the enlisted projects were known to us. these projects have direct and indirect focus on the issues of service creation. however they do not tackle issues on enduser service creation. projects such as spice 3 and sms 4 deal mainly on supporting telcos in providing user-centric services. some of the proposed service creation tools still require certain level of technical knowledge, such as data flow definition. in our opinion such approaches might be still complex for end-users. the tasc concept can be seen as a complementing approach to the solutions from these projects. yahoo! pipes 5 and google mashup 6 are some prominent web 2.0 [o’r05] service creation products. however the web 2.0 services focus more on content aggregation and manipulation, and do not provide semantic based service creation. the comparison made here by the participants gave us a good insight on current related work. this will assist us in reviewing and improving our approach and the prototypes. 5.6 q6: which factors could be supportive or threatening for the market success of the overall concepts of tasc? figure 7: evaluation result on the market success potential from the economical point of view (fig. 7), our approach was foreseen to benefit third party service providers. the service creation tools can allow them to provide sbbs for easy service creation. one should also take note of the spam threat that can exist in such an implementation. in the category of social, the authentication, authorization and accounting (aaa) approach was seen as necessary. this will tackle issues regarding trust and privacy issues in service creation and usage. newer target groups were also expected, since the nature of the proposed concepts allows sharing of created services. from the technological point of view, common vocabulary was highlighted. this was due to the fact when one wishes to create services using own vocabulary, he must be sure that the keywords used are known in the system. we agreed that through the use of semantic description 3 http://www.ist-spice.org, last visited on 10th january 2010 4 http://www.ist-sms.org/, last visited on 10th january 2010 5 http://pipes.yahoo.com/, last visited on 10th january 2010 6 http://editor.googlemashups.com/, last visited on 10th january 2010 9 / 12 volume 27 (2010) evaluation of the technology agnostic service creation approach and discovery, common semantic can be a good alternative. different vocabulary with the same semantic can be linked to the desired sbb. for a successful implementation of tasc approach in future see, a group also noted that in-depth knowledge is needed. 6 feedback and suggestions 6.1 the tasc approach the tasc approach gained positive response based on the participants’ feedback. the hands-on tests on different service creation tools were successful, given the fact that the participants were able to understand the concepts behind the different tools. the idea of bringing easy service creation to non-developers was a new concept to the participants and they welcome the idea. the tasc approach was seen as acceptable in area of service creation. participants were quick in adapting to the concept, as they were able to use the vse with non-technical semantics to create services. the participants also agreed that technicalities could be a hurdle for the nondevelopers, and the proposed approach successfully tackled this issue with the provided solution. the realisation of service creation via “draw-a-service” brought also positive feedback. most of the participants agreed that this concept has high potential in enabling service creation for non-technical users. the usage of rules to express service needs was also well accepted by the participants. the use of technology agnostic keywords for semantic service discovery was seen as a novel approach where end-users can use technology agnostic terms to create services. the participants also welcomed the idea of platform independent implementation. the proof of concept implementations was based on java and .net web services. this demonstrated that the proposed approaches were not limited to only certain technologies. the choice of rule language is also not fixed, where future implementations can freely select the most suitable rule representation needed for the designated platform. 6.2 the tasc tools during the evaluation event, the participants were willing to test various prototypes and to ask questions in order to understand the tasc tools and approaches. the implementation of an ide plug-in for sbb developers gained positive feedback. the main benefits of having such a plug-in were the time and resource saving factors. the participants found the assistance and wizards provided by the plug-in useful. the participants also made good remarks on the vse. the ability to graphically “draw-a-service” without prior knowledge of the provided service environment was regarded as a feasible feature. the hands-on tests of the vse also brought valuable suggestions for future improvements. 6.3 suggestions the technology agnostic process of service creation can be simplified and improved with the help of graphical debugging and monitoring. consistency checks for the rules can inform the enduser while drawing a service, if there are mistakes such as wrong compositions and misspelled entries. in-depth research also should be carried out on the area of sbb interaction in our service saks 2010 10 / 12 eceasst creation solution. this addresses the unresolved problems of how services and sbbs could interact and how information could be exchanged. besides that, exception handling should also be considered as one of the next steps. this means that the end-user could be informed and advised when an evaluated rule has an error. a self learning dictionary of the defined and used tags as well as meta tags can be added. this will assist the end-users in describing sbbs using their own vocabularies. the dictionary can be improved and modified during the execution of the sbbs or during the service creation process using the provided vse. the dictionary is expected to further improve the implementation of the technology agnostic idea in the area of semantic service description and discovery. other questions which have to be researched are the issues on trust and privacy for the sbbs. these are important challenges because the sbbs used within a service rule are not obligatory connected to concrete implementations of sbbs but are characterised by technology agnostic descriptions. the implementation of trust and privacy will reduce the risk of accidental execution of potentially malicious sbbs from unknown parties. for the market success of a service creation tool, it is necessary to study the requirements that enable open service market places. another potential step in this area is to further push the technology agnostic service creation approach towards standardization. in this way, the openness of the approaches can be kept, while different parties involved in the service provision and creation chain can also profit from the approach. more sbbs should also be made available for further tests and usages so that the approach can be evaluated and used by more users. 7 conclusion and future work in our work we have developed a prototype service creation environment that aims to enable service creation for everyone. an evaluation event was held to allow participants to test and evaluate our prototype tools and service creation approach. generally the evaluation process has brought up fruitful and good suggestions. potential extensions were proposed in order to further improve the concepts. the challenges ahead were also identified. as future work we will investigate issues such as consistency, feature interaction, concurrent execution. at the same time, more sbbs will be developed for additional use cases. we also intend to investigate further semantic service description and discovery methods to improve sbb discovery for our prototype tools. acknowledgment the work performed is partly funded by the german “bundesministerium für bildung und forschung” (bmbf). the authors thank the evaluation participants for their valuable feedback. bibliography [all] o. m. alliance. oma enabler and reference releases. available online at http: //www.openmobilealliance.org/technical/released enablers.aspx, last visited on 10th 11 / 12 volume 27 (2010) http://www.openmobilealliance.org/technical/released_enablers.aspx http://www.openmobilealliance.org/technical/released_enablers.aspx evaluation of the technology agnostic service creation approach january 2010. [as01] t. aubonnet, n. simoni. pilote: a service creation environment in next generation networks. in intelligent network workshop, 2001 ieee. pp. 36–40. may 2001. [fuj] fujaba tool suite. available online at http://www.fujaba.de, last visited on 10th january 2010. [gro] o. m. group. mda model-driven architecture guide. available online at http:// ormsc.omg.org/mda guide working page.htm, last visited on 10th january 2010. [lhl04] y. li, j. i. hong, j. a. landay. topiary: a tool for prototyping location-enhanced applications. in uist ’04: proceedings of the 17th annual acm symposium on user interface software and technology. pp. 217–226. acm, new york, ny, usa, 2004. [lkp+08] s. l. lau, n. klein, a. pirali, i. koenig, o. droegehorn, k. david. making service creation for (almost) everyone. in ict-mobile summit 2008. stockholm, june 2008. [o’r05] t. o’reilly. what is web 2.0. design patterns and business models for the next generation of software 30, 2005. available online at http://www.oreilly.de/artikel/ web20.html, last visited on 10th january 2010. [pha06] c. pautasso, t. heinis, g. alonso. jopera: autonomic service orchestration. ieee data eng. bull. 29(3):32–39, 2006. [rep93] a. repenning. agentsheets: a tool for building domain-oriented dynamic, visual environments. phd thesis, boulder, co, usa, 1993. [rul] the rule markup initiative. available online at http://www.ruleml.org, last visited on 10th january 2010. [sd03] t. sohn, a. dey. icap: an informal tool for interactive prototyping of context-aware applications. in chi ’03: chi ’03 extended abstracts on human factors in computing systems. pp. 974–975. acm, new york, ny, usa, 2003. [szy97] c. szyperski. component software: beyond object-oriented programming (acm press). addison-wesley professional, december 1997. [wdd04] b. wuest, o. droegehorn, k. david. the fame2 platform concept: moving platforms to the mobile. in proc. 5th int. conference on internet computing (ic’04). pp. 423–430. lasvegas, usa, 2004. [wil80] r. wilensky. meta-planning. in aaai. pp. 334–336. 1980. [ws01] r. weinreich, j. sametinger. component-based software engineering: putting the pieces together. chapter component models and component services: concepts and principles, pp. 33–48. addison-wesley longman publishing co., inc., 2001. saks 2010 12 / 12 http://www.fujaba.de http://ormsc.omg.org/mda_guide_working_page.htm http://ormsc.omg.org/mda_guide_working_page.htm http://www.oreilly.de/artikel/web20.html http://www.oreilly.de/artikel/web20.html http://www.ruleml.org introduction state of the art technology agnostic service creation (tasc) approach evaluation event evaluation questions and results q1: how do you rate the usability of the visual service editor? q2: what percentage of workload do you expect to save through the usage of the plug-in? q3: accessing the ``rule-idea'' q4: how do you assess the general definition of service in the tasc approach? q5: which are the most rivalling ideas with regard to the tasc? q6: which factors could be supportive or threatening for the market success of the overall concepts of tasc? feedback and suggestions the tasc approach the tasc tools suggestions conclusion and future work electronic communications of the easst volume 33 (2010) proceedings of the fourth international workshop on foundations and techniques for open source software certification (opencert 2010) integrating data from multiple repositories to analyze patterns of contribution in foss projects. sulayman k. sowe and antonio cerone 17 pages guest editors: luis s. barbosa, antonio cerone, siraj a. shaikh managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 eceasst integrating data from multiple repositories to analyze patterns of contribution in foss projects. sulayman k. sowe1∗ and antonio cerone2 1 sowe@ias.unu.edu, unu-ias, yokohama, japan. 2 antonio@iist.unu.edu, unu-iist, macau sar china. abstract: the majority of free and open source software (foss) developers are mobile and often use different identities in the projects or communities they participate in. these characteristics not only poses challenges for researchers studying the presence (where) and contributions (how much) of developers across multiple repositories, but may also require special attention when formulating appropriate metrics or indicators for the certification of both the foss product and process. in this paper, we present a methodology to study the patterns of contribution of 502 developers in both svn and mailing lists in 20 gnome projects. our findings shows that only a small percentage of developers are contributing to both repositories and this cohort are making more commits than they are posting messages to mailing lists. the implications of these findings for our understanding of the patterns of contribution in foss projects and on the quality of the final product are discussed. keywords: open source software developers, open source software projects, software repositories, concurrent versions system, mailing lists, linking data, software quality. 1 introduction free and open source software (foss) developers are like nomads; freely moving from one project to another. they commit bits and pieces of code, report and fix bugs, take part in discussions in various mailing lists, forums, and irc channels, document coding ethics and guidelines, and help new entrants. along the way they create and archive a wealth of knowledge and experience associated with their art [sas06]. participants in various projects use tools (versioning systems, mailing lists, bug tracking systems, etc.) to enable the distributed and collaborative software development process to proceed. these tools serve as repositories which can be data mined to understand who is involved, who is talking to whom, what is talked about, how much someone contributes in terms of code commits or email postings. thus, by applying cyberarcheology [sii07] to these repositories, we can learn and better understand the patterns of contribution [sff+06, gks08] of foss developers in the projects concerned. ∗ correspondence author: sulayman k. sowe. email: sowe@ias.unu.edu. address: unu-ias, yokohama 220-8502, japan. tel: +81-45-221-2300, fax: +81-45-221-2302. 1 / 17 volume 33 (2010) patterns of contribution in foss projects an important aspect of software engineering research, and the certification of foss products in particular, is understanding and measuring the contribution of individuals, particularly developers, who work on a project [so09a, sas06]. a host of factors which have both empirical and industrial implications motivates this kind of research. factors include, but not limited to; helping practitioners understand and monitor the rate of project development, characterizing foss projects in terms of developers turnover and extent of contribution [clm03, gks08, sssa08], identifying bottlenecks and isolate exceptional cases in terms of projects and individuals contributions [so09a], and using the research results to develop new metrics or evaluate an existing taxonomy [so09b] of metrics (process, product, and resources) for foss quality attributes [saob02] and the certification process. furthermore, as argued by [sc09], communication and patterns of contribution are factors that contribute to measure the efficiency of the development process, a measure that the authors called “quality by development”. indeed, the patterns of [code] contribution in foss projects has emerged as an important measure in assessing the quality of foss products [so09b, saob02]. a lot of research utilizes data from a single repository to analyze code contribution of developers [rg06, gks08], trends and inequality in posting and replying activities in apache and mozilla [mfh02], kde [kuk06], debian [ssl08], and freebsd [db05]. most of these researches use data from cvs or mailing lists as these are de facto repositories in foss projects. source configuration management (scm), of which cvs or svn1 is part, is mainly used to coordinate the coding activities of software developers and manage software builds and releases. mailing lists, on the other hand, are the main communication channels [ssl08]. many important aspects of a project are negotiated in [developer] lists: software configuration details, the way forward and how to deal with future requests, how tasks are distributed, issues concerning package dependencies, scheduling online and off-line meetings, etc. thus, for a developer to keep abreast with developments in a project, committing code to svn alone is not sufficient. s/he needs to participate in the respective lists, communicate his ideas, and engage with colleagues. to bolster this view, [bro75] pointed out the essence of communication as a means to foster long term success of software projects. this may take the form of a bi-directional developer to developer, developer to user, and developer to community communication. even though a strong linkage exist between the information in foss repositories (e.g. bug reports and source code repositories [db07, zpz07]), few researchers strive to understand how developers’ contributions varies across repositories. in this research we tired to fill this niche by establishing links between svn and mailing lists to locate developers who are present in both repositories and quantify their contribution in terms of commits and posts. the rest of the paper is organized as follows. first, in section 2, we discuss the rationale behind this research and construct two hypothesis which will guide us for the rest of the paper. 1 note: svn is our software code repository (see subsection 3.1). reference is made to cvs when other researchers mentioned using data from that repository. proc. opencert 2010 2 / 17 eceasst in section 3, we outline the methodology and data used in this research and present our algorithm for identifying and quantifying developers contributions to both svn and mailing lists. this is followed by an analysis and discussion of our results in section 4. our concluding remarks and future work are presented in 5 section. 2 research rationale and hypothesis for software projects to evolve, it is by design that developers must continuously commit and review the codebase. in the eyes of the developer, user, and business community an active mailing list is a proxy of project success. the presence of project’s leads, core and active developers in mailing lists has a profound effect on the way individuals within and outside the project see the commitment of the most influential members in the project. for software companies and private enterprises, developers presence in lists may indicate that software support activities are not only available from ordinary users, but also comes form individuals behind the software and project. thus, developers should strive to balance their coding activity with their involvement in mailing lists. this raises a number of questions which may be of great interest to both foss project administrators and researchers. for instance; • how many developers are willing to commit code and patches and at the same time participate in discussions in mailing lists and other project’s fora? • if developers are coding more than they are participating in mailing lists, what does this tell us about the maintenance and dynamics of the software and project? • how much effort can a developer allocate to one activity and at what stage in the project’s life-cycle? • if attaining a balance activity is much required in a project, how can project administrators schedule and assign or dedicate one activity at the expense of another? • what is the impact on the performance the project of having developers specializing in one activity? in this research, we used data provided by the flossmetrics project2 to proposed a methodology to help us answer some of the above questions. foss researchers (e.g. [mfh02, kuk06, db05]) study and report developers coding activities separately from their mailing lists activities. however, research on the foss development process [mas05, sff+06] informs us that in many projects, a small number of talented core developers or “cod gods” [rg06] are busily (as if in a software beehive) submitting patches and tinkering with code to produce good and usable software for the rest of the community. this cohort also contribute to discussions in mailing lists; interacting with other software developers and users, keeping abreast with project activities and monitoring what goes on in there projects or packages [ssl08]. nevertheless, we conjecture that not all the developers who commit or make changes to a project’s source repository also participate in [developer] mailing lists. this study investigates the contributions of foss developers to 2 http://flossmetrics.org/; last visited: monday, november 29, 2010. 3 / 17 volume 33 (2010) patterns of contribution in foss projects both svn and developer mailing lists and presents a methodology to overcome the empirical research challenges associated with integrating or linking data from multiple repositories. that is, we find out if developers are coding through commits in svn as much as they are participating in mailing lists. this involves correlating developers commits activities with their corresponding mailing lists activities within the same project. hypothesis put forward in this research are the following; • hypothesis [h1]: since developers must code and commit, ad infinitum, for the software and project to evolve, we hypothesize that foss developers make more commits to a project’s code (svn) repository than they are posting messages to mailing lists. • hypothesis [h2]: however, we posit that developers must strike a balance between their coding and mailing lists activities. thus, foss developers contribute equally to code repository and mailing lists. 3 research methodology the methodology employed in this research investigates the simultaneous occurrence of developers in svn and mailing lists. that is, identifying developers who make both commits and postings, and ensuring that the developer making the svn commit is the same individual posting to the developer mailing list(s) of the same project. the methodology also ensures that developers with multiple identities are only counted once. the methodology, as represented in figure 1, shows the flossmetrics database as the data source from which we extracted svn and mailing lists data for the 20 projects in our study. in our data acquisition, a fundamental question is always asked; “is this the same developer we have in both repositories ?” figure 1 also shows the mysql database tables and fields from which we extracted commits and posts which are used in our analysis to identify developers (see subsection 3.3) in the projects. the links between the tables as indicated by the arrows (with “is”) shows the path taken to locate a developer and counting his contribution to both svn and mailing lists. figure 1: methodology to identify developers from multiple repositories. proc. opencert 2010 4 / 17 eceasst 3.1 data the data for this research consists of the 20 gnome projects shown in table 1. the flosstable 1: list of gnome projects studied no. projects no. projects 1 balsa 11 gnome control center 2 brasero 12 gnome games 3 deskbar applet 13 gnome media 4 ekiga 14 gnome power manager 5 eog 15 gnome screensaver 6 epiphany 16 gnome system tools 7 evince 17 libsoup 8 evolution 18 metacity 9 gdm 19 nautilus 10 gedit 20 seahorse metrics database retrieval system uses a combination of tools3 to retrieve data from projects (e.g. gnome and apache) and forges (e.g. sourceforge) and computes various code and community metrics. the cvsanaly2 [arg06, rgch09, sssa08] tool retrieves source content management systems (scm) data and stores committers attributes into various tables. the mlstats [sssa08] tool extracts one or more mailing lists archives of a particular project. for each of the 20 projects, committers svn identifications (commit id) and the total number of commits each committer made is extracted. for the mailing list data, for each project, data was extracted from two flossmetrics database tables: two fields (type of recipient and email address) from the “messages people” table. the type of recipient field has the format “from”, “to”, and “cc”. the “from” email header is used to identify lists posters [qj04] and counting their contribution to mailing lists [sas06]. and three fields (email address, name, and username) from the “people” table. 3.2 data cleaning having identified fields needed to analyze developers participation in svn and mailing lists, we proceeded with data cleaning. for the mailing lists data, since we need both the “name” and “username”, all posters without recognizable names and/or usernames were removed. some of the names contained unrecognizable characters such as “=?iso88591?q?g=fcrkan g=fcr?=”. some of the posts with null posters/developere were also removed. furthermore, since the full name (first +last) is needed to identify a developer, all posters with a single name were deleted from the mailing lists data. that is, delete developer “foo” but retain developer “foo bar”. for the svn data, all commits without committers or authors were removed. aggregate number of items deleted in each of the above categories were; unrecognizable characters = 28, posts with null posters = 30, posters with a single name = 14, and commits without authors = 5093. 3 http://tools.libresoft.es/; last visited: monday, november 29, 2010 5 / 17 volume 33 (2010) patterns of contribution in foss projects 3.3 identification of developers across repositories as depicted in figure 1, a poster in the mailing lists can be identified in two ways. in the messages people table, a poster is identified by his email address. by using the “from” field, all the emails posted by a particular person can be aggregated . the people table is used to identify a poster through his “email address”, poster “name” in the form of first name + last name (eg. pawel salek), and “username” (eg. pawsa). for the svn data, the committer field from the commits table was used to identify a committer or author of a commit. in svn, an individual is simply identified as a “committer” or an “author” of one or more commits. mailing lists participants, on the other hand, can be identified by means of message identifiers like “from:” in email headers [sas06]. the identification process proceeds thus; 1. for each project in the commits table, list all the committers and for each committer (unique commit id or commit id) sum all his commits and store the value as ncommits variable. 2. for each project in the people table, list (“email address” + “name” + “username” or poster id) where both name and username is the same for this committer as in the commits table. and 3. from the messages people table, list developers “email address”, where people.email address = messages people.email address. for each developer, count all the posts and store the value as nposts variable. the results of a typical query is shown in figure 2, with developers emails anonymized. from the query, it can be seen that a developer may appear many times. this is because, while a developer has only one identification in svn, his commit id, the same developer may use many email addresses when posting messages to developer mailing lists. figure 2: query showing the identification of foss developers from svn and mailing lists. proc. opencert 2010 6 / 17 eceasst 3.3.1 unmasking aliases and removing duplicates the volunteering nature of the foss development process and participation in public repositories means that participants may use different emails. for example, as shown in figure 2, a developer (e.g. felix riemann) has his identity masked in three email aliases; foo@svn.gnome.org, bar@gnome.org, foo.bar@cvs.gnome.org. the fundamental problem in email alias unmasking [bgd+06, ssl08] is finding out that those aliases all belong to one developer. the algorithm for checking duplicate records and unmasking aliases in the mailing lists data proceeded thus; ------begin algorithm------------------------------for all records in project x if ncommits occurs more than once for this developer and poster_id = commit_id return ’’this is a duplicate’’ record only 1 value of ncommits for this developer total posts for this developer = sum of nposts. ------end algorithm------------------------------the query scenario in figure 3 shows the result when the algorithm is applied to the dataset. this literally means; a developer (e.g. federico mena quintero in figure 2) with a unique commit id (federico) made 100 commits to the project’s svn. however, he contributed to mailing lists using two emails (foo@ximian.com and foo.bar@gnu.org). he posted 28 messages using the first email and 1 message using the second email. the developer’s overall email postings is the sum of the two posts he made using the different emails, i.e. 28 + 1 = 29. all duplicate email1 email2 nposts = 28ncommits = 100 nposts = 1ncommits = 100 poster_id2 = commit_id2poster_id1 = commit_id1 full_name1 = full_name2 (developer) email1 email2 nposts = x ncommits = nposts = y ncommits = poster _id2 = commit_id2poster_id1 = commit_id1 full_name1 = full_name2 = full_name... n (developer) email...n poster _id...n = commit_id...n ncommits = nposts = z figure 3: query scenario to identify developers in svn and mailing lists records are identified and developers nposts and ncommits are calculated in a similar manner. there were an average of 115 duplicate records of this nature per project in our dataset. this means that many developers are using multiple email addresses. generally, as shown on the right hand side of figure 3, a developer contribution to mailing list (nposts) will be counted as x + y + z, whilst his svn contribution (ncommits) will be counted as α . 7 / 17 volume 33 (2010) patterns of contribution in foss projects 4 analysis and discussion according to [sek06], an exploratory study is undertaken “when not much is known about the situation at hand or no information is available on how similar problem or research issues have been solved in the past”. thus, we begin our analysis using what we call an exploratory data analysis (eda) technique to help us examine the distribution, the nature of the commits and posts, and prepare the ground for what may be the appropriate analysis technique to be used to answer the research hypothesis. tables 2 and 3 shows the descriptive statistics of the developers posting and committing activities after data cleaning. table 2: descriptive statistics of posts projects n posters mean median std. dev. skewness std. err. of skewness max. sum balsa ** 1088 12.98 2.00 67.273 13.942 .074 1465 14125 brasero 63 4.13 1.00 8.071 3.498 .302 45 260 deskbar applet 97 7.00 2.00 19.187 5.200 .245 137 679 ekiga ** 729 9.24 3.00 59.999 22.103 .091 1509 6734 eog 134 4.17 1.50 8.914 4.533 .209 67 559 epiphany ** 889 5.91 1.00 23.795 12.657 .082 470 5250 evince ** 451 3.46 1.00 13.093 14.013 .115 238 1562 evolution ** 4769 7.44 2.00 46.274 25.619 .035 1760 35478 gdm ** 658 3.99 1.00 25.597 20.006 .095 595 2628 gedit ** 571 3.95 1.00 15.653 14.252 .102 306 2253 gnome power manager ** 203 5.58 2.00 33.046 13.881 .171 470 1133 gnome control center 174 8.36 2.00 20.936 5.261 .184 186 1455 gnome games 173 8.79 2.00 25.146 5.909 .185 224 1521 gnome media 289 5.39 2.00 12.270 5.884 .143 115 1557 gnome screensaver 27 5.59 3.00 7.846 3.322 .448 39 151 gnome system tools ** 297 4.51 1.00 11.019 6.076 .141 112 1339 libsoup ** 52 3.73 1.00 8.761 6.326 .330 63 194 metacity 60 4.82 2.00 11.029 5.301 .309 77 289 nautilus ** 2065 8.61 2.00 61.402 32.822 .054 2475 17782 seahorse 62 6.16 2.00 18.382 5.390 .304 122 382 total 128,512 95,331 table 3: descriptive statistics of commits projects n committers mean median std. dev. skewness std. err. of skewness max. sum balsa 181 44.09 4.00 241.309 9.233 .181 2688 7981 brasero ++ 86 26.05 5.00 137.976 8.869 .260 1271 2240 deskbar applet ++ 133 19.67 5.00 84.751 8.413 .210 834 2616 ekiga 186 41.99 5.00 286.865 12.130 .178 3757 7810 eog 298 16.59 4.00 53.660 8.231 .141 581 4944 epiphany 252 34.84 6.00 217.618 14.340 .153 3352 8780 evince 203 17.30 4.00 59.881 7.494 .171 535 3511 evolution 430 81.11 10.00 309.253 8.099 .118 4061 34877 gdm 282 23.63 5.00 103.297 9.653 .145 1266 6663 gedit 329 20.68 5.00 81.699 10.704 .134 1153 6804 gnome power manager 148 22.75 5.00 161.952 12.060 .199 1974 3367 gnome control center ++ 423 21.39 6.00 55.908 6.917 .119 634 9049 gnome games ++ 321 27.68 7.00 89.618 8.559 .136 1164 8884 gnome media ++ 324 13.05 4.00 31.803 6.804 .135 345 4228 gnome screensaver ++ 126 12.79 4.00 74.388 11.097 .216 838 1611 gnome system tools ++ 207 20.55 5.00 82.615 10.079 .169 1043 4254 libsoup 37 32.49 1.00 111.261 5.067 .388 647 1202 metacity ++ 264 15.50 4.00 61.675 8.547 .150 600 4091 nautilus 395 37.52 7.00 126.202 8.529 .123 1712 14822 seahorse ++ 137 21.39 5.00 99.481 9.603 .207 1087 2931 total 4,762 140,665 as shown in table 2, for each project the total number of posters (n posters), the mean post per poster, the median, standard deviation, skewness, the maximum posts made by one individual, and the total or sum of postings for that project are shown. for all the projects, the mode and proc. opencert 2010 8 / 17 eceasst minimum numbers of posts made equals 1. a total of 12,851 posters contributed 95,331 email messages. table 3 shows the same descriptive statistics for the committers (n committers) in each project. a total of 4,762 developers made 140,665 commits. evident from the statistics is that each project has its unique characteristics [clm03] in terms of developers’ postings and committing activities, as well as the number of developers involved in each activity. for instance, 45% (n = 9) of the projects (marked with ++ in table 3) have more committers than posters. the other 55% (n = 11) of the projects (marked with ** in table 2) have more posters than committers. furthermore, figures 4 (both y -axis in logarithmic scale) shows the distribution of posts and commits in the respective projects. from the boxplots it can be seen that the contributions of the developers to mailing lists is characterized by smaller means (post per poster). however, the posting data has many outliers; with many developers posting few emails and a few making large numbers of posts. on the contrary, the commits are characterized by larger means (commits per committer). these characteristics are reminiscent of power distributions observed in foss participants’ contributions to mailing lists [ssl08] and cvs [mft02] activities. figure 4: box-plots showing the distributions of posts and commits. 4.1 developers in both svn and mailing lists in order to analyze the simultaneous occurrence of the developers in both repositories, we queried the svn and mailing lists data for each project and computed developers contributions in terms of the ncommits and nposts variables discussed in subsection 3.3. table 4 shows the number of developers (n dev) in each project who contributed to both svn and mailing lists. for the 20 projects, 502 developers made more commits (mean = 152.1; std. deviation = 431.171) than posts (mean = 43.19; std. deviation = 164.353). furthermore, as shown in figure 5, our identification technique and algorithm revealed a rel9 / 17 volume 33 (2010) patterns of contribution in foss projects table 4: developers contribution to both svn and mailing lists nposts ncommits projects n dev. mean median std.dev. max. sum mean median std.dev. max. sum balsa 40 37.23 5.5 133.76 851 1489 112.53 25 206.33 751 4501 brasero 6 19.33 2 30.936 77 116 69.17 8.5 98.3 196 415 deskbar applet 8 20.13 6 35.64 106 161 120.25 5.5 289.5 834 962 ekiga 4 438.25 121.50 722.49 1509 1753 2170.25 2417 1876.01 3757 8681 eog 16 18.81 4.5 25.95 78 301 129.38 37.5 196.16 581 2070 epiphany 40 55.73 7 116.69 470 2229 146.82 16.5 536.03 3352 5873 evince 18 27.17 2 58.61 238 489 100.89 10.5 180.31 535 1816 evolution 92 56.47 4.5 172.68 1481 5195 283.29 46 622.01 4061 26063 gdm 21 26.38 2 56.63 227 554 112.9 17 242.76 939 2371 gedit 19 20.84 2 69.34 306 396 103 4 267.13 1153 1957 gnome control center 35 21 4.00 51.753 296 735 69.54 19 125.13 527 2434 gnome games 14 43.57 7 83.15 304 610 178.93 13.5 341.49 1164 2505 gnome media 23 21.87 5 36.67 130 503 39.22 6 84.03 345 902 gnome power manager 7 3.43 4 1.51 6 24 8 2 11.4 32 56 gnome screensaver 4 15.75 10 15.84 39 63 211.5 3.5 417.67 838 846 gnome system tools 22 17.14 3 33.42 154 377 92.59 24 228.27 1043 2037 ibsoup 3 28.33 8 39.63 74 85 219.67 8 370.09 647 659 metacity 10 14.8 6 23.85 77 148 184.2 7 270.12 600 1842 nautilus 136 49.95 8.5 225.14 2475 6793 86.63 13 220.1 1712 11782 seahorse 2 73.5 73.5 101.12 145 147 198 198 275.77 393 396 atively small, but varying, percentage4 of developers who are involved in both activities. the figure 5: percentage of developers involved in posting and committing. percentage of developers in each activity varies across the projects. for example, the ekiga, gnome power manager, and seahorse projects having less than 5% of their developers committing to svn and at the same time posting messages to their respective projects’ mailing lists. projects such as balsa and nautilus have few poster (3.68% and 3.23%), but higher percentage of committers (22.1% and 34.43%). 4 calculated as: % posters = (n dev/n poster)*100 and % committers = (n dev/n committers)*100 proc. opencert 2010 10 / 17 eceasst 4.1.1 are developers making more commits than posts? hypothesis [h1]: foss developers make more commits to a project’s code (svn) repository than they are posting messages to mailing lists. in our investigation of h1, for each project, we compared the total number of commits made to svn with the total number of messages developers posted to the mailing lists. the pattern of contribution for all the 502 developers in the 20 projects is shown in the boxplots in figure 6. in the boxplots, the median line and error t-bar widths for each set of project data (nposts and ncommits) are shown. the domination of svn commits, with larger means of commits per developer (mean = 150.32, std. deviation = 424.986) over posts (mean = 42.63, std. deviation = 161.852) is evident in all the projects. figure 6: distributions of posts and commits for all projects (y-axis in log scale). 4.1.2 are developers contributing equally to svn and mailing lists? hypothesis [h2]: foss developers contribute equally to code repository and mailing lists. we used correlation between commits and posts to study how developers activities in svn and mailing lists are related. the scatter plot in figure 7 shows the correlation between commits and posts in all projects. in the plot, data points are fitted to a line to show the trend in the commits and posting activities of the developers. previous research ([ssl08]; page 414) showed that foss developers and users mailing lists activities have fractal or self-similarities properties and could best be explained by a polynomial model of third order, i.e. a cubic relation of the type logn = b0 + b1 ∗ logr + b2 ∗(logr)2 + b3 ∗(logr)3 (1) as shown in figure 7, our fit method could explain 30.4% (r3 = 0.304) of the variability in commits and posting activities. this translates to 26.5% or r2 = 0.265 in linear terms. the linear 11 / 17 volume 33 (2010) patterns of contribution in foss projects figure 7: relationship between posts and commits. both axis in a log scale. association between nposts and ncommits as measured by pearson correlation = 0.594, and this is significant at the 0.01 level (2-tailed) with ρ = 0.000. however, the nposts and ncommits data are not normally distributed and have outliers. thus, nonparametric correlations using spearman’s rho and kendall’s tau b statistics, which work regardless of the distribution of the variables [nor04], are used to report the association between posts and commits. table 5 shows that, overall, there is a low correlation between commits and posts, with spearman’s coefficient (ρ ) = 0.426 (p =1.000). table 5: correlations between posts and commits nposts ncommits kendall’s tau b nposts correlation coefficient 1.000 .308 sig. (2-tailed) . .000 n 502 502 ncommits correlation coefficient .308 1.000 sig. (2-tailed) .000 . n 502 502 spearman’s rho nposts correlation coefficient 1.000 .426 sig. (2-tailed) . .000 n 502 502 ncommits correlation coefficient .426 1.000 sig. (2-tailed) .000 . n 502 502 furthermore, wilcoxon signed ranks for the two-related-samples tests procedure was used proc. opencert 2010 12 / 17 eceasst to compare the distributions of two variables. the results of the test in table 6 shows that for the 502 developers in the 20 projects; for 140 = ncommits < nposts, for 327 developer ncommits > nposts, and 35 developers had a balanced activity with ncommits = nposts. table 6: ranks of developers contribution variable ndev. mean rank sum of ranks ncommits -nposts negative ranks 140 175.46 24565.00 positive ranks 327 259.06 84713.00 ties 35 total 502 5 concluding remarks in this paper we have put forward research questions to investigate whether foss developers are making more commits to code repositories (svn) than they are posting messages to mailing lists (hypothesis 1), and whether developers should aim at a balanced activity by contributing equally there repositories (hypothesis 2). despite the fact that foss data is widely available and can be easily extracted [sasm07], this kind of research is made difficult because of the problem associated with integrating data from and the subsequent identification of developers from multiple repositories (svn and mailing lists). we have presented and discuss a methodology which alleviates these empirical research obstacles. the methodology and algorithm enabled us to locate and count the quantitative contribution of foss developers in 20 gnome projects. an exploratory data analysis or eda technique was used to show that each project has its unique characteristics and developers contribution to either coding or mailing lists can vary tremendously. in our data consisting of 12,851 posters and 4,762 committers who, respectively posted 95,331 email messages and made 140,665 commits, we found out that in 55% (n = 11) of the projects there are more developers as posters, with smaller means (post per poster), than committers, with larger means (commits per committer). from this sample of posters and committers we are able to extract 502 developers who simultaneously contribute to both svn and mailing lists. this cohort made more commits (mean = 152.1; std. deviation = 431.171) than posts (mean = 43.19; std. deviation = 164.353). however, this group accounts for a relatively small percentage of the overall developer community in each project. but a close examination of the percentage of developers involved in posting and committing shows that projects with small number of posters will also have a small number of committers. this is valid in 60% (n = 12) of the projects studied. there is a 50-50 split (20%; n=4 on either side) between projects with small percentage of posters but large percentage of committers (balsa, epiphany, evolution, and nautilus) and those with large percentage of posters but a smaller percentage of committers. the analysis supports our first hypothesis (h1) that developers are making more commits to svn (mean = 150.32, std. deviation = 424.986) than they are posting messages to the developers mailing lists (mean = 42.63, std. deviation = 161.852). furthermore, a low but significant correlation (ρ = .0426; p = 1.000) between developers commits and posting were observed. 13 / 17 volume 33 (2010) patterns of contribution in foss projects this moderately supports our second hypothesis (h2) that developers are contributing equally to code repositories and mailing lists. wilcoxon signed ranks for the two-related-samples tests revealed that only 35 developers (less than 10%) had a balanced or tie activity. the implications of these findings may provide assurance that foss developers, apart from coding and committing bits of code to a project’s scm, they are also involved in knowledge brokage [sas06] in mailing lists. we can conjecture from earlier findings [sas06, arg06, lon06] and our experience in both the flossmetrics5 and sqo-oss6 projects that this serendipity has implications for the quality of code since a large number of developers are externalizing and discussing their coding activities with other community members in the mailing lists. this kind of engagement may enable the developers to improve the quality of their code base, do more refactoring and learn about how the quality of the produced code may be improved. future work and research directions: as a follow up to this research, our future work aims at consolidating understanding developer dynamics and the development of appropriate community metrics [sc09] or indicators for the certification of both the foss product and process. thus, narrowing the gap which exist in foss certification and formal methods [cs08]. specifically, we plan to add a qualitative element to our research by interviewing some of the α [vtg+06] or star [ssl08] or key developers. this future work may also incorporate content analysis of the postings, new metrics like posts/commits and how such metrics vary overtime. this kind of data, metrics and commits analysis may help us better understand the quality of developers contribution, reveal any bottlenecks which may hinder the incorporation of developers code into the release product, and further reveal what kinds of metrics may be most appropriate when characterizing foss developers and projects. furthermore, in addition to svn and mailing lists, developers also contribute intensively to the bug reporting and fixing process. therefore, there exist an avenue of extending the methodology presented in this research to incorporate data from bug tracking systems data. this will provide a more comprehensive view of the pattern of developers contribution in open source projects. while the conclusion drawn from this study points out certain trends in gnome projects, we are working on extracting a more heterogenous sample of projects and apply the same methodology to see if the patterns observed here can be generalized to other foss projects, not specifically gnome based. acknowledgements: we are grateful to all partners in the flossmetrics project for providing access to the data and tools used in this study. we also wish to acknowledge the excellent suggestions we received from anonymous reviewers and participants at the 4th international workshop on foundations and techniques for open source software certification (opencert2010). their comments have helped us improve the paper greatly. the correspondence author wishes to acknowledge the japan society for the promotion of science (jsps) who are currently sponsoring his research under grant id: p10807 and unu-merit, maastricht, netherlands where this research began. 5 http://www.flossmetrics.org/; last visited: tuesday, november 30, 2010 6 http://www.sqo-oss.org/home; last visited: tuesday, november 30, 2010 proc. opencert 2010 14 / 17 eceasst bibliography [arg06] j. amor, g. robles, j. gonzalez-barahona. discriminating development activities in versioning systems: a case study. in proceedings promise 2006: 2nd. international workshop on predictor models in software engineering co-located at the 22th international conference on software maintenance (philadelphia, pennsilvanya, usa). 2006. [bgd+06] c. bird, a. gourley, p. devanbu, m. gertz, a. swaminathan. mining email social networks. in msr ’06: proceedings of the 2006 international workshop on mining software repositories. pp. 137–143. acm press, new york, ny, usa, 2006. [bro75] f. brooks. the mythical man-month. essays on software engineering. addisonwelsey publishing, 1975. [clm03] a. capiluppi, p. lago, m. morisio. characteristics of open source projects. in csmr ’03: proceedings of the seventh european conference on software maintenance and reengineering. p. 317. ieee computer society, washington, dc, usa, 2003. [cs08] a. cerone, s. a. shaikh. incorporating formal methods in the open source software development process. in 2nd international workshop on foundations and techniques for open source software certification. milan, italy, 10 september 2008 2008. [db05] t. t. dinh-trong, j. m. bieman. the freebsd project: a replication case study of open source development. ieee transactions on software engineering 31(6):481– 494, 2005. [db07] j. m. dalle, m. den besten. different bug fixing regimes? a preliminary case for superbugs. in feller et al. (eds.), open source development, adoption and innovation. ifip international federation for information processing 234, pp. 247–252. springer, september 7-10 2007. [gks08] g. gousios, e. kalliamvakou, d. spinellis. measuring developer contribution from software repository data. in msr ’08: proceedings of the 2008 international workshop on mining software repositories. pp. 129–132. acm, 2008. [kuk06] g. kuk. strategic interaction and knowledge sharing in the kde developer mailing list. management science 2006 52: 1031-1042. 52:1031–1042, 2006. [lon06] j. long. understanding the role of core developers in open source development. journal of information, information technology, and organizations 1:75–85, 2006. [mas05] b. massey. longitudinal analysis of long-timescale open source repository data. in promise ’05: proceedings of the 2005 workshop on predictor models in software engineering. pp. 1–5. acm, new york, ny, usa, 2005. 15 / 17 volume 33 (2010) patterns of contribution in foss projects [mfh02] a. mockus, r. fielding, j. herbsleb. two case studies of open source software development: apache and mozilla. transactions on software engineering and methodology. 11(3):1–38, 2002. [mft02] g. madey, v. freeh, r. tynan. the open source software development phenomenon: an analysis based on social network theory. in americas conf. on information systems (amcis2002). pp. 1806–1813. 2002. [nor04] m. norusis. statistical procedures companion. prentice hall, inc., 2004. [qj04] s. r. q. jones, g. ravid. information overload and the message dynamics of online interaction spaces: a theoretical model and empirical exploration. information system research 15 (2):194210, 2004. [rg06] g. robles, j. gonzalez-barahona. contributor turnover in libre software projects. in damiani et al. (eds.), ifip international federation for information processing, open source systems. volume 203, pp. 273–286. springer,boston, 2006. [rgch09] g. robles, j. gonzalez-barahona, d. cortazar, i. herraiz. tools for the study of the usual data sources found in libre software projects. international journal of open source software and processes 1(1):24–45, jan-march 2009. [saob02] i. stamelos, l. angelis, a. oikonomou, g. bleris. code quality analysis in opensource software development. information systems journal, 2nd special issue on open-source, blackwell science 12 (1):43–60, 2002. [sas06] s. k. sowe, l. angelis, i. stamelos. identifying knowledge brokers that yield software engineering knowledge in oss projects. information and software technology 48:1025–1033., 2006. [sasm07] s. k. sowe, l. angelis, i. stamelos, y. manolopoulos. using repository of repositories (rors) to study the growth of f/oss projects: a meta-analysis research approach. in open source development, adoption and innovation. ifip international federation for information processing 234/2007(978-0-387-72485-0), pp. 147–160. springer boston, august 2007. [sc09] s. a. shaikh, a. cerone. towards a metric for open source software quality. electronic communications of the easst volume 20: foundations and techniques for open source certification 2009, 2009. [sek06] u. sekaran. research methods for business: a skill building approach. wiley, 4th edition, 2006. [sff+06] w. scacchi, j. feller, b. fitzgerald, s. a. hissam, k. lakhani. understanding free/open source software development processes. software process: improvement and practice 11(2):95–105, 2006. [sii07] s. k. sowe, g. s. ioannis, m. s. ioannis (eds.). emerging free and open source software practices. igi global, 2007. proc. opencert 2010 16 / 17 eceasst [so09a] sqo-oss. novel quality assessment techniques. deliverable report-d7. technical report, software quality observatory for open source software. project number: ist-2005-33331, 29 june 2009. http://www.sqo-oss.eu/research/reports/sqo-oss d 7 final.pdf [so09b] sqo-oss. overview of the state of the art. deliverable report-d2. technical report, software quality observatory for open source software. project number: ist2005-33331, 29 june 2009. http://www.sqo-oss.eu/research/reports/sqo-oss d 2 final.pdf [ssl08] s. k. sowe, i. stamelos, a. lefteris. understanding knowledge sharing activities in free/open source software projects: an empirical study. journal of systems and software 81(3):431–446., 2008. [sssa08] s. k. sowe, i. samoladas, i. stamelos, l. angelis. are floss developers committing to cvs/svn as much as they are talking in mailing lists? challenges for integrating data from multiple repositories. in 3rd international workshop on public data about software development (wopdasd). september 7th 10th 2008, milan, italy. 2008. [vtg+06] s. valverde, g. theraulaz, j. gautrais, v. fourcassie, r. v. sole. self-organization patterns in wasp and open source communities. ieee intelligent systems 21(2):36– 40, 2006. [zpz07] t. zimmermann, r. premraj, a. zeller. predicting defects for eclipse. in promise ’07: proceedings of the third international workshop on predictor models in software engineering. p. 9. ieee computer society, washington, dc, usa, 2007. 17 / 17 volume 33 (2010) stochastic graph transformation with regions electronic communications of the easst volume 29 (2010) proceedings of the ninth international workshop on graph transformation and visual modeling techniques (gt-vmt 2010) stochastic graph transformation with regions paolo torrini, reiko heckel, istván ráth and gábor bergmann 15 pages guest editors: jochen küster, emilio tuosto managing editors: tiziana margaria, julia padberg, gabriele taentzer eceasst home page: http://www.easst.org/eceasst/ issn 1863-2122 http://www.easst.org/eceasst/ eceasst stochastic graph transformation with regions paolo torrini1, reiko heckel2, istván ráth3 and gábor bergmann4 1 pt95@mcs.le.ac.uk 2 reiko@mcs.le.ac.uk university of leicester 3 rath@mit.bme.hu 4 bergmann@mit.bme.hu budapest university of technology and economics abstract: graph transformation can be used to implement stochastic simulation of dynamic systems based on semi-markov processes, extending the standard approach based on markov chains. the result is a discrete event system, where states are graphs, and events are rule matches associated to general distributions, rather than just exponential ones. we present an extension of this model, by introducing a hierarchical notion of event location, allowing for stochastic dependence of higherlevel events on lower-level ones. keywords: graph transformation, stochastic simulation, topology 1 introduction graph transformation combines the idea of graphs as a universal modelling paradigm with a rule-based approach to specify the evolution of systems [kk96]. behaviour can be modelled in terms of labelled transition systems, where states are graphs and rule applications represent transitions. a discrete event system can be generally obtained by interpreting rule matches as events. hierarchical graphs can be used to keep into account the spatial structure of graphs in terms of topological grouping, with advantages that have been underlined from the point of view of modelling and verification [bl09]. stochastic graph transformation is applicable to probabilistic analysis and stochastic validation of graph-based modelling. stochastic simulation can be particularly useful as validation technique when systems are too complex to be model-checked. it can be implemented relying on a discrete event system approach [cl08]. transitions are labelled by scheduling times, randomly chosen according to given probability distributions — thus replacing stochastic determinism for indeterminism in the models. a simple form of stochastic graph transformation can be obtained by associating rule names with exponential distributions [hlm06]. the associated markov-chain analysis has been applied to integrated modelling of architectural reconfiguration and non-functional aspects of network models [hec05]. however, this approach has some limits. exponential distributions can express well the relative speed of processes, but are less than suited to describe phenomena characterised by mean and deviation. generalised stochastic graph transformation can answer this problem, allowing for general distributions to be associated with rule names [kl07] and more generally 1 / 15 volume 29 (2010) mailto:pt95@mcs.le.ac.uk mailto:reiko@mcs.le.ac.uk mailto:rath@mit.bme.hu mailto:bergmann@mit.bme.hu sgt with regions with rule matches [ht10, kth09]. in the latter case, assignment of probability distributions to events may depend e.g. on attributes of match elements. generalised semi-markov processes provide the discrete event semantics for such systems. in reality, events can often be described at different levels of spatial and causal detail. the expression of causal dependency in graph transformation depends solely on rules and their matching. on the other hand, in the approaches that we have considered up to now, each event is treated as stochastically independent from any other with respect to the assignment of probability distributions. stochastic dependency on global variables and derived attributes has been considered [ht10]. even allowing that, it is not generally possible to express in a direct way e.g. that the probability of a certain event depends on other events. this can make it particularly hard to model aspects that involve correlation between different levels of description, as in the case of geographic and biochemical systems, where information is usually found at different levels of spatial granularity [tsb02]. in this paper we propose an approach based on hierarchical graphs in order to introduce localisation and granularity of events, we define a notion of structured stochastic simulation allowing us to express stochastic dependency of higher-level events on lower-level ones, and we provide a semantics for it in terms of discrete event systems. regardless of the specific approach, a major stumbling block in the implementation of stochastic simulation based on graph transformation is the need to compute all the matches at each step. this is hard in principle — the subgraph homomorphism problem is known to be np-complete, though feasible in many cases of interest. however, the cost of recomputing can be prohibitive. for this reason, we rely on incremental pattern matching based on a rete-style algorithm as implemented in viatra [bhrv08] (a model transformation plugin of eclipse). in [thr10] we presented grass, a tool that extends viatra with a stochastic simulation control based on the ssj libraries [lmv02]. by using a decoupled notion of graph hierarchy, it should be possible to implement hierarchical stochastic simulation in viatra/grass. 1.1 hierarchical extensions hierarchy in graph models can be used to introduce a notion of topological grouping on model elements. grouping information can be represented as a hierarchy graph, as distinct from the underlying graph, relying on a decoupled approach [bkk05]. in the case of bigraphs, the approach is to pair place graphs and link graphs, together with a specific notion of matching [mil08]. here we use topology to localise events, rather than elements, relying on a generic notion of rule matching. a model consists of an underlying graph coupled with a place graph, where the latter is a directed acyclic graph (dag) from which the hierarchy arises, as partial order (≤). topological grouping arises from rule matching through the hierarchy. nodes in the dag are places and edges represent containment between places (hierarchical containment). the two graphs are linked together by containment edges (coupling containment) that map underlying graph nodes to places. regions are defined as downward-closed sets with respect to the hierarchy, i.e. closed sets in the corresponding order topology [tsb02]. from the stochastic point of view, we use hierarchy to let lower-level events affect the assignment of probability distributions to higher-level ones. in particular, we allow for the distribution assigned to an event to depend (1) on the enabling of other events, and more generally on the proc. gt-vmt 2010 2 / 15 eceasst number of enabled matches of a certain type — what we call a density measure; (2) on the scheduling of other events — what we call an activity measure. in this way, we expect to be able to perform more sensitive stochastic analysis without resorting to making models and reachability analysis more complex. in fact, density measures boil down to counting matches, therefore they could be handled by introducing additional attributes in a flat model — though this would mean making the model more complex. activity measures are trickier, as in principle they might lead to circular dependencies. this is avoided by requiring that stochastic dependency between events as well as event time scheduling comply with the hierarchy. therefore, no event may depend on higher level ones, and at each step of the simulation, the time scheduling of lower-level events takes place before that of higher-level ones. 2 example we model a power grid as example in which higher-level events may depend stochastically on large numbers of lower-level ones. each power source serves a number of distribution points, by allocating power quotas in a reconfigurable way. appliances can be added to and removed from a distribution area, and they can be connected to and disconnected from distribution points, determining the level of consumption, which must remain within a tolerance of the quota. a power failure may occur when the quota is overstepped. a failure determines the disruption of the distribution point, with consequent loss of data, and it forces the intervention of a recovery unit. actual reconfiguration is carried out following optimisation criteria that can be reflected stochastically in the application of the rule. the model is based on the spo approach, and uses typed graphs with attributes. a power station is connected to each of the distribution points by power lines denoted by multi-edges, i.e. sets of parallel edges represented as a single edge with an integer value. a station can reconfigure the capacity of each power line depending on the available power and the distribution area consumption — this takes place by changing the number of line edges, also updating residual power and local quota. the spatial structure of the model is quite simple — there are three types of places: the network area, a supply area for each station, and a distribution area for each service point. each place is represented as a rounded box. the hierarchy order ≤ is represented as containment (larger boxes are places higher up in the order, therefore associated with higher-level elements). the coupling order is also represented as containment in an obvious way — each underlying graph node (a square box) being coupled only with the smallest place box it is contained in. in this example, the place graph is a tree. the notation could be easily extended to the dag case, by associating places to intersections. the symbols dec, inc, tol, add, f, g, h, p in the figures stand for given functions. the distinction between higher-level and lower-level events here is comparatively straightforward. the former ones are those associated with reconfigurations, failures and recoveries, and located in regions generated by supply areas. the latter ones are associated with adding, removing, switching on and off appliances, and are located in regions generated by distribution areas. from the stochastic point of view, actions that depend heavily on external aspects, such 3 / 15 volume 29 (2010) sgt with regions switchoff d:dpoint a:app d:dpoint a:app c2=dec(c1,x) c1:acons x:cweight c2:acons d:dpoint a:app c2=inc(c1,x) d:dpoint a:app switchon c1:acons l:quota c2:acons x:cweight c2l a b c a b c b:da c:sa recovery unit b:da c:saa:na a:na (a) failure, recovery figure 3: failure, recovery as adding appliances, switching on and failure, may be assigned exponential distributions. actions more plausibly associated with mean values, such as switching off and recovery, may be more naturally associated with normal distributions. crucially, reconfiguration can dependent stochastically on the context. in the example, there are two possible matches for the reconfiguration rule — one with a1 and the other with a2 as distribution areas. in order to model stochastically a “smart” reconfiguration strategy, one could make the probability of application inversely dependant on the difference between quota and area consumption (a derived attribute associated with distribution points and denoted by d in the picture). however, if that is to be the only criteria, here there is little chance of modelling a high quality of service without changing the model. given a high rate of switching on against a low one of appliance addition, the area a1 is more at risk than a2, in spite of the higher d value. this risk is essentially associated with the number of matches for switch on in a1, and further than that — with their scheduling times. of course it would be possible to retain information about the number of appliances in an area explicitly, by adding an attribute — however, apart from the need to extend the model, this way of capturing the density measure would not be the most natural in this case, as it would not belong to the service point. moreover, it is difficult to think of a similar way to capture an activity measure. on the other hand, the knowledge embedded in the reconfiguration strategy might be based on estimates rather than precise data. therefore, modelling it in terms of implicit stochastic dependence seems realistic. 3 stochastic graph transformation stochastic graph transformation for semi-markov process modelling requires us to track matches through transformation. incremental pattern matching is indeed based on tracking partial 5 / 15 volume 29 (2010) sgt with regions y:app s:ps w=1 a1:da x:app w=1w=1 w:app a2:da d2:dp d=1 d1:dp d=2 z:app (a) example figure 4: example matches. here we provide a general definition of typed graph transformation that supports tracking with respect to a generic approach (although the running example is based on spo), allowing for node type inheritance and negative application conditions. we then extend the notion, by endowing graphs with hierarchy and derived topological structure. 3.1 graph transformation in existing axiomatic descriptions of graph transformation [kk96], a graph transformation approach is given by a class of graphs g , a class of rules r, and a family of binary relations ⇒r⊆ g ×g representing transformations by rules r ∈ r. here we assume that each rule r is associated to a left hand-side graph lr and a set of negative application conditions nr. this notion can be further refined by introducing a definition of rule match depending on a given approach (including spo and dpo). in the following, we will sometimes use a syntax for function definitions with dependent types [bar92] in a comparatively informal way, in order to specify functions that we assume to be implementable, by writing πx ∈ α.β rather than α → β when x ∈ α and β depends on x. basically, a graph is a triple g = 〈nodesg, edgesg, asgg〉, where for x ∈ nodesg, asgg(x) = 〈y, z〉 with y, z ∈ nodesg. at an abstract level, a partial match of a rule r in a graph g can be represented as a triple m = 〈r, g, c〉, where r = rule(m), g = sg(m) is a partial graph morphism from lr into g, and c = ac(m) ⊆ nr is the set of application conditions that are satisfied. we denote the graph elements of the match, i.e. the image of m, by el(m). we say that a match m is valid when sg(m) is total and ac(m) = nr. we denote by mr,g the set of the partial matches of r in g. mr,g is ordered by a relation vr,g, component-wise defined as subgraph and subset relation on the sg and ac components of the matches, respectively. we define the set of all partial matches in a graph g as mg = ⋃ r∈r mr,g, and by m v g ⊆ mg the set of all those that are valid. def. 1 we define a function ⇒: πg ∈ g .mvg → g . we write g ⇒m h for ⇒ (g)(m) = h, and we say that this is the transformation step determined by the application of rule rule(m) to match sg(m) in graph g. proc. gt-vmt 2010 6 / 15 eceasst notice that transformation steps correspond to a function that is partially defined with respect to the set of all matches. the functional requirement captures the idea that rule application is well-defined and deterministic once a valid match m is found in g. this is needed, in order to guarantee that matches form a proper set, unlike in more abstract presentations [eept06]. also notice that, however, we implicitly allow for a global renaming action associated with a transformation. def. 2 a graph transformation system (gts) g = 〈r, g0〉 consists of a set r ⊆ r of rules and an initial graph g0 ∈ g . a transformation in g is a sequence of rule applications g0 ⇒m1 g1 ⇒m2 ···⇒mn gn using rules in g with all graphs gi ∈ g . assuming finite graphs and an enumerable set of rules, the graphs that are reachable from g0 by a finite sequence of transformation steps form a set, denoted by lg, and so do the partial matches over the reachable graphs, denoted by mg. even without fixing the approach, we can say that in general, a transformation step t = g ⇒m h is associated with a set delt of all the graph elements that are deleted or modified by t, and with a set cret of all the graph elements that are created by t. correspondingly, the partial matches that are destroyed form a set dg,t ⊆ mg, those that are created form a set ch,t ⊆ mh , and those that are preserved are m|t = mg\dg,t . from the deterministic assumption, mh = σt (m|t )∪cg,t follows, where σt is the renaming induced by t (assuming the name spaces are disjoint). we are interested in defining a notion of persistent match, by identifying matches that are preserved through transformation. in particular, from the point of view of stochastic models, given m1 ∈ σt (dg,t ), m2 ∈ dg,t and m2 = σt (m1), we want to identify m1 and m2 when they are both valid with respect to the same rule r. this can be generalised to partial matches. in [kth09, kl07] we relied on a conservative naming policy — here we adopt a looser one altogether, though still defining a persistent match as equivalence class. in order to abstract from renaming, we define, for n1 ∈ mr,g′, n2 ∈ mr,g′′, the symmetric relation n1 =a n2 that holds whenever for all transformation steps t, if t = g′⇒m g′′ and n1 ∈m|t , then n2 = σt (n1), and if t = g′′ ⇒m g′ and n2 ∈ m|t then n1 = σt (n2). we can then define the transitive closure using the least fixpoint operator (µ ) n1 ≡ n2 =d f µ e.(n1 = n2)∨(∃n3.e(n1, n3)∧n3 =a n2) it is a matter of routine to show that ≡ is indeed an equivalence relation. the persistent matches over the set of the reachable graphs in g can therefore be defined as the quotient class mg = mg/ ≡. we call event a persistent valid match, and we denote with eg the corresponding set of events. we define mg = {[m]|m ∈ mg}, and eg = {[m]|m ∈ mvg}. this in general will allow us to lift definitions from valid matches to events. lr n1 // = n2 88g t / h figure 5: persistence of matches 7 / 15 volume 29 (2010) sgt with regions 3.2 hierarchical structure we use hierarchical graphs in the decoupled sense [bkk05], i.e. we define a hierarchical graph as graph that includes the underlying graph as well as a directed acyclic graph representing the hierarchical structure. def. 3 a hierarchical graph is a graph g in which there is a distinguished dag pg ⊂ g called the place graph, where the nodes of pg are the places; (a) the edges that link nodes in g\pg to (non-empty) places, called c-edges, express coupling containment and form a distinguished set cedgesg ⊂ edgesg; (b) the edges connecting places together (h-edges) express hierarchical containment. moreover, the following conditions must be satisfied: (1) 〈pg,≤g〉 is a partial order (hierarchy of g), where ≤g is the reflexive-transitive closure of hierarchical containment. (2)